S8HR Roaming Compatibility

The Oracle Communications Session Border Controller (SBC) allows you to configure support for S8 Home Routing (S8HR) routing architecture. S8 is the 3GPP-defined Packet Data Network (PDN) Gateway to Serving Gateway (S-GW) interface used when a UE is roaming. S8HR is described in full by 3GPP TR 23.749. The SBC feature provides support for UE connectivity. sec-agree and emergency call services.

S8HR Overview

S8HR supports roaming in VoLTE networks whereby the IMS infrastructure elements are located in the Home Public LAN Mobile Network (HPLMN), and the UE is roaming in a Visited Public Land Mobile Network (VPLMN).

Applicable IMS infrastructure elements include:

Packet Data Network Gateway (PGW) —Supports the UNI interface from the roaming UE to the HPLMN
Policy and Charging Rules Function (PCRF)—Supports the policy decision function by acting as the source for validating roaming and the International Mobile Equipment Identity (IMEI)
Proxy-Call Session Control Function (P-CSCF)—The SBC performs this function at the HPLMN edge.

Interconnections between S8HR components are displayed below.

Key S8HR features include:

IMS services are home-routed using a "well known" IMS Access Point Name (APN) via the S8 interface, similar to other data roaming traffic. Signaling and media use the same "well known" IMS APN established with the HPLMN, each with a specific QoS Class Identifier (QCI).
The HPLMN controls call routing and per service logic.
The IMS UNI is provided directly between UE and the HPLMN over the S8 interface. (S8HR does not require an IMS network-to-network interface (NNI) between the VPLMN and HPLMN.)
The VPLMN is not service aware but it is QoS/APN aware.
The architectures uses the Policy and Charging Control (PCC) framework of the HPLMN. QoS rules are generated in the HPLMN and enforced by the VPLMN per the carriers' roaming agreement.

Within the context of S8HR roaming support, the SBC is responsible for:

Providing VPLMN identity to IMS entities in HPLMN
- The HPLMN IMS entities need to be aware of the ID of the visited PLMN at session set up to populate the charging records.
- During the registration, the S-CSCF and TAS need to be made aware about the ID of the visited PLMN to enable the HPLMN to subsequently perform roaming registration restriction or communication barring supplementary services.
- To handle a non-UE detectable IMS emergency session establishment, the P-CSCF needs to be aware of the MCC of the VPLMN from where the UE initiates the IMS session. This information is needed at the P-CSCF at every IMS session establishment.
Enforcing encryption procedures and requirements
- The HPLMN must ensure that the IMS layer signaling and media confidentiality protection can be de-activated to enable the VPLMN to meet local regulatory requirement.
- The SBC shall force NULL encryption for roaming users as part of the sec-agree negotiating mechanism based on an Mobile Network Code (MNC) and Mobile Country Code (MCC) match configured on the SBC.
- When Sec-Agree (IMS-AKA) and S8HR are both enabled, the SBC triggers an AAR upon 1st unsecured SIP REGISTER to determine if the roaming network does not need encryption.
Supporting Emergency calls
Since there is no NNI over which typical authentication can be performed, the SBC enables the network to skip the IMS level authentication with sufficient confidence based on the fact that the UE has been successfully authenticated at EPS level. The identities number retrieved via the PCRF serves as a "soft" proof with which IMS proceeds without authenticating the UE at the IMS level.

S8HR Configuration and Configuration Considerations

To enable S8HR roaming, you create an S8HR profile and apply it to the applicable interface. Refer to the detail on profile configuration within this document.

S8HR roaming, however, is dependent on additional SBC configuration for its functionality:

You must have enabled the VoLTE feature flag.
sip-interface, sip-ims-feature enabled
You must have enabled the Sec-Agree feature.
sip-interface, sec-agree-feature enabled and

