ETSI TS 103 755 V1.1.1 (2022-06)

Emergency Communications (EMTEL); PEMEA ESInet Shared Services

DTS/EMTEL-00052

General Information

• Status: Not Published
• Technical Committee: EMTEL - Emergency Communications
• Current Stage: 12 - Completion
• Due Date: 16-Jun-2022
• Completion Date: 15-Jun-2022

Standards Content (Sample)

TECHNICAL SPECIFICATION
Emergency Communications (EMTEL);
PEMEA ESInet Shared Services
2 ETSI TS 103 755 V1.1.1 (2022-06)

Reference
DTS/EMTEL-00052
Keywords
application, emergency
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

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

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2022.
All rights reserved.
ETSI
3 ETSI TS 103 755 V1.1.1 (2022-06)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 6
3.1 Terms . 6
3.2 Symbols . 6
3.3 Abbreviations . 6
4 Integrated network view . 7
4.1 Introduction . 7
4.2 PEMEA ESInet interworking beyond the SPIF. 7
4.3 PEMEA ESInet interworking architecture . 7
5 PEMEA ECRF definitions and procedures . 8
5.1 Overview . 8
5.2 PEMEA service identifiers . 8
5.2.1 Overview . 8
5.2.2 Definition . 9
5.2.3 Service tags schema . 10
5.3 PSP to ECRF query response procedures . 10
6 Policy routing function integration with PEMEA . 12
6.1 Overview . 12
6.2 Procedures . 12
7 EDS forwarding . 13
7.1 Overview . 13
7.2 PEMEA Error message reasonTokens . 13
7.3 Common forwarding rules . 14
7.4 Parallel voice call . 14
7.5 PSAP unavailable . 15
7.6 Requested services unavailable . 15
Annex A (informative): Bibliography . 16
History . 17

ETSI
4 ETSI TS 103 755 V1.1.1 (2022-06)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Technical Specification (TS) has been produced by ETSI Special Committee Emergency Communications
(EMTEL).
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
5 ETSI TS 103 755 V1.1.1 (2022-06)
1 Scope
The present document describes interoperability, re-use and enhancement of PEMEA and Emergency Services IP
network (ESInet) components to ensure seamless integration of Internet Apps and traditional telecommunications
service provider solutions and future emergency services offerings. An understanding of the PEMEA architecture is
specified in ETSI TS 103 478 [1] and the Core elements for network independent access to emergency services in ETSI
TS 103 479 [2], currently named Next Generation 112 (NG112) architecture.
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
https://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 TS 103 478 (V1.2.1): "Emergency Communications (EMTEL); Pan-European Mobile
Emergency Application".
NOTE: Available at
https://www.etsi.org/deliver/etsi_ts/103400_103499/103478/01.02.01_60/ts_103478v010201p.pdf.
[2] ETSI TS 103 479 (V1.1.1): "Emergency Communications (EMTEL); Core elements for network
independent access to emergency services".
NOTE: Available at
https://www.etsi.org/deliver/etsi_ts/103400_103499/103479/01.01.01_60/ts_103479v010101p.pdf.
[3] IANA language subtag registry.
NOTE: Available at http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry.
[4] IETF RFC 5222: "LoST: A Location-to-Service Translation Protocol", August 2008.
NOTE: Available at https://datatracker.ietf.org/doc/html/rfc5222.
[5] IETF RFC 5031: "A Uniform Resource Name (URN) for Emergency and Other Well-Known
Services", January 2008.
NOTE: Available at https://datatracker.ietf.org/doc/html/rfc5031.
ETSI
6 ETSI TS 103 755 V1.1.1 (2022-06)
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] IETF RFC 7235: "Hypertext Transfer Protocol (HTTP/1.1): Authentication", June 2014.
NOTE: Available at https://datatracker.ietf.org/doc/html/rfc7235.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
security: techniques and methods used to ensure:
• authentication of entities accessing resources or data
• authorization of authenticated entities prior to accessing or obtaining resources and/or data
• privacy of user data ensuring access only to authenticated and authorized entities
• secrecy of information transferred between two authenticated and authorized entities
trusted: identity of entity assured through an approved authentication mechanism and the entity authorized to perform
the action
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AP Application Provider
App Application
ASP Aggregation Service Provider
BCF Border Control Function
ECRF Emergency Call Routing Function
EDR Emergency Data Received (message)
EDS Emergency Data Send (message)
ESInet Emergency Services IP network
ESRP Emergency Service Routing Proxy
ETSI European Telecommunications Standards Institute
HTTP Hyper-Text Transfer Protocol
IETF Internet Engineering Task Force
IM Instant Messenger
LoST Location to Service Translation
OTT Over-The-Top
PEMEA Pan-European Mobile Emergency Application
ETSI
7 ETSI TS 103 755 V1.1.1 (2022-06)
PIDF-LO Presence Information Document Format Location Object
PIM PSAP Interface Module
PRF Policy Routing Function
PSAP Public Safety Answering Point
PSP PSAP Service Provider
RTT Real-Time Text
SIP Session Initiation Protocol
SIPS SIP Secure
SPIF SIP PEMEA Interworking Function
URI Uniform Resource Identifier
URN Uniform Resource Name
XML eXtensible Markup Language
4 Integrated network view
4.1 Introduction
The ESInet and PEMEA architecture have nodes that perform similar functions but in quite different ways.
Consequently there is a need for some of the functions to sit side by side, while some of the more common
functionalities can be shared.
4.2 PEMEA ESInet interworking beyond the SPIF
ETSI TS 103 478 [1] defines a basic interworking between PEMEA and SIP via an entity called the SIP PEMEA
Interworking Function (SPIF). In this approach, in the absence of a global forest guide network or local public ECRF,
an OTT terminal can acquire the SIP address of the local ESInet BCF using the PEMEA network. This approach
requires "terminating" the PEMEA signalling at the edge of the emergency network in the SPIF, which consists of a
PIM coupled with a SIP-proxy. Such a system allows for basic PEMEA capabilities such as user information and
updated location to be provided to Public Safety Answering Points (PSAPs) inside the ESInet, however, it does not
allow advanced PEMEA services to be propagated to, and used by PSAPs as there is no way to signal these capabilities
to the PSAP.
The present document does not explore the SPIF further, but rather moves the decision point inside the ESInet to the
PIM associated with the terminating PSAP. There are a number of advantages to this approach including supporting
advanced PEMEA services as well as situations where some services will be delivered via SIP and others via PEMEA
giving the PSAP the flexibility to choose.
4.3 PEMEA ESInet interworking architecture
The architecture for PEMEA and ESInet node sharing is shown in Figure 1.
ETSI
8 ETSI TS 103 755 V1.1.1 (2022-06)

