6 Functional description

23.1673GPPIP Multimedia Subsystem (IMS) emergency sessionsRelease 17TS

6.1 UE

– Should be able to detect an emergency session establishment request.

– In the case of NG-eCall, the IMS emergency session establishment request may be invoked either automatically without user input or manually via user input.

– Initiate an IMS emergency registration request.

– The UE may perform an IMS emergency session establishment without prior emergency registration when already IMS registered and it is in home network (e.g. including IP-CANs where roaming outside the home network is not supported).

– Otherwise, the UE shall perform an IMS emergency registration.

– Include an emergency service indication in the emergency session request.

– UE may support the GIBA procedure defined in TS 24.229 [19] as part of the emergency IMS registration procedure.

– In the case of emergency IMS registration failure the UE shall be able to interpret the indication, if provided by the serving IMS, whether anonymous IMS emergency sessions are supported in the serving IMS. If the serving IMS has indicated support, the UE shall proceed with an anonymous IMS emergency session, otherwise it proceeds according to clause H.5.

NOTE 1: 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 clause H.5.

– Include an equipment identifier in the request to establish an emergency session for "anonymous user".

NOTE 2: "Anonymous user" in this context is the person who does not have sufficient credential for IMS registration. No Stage 3 work is expected as the anonymous user detection already existed today.

– Include an equipment identifier in the request to establish an emergency session when the UE supports SRVCC as specified in TS 23.237 [32].

– Include identity information for the IP-CAN if available (e.g. MCC-MNC or an equivalent)

NOTE 3: UE provided IP-CAN identity information will not be completely reliable.

– Attempt the emergency call in CS domain, if capable.

– Handle a 380 (Alternative Service) response with the type set to "emergency" e.g. as a result of non UE detectable emergency attempt.

– Handle a response with an indication, IMS emergency registration required as a result of emergency session establishment attempt.

– Other general requirements of UE shall be referred to the general requirements of emergency calls in TS 22.101 [8].

– For NG-eCall, where transfer of the MSD is not acknowledged by the PSAP, the UE shall fall back to the in-band transfer of the MSD, as in CS domain defined in TS 26.267 [42].

The UE initiates the emergency session establishment request, and for the purpose of processing the request properly in the network, the following specific information is supplied in the request message.

– Emergency service indication.

– A registered Public User Identifier. If the UE performed an emergency registration using a temporary Public User Identifier then the UE should not use the temporary Public User Identifier to initiate the emergency session. The selected Public User Identifier shall be part of an implicit registration set that includes a TEL‑URI.

NOTE 4: The UE can be preconfigured with information to select the appropriate Public User Identifier if more than one Public User Identifier is provisioned in the UE.

– Optionally, type of emergency service. It could be implied in the above emergency service indication.

– For an NG-eCall an eCall indication including whether eCall is automatic or manual.

– UE’s location information, if available.

– The TEL‑URI associated to the Public User Identifier, if available.

– GRUU, if available.

In the case of a non UE detectable emergency call, upon reception of indication from the network, the UE shall handle the call as described in clause 7.1.2.

NOTE 5: If the indication was received in a rejection message the UE performs appropriate emergency error handling procedures.

6.2 IMS Functional entities

6.2.1 Proxy‑CSCF

– Handle registration requests with an emergency registration indication like any other registration request, except that it may reject an emergency registration request if the IM CN subsystem that the P‑CSCF belongs to can not support emergency sessions for the UE (e.g., due to operator policy or UE is not within IM CN subsystem’s geographical area or IP-CAN not supported).

– Detect an emergency session establishment request.

– Reject/allow unmarked emergency requests.

– Reject/allow anonymous emergency requests.

– Prevent non-emergency requests that are associated with an emergency registration.

– May query IP-CAN for location identifier.

– May query IP-CAN for additional subscriber related identifier(s).

– Select an Emergency CSCF in the same network to handle the emergency session request. The selection method is not standardized in the present document.

– Alternatively, for non-roaming subscribers and when the request is received over a non-emergency registration, the P-CSCF may forward an emergency session to an S-CSCF if so instructed by operator policy or local regulation.

NOTE: This can be for example the case if the P‑CSCF recognizes that an emergency session was not received via a security association for a UE previously authenticated with digest type proxy authentication.

– Do not apply emergency session detection if requested using private network traffic and forward the session to the S-CSCF, except if operator policy requires the P-CSCF to detect emergency session requests and treat detected emergency session requests as if they are part of public network traffic.

– For UEs without credentials, forward the equipment identifier to the E-CSCF that was received from the UE.

