1. Configuration Guide
  2. IMS Support
  3. S8HR Roaming Compatibility

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.
  • For some call flows, the SBC adds PLMN information into the PVNI header within 200 OKs. These flows include mobile terminating INVITE and MESSAGE sessions. Also included are flows wherein a Re-INVITE's 200 OK towards the core includes a PLMN change triggered by subscription.

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.

PLMN-ID Info Scenarios for MO SIP INVITE and MESSAGE Flows

In addition to REGISTRATION scenarios, the SBC can use the latest PVNI header with the latest PLMN information in the INVITE/REINVITE/MESSAGE sip request’s 200 OK response towards the core. This occurs after S8HR inter-PLMN handover. These scenarios include those that generate a 200 OK toward the core during SIP MO INVITE signaling.

For these call flows, the SBC adds the PVNI header with the latest PLMN information in the SBC cache in the outgoing SIP INVITE towards the access side and the 200 OK towards the core. These scenarios assume the same configuration requirements, including the sip-ims-feature enabled on the ingress sip-interface.

The SBC stores PLMN information obtained during the REGISTER for a user in its contact cache. In cases where the SBC does not receive new PLMN information, the SBC adds the original PLMN to a PVNI header for new INVITE/MESSAGE SIP requests.

When the SBC subscribes to PLMN_CHANGE notifications during the registration process, the PCRF sends a PLMN change notification in a RAR with new MCC and MNC information towards the SBC when an S8HR handover happens. Upon receiving the RAR, the SBC finds the contact and updates the cache with the new PLMN information. This allows the SBC to add new PLMN information in the PVNI header in any INVITE/MESSAGE as well as it's 200 OK towards the core.

PLMN-ID Info Insertion for a SIP INVITE Case

During calls, the S-CSCF needs to know the ID of the visited PLMNs for charging purposes. The P-CSCF (SBC) gets this information by subscribing to the PLMN Change via the PCRF. The image below shows a call flow that adds PVNI to Mobile Terminating INVITE session without any further PLMN change notification.

The SBC supporting PVNI insertion into the 200 OK toward the core during a SIP MO INVITE session.

Explanations for each step in the process include:

  1. After registration, the IMS core sends a SIP INVITE request to the registered contact (Mobile-Terminating) via the SBC.
  2. The INVITE arrives at the ingress sip-interface. Note the sip-ims-feature is enabled.
  3. The SBC locates the callee's contact information in its cache, from which it gets the PLMN information that was obtained during the Rx interaction with the PCRF during registration.
  4. After finding the PLMN information for that user, the SBC adds the PVNI header with that MCC and MNC information in the outgoing INVITE request towards the callee.
  5. The callee responds with a 200 OK. which reaches the SBC. (Note the extraneous 18x responses are not shown in the diagram.)
  6. The SBC finds the PLMN information again from the contact and adds PVNI header to 200 OK response towards the caller.
  7. The SBC relays the 200 OK to the IMS core.

PLMN-ID Info Insertion for a SIP MESSAGE Case

The next case includes the same behavior as the case above, implemented within a SIP MESSAGE session. The image below shows a call flow that adds PVNI to Mobile Terminating MESSAGE without any further PLMN change notification.

The SBC supporting PVNI insertion into the 200 OK toward the core during a SIP MO MESSAGE session.

Explanations for each step in the process include:

  1. After registration, the IMS core sends a SIP MESSAGE request to the registered contact (Mobile-Terminating) via the SBC.
  2. The MESSAGE arrives at the ingress sip-interface. Note the sip-ims-feature is enabled.
  3. The SBC locates the callee's contact information in its cache, from which it gets the PLMN information that was obtained during the Rx interaction with the PCRF during registration.
  4. After finding the PLMN information of that user, the SBC checks if either any active sip session available or the pcscf-cdr-compliance=PVNI-pref option within the accounting-config is enabled. If either of these are true, the SBC adds the MCC and MNC information to the PVNI header in the outgoing INVITE request towards the callee.
  5. The callee responds with a 200 OK, which reaches the SBC. (Note the extraneous 18x responses are not shown in the diagram.)
  6. The SBC finds the PLMN information again from the contact and adds PVNI header to 200 OK response towards the caller.
  7. The SBC relays the 200 OK to the IMS core.

If the SBC receives an INDICATION_OF_LOSS_OF_BEARER or an INDICATION_OF_RELEASE_OF_BEARER notification from the PCRF during or after the S8HR inter-PLMN handover for an ongoing S8HR call, the SBC terminates that call. Under these circumstances, the SBC cannot update any ensuing PVNI to the core.

