ETSI TS 103 478 V1.2.1 (2020-03)

Emergency Communications (EMTEL); Pan-European Mobile Emergency Application

RTS/EMTEL-00048

General Information

• Status: Published
• Publication Date: 25-Mar-2020
• Technical Committee: EMTEL - Emergency Communications
• Current Stage: 12 - Completion
• Due Date: 26-Mar-2020
• Completion Date: 26-Mar-2020

Standards Content (Sample)

TECHNICAL SPECIFICATION
Emergency Communications (EMTEL);
Pan-European Mobile Emergency Application

2 ETSI TS 103 478 V1.2.1 (2020-03)

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

Tel.: [phone]  Fax: [phone]

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

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

© ETSI 2020.
All rights reserved.
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.
ETSI
3 ETSI TS 103 478 V1.2.1 (2020-03)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
Executive summary . 6
Introduction . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 9
3.3 Abbreviations . 9
4 PEMEA architecture and functional entities . 10
4.1 Introduction . 10
4.2 Functional entities overview. 10
4.2.0 PEMEA Registration Authority . 10
4.2.1 Application (App) . 10
4.2.2 Application Provider (AP) . 11
4.2.3 PSAP Service Provider (PSP) . 11
4.2.4 Aggregating Service Provider (ASP) . 11
4.3 Interface definitions . 11
4.3.1 Application Interface (Pa) . 11
4.3.2 Application Provider to PSAP Service Provider Interface (Ps) . 12
4.3.3 PSAP Service Provider Interface to Aggregating Service Provider Interface (Pr) . 12
4.3.4 PSAP Service Provider to PSAP Interface (Pp) . 12
5 PEMEA functional entity requirements . 12
5.1 Introduction . 12
5.2 Application requirements . 12
5.3 Application provider requirements . 13
5.4 PSAP service provider requirements . 13
5.5 Aggregating service provider requirements. 14
6 PEMEA Message Element Definitions . 14
6.1 Introduction . 14
6.2 emergencyDataSend Information Elements . 15
6.3 emergencyDataReceived Information Elements . 16
6.4 error Information Elements . 16
6.5 PEMEA Confirmation Messages . 16
7 PEMEA Message Flows . 16
7.1 Introduction . 16
7.2 Ps message flows . 17
7.2.1 Ps message flow description . 17
7.2.2 Ps basic flow . 17
7.2.3 Ps error flow . 18
7.2.4 Ps routing flow . 19
7.3 Pr message flows . 20
7.3.1 Pr message flow description . 20
7.3.2 Pr terminating-PSP basic flow . 20
7.3.3 Pr error flow . 21
7.3.4 Pr end to end routing flow . 22
8 PEMEA alignment with ETSI TS 103 479 . 24
ETSI
4 ETSI TS 103 478 V1.2.1 (2020-03)
8.1 General alignment . 24
8.2 PEMEA to border control function . 24
8.3 PEMEA to Legacy Network Gateway . 26
9 Message transportation and processing . 27
9.1 HTTP usage . 27
9.2 Authenticating and authorizing PEMEA entities . 28
9.3 PEMEA Securing a PSAP Retrieving Data By Reference or a reach-back URI . 28
9.4 PEMEA XML Processing Rules . 29
10 PEMEA XML structures and messages . 29
10.1 Ps Introduction . 29
10.2 Timestamps . 29
10.3 General types . 30
10.3.1 pemea:posIntType . 30
10.3.2 pemea:nodeType . 30
10.3.3 pemea:hopsType . 30
10.3.4 pemea:routeType . 30
10.3.5 pemea:destinationType . 31
10.3.6 pemea:destinationNodeType. 31
10.3.7 pemea:deliveryType. 31
10.3.8 pemea:typeOfCallerIdType. 31
10.3.9 pemea:callerIdType . 31
10.3.10 pemea:callerIdListType . 32
10.3.11 pemea:informationType . 32
10.3.12 pemea:ap MoreInfoT ype . 33
10.3.13 pemea:accessDataType . 33
10.3.13.1 pemea:accessDataType structure . 33
10.3.13.2 network . 34
10.3.13.3 wifi . 34
10.3.14 pemea:accessData . 35
10.3.15 pemea:msgInfoType . 35
11 PEMEA Message Definition . 35
11.1 emergencyDataSend Message . 35
11.1.1 emergencyDataSend message structure . 35
11.1.2 emergencyDataSend example . 37
11.1.3 onErrorPost usage details . 37
11.1.4 onCapSupportPost usage details . 38
11.2 emergencyDataReceived message . 39
11.2.1 emergencyDataReceived message structure . 39
11.2.2 emergencyDataReceived example . 40
11.3 error message . 40
12 PEMEA PIDF-LO Profiling . 42
12.1 Rationale. 42
12.2 entity . 42
12.3 tuple . 42
12.4 status . 42
12.5 geopriv . 43
12.5.1 geopriv element profile . 43
12.5.2 location-info . 43
12.5.2.1 location-info profile . 43
12.5.2.2 Confidence . 43
12.5.3 usage-rules . 44
12.5.4 method . 44
12.5.5 provided-by . 44
12.6 timestamp . 44
12.7 PIDF-LO example . 44
13 PEMEA Additional-Data Profiling . 45
13.1 Rationale. 45
13.2 Additional-Data :- provided-by . 45
13.3 EmergencyCallDataValue . 45
ETSI
5 ETSI TS 103 478 V1.2.1 (2020-03)
13.4 EmergencyCallData.ProviderInfo . 45
13.4.1 EmergencyCallData.ProviderInfo profile . 45
13.4.2 DataProviderContact :- vcard . 46
13.4.2.1 DataProviderContact :- vcard profile . 46
13.4.2.2 DataProviderContact :- org . 46
13.4.2.3 DataProviderContact :- adr . 47
13.4.2.4 DataProviderContact :- email . 48
13.4.2.5 DataProviderContact :- URL . 48
13.4.3 EmergencyCallData.ProviderInfo:- Complete Example . 48
13.5 EmergencyCallData.DeviceInfo . 49
13.6 EmergencyCallData.SubscriberData . 49
13.6.1 EmergencyCallData.SubscriberData profile . 49
13.6.2 SubscriberData :- vcard . 50
13.6.2.1 SubscriberData :- vcard profile . 50
13.6.2.2 SubscriberData :- Caller's name . 50
13.6.2.3 SubscriberData :- home address . 51
13.6.2.4 SubscriberData :- language . 51
13.6.2.5 SubscriberData :- gender . 52
13.6.2.6 SubscriberData :- bday . 52
13.6.2.7 SubscriberData :- tel . 52
13.6.2.8 SubscriberData :- email . 53
13.6.2.9 SubscriberData :- Emergency Family Contacts . 54
13.6.3 EmergencyCallData.SubscriberData :- Complete Example . 55
13.7 Additional-Data :- EmergencyCallDataReference . 56
13.8 provided-by : Complete Examples . 57
14 Operating Procedures . 58
14.1 Application Provider Operating Procedures . 58
14.1.1 AP sending an EDS to the PSP . 58
14.1.2 AP reach-back URI queries . 59
14.1.3 Call termination (ending) and URI invalidation . 60
14.2 PSAP Service Provider Operating Procedures . 60
14.2.1 PSP receiving an EDS message over Ps . 60
14.2.2 PSP sending an EDS message over Pr . 61
14.2.3 PSP receiving an EDS message over Pr. 62
14.3 Aggregating Service Provider Operating Procedures . 63
14.3.1 Overview of Pr . 63
14.3.2 ASP receiving an EDS message over Pr . 63
14.3.3 ASP sending an EDS message over Pr . 64
15 Example message Flows . 64
15.1 Description . 64
15.2 AP to PSP EDS . 64
15.3 oPSP to AP EDR . 66
15.4 oPSP to ASP EDS . 66
15.5 ASP to oPSP EDR . 67
15.6 ASP to tPSP EDS . 68
15.7 tPSP to ASP EDR . 69
16 PEMEA Schema . 70
Annex A (informative): Route Determination . 75
Annex B (informative): Caller Data . 77
Annex C (informative): Additional AP Information . 78
History . 79

