Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.167  Word version:  16.3.0

Top   Top   Up   Prev   Next
1…   4…   5…   7…   7.5…   7.7…   C…   E…   I…   K…   L…

 

K (Normative)  Support of IMS emergency sessions for roaming users in deployments without IMS-level roaming interfaces |R14|Word‑p. 57

K.1  General

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 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.
Up

K.2  Functional description

K.2.1  General

This clause lists the additional functionality in the network that is required to support IMS emergency sessions for roaming users in network deployments where there are no IMS-level roaming interfaces between the serving IMS network and the home IMS network.

K.2.2  P-CSCF

In addition to the functionality described in clause 6.2.1, the P-CSCF supports the functionality listed below:
  • P-CSCF shall be able to retrieve the UE/user's IMSI, IMEI and MSISDN (if available) from the PCRF/PCF.
  • P-CSCF may support the GIBA procedure over Gm as defined in TS 24.229.
  • P-CSCF may verify the IMSI/IMEI provided in the SIP REGISTER message against the IMSI/IMEI provided by the PCRF or PCF.
Up

K.2.3  PCRF or PCF

 
  • PCRF or PCF shall be able to provide the IMSI, the ME Identity (IMEISV), and MSISDN (if available) over Rx to the P-CSCF.

K.2.4  PGW or SMF/UPF

 
  • PGW or SMF/UPF shall be able to prevent "source IP address spoofing" for IMS emergency PDN connections if GIBA authentication, defined in TS 33.203, is used as part of emergency IMS registration.

K.2.5  HSS or UDMWord‑p. 58
 
  • The EPS user subscription at the HSS should contain exactly one MSISDN which should be the same as that in the IMS profile.
  • The 5GS user subscription at the UDM should contain exactly one MSISDN based GPSI which should be the same as that in the IMS profile.

K.3  IMS Emergency Registration and Session Establishment

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.
(not reproduced yet)
Figure K.3-1: IMS Emergency Session Establishment in deployments without IMS roaming interface between VPLMN and HPLMN
Up
Step 1.
UE establishes a PDN connection (for EPC) or PDU session (for 5GC) for IMS emergency services.
Step 2.
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 and the PEI needs to contain an IMEI(SV). The GPSI (if available) is provided by the UDM; the GPSI needs to contain an MSISDN.
Step 3.
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.
Step 4.
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.
Step 5.
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.
Step 6.
UE initiates IMS emergency registration by sending a SIP REGISTER (UserID-1) message. The UserID-1 parameter is an IMPI and optionally an IMPU.
Step 7a.
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.
Step 7b.
For EPC, the PCRF performs session binding based on the UE's IP address/prefix (as defined in TS 23.203, clause 6.1.1.2) 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.
Step 8.
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).
Step 9.
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 an a public user identity derived from IMSI. P-CSCF may verify the IMSI/IMEI provided by the PCRF or PCF in step 7b against the IMSI/IMEI derived from the public user identity provided by the UE, prior to accepting the SIP REGISTER message.
Step 10.
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.
Step 11.
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).
Step 12.
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:
Step 13.
The UE may attempt an unauthenticated IMS emergency session including an "anonymous user" parameter in the SIP INVITE message.
Step 14.
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.
Step 15.
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:
Step 16.
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.
Up

K.4  Non UE detectable Emergency SessionWord‑p. 60
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 of the UE as described in TS 23.228, clause W.3 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- specific emergency numbers and its interface with the P-CSCF are not specified by 3GPP.
Up


Up   Top   ToC