Figure 1: PEMEA and ESInet shared services network architecture
The main operations and interfaces are described in more detail in subsequent clauses of the present document. The PSP
acts as the gatekeeping into the shared services network. As described in ETSI TS 103 478 [1], a PSP has a specific
relationship with AP that are directly connected to it and these will, in most circumstance, be permitted to communicate
with the local PSAP. Whilst PEMEA has been designed to allow applications to roam anywhere in Europe, certain
PSAP regions may wish to restrict their access to only certain application providers. The PSP implements this
functionality through a permissive white list. This ensures that only valid PEMEA entities that are also on this white list
are permitted to enter the shared services network.
5 PEMEA ECRF definitions and procedures
5.1 Overview
The Emergency Call Routing Function (ECRF) uses the Location Service Translation (LoST) protocol as defined in
IETF RFC 5222 [4] to transform a location and service identifier into a series of destination identifiers, usually
Universal Resource Identifiers (URIs). Different URI types are used for different protocol types, for example SIP or
SIPS would be used for the delivery of SIP-based communication services. Similarly, HTTPS URIs destination can be
used for the delivery of PEMEA communication messages, and this can be handled natively by the LoST protocol with
no required changes to the IETF RFC 5222 LoST protocol specification [4].
5.2 PEMEA service identifiers
5.2.1 Overview
PEMEA was conceived with a single, central service identifier in mind, as a consequence, natively per ETSI
TS 103 478 [1], it does not have a concept of sub-services, such as police, fire and ambulance which are easily defined
by the service urns used within the ESInet signalling. Despite the promotion of the common 112 number for emergency
services in Europe, many member states operate independent numbers for different services and this is a capability that
needs to be folded into PEMEA. The support for these services is defined in the subsequent clauses. The guidelines in
PEMEA regarding non-understood extensions applies and any implementation that does not understand the service tags
extension shall ignore them but pass them through in any EDS routing.
ETSI
9 ETSI TS 103 755 V1.1.1 (2022-06)
5.2.2 Definition
PEMEA has a philosophy of defining generic containers into which specific capabilities and definitions are bound.
Service tag definitions will follow this same approach. The serviceTags element will consist of one or more
serviceTags, where each serviceTag consists of a name attribute and a value.
Table 1
Attribute Meaning
name This is the identifier of the specific service type. For example: name="serviceUrn". In this case it is
saying that the value associated with the service name is to be interpreted as a service urn.
value Is of type token or of type URI. Complex values are not supported in serviceTags. URIs to retrieve
complex values from an external source are a matter for further study.

Specifying a new service requires defining the value type and specifying a new unique name.
EXAMPLE:

urn:service:sos:police
en
audio
fr
text

The present document specifies five service options, though not all are relevant to the ECRF routing, the others may be
used for policy routing and direction further in the processing pipeline.
Table 2
Name Value type Description
serviceUrn URI This is the service URN aligning with the service that the user of the
application selected. This is the service URN that will be included in any
location-based route determination, whether internal to the
...