1. Feature Guide
  2. DSR Features and Functions
  3. DSR Applications
  4. Full Address Based Resolution

2.13.2 Full Address Based Resolution

Full address based resolution is a DSR enhanced routing application which allows the user to route Diameter end-to-end transactions based on Application ID, Command Code, “Routing Entity” Type, and individual Routing Entity. For FABR a Routing Entity can be a User Identity (IMSI, MSISDN, URI, wild carded NAI, External-Identifier, IMPI or IMPU). The FABR also supports third (tertiary) routing entity search in the priority list for performing Destination lookups for a given application-id and command code. That is, customers can use up to 3 routing entities to perform address Resolution, for e.g. IMSI, MSISDN and External-Identifier in the preferred order of priority. Each Routing Entity supports up to two prioritized AVPs that are searched for in the ingress Diameter message resolving to configure Destination node. As in RBAR, routing resolves to a “Destination” which can be configured with any combination of a Realm and FQDN (Realm-only, FQDN-only, or Realm and FQDN). Prefix filtering is provided with the creation of a user-configurable table filled with invalid IMSI MCC values that is used during IMSI validation prior to using the IMSI value for address resolution. The address resolution application checks against ranges of MCC values which are then used to invalidate an IMSI.

The FABR application routes all messages as a Diameter Proxy Agent. When a message successfully resolves toa Destination, FABR replaces the Destination-Host and possibly Destination-Realm AVP in the ingress message,with the corresponding values assigned to the resolved Destination, and forwards the message to the DSR RelayAgent for egress routing into the network. FABR uses the remote database storage called DSR Data Repository(DDR) to store subscriber data. DDR is hosted on the Database Processor blades at each node.

A GUI is provided allowing the operator to provision MCC-MNC combinations of all network operators in the world including the country and network name. A list of all the well-known MCC-MNC combinations are pre-populated at installation time but these can be modified/deleted at a later time.

Subscriber Data Server (SDS) Integration

Oracle Communication’s Subscriber Data Server (SDS) integrates with the DSR to provide the following functions:

  • Provisioning and storage of large amounts of database information required for the Full Address Based Resolution (FABR) feature.
  • Replication of information across multiple sites so that the data may be queried at the DSR sites.
  • Support for querying by backend Operating systems to maintain reports and audit information.

The central provisioning capability is provided by the SDS component. The SDS is deployed optionally geo-redundantly at a Primary and Disaster recovery site. A Query Server component that processes queries from backend customer operations systems is deployed optionally geo-redundantly at the Primary and Disaster Recovery SDS site. FABR data along with any other future DSR specific subscriber data is termed DSR Data. The application hosting the DSR Data is termed the DSR Data Repository (DDR). The SDS supports a SOAP/XML interface for provisioning. This interface supports Insert, Update & Delete functions on the Subscriber profile.

Figure 2-49 Subscriber Data Server Architecture


Subscriber Data Server Architecture

The SDS also supports Split NPA data. When a service provider exhausts all MSISDNs within a Numbering Plan Area (NPA), the service provider commonly adds another NPA to the region. The result of assigning a new NPA is called a NPA Split. As new NXXs are defined in the new NPA, existing exchanges (NXXs) may be assigned to the newly created NXXs from the old NPA. The new and the old NXX have the same value.

When an NPA split occurs, a period of time is set aside during which a subscriber can be reached via phone number using old NPA-NXX and via phone number using new NPA-NXX. This period is called Permissive Dialing Period (PDP).

NPA splits apply to MSISDNs. During the NPA Split process, the SDS will automatically create duplicate MSISDN records at the start of Permissive Dialing Period (PDP) time (activation) and delete old MSISDN records at the end of PDP time (completion).

The SDS Subscriber Identity Grouping (Subscribers page) allows users to group optional customer-specified account IDs, multiple MSISDNs routing entities, and/or multiple IMSI routing entities together into one Subscriber. After a Subscriber (a group of related routing entities and an optional Account ID value) is created, the destinations for all of the related routing entities can be updated, all data from the subscriber can be read, and the subscriber can be deleted or its addresses modified by using any of the subscriber’s addresses (account ID, MSISDN, orIMSI).

In order to help maintenance personnel with trouble shooting at the Query Server, records belonging to a single subscriber are now correlated at the SDS and the Query Server.

User Data Repository (UDR) Integration

Oracle Communication’s User Data Repository (UDR) integrates with the DSR to provide the following functions:

  • Provisioning and storage of large amounts of database information required for the Full Address Based Resolution (FABR) feature.
  • Replication of information across multiple sites so that the data may be queried at the DSR sites.
  • Support for querying by backend Operating systems to maintain reports and audit information.

