ETSI TS 123 167 V15.4.0 (2019-03)

Universal Mobile Telecommunications System (UMTS); LTE; IP Multimedia Subsystem (IMS) emergency sessions (3GPP TS 23.167 version 15.4.0 Release 15)

RTS/TSGS-0223167vf40

General Information

• Status: Published
• Publication Date: 10-Mar-2019
• Technical Committee: 3GPP SA 2 - Architecture
• Current Stage: 12 - Completion
• Completion Date: 11-Mar-2019

Standards Content (Sample)

TECHNICAL SPECIFICATION
Universal Mobile Telecommunications System (UMTS);
LTE;
IP Multimedia Subsystem (IMS) emergency sessions
(3GPP TS 23.167 version 15.4.0 Release 15)

3GPP TS 23.167 version 15.4.0 Release 15 1 ETSI TS 123 167 V15.4.0 (2019-03)

Reference
RTS/TSGS-0223167vf40
Keywords
LTE,UMTS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2019.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3GPP TS 23.167 version 15.4.0 Release 15 2 ETSI TS 123 167 V15.4.0 (2019-03)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.
The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under
http://webapp.etsi.org/key/queryform.asp.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
3GPP TS 23.167 version 15.4.0 Release 15 3 ETSI TS 123 167 V15.4.0 (2019-03)
Contents
Intellectual Property Rights . 2
Foreword . 2
Modal verbs terminology . 2
Foreword . 6
1 Scope . 7
2 References . 7
3 Definitions, symbols and abbreviations . 9
3.1 Definitions . 9
3.2 Abbreviations . 11
4 High level Principles . 11
4.1 Architectural Principles . 11
4.2 Naming and Addressing . 14
4.3 Location information for Emergency Sessions. 14
4.3.1 General Location Information Principles . 14
4.3.2 Void . 15
4.4 IP-CAN . 15
4.5 Media . 16
5 Architecture model and reference points . 16
5.1 Reference architecture . 16
5.2 Reference points . 17
6 Functional description . 17
6.1 UE . 17
6.2 IMS Functional entities . 19
6.2.1 Proxy-CSCF . 19
6.2.2 Emergency-CSCF . 20
6.2.3 Location Retrieval Function . 20
6.2.4 Serving-CSCF . 21
6.2.5 Void . 21
6.2.6 Emergency Access Transfer Function (EATF) . 21
6.2.7 Interrogating-CSCF . 22
6.2.8 AS . 22
6.2.9 HSS . 22
6.2.10 Media Gateway Control Function (MGCF) . 22
6.2.11 MSC Server enhanced with ICS . 22
6.2.12 IBCF . 22
7 Procedures related to establishment of IMS emergency session . 23
7.1 High Level Procedures for IMS Emergency Services . 23
7.1.1 UE Detectable Emergency Session . 23
7.1.2 Non UE detectable Emergency Session . 24
7.1.3 Emergency Session Establishment using LRF/RDF . 25
7.2 IMS Registration for Emergency Session . 26
7.3 Emergency Session Establishment in the Serving IMS network . 26
7.4 IMS Emergency Session Establishment without Registration . 28
7.5 Interworking with PSAP . 28
7.5.1 PSAP/Emergency centre located at the GSTN . 28
7.5.2 PSAP/Emergency centre connected via IP using SIP . 28
7.5.3 PSAP/Emergency centre connected via ECS . 28
7.5.4 PSAP supporting NG-eCall . 28
7.6 Retrieving Location information for Emergency Session . 28
7.6.1 Acquiring location information from the UE or the network . 28
7.6.2 Void . 30
7.6.3 Void . 31
ETSI
3GPP TS 23.167 version 15.4.0 Release 15 4 ETSI TS 123 167 V15.4.0 (2019-03)
7.7 Transfer of MSD for eCall . 31
7.7.1 MSD Transfer/Acknowledgement during Session Establishment with PSAP supporting NG-eCall . 31
7.7.2 MSD Transfer/Acknowledgement during Session Establishment with a PSAP Not supporting NG-
eCall (inband means) . 32
7.7.3 Transfer of an updated MSD. 33
Annex A (informative): Void . 34
Annex B (informative): Void . 35
Annex C (normative): IMS emergency services using Fixed Broadband Access . 36
C.1 Location Retrieval for emergency services over fixed broadband access . 36
C.1.1 High Level Principles for Emergency location information for fixed broadband access . 36
C.1.2 Retrieval of location information for emergency services over fixed broadband access . 37
Annex D (informative): Examples of call flows according to NENA I2 recommendations . 38
D.1 ECS redirecting IMS emergency call . 38
D.2 ECS routes the emergency call to the gateway with record route . 40
Annex E (informative): Emergency support in different IP-CANs . 42
Annex F (normative): IMS Emergency Services Using HRPD/PDS Network . 43
F.1 cdma2000 HRPD/PDS Options . 43
F.2 Requirements on the HRPD Network as an IP-CAN . 43
F.3 Information Flows . 43
Annex G (informative): TEL-URI provisioning considerations for IMS emergency call back . 44
Annex H (normative): IMS emergency services using UTRAN, E-UTRAN and NG-RAN
radio access network . 45
H.1 General . 45
H.2 UE specific behaviour . 45
H.3 High Level Procedures for IMS emergency calls . 46
H.4 Location handling . 46
H.5 Domain Priority and Selection Rules for Emergency Session Attempts . 47
H.6 eCall over IMS . 50
Annex I (normative): IMS Emergency Services Using HRPD/EPC Network . 52
I.1 cdma2000 HRPD/EPC Options . 52
I.2 Requirements on the HRPD/EPC Network as an IP-CAN. 52
I.3 Information Flows . 52
Annex J (normative): IMS emergency services using WLAN access to EPC . 53
J.1 General . 53
J.2 UE specific behaviour . 53
J.3 High Level Procedures for IMS emergency calls . 54
J.4 Location handling . 55
Annex K (normative): Support of IMS emergency sessions for roaming users in
deployments without IMS-level roaming interfaces . 56
K.1 General . 56
ETSI
3GPP TS 23.167 version 15.4.0 Release 15 5 ETSI TS 123 167 V15.4.0 (2019-03)
K.2 Functional description . 56
K.2.1 General . 56
K.2.2 P-CSCF . 56
K.2.3 PCRF . 56
K.2.4 PGW . 56
K.2.4 HSS . 56
K.3 IMS Emergency Registration and Session Establishment . 56
K.4 Non UE detectable Emergency Session . 58
Annex L (normative): IMS emergency services using untrusted non-3GPP access to 5GC . 60
L.1 General . 60
L.2 UE specific behaviour . 60
L.3 High Level Procedures for IMS emergency calls . 60
L.4 Location handling . 62
Annex M (informative): Change history . 63
History . 66