sec-agree-pref is configured as 3gppIpsec
You must have disabled the Provision Signaling Flow feature.
media-manager, ext-policy-server, provision-signalingflow disabled.
You must configure a subscription to PLMN changes.
media-manager, ext-policy-server, specific-action-subscription set to plmn-change.
You must configure a signaling flow subscription when you need to support an Abort-Session-Request (ASR) via the PCRF to close a session when a user returns to their home-network from a roaming network. This allows the system to de-register and clear the registration cache of the user. Upon receiving a new register request from user, the system performs a new Rx dip.
media-manager, ext-policy-server, specific-action-sig-flow-subscription set to release-of-bearer
You must enable network management controls on the realm.
media-manager, realm-config, net-management-control enabled.
You must have configured an external policy server and applied it to a SIP interface.
media-manager, ext-policy-server configured and applied to the sip-interface:
- reserve-incomplete set to enabled or origin-realm-only.
- optimize-aar disabled
- asynchronous-mode disabled

If you intend to accept unregistered emergency calls:

Reject Unregistered priority calls feature is disabled
sip-interface, options, reject-unreg-priority-calls disabled and

sip-interface, send-380-response set to null
You must have disabled the disallow priority calls feature.
sip-interface, options, disallow-priority-calls disabled

Reporting on S8HR Operation

The show sipd register command includes cached information, including the MNC/MCC/IMSI/IMEI/MSISDN for each user, and specifies if the user is an emergency roaming contact.

ORACLE# show sipd register

In addition, the show sipd status includes the following S8HR-related statistics:

Forward User PVNI
Forward Default PVNI
Encrypt Disabled
S8HR Emgy Reg 200
S8HR Emgy Reg 403
S8HR Emgy Inv
S8HR Emgy Inv 403

ORACLE# show sipd status

VPLMN-ID Management Support

The Oracle Communications Session Border Controller (SBC) performs tasks to ensure the HPLMN IMS entities are aware of the VPLMN-ID at session set up for multiple purposes, including populating the charging records. 3GPP TR 23.749 covers this process

To support connectivity, the home network determines the serving PLMN of the UE using a procedure where the P-CSCF (SBC) gets the current location of the UE during registration and maintains it by establishing a PLMN-ID via AAR/RAR exchanges with the PCRF. The P-CSCF forwards this PLMN-ID information in the SIP REGISTER request in the P-Visited-Network-ID header, in addition to other SIP transactions.

Examples of other SIP message that use this roaming location information from the P-CSCF include:

The P-CSCF creates and inserts the PLMN-ID into any INVITE coming from the UE.
The P-CSCF can include the P-Access-Network-Info and P-Visited-Network-ID header in the SIP Register before forwarding.
To handle non UE detectable IMS emergency session establishment the P-CSCF needs to be aware of the MCC of the VPLMN from where the UE initiates IMS session. This information is needed at the P-CSCF for every IMS session.

PLMN-ID Info Subscription Case

UE registration also triggers the P-CSCF subscription to the PLMN-ID changes via the PCRF. During the subscription, the PCRF retrieves the PLMN-ID from the PGW and provides the information to the P-CSCF using a NOTIFY message.

During this exchange, the subscription from the P-CSCF can trigger a subscription by the PCRF to the P-GW, if one is not already in place. The subscription sequence results in the P-CSCF receiving MCC and MNC information to be used for the PLMN-ID, which it then stores for use with the subsequent REGISTER and other sessions.

As long as the registration is in effect, the PCRF sends the P-CSCF NOTIFY messages when the PLMN-ID changes. Termination of the registration, by any means, triggers the systems to terminate the subscription.

PLMN-ID Info Registration Scenarios

During the registration, the S-CSCF and Telecommunication Application Server (TAS) need to know the ID of the visited PLMN for charging purposes and to enable the HPLMN to subsequently perform roaming registration restriction or communication barring supplementary services. The P-CSCF gets this information by subscribing to the PLMN Change via the PCRF.

Initial SIP REGISTRATION with PLMN-ID information is provided in the AAR/AAA exchange. This is similar to and happens in conjunction with the subscription logic above. Registration scenarios, however, also include applicable updates via RAR/RAA exchanges. The scenario assumes that both the AAA and RAR arrive within the holding period. The PLMN ID information is passed on via P-Visited- Network-ID header.

