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

• 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 and TS 23.216, 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. E-CSCF follows the same procedure as defined for handling emergency session request from P-CSCF.

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.

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

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

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

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

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.

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

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.

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