Furthermore, if the IP/Port or realms of a UE changes after handover, there would not be any further SIP messages sent to the UE. Therefore, no updated PLMN information can be provided in the upcoming REINVTE/200 OK. In addition, the SBC would not be aware of the new IP/Port until the UE re-registers. This opens the possibility that the SBC might treat the new registration as a new contact, depending on your configuration.

PLMN-ID Info Insertion for an MT Re-INVITE Case

The next case includes the addition of PVNI to a Mobile Terminating INVITE and REINVITE with a PLMN change notification.

The SBC supporting PVNI insertion into a Re-INVITE toward the access during a SIP MT Call session.

Explanations for each step in the process include:

  1. After the REGISTER, the IMS core sends a SIP INVITE request to a registered contact (Mobile- Terminating) to the SBC.
  2. The MESSAGE arrives at the ingress sip-interface. Note the sip-ims-feature is enabled.
  3. The SBC locates the callee's contact information in its cache, from which it gets the PLMN information that was obtained during the Rx interaction with the PCRF during registration.
  4. After finding the PLMN information of that user, the SBC adds a PVNI header with that MCC and MNC information in the outgoing INVITE request towards the UE.
  5. The callee responds with a 200 OK, which reaches the SBC. (Note the extraneous 18x responses are not shown in the diagram.)
  6. The SBC does not add any PVNI header to the 200 OK response
  7. The SBC SBC relays the 200 OK to the IMS core.
  8. While the INVITE session is in-progress, there is a S8HR hand over. The SBC gets a PLMN change notification from the PCRF with new MCC-MNC in a RAR.
  9. The SBC responds with an RAA.
  10. Also the SBC find the contact cache and updates the cache with this new PLMN information.
  11. The IMS core sends a SIP RE-INVITE(MT) request for the active session.
  12. The SBC retrieves the contact information and determines the latest contact. This came from the PLMN information that was obtained during the RAR PLMN change notification just before this REINVITE.
  13. After finding the PLMN information of that user, the SBC adds a PVNI header with the latest MCC and MNC information in the outgoing INVITE request towards the UE.
  14. the UE responds with 200 OK which reaches the SBC. (Note the extraneous 18x responses are not shown in the diagram.)
  15. The SBC does not add any PVNI header to 200 OK response.
  16. The SBC relays the 200 OK to IMS core.

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Creating the PAI from Rx IMSI information for Emergency Calls

You can configure the SBC to build the host part of a P-Asserted-Identity header based solely on the EPC level IMSI information provided by the PCRF within Rx information, if required. This configuration applies to S8HR deployments when the system handles a local or roaming emergency call. The system performs this function regardless of whether the emergency call comes from an unregistered, emergency registered or a non-emergency registered endpoint. This feature establishes compliance with the applicable requirement within 3GPP 24.229.

When generating public user identity information by default, the SBC first tries to verify any public user identity information received from the PCRF by checking whether the IMSI is consistent with the currently configured operator-config-local-mccmnc. If so, the SBC recognizes the caller as being a local subscriber and builds the host part of the PAI based solely on the Rx information. If this is not true, however, the SBC proceeds with creating a PAI with public user identity using the PPI, or the PAI, or the FROM header host part from the incoming request. The system includes this PAI host in the applicable outgoing request.

If the information in the incoming INVITE includes EPC level IMSI that is not consistent with your configuration, and you need to comply with the applicable requirements within 3GPP 24.229, you can set the emergency-pai-host-from-rx option in the ext-policy-server configuration that points to the PCRF. When you set this option, the SBC builds the outgoing PAI header based only on information received from PCRF, ignoring locally configured and incoming INVITE data.

The syntax below shows how to set this option.

ORACLE(ext-policy-server)#options +emergency-pai-host-from-rx

Note:

If you type the option without the plus sign, you overwrite any previously configured options. To append the new option to the options list, prepend the new option with a plus sign as shown in the previous example.

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 as follows.

sip:<IMSI>@ims.mnc<MNC>.mcc<MCC>.example.com

