4 High level Principles

23.1673GPPIP Multimedia Subsystem (IMS) emergency sessionsRelease 17TS

4.1 Architectural Principles

The solution for emergency sessions in the IMS fulfils the emergency principles and requirements of TS 22.101 [8], TS 22.228 [27] and the following architectural requirements:

1. Void.

2. Emergency services are independent from the IP-CAN with respect to the detection and routing of emergency sessions. The emergency services shall be possible over at least a cellular access network (terrestrial or satellite), a fixed broadband access, a nomadic access and a WLAN access to EPC or non-3GPP access to 5GC.

2a. Emergency numbers and associated types or URN information received via WLAN (for access to EPC) are only used for detecting emergency calls in the same country, if permission from PLMN selected in 3GPP access was received (see TS 23.401 [28] and TS 23.060 [2] for EPC access).

NOTE 1: Some features described in this clause do not apply for emergency session set-up over WLAN access to EPC or to 5GC. The limitations are documented in Annex J and Annex L.

2b. Emergency numbers and associated types received using a list as described in TS 24.008 [13] are only used for detecting emergency calls in the same country. The UE can obtain these numbers and associated types via mobility management procedures as described in TS 24.008 [13], TS 24.301 [33] and TS 24.501 [52]. The associated types consist of a limited number of emergency service categories from which a limited number of URNs can be derived.

2c. Emergency numbers and associated URN information received using a list as described in TS 24.301 [33] are only used when they are valid. The validity of these numbers and associated URN information is specified in clause 10.4.1 of TS 22.101 [8] (i.e. the serving network indicates whether this list is valid in the country or only in the PLMN or SNPN). The UE can obtain these numbers and associated URN information via mobility management procedures as described in TS 24.301 [33] and TS 24.501 [52].

3. Any kind of emergency numbers, and emergency SIP and TEL‑URIs as specified in TS 22.101 [8], and special indications for emergency sessions within the SIP signalling shall be supported. The URIs allowed to resolve to emergency services may be subject to local regulation in the serving network.

4. Emergency sessions should be prioritized over non-emergency sessions by the system.

5. The establishment of IMS emergency sessions shall be possible for users with a barred public user identity.

6. The primary solution shall be that the UE can detect an emergency session (e.g. by evaluating the SIP-URI or the dialled number) by itself and indicates the emergency session to the network. The cases where the UE can’t detect an emergency session shall also be supported.

7. The solution shall work if the UE has sufficient credentials to authenticate with the IMS and is registered to the IMS or is not registered with the IMS. The case where the UE does not have sufficient credentials to authenticate with the IMS shall also be supported if required by local regulation.

In the case that UE is not already IMS registered, it shall perform a registration for the support of emergency services (emergency registration).

In the case a UE is already IMS registered, the UE may skip the additional emergency registration if the UE is aware that it is in its home network (e.g. including IP-CANs where roaming outside the home network is not supported).

If the UE does not have sufficient credentials to authenticate with the IMS it shall be possible to perform session establishment without an existing security association between UE and P‑CSCF, and the UE shall include an equipment identifier (the specific details of the equipment identifier to use may depend upon the IP-CAN) in the request to establish an emergency session.

Subject to local regulation or operator policy, the network and the UE shall support the same authentication and security methods for an emergency service request as for non-emergency requests.

8. It shall be possible to reject emergency service requests from an UE, without sufficient credentials to authenticate with the IMS in networks where emergency services from UEs with sufficient credentials to authenticate with the IMS are required.

9. Emergency Service is not a subscription service.

9a. When the UE has roamed out of its home network, emergency services shall not be provided by the home network and shall be provided in the roamed-to network if the roamed-to network supports emergency sessions. If a UE has sufficient credentials, it shall initiate an emergency registration with the network (requiring the involvement of the home network). The CSCFs providing service for emergency sessions may be different from the CSCFs involved in the other IMS services. If the registration fails and if the serving IMS has indicated support for anonymous IMS emergency sessions as part of the IMS registration failure, the UE shall attempt an anonymous emergency session. If the IMS registration fails and if the serving IMS has not indicated support for anonymous IMS emergency sessions as part of the IMS registration failure, the UE may attempt an anonymous IMS emergency session.

