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…

 

5  Architecture model and reference points

5.1  Reference architecture

This specification introduces an additional CSCF role to those defined in the IMS architecture TS 23.002, called Emergency CSCF (E-CSCF), see Figure 5.1.
Reproduction of 3GPP TS 23.167, Figure 5.1: E-CSCF in reference architecture
Up

5.2  Reference pointsWord‑p. 17
The E-CSCF uses Mw, Mg, Mi, Ml, Mm, Mx and I4 reference points to connect to other IMS entities and other IP Networks.
I4:
reference point between an E-CSCF and an EATF. See TS 23.237.
I5:
reference point between an I-CSCF and an EATF. See TS 23.237.
I6:
reference point between an MSC Server enhanced for ICS and E-CSCF. See TS 23.292.
Sh:
reference point between LRF and HSS. See TS 29.328.

6  Functional description

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 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.
  • Include an equipment identifier in the request to establish an emergency session for "anonymous user".
  • Include an equipment identifier in the request to establish an emergency session when the UE supports SRVCC as specified in TS 23.237.
  • Include identity information for the IP-CAN if available (e.g. MCC-MNC or an equivalent)
  • 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.
  • 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.
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.
  • 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.
Up

6.2  IMS Functional entitiesWord‑p. 19

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

6.2.2  Emergency CSCFWord‑p. 20
 
  • 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.
Up

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

6.2.4  Serving-CSCFWord‑p. 21
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.
Up

6.2.5Void

6.2.6  Emergency Access Transfer Function (EATF) |R9|Word‑p. 22
The EATF provides IMS emergency session continuity which is specified in TS 23.237.

6.2.7  Interrogating-CSCF |R9|

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

6.2.8  AS |R10|

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

6.2.9  HSS |R9|

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

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

6.2.11  MSC Server enhanced with ICS |R14|

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.

6.2.12  IBCF |R14|Word‑p. 23
 
  • Forward emergency session establishment requests.
  • Prioritize the emergency session based on operator policy.


Up   Top   ToC