S8HR Roaming Compatibility
The Oracle Communications Session Border Controller (OCSBC) 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 OCSBC 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 romaing 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 OCSBC performs this function at the HPLMN edge.
Interconnections between S8HR components are displayed below.
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 OCSBC 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 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 enabled
- 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-prioritycalls 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 (OCSBC) 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 (OCSBC) 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.
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.
Sec-Agree for S8HR Roaming Support
The Oracle Communications Session Border Controller (OCSBC) supports security agreement negotiation as described in RFC3329. For S8HR, the OCSBC 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 OCSBC enforces your configuration by offering NULL as the only encryption algorithm for trusted networks.
The OCSBC determines whether a network is trusted based on its VPLMN-ID. To determine this, the OCSBC queries the PCRF. The subsequent Rx exchange provides the VPLMN-ID. The OCSBC 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 OCSBC 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 OCSBC 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 OCSBC 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 (OCSBC) 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 OCSBC supports multiple variations on S8HR emergency call support, including:
- Emergency Registration
- Emergency Re-Registration
- Emergency De-Registration
- Emergency INVITE from Un-Registered User
- Emergency INVITE after emergency registration
Emergency Registration
When the OCSBC 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 OCSBC 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 OCSBC 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 OCSBC 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 OCSBC keeps the entry in its registration cache and allows the associated contact address to use emergency service only.
If identity verification fails, the OCSBC sends a 403 (Forbidden) with configurable reason back to the UE. Successful registration is depicted below.
Emergency re-Registration
When the OCSBC 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 OCSBC deletes (expires) the original contact for the emergency registration and add the newly registered contact. The OCSBC 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 OCSBC 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 OCSBC does not forward the de-register to the registrar. Instead, it searches for the registration in its cache. If it finds the registration, the OCSBC sends a 200 (OK) response to the UE and removes the registration entry from its cache.
Emergency INVITE from an Un-Registered User
If the OCSBC 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 OCSBC 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 OCSBC modifies the INVITE as following and forwards it to the core:
- Remove any P-Preferred-Identity header field from the INVITE.
- If the OCSBC retrieves an MSISDN, it inserts a P-Asserted-Identity header field set to “tel:<MSISDN>” in the INVITE.
- If the OCSBC 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 OCSBC to reject in this case, it replies to the UE with a 403 (forbidden).
Note:
If identity verification failed but the OCSBC 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 OCSBC 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.
Configuring an S8HR Profile
You configure an S8HR profile for serving roaming UEs with values that apply to your deployment.
Apply this S8HR profile to the appropriate sip-interface.
Applying an S8HR Profile to a SIP Interface
You configure the applicable sip interface to use the applicable S8HR profile to support this roaming on that interface.
Configuring a PLMN INFO Change Subscription
For S8HR opertions, you configure the Oracle Communications Session Border Controller (OCSBC) with a subscription to PLMN location changes with the PCRF. The external policy configuration provides for this subscription configuration.
Apply this policy server to the appropriate sip-interface.