NOTE 2: UEs compliant with pre-Rel‑14 versions of this specification are unable to interpret this indication and ignore the indication. Such UEs might attempt an anonymous IMS emergency session or proceed according to Annex H.5.

10. If an emergency session establishment request is routed to a P‑CSCF located in the home network, the home network should be able to detect that the session is for emergency service (whether indicated as such or not) and respond to the UE indicating that the UE should initiate an emergency session in the visited network (e.g. via the CS domain of the visited network).

11. Emergency centres and PSAPs may be connected to the PSTN, CS domain, PS domain or any other packet network.

12. The architecture shall enable emergency centres and PSAPs to request a PSAP call back to a UE with which the Emergency centres or PSAPs had an emergency session. The serving network of the UE shall use the appropriate call termination procedures e.g. IMS if the UE is available for voice over PS, or ICS if the user is available over CS. PSAP call back is subject to local regulation.

NOTE 3: PSAP call back sessions are treated as normal calls.

NOTE 4: Subject to local regulation, any supported media can be used during a call back attempt from a PSAP.

13. The IMS core network shall be able to transport information on the location of the subscriber.

14. Void.

15. The network shall be able to retrieve the caller’s location;

16. As a regional option, the network shall be capable of assigning a routable location key (i.e. Emergency Services Query Key, a.k.a. ESQK, which has the same properties as the existing ESRK in wireless 911 services) to an IMS emergency session, and releasing the ESQK when the emergency session is terminated.

17. The network shall provide the caller’s location information to the PSAP upon query from the PSAP.

18. The network shall provide the possibility to route to a default answering point given the scenario where the local PSAP can not be determined.

19. The network may provide a capability to enable a UE to obtain local emergency numbers.

20 A UE should support a capability to obtain local emergency numbers from the network once such a capability has been defined and agreed.

21. The network (e.g. in the E‑CSCF) shall prevent the sending of the information of the users, such as public user identifiers and the location information, to the PSAP if explicitly requested by the user (i.e. request on session by session basis), and local regulation requires the operator to provide privacy to the user.

22. Void.

NOTE 5: TS 24.008 [13] contains a procedure to provide local emergency numbers for UMTS and GPRS access but the procedure is not applicable to cdma2000 HRPD and contains a limited number of emergency service categories.

23. Void.

24. Subject to operator policy, the architecture shall allow an emergency session to be initiated by a trusted AS on behalf of a user that is not roaming.

25 Subject to local regulation, for non-roaming subscribers the network shall apply normal routing procedures for private network traffic even if that is marked as emergency session.

26. When a call is established with a PSAP that supports voice only, voice media is supported and GTT if required by local regulation or operator policy.

27. When a call is established with a PSAP that supports voice and other media, voice, GTT and other media according to TS 22.101 [8] (e.g. video, session mode text-based instant messaging) can be used during an IMS emergency session if required by local regulation. This media may be used in addition to or instead of voice and/or GTT.

28. NG-eCall is a variant of IMS emergency services and follows the same principles, architecture, and procedures as other emergency services over IMS.

29. An originating network that is processing an emergency session shall, if configured through operator policies, invoke an AS for the signing of attestation and identity information and Resource-Priority information, if available in the incoming request. The originating network shall include the signed information in the outgoing emergency request.

30. A network serving a UE receiving a PSAP call back shall, if configured through operator policies, invoke an AS for the verification of signed caller identity information, and Resource-Priority information, if available in the incoming request.

In addition to the architectural requirements, the following architectural principles apply to IMS emergency sessions:

– The IMS network shall be able to discriminate between emergency sessions and other sessions. This shall allow special treatment (e.g. with respect to filtering, higher priority, routing, QoS, supplementary services interactions) of emergency sessions.

