DSR Applications Overview

Full Address Based Resolution

Full Address Based Resolution (FABR) is a DSR enhanced routing application that resolves the designated Diameter server (IMS HSS, LTE HSS, PCRF, OCS, OFCS, and AAA) addresses based on configured Diameter Application ID, Command Code, Routing Entity Type, and Routing Entity addresses.

The FABR application validates the ingress Diameter Request message, retrieves the Application ID and Command Code from the message, and determines the desired Routing Entity Type to be decoded from the message, based on the configuration.

The FABR application extracts the Routing Entity address from user-configured Attribute-Value Pairs (AVPs) in the ingress message and sends the successfully extracted Routing Entity address to an off-board SDS DP for destination address resolution.

The resolved destination address can be any combination of a Realm and Fully Qualified Domain Name (FQDN), such as Realm-only, FQDN-only, or Realm and FQDN.

The FABR application replaces the Destination-Host and/or Destination-Realm AVP in the ingress Request message with the corresponding values of the resolved destination, and forwards the message to the Diameter Routing Function for egress routing into the network.

FABR Deployment with SDS

DSR deployments that include support for the DSR Full Address Based Resolution (FABR) application must be deployed with the Subscriber Database Server (SDS). The SDS is used to provision the FABR subscriber data.

The SDS DP system consists of a Primary Provisioning Site, a Disaster Recovery (DR) Provisioning Site, and DSR Signaling Site servers with redundant DP SOAM servers and up to 2 DP blades. Each Provisioning Site has an Active/Standby pair of servers in a high availability (HA) configuration and a third server configured as a Query Server.

The DSR SOAMP and the SDS SOAMP servers are run on the DSR OAM blade using virtualization technology. It is assumed that most deployments that support both DSR and SDS will deploy the DSR NOAMP on Rack Mount Servers, as this is how the SDS NOAMP is deployed. Small deployments that minimize the amount of hardware investment require the DSR NOAMP to be deployed as a virtual server on the OAM blade. This requires running three Virtual Machines (VMs) on the blade – DSR NOAMP, DSR SOAMP and SDS SOAMP.

Range Based Address Resolution

Range Based Address Resolution (RBAR) is a DSR-enhanced routing application that allows the routing of Diameter end-to-end transactions based on Diameter Application ID, Command Code, Routing Entity Type, and Routing Entity addresses (range and individual) as a Diameter Proxy Agent.

Routing resolves to a destination that can be configured with any combination of a Realm and Fully Qualified Domain Name (FQDN): Realm-only, FQDN-only, or Realm and FQDN.

When a message successfully resolves to a destination, RBAR replaces the destination information (Destination-Host and/or Destination-Realm) in the ingress (incoming) message, with the corresponding values assigned to the resolved destination, and forwards the message to the Diameter Routing Function for egress (outgoing) routing into the network.

Charging Proxy Application

The Charging Proxy Application (CPA) is a DSR Application is responsible for routing Diameter accounting (Rf) messages that are being exchanged between Offline Charging clients (CTFs) and servers (CDFs).

The CPA communicates with an off-board (resides on a different MP) Charging Session Binding Repository (SBR) database that stores the session binding information to enable the Topology Hiding that the CPF provides. The Charging SBR stores information that the CPA uses for consistently routing Diameter requests from instances of Charging Trigger Function (CTF) to instances of Charging Data Function (CDF). For any given session, the CPA stores in the Charging SBR the identity of the CDF that the CPA has chosen to service the Diameter requests for that session, or a session binding. When the CPA routes subsequent Diameter requests for a session, it queries the Charging SBR for the session binding to determine the identity of the serving CDF. The Charging SBR database can be distributed over multiple physical servers using database slices (partitions) to reduce the volume of replication typically required for a large database.

The CPA enables load balancing of ACR-Start and ACR-Event messages across CDFs. The CPA also sets the preferred CDF value in the Charging SBR. The preferred CDF is used for the duration of the Rf accounting session. The CPA updates the preferred CDF in the event of a CDF failover.

The CPA is also responsible for triggering Message Copy. For the CPA, Message Copy allows ACR-Start or ACR-Event messages that match a configured rule to be copied to a Diameter Application Server (DAS). A triggering condition or rule can be defined in the CPA configuration. When a Diameter Request meeting the triggering condition is received by the DSR, the message is marked as ready to copy by the application as it is processed. When the response to the Request (the Answer) is received, if the Answer contains the correct result code as specified by the system-wide configuration, the resulting action is executed. The action for Message Copy is to copy the Request and send the copy to a DAS Peer Message Copy can be enabled and disabled without impacting the other functions of the CPA.

Policy and Charging Application

A PCA DSR consists of a number of PCA DA-MP server, a number of SBR servers, OAM servers, and optional IPFE servers. The PCA DA-MPs are responsible for handling Diameter signaling and implementing the Policy DRA and Online Charging DRA functionalities, as well as the overall PCA application itself.

SBR servers host the policy session and policy binding databases for the P-DRA function and session database for the OC-DRA function. These are special purpose MP blades that provide an off-board database for use by the Policy DRA feature hosted on the Policy DRA DA-MPs. Policy SBRs host the Policy session and Policy Binding databases.