The central provisioning capability is provided by the UDR component. The UDR is deployed optionally geo-redundantly at a Primary and Disaster recovery site. A Query Server component that processes queries from backend customer operations systems is deployed optionally geo-redundantly at the Primary and Disaster Recovery UDR site. FABR data along with any other future DSR specific subscriber data is termed DSR Data. The application hosting the DSR Data is termed the DSR Data Repository (DDR). The UDR supports a SOAP/XMLinterface for provisioning. This interface supports Insert, Update & Delete functions on the Subscriber profile.

Figure 2-50 User Data Repository Architecture


User Data Repository Architecture

The UDR also supports Split NPA data. When a service provider exhausts all MSISDNs within a Numbering Plan Area (NPA), the service provider commonly adds another NPA to the region. The result of assigning a new NPA is called a NPA Split. As new NXXs are defined in the new NPA, existing exchanges (NXXs) may be assigned to the newly created NXXs from the old NPA. The new and the old NXX have the same value.

When an NPA split occurs, a period of time is set aside during which a subscriber can be reached via phone number using old NPA-NXX and via phone number using new NPA-NXX. This period is called Permissive Dialing Period (PDP).

NPA splits apply to MSISDNs. During the NPA Split process, the UDR will automatically create duplicate MSISDN records at the start of Permissive Dialing Period (PDP) time (activation) and delete old MSISDN records at the end of PDP time (completion).

The UDR Subscriber Identity Grouping (Subscribers page) allows users to group optional customer-specified account IDs, multiple MSISDNs routing entities, and/or multiple IMSI routing entities together into one Subscriber. After a Subscriber (a group of related routing entities and an optional Account ID value) is created, the destinations for all of the related routing entities can be updated, all data from the subscriber can be read, and the subscriber can be deleted or its addresses modified by using any of the subscriber’s addresses (account ID, MSISDN, or IMSI).

In order to help maintenance personnel with trouble shooting at the Query Server, records belonging to a single subscriber are now correlated at the UDR and the Query Server.

Limitations of UDR

As DSR can now send FABR queries to UDR, unlike SDS the following features are currently not supported by UDR:

  • Prefix Search for IMSI and MSISDN.
  • External Identifier match partial (Domain identifier).
  • 16 priority Support.
  • NGN PS priority Support.
  • Wild Card Nai User.

FABR Blacklist

The FABR application also supports the rejection of Diameter requests which carry a blacklisted IMSI/MSISDN. A blacklist search is performed prior to the Full address search. This search can be enabled for a combination of Application-Id, Command-Code, and Routing Entity. If a match is found during the blacklist search, the operator is able to configure FABR, on a per Application-Id basis, to either respond to the Diameter request with a configurable Result-Code/ Experimental Result-Code, or Forward the Request to a default destination or forward the Request unchanged.

A total of 1 Million IMSIs and 1 Million MSISDNs (not prefixes) are supported for blacklisting. The IMSIs are of fixed length (15 digits long) and the MSISDNs are provisioned as E.164 numbers (includes the Country code but with out the + sign). The blacklisted IMSIs and MSISDNs are provisioned via the SDS/UDR GUI or via bulk import using a CSV file.

IMSI/MSISDN Prefix Lookups

Operators use FABR to resolve individual subscriber IMSIs or MSISDNs to specific end points such as a HSS. This ability to resolve the address on an individual subscriber basis provides the highest degree of freedom and flexibility to the operator and allows for subscribers to be assigned to an HSS based on a criteria that fits the operator’s needs.

The prefix lookups allow an operator to manage routing based on IMSI prefixes/ranges. All the IMSIs that fall under a particular IMSI prefix/range resolve to the same end point. For example, a block of IMSIs for Machine-to-Machine(M2M) communication could be used and the operator wishes to route all registration requests arising from these IMSIs to a specific HSS (or a set of HSSs) that is dedicated for M2M. Providing the ability to provision ranges results in significant operational savings from a provisioning point of view.

Prefix based lookups are performed after the full address lookup. The prefix based lookup is only performed if the full address lookup does not find a match and can be enabled by the operator for a combination of Application-Id,Command-Code and Routing Entity Type. For example, an operator can choose to perform the prefix lookup onlyon the S6a-AIR request but not on the other S6a requests. The Routing Entity Type provides additional granularity when the same request carries multiple subscriber identities and the prefix lookup is performed only for one of those identities but not both. For example, certain Cx Requests are known to carry both an IMSI and an MSISDN and this feature allows an operator to perform a prefix lookup for the IMSI but not for the MSISDN.92 | ORACLE COMMUNICATIONS DIAMETER SIGNALING ROUTER RELEASE 9.0.0.0.0 FEATURE GUIDEMSISDN prefixes are supported as well. This allows an operator to route a Diameter Request such as the Cx-LIRbased on a prefix if the individual entry is not found.