Ibn this case, key AVPs include:

- Required-Access-Info—The USER_LOCATION value holds the PLMN-ID for use by the S-CSCF.
- Specific-Action—The PLMN_CHANGE value informs the components of the action.
- 3GPP-SGSN-MCC-MNC— Provides information used for P-Visited-Network-ID and queues the system to reset the register-hold-for-plmn-info timer.

The typical initial registration scenario includes both AAR and RAR exchanges occurring within the S8HR profile's hold time.

Additional scenarios, with deviations from the basic registration scenario include:

PLMN-ID Info received by AAA and hold time expired—If the profile's hold time expires before, the SBC proceeds without the RAR/RAA exchange, creating the PLMN-ID with information determined during the AAA/AAR exchange and forwarding the REGISTER.
Hold time expired, default PLMN-ID Info is used—This scenario differs from a typical registration in that the SBC does not receive or have any PLMN-ID information prior to the hold time expiry. The SBC proceeds, however, using default PLMN information you configure on the access side of sip interface (session-router, sip-interface, network-id. The SBC adds this default PLMN information to the SIP REGISTER message in the P-Visited-Network-Id header and forwards it to the core.
PLMN-ID Info re-registration—The P-CSCF supports re-registration, triggered by the UE and avoiding the any Rx exchange, using cached location information and relying on the subscription to update that information if it changes. If the NPLI feature is enabled and the re-registration occurs after more than half the registration time has expired, however, the SBC proceeds with the Rx exchange. In addition, the SBC renews its subscription to PLMN information changes. Furthermore, the SBC sends out the REGISTER with both PVNI (for S8HR) and PNNI (for NPLI) headers.
PLMN-ID Info de-registration Case—The SBC performs standard de-registration procedures. This happens the UE presents a re-registration with an expires time of zero or the registration reaches its previously set expires time. The SBC also un-subscribes from the PLMN changes using STR exchanges with the PCRF.

Sec-Agree for S8HR Roaming Support

The Oracle Communications Session Border Controller (SBC) supports security agreement negotiation as described in RFC3329. For S8HR, the SBC extends upon sec-agree to disable encryption for trusted roaming networks. You specify which networks are trusted with the s8hr-profile that you apply to an interface. The SBC enforces your configuration by offering NULL as the only encryption algorithm for trusted networks.

The SBC determines whether a network is trusted based on its VPLMN-ID. To determine this, the SBC queries the PCRF. The subsequent Rx exchange provides the VPLMN-ID. The SBC triggers this Rx exchange when it receives the unsecured 1st REGISTER. (PLMN info is required from the PCRF to determine whether or not the UE is roaming.)

Note:

The SBC also performs functions, including NPLI subscription and PANI header population upon this 1st REGISTER to minimize the number of Rx queries.

System process:

Determine if UE is roaming with S8HR by comparing the local configured MNC/MCC with the roaming MNC/MCC received via Rx and cached for this contact. If they are different, the UE is roaming with S8HR.
Check if the sip-interface is configured to disable encryption for all roaming partners. The encrypt-disabled-mnc-mcc parameter takes a list of roaming network MNC/MCC the S8HR profile defines to disable the encryption.
Check if roaming network (core) is one of the configured partners to disable the encryption. SBC compares the roaming MNC/MCC to the encryption disable network list configured in the S8HR profile.
If applicable, disable encryption for this roaming network (core). The SBC caches the “encryptDisabled” flag for the contact and sets all subsequent SIP request message security headers with the ealg parameter set to NULL.

MNC/MCC received from the PCRF are presented as unsigned integer data type. They are converted to a string in MNC/MCC format where 0-3 characters are MNC and 4-6 characters are MCC. The SBC uses this same format for the encrypt-disabled-mnc-mcc parameter.

Note:

The ealg header presents only when sec-agree chooses “ipsec3gpp” as the security mechanism.

The uses the Rx exchange to determine the roaming network and whether or not it is on the encryption disable list. If so, encryption is disabled in SIP message header.

Additional considerations include:

The HPLMN must be able to ensure that the IMS layer signaling and media confidentiality protection is not activated in order to enable the VPLMN to meet the local regulatory requirements.
If the HPMN uses IMS layer signaling and media confidentiality protection on its network (e.g. for the HPMN’s own subscribers, for inbound roaming LBO IMS subscribers), then based on the customer location and IMS Roaming agreement type, this protection may have to be deactivated in the HPMN.

Emergency Service Support

The Oracle Communications Session Border Controller (SBC) supports emergency calls from roaming UEs over S8HR.

When S8HR roaming is used for VoLTE there is no IMS roaming NNI between the VPLMN and the HPLMN. It is, therefore, not possible to use standard methods to authenticate the UE in the IMS Domain. To support Emergency calls and meet regulatory requirements, the SBC supports multiple variations on S8HR emergency call support, including:

Emergency Registration
Emergency Re-Registration
Emergency De-Registration
Emergency Registration Based on Roaming Status
Emergency INVITE from Un-Registered User
Emergency INVITE after emergency registration

Supporting Emergency Registration

Basic Emergency Registration

When the SBC receives an initial un-secured REGISTER SIP message for an IMS emergency registration, it requests the the Evolved Packet Core (EPC)-level identities available for that IP-Connectivity Access Network (IP-CAN) session from the PCRF, including:

Mobile Station International Subscriber Directory Number (MSISDN)
International Mobile Subscriber Identity (IMSI)
International Mobile Equipment Identity IMEI and Software Version (SV)

To do so, the SBC initiates an Rx Diameter session with the PCRF using an AA-Request (AAR) command. The AAR includes three AVPs:

Framed-IP-Address (or Framed-IPV6-Prefix) AVP with value set to the IP in the REGISTER Contact header field.
AF-Requested-Data AVP with value set to “EPC-level identities required(0)”, indicating that the AF requests the PCRF to provide the EPC-level identities.
Service-URN AVP with value set to “sos”, indicating this is an emergency registration.

When the Service-URN AVP indicates that the AF session relates to emergency traffic and the AF-Requested-Data AVP indicates "EPC-level Identities required", the PCRF provides the requested identity information for the IPCAN session within the Subscription-Id AVP(s) and/or the IMEI(SV) within the User-Equipment-Info AVP in the AAA.

The PCRF provides the UE public identities in the AAA message. The SBC looks for the IMSI and/or the MSISDN in the Subscription-Id group AVPs, and IMEI in the User-Equipment-Info group AVPs:

Subscription-Id AVP
- MSISDN: value of Subscription-Id-Data with Subscription-Id-Type = END_USER_E164 (0)
- IMSI: value of Subscription-Id-Data with Subscription-Id-Type = END_USER_IMSI (1)
User-Equipment-Info AVP
- IMEI: value of User-Equipment-Info-Value with User-Equipment-Info-Type = IMEISV (0)

The SBC does not forward this REGISTER request. Instead, it stores and verifies the received IMSI or IMEI. If verification succeeds, it sends a 200 (OK) to the UE and the UE is successfully registered. The SBC keeps the entry in its registration cache and allows the associated contact address to use emergency service only.

If identity verification fails, the SBC sends a 403 (Forbidden) with configurable reason back to the UE. Successful registration is depicted below.

Note:

For the emergency roaming user, the SBC does not support the 420 response with sec-agree. This means the 1st un-secured REGISTER is handled with 200 or 403 response from SBC. There is no sec-agree or secured REGISTER involved. Refer to 3GPP TS 24.299 5.2.10.5 for more details.

Emergency re-Registration

When the SBC a re-registration from a S8HR roaming user, it refreshes its registration cache for this contact. It does not forward the REGISTER to the core. Instead, it sends a 200 (OK) response including the P-Associated-URI header filed containing the list of implicitly registered public user identities saved in its cache for this contact. There is no Rx exchange with PCRF triggered in this case.

However, when the UE re-registers with a different contact for the emergency registrations, the SBC deletes (expires) the original contact for the emergency registration and add the newly registered contact. The SBC the initiates an Rx exchange with the PCRF to retrieve EPC-level identities, like the initial registration.

Emergency de-Registration

Like a normal emergency contact, once the UE registers a public user identity and an associated contact address via emergency registration, it cannot de-register the associated user identity and contact address. The SBC removes the registration when it expires.

If the SBC receives a de-register from the S8HR roaming user for the emergency registration, SBC will NOT forward the deregister to the registrar. SBC will send response 200 (OK) to UE.

If it receives a de-register from the roaming user for the emergency registration, the SBC does not forward the de-register to the registrar. Instead, it searches for the registration in its cache. If it finds the registration, the SBC sends a 200 (OK) response to the UE and removes the registration entry from its cache.

Emergency Registrations Based on Roaming Status

The SBC IMEI/IMSI validation for Emergency registration from S8HR roaming user utilizes the epc-id-required parameter to determine its authentication behavior based on input from the REGISTER and the PCRF.

Using epc-id-required within the context of emergency registration feature for S8HR Roaming station, the SBC:

Provides the VPLMN identity to IMS entities in the HPLMN:
- During the registration, the S-CSCF and TAS need to be made aware about the ID of the visited PLMN e.g. for charging purposes and to enable the HPLMN to subsequently perform roaming registration restriction or communication barring supplementary services.
- To handle non UE detectable IMS emergency session establishment the P-CSCF needs to be aware of the MCC of the VPLMN from where the UE initiates IMS session. This information is needed at the P-CSCF at every IMS session establishment.
- The HPLMN IMS entities need to be aware of the ID of the visited PLMN at session set up in order to populate the charging records.
Supports the HPLMN, which must ensure that IMS layer signaling and media confidentiality protection is not activated in order to enable the VPLMN to meet the local regulatory requirements.
Supports the HPLMN, if it uses the IMS layer signaling and media confidentiality protection on its network (e.g. for the HPMN’s own subscribers, for inbound roaming LBO IMS subscribers). Based on the customer location and IMS Roaming agreement type, this protection may be deactivated in the HPMN.
Supports Emergency calls regulatory requirement when you are using S8HR roaming for VoLTE and there is no IMS roaming NNI between the VPLMN and the HPLMN. This would mean it is not possible to use existing methods to authenticate the UE in the IMS Domain.

An emergency REGISTER from an S8HR roaming user has following characteristics:

Contains an “sos” SIP URI parameter in the Contact header field (3GPP TS 24.299 describes the syntax)
Does not contain an Authorization header field
The Domain name retrieved from the Request-URI is different from the SBC local network (sip-interface, uri-fqdn-domain).

The SBC retrieves and caches the IMSI, and/or IMEI, and/or MSISDN from AAA message, and performs the following identity verification tasks:

If the IMSI derived from the public user identity in the TO header of the REGISTER is the same as the IMSI received from the PCRF, the SBC marks the IMSI verification as successful.
If the IMEI obtained from instance ID conveyed in the Contact header field of the REGISTER is the same as the IMEI received from the PCRF, the SBC marks the IMSI verification as successful.

The SBC performs this authentication dependent on your setting for the epc-id-required parameter. If you set the epc-id-required parameter to IMSI_STRICT, the SBC behaves as follows:

If the SBC receives both the IMSI and IMEI from the PCRF, it verifies both of them. If either of those verifications fail, the SBC rejects the REGISTER request by returning a 403 (Forbidden). Otherwise, it accepts the REGISTER request and sends a 200 (OK).
If the SBC receives the IMSI only from the PCRF, it verifies the IMSI. If the IMSI verification fails, the SBC rejects the REGISTER request by returning a 403 (Forbidden). Otherwise, it accepts the REGISTER request and sends a 200 (OK).
If the SBC receives the IMEI only from the PCRF, it rejects the REGISTER request by returning a 403 (Forbidden).
If the SBC does not receive both the IMEI and IMSI from the PCRF, it rejects the REGISTER request and sends a 403 (Forbidden) response.

Note:
Oracle recommends the IMSI_STRICT setting for environments that require an IMSI in the end user's device as a prerequisite to setting up an emergency call.

If you set the epc-id-required parameter to IMSI_LOOSELY, the SBC behaves as follows:

If the SBC receives both the IMSI and IMEI from the PCRF, it verifies both the IMSI and the IMEI. If either verification fails, the SBC rejects the REGISTER request and sends a 403 (Forbidden) response. Otherwise, it accepts the REGISTER request and sends a 200 (OK).
If the SBC receives only the IMSI from the PCRF, it verifies the IMSI. If the verification fails, the SBC rejects the REGISTER request and sends a 403 (Forbidden) response. Otherwise, it accepts the REGISTER request and sends a 200 (OK).
If the SBC receives only the IMEI from the PCRF, it verifies the IMEI. If the verification fails, the SBC rejects the REGISTER request and sends a 403 (Forbidden) response. Otherwise, it accepts the REGISTER request and sends a 200 (OK).
If the SBC does not receive both the IMSI and the IMEI, it rejects the REGISTER request and sends a 403 (Forbidden) response.

If you set the epc-id-required parameter to IMSI_AND_IMEI_LOOSELY, the SBC behaves as follows:

If the SBC receives both the IMSI and IMEI from the PCRF, it verifies both IMSI and IMEI. If either verification fails, the SBC rejects the REGISTER request and sends a 403 (Forbidden) response. Otherwise, it accepts the REGISTER request and sends a 200 (OK).
If the SBC receives only the IMSI from the PCRF, it verifies the IMSI. If the verification fails, the SBC rejects the REGISTER request and sends a 403 (Forbidden) response. Otherwise, it accepts the REGISTER request and sends a 200 (OK).
If the SBC receives only the IMEI from the PCRF, it verifies the IMEI. If the verification fails, the SBC rejects the REGISTER request and sends a 403 (Forbidden) response. Otherwise, it accepts the REGISTER request and sends a 200 (OK).
If the SBC does not receive both the IMSI and IMEI, it accepts the REGISTER request and sends a 200 (OK)

If you set the epc-id-required parameter to IMSI_OR_IMEI, which is the default, the SBC behaves as follows:

If the SBC receives both the IMSI and IMEI from the PCRF, it verifies both the IMSI and the IMEI. If either of the verifications succeed, it accepts the REGISTER request and sends a 200 (OK). Otherwise, it rejects the REGISTER request and sends a 403 (Forbidden).
If the SBC receives only the IMSI from the PCRF, it verifies the IMSI. If the verification fails, the SBC rejects the REGISTER request and sends a 403 (Forbidden) response. Otherwise, it accepts the REGISTER request and sends a 200 (OK).
If the SBC receives only the IMEI from the PCRF, it verifies the IMEI. If the verification fails, the SBC rejects the REGISTER request and sends a 403 (Forbidden) response. Otherwise, it accepts the REGISTER request and sends a 200 (OK).
If the SBC does not receive both the IMSI and IMEI, it rejects the REGISTER request and sends a 403 (Forbidden) response.

Note:

If there is no IMSI and/or IMEI in the TO or Contact header field of the REGISTER, the SBC marks the corresponding (IMSI and/or IMEI) validation as failed. It does this even if the PCRF returns corresponding (IMSI and/or IMEI) values. The SBC behavior is based on the epc-id-required setting in the applicable s8hr-profile.

When identity verification for a roaming user succeeds, the SBC begins to prepare the 200 (OK) response to UE. It uses the MSISDN to generate the following URIs:

A SIP URI with user=phone for the MSISDN—This is the default public user identity and becomes the first URI in the list of public user identities.
A tel URI from the MSISDN

The SBC uses these URIs in the P-Associated-URI header fields, so the response contains the list of implicitly registered public user identities bound to the contact.

Note:

If MSISDN is not received from PCRF, SBC will generate a temporary public user identity from the received IMSI. This temporary public user id is used as MSISDN to create URIs described above.

When identity verification for a roaming user fails, the SBC begins to prepare the 403 (Forbidden) response to UE. The 403 (Forbidden) includes:

A Content-Disposition header field with a disposition type “render” value and a “handling” header filed parameter with an “optional” value.
Content-Type header field with the value set to associated MIME type of the 3GPP IM CN subsystem XML body. This is the same XML as when the SBC responds with a 380.
A P-Asserted-Identity header field set to the value of the SBC SIP URI.
3GPP IM CN subsystem XML body containing an <ims-3gpp> element with the "version" attribute set to "1" and with an <alternative-service> child element, set to the parameters of the alternative service:
- A <type> child element, set to "emergency" to indicate that it was an emergency call
- A <reason> child element, set to a configurable reason you set with the emergency-reject-reason in the applicable s8hr-profile
- An <action> child element, set to "anonymous-emergencycall"

Note:

The existing registration-interval configuration on the sip-interface specifies the maximum expires allowed for the registration.

Configure the Registration Behavior

The syntax for configuring the epc-id-required parameter to the IMSI_OR_IMEI value is:

ORACLE(s8hr-profile)# epc-id-required IMSI_OR_IMEI

Emergency INVITEs

Emergency INVITE from an Un-Registered User

If the SBC receives an emergency INVITE from an un-registered roaming user, it initiates an Rx exchange with the PCRF requesting EPC-level identities (MSISDN, IMEI, IMSI). This Rx message sequence is the same as for the Emergency REGISTER scenario.

The SBC compares the IMEI received from the PCRF with the one in the INVITE. If there is a match, it modifies the SIP INVITE to include the UE's public identities and then forwards it to the core. It sends the corresponding responses from core back to UE when it receives them.

Specifically, if the IMEI obtained from “+sip.instance” parameter conveyed in the Contact header field of INVITE is the same as the IMEI received from PCRF, the IMEI validation is successful. The SBC modifies the INVITE as following and forwards it to the core:

Remove any P-Preferred-Identity header field from the INVITE.
If the SBC retrieves an MSISDN, it inserts a P-Asserted-Identity header field set to “tel:<MSISDN>” in the INVITE.
If the SBC retrieves an IMSI, it inserts a P-Asserted-Identity header field set to a temporary public user identity derived in the INVITE.

If the IMEI verification fails, and you have configured the SBC to reject in this case, it replies to the UE with a 403 (forbidden).

Note:

If identity verification failed but the SBC is not configured to reject, it modifies the INVITE forwards it to the core similarly to the IMEI verification success case.

Emergency INVITE from a Registered User

The SBC determines the registration associated with the session initiator as well as the next possible route normally for a registered user that happens to be roaming. The emergency registration is valid for emergency sessions only.

Use of the AF-Requested-Data AVP to Obtain EPC Identity for Emergency Calls

You can configure the Oracle Communications Session Border Controller (SBC) to get EPC-level identities from the PCRF through the Rx interface. When triggered, the feature issues an AAR that includes the AF-Requested-Data AVP set to the value, EPC-level identities required, as described in TS 29.214, during emergency calls. Within this context, the SBC is the Application Function (AF). Target deployment scenarios include supporting emergency call for native, multi-SIM subscribers. These subscribers may use multiple terminals with the same IMS-level MSISDN, such as a smart phone and a wearable device, that are in different locations. You can use this feature to populate an emergency INVITE with the terminal identity retrieved by the EPC.

The SBC performs this procedure on the initial INVITE of an emergency call. Applicable caller status includes unregistered, emergency registered and non-emergency registered. All forms of emergency calls that are supported by the SBC, including SOS URN, MPs, NMC configuration, and RPH calls trigger this functionality.

This feature is disabled by default. Applicable configuration includes the following parameters on the ext-policy-server of the applicable access realm:

Enable the emergency-epc-level-identities parameter to enable the feature.
Enable the use-epc-level-msisdn parameter to specify that the SBC should insert an EPC-level MSISDN into the PAI of the egress INVITE. This parameter is only relevant if you have also enabled emergency-epc-level-identities.
Set the operator-config-local-mcc-mnc parameter to specify the MNC digit.

The PCRF can reply to the SBC with an AAA that includes either no identities, the IMSI identity, the MSISDN identity or both. It may also include the IMEI identity, but this is always ignored. The identities arrive within Subscription-Id AVPs objects, as specified in 3GPP TS 29.214. Having received the AAA, the SBC constructs the components of the INVITE as follows:

When building the IMSI identity, the egress INVITE has a P-Asserted-Id containing a temporary public user identity derived from the IMSI, as defined in 3GPP TS 23.003. The format is sip:<IMSI>@ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org. The SBC builds the MNC digit based on:
- If the IMSI is consistent with the currently configured operator-config-local-mcc-mnc, then it's a local subscriber and the SBC builds the host part of the PAI accordingly based solely on the Rx information.
- If the IMSI is not consistent, the user is a roaming subscriber. In this case, the SBC uses the PPI, or the PAI, or the from header host part, if it is in the format ims.mncXXX.mccXXX.3gppnetwork.org. The selection precedence is PPI, then PAI, then from header.
- If neither of the above, the SBC builds the PAI using the locally configured mnc/mcc values.
When building the MSISDN identity, if you have enabled use-epc-level-msisdn, the SBC uses it as the P-Asserted-Id in the tel-uri format.
When building both MSISDN and the IMSI identities, both are processed independently as per the guidelines above.
The IMEI identity is always ignored.

The basic sequence resulting in the retrieval includes the 6 steps shown in the call flow below.

The SBC modifies the INVITE as following and forwards it to the core.

If an MSISDN is retrieved, insert or replace a P-Asserted-Identity header field in the INVITE set to "tel:<MSISDN>". See RFC 3325 for header details and format.
If an IMSI is retrieved, insert/replace a P-Asserted-Identity header field in the INVITE set to a temporary public user identity derived from the IMSI. See 3GPP TS 23.003 for derivation and format details.

The SBC uses additional conditions for processing these EPC-level identities, depending on whether or not the user is registered. These conditions are presented in sections below.

Emergency Call Hand off

Emergency call handoffs may occur after the SBC has processed the initial INVITE. At this point, the SBC has already sent the initial AAR with the AF-Requested-Data with EPC-Level identities required. The SBC only requests the EPC identities once. As such, the SBC does not request these identities again during a handoff, making the assumption the identities do not change.

If you configure the applicable ext-policy-server on the interfaces for CS call leg, then the SBC sends the Rx AAR with the Rx-Request-Type AVP set to UPDATE_REQUEST. This INVITE is not the same as the initial INVITE, so the SBC never includes an AF-Requested-Data AVP in these AARs.

Related Feature Dependencies

Other SBC configuration can impact the operation of this feature including the following:

If you have enabled asynchronous-mode on the applicable ext-policy-server, the SBC does not wait for an AAA in response to an AAR. In this case, the AF-Requested-Data is not applicable because the SBC does not send the AF-Requested-Data AVP in the Rx AAR to the PCRF.
Refer to Asynchronous SIP-Diameter Communication for additional detail.
Keep in mind the inclusion of both SIP and TEL PAI types when you enable the add-second-pai-for-emergency-calls option in the sip-config.
All net-management-control configurations that trigger this feature require:
- The type parameter set to priority.
- The destination-identifier parameter set to urn:service:sos.
- The rph-feature parameter set to enabled.

EPC-Level ID Processing for Registered Users

The tables below show the results of the processing performed by the SBC to produce the applicable output. The first column shows what the SBC would send out if EPC identities were not retrieved. The top row shows the EPC identities the SBC receives in the AAR.