When configured with this option, the SBC follows the steps below to build the MNC:

  1. If the IMSI from the PCRF is consistent with the currently configured operator-config-local-mccmnc, then it's a local subscriber and the SBC builds the host part of the PAI based solely on the Rx information.
  2. If the call is an emergency call and the SBC receives EPC level IMSI from the PCRF, then SBC builds the host part of the PAI based solely on the Rx information and regardless of user status (local or roaming).
  3. If the IMSI from the INVITE was not consistent and the SBC did not receive EPC level IMSI from the PCRF, 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.example.com. The selection precedence is PPI, then PAI, then FROM header.

    Note:

    When you set the emergency-pai-host-from-rx option, the system does not perform steps 3 and 4.
  4. If none of the above, the SBC builds the PAI using the locally configured mnc/mcc values.

Although the SBC replicates this configuration across an HA pair, it does not replicate the PAI headers. The feature works on current data received from the PCRF, which the SBC uses to create the PAI header for the INVITE. But the system does not synchronize this data with the standby.

MNC Digit Constraints

In addition to the configuring the SBC to use the PAI host from the Rx information, you need to consider whether you need the system to parse the IMSI for a 3 digit MNC instead of 2. This allows the system to build the PAI properly.

An IMSI presented by the PCRF may be 14 or 15 digits, depending on whether the MNC within is 2 digits (European standard) or 3 digits (American standard). The IMSI begins with the mobile country code (MCC), which is three digits, followed by the mobile network code. If your environment uses 3 digit MNC values, set this option so the SBC can parse the MNC properly.

To configure this behavior, set the emergency-pai-host-three-digit-mnc options in the same external policy server configuration for which you set the PAI from Rx option. The syntax below shows how to set this option. 

ORACLE(ext-policy-server)#options +emergency-pai-host-three-digit-mnc

If you do not set this option, the SBC parses and extracts only the applicable 2 digits as the MNC.

Applicable Call Flows

The call flows below depict the signaling when an emergency call comes from unregistered, emergency registered and non-emergency registered users. In all of these cases, the SBC, configured with this option, constructs the outgoing PAI header based on information received from PCRF and not from the local configured or incoming INVITE data.

The first call flow depicts an emergency INVITE received from an unregistered user:

  1. The SBC receives an emergency INVITE from an unregistered user.
  2. SBC sends the AAR towards the PCRF, including the AF-Requested-Data AVP.
  3. The PCRF sends the AAA with the IMSI in the Subscription-Id grouped AVP.
  4. SBC constructs the PAI header appropriately and sends the Emergency INVITE to the UAS.
This image depict emergency IMSI creation for an unregistered callee.

The second call flow depicts an emergency INVITE received from an registered user:

  1. The end user performs an emergency registration.
  2. The SBC receives an emergency INVITE from this newly registered user.
  3. SBC sends the AAR towards the PCRF, including the AF-Requested-Data AVP.
  4. The PCRF sends the AAA with the IMSI in the Subscription-Id grouped AVP.
  5. SBC constructs the PAI header appropriately and sends the Emergency INVITE to the UAS.
This image depicts emergency IMSI Creation for a registered callee.

The third call flow depicts an emergency INVITE received from an registered user that is currently roaming:

  1. The end user performs an emergency registration.
  2. The SBC receives an emergency INVITE from this registered, roaming user.
  3. SBC sends the AAR towards the PCRF, including the AF-Requested-Data AVP.
  4. The PCRF sends the AAA with the IMSI in the Subscription-Id grouped AVP.
  5. SBC constructs the PAI header appropriately and sends the Emergency INVITE to the UAS.
This image depicts emergency IMSI creation for a registered, roaming callee.

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 from the PCRF 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.
    • The SBC includes an additional behavior, based on configuration. If the call is an emergency call and the SBC receives epc level IMSI from the PCRF, the SBC builds the host part of the PAI based solely on the received Rx information, regardless of user status (local or roaming).

      See "Creating the PAI from Rx IMSI information for Emergency Calls" for configuration and detailed behavior.

    • If the IMSI from the INVITE was not consistent and the SBC did not receive EPC level IMSI from the PCRF, 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 none 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.

Assume the SBC configuration list is activated:

  • emergency-epc-level-identities configured
  • use-epc-level-msisdn not configured
  • 2nd PAI Option (add-second-pai-for-emergency-calls) disabled
Outgoing INVITE Only IMSI Received Only MSISDN Received IMSI and MSISDN Received
Only SIP PAI Replace SIP PAI with IMSI PAI SIP PAI as is Replace SIP PAI with IMSI PAI
Only Tel PAI Tel PAI as is Tel PAI as is Tel PAI as is
None Add IMSI PAI No Change Add IMSI PAI

