Page History

Introduction

The S8 Home Routing (S8HR) uses the LTE S8 interface for transporting VoLTE traffic between the visited and home network as data traffic. The S8HR does not require IMS in the visited LTE network. In S8HR roaming architecture model of VoLTE, the Packet Data Network Gateway (PGW), Policy Charging and Rules Function (PCRF), and Proxy Call Session Control Function (P-CSCF) are in the Home Public Land Mobile Network (HPLMN) when the UE is roaming in a Visited Public Land Mobile Network (VPLMN). The S8HR roaming architecture provides all the IMS services to the UEs roaming in the VPLMN. In this scenario, the UE does not require any IMS network to network interface (NNI) between the VPLMN and HPLMN. A roaming user receives all the services of the home network in the S8HR model. In S8HR roaming model, the IMS/SIP/RTP traffic is tunneled back to the HPLMN like data traffic. In this model, the P-CSCF is present in the home network for the roaming UEs. However, during an emergency call, the UE connects to the HPLMN instead of the VPLMN. The Public Safety Answering Point (PSAP) of the HPLMN is situated in a different geographic location than that of the roaming user. So, the roaming emergency call must be rejected or re-directed to the visiting network where UE has tried the emergency call. The 3GPP standards define specific error response to indicate UE that the emergency calls are to be handled in the VPLMN. When P-CSCF in the HPLMN detects that the R-URI in INVITE points to an emergency URI, the P-CSCF rejects the INVITE with 380 response. However, when the UE handles the reject response from the HPLMN's P-CSCF, it can either fallback to use Circuit Switch (CS) domain for emergency calls or connect to emergency APN/ emergency-PDN. In the IMS architecture, the registrations (including the emergency registrations) are handled by the S-CSCF through the P-CSCF (home or visited). However, in the case of inbound S8HR users, there is no NNI between the P-CSCF at the VPLMN and the S-CSCF at the HPLMN. Thus, the P-CSCF cannot forward the registration to the S-CSCF. The P-CSCF, in this case, acts as a registrar for the emergency registrations originated from the S8HR inbound roamer and route the emergency calls from such users to the PSAP.

The visited S8HR user is authenticated using the GPRS-IMS-Bundled Authentication (GIBA) procedure and handles the emergency call. The flags s8hrSupport and gibaSupportForS8hrInboundUser are added to the SIP Trunk Group to support the emergency call handling for S8HR model.

Retrieve Location Information from PCRF

The P-CSCF retrieves the user location information (PLMN ID) from the Policy and Charging Rules Function (PCRF) using the Rx interface. Once PLMN ID is retrieved, it is compared against the configured PLMN IDs (HPLMN/VPLMN ID profiles) in the SBC.

• If the retrieved PLMN ID is matched with any of the PLMN IDs configured in the HPLMN ID profile, the user is not S8HR outbound roaming user (can be Home, Ravel, or S8HR inbound roaming user). In this case, the PSX sends roaming type in the policy response.
• If the retrieved PLMN ID does not match with the PLMN IDs configured in the HPLMN ID profile and is matched with any of the PLMN IDs configured in VPLMN ID Profile, the user is an S8HR outbound roaming user.
• If the called number from the S8HR outbound user is matched with the emergency prefix of the corresponding VPLMN ID, the call is an S8HR emergency call and must be rejected with 380.

The P-CSCF queries the PCRF for PLMN ID when it receives a REGISTER request.

