ETSI TS 123 167 V16.4.0 (2021-07)

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

RTS/TSGS-0223167vg40

General Information

• Status: Not Published
• Technical Committee: 3GPP SA 2 - Architecture
• Current Stage: 12 - Completion
• Completion Date: 29-Jul-2021

Standards Content (Sample)

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

3GPP TS 23.167 version 16.4.0 Release 16 1 ETSI TS 123 167 V16.4.0 (2021-07)

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

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

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
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
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 2021.
All rights reserved.
ETSI
3GPP TS 23.167 version 16.4.0 Release 16 2 ETSI TS 123 167 V16.4.0 (2021-07)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 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.
Legal Notice
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. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 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 16.4.0 Release 16 3 ETSI TS 123 167 V16.4.0 (2021-07)
Contents
Intellectual Property Rights . 2
Legal Notice . 2
Modal verbs terminology . 2
Foreword . 6
1 Scope . 8
2 References . 8
3 Definitions, symbols and abbreviations . 10
3.1 Definitions . 10
3.2 Abbreviations . 12
4 High level Principles . 12
4.1 Architectural Principles . 12
4.2 Naming and Addressing . 15
4.3 Location information for Emergency Sessions. 15
4.3.1 General Location Information Principles . 16
4.3.2 Void . 16
4.4 IP-CAN . 16
4.5 Media . 17
5 Architecture model and reference points . 17
5.1 Reference architecture . 17
5.2 Reference points . 18
6 Functional description . 18
6.1 UE . 18
6.2 IMS Functional entities . 20
6.2.1 Proxy-CSCF . 20
6.2.2 Emergency-CSCF . 21
6.2.3 Location Retrieval Function . 21
6.2.4 Serving-CSCF . 22
6.2.5 Void . 23
6.2.6 Emergency Access Transfer Function (EATF) . 23
6.2.7 Interrogating-CSCF . 23
6.2.8 AS . 23
6.2.9 HSS . 23
6.2.10 Media Gateway Control Function (MGCF) . 23
6.2.11 MSC Server enhanced with ICS . 23
6.2.12 IBCF . 24
7 Procedures related to establishment of IMS emergency session . 24
7.1 High Level Procedures for IMS Emergency Services . 24
7.1.1 UE Detectable Emergency Session . 24
7.1.2 Non UE detectable Emergency Session . 25
7.1.3 Emergency Session Establishment using LRF/RDF . 26
7.2 IMS Registration for Emergency Session . 27
7.3 Emergency Session Establishment in the Serving IMS network . 27
7.4 IMS Emergency Session Establishment without Registration . 29
7.5 Interworking with PSAP . 29
7.5.1 PSAP/Emergency centre located at the GSTN . 29
7.5.2 PSAP/Emergency centre connected via IP using SIP . 29
7.5.3 PSAP/Emergency centre connected via ECS . 29
7.5.4 PSAP supporting NG-eCall . 29
7.6 Retrieving Location information for Emergency Session . 30
7.6.1 Acquiring location information from the UE or the network . 30
7.6.2 Void . 32
7.6.3 Void . 32
ETSI
3GPP TS 23.167 version 16.4.0 Release 16 4 ETSI TS 123 167 V16.4.0 (2021-07)
7.7 Transfer of MSD for eCall . 32
7.7.1 MSD Transfer/Acknowledgement during Session Establishment with PSAP supporting NG-eCall . 32
7.7.2 MSD Transfer/Acknowledgement during Session Establishment with a PSAP Not supporting NG-
eCall (inband means) . 33
7.7.3 Transfer of an updated MSD. 34
Annex A (informative): Void . 36
Annex B (informative): Void . 37
Annex C (normative): IMS emergency services using Fixed Broadband Access . 38
C.1 Location Retrieval for emergency services over fixed broadband access . 38
C.1.1 High Level Principles for Emergency location information for fixed broadband access . 38
C.1.2 Retrieval of location information for emergency services over fixed broadband access . 39
Annex D (informative): Examples of call flows according to NENA I2 recommendations . 40
D.1 ECS redirecting IMS emergency call . 40
D.2 ECS routes the emergency call to the gateway with record route . 42
Annex E (informative): Emergency support in different IP-CANs . 44
Annex F (normative): IMS Emergency Services Using HRPD/PDS Network . 45
F.1 cdma2000 HRPD/PDS Options . 45
F.2 Requirements on the HRPD Network as an IP-CAN . 45
F.3 Information Flows . 45
Annex G (informative): TEL-URI provisioning considerations for IMS emergency call back . 46
Annex H (normative): IMS emergency services using UTRAN, E-UTRAN and NG-RAN
radio access network . 47
H.1 General . 47
H.2 UE specific behaviour . 47
H.3 High Level Procedures for IMS emergency calls . 48
H.4 Location handling . 48
H.5 Domain Priority and Selection Rules for Emergency Session Attempts . 49
H.6 eCall over IMS . 52
Annex I (normative): IMS Emergency Services Using HRPD/EPC Network . 54
I.1 cdma2000 HRPD/EPC Options . 54
I.2 Requirements on the HRPD/EPC Network as an IP-CAN. 54
I.3 Information Flows . 54
Annex J (normative): IMS emergency services using WLAN access to EPC . 55
J.1 General . 55
J.2 UE specific behaviour . 55
J.3 High Level Procedures for IMS emergency calls . 56
J.4 Location handling . 57
Annex K (normative): Support of IMS emergency sessions for roaming users in
deployments without IMS-level roaming interfaces . 58
K.1 General . 58
ETSI
3GPP TS 23.167 version 16.4.0 Release 16 5 ETSI TS 123 167 V16.4.0 (2021-07)
K.2 Functional description . 58
K.2.1 General . 58
K.2.2 P-CSCF . 58
K.2.3 PCRF or PCF . 58
K.2.4 PGW or SMF/UPF . 58
K.2.4 HSS or UDM . 59
K.3 IMS Emergency Registration and Session Establishment . 59
K.4 Non UE detectable Emergency Session . 61
Annex L (normative): IMS emergency services using non-3GPP access to 5GC . 62
L.1 General . 62
L.2 UE specific behaviour . 62
L.3 High Level Procedures for IMS emergency calls . 63
L.4 Location handling . 64
Annex M (informative): Change history . 65
History . 67