Assume the SBC configuration list is activated:

  • emergency-epc-level-identities configured.
  • use-epc-level-msisdn not configured.
  • Second PAI Option (add-second-pai-for-emergency-calls) enabled.
Outgoing INVITE Only IMSI Received Only MSISDN Received IMSI and MSISDN Received
Only SIP PAI Replace SIP PAI with IMSI PAI SIP PAI as is Replace SIP PAI with IMSI PAI
Only Tel PAI Add IMSI PAI

Tel PAI as is

Tel PAI as is Add IMSI PAI

Tel PAI as is

SIP PAI and Tel PAI Replace SIP PAI with IMSI PAI

Tel PAI as is

SIP and TEL PAIs as are Replace SIP PAI with IMSI PAI

Tel PAI as is

None Add IMSI PAI No Change Add IMSI PAI

Assume the SBC configuration list is activated:

  • emergency-epc-level-identities configured.
  • use-epc-level-msisdn configured.
  • 2nd PAI Option (add-second-pai-for-emergency-calls) disabled
Outgoing INVITE Only IMSI Received Only MSISDN Received IMSI and MSISDN Received
Only SIP PAI Replace SIP PAI with IMSI PAI SIP PAI as is Replace SIP PAI with IMSI PAI
Only Tel PAI Tel PAI as is Replace Tel PAI with MSISDN PAI Replace Tel PAI with MSISDN PAI
None Add IMSI PAI Add MSISDN PAI Add IMSI PAI

Assume the SBC configuration list is activated:

  • emergency-epc-level-identities configured.
  • use-epc-level-msisdn configured.
  • 2nd PAI Option (add-second-pai-for-emergency-calls) enabled.
Outgoing INVITE Only IMSI Received Only MSISDN Received IMSI and MSISDN Received
Only SIP PAI Replace SIP PAI with IMSI PAI SIP PAI as is.

Add MSISDN PAI

Replace SIP PAI with IMSI PAI

Add MSISDN PAI

Only Tel PAI Add IMSI PAI

Tel PAI as is

Replace Tel PAI with MSISDN PAI Replace SIP PAI with IMSI PAI

Add IMSI PAI

SIP PAI and Tel PAI Replace SIP PAI with IMSI PAI

Tel PAI as is

SIP PAI as is.

Replace Tel PAI with MSISDN PAI

Replace SIP PAI with IMSI PAI

Replace Tel PAI with MSISDN PAI

None Add IMSI PAI Add MSISDN PAI Add IMSI PAI

Add MSISDN PAI

EPC-Level ID Processing for Unregistered Users

Some networks support IMS services for roaming users in deployments without IMS-level roaming interfaces. This section details EPC-level processing for these unregistered users.

The tables below specifies the results of the processing performed by the SBC to produce the applicable output. The first column shows what is received in the original INVITE. The top row shows the EPC identities the SBC receives in the AAR.

Assume the SBC configuration list is activated:

  • emergency-epc-level-identities configured.
  • use-epc-level-msisdn NOT configured.
  • Second PAI Option (add-second-pai-for-emergency-calls) enabled.
Only IMSI Only MSISDN IMSI and MSISDN None
Add IMSI as SIP PAI None Add IMSI as SIP PAI Remove PPIs from incoming INVITE and forward to core

Assume the SBC configuration list is activated:

  • emergency-epc-level-identities configured.
  • use-epc-level-msisdn NOT configured.
  • 2nd PAI Option (add-second-pai-for-emergency-calls) disabled.
Only IMSI Only MSISDN IMSI and MSISDN None
Add IMSI as SIP PAI None Add IMSI as SIP PAI Remove PPIs from incoming INVITE and forward to core

Assume the SBC configuration list is activated:

  • emergency-epc-level-identities configured.
  • use-epc-level-msisdn configured.
  • 2nd PAI Option (add-second-pai-for-emergency-calls) disabled
Only IMSI Only MSISDN IMSI and MSISDN None
Add IMSI as SIP PAI Add MSISDN as TEL PAI Add IMSI as SIP PAI Remove PPIs from incoming INVITE and forward to core

Assume the SBC configuration list is activated:

  • emergency-epc-level-identities configured.
  • use-epc-level-msisdn configured.
  • 2nd PAI Option (add-second-pai-for-emergency-calls) enabled.
Only IMSI Only MSISDN IMSI and MSISDN None
Add IMSI as SIP PAI Add MSISDN as TEL PAI Add IMSI as SIP PAI ADD MSISDN as TEL PAI Remove PPIs from incoming INVITE and forward to core

