2.3 Request Message Validation

The derivation of a user identity address from the ingress diameter request message governed by the rules determined by user identity configuration. The configuration defines the supported application IDs, the supported command codes associated with each application ID, the preferred user identity types to search, and the associated AVPs that contain the user identity addresses.

The FABR application processes the diameter request message based on the configuration to extract the user identity addresses.

The diameter request message sent to FABR validates as followed:

• Determine whether the Application ID in the message header is defined in the configuration.
• If the diameter request message receives a valid (configured) Application ID, validate whether the pair (Application ID and command code) in the message is defined in the configuration.
• If the pair is configured, select the highest priority user identity type associated with the pair in the configuration for user identity address searching.
• Search for a valid user identity address from an AVP in the ingress message based on a prioritized set of AVPs assigned to the triplet (Application ID, command code, and then routing entity type).

If a user identity address cannot be found in searching the configured user identity types and AVPs, the No Valid Routing Entity Address routing exception handling procedure invokes.

Routing Exception Handling

When an ingress FABR request message cannot be resolved to a destination, (no address matched, no valid digits decoded, or any other error returns), FABR invokes a routing exception handling procedure based on user-defined configuration.

Routing exception handling procedures result in one of the following configured actions:

• Forward the message unchanged
• Forward the message using a user-defined default destination
• Send an Answer response with a user-defined result-code AVP value
• Send an Answer response with user-defined experimental-code AVP values
• Abandon Request

The routing exceptions types support the following:

• Unknown command code
• No valid routing entity addresses were found
• A valid routing entity address did not resolve to a configured address
• Blacklisted subscriber
• DP congestion
• DP errors

Supported AVPs

FABR supports the AVPs associated with the user identity types as defined in Table 2-1.

Note:

There is no support for Service-Information: Subscription-ID-Data (4-Server Private) in FABR and not looked up when retrieving a user identity address.

Table 2-1 FABR Supported AVPs

AVPs	AVP Code	AVP Type	AVP Reference
User-Identity [Public-Identity] [MSISDN]	700	Grouped	Section 6.3.1 of 3GPP 29.329
MSISDN	701	OctetString	Section 6.3.2 of 3GPP 29.329
Public-Identity	601	UTF8String	Section 6.3.2 of 3GPP 29.229
Service-Information [Subscription-ID] […]	873	Grouped	Section 7.2.192 of 3GPP 32.299
Subscription-Id [Subscription-ID-Type [Subscription-ID-Data]	443	Grouped	Section 8.46 of RFC 4006
Subscription-ID-Type	450	Enumerated	Section 8.47 of RFC 4006
Subscription-ID-Data	444	UTF8String	Section 8.47 of RFC 4006
User-Name	1	UTF8String	Section 8.14 of RFC 3588bis
Wildcarded-Public-​Identity	634	UTF8String	Section 6.3.35 of 3GPP 29.229
MSISDN	701	OctetString	Section 6.3.2 of 3GPP 29.329
Public Identity	601	UTF8String	Section 6.3.2 of 3GPP 29.229
User-Identifier: [User-Name] [MSISDN]	3102	Grouped	Section 6.4.2 of 3GPP 29.336
User-Name	1	UTF8String	Section 8.14 of RFC 6733
MSISDN	701	OctetString	Section 6.3.2 of 3GPP 29.329
External Identifier		UTF8String	Section 6.3.2 of 3GPP 29.336

Each of the configured user identity types supported in FABR is associated with certain AVPs that contains the user identity type as defined by various diameter application standards. Table 2-2 presents all possible combinations of the user identity types and the associated AVPs.

Table 2-2 Combinations of User Identity Types and Associated AVPs

User Identity Types/AVPs	IMSI	MSISDN	IMPI	IMPU
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	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
Wildcarded-Public-Identity				Applicable
User-Identifier: User-Name	Applicable		Applicable
User-Identifier: MSISDN		Applicable		Applicable
User-Identifier: External Identifier	Applicable	Applicable

A user identity type can be associated with one or more data formats that is 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 2-3.

Table 2-3 Relation between Configured User Identity Types and Data Formats

Configurable User Identity Types/User Identity Formats in Messages	IMSI	MSISDN	IMPI	IMPU
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:[e-mail] sip:[e-mail] sip:[e-mail] sip:[e-mail]
SIP URI with MSISDN Format: ASCII Examples: sip:[e-mail];user=phone sip:[e-mail]		Applicable		Applicable
SIP URI with NAI Format: ASCII Example: sip:[e-mail]			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:[phone]; phone-context=example.com tel:[phone] tel:[phone]
NAI with IMSI/MSISDN Format: ASCII	Applicable	Applicable	Applicable	Applicable
Examples: [e-mail] 123456789012345 [e-mail] [e-mail] [e-mail]
NAI Format: ASCII Example: [e-mail]			Applicable	Applicable

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.

Most of the time, these applications can clearly categorize the decoded user identity based on:

• 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 plus sign before the digits (such as sig:[e-mail]), 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 plus sign before the digits).

If FABR has been configured to decode an IMPU 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.

If the routing entity type is IMPU, the user identity extracted results in only digits, and the length of the digits in the user identity falls within an overlap digits range of MSISDN and IMSI, the following logic can be used to determine if the user identity is an IMSI or MSISDN.

• FABR 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, and then Network Identifiers, and then MCCMNC pages can be used to configure up to 2500 distinct combinations of Mobile Country Code (MCC) and Mobile Network Code (MNC). (Refer to 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 and used for IMSI lookup.
• If a match does not occur, the user identity is considered as an MSISDN and used for MSISDN lookup.