– For UEs without credentials and subjected to local regulation, forward the additional subscriber related identifier(s) received from IP-CAN to the E-CSCF.

– Prioritize the emergency session.

– Check the validity of the caller TEL‑URI if provided by the UE and shall provide the TEL‑URI in the session establishment request if it is aware about the TEL‑URI associated with the Public User Identifier used for an emergency registration.

– May respond to a UE with an emergency service indication as a result of detecting a non UE detectable emergency session establishment request

– May respond to the UE with an indication, IMS emergency registration required as a result of processing the emergency session establishment attempt.

– Should be able to identify the service data flow associated with emergency service and inform PCRF accordingly.

– Upon IMS registration failure the P-CSCF may indicate to the UE whether anonymous IMS emergency sessions are supported.

– P-CSCF may, based on operator policy, insert attestation information related to the asserted calling identity associated with an emergency session, if operating in a network that supports calling number attestation and signing.

– P-CSCF may assert Resource-Priority information for an emergency session if configured through operator policies.

6.2.2 Emergency‑CSCF

– Receive an emergency session establishment request from a P‑CSCF or an S-CSCF.

– If the UE does not have credentials, a non-dialable callback number shall be derived where required by local regulation (e.g. see Annex C of J‑STD‑036 [23]).

– If location information is not included in the emergency request or additional location information is required, the E‑CSCF may request the LRF to retrieve location information as described in clause 7.6 Retrieving Location information for Emergency Session.

– If required, the E‑CSCF requests the LRF to validate the location information if included by the UE.

– Determines or queries the LRF for the proper routing information/PSAP destination.

– Route emergency session establishment requests to an appropriate destination including anonymous session establishment requests.

– Subject to local regulation, the E‑CSCF may send the contents of the P-asserted ID or UE identification to the LRF.

– Based on operator policy, the E‑CSCF may route the emergency IMS call to ECS for further call process.

– For supporting SRVCC and/or DRVCC, see TS 23.237 [32] and TS 23.216 [31], the E CSCF forwards the session establishment request to the EATF in the serving IMS network for anchoring.

– Generation of CDRs.

– For an NG-eCall and if an LRF/RDF is not deployed, the E-CSCF may use an indication of an automatic eCall or a manual eCall to assist routing of an emergency session establishment request.

– For supporting emergency session request from MSC Server enhanced with ICS, see TS 23.292 [46]. E-CSCF follows the same procedure as defined for handling emergency session request from P-CSCF.

6.2.3 Location Retrieval Function

