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.

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 OCSBC 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 OCSBCOCSBC 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 OCSBC.
- When Sec-Agree (IMS-AKA) and S8HR are both enabled, the OCSBC 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 OCSBC 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 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.

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 OCSBC 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 OCSBC does not receive or have any PLMN-ID information prior to the hold time expiry. The OCSBC proceeds, however, using default PLMN information you configure on the access side of sip interface (session-router, sip-interface, network-id. The OCSBC 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 OCSBC proceeds with the Rx exchange. In addition, the OCSBC renews its subscription to PLMN information changes. Furthermore, the OCSBC sends out the REGISTER with both PVNI (for S8HR) and PNNI (for NPLI) headers.
PLMN-ID Info de-registration Case—The OCSBC 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 OCSBC 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 (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.

Note:

For the emergency roaming user, the OCSBC does not support the 420 response with sec-agree. This means the 1st un-secured REGISTER is handled with 200 or 403 response from OCSBC. 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 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.

To configure an S8HR profile:

In Superuser mode, use the following command sequence to access s8hr profile configuration:
```
ORACLE# configuration terminal
ORACLE(configure)# session-router
ORACLE(session-router)# s8hr-profile
```
If you are configuring a pre-existing profile, use select to choose the profile you want to edit.
Use the name parameter to create a reference name for this profile and press Enter.
```
ORACLE(s8hr-profile)# name s8hr1
```
Type register-hold-for-plmn-info, and enter the length of time to hold REGISTERs while waiting for PLMN information. The valid value range from 0-30 seconds. The default of zero disables the parameter.
```
ORACLE(s8hr-profile)# register-hold-for-plmn-info 10
```
Type plmn-id-prefix, and enter the prefix string the system uses for P-Visited-Network-ID headers associated with this profile.
```
ORACLE(s8hr-profile)# plmn-id-prefix s8hr
```
Type emergency-reject-on-ident-error, then type enabled or disabled. If this flag is enabled, the SBC rejects any emergency session for which user identity validation fails.
```
ORACLE(s8hr-profile)# emergency-reject-on-ident-error enabled
```
Type emergency-403-reason, and enter a reason to explain why an emergency session is rejected.
```
emergency-403-reason “IMEI cannot be verified”
```
Type local-mnc, and enter the local MNC where the OCSBC resides. This value should be a 2 or 3-digit integer.
```
ORACLE(s8hr-profile)# local-mnc 22
```
Type local-mcc, and enter the local MCC where the OCSBC resides. This value should be a 3-digit integer.
```
ORACLE(s8hr-profile)# local-mcc 555
```
Type encrypt-disabled-mnc-mcc, and enter a list of networks for which the system must disable encryption when using this profile.
```
ORACLE(s8hr-profile)# encrypt-disabled-mnc-mcc 033444 456789 *
```
To disable encryption for all roaming networks, enter an asterisk (*).

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.

To apply an S8HR profile:

In Superuser mode, use the following command sequence to access existing sip interface configuration element:
```
ORACLE# configuration terminal 
ORACLE(configure)# session-router 
ORACLE(session-router)# sip-interface
```
Select the access side of the sip interface, use select:
```
ORACLE(sip-interface)# select
```
Set the s8hr-profile parameter to the applicable profile's name parameter.
```
ORACLE(sip-interface)# s8hr-profile s8hr1
```
Type done to save the work.

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.

To configure a subscription to PLMN location changes:

Access the ext-policy-server configuration element.

ORACLE # 
configure terminal 
ORACLE(configure)# media-manager 
ORACLE(media-manager)# ext-policy-server 
ORACLE(ext-policy-server)#

To select the applicable external policy server, use select:
```
ORACLE(ext-policy-server)# select
```
Configure the specific-action-subscription parameter with the plmn-change value.
```
ORACLE(ext-policy-server)# specific-action-subscription “plmn-change”
```
Type done to save the work.

Apply this policy server to the appropriate sip-interface.