– If a visited network can support PS emergency service, the emergency session shall be established in the visited network whether or not UE is registered in IMS in the home network.

– When a UE using public network traffic initiates an emergency session, the P‑CSCF is the IMS network entity, which is responsible to detect the request for emergency session. The P-CSCF then forwards the request to E‑CSCF in the same network, unless authentication and security procedures (see principle #7) require the request to be forwarded to the S-CSCF in the same network.

NOTE 6: While in the home network, forwarding of an emergency session to the S-CSCF is only expected over a non-emergency registration.

– The P‑CSCF serving the emergency call is the IMS network entity which may retrieve the location identifier from the IP-CAN. For emergency sessions initiated by a trusted AS on behalf of a non-roaming subscriber, the AS may provide the location identifier.

– The P‑CSCF serving the emergency call is the IMS network entity which may receive additional caller related identifier(s) from the IP-CAN (e.g. IP-CAN level’s subscriber ID). If required by local regulation, these additional identifier(s) shall be forwarded by the IMS network to the emergency control centre/PSAP for those UEs that have not been authenticated by IMS network and are requesting to establish an emergency session,

– The E‑CSCF is the IMS network entity, which shall be able to retrieve geographical location information from the LRF in the case that the geographical location information is not available and is required.

– If required, the E‑CSCF shall be able to forward the location information to the LRF for validation of geographical location information in the case that the geographical location information is included by the UE over any access network type.

– The E‑CSCF is the IMS network entity, which is responsible to route the request to an emergency centre/PSAP via or BGCF, IBCF or IP multimedia network based on location information and additionally other information such as type of emergency service in the request.

– As a regional option where the emergency centre/PSAP is connected to the IMS of another network (e.g. TTC spec), emergency sessions may be routed over Inter-IMS Network to Network Interface between two IM CN subsystem networks.

– The architecture shall allow for compliance with other regional regulations (i.e. ATIS and NENA specs in North America region) in which the originating network shall have the ability to route an emergency call via an IBCF to an emergency services network.

4.2 Naming and Addressing

When a UE performs an emergency registration, barring and roaming restrictions are ignored. The implicit registration set of the Public User Identifier used for emergency registrations shall contain an associated TEL‑URI.

NOTE: Annex G provides recommendations for the provisioning of TEL‑URI(s) in the IMS subscription for the purposes of IMS emergency sessions.

When a call is initiated to a PSAP from a UE without credentials, the E-CSCF shall derive a non-dialable callback number where required by local regulation (e.g. see Annex C of ANSI/J‑STD‑036 B [23]).

4.3 Location information for Emergency Sessions

Location information is needed for 2 main reasons in emergency services. The initial purpose of the location information is to enable the IMS network to determine which PSAP serves the area where the UE is currently located, so that the IMS network can route the emergency session to the correct PSAP. The second purpose is for the PSAP to get more accurate or updated location information for the terminal during or after the emergency session where required by local regulation.

4.3.1 General Location Information Principles

The following general principles shall apply regarding the handling of location information:

– If the UE has location information available, the UE shall include the location information in the request to establish an emergency session. The location information may consist of network location information, that is the Location Identifier, and/or the Geographical location information.

NOTE 1: For untrusted non-3GPP access to 5GC, provided location information can only correspond to the UE IP address seen by the N3IWF and used for traffic destined towards the UE.

NOTE 2: For NR satellite access to 5GC, an NR CGI (NCGI) provided in the location information by the UE can differ from the NCGI provided by NG-RAN and the area indicated by the former NCGI can differ from the area indicated by the latter NCGI.

– The P‑CSCF may query the IP‑CAN to obtain location identifier.

– If a trusted AS is used for the emergency session, the AS may provide the location identifier.

– When an emergency session is coming from a private network, it is assumed that the private network includes the initial location information in the request to establish an emergency session and subsequent location information as requested.

The E‑CSCF, if required, may query the LRF for additional location information. If the E‑CSCF does not receive location information in the emergency service request, it may query the LRF for location information.

– The E‑CSCF shall be able to query the LRF to validate the location information if provided initially by the UE.

– For WLAN access, the LRF may query HSS for NPLI if the UE is not roaming. In some regions, for example in the North American region [45], if the BSSID of the serving WLAN is available, the LRF may query a database subject to national regulations and operator policies for the dispatchable location associated with the BSSID of the WLAN Access Point.

– The E‑CSCF routes the emergency request to the PSAP/Emergency Centre that corresponds to the type of emergency service requested and to the type of emergency service requested and to the current location of the UE or to a default PSAP/Emergency Centre. The access dependent variations of this approach are described in the respective access specific annexes, for the cases where the UE is using GPRS (UTRAN), EPS (UTRAN and E-UTRAN), 5GS (NG-RAN), fixed broadband access, WLAN access to EPC or non-3GPP access to 5GC for the emergency service.

– The E‑CSCF forwards the SIP request containing the UE’s location information to the PSAP/Emergency Centre via PS domain or via BGCF/MGCF through the CS domain. The location information can contain explicit location information and/or a reference key to allow the PSAP to retrieve location at a later stage.

4.3.2 Void

4.4 IP-CAN

The following are the expectations on the IP-CAN for IMS emergency services:

– Except for emergency services over WLAN access to EPC or non-3GPP access to 5GC, it shall be possible to access the IP-CAN without sufficient security credentials.

– It shall be possible to reject requests from UE without sufficient security credentials to establish bearer resources.

– In the case that the IP-CAN receives a request to establish bearer resources for emergency services, it shall be possible for the IP-CAN to prioritise emergency services traffic. PCC (Policy and Charging Control) methods may be used to inform the IP-CAN and request appropriate handling of the emergency service. The QoS information for emergency traffic is specified in TS 23.203 [20].

– In the case that the IP-CAN receives a request to establish bearer resources for emergency services, the IP-CAN shall ensure that the IP flows using the requested resources are only for communication with the network entities involved in the support of the emergency services. Applicable service data flow filters for emergency traffic need to be defined by the operator according to the details described in TS 23.203 [20].

– In the case that the IP-CAN receives a request to establish bearer resources for emergency services, the IP-CAN may provide additional identifier(s) to IMS network (e.g. IP-CAN level’s subscriber ID).

– The IP-CAN may support emergency services free of charge. Applicable PCC rules need to be defined by the operator according to the details described in TS 23.203 [20].

– The IP-CAN may provide emergency numbers to the UE in order to ensure that local emergency numbers are known to the UE (see TS 22.101 [8]).

If the IP-CAN is a GPRS (UTRAN) network, the detailed procedures are described in TS 23.060 [2]. If the IP-CAN is an EPS (UTRAN and E-UTRAN) network, the detailed procedures are described in TS 23.401 [28] and TS 23.060 [2] and in Annex H. If the IP- CAN corresponds to WLAN access to EPC, the detailed procedures are described in TS 23.402 [29] and in Annex J. If the IP-CAN is a 5GS (NG-RAN) network, the detailed procedures are described in TS 23.502 [49] and in Annex H. If the IP-CAN corresponds to non-3GPP access to 5GC, the detailed procedures are described in TS 23.502 [49] and in Annex L.

The emergency support in different IP-CAN scenarios is described in the Informative Annex E.

4.5 Media

– When the call is established with a PSAP that supports voice only, voice and subject to local regulation, GTT media is allowed during the IMS emergency session.

– When the call is established with a PSAP that supports voice and other media, subject to UE and network support for the other media and local regulation, voice, GTT and other media according to TS 22.101 [8] can be used during the IMS emergency session.

– For sessions with a PSAP that supports voice and other media, media can be added, modified or removed during the IMS emergency session (e.g. adding video to a voice call) per media negotiation in TS 23.228 [1].

– When a PSAP that supports voice and other media attempts to add media, the media shall be added if accepted by the UE.