The Location Retrieval Function (LRF) is responsible for retrieving the location information of the UE that has initiated an IMS emergency session. It shall be possible to support configurations where the Location Retrieval Function (LRF) may consist of a Routing Determination Function (RDF) and a LS, the interface between Location Server and RDF is out of scope of this specification. For WLAN access, and for non-roaming UEs, if the LRF is configured then it may interact with HSS to provide an NPLI before interacting with the RDF. In some regions, for example in the North American region, ATIS-0700028 [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 LRF utilizes the RDF to provide the routing information to the E‑CSCF for routing the emergency request. The RDF can interact with a LS and manage ESQK allocation and management. The ESQK is used by the PSAP to query the LRF for location information and optionally a callback number. The LRF-PSAP interactions are outside the scope of this specification.

Information provided by the LRF to the E‑CSCF includes the routing information and other parameters necessary for emergency services, which are subject to local regulation. For example, this information may include the ESQK, ESRN, LRO in North America, location number in EU, PSAP SIP‑URI or TEL‑URI.

In order to provide the correct PSAP destination address to the E‑CSCF, the LRF may require interim location information for the UE.

In some regions, for example in the North American region, it may be a requirement to provide the PSAP with an accurate initial location estimate for the UE and possibly to provide an accurate updated location estimate for the UE if requested by the PSAP. When this requirement exists, the LRF may store a record of the emergency session including all information provided by the E‑CSCF and shall only release this record when informed by the E‑CSCF that the emergency session has terminated. The information provided by the LRF to the E‑CSCF (e.g. ESQK) shall then include correlation information identifying both the LRF and the emergency session record in the LRF. This correlation information shall be transferred to the PSAP during session establishment (e.g. in a SIP INVITE or via SS7 ISUP signalling from the MGCF). The PSAP may use this information to request an initial location estimate from the LRF and/or to request an updated location estimate.

6.2.4 Serving-CSCF

When the S‑CSCF receives an Emergency Registration, the S‑CSCF determine the duration of the registration by checking the value of the Expires header in the received REGISTER request and based on local regulation or operator policy of the serving system.

NOTE 1: The value of the emergency registration time is subject to local regulation and can be subject to roaming agreements.

The emergency registration shall be handled as normal IMS registrations with the following considerations:

– Upon emergency registration:

– If a normal registration for the user does not exist, the S-CSCF shall download corresponding user profile from HSS to ensure that HSS allocates S-CSCF name to this subscriber and the registration status is set to UNREGISTERED.

– Otherwise, S-CSCF shall ensure that the registration status of the user is not changed in the HSS.

– Upon deregistration or expiration of the last normal session:

– If an emergency registration for the user still exists, the S-CSCF shall ensure that the HSS keeps S-CSCF name allocated to this subscriber and the registration status is set to UNREGISTERED.

– Upon expiration of an emergency registration:

– If a normal registration for the user still exists, the S-CSCF shall ensure that the registration status of the user is not changed in the HSS.

– Otherwise, the S-CSCF can either de-register the user in HSS or keep the registration status of the user unchanged in the HSS.

When an S-CSCF receives a session initiated by a non-roaming subscriber marked as emergency session from a P-CSCF, the S-CSCF:

– performs caller authentication in the same way as for any other sessions;

– if required, uses filter criteria to route to AS;

– and forwards the request to an E-CSCF.

When an S-CSCF receives a session marked as emergency session from an AS, the S-CSCF:

– if required, uses filter criteria to route to other ASs;

– and forwards the request to an E-CSCF.

NOTE 2: The AS can initiate an emergency request on behalf of a non-roaming user, can convert private network traffic to public network traffic, or can interpret a number in private numbering plan and detect that the request is for emergency session.

NOTE 3: Reception of a session initiation request marked as an emergency session from a P-CSCF and/or an AS by the S-CSCF is only expected over a non-emergency registration.

6.2.5 Void

6.2.6 Emergency Access Transfer Function (EATF)

The EATF provides IMS emergency session continuity which is specified in TS 23.237 [32].

6.2.7 Interrogating-CSCF

I-CSCF supports IMS emergency session continuity which is specified in TS 23.237 [32].

6.2.8 AS

An AS can be involved in emergency session handling (e.g. for emergency sessions made via hosted enterprise services ETSI TS 182 024 [37], or for AS initiated session).

NOTE 1: The participation of an AS in emergency session handling is only expected over a non-emergency registration.

Dependent on the service provided by the AS, if the AS is the first point that identifies an IMS emergency session, then the AS shall provide the following emergency session handling functions:

– Detect an emergency session establishment request.

– Verify that the UE is not roaming.

– Optionally obtain location.

– Prioritize the emergency session.

– Provide in the session establishment request the TEL URI associated to the public user identity, in global format, if known and not already present.

– Check the validity of the caller TEL URI if provided by the UE.

– Mark the request as an emergency session request.

NOTE 2: If the AS converts a request marked as private network traffic to public network traffic and the request is marked by the AS as emergency session, the AS routes the request back to the S-CSCF, which will forward the request towards a public PSAP. If a request is targeted to a private PSAP, then it is marked as private network traffic and normal routing procedures in the IMS network will deliver the request to its target, possibly with priority handling if mandated by local regulations.

6.2.9 HSS

In the course of an emergency registration, the HSS shall not apply any barring condition and/or roaming restriction associated with the Public User Identity received in the emergency registration request.

The emergency registration shall be handled with the considerations defined in clause 6.2.4.

6.2.10 Media Gateway Control Function (MGCF)

For NG-eCall MGCF handles the emergency session as normal emergency call establishment.

NOTE: The MGCF does not forward the initial MSD, if received in the emergency session request.

6.2.11 MSC Server enhanced with ICS

The MSC Server enhanced with ICS may provide interworking mechanisms to support emergency call using CS media bearer and using IMS for routing/handling the emergency call toward PSAP. From the view point of E-CSCF, MSC Server enhanced with ICS behaves like a P-CSCF. Further details on MSC Server procedure are defined in TS 23.292 [46].

6.2.12 IBCF

– Forward emergency session establishment requests.

– Prioritize the emergency session based on operator policy.

– For an emergency session leaving an IBCF, the IBCF, if configured through operator policies, invokes an AS for the signing of attested caller identity and asserted Resource-Priority information, if available in the incoming request. The IBCF includes the signed information in the outgoing request.

– For a call back received by an IBCF, the IBCF, if configured through operator policies, shall invoke an AS for the verification of Resource-Priority information, if available in the incoming request.