This annex includes network impact and call flows for support of IMS emergency sessions for roaming users in deployments without IMS-level roaming interface between the P-CSCF in the VPLMN and the S-CSCF in the HPLMNs. This annex also applies to IMS emergency sessions for SNPN users when there is no support for IMS-level roaming, or the user has no IMS credentials. This annex is only applicable to UTRAN, E-UTRAN and NG-RAN access networks.
IMS authentication is performed by linking the IMS registration to user's EPS or 5GS authentication based on the user's IP address and IMSI. This mechanism is similar to GIBA (GPRS-IMS bundled authentication) specified in TS 33.203
. The P-CSCF performs the GIBA procedure over Gm with the UE as defined in TS 24.229
. If this procedure is not supported, UE may perform anonymous emergency session. A callback number for the user may also be retrieved via the PCRF or PCF.
The call flow for support of IMS emergency sessions for roaming users in deployments without IMS-level roaming interfaces for UTRAN, E-UTRAN or NG-RAN access networks is described in Figure K.3-1.
UE establishes a PDN connection (for EPC) or PDU session (for 5GC) for IMS emergency services.
For EPC, IMSI and IMEI(SV) are retrieved from the UE. The MSISDN (if available) is provided by the HSS.
For 5GC, the SUPI and PEI are retrieved from the UE context stored in the AMF; the SUPI needs to contain an IMSI for PLMN accesses, and may contain an IMSI or a network-specific identifier (NSI) that takes the form of an NAI for SNPN access. TS 23.003
specifies the IMPI and IMPI derivation for a NAI-based SUPI.
The PEI needs to contain an IMEI(SV). The GPSI (if available) is provided by the UDM; the GPSI needs to contain an MSISDN.
For EPC: MME/SGSN sends a Create Session Request towards the PGW including the IMSI, the IMEI(SV) and the MSISDN (if available) as specified in TS 23.401
For 5GS: AMF sends a Nsmf_PDUSession_CreateSMContextRequest
towards the SMF/UPF including the SUPI, the PEI and the GPSI (if available) as specified in TS 23.502
For EPC, PGW establishes an IP-CAN session with the PCRF as described in TS 23.401
and TS 23.203
. The IP-CAN session is identified with UE's IPv4 address of IPv6 prefix associated with the PDN connection for IMS emergency services. The IMSI, the IMEI(SV) and the MSISDN (if available) are passed to the PCRF as part of the IP-CAN session establishment.
For 5GC, SMF establishes an SM Policy Association with the PCF as described in TS 23.502
and TS 23.503
. The PDU session is identified with UE's IPv4 address or IPv6 prefix. The SUPI, PEI, GPSI (if available) and emergency DNN are passed to the PCF.
The Attach or UE requested PDN connection procedure (for EPC) or the PDU Session Establishment procedure (for 5GC) is being completed.
Steps 6-12 apply if the UE performs IMS Emergency Registration, based on conditions specified in clause 4.1
e.g. UE is aware that it has sufficient IMS authentication material.
UE initiates IMS emergency registration by sending a SIP REGISTER (UserID-1) message. The UserID-1 parameter is an IMPI and optionally an IMPU.
Upon reception of the SIP REGISTER message the P-CSCF determines that there is no IMS NNI to the user's HPLMN. The P-CSCF requests the PCRF or PCF for EPS-level identities (e.g. IMSI, IMEI(SV), MSISDN) in the Rx session establishment request. For 5GC, P-CSCF may use the Npcf_PolicyAuthorization
service as described in TS 23.502
and TS 23.503
instead of the Rx interface.
For EPC, the PCRF performs session binding based on the UE's IP address/prefix (as defined in clause 18.104.22.168 of TS 23.203
) and provides one or more EPS-level identities and the MSISDN (if available) to the P-CSCF.
For 5GC, the PCF performs session binding based on the UE's IP address/prefix (as defined in TS 23.503
). If the Rx interface is used, the PCF extracts IMSI, IMEI(SV), and if available MSISDN from SUPI, PEI, and GPSI, respectively and provides the former identities to the P-CSCF. If the Npcf_PolicyAuthorization
service is used, the PCF provides SUPI, PEI, and if available GPSI, and the P-CSCF extracts IMSI, IMEI(SV), and if available MSISDN from those identities.
Based on operator configuration and if the network supports the GIBA procedure over Gm as defined in TS 24.229
, the P-CSCF responds with a 420 response with sec-agree value listed in the unsupported header field. Otherwise it rejects the IMS registration request with SIP 403 (Forbidden) as defined in TS 24.229
. If the network supports anonymous IMS emergency sessions, P-CSCF may add an indication whether it supports anonymous IMS emergency sessions to the 403 or 420 response.
Steps 9-12 apply if the P-CSCF has responded with a 420 response in step 8 and if the UE supports GIBA procedure as part of emergency IMS registration (irrespective of whether indication of anonymous IMS emergency session support was included in step 8).
UE according to TS 24.229
, performs a new initial registration by sending a SIP REGISTER (UserID-2, IMEI) message and without inclusion of the Authorization header field. UserID-2 is a public user identity derived from SUPI (IMSI or NSI). P-CSCF may verify the IMSI/NSI/IMEI provided by the PCRF or PCF in step 7b against the IMSI/NSI/IMEI derived from the public user identity provided by the UE, prior to accepting the SIP REGISTER message.
P-CSCF accepts the registration with 200 OK and provides a tel-URI based on the MSISDN (if available) received from PCRF in step 7b to the UE. From the UE point of view, the procedure is the same as specified for GIBA (GPRS-IMS bundled authentication) procedures in TS 24.229
UE then attempts an IMS emergency session by sending a SIP INVITE (UserID-3) message. UserID-3 is set to UE's public identity (i.e. MSISDN as Tel-URI received in step 10).
The P-CSCF verifies whether the UserID-3 indicated in the SIP INVITE message complies with the tel-URI that was provided to the UE. If compliant, P-CSCF forwards the SIP INVITE towards the PSAP including a callback parameter (CallBackPar) in the form of TEL-URI derived from the MSISDN received in step 7. The procedure stops here.
Steps 13-15 apply if the UE attempts anonymous IMS emergency session, e.g. the P-CSCF has responded in step 8 with a 403 (Forbidden) response, or the P-CSCF has responded in step 8 with 420 response and the UE does not support GIBA as part of emergency IMS registration, or if the UE skipped IMS emergency registration:
The UE may attempt an unauthenticated IMS emergency session including an "anonymous user" parameter in the SIP INVITE message.
Upon reception of the SIP INVITE the P-CSCF either internally retrieves the one or more EPS-level identities and the MSISDN (if available) that were received in step 7b, or performs step 7 again.
The P-CSCF forwards the SIP INVITE (UserID-4, CallBackPar) towards the PSAP. UserID-4 is derived from one of the EPS-level identities received in step 7b. CallBackPar in the form of TEL-URI is derived from the MSISDN received in step 7b. The procedure stops here.
Step 16 applies if the UE attempts an emergency call in the CS domain as specified in clause 4.1
Subsequent to the IMS registration failure in step 8 or subsequent to an anonymous SIP INVITE attempt the UE may attempt an emergency call in the CS domain.
In addition to clause 7.1.2
, the following is applicable for this scenario:
It is recommended that local emergency call numbers are provided to the UE according to the procedures specified in TS 24.501, TS 24.301, TS 24.008 or Annex J.2. This helps to reduce the number of non-UE detected emergency numbers even for those PLMNs where only a subset of the local emergency numbers can be downloaded to the UEs.
When the UE registers in the IMS, the P-CSCF may retrieve the VPLMN-ID or SNPN ID of the UE as described in clause W.3 of TS 23.228 and may access a database to obtain a list of all local emergency numbers for the visited PLMN, if not already available in the P-CSCF. These numbers are used for detection of non UE detectable emergency calls during IMS session setup. The database of PLMN-/SNPN- specific emergency numbers and its interface with the P-CSCF are not specified by 3GPP.