Modified: for 12.1.1
In this section:
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.
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.
The P-CSCF queries the PCRF for PLMN ID when it receives a REGISTER request.
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.
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.
If the flag requiredRegistration
is enabled, all the calls including emergency calls, are rejected for the unregistered users.
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:
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.
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.
When emergencyCallHandlingMode
is set to rejectWith380
, the emergency calls from all the unregistered users are rejected with 380 response.
The SBC CNe supports relevant procedures on SIP and Diameter interfaces for routine and emergency calls as a Home P-CSCF and a Visiting P-CSCF.