ETSI
3GPP TS 23.167 version 15.4.0 Release 15 6 ETSI TS 123 167 V15.4.0 (2019-03)
Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
ETSI
3GPP TS 23.167 version 15.4.0 Release 15 7 ETSI TS 123 167 V15.4.0 (2019-03)
1 Scope
This document defines the stage 2 service description for emergency services in the IP Multimedia Core Network
Subsystem (IMS), including the elements necessary to support IP Multimedia (IM) emergency services and IM
emergency services for eCall. ITU-T Recommendation I.130 [4] describes a three-stage method for characterisation of
telecommunication services, and ITU-T Recommendation Q.65 [3] defines stage 2 of the method.
This document covers also the Access Network aspects that are crucial for the provisioning of IMS emergency services.
Other 3GPP specifications that are related to the IMS emergency services are TS 23.228 [1] on IMS in general,
including fixed broadband access aspects, TS 23.060 [2] describing GPRS (UTRAN): TS 23.401 [28] describing EPS
(UTRAN and E-UTRAN); TS 23.402 [29] describing Non 3GPP access (WLAN) to EPC; TS 23.271 [5] that covers
location services; TS 23.216 [31] and TS 23.237 [32] describing Single Radio Voice Call Continuity (SRVCC) and
Dual Radio Voice Call Continuity (DRVCC) for IMS Emergency session, TS 23.292 [45] describing the use of IMS
services when using CS access for the media bearer and TS 23.501 [48] and TS 23.502 [49] describing support of
emergency services and location for 5GS. TS 25.301 [6] contains an overall description of the UMTS Terrestrial Radio
Access Network; TS 36.300 [30] contains an overall description of the Evolved Universal Terrestrial Radio Access (E-
UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); and TS 38.300 [50] contains an overall
description of the Next Generation Radio Access Network (NG-RAN). Other non-3GPP specifications that are related
to the IMS emergency services include 3GPP2 cdma2000 HRPD IP-CAN, as specified in 3GPP2 X.S0060 [25] when
the UE is connected to a PDS core network and 3GPP2 X.S0057-A [39] when the UE is connected to an EPC core
network.
The emergency support in different IP-CANs is described in the Informative Annex E.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TS 23.228: "3rd Generation Partnership Project; Technical Specification Group Services
and Systems Aspects; IP Multimedia Subsystem (IMS); Stage 2".
[2] 3GPP TS 23.060: "3rd Generation Partnership Project; Technical Specification Group Services
and Systems Aspects; General Packet Radio Service (GPRS); Service description; Stage 2".
[3] CCITT Recommendation Q.65: "Methodology – Stage 2 of the method for the characterisation of
services supported by an ISDN".
[4] ITU Recommendation I.130: "Method for the characterization of telecommunication services
supported by an ISDN and network capabilities of an ISDN".
[5] 3GPP TS 23.271: "3rd Generation Partnership Project; Technical Specification Group Services
and Systems Aspects; Functional stage 2 description of LCS".
[6] 3GPP TS 25.301: "3rd Generation Partnership Project; Technical Specification Group Radio
Access Network; Radio Interface Protocol Architecture".
[7] Void.
[8] 3GPP TS 22.101: "3rd Generation Partnership Project; Technical Specification Group Services
and Systems Aspects; Service aspects; Service principles".
[9] IETF RFC 3825: "Dynamic Host Configuration Protocol Option for Coordinate-based Location
Configuration Information".
ETSI
3GPP TS 23.167 version 15.4.0 Release 15 8 ETSI TS 123 167 V15.4.0 (2019-03)
[10] IETF RFC 4676: "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for
Civic Addresses Configuration Information ".
[11] 3GPP TR 21.905: "3rd Generation Partnership Project; Technical Specification Group Services
and System Aspects; Vocabulary for 3GPP Specifications".
[12] 3GPP TS 23.002: "3rd Generation Partnership Project; Technical Specification Group Services
and Systems Aspects; Network architecture".
[13] 3GPP TS 24.008: "3rd Generation Partnership Project; Technical Specification Group Core
Network and Terminals; Mobile radio interface Layer 3 specification; Core network protocols;
Stage 3".
[14] IETF RFC 4119: "A Presence-based GEOPRIV Location Object Format".
[15] OMA AD SUPL: "Secure User Plane Location Architecture", http://www.openmobilealliance.org.
[16] OMA TS ULP: "User Plane Location Protocol", http://www.openmobilealliance.org.
[17] NENA I2 architecture: "Interim VoIP Architecture for Enhanced 9-1-1 Services (i2)".
[18] ETSI ES 282 004: "Protocols for Advanced Networking (TISPAN); NGN Functional Architecture;
Network Attachment Sub-System (NASS)".
[19] 3GPP TS 24.229: "IP multimedia call control protocol based on SIP and SDP; stage 3".
[20] 3GPP TS 23.203: "Policy and Charging Control architecture".
[21] 3GPP TS 23.003: "Numbering, addressing and identification".
[22] Void.
[23] ANSI/J-STD-036-B: "Enhanced Wireless 9-1-1, Phase 2".
[24] 3GPP2 X.S0002-0: "MAP Location Services Enhancements".
[25] 3GPP2 X.S0060: "HRPD Support for Emergency Service".
[26] 3GPP TS 22.003: "Circuit Teleservices supported by a Public Land Mobile Network (PLMN)".
[27] 3GPP TS 22.228: "Service requirements for the Internet Protocol (IP) multimedia core network
subsystem; Stage 1".
[28] 3GPP TS 23.401: "General Packet Radio Service (GPRS) enhancements for Evolved Universal
Terrestrial Radio Access Network (E-UTRAN) access".
[29] 3GPP TS 23.402: "Architecture enhancements for non-3GPP accesses".
[30] 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal
Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2".
[31] 3GPP TS 23.216: "Single Radio Voice Call Continuity (SR VCC); Stage 2".
[32] 3GPP TS 23.237: "IP Multimedia Subsystem (IMS) Service Continuity; Stage 2".
[33] 3GPP TS 24.301: "General Packet Radio Service (GPRS) enhancements for Evolved Universal
Terrestrial Radio Access Network (E-UTRAN) access".
[34] 3GPP TS 26.114: "IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and
interaction".
[35] 3GPP TS 32.260: "Telecommunication management; Charging management; IP Multimedia
Subsystem (IMS) charging".
[36] ETSI TS 181 019 V2.0.0: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Business Communication Requirements".
ETSI
3GPP TS 23.167 version 15.4.0 Release 15 9 ETSI TS 123 167 V15.4.0 (2019-03)
[37] ETSI TS 182 024 v.2.1.1: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Hosted Enterprise Services; Architecture, functional description
and signalling".
[38] ETSI TS 182 025 v.2.1.1: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Business trunking; Architecture and functional description".
[39] 3GPP2 X.S0057-C v1.0: "E-UTRAN - eHRPD Connectivity and Interworking: Core Network
Aspects".
[40] NENA 08-002, Version 1.0 (i3): "NENA Functional and Interface Standards for Next Generation
9-1-1".
[41] 3GPP TS 23.122: "Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle
mode".
[42] 3GPP TS 26.267: "Digital cellular telecommunication systems (Phase 2+); Universal Mobile
Telecommunication System (UMTS); eCall data transfer; In-band modem solution General
description".
[43] 3GPP TS 23.328: "P Multimedia (IM) Subsystem Sh interface; Signalling flows and message
contents".
[44] 3GPP TS 33.203: "3G security; Access security for IP-based services".
[45] ATIS-0700028: "Location Accuracy Improvements for Emergency Calls".
[46] 3GPP TS 23.292: "IP Multimedia Subsystem (IMS) centralized services".
[47] IEEE Std 802.11-2012: "IEEE Standard for Information technology--Telecommunications and
information exchange between systems Local and metropolitan area networks--Specific
requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications".
[48] 3GPP TS 23.501: "System Architecture for the 5G System; Stage 2".
[49] 3GPP TS 23.502: "Procedures for the 5G System; Stage 2".
[50] 3GPP TS 38.300: "NR; Overall description; Stage-2".
[51] 3GPP TS 23.503: "Policy and Charging Control Framework for the 5G System; Stage 2".
[52] 3GPP TS 24.501: "Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3".
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [11] and the following apply. A
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [11].
Charging Data Record: Record generated by a network element for the purpose of billing a subscriber for the
provided service. See TS 32.260 [35] for further details.
Connectivity Session Location and Repository Function (CLF): As per ETSI ES 282 004 [18], the Connectivity
Session Location and Repository Function (CLF) registers the association between the IP address allocated to the UE
and related network location information, i.e.: access transport equipment characteristics, line identifier (Logical Access
ID), IP Edge identity.
NG-eCall (eCall Over IMS): A manually or automatically initiated IMS emergency call, from a vehicle, supplemented
with a minimum set of emergency related initial data (MSD).
ETSI
3GPP TS 23.167 version 15.4.0 Release 15 10 ETSI TS 123 167 V15.4.0 (2019-03)
Emergency Call Server (ECS): The functional entity consists of a Location Retrieval Function (LRF) and either a
routing proxy or a redirect server, e.g. an ECS contains a VPC and a Routing Proxy or Redirect Server in NENA I2
architecture [17].
Emergency-CSCF: The Emergency-CSCF handles certain aspects of emergency sessions, e.g. routing of emergency
requests to the correct emergency centre or PSAP.
Emergency Service Query Key (ESQK): A 10-digit North American Numbering Plan number used to identify a
particular emergency call instance. It is used by the LRF as a key to look up for the location information and callback
information associated with the emergency call instance and is also used by the PSAP to query location information
from the LRF.
Emergency Service Routing Key (ESRK): see TS 23.271 [5] or J-STD-036 [23].
Emergency Service Routing Number (ESRN): North American Numbering Plan number used for routing of an
emergency call to the appropriate gateway for an eventual delivery towards a CS-based PSAP.
Geographical Location Information: Location indicated in geographical terms, for example geographical coordinates
or street address (e.g. as supported by IETF RFC 4119 [14]).
Local regulation: Condition defined by the authority whose legislation applies where the emergency service is
invoked.
Location Identifier: Information about the current location of the UE in the network. Location is indicated in network
terms, for example using the global cell id in cellular networks, line-id in fixed broadband networks, (OMA-Location
also uses this term, but OMA so far defines the Location Identifier only for cellular access.)
Location Information: The location information may consist of the Location Identifier, and/or the Geographical
location information.
Location Retrieval Function (LRF): This functional entity handles the retrieval of location information for the UE
including, where required, interim location information, initial location information and updated location information.
The LRF may interact with a separate RDF or contain an integrated RDF in order to obtain routing information. The
LRF may interact with a separate Location Server or contain an integrated Location Server in order to obtain location
information. The LRF may interact with or contain other types of location server functions in order to obtain location
information.
Location Server (LS): General term for the entity responsible for obtaining the location of the UE (e.g. GMLC see
TS 23.271 [5], MPC see 3GPP2 X.S0002 [24] or SLP see OMA AD SUPL [15]).
Last Routing Option (LRO): A number, which may be used in the event of network failure towards a specific location
based PSAP or a number that can be associated to a national or default PSAP/Emergency centre.
Operator policy: Condition set by operator.
Private Numbering Plan: According to ETSI TS 181 019 [36], a numbering plan explicitly relating to a particular
private numbering domain.
Public Safety Answering Point (PSAP): A physical location, where emergency calls from the public are received.
Routing Determination Function (RDF): The functional entity, which may be integrated in a Location Server or in an
LRF, provides the proper PSAP destination address to the E-CSCF for routing the emergency request. It can interact
with a LS to manage ESQK allocation and management, and deliver location information to the PSAP.
For the purposes of the present document, the following terms and definitions given in TS 24.229 [19] apply:
Private Network Traffic
NOTE: All traffic from UEs having registered a contact bound to a public user identity receiving hosted
enterprise services, is private network traffic.
Public Network Traffic
For the purposes of the present document, the following terms and definitions given in TS 23.401 [28] apply:
eCall Only Mode: See TS 23.401 [28].
ETSI
3GPP TS 23.167 version 15.4.0 Release 15 11 ETSI TS 123 167 V15.4.0 (2019-03)
For the purposes of the present document, the following terms and d efinitions given in TS 22.101 [8] apply:
eCall: See TS 22.101 [8].
Minimum Set of Data (MSD): See TS 22.101 [8].
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
CDR Charging Data Record
CLF Connectivity session Location and repository Function
CS Circuit Switched
DRVCC Dual Radio Voice Call Continuity
E-CSCF Emergency-CSCF
EATF Emergency Access Transfer Function
ECS Emergency Call Server
ESQK Emergency Service Query Key
ESRK Emergency Service Routing Key
ESRN Emergency Service Routing Number
HRPD High Rate Packet Data
LRF Location Retrieval Function
LRO Last Routing Option
LS Location Server
MPC Mobile Positioning Centre
MSD Minimum Set of emergency related Data
PDS Packet Data Subsystem
PSAP Public Safety Answering Point
RDF Routing Determination Function
SET SUPL Enabled Terminal
SLP SUPL Location Platform
SRVCC Single Radio Voice Call Continuity
SUPL Secure User Plane for Location
URN Uniform Resource Name
VPC VoIP Positioning Centre
WLAN Wireless LAN
4 High level Principles
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, a fixed broadband
access, a nomadic access and a WLAN access to EPC or untrusted non-3GPP access to 5GC (using procedures
for Un-trusted access to EPC (respectively 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
ETSI
3GPP TS 23.167 version 15.4.0 Release 15 12 ETSI TS 123 167 V15.4.0 (2019-03)
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
TS 22.101 [8] clause 10.4.1 (i.e. the serving network indicates whether this list is valid in the country or only in
the PLMN). 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 in case 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).
ETSI
3GPP TS 23.167 version 15.4.0 Release 15 13 ETSI TS 123 167 V15.4.0 (2019-03)
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
...