ETSI
6 ETSI TS 103 478 V1.2.1 (2020-03)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Specification (TS) has been produced by ETSI 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.
Executive summary
The Pan-European Mobile Emergency Application (PEMEA) architecture provides the requirements and architecture
for a solution to provide emergency application interconnection. It specifies the protocols and procedures enabling
interoperable implementations of the architecture and provides extension points to enable new communication
mechanisms as they evolve.
Introduction
The rise of smart devices such as smart phones, tablets and laptops has led to an explosion in communications
applications. Many of these applications aim to supplement existing communications services, such as providing caller
and location information for emergency calls, while others seek to provide alternative communication mechanisms such
as total conversation and instant messaging for example. Many of these applications already exist in limited local
capacities but lack a common framework for easy interconnection. This limitation prohibits a user's application
operating in a region other than the one it was developed in and having his/her information and accurate location
information passed to the PSAP serving their location. The Pan-European Mobile Emergency Application (PEMEA)
architecture provides a solution to interconnect these applications.

ETSI
7 ETSI TS 103 478 V1.2.1 (2020-03)
1 Scope
The present document is divided into two parts. The first part provides the requirements and functional architecture
while the second part provides the protocol and procedures for implementing the Pan-European Mobile Emergency
Application (PEMEA). The first part identifies the key functional entities involved in the emergency application
architecture, the interfaces between each functional entity, and the requirements on each interface. The second part
defines the data exchanges, message, protocols and procedures used across each of the identified PEMEA interfaces.
It is recognized that many existing application implementations combine the functional entities identified in the present
document into a single entity. The most common example of combined functional entities is the combined Application
Provider (AP) and PSAP Service Provider (PSP), these are common because it is often the PSAP that writes or engages
a third-party to write a local emergency application that interfaces directly with the PSAP. The present document does
not seek to disallow integrated node implementations, however, it does not define how additional applications or
application providers using proprietary Application Programming Interfaces (APIs) and protocols can provide PEMEA
extended features, such solutions are left to the integrated node providers.
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] IETF RFC 2818: "HTTP Over TLS", May 2000.
[2] IETF RFC 2965: "HTTP State Management Mechanism", October 2000.
[3] IETF RFC 4119: "A Presence-based GEOPRIV Location Object Format", December 2005.
[4] IETF RFC 5491: "GEOPRIV Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", March 2009.
[5] IETF RFC 3966: "The tel URI for telephone Number", December 2004.
[6] IETF RFC 7459: "Representation of Uncertainty and Confidence in the Presence Information Data
Format Location Object (PIDF-LO)", February 2015.
[7] IETF RFC 3863: "Presence Information Data Format (PIDF)", August 2004.
[8] IETF RFC 5139: "Revised Civic Location Format for Presence Information Data Format Location
Object (PIDF-LO)", February 2008.
[9] IETF RFC 6848: "Specifying Civic Address Extensions in the Presence Information Data Format
Location Object (PIDF-LO)", January 2013.
[10] IANA: "Method Token Registry of Values".
NOTE: Available at http://www.iana.org/assignments/method-tokens/method-tokens.xhtml#method-tokens-1.
[11] IETF RFC 7852: "Additional Data Related to an Emergency Call", July 2016.
ETSI
8 ETSI TS 103 478 V1.2.1 (2020-03)
[12] IETF RFC 7105: "Using Device-Provided Location-Related Measurements in Location
Configuration Protocols", January 2014.
[13] IANA: "Language subtag registry".
NOTE: Available at http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry.
[14] ISO 639-3 (2007): "Codes for the representation of names of languages -- Part 3: Alpha-3 code for
comprehensive coverage of languages".
NOTE: Available at https://www.iso.org/standard/39534.html.
[15] IETF RFC 6753: "A Location Dereference Protocol Using HTTP-Enabled Location Delivery
(HELD)", October 2012.
[16] IETF RFC 5808: "Requirements for a Location-by-Reference Mechanism", May 2010.
[17] Open Mobile Alliance OMA-TS-MLP-V3-2-20110719-A: "Mobile Location Protocol 3.2"
July 2011.
[18] Open Mobile Alliance OMA-TS-MLP-V3-3-1-20111117-A: "Mobile Location Protocol 3.3.1",
November 2011.
[19] Open Mobile Alliance OMA-TS-MLP-V3-4-20150512-A: "Mobile Location Protocol 3.4",
May 2015.
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 TS 103 479: "Emergency Communications (EMTEL); Core elements for network
independent access to emergency services".
[i.2] EENA: "Pan-European Mobile Emergency Application (PEMEA) Requirements and Functional
Architecture", Version 7, February 2015.
NOTE: Available at https://eena.org/wp-content/uploads/2015_12_02_PEMEA-Final.pdf.
[i.3] Void.
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
ETSI
9 ETSI TS 103 478 V1.2.1 (2020-03)
• 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
API Application Programming Interface
App Application
ASP Aggregating Service Provider
BCF Border Control Function
BSSID Basic Service Set Identifier
CID Cell Identifier
ECRF Emergency Call Routing Function
EDR Emergency Data Received (message)
EDS Emergency Data Send (message)
EENA European Emergency Number Association
ESInet Emergency Services IP Network
ESRP Emergency Services Routing Proxy
ETSI European Telecommunications Standards Institute
GML Geography Markup Language
GNSS Global Navigation Satellite System
HELD HTTP-Enabled Location Delivery
HTTP Hyper-Text Transfer Protocol
IETF Internet Engineering Task Force
IMEI International Mobile Equipment Identifier
IMSI International Mobile Subscriber Identifier
LIF Location Interworking Function
LIS Location Information Server
LNG Legacy Network Gateway
MAC Media Access Control
MCC Mobile Country Code
MLP Mobile Location Protocol
MNC Mobile Network Code
MSISDN Mobile Service International Subscriber Dial Number
OMA Open Mobile Alliance
oPSP Originating PSP
OTT Over The Top
Pa PEMEA Application to AP interface
PEMEA Pan-European Mobile Emergency Application
PIDF-LO Presence Information Data Format Location Object
Pp PEMEA PSP to PSAP interface
Pr PEMEA PSP to ASP or ASP to PS interface
PRA PEMEA Registration Authority
Ps PEMEA AP to PSP interface
PSAP Public Safety Answering Point
PSP PSAP Service Provider
PSTN Public Switched Telephone Network
RTT Real-Time Text
SIP Session Initiation Protocol
SIPS SIP Secure
TLS Transport Layer Security
tPSP terminating PSP
ETSI
10 ETSI TS 103 478 V1.2.1 (2020-03)
ttl time to live
UCF Universal Character Set
UMTS Universal Mobile Telecommunication System (cellular 3G)
URI Uniform Resource Identifier
URL Uniform Resource Locator
URN Universal Resource Name
UTC Coordinated Universal Time
UTF UCF Transformation Format
VSP Voice Service Provider
XML eXtensible Markup Language
XSD XML Schema Definition
4 PEMEA architecture and functional entities
4.1 Introduction
The extensive deployment of existing mobile emergency applications and their interconnection into a Pan-European
Emergency Application ecosystem has prompted the definition of entities identified in Figure 1.