Per TS 24.229 section 5.2.10.2 point number 5, the SBC attempts to get EPC-level identities. The SBC must also strip any PPI. If it receives an MSISDN, the SBC inserts P-Asserted-Identity header field in the request set to a tel-URI carrying the MSISDN. If it receives an IMSI, the SBC inserts a P-Asserted-Identity header field in the request set to a temporary public user identity derived from the IMSI, as defined in 3GPP TS 23.003.

If the SBC receives no subscription-Id AVP, then it forwards the call by removing the P-Preferred-Identity header field, and keeps any PAIs as is. If it receives no AAA, the SBC behaves as if the emergency-epc-level-identities and use-epc-level-msisdn are not enabled.

Configuring AF-Requested EPC Identities

You enable the following parameters to enable specific components of Configuring AF-Requested EPC Identities. Refer to related configuration information to ensure you have considered and are implementing complementary or conflicting configuration properly for your deployment.

Use the following procedure to configure AF-Requested EPC Identities support.

  1. Navigate to the ext-policy-server configuration element. 
    ACMEPACKET# configure terminal
ACMEPACKET(configure)# media-manager
ACMEPACKET(media-manager)# ext-policy-server
  2. Enable the emergency-epc-level-identities parameter. 
    
ACMEPACKET(ext-policy-server)#emergency-epc-level-identities enable
  3. Enable the use-epc-level-msisdn parameter. 
    
ACMEPACKET(ext-policy-server)#use-epc-level-msisdn enable
  4. If the default is not acceptable, specify the MNC value and number of digits to use when creating the outgoing PAI using the operator-config-local-mcc-mnc parameter. 
    
ACMEPACKET(ext-policy-server)#operator-config-local-mcc-mnc 23232
  5. If applicable to your deployment, enable the emergency-pai-host-from-rx option. 
    
ACMEPACKET(sip-config)#option +emergency-pai-host-from-rx
  6. If applicable to your deployment, enable the emergency-pai-host-three-digit-mnc option. 
    
ACMEPACKET(sip-config)#option +emergency-pai-host-three-digit-mnc
  7. Use done, exit, exit to save the configuration.
  8. Navigate to the sip-config configuration element. 
    ACMEPACKET# session-router
ACMEPACKET(configure)# sip-config
  9. If applicable to your deployment, enable the add-second-pai-for-emergency-calls option. 
    
ACMEPACKET(sip-config)#option +add-second-pai-for-emergency-calls
  10. Use done, exit, and verify-config to complete configuration.
    This configuration supports real-time configuration, and therefore does not require a reboot.

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:
  1. 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.

  2. Use the name parameter to create a reference name for this profile and press Enter. 
    ORACLE(s8hr-profile)# name s8hr1
  3. 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
  4. 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
  5. 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
  6. Type emergency-reject-reason, and enter a reason to explain why an emergency session is rejected. 
    emergency-reject-reason “IMEI cannot be verified”
  7. Type local-mccmnc, and enter the local MNC where the SBC resides. This value should be a 2 or 3-digit integer. 
    ORACLE(s8hr-profile)# local-mccmnc 22
  8. Type epc-id-required, and enter the epc operational mode for emergency roaming service. Values include:
    • IMEI_OR_IMSI (Default)
    • IMSI_AND_IMEI_LOOSELY
    • IMSI_LOOSELY
    • IMSI_STRICT
    ORACLE(s8hr-profile)# epc-id-required IMSI_OR_IMEI
  9. 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:
  1. 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
  2. Select the access side of the sip interface, use select: 
    ORACLE(sip-interface)# select
  3. Set the s8hr-profile parameter to the applicable profile's name parameter. 
    ORACLE(sip-interface)# s8hr-profile s8hr1
  4. Type done to save the work.

Configuring a PLMN INFO Change Subscription

For S8HR operations, you configure the Oracle Communications Session Border Controller (SBC) 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:
  1. Access the ext-policy-server configuration element. 
    ORACLE # 
configure terminal 
ORACLE(configure)# media-manager 
ORACLE(media-manager)# ext-policy-server 
ORACLE(ext-policy-server)#
  2. To select the applicable external policy server, use select: 
    ORACLE(ext-policy-server)# select
  3. Configure the specific-action-subscription parameter with the plmn-change value. 
    ORACLE(ext-policy-server)# specific-action-sig-flow-subscription plmn-change
  4. Type done to save the work.

Apply this policy server to the appropriate sip-interface.