SIST ES 203 283 V1.1.1:2018
(Main)Protocol specifications for Emergency Service Caller Location determination and transport
Protocol specifications for Emergency Service Caller Location determination and transport
The present document describes the protocol specifications for emergency service caller location determination and
transport architecture as specified in ETSI ES 203 178 [1].
Specifikacije protokolov službe za nujno pomoč za ugotavljanje lokacije klicatelja in za prevoz
V tem dokumentu so opisane specifikacije protokola za ugotavljanje lokacije klicatelja storitve za pomoč v sili in transportne arhitekture, kot je določeno v standardu ETSI ES 203 178 [1].
General Information
Standards Content (Sample)
Final draft ETSI ES 203 283 V1.1.0 (2017-09)
ETSI STANDARD
Protocol specifications for Emergency Service
Caller Location determination and transport
2 Final draft ETSI ES 203 283 V1.1.0 (2017-09)
Reference
DES/NTECH-00025-M493-protocols
Keywords
emergency, location, VoIP
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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 only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
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 2017.
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
3GPP and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
GSM® and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 Final draft ETSI ES 203 283 V1.1.0 (2017-09)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 8
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 10
4 Descriptions and assumptions . 11
4.1 Introduction . 11
5 Protocol specifications for the interfaces of the functional architecture in ETSI ES 203 178 . 12
5.1 Interface ia . 12
5.2 Interface ib. 12
5.2.1 Protocol specifications . 12
5.2.2 IMS/NGN implementation considerations . 12
5.3 Interface ic . 13
5.3.1 Protocol specifications . 13
5.3.1.1 General . 13
5.3.1.2 Location request without pre-established relationship between VSP and ANP . 13
5.3.1.3 Location request in the case of pre-established relationship between VSP and ANP . 15
5.3.1.4 Location request to a gateway mobile location centre . 17
5.3.2 IMS implementation considerations . 17
5.4 Interface id. 18
5.4.1 Protocol specifications . 18
5.4.2 IMS implementation considerations . 18
5.5 Interface ie . 18
5.5.1 Protocol specifications . 18
5.5.2 IMS implementation considerations . 21
5.6 Interface if . 22
5.6.1 Protocol specifications . 22
5.6.2 IMS/NGN implementation considerations . 24
5.7 Interface ig. 24
5.7.1 Protocol specifications . 24
5.7.2 IMS implementation considerations . 24
5.8 Interface ih. 25
5.8.1 Protocol specifications . 25
5.8.2 IMS implementation considerations . 27
5.9 Interface ii . 27
5.9.1 Protocol specifications . 27
5.9.2 IMS implementation considerations . 28
5.10 Interface ij . 28
5.10.1 Protocol specifications . 28
5.10.2 IMS/NGN implementation considerations . 30
5.11 Interface ik. 30
5.11.1 Protocol specifications . 30
5.11.2 IMS/NGN implementation considerations . 31
5.12 Interface il . 31
5.12.1 Protocol specifications . 31
5.12.2 IMS implementation considerations . 32
5.13 Interface im . 32
5.13.1 Protocol specifications . 32
5.13.2 IMS implementation considerations . 33
ETSI
4 Final draft ETSI ES 203 283 V1.1.0 (2017-09)
5.14 Interface in. 33
5.14.1 Protocol specifications . 33
5.14.2 IMS implementation considerations . 34
6 Functional entities . 34
6.1 UE . 34
6.2 Location Server . 34
6.3 LS Discovery . 34
6.4 VSP Call Control . 35
6.5 Emergency Service Routing Function (ESRF) . 35
6.5.1 Retrieval of the PSAP URI . 35
6.5.2 Additional functionalities of the ESRF . 36
6.5.3 Privacy considerations . 36
6.6 LS Proxy . 36
6.7 Emergency Service Routing Proxy (ESRP) . 37
6.8 Route Server . 37
6.9 IP-PSAP . 37
6.10 PSTN-PSAP . 37
7 Protocol registration requirements . 37
7.1 General . 37
7.2 ProviderIDseries . 37
7.3 ProviderID . 38
History . 39
ETSI
5 Final draft ETSI ES 203 283 V1.1.0 (2017-09)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to the present document 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 final draft ETSI Standard (ES) has been produced by ETSI Technical Committee Network Technologies
(NTECH), and is now submitted for the ETSI standards Membership Approval Procedure.
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
6 Final draft ETSI ES 203 283 V1.1.0 (2017-09)
1 Scope
The present document describes the protocol specifications for emergency service caller location determination and
transport architecture as specified in ETSI ES 203 178 [1].
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI ES 203 178: "Functional architecture to support European requirements on emergency caller
location determination and transport".
[2] OMA-TS-MLP-V3_5: "Mobile Location Protocol Version 3.5".
NOTE: Available at http://www.openmobilealliance.org/release/MLS/V1_4-20150224-C/OMA-TS-MLP-V3_5-
20150224-C.pdf.
[3] IETF RFC 3261: "SIP: Session Initiation Protocol".
[4] IETF RFC 4320: "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP)
Non-INVITE Transaction".
[5] IETF RFC 5393: "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP)
Forking Proxies".
[6] IETF RFC 5954: "Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261".
[7] IETF RFC 6442: "Location Conveyance for the Session Initiation Protocol".
[8] IETF RFC 4566: "SDP: Session Description Protocol".
[9] IETF RFC 3264: "An Offer/Answer Model with the Session Description Protocol (SDP)".
[10] ETSI TS 124 229: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; IP multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3
(3GPP TS 24.229)".
[11] ETSI TS 129 165: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Inter-IMS Network to Network Interface
(NNI) (3GPP TS 29.165)".
[12] ETSI TS 123 167: "Universal Mobile Telecommunications System (UMTS); LTE; IP Multimedia
Subsystem (IMS) emergency sessions (3GPP TS 23.167)".
[13] ETSI ES 283 035: "Network Technologies (NTECH); Network Attachment; e2 interface based on
the DIAMETER protocol".
ETSI
7 Final draft ETSI ES 203 283 V1.1.0 (2017-09)
[14] ETSI TS 129 163: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Interworking between the IP Multimedia
(IM) Core Network (CN) subsystem and Circuit Switched (CS) networks (3GPP TS 29.163)".
[15] IETF RFC 4119: "A Presence-based GEOPRIV Location Object Format".
[16] IETF RFC 5139: "Revised Civic Location Format for Presence Information Data Format Location
Object (PIDF-LO)".
[17] IETF RFC 5491: "GEOPRIV Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations".
[18] IETF RFC 6848: "Specifying Civic Address Extensions in the Presence Information Data Format
Location Object (PIDF-LO)".
[19] IETF RFC 7216: "Location Information Server (LIS) Discovery Using IP Addresses and Reverse
DNS".
[20] IETF RFC 5985: "HTTP-Enabled Location Delivery (HELD)".
[21] IETF RFC 5986: "Discovering the Local Location Information Server (LIS)".
[22] IETF RFC 6155: "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)".
[23] IETF RFC 6915: "Flow Identity Extension for HTTP-Enabled Location Delivery (HELD)".
[24] IETF RFC 7840: "A Routing Request Extension for the HTTP-Enabled Location Delivery
(HELD) Protocol".
[25] IETF RFC 6753: "A Location Dereference Protocol Using HTTP-Enabled Location Delivery
(HELD)".
[26] IETF RFC 5031: "A Uniform Resource Name (URN) for Emergency and Other Well-Known
Services".
[27] IETF RFC 6881: "Best Current Practice for Communications Services in Support of Emergency
Calling".
[28] IETF RFC 3325: "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks".
[29] IETF RFC 7852: "Additional Data Related to an Emergency Call".
[30] IETF RFC 3323: "A Privacy Mechanism for the Session Initiation Protocol (SIP)".
[31] IETF RFC 5079: "Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)".
[32] Recommendation ITU-T Q.850 (1998) Amd. 1 (07/2001): "Usage of cause and location in the
Digital Subscriber Signalling System No. 1 (DSS1) and the Signalling System No. 7 ISDN user
part (ISUP), Amendment 1".
[33] ETSI TS 124 525: "Universal Mobile Telecommunications System (UMTS); LTE; Business
trunking; Architecture and functional description (3GPP TS 24.525)".
[34] ETSI EN 300 899-1 (V1.1.2) (09-1998): "Integrated Services Digital Network (ISDN); Signalling
System No.7; Interworking between ISDN User Part (ISUP) version 2 and Digital Subscriber
Signalling System No. one (DSS1); Part 1: Protocol specification [ITU-T Recommendation Q.699,
modified]".
[35] IETF RFC 7163: "URN for Country-Specific Emergency Services".
[36] draft-winterbottom-sipcore-locparam-01 (May 2017): "Location Source Parameter for the SIP
Geolocation Header Field".
ETSI
8 Final draft ETSI ES 203 283 V1.1.0 (2017-09)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI ES 282 001: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN Functional Architecture".
[i.2] IETF RFC 3825: "Dynamic Host Configuration Protocol Option for Coordinate-based Location
Configuration Information".
[i.3] IETF RFC 6225: "Dynamic Host Configuration Protocol Options for Coordinate-Based Location
Configuration Information".
[i.4] ETSI TS 123 228: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; IP Multimedia Subsystem (IMS); Stage 2
(3GPP TS 23.228)".
[i.5] ETSI TS 123 032: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); Universal Geographical Area Description (GAD)
(3GPP TS 23.032)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
access network: portion of the telecommunications network that provides access to the switching function and
terminates the user access signalling
Access Network Provider (ANP): service provider that provides physical and IP connectivity to a user equipment
(UE) via a fixed or mobile access
NOTE: The access network may be provided by a single organization or it may be provided by a number of
different organizations, BUT the interfaces between these organizations are not relevant to the scope of
the present document as it is matter of contractual relations between the parties.
default PSAP: PSAP that is routed to when insufficient information exists to route to a specific PSAP, based on either
location or emergency category
emergency: urgent need for assistance or relief
emergency call: call from a user to an emergency call centre, PSAP or similar agency charged with routeing calls to the
relevant emergency response organization
emergency call facilities: mechanisms provided by public or private communications networks, emergency telephone
stanchions/boxes, fire alarms, etc. the use of which enables emergency calls to be made
Emergency Call Service Provider (ECSP): service provider that acts as a mediator between the voice service
providers and the public safety answering point service providers
emergency caller: individual placing an emergency call to reach the suitable PSAP
ETSI
9 Final draft ETSI ES 203 283 V1.1.0 (2017-09)
emergency category: differentiator for a specific emergency service type
NOTE: Examples of emergency service types are ambulance, police, fire brigade, etc.
emergency response organization: local or national force established to provide assistance to citizens in the event of
their being involved in an emergency situation and requiring specialized help
EXAMPLE: The police, fire service and emergency medical services.
emergency service: service that provides immediate and rapid assistance in situations where there is a direct risk to life
or limb, individual or public health or safety, to private or public property, or the environment but not necessarily
limited to these situations
emergency situation: abnormal situation of serious nature that develops suddenly and unexpectedly, of which the
evolution is uncertain and which may turn into a crisis or cause damage and casualties
Location-by-Reference: representing location information indirectly using a location URI
Location-by-Value: using location information in the form of a location object (LO), such as a PIDF-LO
location information: location value, and/or a location identifier and/or a location reference
location identifier: public network identifier, which provides a location value
EXAMPLE: A cell ID or line ID (see ETSI TS 123 167 [12]).
NOTE: A location value can be obtained from a location identifier by applying a static mapping or the location
identifier may be encoded in such a way that it contains a location value (e.g. a ZIP code).
location reference: identifies a location server and provides sufficient information to allow the location server to
provide the location value for the UE
EXAMPLE: https://ls.example.com:49152/uri/w3g61nf5n66p0, IETF RFC 6753 [25].
location URI: identifier that serves as a reference to location information which is later used as input by a dereference
protocol to retrieve location information
location value: civic or geodetic position
network-provided location information: any location information pertaining to the calling device that is determined,
provided or verified by the ANP
Next Generation Network (NGN): packet-based network able to provide telecommunication services and able to
make use of multiple broadband, QoS-enabled transport technologies and in which service-related functions are
independent from underlying transport-related technologies
nomadic: having the ability to move across network access points
NOTE: A nomadic user can make calls from different locations. However, unlike a mobile user, the location of a
nomadic user cannot change during a specific call.
originating network: access network in which the emergency call was placed
PSAP address: URI or an E.164 number identifying a PSAP or a group of PSAPs
PSAP Service Provider (PSP): service provider that provides connectivity to Public Safety Answering Points (PSAPs)
and directs emergency calls from the ECSP to the PSAP
Public Safety Answering Point (PSAP): physical location where emergency calls are received under the responsibility
of a public authority
regulatory domain: geographical area where a set of regulatory rules applies
telecommunication: any transmission, emission, or reception of signs, signals, writing, images, sounds or intelligence
of any nature, by wire, radio, optical fibre or other electromagnetic system
ETSI
10 Final draft ETSI ES 203 283 V1.1.0 (2017-09)
user access: point of connection to a telecommunication network from which a call can be placed
NOTE: This includes public telephones and "emergency call facilities".
user equipment: device allowing a user access to network services
user-provided location information: any location information originating from user-equipment that is not
independently verified by the ANP
Voice Service Provider (VSP): specific type of application service provider that provides voice related services and
optionally text and video-related services, on IP
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AF Application Function
ANP Access Network Provider
APRI Address Presentation Restriction Indicator
AVP Attribute-Value-Pair
CID Content ID
CLF Connectivity session Location and repository Function
DNS Domain Name Server
EC European Commission
E-CSCF Emergency-Call Session Control Function
ECSP Emergency Call Service Provider
ESRF Emergency Service Routing Function
ESRP Emergency Service Routeing Proxy
ETSI European Telecommunications Standards Institute
EU European Union
FQDN Fully Qualified Domain Name
GAD Universal Geographical Area Description
GMLC Gateway Mobile Location Centre
HELD HTTP Enabled Location Delivery
HTTPS Hypertext Transfer Protocol Secure
IANA Internet Assigned Numbers Authority
IBCF Interconnection Border Control Function
IE Information Element
IETF Internet Engineering Task Force
II-NNI Inter-IMS Network to Network Interface
IMS IP Multimedia Core Network Subsystem
IP Internet Protocol
ISUP ISDN User Part
ITU-T International Telecommunications Union - Telecommunications
LbyR Location-by-Reference
LbyV Location-by-Value
LRF Location Retrieval Function
LS Location Server
MLP Mobile Location Protocol
NAPTR Naming Authority PoinTeR
NGN Next Generation Network
OMA Open Mobile Alliance
P-CSCF Proxy-Call Session Control Function
PSAP Public Safety Answering Point
PSP PSAP Service Provider
PSTN Public Switched Telephone Network
RDF Routeing Determination Function
RFC Request For Comment
SIP Session Initiation Protocol
SIPS Session Initiation Protocol Secure
UA User Agent
UE User Equipment
ETSI
11 Final draft ETSI ES 203 283 V1.1.0 (2017-09)
URI Uniform Resource Identifier
URL Uniform Resource Locator
URN Uniform Resource Name
VAE VSP Aggregating Entity
VAP VSP Aggregation Provider
VoIP Voice over Internet Protocol
VSP Voice Service Provider
4 Descriptions and assumptions
4.1 Introduction
ETSI ES 203 178 [1] defines the interfaces between functional entities in the functional architecture to support
European requirements on emergency caller location determination and transport, and places requirements on each of
these interfaces. However, it does not specify what protocols are available or might be used to implement the required
functionality across each of the interfaces. The present document matches interfaces with existing protocols and where
gaps exist clearly indicates what the gaps are.
Table 4.1 summarizes the interfaces defined in ETSI ES 203 178 [1] and categorizes them as being either in scope or
out of scope for the present document. Interfaces deemed as "In Scope" have specific clauses detailing how to achieve
the functionality specified in ETSI ES 203 178 [1]. The details may refer to other specification, profile or extend
existing protocols, or define new protocols. Interfaces deemed "Out of Scope" do not have detailed specifications
provided in the present document.
Table 4.1: Categories of Interfaces defined in ETSI ES 203 178 [1]
st nd
Interface Scope
1 endpoint 2 endpoint
ia User equipment VSP Call Control Out of scope
ib VSP Call Control LS Discovery In scope
ic VSP Call Control Location Server In scope
id Location Server Route Server In scope
ie VSP Call Control/VAE VAE/ESRF In scope
if ESRF/LS-Proxy Location Server In scope
ig ESRF Route Server In scope
ih ESRF ESRP In scope
ii ESRP PSTN-PSAP In scope
ij ESRP IP-PSAP In scope
ik PSTN-PSAP ESRF/LS-Proxy In scope
il IP-PSAP Location Server In scope
im IP-PSAP ESRF/LS-Proxy In scope
in ESRF LS-Proxy In scope
As is stated in ETSI ES 203 178 [1], some interfaces in the architecture are between functional entities belonging to
different operators or providers and, as a consequence, these interfaces have interoperability requirements and shall be
implemented following the present document by the related connected functional entities. The protocol selection for
these interfaces can impose requirements on provider internal functionalities and some provider internal interfaces; the
definition of these requirements is however outside the scope of the present document.
The EC standardisation mandate M/493 (see ETSI ES 203 178 [1], annex B) demands that "this work shall not be
focused on NGN but shall address current implementations for all types of voice calls (fixed, mobile, static and
nomadic VoIP) in EU countries". Consequently, the functional architecture is intended to be compatible with
IMS-based deployments and specifications regarding emergency services provision. The present document includes
statements on IMS/NGN implementation considerations per interface.
IMS considerations can include statements regarding the IMS protocol assignment, parameterization and control plane
interworking.
ETSI
12 Final draft ETSI ES 203 283 V1.1.0 (2017-09)
The interfaces ia, ib, ic and ie are external, which means between country A and anywhere and (with the exception of
ia) are specified in detail to ensure that all VSPs and VAPs can participate in the processes for emergency service caller
location determination and transport based on the architecture of ETSI ES 203 178 [1] within country A.
The interfaces id, if, ig, ih, ii, ij, ik, il, im and in are internal, inside country A, and should be specified considering the
existing national implementations and regulations in country A. When other protocols are used care is to be taken that
all information elements outlined in the architecture are covered.
5 Protocol specifications for the interfaces of the
functional architecture in ETSI ES 203 178
5.1 Interface ia
The protocol used on the interface ia is determined by the VSP only and is therefore out of scope for the present
document.
5.2 Interface ib
5.2.1 Protocol specifications
The ib interface defines the interactions between the VSP call control and the LS discovery functional entity. The VSP
call control uses the public IP address of the UE to interrogate the LS discovery functional entity in order to obtain the
address of the LS serving the access network to which the UE is attached. Since this function is expected to be
accessible to any VSP anywhere, this is an open interface.
If a pre-established relationship exists between the ANP and the VSP then DNS may be used for the LS discovery
function. The first part of this discovery process in IETF RFC 7216 [19] yields the domain name of the serving access
network. If the VSP knows the address of the LS for the serving ANP, then no further discovery is required, otherwise
an additional DNS query may be used.
If no pre-established relationship exists between the VSP and the ANP then the LS Discovery function shall use the
Domain Name Service (DNS). The VSP requires the URL of the LS serving the access network to which the UE is
attached. The URL shall be a HELD URI (IETF RFC 5985 [20]). The URL discovery shall perform the U-NAPTR
procedures defined in sections 2 and 4 of IETF RFC 5986 [21] with the following variations:
• the domain shall be known as a result of having performed the steps in IETF RFC 7216 [19]; and
• the device based interfaces are irrelevant as discovery is performed by a third-party, i.e. the VSP; and
• the process stops once the URL for the LS has been resolved based on the steps in section 4 of IETF
RFC 5986 [21].
5.2.2 IMS/NGN implementation considerations
This interface is between the VSP call control and the LS Discovery functionality.
This interface is not part of the IMS architecture as specified in ETSI TS 123 228 [i.4] and it is not part of the NGN
architecture as specified in ETSI ES 282 001 [i.1].
ETSI
13 Final draft ETSI ES 203 283 V1.1.0 (2017-09)
5.3 Interface ic
5.3.1 Protocol specifications
5.3.1.1 General
Depending on the pre-established relationship the VSP call control can use interface ic to request location and routeing
information from the location server. The following clauses differentiate cases where a pre-established relationship
between entities exists or not.
When the ANP trusts the VSP, and the VSP has been given knowledge of this trust by prior agreement, then
clauses 5.3.1.3 or 5.3.1.4 can be used to request location. Clause 5.3.1.4 can only be used when the ANP provides a
gateway mobile location centre (GMLC).
Otherwise clause 5.3.1.2 shall be used.
5.3.1.2 Location request without pre-established relationship between VSP and ANP
Where no pre-established relationship exists between the VSP and the ANP then the HELD protocol (IETF
RFC 5985 [20]) shall be used by the VSP to acquire location from the LS. The VSP shall use IP address and port
information in the HELD request to the LS using HELD device identity extensions defined in IETF RFC 6155 [22].
Where the VSP has the full IP flow identity information available then it shall use the IP flow identity definitions in
IETF RFC 6915 [23]. The VSP shall set:
• the locationType to "any"; and
• the exact attribute to "false"; and
• the responseTime to "emergencyRouting".
The VSP includes a request for routeing information as described in IETF RFC 7840 [24]. The VSP shall not set the
service attribute in the routeing request unless the UE has identified a specific service to the VSP over ia. If the service
attribute is set then its value shall be identical to the value provided by the UE.
If the LS has no pre-established relationship with the VSP then the LS shall not return a location value but shall return a
location reference in the form of a location URI using the HTTPS URI schemes.
If the HELD request to the LS includes request for routeing information then the LS shall provide routeing information
in accordance with IETF RFC 7840 [24] in the location response message.
NOTE: The HELD protocol does not define explicitly the transport of location identifiers as specified in ETSI
ES 203 178 [1]. In order for HELD to convey these items without modification, location identifiers would
need to be encoded as some kind of URI.
Tables 5.1 and 5.2 describe the elements used for the HELD location request and location response via the ic interface.
In table 5.1 column 1 represents the element name of the HELD protocol. Column 2 indicates the status of this element
(mandatory, conditional or optional). Column 3 describes additional requirements and the mapping of the element to the
information element (IE) in ETSI ES 203 178 [1]. Column 4 specifies the permitted values for the element in column 1.
ETSI
14 Final draft ETSI ES 203 283 V1.1.0 (2017-09)
Table 5.1: HELD Location Request
HELD Element Name Status in HELD Description and related Value
ETSI ES 203 178 [1] Information element
with (Status in ETSI ES 203 178 [1])
responseTime M The time in which the requesting entity would emergencyRouting
like a response in ms. LS defined values for
emergencyRouting and emergencyDispatch
can also be used
Not defined in ETSI ES 203 178 [1].
requestRoutingInformation M Allows the requesting entity to request routing Empty or
information urn:service:sos or
ETSI ES 203 178 [1]: Routing request (O). urn:servive:sos with a
subtype
locationType M Specifies the form that the requesting entity
any
would like the location to come in.
Not defined in ETSI ES 203 178 [1].
exact M Specifies whether the server returns an error if false
the requested locationType is not available.
Not defined in ETSI ES 203 178 [1].
device C The VSP call control shall provide a device IP address (+ port)
identifier to specify IP address and port if a
complete IP flow is not available.
The VSP call control may include device
identity information in addition to the complete
IP flow being available.
The structure and format of device identifiers
shall comply with the provisions in IETF
RFC 6155 [22].
The LS shall only use the device information if
it is unable to identify the device based on flow
information.
flow C The VSP call control shall provide the IP flow Source IP address +
between the source and destination if port
available as specified in IETF RFC 6915 [23]. and
The LS shall try to determine the location of Destination IP address
the device using the full IP flow information if + port
possible.
The LS may use information provided in the
device element if IP flow information is not
provided or is insufficient to allow device
location to be determined.
ETSI ES 203 178 [1]: Calling IP address and
port (M).
In table 5.2 column 1 represents the element name of the HELD protocol. Column 2 indicates the status of this element
(mandatory, conditional or optional). Column 3 describes additional requirements and the mapping of the element to the
information element (IE) in ETSI ES 203 178 [1]. Column 4 specifies the permitted values for the element in column 1.
ETSI
15 Final draft ETSI ES 203 283 V1.1.0 (2017-09)
Table 5.2: HELD Location Response
HELD Element Status in Description and related Value
Name HELD ETSI ES 203 178 [1] Information element
with (Status in ETSI ES 203 178 [1])
locationUriSet C If the location response from the location locationURI,
server has either a location reference or a expires
location identifier to return the locationUriSet
parameter shall be present in the response.
ETSI ES 203 178 [1]: Network-provided
location information (M)
Presence C If the location server needs to return a Location-info
location value, either civic, geodetic or both, (PIDF-LO)
then the Presence element shall be present.
ETSI ES 203 178 [1]: Network-provided
location information (M)
routingInformation C If the locationRequest included a
requestRoutingInformation attribute, then
the response shall contain sip:112@example.com
routingInformation (and
ETSI ES 203 178 [1]: ESRF URI (C)
sips:112@example.com)
xmpp:112@example.com
(see note)
NOTE: For the dest field, a SIP URI shall be used. A SIPS URI may be used in addition to the SIP URI. If the VSP is
able to route the SIPS URI destination, then the SIPS URI should be used to enhance security.
5.3.1.3 Location request in the case of pre-established relationship between VSP
and ANP
When the ANP trusts the VSP, and the VSP has been given knowledge of this trust by prior agreement the protocol
defined in ETSI ES 283 035 [13] may be used between the VSP and the LS as an alternative to the HELD protocol
(IETF RFC 5985 [20]). In case the HELD protocol is used, tables 5.1 and 5.2 apply with the exception that the LS can
return a location value.
NOTE: No explicit LS discovery mechanism exists for this option so the relationship between the entities needs
to include how the VSP identifies the corresponding LS.
ETSI ES 2
...
ETSI STANDARD
Protocol specifications for Emergency Service
Caller Location determination and transport
2 ETSI ES 203 283 V1.1.1 (2017-11)
Reference
DES/NTECH-00025-M493-protocols
Keywords
emergency, location, VoIP
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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 only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
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 2017.
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
3GPP and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
GSM® and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI ES 203 283 V1.1.1 (2017-11)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 8
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 10
4 Descriptions and assumptions . 11
4.1 Introduction . 11
5 Protocol specifications for the interfaces of the functional architecture in ETSI ES 203 178 . 12
5.1 Interface ia . 12
5.2 Interface ib. 12
5.2.1 Protocol specifications . 12
5.2.2 IMS/NGN implementation considerations . 12
5.3 Interface ic . 13
5.3.1 Protocol specifications . 13
5.3.1.1 General . 13
5.3.1.2 Location request without pre-established relationship between VSP and ANP . 13
5.3.1.3 Location request in the case of pre-established relationship between VSP and ANP . 15
5.3.1.4 Location request to a gateway mobile location centre . 17
5.3.2 IMS implementation considerations . 17
5.4 Interface id. 18
5.4.1 Protocol specifications . 18
5.4.2 IMS implementation considerations . 18
5.5 Interface ie . 18
5.5.1 Protocol specifications . 18
5.5.2 IMS implementation considerations . 21
5.6 Interface if . 22
5.6.1 Protocol specifications . 22
5.6.2 IMS/NGN implementation considerations . 24
5.7 Interface ig. 24
5.7.1 Protocol specifications . 24
5.7.2 IMS implementation considerations . 24
5.8 Interface ih. 25
5.8.1 Protocol specifications . 25
5.8.2 IMS implementation considerations . 27
5.9 Interface ii . 28
5.9.1 Protocol specifications . 28
5.9.2 IMS implementation considerations . 28
5.10 Interface ij . 28
5.10.1 Protocol specifications . 28
5.10.2 IMS/NGN implementation considerations . 30
5.11 Interface ik. 30
5.11.1 Protocol specifications . 30
5.11.2 IMS/NGN implementation considerations . 31
5.12 Interface il . 32
5.12.1 Protocol specifications . 32
5.12.2 IMS implementation considerations . 32
5.13 Interface im . 33
5.13.1 Protocol specifications . 33
5.13.2 IMS implementation considerations . 33
ETSI
4 ETSI ES 203 283 V1.1.1 (2017-11)
5.14 Interface in. 34
5.14.1 Protocol specifications . 34
5.14.2 IMS implementation considerations . 34
6 Functional entities . 34
6.1 UE . 34
6.2 Location Server . 34
6.3 LS Discovery . 35
6.4 VSP Call Control . 35
6.5 Emergency Service Routing Function (ESRF) . 35
6.5.1 Retrieval of the PSAP URI . 35
6.5.2 Additional functionalities of the ESRF . 36
6.5.3 Privacy considerations . 36
6.6 LS Proxy . 36
6.7 Emergency Service Routing Proxy (ESRP) . 37
6.8 Route Server . 37
6.9 IP-PSAP . 37
6.10 PSTN-PSAP . 37
7 Protocol registration requirements . 37
7.1 General . 37
7.2 ProviderIDseries . 37
7.3 ProviderID . 38
History . 39
ETSI
5 ETSI ES 203 283 V1.1.1 (2017-11)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to the present document 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 ETSI Standard (ES) has been produced by ETSI Technical Committee Network Technologies (NTECH).
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
6 ETSI ES 203 283 V1.1.1 (2017-11)
1 Scope
The present document describes the protocol specifications for emergency service caller location determination and
transport architecture as specified in ETSI ES 203 178 [1].
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI ES 203 178: "Functional architecture to support European requirements on emergency caller
location determination and transport".
[2] OMA-TS-MLP-V3_5: "Mobile Location Protocol Version 3.5".
NOTE: Available at http://www.openmobilealliance.org/release/MLS/V1_4-20150224-C/OMA-TS-MLP-V3_5-
20150224-C.pdf.
[3] IETF RFC 3261: "SIP: Session Initiation Protocol".
[4] IETF RFC 4320: "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP)
Non-INVITE Transaction".
[5] IETF RFC 5393: "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP)
Forking Proxies".
[6] IETF RFC 5954: "Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261".
[7] IETF RFC 6442: "Location Conveyance for the Session Initiation Protocol".
[8] IETF RFC 4566: "SDP: Session Description Protocol".
[9] IETF RFC 3264: "An Offer/Answer Model with the Session Description Protocol (SDP)".
[10] ETSI TS 124 229: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; IP multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3
(3GPP TS 24.229)".
[11] ETSI TS 129 165: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Inter-IMS Network to Network Interface
(NNI) (3GPP TS 29.165)".
[12] ETSI TS 123 167: "Universal Mobile Telecommunications System (UMTS); LTE; IP Multimedia
Subsystem (IMS) emergency sessions (3GPP TS 23.167)".
[13] ETSI ES 283 035: "Network Technologies (NTECH); Network Attachment; e2 interface based on
the DIAMETER protocol".
ETSI
7 ETSI ES 203 283 V1.1.1 (2017-11)
[14] ETSI TS 129 163: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Interworking between the IP Multimedia
(IM) Core Network (CN) subsystem and Circuit Switched (CS) networks (3GPP TS 29.163)".
[15] IETF RFC 4119: "A Presence-based GEOPRIV Location Object Format".
[16] IETF RFC 5139: "Revised Civic Location Format for Presence Information Data Format Location
Object (PIDF-LO)".
[17] IETF RFC 5491: "GEOPRIV Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations".
[18] IETF RFC 6848: "Specifying Civic Address Extensions in the Presence Information Data Format
Location Object (PIDF-LO)".
[19] IETF RFC 7216: "Location Information Server (LIS) Discovery Using IP Addresses and Reverse
DNS".
[20] IETF RFC 5985: "HTTP-Enabled Location Delivery (HELD)".
[21] IETF RFC 5986: "Discovering the Local Location Information Server (LIS)".
[22] IETF RFC 6155: "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)".
[23] IETF RFC 6915: "Flow Identity Extension for HTTP-Enabled Location Delivery (HELD)".
[24] IETF RFC 7840: "A Routing Request Extension for the HTTP-Enabled Location Delivery
(HELD) Protocol".
[25] IETF RFC 6753: "A Location Dereference Protocol Using HTTP-Enabled Location Delivery
(HELD)".
[26] IETF RFC 5031: "A Uniform Resource Name (URN) for Emergency and Other Well-Known
Services".
[27] IETF RFC 6881: "Best Current Practice for Communications Services in Support of Emergency
Calling".
[28] IETF RFC 3325: "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks".
[29] IETF RFC 7852: "Additional Data Related to an Emergency Call".
[30] IETF RFC 3323: "A Privacy Mechanism for the Session Initiation Protocol (SIP)".
[31] IETF RFC 5079: "Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)".
[32] Recommendation ITU-T Q.850 (1998) Amd. 1 (07/2001): "Usage of cause and location in the
Digital Subscriber Signalling System No. 1 (DSS1) and the Signalling System No. 7 ISDN user
part (ISUP), Amendment 1".
[33] ETSI TS 124 525: "Universal Mobile Telecommunications System (UMTS); LTE; Business
trunking; Architecture and functional description (3GPP TS 24.525)".
[34] ETSI EN 300 899-1 (V1.1.2) (09-1998): "Integrated Services Digital Network (ISDN); Signalling
System No.7; Interworking between ISDN User Part (ISUP) version 2 and Digital Subscriber
Signalling System No. one (DSS1); Part 1: Protocol specification [ITU-T Recommendation Q.699,
modified]".
[35] IETF RFC 7163: "URN for Country-Specific Emergency Services".
[36] draft-winterbottom-sipcore-locparam-01 (May 2017): "Location Source Parameter for the SIP
Geolocation Header Field".
ETSI
8 ETSI ES 203 283 V1.1.1 (2017-11)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI ES 282 001: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN Functional Architecture".
[i.2] IETF RFC 3825: "Dynamic Host Configuration Protocol Option for Coordinate-based Location
Configuration Information".
[i.3] IETF RFC 6225: "Dynamic Host Configuration Protocol Options for Coordinate-Based Location
Configuration Information".
[i.4] ETSI TS 123 228: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; IP Multimedia Subsystem (IMS); Stage 2
(3GPP TS 23.228)".
[i.5] ETSI TS 123 032: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); Universal Geographical Area Description (GAD)
(3GPP TS 23.032)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
access network: portion of the telecommunications network that provides access to the switching function and
terminates the user access signalling
Access Network Provider (ANP): service provider that provides physical and IP connectivity to a user equipment
(UE) via a fixed or mobile access
NOTE: The access network may be provided by a single organization or it may be provided by a number of
different organizations, BUT the interfaces between these organizations are not relevant to the scope of
the present document as it is matter of contractual relations between the parties.
default PSAP: PSAP that is routed to when insufficient information exists to route to a specific PSAP, based on either
location or emergency category
emergency: urgent need for assistance or relief
emergency call: call from a user to an emergency call centre, PSAP or similar agency charged with routeing calls to the
relevant emergency response organization
emergency call facilities: mechanisms provided by public or private communications networks, emergency telephone
stanchions/boxes, fire alarms, etc. the use of which enables emergency calls to be made
Emergency Call Service Provider (ECSP): service provider that acts as a mediator between the voice service
providers and the public safety answering point service providers
emergency caller: individual placing an emergency call to reach the suitable PSAP
ETSI
9 ETSI ES 203 283 V1.1.1 (2017-11)
emergency category: differentiator for a specific emergency service type
NOTE: Examples of emergency service types are ambulance, police, fire brigade, etc.
emergency response organization: local or national force established to provide assistance to citizens in the event of
their being involved in an emergency situation and requiring specialized help
EXAMPLE: The police, fire service and emergency medical services.
emergency service: service that provides immediate and rapid assistance in situations where there is a direct risk to life
or limb, individual or public health or safety, to private or public property, or the environment but not necessarily
limited to these situations
emergency situation: abnormal situation of serious nature that develops suddenly and unexpectedly, of which the
evolution is uncertain and which may turn into a crisis or cause damage and casualties
Location-by-Reference: representing location information indirectly using a location URI
Location-by-Value: using location information in the form of a location object (LO), such as a PIDF-LO
location identifier: public network identifier, which provides a location value
EXAMPLE: A cell ID or line ID (see ETSI TS 123 167 [12]).
NOTE: A location value can be obtained from a location identifier by applying a static mapping or the location
identifier may be encoded in such a way that it contains a location value (e.g. a ZIP code).
location information: location value, and/or a location identifier and/or a location reference
location reference: identifies a location server and provides sufficient information to allow the location server to
provide the location value for the UE
EXAMPLE: https://ls.example.com:49152/uri/w3g61nf5n66p0, IETF RFC 6753 [25].
location URI: identifier that serves as a reference to location information which is later used as input by a dereference
protocol to retrieve location information
location value: civic or geodetic position
network-provided location information: any location information pertaining to the calling device that is determined,
provided or verified by the ANP
Next Generation Network (NGN): packet-based network able to provide telecommunication services and able to
make use of multiple broadband, QoS-enabled transport technologies and in which service-related functions are
independent from underlying transport-related technologies
nomadic: having the ability to move across network access points
NOTE: A nomadic user can make calls from different locations. However, unlike a mobile user, the location of a
nomadic user cannot change during a specific call.
originating network: access network in which the emergency call was placed
PSAP address: URI or an E.164 number identifying a PSAP or a group of PSAPs
PSAP Service Provider (PSP): service provider that provides connectivity to Public Safety Answering Points (PSAPs)
and directs emergency calls from the ECSP to the PSAP
Public Safety Answering Point (PSAP): physical location where emergency calls are received under the responsibility
of a public authority
regulatory domain: geographical area where a set of regulatory rules applies
telecommunication: any transmission, emission, or reception of signs, signals, writing, images, sounds or intelligence
of any nature, by wire, radio, optical fibre or other electromagnetic system
ETSI
10 ETSI ES 203 283 V1.1.1 (2017-11)
user access: point of connection to a telecommunication network from which a call can be placed
NOTE: This includes public telephones and "emergency call facilities".
user equipment: device allowing a user access to network services
user-provided location information: any location information originating from user-equipment that is not
independently verified by the ANP
Voice Service Provider (VSP): specific type of application service provider that provides voice related services and
optionally text and video-related services, on IP
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AF Application Function
ANP Access Network Provider
APRI Address Presentation Restriction Indicator
AVP Attribute-Value-Pair
CID Content ID
CLF Connectivity session Location and repository Function
DNS Domain Name Server
EC European Commission
E-CSCF Emergency-Call Session Control Function
ECSP Emergency Call Service Provider
ESRF Emergency Service Routing Function
ESRP Emergency Service Routeing Proxy
ETSI European Telecommunications Standards Institute
EU European Union
FQDN Fully Qualified Domain Name
GAD Universal Geographical Area Description
GMLC Gateway Mobile Location Centre
HELD HTTP Enabled Location Delivery
HTTPS Hypertext Transfer Protocol Secure
IANA Internet Assigned Numbers Authority
IBCF Interconnection Border Control Function
IE Information Element
IETF Internet Engineering Task Force
II-NNI Inter-IMS Network to Network Interface
IMS IP Multimedia Core Network Subsystem
IP Internet Protocol
ISUP ISDN User Part
ITU-T International Telecommunications Union - Telecommunications
LbyR Location-by-Reference
LbyV Location-by-Value
LRF Location Retrieval Function
LS Location Server
MLP Mobile Location Protocol
NAPTR Naming Authority PoinTeR
NGN Next Generation Network
OMA Open Mobile Alliance
P-CSCF Proxy-Call Session Control Function
PSAP Public Safety Answering Point
PSP PSAP Service Provider
PSTN Public Switched Telephone Network
RDF Routeing Determination Function
RFC Request For Comment
SIP Session Initiation Protocol
SIPS Session Initiation Protocol Secure
UA User Agent
UE User Equipment
ETSI
11 ETSI ES 203 283 V1.1.1 (2017-11)
URI Uniform Resource Identifier
URL Uniform Resource Locator
URN Uniform Resource Name
VAE VSP Aggregating Entity
VAP VSP Aggregation Provider
VoIP Voice over Internet Protocol
VSP Voice Service Provider
4 Descriptions and assumptions
4.1 Introduction
ETSI ES 203 178 [1] defines the interfaces between functional entities in the functional architecture to support
European requirements on emergency caller location determination and transport, and places requirements on each of
these interfaces. However, it does not specify what protocols are available or might be used to implement the required
functionality across each of the interfaces. The present document matches interfaces with existing protocols and where
gaps exist clearly indicates what the gaps are.
Table 4.1 summarizes the interfaces defined in ETSI ES 203 178 [1] and categorizes them as being either in scope or
out of scope for the present document. Interfaces deemed as "In Scope" have specific clauses detailing how to achieve
the functionality specified in ETSI ES 203 178 [1]. The details may refer to other specification, profile or extend
existing protocols, or define new protocols. Interfaces deemed "Out of Scope" do not have detailed specifications
provided in the present document.
Table 4.1: Categories of Interfaces defined in ETSI ES 203 178 [1]
st nd
Interface Scope
1 endpoint 2 endpoint
ia User equipment VSP Call Control Out of scope
ib VSP Call Control LS Discovery In scope
ic VSP Call Control Location Server In scope
id Location Server Route Server In scope
ie VSP Call Control/VAE VAE/ESRF In scope
if ESRF/LS-Proxy Location Server In scope
ig ESRF Route Server In scope
ih ESRF ESRP In scope
ii ESRP PSTN-PSAP In scope
ij ESRP IP-PSAP In scope
ik PSTN-PSAP ESRF/LS-Proxy In scope
il IP-PSAP Location Server In scope
im IP-PSAP ESRF/LS-Proxy In scope
in ESRF LS-Proxy In scope
As is stated in ETSI ES 203 178 [1], some interfaces in the architecture are between functional entities belonging to
different operators or providers and, as a consequence, these interfaces have interoperability requirements and shall be
implemented following the present document by the related connected functional entities. The protocol selection for
these interfaces can impose requirements on provider internal functionalities and some provider internal interfaces; the
definition of these requirements is however outside the scope of the present document.
The EC standardisation mandate M/493 (see ETSI ES 203 178 [1], annex B) demands that "this work shall not be
focused on NGN but shall address current implementations for all types of voice calls (fixed, mobile, static and
nomadic VoIP) in EU countries". Consequently, the functional architecture is intended to be compatible with
IMS-based deployments and specifications regarding emergency services provision. The present document includes
statements on IMS/NGN implementation considerations per interface.
IMS considerations can include statements regarding the IMS protocol assignment, parameterization and control plane
interworking.
ETSI
12 ETSI ES 203 283 V1.1.1 (2017-11)
The interfaces ia, ib, ic and ie are external, which means between country A and anywhere and (with the exception of
ia) are specified in detail to ensure that all VSPs and VAPs can participate in the processes for emergency service caller
location determination and transport based on the architecture of ETSI ES 203 178 [1] within country A.
The interfaces id, if, ig, ih, ii, ij, ik, il, im and in are internal, inside country A, and should be specified considering the
existing national implementations and regulations in country A. When other protocols are used care is to be taken that
all information elements outlined in the architecture are covered.
5 Protocol specifications for the interfaces of the
functional architecture in ETSI ES 203 178
5.1 Interface ia
The protocol used on the interface ia is determined by the VSP only and is therefore out of scope for the present
document.
5.2 Interface ib
5.2.1 Protocol specifications
The ib interface defines the interactions between the VSP call control and the LS discovery functional entity. The VSP
call control uses the public IP address of the UE to interrogate the LS discovery functional entity in order to obtain the
address of the LS serving the access network to which the UE is attached. Since this function is expected to be
accessible to any VSP anywhere, this is an open interface.
If a pre-established relationship exists between the ANP and the VSP then DNS may be used for the LS discovery
function. The first part of this discovery process in IETF RFC 7216 [19] yields the domain name of the serving access
network. If the VSP knows the address of the LS for the serving ANP, then no further discovery is required, otherwise
an additional DNS query may be used.
If no pre-established relationship exists between the VSP and the ANP then the LS Discovery function shall use the
Domain Name Service (DNS). The VSP requires the URL of the LS serving the access network to which the UE is
attached. The URL shall be a HELD URI (IETF RFC 5985 [20]). The URL discovery shall perform the U-NAPTR
procedures defined in sections 2 and 4 of IETF RFC 5986 [21] with the following variations:
• the domain shall be known as a result of having performed the steps in IETF RFC 7216 [19]; and
• the device based interfaces are irrelevant as discovery is performed by a third-party, i.e. the VSP; and
• the process stops once the URL for the LS has been resolved based on the steps in section 4 of IETF
RFC 5986 [21].
5.2.2 IMS/NGN implementation considerations
This interface is between the VSP call control and the LS Discovery functionality.
This interface is not part of the IMS architecture as specified in ETSI TS 123 228 [i.4] and it is not part of the NGN
architecture as specified in ETSI ES 282 001 [i.1].
ETSI
13 ETSI ES 203 283 V1.1.1 (2017-11)
5.3 Interface ic
5.3.1 Protocol specifications
5.3.1.1 General
Depending on the pre-established relationship the VSP call control can use interface ic to request location and routeing
information from the location server. The following clauses differentiate cases where a pre-established relationship
between entities exists or not.
When the ANP trusts the VSP, and the VSP has been given knowledge of this trust by prior agreement, then
clauses 5.3.1.3 or 5.3.1.4 can be used to request location. Clause 5.3.1.4 can only be used when the ANP provides a
gateway mobile location centre (GMLC).
Otherwise clause 5.3.1.2 shall be used.
5.3.1.2 Location request without pre-established relationship between VSP and ANP
Where no pre-established relationship exists between the VSP and the ANP then the HELD protocol (IETF
RFC 5985 [20]) shall be used by the VSP to acquire location from the LS. The VSP shall use IP address and port
information in the HELD request to the LS using HELD device identity extensions defined in IETF RFC 6155 [22].
Where the VSP has the full IP flow identity information available then it shall use the IP flow identity definitions in
IETF RFC 6915 [23]. The VSP shall set:
• the locationType to "any"; and
• the exact attribute to "false"; and
• the responseTime to "emergencyRouting".
The VSP includes a request for routeing information as described in IETF RFC 7840 [24]. The VSP shall not set the
service attribute in the routeing request unless the UE has identified a specific service to the VSP over ia. If the service
attribute is set then its value shall be identical to the value provided by the UE.
If the LS has no pre-established relationship with the VSP then the LS shall not return a location value but shall return a
location reference in the form of a location URI using the HTTPS URI schemes.
If the HELD request to the LS includes request for routeing information then the LS shall provide routeing information
in accordance with IETF RFC 7840 [24] in the location response message.
NOTE: The HELD protocol does not define explicitly the transport of location identifiers as specified in ETSI
ES 203 178 [1]. In order for HELD to convey these items without modification, location identifiers would
need to be encoded as some kind of URI.
Tables 5.1 and 5.2 describe the elements used for the HELD location request and location response via the ic interface.
In table 5.1 column 1 represents the element name of the HELD protocol. Column 2 indicates the status of this element
(mandatory, conditional or optional). Column 3 describes additional requirements and the mapping of the element to the
information element (IE) in ETSI ES 203 178 [1]. Column 4 specifies the permitted values for the element in column 1.
ETSI
14 ETSI ES 203 283 V1.1.1 (2017-11)
Table 5.1: HELD Location Request
HELD Element Name Status in HELD Description and related Value
ETSI ES 203 178 [1] Information element
with (Status in ETSI ES 203 178 [1])
responseTime M The time in which the requesting entity would emergencyRouting
like a response in ms. LS defined values for
emergencyRouting and emergencyDispatch
can also be used
Not defined in ETSI ES 203 178 [1].
requestRoutingInformation M Allows the requesting entity to request routing Empty or
information urn:service:sos or
ETSI ES 203 178 [1]: Routing request (O). urn:servive:sos with a
subtype
locationType M Specifies the form that the requesting entity
any
would like the location to come in.
Not defined in ETSI ES 203 178 [1].
exact M Specifies whether the server returns an error if false
the requested locationType is not available.
Not defined in ETSI ES 203 178 [1].
device C The VSP call control shall provide a device IP address (+ port)
identifier to specify IP address and port if a
complete IP flow is not available.
The VSP call control may include device
identity information in addition to the complete
IP flow being available.
The structure and format of device identifiers
shall comply with the provisions in IETF
RFC 6155 [22].
The LS shall only use the device information if
it is unable to identify the device based on flow
information.
flow C The VSP call control shall provide the IP flow Source IP address +
between the source and destination if port
available as specified in IETF RFC 6915 [23]. and
The LS shall try to determine the location of Destination IP address
the device using the full IP flow information if + port
possible.
The LS may use information provided in the
device element if IP flow information is not
provided or is insufficient to allow device
location to be determined.
ETSI ES 203 178 [1]: Calling IP address and
port (M).
In table 5.2 column 1 represents the element name of the HELD protocol. Column 2 indicates the status of this element
(mandatory, conditional or optional). Column 3 describes additional requirements and the mapping of the element to the
information element (IE) in ETSI ES 203 178 [1]. Column 4 specifies the permitted values for the element in column 1.
ETSI
15 ETSI ES 203 283 V1.1.1 (2017-11)
Table 5.2: HELD Location Response
HELD Element Status in Description and related Value
Name HELD ETSI ES 203 178 [1] Information element
with (Status in ETSI ES 203 178 [1])
locationUriSet C If the location response from the location locationURI,
server has either a location reference or a expires
location identifier to return the locationUriSet
parameter shall be present in the response.
ETSI ES 203 178 [1]: Network-provided
location information (M)
Presence C If the location server needs to return a Location-info
location value, either civic, geodetic or both, (PIDF-LO)
then the Presence element shall be present.
ETSI ES 203 178 [1]: Network-provided
location information (M)
routingInformation C If the locationRequest included a
requestRoutingInformation attribute, then
the response shall contain sip:112@example.com
routingInformation (and
ETSI ES 203 178 [1]: ESRF URI (C)
sips:112@example.com)
xmpp:112@example.com
(see note)
NOTE: For the dest field, a SIP URI shall be used. A SIPS URI may be used in addition to the SIP URI. If the VSP is
able to route the SIPS URI destination, then the SIPS URI should be used to enhance security.
5.3.1.3 Location request in the case of pre-established relationship between VSP
and ANP
When the ANP trusts the VSP, and the VSP has been given knowledge of this trust by prior agreement the protocol
defined in ETSI ES 283 035 [13] may be used between the VSP and the LS as an alternative to the HELD protocol
(IETF RFC 5985 [20]). In case the HELD protocol is used, tables 5.1 and 5.2 apply with the exception that the LS can
return a location value.
NOTE: No explicit LS discovery mechanism exists for this option so the relationship between the entities needs
to include how the VSP identifies the corresponding LS.
ETSI ES 283 035 [13] specifies a Diameter application between an Application Function (AF) and a Connectivity
session Location and repository Function (CLF). An AF sends an "Information Query Request" message to a CLF. In
IMS, the AF may be a P-CSCF that perfor
...
SLOVENSKI STANDARD
01-maj-2018
6SHFLILNDFLMHSURWRNRORYVOXåEH]DQXMQRSRPRþ]DXJRWDYOMDQMHORNDFLMHNOLFDWHOMD
LQ]DSUHYR]
Protocol specifications for Emergency Service Caller Location determination and
transport
Ta slovenski standard je istoveten z: ETSI ES 203 283 V1.1.1 (2017-11)
ICS:
13.200 3UHSUHþHYDQMHQHVUHþLQ Accident and disaster control
NDWDVWURI
33.030 Telekomunikacijske Telecommunication services.
uporabniške rešitve Applications
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
ETSI STANDARD
Protocol specifications for Emergency Service
Caller Location determination and transport
2 ETSI ES 203 283 V1.1.1 (2017-11)
Reference
DES/NTECH-00025-M493-protocols
Keywords
emergency, location, VoIP
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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 only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
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 2017.
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
3GPP and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
GSM® and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI ES 203 283 V1.1.1 (2017-11)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 8
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 10
4 Descriptions and assumptions . 11
4.1 Introduction . 11
5 Protocol specifications for the interfaces of the functional architecture in ETSI ES 203 178 . 12
5.1 Interface ia . 12
5.2 Interface ib. 12
5.2.1 Protocol specifications . 12
5.2.2 IMS/NGN implementation considerations . 12
5.3 Interface ic . 13
5.3.1 Protocol specifications . 13
5.3.1.1 General . 13
5.3.1.2 Location request without pre-established relationship between VSP and ANP . 13
5.3.1.3 Location request in the case of pre-established relationship between VSP and ANP . 15
5.3.1.4 Location request to a gateway mobile location centre . 17
5.3.2 IMS implementation considerations . 17
5.4 Interface id. 18
5.4.1 Protocol specifications . 18
5.4.2 IMS implementation considerations . 18
5.5 Interface ie . 18
5.5.1 Protocol specifications . 18
5.5.2 IMS implementation considerations . 21
5.6 Interface if . 22
5.6.1 Protocol specifications . 22
5.6.2 IMS/NGN implementation considerations . 24
5.7 Interface ig. 24
5.7.1 Protocol specifications . 24
5.7.2 IMS implementation considerations . 24
5.8 Interface ih. 25
5.8.1 Protocol specifications . 25
5.8.2 IMS implementation considerations . 27
5.9 Interface ii . 28
5.9.1 Protocol specifications . 28
5.9.2 IMS implementation considerations . 28
5.10 Interface ij . 28
5.10.1 Protocol specifications . 28
5.10.2 IMS/NGN implementation considerations . 30
5.11 Interface ik. 30
5.11.1 Protocol specifications . 30
5.11.2 IMS/NGN implementation considerations . 31
5.12 Interface il . 32
5.12.1 Protocol specifications . 32
5.12.2 IMS implementation considerations . 32
5.13 Interface im . 33
5.13.1 Protocol specifications . 33
5.13.2 IMS implementation considerations . 33
ETSI
4 ETSI ES 203 283 V1.1.1 (2017-11)
5.14 Interface in. 34
5.14.1 Protocol specifications . 34
5.14.2 IMS implementation considerations . 34
6 Functional entities . 34
6.1 UE . 34
6.2 Location Server . 34
6.3 LS Discovery . 35
6.4 VSP Call Control . 35
6.5 Emergency Service Routing Function (ESRF) . 35
6.5.1 Retrieval of the PSAP URI . 35
6.5.2 Additional functionalities of the ESRF . 36
6.5.3 Privacy considerations . 36
6.6 LS Proxy . 36
6.7 Emergency Service Routing Proxy (ESRP) . 37
6.8 Route Server . 37
6.9 IP-PSAP . 37
6.10 PSTN-PSAP . 37
7 Protocol registration requirements . 37
7.1 General . 37
7.2 ProviderIDseries . 37
7.3 ProviderID . 38
History . 39
ETSI
5 ETSI ES 203 283 V1.1.1 (2017-11)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to the present document 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 ETSI Standard (ES) has been produced by ETSI Technical Committee Network Technologies (NTECH).
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
6 ETSI ES 203 283 V1.1.1 (2017-11)
1 Scope
The present document describes the protocol specifications for emergency service caller location determination and
transport architecture as specified in ETSI ES 203 178 [1].
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI ES 203 178: "Functional architecture to support European requirements on emergency caller
location determination and transport".
[2] OMA-TS-MLP-V3_5: "Mobile Location Protocol Version 3.5".
NOTE: Available at http://www.openmobilealliance.org/release/MLS/V1_4-20150224-C/OMA-TS-MLP-V3_5-
20150224-C.pdf.
[3] IETF RFC 3261: "SIP: Session Initiation Protocol".
[4] IETF RFC 4320: "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP)
Non-INVITE Transaction".
[5] IETF RFC 5393: "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP)
Forking Proxies".
[6] IETF RFC 5954: "Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261".
[7] IETF RFC 6442: "Location Conveyance for the Session Initiation Protocol".
[8] IETF RFC 4566: "SDP: Session Description Protocol".
[9] IETF RFC 3264: "An Offer/Answer Model with the Session Description Protocol (SDP)".
[10] ETSI TS 124 229: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; IP multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3
(3GPP TS 24.229)".
[11] ETSI TS 129 165: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Inter-IMS Network to Network Interface
(NNI) (3GPP TS 29.165)".
[12] ETSI TS 123 167: "Universal Mobile Telecommunications System (UMTS); LTE; IP Multimedia
Subsystem (IMS) emergency sessions (3GPP TS 23.167)".
[13] ETSI ES 283 035: "Network Technologies (NTECH); Network Attachment; e2 interface based on
the DIAMETER protocol".
ETSI
7 ETSI ES 203 283 V1.1.1 (2017-11)
[14] ETSI TS 129 163: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; Interworking between the IP Multimedia
(IM) Core Network (CN) subsystem and Circuit Switched (CS) networks (3GPP TS 29.163)".
[15] IETF RFC 4119: "A Presence-based GEOPRIV Location Object Format".
[16] IETF RFC 5139: "Revised Civic Location Format for Presence Information Data Format Location
Object (PIDF-LO)".
[17] IETF RFC 5491: "GEOPRIV Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations".
[18] IETF RFC 6848: "Specifying Civic Address Extensions in the Presence Information Data Format
Location Object (PIDF-LO)".
[19] IETF RFC 7216: "Location Information Server (LIS) Discovery Using IP Addresses and Reverse
DNS".
[20] IETF RFC 5985: "HTTP-Enabled Location Delivery (HELD)".
[21] IETF RFC 5986: "Discovering the Local Location Information Server (LIS)".
[22] IETF RFC 6155: "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)".
[23] IETF RFC 6915: "Flow Identity Extension for HTTP-Enabled Location Delivery (HELD)".
[24] IETF RFC 7840: "A Routing Request Extension for the HTTP-Enabled Location Delivery
(HELD) Protocol".
[25] IETF RFC 6753: "A Location Dereference Protocol Using HTTP-Enabled Location Delivery
(HELD)".
[26] IETF RFC 5031: "A Uniform Resource Name (URN) for Emergency and Other Well-Known
Services".
[27] IETF RFC 6881: "Best Current Practice for Communications Services in Support of Emergency
Calling".
[28] IETF RFC 3325: "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks".
[29] IETF RFC 7852: "Additional Data Related to an Emergency Call".
[30] IETF RFC 3323: "A Privacy Mechanism for the Session Initiation Protocol (SIP)".
[31] IETF RFC 5079: "Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)".
[32] Recommendation ITU-T Q.850 (1998) Amd. 1 (07/2001): "Usage of cause and location in the
Digital Subscriber Signalling System No. 1 (DSS1) and the Signalling System No. 7 ISDN user
part (ISUP), Amendment 1".
[33] ETSI TS 124 525: "Universal Mobile Telecommunications System (UMTS); LTE; Business
trunking; Architecture and functional description (3GPP TS 24.525)".
[34] ETSI EN 300 899-1 (V1.1.2) (09-1998): "Integrated Services Digital Network (ISDN); Signalling
System No.7; Interworking between ISDN User Part (ISUP) version 2 and Digital Subscriber
Signalling System No. one (DSS1); Part 1: Protocol specification [ITU-T Recommendation Q.699,
modified]".
[35] IETF RFC 7163: "URN for Country-Specific Emergency Services".
[36] draft-winterbottom-sipcore-locparam-01 (May 2017): "Location Source Parameter for the SIP
Geolocation Header Field".
ETSI
8 ETSI ES 203 283 V1.1.1 (2017-11)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI ES 282 001: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN Functional Architecture".
[i.2] IETF RFC 3825: "Dynamic Host Configuration Protocol Option for Coordinate-based Location
Configuration Information".
[i.3] IETF RFC 6225: "Dynamic Host Configuration Protocol Options for Coordinate-Based Location
Configuration Information".
[i.4] ETSI TS 123 228: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); LTE; IP Multimedia Subsystem (IMS); Stage 2
(3GPP TS 23.228)".
[i.5] ETSI TS 123 032: "Digital cellular telecommunications system (Phase 2+) (GSM); Universal
Mobile Telecommunications System (UMTS); Universal Geographical Area Description (GAD)
(3GPP TS 23.032)".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
access network: portion of the telecommunications network that provides access to the switching function and
terminates the user access signalling
Access Network Provider (ANP): service provider that provides physical and IP connectivity to a user equipment
(UE) via a fixed or mobile access
NOTE: The access network may be provided by a single organization or it may be provided by a number of
different organizations, BUT the interfaces between these organizations are not relevant to the scope of
the present document as it is matter of contractual relations between the parties.
default PSAP: PSAP that is routed to when insufficient information exists to route to a specific PSAP, based on either
location or emergency category
emergency: urgent need for assistance or relief
emergency call: call from a user to an emergency call centre, PSAP or similar agency charged with routeing calls to the
relevant emergency response organization
emergency call facilities: mechanisms provided by public or private communications networks, emergency telephone
stanchions/boxes, fire alarms, etc. the use of which enables emergency calls to be made
Emergency Call Service Provider (ECSP): service provider that acts as a mediator between the voice service
providers and the public safety answering point service providers
emergency caller: individual placing an emergency call to reach the suitable PSAP
ETSI
9 ETSI ES 203 283 V1.1.1 (2017-11)
emergency category: differentiator for a specific emergency service type
NOTE: Examples of emergency service types are ambulance, police, fire brigade, etc.
emergency response organization: local or national force established to provide assistance to citizens in the event of
their being involved in an emergency situation and requiring specialized help
EXAMPLE: The police, fire service and emergency medical services.
emergency service: service that provides immediate and rapid assistance in situations where there is a direct risk to life
or limb, individual or public health or safety, to private or public property, or the environment but not necessarily
limited to these situations
emergency situation: abnormal situation of serious nature that develops suddenly and unexpectedly, of which the
evolution is uncertain and which may turn into a crisis or cause damage and casualties
Location-by-Reference: representing location information indirectly using a location URI
Location-by-Value: using location information in the form of a location object (LO), such as a PIDF-LO
location identifier: public network identifier, which provides a location value
EXAMPLE: A cell ID or line ID (see ETSI TS 123 167 [12]).
NOTE: A location value can be obtained from a location identifier by applying a static mapping or the location
identifier may be encoded in such a way that it contains a location value (e.g. a ZIP code).
location information: location value, and/or a location identifier and/or a location reference
location reference: identifies a location server and provides sufficient information to allow the location server to
provide the location value for the UE
EXAMPLE: https://ls.example.com:49152/uri/w3g61nf5n66p0, IETF RFC 6753 [25].
location URI: identifier that serves as a reference to location information which is later used as input by a dereference
protocol to retrieve location information
location value: civic or geodetic position
network-provided location information: any location information pertaining to the calling device that is determined,
provided or verified by the ANP
Next Generation Network (NGN): packet-based network able to provide telecommunication services and able to
make use of multiple broadband, QoS-enabled transport technologies and in which service-related functions are
independent from underlying transport-related technologies
nomadic: having the ability to move across network access points
NOTE: A nomadic user can make calls from different locations. However, unlike a mobile user, the location of a
nomadic user cannot change during a specific call.
originating network: access network in which the emergency call was placed
PSAP address: URI or an E.164 number identifying a PSAP or a group of PSAPs
PSAP Service Provider (PSP): service provider that provides connectivity to Public Safety Answering Points (PSAPs)
and directs emergency calls from the ECSP to the PSAP
Public Safety Answering Point (PSAP): physical location where emergency calls are received under the responsibility
of a public authority
regulatory domain: geographical area where a set of regulatory rules applies
telecommunication: any transmission, emission, or reception of signs, signals, writing, images, sounds or intelligence
of any nature, by wire, radio, optical fibre or other electromagnetic system
ETSI
10 ETSI ES 203 283 V1.1.1 (2017-11)
user access: point of connection to a telecommunication network from which a call can be placed
NOTE: This includes public telephones and "emergency call facilities".
user equipment: device allowing a user access to network services
user-provided location information: any location information originating from user-equipment that is not
independently verified by the ANP
Voice Service Provider (VSP): specific type of application service provider that provides voice related services and
optionally text and video-related services, on IP
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AF Application Function
ANP Access Network Provider
APRI Address Presentation Restriction Indicator
AVP Attribute-Value-Pair
CID Content ID
CLF Connectivity session Location and repository Function
DNS Domain Name Server
EC European Commission
E-CSCF Emergency-Call Session Control Function
ECSP Emergency Call Service Provider
ESRF Emergency Service Routing Function
ESRP Emergency Service Routeing Proxy
ETSI European Telecommunications Standards Institute
EU European Union
FQDN Fully Qualified Domain Name
GAD Universal Geographical Area Description
GMLC Gateway Mobile Location Centre
HELD HTTP Enabled Location Delivery
HTTPS Hypertext Transfer Protocol Secure
IANA Internet Assigned Numbers Authority
IBCF Interconnection Border Control Function
IE Information Element
IETF Internet Engineering Task Force
II-NNI Inter-IMS Network to Network Interface
IMS IP Multimedia Core Network Subsystem
IP Internet Protocol
ISUP ISDN User Part
ITU-T International Telecommunications Union - Telecommunications
LbyR Location-by-Reference
LbyV Location-by-Value
LRF Location Retrieval Function
LS Location Server
MLP Mobile Location Protocol
NAPTR Naming Authority PoinTeR
NGN Next Generation Network
OMA Open Mobile Alliance
P-CSCF Proxy-Call Session Control Function
PSAP Public Safety Answering Point
PSP PSAP Service Provider
PSTN Public Switched Telephone Network
RDF Routeing Determination Function
RFC Request For Comment
SIP Session Initiation Protocol
SIPS Session Initiation Protocol Secure
UA User Agent
UE User Equipment
ETSI
11 ETSI ES 203 283 V1.1.1 (2017-11)
URI Uniform Resource Identifier
URL Uniform Resource Locator
URN Uniform Resource Name
VAE VSP Aggregating Entity
VAP VSP Aggregation Provider
VoIP Voice over Internet Protocol
VSP Voice Service Provider
4 Descriptions and assumptions
4.1 Introduction
ETSI ES 203 178 [1] defines the interfaces between functional entities in the functional architecture to support
European requirements on emergency caller location determination and transport, and places requirements on each of
these interfaces. However, it does not specify what protocols are available or might be used to implement the required
functionality across each of the interfaces. The present document matches interfaces with existing protocols and where
gaps exist clearly indicates what the gaps are.
Table 4.1 summarizes the interfaces defined in ETSI ES 203 178 [1] and categorizes them as being either in scope or
out of scope for the present document. Interfaces deemed as "In Scope" have specific clauses detailing how to achieve
the functionality specified in ETSI ES 203 178 [1]. The details may refer to other specification, profile or extend
existing protocols, or define new protocols. Interfaces deemed "Out of Scope" do not have detailed specifications
provided in the present document.
Table 4.1: Categories of Interfaces defined in ETSI ES 203 178 [1]
st nd
Interface Scope
1 endpoint 2 endpoint
ia User equipment VSP Call Control Out of scope
ib VSP Call Control LS Discovery In scope
ic VSP Call Control Location Server In scope
id Location Server Route Server In scope
ie VSP Call Control/VAE VAE/ESRF In scope
if ESRF/LS-Proxy Location Server In scope
ig ESRF Route Server In scope
ih ESRF ESRP In scope
ii ESRP PSTN-PSAP In scope
ij ESRP IP-PSAP In scope
ik PSTN-PSAP ESRF/LS-Proxy In scope
il IP-PSAP Location Server In scope
im IP-PSAP ESRF/LS-Proxy In scope
in ESRF LS-Proxy In scope
As is stated in ETSI ES 203 178 [1], some interfaces in the architecture are between functional entities belonging to
different operators or providers and, as a consequence, these interfaces have interoperability requirements and shall be
implemented following the present document by the related connected functional entities. The protocol selection for
these interfaces can impose requirements on provider internal functionalities and some provider internal interfaces; the
definition of these requirements is however outside the scope of the present document.
The EC standardisation mandate M/493 (see ETSI ES 203 178 [1], annex B) demands that "this work shall not be
focused on NGN but shall address current implementations for all types of voice calls (fixed, mobile, static and
nomadic VoIP) in EU countries". Consequently, the functional architecture is intended to be compatible with
IMS-based deployments and specifications regarding emergency services provision. The present document includes
statements on IMS/NGN implementation considerations per interface.
IMS considerations can include statements regarding the IMS protocol assignment, parameterization and control plane
interworking.
ETSI
12 ETSI ES 203 283 V1.1.1 (2017-11)
The interfaces ia, ib, ic and ie are external, which means between country A and anywhere and (with the exception of
ia) are specified in detail to ensure that all VSPs and VAPs can participate in the processes for emergency service caller
location determination and transport based on the architecture of ETSI ES 203 178 [1] within country A.
The interfaces id, if, ig, ih, ii, ij, ik, il, im and in are internal, inside country A, and should be specified considering the
existing national implementations and regulations in country A. When other protocols are used care is to be taken that
all information elements outlined in the architecture are covered.
5 Protocol specifications for the interfaces of the
functional architecture in ETSI ES 203 178
5.1 Interface ia
The protocol used on the interface ia is determined by the VSP only and is therefore out of scope for the present
document.
5.2 Interface ib
5.2.1 Protocol specifications
The ib interface defines the interactions between the VSP call control and the LS discovery functional entity. The VSP
call control uses the public IP address of the UE to interrogate the LS discovery functional entity in order to obtain the
address of the LS serving the access network to which the UE is attached. Since this function is expected to be
accessible to any VSP anywhere, this is an open interface.
If a pre-established relationship exists between the ANP and the VSP then DNS may be used for the LS discovery
function. The first part of this discovery process in IETF RFC 7216 [19] yields the domain name of the serving access
network. If the VSP knows the address of the LS for the serving ANP, then no further discovery is required, otherwise
an additional DNS query may be used.
If no pre-established relationship exists between the VSP and the ANP then the LS Discovery function shall use the
Domain Name Service (DNS). The VSP requires the URL of the LS serving the access network to which the UE is
attached. The URL shall be a HELD URI (IETF RFC 5985 [20]). The URL discovery shall perform the U-NAPTR
procedures defined in sections 2 and 4 of IETF RFC 5986 [21] with the following variations:
• the domain shall be known as a result of having performed the steps in IETF RFC 7216 [19]; and
• the device based interfaces are irrelevant as discovery is performed by a third-party, i.e. the VSP; and
• the process stops once the URL for the LS has been resolved based on the steps in section 4 of IETF
RFC 5986 [21].
5.2.2 IMS/NGN implementation considerations
This interface is between the VSP call control and the LS Discovery functionality.
This interface is not part of the IMS architecture as specified in ETSI TS 123 228 [i.4] and it is not part of the NGN
architecture as specified in ETSI ES 282 001 [i.1].
ETSI
13 ETSI ES 203 283 V1.1.1 (2017-11)
5.3 Interface ic
5.3.1 Protocol specifications
5.3.1.1 General
Depending on the pre-established relationship the VSP call control can use interface ic to request location and routeing
information from the location server. The following clauses differentiate cases where a pre-established relationship
between entities exists or not.
When the ANP trusts the VSP, and the VSP has been given knowledge of this trust by prior agreement, then
clauses 5.3.1.3 or 5.3.1.4 can be used to request location. Clause 5.3.1.4 can only be used when the ANP provides a
gateway mobile location centre (GMLC).
Otherwise clause 5.3.1.2 shall be used.
5.3.1.2 Location request without pre-established relationship between VSP and ANP
Where no pre-established relationship exists between the VSP and the ANP then the HELD protocol (IETF
RFC 5985 [20]) shall be used by the VSP to acquire location from the LS. The VSP shall use IP address and port
information in the HELD request to the LS using HELD device identity extensions defined in IETF RFC 6155 [22].
Where the VSP has the full IP flow identity information available then it shall use the IP flow identity definitions in
IETF RFC 6915 [23]. The VSP shall set:
• the locationType to "any"; and
• the exact attribute to "false"; and
• the responseTime to "emergencyRouting".
The VSP includes a request for routeing information as described in IETF RFC 7840 [24]. The VSP shall not set the
service attribute in the routeing request unless the UE has identified a specific service to the VSP over ia. If the service
attribute is set then its value shall be identical to the value provided by the UE.
If the LS has no pre-established relationship with the VSP then the LS shall not return a location value but shall return a
location reference in the form of a location URI using the HTTPS URI schemes.
If the HELD request to the LS includes request for routeing information then the LS shall provide routeing information
in accordance with IETF RFC 7840 [24] in the location response message.
NOTE: The HELD protocol does not define explicitly the transport of location identifiers as specified in ETSI
ES 203 178 [1]. In order for HELD to convey these items without modification, location identifiers would
need to be encoded as some kind of URI.
Tables 5.1 and 5.2 describe the elements used for the HELD location request and location response via the ic interface.
In table 5.1 column 1 represents the element name of the HELD protocol. Column 2 indicates the status of this element
(mandatory, conditional or optional). Column 3 describes additional requirements and the mapping of the element to the
information element (IE) in ETSI ES 203 178 [1]. Column 4 specifies the permitted values for the element in column 1.
ETSI
14 ETSI ES 203 283 V1.1.1 (2017-11)
Table 5.1: HELD Location Request
HELD Element Name Status in HELD Description and related Value
ETSI ES 203 178 [1] Information element
with (Status in ETSI ES 203 178 [1])
responseTime M The time in which the requesting entity would emergencyRouting
like a response in ms. LS defined values for
emergencyRouting and emergencyDispatch
can also be used
Not defined in ETSI ES 203 178 [1].
requestRoutingInformation M Allows the requesting entity to request routing Empty or
information urn:service:sos or
ETSI ES 203 178 [1]: Routing request (O). urn:servive:sos with a
subtype
locationType M Specifies the form that the requesting entity
any
would like the location to come in.
Not defined in ETSI ES 203 178 [1].
exact M Specifies whether the server returns an error if false
the requested locationType is not available.
Not defined in ETSI ES 203 178 [1].
device C The VSP call control shall provide a device IP address (+ port)
identifier to specify IP address and port if a
complete IP flow is not available.
The VSP call control may include device
identity information in addition to the complete
IP flow being available.
The structure and format of device identifiers
shall comply with the provisions in IETF
RFC 6155 [22].
The LS shall only use the device information if
it is unable to identify the device based on flow
information.
flow C The VSP call control shall provide the IP flow Source IP address +
between the source and destination if port
available as specified in IETF RFC 6915 [23]. and
The LS shall try to determine the location of Destination IP address
the device using the full IP flow information if + port
possible.
The LS may use information provided in the
device element if IP flow information is not
provided or is insufficient to allow device
location to be determined.
ETSI ES 203 178 [1]: Calling IP address and
port (M).
In table 5.2 column 1 represents the element name of the HELD protocol. Column 2 indicates the status of this element
(mandatory, conditional or optional). Column 3 describes additional requirements and the mapping of the element to the
information element (IE) in ETSI ES 203 178 [1]. Column 4 specifies the permitted values for the element in column 1.
ETSI
15 ETSI ES 203 283 V1.1.1 (2017-11)
Table 5.2: HELD Location Response
HELD Element Status in Description and related Value
Name HELD ETSI ES 203 178 [1] Information element
with (Status in ETSI ES 203 178 [1])
locationUriSet C If the location response from the location locationURI,
server has either a location reference or a expires
location identifier to return the locationUriSet
parameter shall be present in the response.
ETSI ES 203 178 [1]: Network-provided
location information (M)
Presence C If the location server needs to return a Location-info
location value, either civic, geodetic or both, (PIDF-LO)
then the Presence element shall be present.
ETSI ES 203 178 [1]: Network-provided
location information (M)
routingInformation C If the locationRequest included a
requestRoutingInformation attribute, then
the response shall contain sip:112@example.com
routingInformation (and
ETSI ES
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...