ETSI
3GPP TS 23.167 version 16.4.0 Release 16 6 ETSI TS 123 167 V16.4.0 (2021-07)
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.
In the present document, modal verbs have the following meanings:
shall indicates a mandatory requirement to do something
shall not indicates an interdiction (prohibition) to do something
The constructions "shall" and "shall not" are confined to the context of normative provisions, and do not appear in
Technical Reports.
The constructions "must" and "must not" are not used as substitutes for "shall" and "shall not". Their use is avoided
insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced,
non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a
referenced document.
should indicates a recommendation to do something
should not indicates a recommendation not to do something
may indicates permission to do something
need not indicates permission not to do something
The construction "may not" is ambiguous and is not used in normative elements. The unambiguous constructions
"might not" or "shall not" are used instead, depending upon the meaning intended.
can indicates that something is possible
cannot indicates that something is impossible
The constructions "can" and "cannot" are not substitutes for "may" and "need not".
will indicates that something is certain or expected to happen as a result of action taken by an agency
the behaviour of which is outside the scope of the present document
will not indicates that something is certain or expected not to happen as a result of action taken by an
agency the behaviour of which is outside the scope of the present document
might indicates a likelihood that something will happen as a result of action taken by some agency the
behaviour of which is outside the scope of the present document
ETSI
3GPP TS 23.167 version 16.4.0 Release 16 7 ETSI TS 123 167 V16.4.0 (2021-07)
might not indicates a likelihood that something will not happen as a result of action taken by some agency
the behaviour of which is outside the scope of the present document
In addition:
is (or any other verb in the indicative mood) indicates a statement of fact
is not (or any other negative verb in the indicative mood) indicates a statement of fact
The constructions "is" and "is not" do not indicate requirements.
ETSI
3GPP TS 23.167 version 16.4.0 Release 16 8 ETSI TS 123 167 V16.4.0 (2021-07)
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".
ETSI
3GPP TS 23.167 version 16.4.0 Release 16 9 ETSI TS 123 167 V16.4.0 (2021-07)
[9] IETF RFC 3825: "Dynamic Host Configuration Protocol Option for Coordinate-based Location
Configuration Information".
[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".
ETSI
3GPP TS 23.167 version 16.4.0 Release 16 10 ETSI TS 123 167 V16.4.0 (2021-07)
[36] ETSI TS 181 019 V2.0.0: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Business Communication Requirements".
[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 29.328: "IP 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.
ETSI
3GPP TS 23.167 version 16.4.0 Release 16 11 ETSI TS 123 167 V16.4.0 (2021-07)
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).
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
ETSI
3GPP TS 23.167 version 16.4.0 Release 16 12 ETSI TS 123 167 V16.4.0 (2021-07)
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].
For the purposes of the present document, the following terms and definitions 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 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).
ETSI
3GPP TS 23.167 version 16.4.0 Release 16 13 ETSI TS 123 167 V16.4.0 (2021-07)
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). 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
...