Each PCA DSR hosts connections to clients and to policy/charging servers such as OCSs and PCRFs. Clients are devices that request authorization for access to network resources on behalf of user equipment (such as mobile phones) from the PCRF, or request billing/charging instructions from an OCS. Policy Clients sit in the media stream and enforce Policy rules specified by the PCRF. Policy authorization requests and rules are carried in Diameter messages that are routed through Policy DRA. Policy DRA makes sure that all Policy authorization requests for a given subscriber are routed to the same PCRF. Charging clients (CTF) generates charging events based on the observation of network resource usage and collects the information pertaining to chargeable events within the network element, assembling this information into matching charging events, and sending these charging events towards the OCS.

PCA DSRs can be deployed in mated pairs such that policy session state is not lost, even if an entire PCA DSR fails or becomes inaccessible. When PCA mated pairs are deployed, the clients and PCRFs/OCSs are typically cross-connected such that both PCA DSRs have connections to all clients and all PCRFs/OCSs at both mated sites.

PCA DSRs can also be deployed in mated triplets such that session states are not lost, even if two PCA DSRs fail or become inaccessible. When a PCA mated triplet is deployed, clients and PCRFs/OCSs are cross-connected such that all three PCA DSRs have connections to all policy clients and all PCRFs/OCSs associated with the mated triplet.

“PCA network” is the term used to describe a set of PCA mated pairs and NOAM server pair/triplet. All clients and PCRFs/OCSs are reachable for Diameter signaling from any PCA DSR in the PCA network.

Gateway Location Application

Gateway Location Application (GLA) is a DSR Application that retrieves subscriber data stored in Session Binding Repository (SBR) provided by PCA. The GLA is deployed in a network model with PCA and has access to all SBR data used by PCA. A key concept is any DA-MP running GLA must be in the same Resource Domain as DA-MPs running PCA. This does not imply any additional Resource Domain configuration is needed specifically for GLA in the DSR GUI.

To simplify deployment of GLA, it is piggybacked on PCA's configuration of DA-MPs within its Resource Domain and configuration of ComAgent connections between DA-MPs and SBRs.

The GLA uses identical access methodologies (an Active/Standby/Spare HA model combined for server redundancy, and splits the database storage resource into multiple sub-resources for load-sharing) as PCA to read the subscriber information from SBR. When GLA queries SBR for a subscriber's information, it must find the same Active sub-resource that Policy DRA is using.

Alarms are generated by the GLA based on its ingress message rate. It is a notification mechanism to the customer; that higher than expected rates of traffic are being processed by the DSR Application. The customer configures the points of the alarms for the GLA Ingress Message Rate. If GLA receives a message that cannot be decoded, it will abandon the Diameter Request message processing, generate a Message Decoding Failure, peg measurement failures and handle the exception based on the user configuration. Refer to DSR Alarms and KPIs Reference and DSR Measurements Reference for other GLA specific alarms.

MAP-Diameter Interworking Function

The DSR MAP-Diameter Interworking Function feature allows the DSR to support bi-directional interworking between Diameter and SS7-MAP messages. This functionality is carried out by two applications: DM-IWF and MD-IWF.

DM-IWF is a DSR application that runs on each DA-MP. It manages MAP-Diameter Interworking transactions received from the Diameter network via DRL and MAP-Diameter Interworking transactions received from SS7-MPs.

MD-IWF is a TCAP application which runs on each SS7-MP. It manages MAP-Diameter Interworking transactions received from the SS7 network (via TCAP) and MAP-Diameter Interworking transactions received from DA-MPs.

The MAP-Diameter Interworking assumes the following things regarding the relationship between the two applications.

• All MAP-Diameter message and parameter interworking is performed on the SS7-MP.
• DM-IWF and MD-IWF exchange Diameter messages using ComAgent. No SS7/MAP message are exchanged between DA-MPs and SS7-MPs. Diameter messages are sent using a new stack event called IWF-Application-Data.
• When a transaction is initiated by either a DM-IWF or MD-IWF instance, it creates a Transaction ID which is unique to the DM-IWF/MD-IWF instance which is initiating the inter-MP transaction. The Transaction ID is sent as an IWF-Application-Data stack event parameter that correlates the messages/responses exchanged between DM-IWF and MD-IWF associated with a transaction. When DM-IWF or MD-IWF sends a response to the request, it echoes the transaction ID from the Request to allow the recipient to correlate the response with the request it had previously sent. The internal Transaction ID eliminates the need to manage Hop-by-Hop IDs in Diameter messages exchanged between DM-IWF and MD-IWF.
• DM-IWF and MD-IWF will use ComAgent's Routed Service with Reliable Transfer now support capabilities that allow eliminating the need for DM-IWFs and MD-IWFs to track growth/degrowth of SS7-MPs and DA-MPs respectively. In this document, any reference to DM-IWF Routed Service or MD-IWF Routed Service should be understood to mean ComAgent Routed Service using Reliable Transfer, utilizing Routed Service enhancements.
  Note: Service users and providers can now dynamically register against the Routed Service. Service Providers publish their own provider status. ComAgent Routed Service accounts for each registered service provider's status and congestion level when selecting service providers to distribute Requests.
• DM-IWF and MD-IWF will use ComAgent's Direct "EventTransfer" Service to route Answer message responses to the specific MD-IWF and DM-IWF respectively which initiated the transaction.

SS7/Sigtran

SS7/Sigtran provides the Signaling Network Interface for the MD-IWF SS7 Application. The interface supports standards-based M3UA, MTP3, and SCCP signaling.