• The PCRF returns the PLMN ID in the Re-Auth-Request (RAR) message. The P-CSCF stores the PLMN ID in the Registration Control Block (RCB).
• The P-CSCF determines if the user is an S8HR outbound user or not, by comparing the received PLMN ID with that of the locally configured VPLMN and HPLMN IDs.
• The P-CSCF performs a PSX dip for the route information and forwards the REGISTER to the IMS core by adding P-Visited-Network-ID based on the PLMN ID.
• The IMS core challenges the user with 401 response, the UE sends the challenge REGISTER back to the P-CSCF and the regular registration procedure continues.
• The P-CSCF stores the registration status (Home/RAVEL/S8HR outbound roamer) of the UE in the RCB.
•  When the P-CSCF receives an INVITE from a registered S8HR outbound user, the P-CSCF identifies if the user is an S8HR outbound roamer using the RCB.
• The P-CSCF determines if it is an emergency call or not by looking into the emergency prefix of corresponding VPLMN ID.
• The P-CSCF sends the PLMN ID to the PSX if it is an emergency call.
• The PSX, based on the PLMN ID, sends the SOS service URN and the "Reject" reason for that VPLMN ID in the D+ response.

• The P-CSCF sends 380 response with the SOS URN in the contact header, and the XML body based on the reject reason sent by the PSX to the UE.

The normal call, from the S8HR outbound user, is processed using the existing procedure.

In S8HR model, the emergency calls are handled only at the VPLMN and thus, the emergency registration for an outbound roaming user is rejected by the home P-CSCF. The UE must register the emergency contact to the emergency APN in the visited network. The P-CSCF determines the PLMN ID from the MCC-MNC, derived from the RAR response and determine if the UE is roaming or not. If the user is roaming, the P-CSCF rejects the emergency registration. The P-CSCF rejects emergency registration when sos parameter is received in Contact header and the flag sosInContactOfRegister is enabled. The emergency call from the S8HR outbound user must be rejected with 380.

When the P-CSCF receives an INVITE from an unregistered user, the P-CSCF identifies if the UE is an S8HR outbound roamer by querying the PCRF.

• The P-CSCF determines if it is an emergency call or not by looking into the emergency prefix of corresponding VPLMN ID.
• The P-CSCF sends the PLMN ID   to the PSX if it is an emergency call.
• The PSX, based on the PLMN ID, sends the SOS service URN and the "Reject" reason for that VPLMN ID in the D+ response.
• The P-CSCF sends 380 response with the SOS URN in the contact header, and XML body based on the reject reason sent by the PSX to the UE.

GIBA Authentication

In the IMS architecture, the registrations (including the emergency registrations) are handled by the S-CSCF through the P-CSCF (home or visited). However, in the case of S8HR model, there is no NNI between the P-CSCF at the VPLMN and the S-CSCF at the HPLMN. Thus, the P-CSCF cannot forward the registration to the S-CSCF. The P-CSCF in this scenario acts as a registrar for the emergency registrations originated from the S8HR inbound roamer and also route emergency calls from such users to the PSAP.

The P-CSCF:

• Identifies the emergency registrations is from an S8HR inbound roamer or not.
• Authenticates the user through GIBA based authentication procedures through the PCRF.
• Acts as a registrar (process the REGISTER request locally, store UE information, and the other authentication information).
• Handles and route emergency calls to PSAP (through E-CSCF) from S8HR inbound roaming user (whether the UE is emergency-registered or not-registered).

Emergency Registration/Calls Rejected by the P-CSCF of the HPLMN

As the emergency calls/registrations are handled by the visited network, the home network rejects any emergency registrations/calls initiated by the S8HR outbound roamer. The P-CSCF rejects the emergency calls with 380 response with a 3GPP XML, which indicates the user whether it falls back to the CS or initiate emergency registration at the Visited network to make a successful emergency call.

Emergency Registration/Calls Accepted by the P-CSCF of the VPLMN

Once the S8HR outbound roamer receives a 380 response from the home network, the UE decides to initiate the emergency registrations with the visited network. Such emergency registration is handled locally by the visited P-CSCF without forwarding to IMS core. The P-CSCF, in this case, performs GIBA procedure to authenticate the UE emergency registrations with the help of PCRF. The P-CSCF accepts only emergency calls from such users and routes the emergency calls from these users as it does for a regular emergency call from its home user. If the emergency registration is rejected with 403 response or cannot perform emergency registration, the UE decides to directly make an unregistered emergency call.