The RBAR application processes the Diameter Request message based on the configuration, to extract the User Identity addresses.
- Determine whether the Application ID in the message header is defined in the configuration.
If a valid Application ID cannot be found, the message is not processed. An Answer response with a Result Code AVP for DIAMETER_APPLICATION_UNSUPPORTED is returned.
- If a valid (configured) Application ID is received in a Diameter Request message, validate whether the pair (Application ID, Command Code) received in the message is defined in the configuration.
If the pair cannot be found in the configuration, the appropriate Routing Exception Handling procedure is invoked.
- If the pair is configured, search for a valid Routing Entity address in the message based on the highest priority Routing Entity Type (Primary Routing Entity Type in Address Resolution configuration) assigned to the pair.
- Search for a valid Routing Entity Address in the message based on a prioritized set of AVPs assigned to the triplet.
If a valid Routing Entity Address cannot be found in searching the configured Routing Entity Types assigned to the pair, the Routing Exception Handling procedure is invoked that is assigned to the Application ID and this Routing Entity Type.
Routing Exception Handling
When an ingress RBAR Request message cannot be resolved to a Destination (no address matched, no valid digits decoded, or any other error is returned), RBAR will invoke a Routing Exception Handling procedure based on user-defined configuration.
Routing Exception Handling procedures will result in one for the following configured actions:
- Forward the message unchanged
- Forward the message using a user-defined Default Destination
- Send Answer response with a user-defined Result-Code AVP value and Error-Message AVP
- Send Answer response with user-defined Experimental-Code AVP values and Error-Message AVP
- Abandon Request (discard the ingress Diameter Request message)
The following types of Routing Exceptions will be supported:
- Unknown Command Code
- Valid address not found
- Valid address was found and did not match a configured address or address range
Supported AVPs
RBAR supports the AVPs associated with a User Identity Type (IMSI, MSISDN, IMPI, IMPU), as defined in Table 1.
| AVPs | Vendor ID and AVP Code | AVP Type | AVP Reference |
|---|---|---|---|
| For a User Identity Type (IMSI, MSISDN, IMPI, IMPU) | |||
|
User-Name |
Vendor-ID: none AVP Code: 1 |
UTF8String |
Section 8.14 of RFC 3588bis |
|
Service-Information
|
Vendor-ID: 10415 (3GPP) AVP Code: 873 |
Grouped |
Section 7.2.192 of 3GPP 32.299 |
|
Subscription-Id
|
Vendor-ID: none AVP Code: 443 |
Grouped |
Section 8.46 of RFC 4006 |
|
Vendor-ID: none AVP Code: 444 |
UTF8String |
Section 8.48 of RFC 4006 |
|
Public Identity |
Vendor-ID: 10145 (3GPP) AVP Code: 601 |
UTF8String |
Section 6.3.2 of 3GPP 29.229 |
|
User-Identity:
|
Vendor-ID: 10415 (3GPP) AVP Code: 700 |
Grouped |
Section 6.3.1 of 3GPP 29.329 |
|
Vendor-ID: 10415 (3GPP) AVP Code: 701 |
OctetString |
Section 6.3.2 of 3GPP 29.329 |
|
Vendor-ID: 10415 (3GPP) AVP Code: 601 |
UTF8String |
Section 6.3.2 of 3GPP 29.229 |
| For a Routing Entity Type "IPv4 Address" | |||
| Framed-IP-Address |
Vendor-ID: none AVP Code: 8 |
OctetString |
Section 6.11.1 of RFC 4005 |
| For a Routing Entity Type "IPv6-Prefix Address" | |||
| Framed-IPv6-Prefix |
Vendor-ID: none AVP Code: 97 |
OctetString |
Section 6.11.6 of RFC 4005 |
Each of the configured User Identity types supported in RBAR is associated with certain AVPs that contain the User Identity type as defined by various Diameter application standards. Table 2 presents all possible combinations of the User Identity types and the associated AVPs.
| User Identity Types |
IMSI |
MSISDN |
IMPI |
IMPU |
|---|---|---|---|---|
| AVPs | ||||
|
MSISDN |
Applicable |
Applicable |
||
|
User-Identity: MSISDN |
Applicable |
Applicable |
||
|
Public-Identity |
Applicable |
Applicable |
Applicable |
Applicable |
|
User-Identity: Public-Identity |
Applicable |
Applicable |
Applicable |
Applicable |
|
User-Name |
Applicable |
Applicable |
||
|
Subscription-ID-Data (0-E.164) |
Applicable |
Applicable |
||
|
Service-Information: Subscription-ID-Data (0-E.164) |
Applicable |
Applicable |
||
|
Subscription-ID-Data (1-IMSI) |
Applicable |
Applicable |
||
|
Service-Information: Subscription-ID-Data (1-IMSI) |
Applicable |
Applicable |
||
|
Subscription-ID-Data (2-SIP URI) |
Applicable |
Applicable |
Applicable |
Applicable |
|
Service-Information: Subscription-ID-Data (2-SIP URI) |
Applicable |
Applicable |
Applicable |
Applicable |
|
Subscription-ID-Data (3-NAI) |
Applicable |
Applicable |
Applicable |
Applicable |
|
Service -Information: Subscription-ID-Data (3-NAI) |
Applicable |
Applicable |
Applicable |
Applicable |
|
Subscription-ID-Data (4-Private) |
Applicable |
Applicable |
Applicable |
Applicable |
Service -Information: Subscription-ID-Data (4-Private) |
Applicable |
Applicable |
Applicable |
Applicable |
|
Wildcarded-Public-Identity |
Applicable |
A User Identity type can be associated with one or more data formats that will be examined when deriving the user identity address from the associated AVPs. The relation between User Identity types and the corresponding data formats to be encountered in the ingress Diameter request message are listed in Table 3.
| Configurable User Identity Types |
IMSI |
MSISDN |
IMPI |
IMPU |
|---|---|---|---|---|
| User Identity Formats in Messages | ||||
|
IMSI Format: ASCII Example: 311480123456789 |
Applicable |
Applicable |
||
|
MSISDN Format: ASCII and TBCD Example: 19194605500 |
Applicable |
Applicable |
||
|
SIP URI with IMSI Format: ASCII |
Applicable |
Applicable |
||
Examples: sip:123456789012345@nai.epc.mnc456.mcc123.3gppnetwork.org sip:6311150999995555@ims.mnc015.mcc311.3gppnetwork.org sip:311480999995555@my.network.org sip: 6311480999995555@my.network.org |
||||
|
SIP URI with MSISDN Format: ASCII Examples: sip:+1-919-460-5500@xyz.com;user=phone sip:311480999995555@my.network.org |
Applicable |
Applicable |
||
|
SIP URI with NAI Format: ASCII Example: sip:handy.manny@xyz.com |
Applicable |
Applicable |
||
|
SIP URI with Wildcarded PSI Format: ASCII Example: sip:WP-A_ServiceType-!.*!@att.com |
Applicable |
|||
|
TEL URI with MSISDN FORMAT: ASCII |
Applicable |
Applicable |
||
Examples: tel:+1-919-460-5500;phone-context=example.com tel:+19258889999 tel:19195551212 |
||||
|
NAI with IMSI/MSISDN Format: ASCII |
Applicable |
Applicable |
Applicable |
Applicable |
Examples: 123456789012345@xyz.com 123456789012345 311480999995555@ims.mnc480.mcc311.3gppnetwork.org 6311150999995555@xyz.com 6311150999995555@ims.mnc015.mcc311.3gppnetwork.org |
||||
|
NAI Format: ASCII Example: handy.manny@xyz.com |
Applicable |
Applicable |
||
Routing Based on IMSI/MSISDN Prefix Lookup
If configured, RBAR will perform prefix-based lookups after the full address lookup is performed. The prefix and range based lookup will only be 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.
If a match is found in the prefix database, that RBAR application will populate the Destination-Host AVP and/or the Destination-Realm AVP based on the resolved destination.
If a match is not found in the prefix database, then RBAR will perform the "No Address Match Found" routing exception handling procedure.
The IMSI/MSISDN Prefix and Range lookup can be enabled or disabled on a system wide basis.
Identifying IMSIs and MSISDNs
In certain Diameter messages over the Cx interface (and possibly over the Sh interface), certain AVPs that typically carry an IMSI sometimes can carry an MSISDN.
Address resolution applications like Full Address Based Resolution (FABR) and Range Based Address Resolution (RBAR) need to categorize User Identities (digit strings) decoded from the Diameter Request AVPs as either MSISDN or IMSI, to allow looking up the User Identity in the appropriate lookup table.
- The configured Routing Entity Type
- The contents of the AVP
For instance, if the User Identity has been decoded from a SIP URI that has a "+" sign before the digits (such as sig:+1-919-460-5500@oracle.com), it can be directly categorized as an MSISDN.
- The number of digits in the User Identity
In certain cases, none of these methods allow a clear categorization (for example, if the number of digits needs to be used and the received number of digits are applicable to both IMSIs and MSISDNs, and thus leads to an ambiguous determination; or if there is no ""+" sign before the digits).
If RBAR has been configured to decode an IMPU/MSISDN from a User Identity (digit string) but cannot determine whether the user identity is an IMSI or an MSISDN based on digit analysis, a tie-breaker is needed to properly categorize the User Identity.
- RBAR extracts the first 5 or 6 digits of the User Identity and compares them against a list of configured 5- or 6-digit MCC-MNC combinations.
The Diameter Common > Network Identifiers > MCCMNC GUI pages can be used to configure up to 2500 distinct combinations of Mobile Country Code (MCC) and Mobile Network Code (MNC). (Refer to the "MCCMNC Configuration" section of the Diameter Common User's Guide and Help for procedures to configure MCC-MNC combinations.)
- If a match occurs, the User Identity is considered as an IMSI. RBAR will bypass the AVP, as RBAR does not support decoding an IMSI form a Routing Entity IMPU or MSISDN.
- If a match does not occur, the User Identity is considered as a MSISDN and used for MSISDN lookup.