Figure 1: PEMEA Reference Architecture
In some implementations functional entities may be owned and operated by the same commercial entity, for example
the Application Provider (AP) and the PSAP Service Provider (PSP) may be the same. In these cases, the external
interfaces shown in the reference architecture need only apply when communicating with external entities.
4.2 Functional entities overview
4.2.0 PEMEA Registration Authority
The PEMEA Registration Authority (PRA) is the entity that contains registrations for all currently valid PEMEA
entities. The PRA accepts registrations from entities that conform to the PEMEA protocol and procedures and only
registered entities may send or receive messages in the PEMEA network. The PRA provides a list of these entities to all
valid entities when requested to do so.
4.2.1 Application (App)
Software that runs on a smartphone or mobile computing platform that is capable of making an emergency call using
mobile network operator call control machinery (3G/4G/WiFi). Simultaneous to call establishment the App sends user
authentication information to an Application Provider and subsequently sends location, connectivity and other
information about the caller to the Application Provider for subsequent conveyance to a PSAP.
ETSI
11 ETSI TS 103 478 V1.2.1 (2020-03)
4.2.2 Application Provider (AP)
The Application Provider (AP) is the entity that provides a mobile emergency application. It is responsible for
authenticating the Application prior to accepting caller information from the App. The AP needs to format the data
received from the App, possibly combining it with caller information stored in AP server, and conveying it to a PSAP
Service Provider (PSP). There needs to be a trust relationship between the AP and PSP. Where the AP and PSP are not
the same entity then data formats defined in the present document shall be used to convey caller information from the
AP to the PSP.
In the general case, an AP has a relationship with a single PSP. However, an AP may have a relationship with more than
one PSP. When this is the case it is up to the AP to determine which PSP to send the information to. How the AP makes
this determination is out of scope of the present document, but the AP shall only send the information to one PSP to
avoid multiple routing of the same messages through the network.
4.2.3 PSAP Service Provider (PSP)
The role of the PSAP Service Provider (PSP) is to take caller information from trusted sources and ensure that it is
provided to the correct PSAP. Where the PSP directly serves the PSAP for which the information is destined, then it is
referred to as the terminating-PSP (tPSP). If a PSP receives information that it knows is not for a PSAP that it directly
services then it should use its knowledge of other PSPs to attempt to deliver the information to the PSP serving the
correct PSAP. When this occurs it is referred to as an originating-PSP (oPSP). This situation occurs when the caller
makes the call outside the area that is serviced by the AP that provided the application.
Information coming from trusted sources shall comply with the data formats and communication mechanisms defined in
the present document.
Trusted information may come from one of two sources. It may come directly from an AP with which the PSP has a
direct trust relationship (Ps). Alternatively, the information may come from an AP with which the terminating-PSP has
no direct trust relationship (Pr). In this latter case, the trust relationship is brokered by another PSP or chain of PSPs to
the terminating-PSP.
How the PSP provides or renders information to a PSAP that it directly services is out of scope of the present document.
4.2.4 Aggregating Service Provider (ASP)
The primary role of the PSP is to ensure that accurate and trusted caller information is provided to the PSAP that is
terminating an emergency call. A PSP may have knowledge of immediately adjacent terminating-PSPs but requiring a
PSP to have a relationship with all other PSPs so that it can direct caller information to the correct terminating-PSP is a
daunting and unnecessary task. The role of the Aggregating Service Provider (ASP) is to provide this routing capability
and some high-level ideas are described in Annex A.
The ASP operates as a centralized or regional entity and can determine, based on information included in the PEMEA
data object, the best terminating-PSP to direct the information to. There may be more than one ASP across Europe and
where this occurs meshing is expected to occur. How the meshing occurs is an operational consideration outside the
scope of the present document but may be addressed by subsequent operational considerations.
4.3 Interface definitions
4.3.1 Application Interface (Pa)
This is the interface used for communication between the Application and the Application P
...