ETSI TS 103 698 V1.2.1 (2026-02)

TECHNICAL SPECIFICATION
Emergency Communications (EMTEL);
Lightweight Messaging Protocol for
Emergency Service Accessibility (LMPE)

2 ETSI TS 103 698 V1.2.1 (2026-02)

Reference
RTS/EMTEL-00077
Keywords
chat, decentralized identifier, emergency services,
location, SSL/TLS certificates
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 - 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 the
ETSI Search & Browse Standards application.
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 on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
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 2026.
All rights reserved.
ETSI
3 ETSI TS 103 698 V1.2.1 (2026-02)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
Executive summary . 6
Introduction . 7
1 Scope . 8
2 References . 8
2.1 Normative references . 8
2.2 Informative references . 9
3 Definition of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 9
3.3 Abbreviations . 9
4 General . 11
4.1 Overview . 11
4.2 Architecture . 11
4.3 Mandatory Interfaces . 12
4.4 Optional Interfaces . 13
5 Entities . 13
5.1 Border Control Function (BCF) . 13
5.1.1 Overview . 13
5.1.2 Mandatory Interfaces . 13
5.1.3 Optional Interfaces . 14
5.2 Emergency Service Routing Proxy (ESRP) . 14
5.2.1 Overview . 14
5.2.2 Mandatory Interfaces . 14
5.2.3 Optional Interfaces . 15
5.3 Emergency Call Routing Function (ECRF) . 15
5.3.1 Overview . 15
5.3.2 Mandatory Interfaces . 15
5.3.3 Optional Interfaces . 15
5.4 Public Safety Answering Point (PSAP). 15
5.4.1 Overview . 15
5.4.2 Mandatory Interfaces . 15
5.4.3 Optional Interfaces . 16
5.5 Location Information Server (LIS) . 16
5.5.1 Overview . 16
5.5.2 Mandatory Interfaces . 16
5.5.3 Optional Interfaces . 16
5.5.4 Location Representation . 17
5.6 Chat Application (APP) . 17
5.6.1 Overview . 17
5.6.2 Mandatory Interfaces . 17
5.6.3 Optional Interfaces . 17
5.6.4 Location Representation . 17
6 Interfaces . 18
6.1 Signalling . 18
6.1.1 SIP Transport (SIP-1) . 18
6.1.2 SIP Session (SIP-2) . 18
6.1.2.1 Overview . 18
6.1.2.2 SIP Methods . 18
6.1.2.3 Required SIP Headers . 18
ETSI
4 ETSI TS 103 698 V1.2.1 (2026-02)
6.1.2.4 Accepted SIP Headers . 19
6.1.2.5 Resource Priority . 20
6.1.2.6 History-Info and Reason . 20
6.1.2.7 Call-Info . 20
6.1.2.8 SIP Message Bodies . 22
6.1.2.9 SIP Element Overload . 22
6.1.2.10 Test Call . 22
6.1.2.11 Decentralized Identifier (DID) . 23
6.2 Instant Messaging (IM-2) . 23
6.2.1 Overview . 23
6.2.2 Session Mode Initiation . 23
6.2.3 Session Mode Chat . 25
6.2.4 Session Mode Termination . 26
6.2.5 Keep-Alive Messages . 26
6.2.6 Transfer . 27
6.2.7 Redirect . 28
6.2.8 Application-Specific Messages . 30
6.2.9 Message Delivery . 30
6.3 Chat Transfer (HTTP-3) . 31
6.3.1 Overview . 31
6.3.2 Transfer Negotiation . 31
6.3.3 Transfer Execution . 32
6.3.4 Message Sequence Chart . 32
Annex A (normative): JSON Schema And Message Type Definition . 36
A.1 ChatTransferNegotiationRequest . 36
A.2 ChatTransferNegotiationResponse . 36
A.3 ChatTransferExecutionRequest . 37
A.4 ChatTransferExecutionResponse . 37
A.5 MessageDeliveryStatus . 38
A.6 Message Type Definition . 38
Annex B (informative): Organizational Descriptions . 39
B.0 General . 39
B.1 Certificate Authority. 39
B.2 National, and Regional Authorities . 39
B.3 Public Safety Computer Emergency Response Team (CERT) . 39
B.4 ETSI Protocol Naming and Numbering Service (PNNS) . 39
B.5 Emergency Call Service Authorities . 39
Annex C (informative): Parameter Registries . 41
C.0 General . 41
Annex D (informative): Use Case Examples . 42
D.0 General . 42
D.1 National/Regional . 42
D.2 International/Roaming . 43
D.3 Smart IoT Devices and Chatbots . 44
Annex E (informative): Cipher Suites . 45
E.1 General . 45
ETSI
5 ETSI TS 103 698 V1.2.1 (2026-02)
E.2 Recommended TLS 1.3 Cipher Suites . 45
E.3 Acceptable TLS 1.2 Cipher Suites . 45
History . 46

ETSI
6 ETSI TS 103 698 V1.2.1 (2026-02)
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 IPR online database.
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™, LTE™ and 5G™ logo 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.
Executive summary
Lightweight Messaging Protocol for Emergency Service accessibility (LMPE) extends a SIP SIMPLE-based messaging
service with session mode and facilities to redirect or transfer a chat. The mechanisms introduced in the present
document differ from existing solutions like Message Session Relay Protocol (MSRP) in a sense that no media plane is
required. This reduces the functionality to chat, but requires less deployment effort and complexity (e.g. no intermediate
services or relays in case of firewalls or NAT), especially in a roaming use case. In addition, to further reduce
complexity, the identification of a user is carried out via a device identifier only, such as a mobile phone number as with
comparable chat services. In summary, it simplifies the implementation and thus can be used in simple mobile
applications or even smart IoT devices and chatbots, that, for example, send or respond to messages automatically.
ETSI
7 ETSI TS 103 698 V1.2.1 (2026-02)
The referred baseline specification (ETSI TS 103 479 [1]) already defines page mode messaging suitable for a single
message exchange or a series of short messages similar to paging or SMS on a mobile device. Routing and mapping
mechanisms (defined in ETSI TS 103 479 [1]) to determine the adequate control room, are based on location
information. Therefore, a single message exchange is not practicable as caller location may change and lead to
messages being routed to a different control room. The present document defines specific message types to group
messages into sessions with routing and mapping only required at setup time. In addition, the same principles are used
to support supplementary services like chat redirect and transfer. Each mechanism is transparent to ETSI
TS 103 479 [1] core services and requires only minor modifications to the Public Safety Answering Points (PSAP)
interface.
Introduction
Emergency communications services are primarily voice-only, along with a marginal share of data and multimedia used
by Public Safety Answering Points (PSAPs). Improving access to emergency services for citizens, especially for the
deaf and hard of hearing, requires PSAPs and people in need to handle new modes of communications such as text.
Messenger services are widespread and well-known to the public. The present document defines extensions to support a
comparable messenger service to access emergency control rooms by leveraging the new architecture introduced in
ETSI TS 103 479 [1]. The main purpose of such extensions is to enable a simplified chat session mode combined with
means to redirect or transfer a chat session. Furthermore, the present document allows a lightweight implementation of
a messenger application for emergency chat or bot services. The fact that besides a signalling plane, no further media
sessions are required, supports a straight integration with firewalls or, in general, network security technologies.

ETSI
8 ETSI TS 103 698 V1.2.1 (2026-02)
1 Scope
The present document describes a lightweight session-based emergency chat protocol that extends the base messaging
functionality as defined in ETSI TS 103 479 [1]. The messaging service is based only on methods of the SIP signalling
plane and interworks with Border Control Function (BCF), Emergency Service Routing Proxy (ESRP), Emergency Call
Routing Function (ECRF), Public Safety Answering Point (PSAP), the Location Information Server (LIS). It is
important to emphasize that this feature is an alternative to MSRP, real-time text or, in general, total conversation and
not a replacement.
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 in the
ETSI docbox.
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 479: "Emergency Communications (EMTEL); Core elements for network
independent access to emergency services".
[2] IETF RFC 2046 (November 1996): "Multipurpose Internet Mail Extensions (MIME) Part Two:
MediaTypes", Freed N. and Borenstein, N.
[3] IETF RFC 3261 (June 2002): "SIP: Session Initiation Protocol", Rosenberg, J., Schulzrinne, H.,
Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and Schooler, E.
[4] IETF RFC 3325 (November 2002): "Private Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity Within Trusted Networks", Jennings, C., Peterson, J. and Watson, M.
[5] IETF RFC 3326 (December 2002): "The Reason Header Field for the Session Initiation Protocol
(SIP)", Oran, D. and Camarillo, G.
[6] IETF RFC 3428 (December 2002): "Session Initiation Protocol (SIP) Extension for Instant
Messaging", Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and Gurle, D.
[7] IETF RFC 3841 (August 2004): "Caller Preferences for the Session Initiation Protocol (SIP)",
Rosenberg, J., Schulzrinne, H. and Kyzivat, P.
[8] IETF RFC 4119 (December 2005): "A Presence-Based GEOPRIV Location Object Format",
Peterson, J.
[9] IETF RFC 7044 (February 2014): "An Extension to the Session Initiation Protocol (SIP) for
Request History Information", Barnes, M.
[10] IETF RFC 4412 (February 2006): "Communications Resource Priority for the Session Initiation
Protocol (SIP)", Schulzrinne, H. and Polk, J.
[11] IETF RFC 8866 (January 2021): "SDP: Session Description Protocol", Begen, A., Kyzivat, P.
Perkins, C., and Handley, M.
[12] IETF RFC 5031 (January 2008): "A Uniform Resource Name (URN) for Emergency and Other
Well-Known Services", Schulzrinne, H.
ETSI
9 ETSI TS 103 698 V1.2.1 (2026-02)
[13] IETF RFC 5621 (September 2009): "Message Body Handling in the Session Initiation Protocol
(SIP)", Camarillo, G.
[14] IETF RFC 6442 (December 2011): "Location Conveyance for the Session Initiation Protocol",
Polk, J., Rosen, B. and Peterson, J.
[15] IETF RFC 6881 (March 2013): "Best Current Practice for Communications Services in Support of
Emergency Calling", Rosen, B. and Polk, J.
[16] IETF RFC 7135 (May 2014): "Registering a SIP Resource Priority Header Field Namespace for
Local Emergency Communications", Polk, J.
[17] IETF RFC 8446 (August 2018): "The Transport Layer Security (TLS) Protocol Version 1.3",
Rescorla, E. ®
[18] W3C Recommendation 19 July 2022: "Decentralized Identifiers (DIDs) v1.0 Core architecture,
data model and representations".
[19] IETF RFC 8224 (February 2018): "Authenticated Identity Management in the Session Initiation
Protocol (SIP)", Peterson J., Jennings C., Rescorla E. and Wendt C.
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 may be useful in implementing an ETSI deliverable or add to the reader's
understanding, but are not required for conformance to the present document.
[i.1] EENA, Version 1.1, March 2013: "Next Generation 112 - Long Term Definition".
[i.2] EENA Version 1.05, March 2016: "Public Safety Digital Transformation - The Internet of Things
(IoT) and Emergency Services". ®
[i.3] W3C Recommendation 15 May 2025: "Verifiable Credentials Data Model 2.0".
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AP Application Provider
APP APPlication
ASP Application Service Provider
BCF Border Control Function
ETSI
10 ETSI TS 103 698 V1.2.1 (2026-02)
BGP Border Gateway Protocol
CA Certificate Authority
CAP Common Alerting Protocol
CERT Computer Emergency Response Team
CR Carriage Return
CTI Centre for Testing & Interoperability (ETSI)
DHE Diffie Hellman Exchange
DID Decentralized Identifier
DLT Distributed Ledger Technology
ECDHE Elliptic Curve Diffie-Hellman Ephemeral
ECDSA Elliptic Curve Digital Signature Algorithm
ECRF Emergency Call Routing Function
ESInet Emergency Services IP network
ESRF Emergency Service Routing Function
ESRP Emergency Service Routing Proxy
ETSI European Telecommunications Standards Institute
FG Forest Guide
GCM Galois/Counter Mode
GIS Geographic Information System
HELD HTTP Enabled Location Delivery
HTTP Hypertext Transfer Protocol
ID IDentity
IETF Internet Engineering Task Force
IM Instant Messaging
IoT Internet of Things
IP Internet Protocol
IT Information Technology ®
JSON JavaScript Object Notation
LF Line Feed
LIS Location Information Server
LMPE Lightweight Messaging Protocol for Emergency service accessibility
LOST Location to Service Translation
LTD Long-Term Definition
MIME Multipurpose Internet Mail Extensions
MSD Minimum Set of Data
MSRP Message Session Relay Protocol
NAT Network Address Translation
OS Operating System
OTA Over The Air
P-A-I P-Asserted-Identity
PIDF Presence Information Data Format
PIDF-LO Presence Information Data Format - Location Object
PNNS Protocol Naming and Numbering Service
PSAP Public Safety Answering Point
RCS Rich Communication Services
RFC Request For Comment
RSA Rivest Shamir Adleman
SIP Session Initiation Protocol
SMS Short Message Service
TCP Transmission Control Protocol
TLS Transport Layer Security
TS (ETSI) Technical Specification
UDP User Datagram Protocol
URI Uniform Resource Identifier
URN Uniform Resource Name
VSP Voice Service Provider
WGS84 World Geodetic System 1984
ETSI
11 ETSI TS 103 698 V1.2.1 (2026-02)
4 General
4.1 Overview
Per ETSI TS 103 479 [1], emergency communications are routed by the ESRF to the ESRP via a BCF. Depending on
national PSAP models the ESRP may then forward directly to the appropriate PSAP as explained in NG112 LTD [i.1].
The same mechanism applies to instant messaging in a non-session mode. The present document defines extensions to
interfaces and introduces an Application (APP) interface to support a session-based chat application.
NOTE: The term APP refers to either a mobile application or a backend service acting on its behalf.
Figure 1 illustrates a high level functional architecture, where specific Application Provider (AP) services are used to
manage the application (AP BE) or to interconnect with an ESInet (SIP PROXY). Chat messages addressed to a public
emergency service SIP URI or service URN are forwarded to a BCF and routed within the ESInet utilizing a geodetic
location determined by the mobile application (typically via sensor fusion).

Figure 1: High level functional architecture
The present document specifies only the signalling interface between APP, PSAP, and other core services required to
setup a session-based chat. The following architecture introduces functional elements that comprise an IP only
environment. Such elements provide security measures (BCF), emergency call routing (ESRP), mapping PSAP
boundaries to SIP URIs (ECRF), a mobile Application (APP), and chat processing equipment (PSAP).
4.2 Architecture
The definition of core elements and interfaces supporting a Lightweight Messaging Protocol for Emergency service
accessibility (LMPE) is based on the core concept introduced in ETSI TS 103 479 [1]. LMPE utilizes IP technology and
requires public and private managed, and routed IP networks. The present document introduces new interfaces between
the functional elements APP and PSAP (dashed-line boxes in Figure 2), and refers to functional elements with their
internal and external interfaces as defined in ETSI TS 103 479 [1], listed below:
• Border Control Function (BCF);
• Emergency Call Routing Function (ECRF);
• Chat Application (APP);
• Public Safety Answering Point (PSAP);
• Emergency Services Routing Proxy (ESRP); and
• Location Information Service (LIS).
ETSI
12 ETSI TS 103 698 V1.2.1 (2026-02)

Figure 2: Core elements
4.3 Mandatory Interfaces
Mandatory interfaces are either referenced (ETSI TS 103 479 [1]), or introduced by the present document to define
simple chat capabilities of an APP and ESInet core elements. Figure 3 shows the following mandatory interfaces:
• SIP-1, SIP-2: Interface between APP, BCF, ESRP and PSAP elements that defines SIP transport and
signalling capabilities.
• LOST-1, LOST-2: Interface between ESRP and ECRF elements that defines LoST signalling capabilities.
• HELD-1, HELD-2: Interface between ESRP or PSAP and LIS elements that defines location dereference and
HELD signalling capabilities.
• IM-2: APP and PSAP chat handling capabilities to support instant messaging.

Figure 3: Considered mandatory interfaces
ETSI
13 ETSI TS 103 698 V1.2.1 (2026-02)
4.4 Optional Interfaces
In addition, optional interfaces as defined in ETSI TS 103 479 [1], are referenced by the present document to extend
mandatory capabilities. Figure 4 shows the following optional interfaces:
• HTTP-2: Interface between BCF and PSAP elements that defines domain specific web service capabilities.
• HTTP-3: Interface between PSAP elements that defines domain specific web service capabilities.
• LOST-1: Interface between APP and ECRF elements that defines LoST signalling capabilities.
• HELD-1: Interface between APP and LIS elements that defines HELD signalling capabilities.

Figure 4: Considered optional interfaces
5 Entities
5.1 Border Control Function (BCF)
5.1.1 Overview
A BCF is the entry point (point-of-interconnect) to the ESInet infrastructure where all traffic from external networks
transits. General procedures and interfaces are specified in ETSI TS 103 479 [1].
5.1.2 Mandatory Interfaces
To be compliant with the procedures in the present document, a BCF shall support:
1) the SIP-1 interface as specified in ETSI TS 103 479 [1], clause 6.1.1;
2) the SIP-2 interface as specified in ETSI TS 103 479 [1], clause 6.1.2.
Figure 5 shows BCF mandatory interfaces and neighbouring entities.
ETSI
14 ETSI TS 103 698 V1.2.1 (2026-02)

Figure 5: BCF mandatory interfaces
5.1.3 Optional Interfaces
In addition to all mandatory interfaces, a BCF may support any other specific interface as listed in ETSI
TS 103 479 [1]:
• the HTTP-2 interface as specified in ETSI TS 103 479 [1], clause 6.2.2.
Figure 6 shows BCF optional interfaces and neighbouring entities.

Figure 6: BCF optional interfaces
5.2 Emergency Service Routing Proxy (ESRP)
5.2.1 Overview
The Emergency Service Routing Proxy (ESRP) is the base routing function for emergency chat. General procedures and
interfaces are specified in ETSI TS 103 479 [1].
Invocation of identity verification, if an Identity header field value conforming to IETF RFC 8224 [19] is received in
incoming signalling, is specified in ETSI TS 103 479 [1], clause 5.2.6.
5.2.2 Mandatory Interfaces
To be compliant with the procedures in the present document, an ESRP shall support:
1) the SIP-1 interface as specified in ETSI TS 103 479 [1], clause 6.1.1;
2) the SIP-2 interface as specified in ETSI TS 103 479 [1], clause 6.1.2;
3) the LOST-1 interface as specified in ETSI TS 103 479 [1], clause 6.4.1;
4) the LOST-2 interface as specified in ETSI TS 103 479 [1], clause 6.4.2;
5) the HELD-1 interface as specified in ETSI TS 103 479 [1], clause 6.5.1;
6) the HELD-2 interface as specified in ETSI TS 103 479 [1], clause 6.5.2.
Figure 7 shows ESRP mandatory interfaces and neighbouring entities.

Figure 7: ESRP mandatory interfaces
ETSI
15 ETSI TS 103 698 V1.2.1 (2026-02)
5.2.3 Optional Interfaces
In addition to all mandatory interfaces, an ESRP may support any other specific interface as listed in ETSI
TS 103 479 [1].
5.3 Emergency Call Routing Function (ECRF)
5.3.1 Overview
The Emergency Call Routing Function (ECRF) is the base mapping function for emergency chat. General procedures
and interfaces are specified in ETSI TS 103 479 [1]. ECRFs may be arranged in hierarchical trees, where each
hierarchical higher ECRF covers a greater area, with a Forest Guide (FG) as an element interconnecting multiple
countries' highest level ECRFs, as specified in ETSI TS 103 479 [1], clause 5.3.6.
5.3.2 Mandatory Interfaces
To be compliant with the procedures in the present document, an ECRF shall support:
1) the LOST-1 interface as specified in ETSI TS 103 479 [1], clause 6.4.1;
2) the LOST-2 interface as specified in ETSI TS 103 479 [1], clause 6.4.2.
Figure 8 shows ECRF mandatory interfaces and neighbouring entities.

Figure 8: ECRF mandatory interfaces
5.3.3 Optional Interfaces
In addition to all mandatory interfaces, an ECRF may support any other specific interface as listed in ETSI
TS 103 479 [1].
5.4 Public Safety Answering Point (PSAP)
5.4.1 Overview
A PSAP is a service, typically composed of more than one functional element. The functional elements that make up a
PSAP are out of scope of the present document. The PSAP implements the LMPE interface including the chat
capability as specified in the present document.
5.4.2 Mandatory Interfaces
To be compliant with the procedures in the present document, a PSAP shall support:
1) the SIP-1 interface as specified in ETSI TS 103 479 [1], clause 6.1.1;
2) the SIP-2 interface as specified in ETSI TS 103 479 [1], clause 6.1.2;
3) the HELD-2 interface as specified in ETSI TS 103 479 [1], clause 6.5.2;
4) the IM-2 interface as specified in clause 6.2.
Figure 9 shows PSAP mandatory interfaces and neighbouring entities.
ETSI
16 ETSI TS 103 698 V1.2.1 (2026-02)

Figure 9: PSAP mandatory interfaces
5.4.3 Optional Interfaces
In addition to all mandatory interfaces, a PSAP may support any other specific interface as listed in ETSI
TS 103 479 [1] and below:
1) the HTTP-2 interface as specified in ETSI TS 103 479 [1], clause 6.2.2;
1) the HTTP-3 interface as specified in clause 6.3.
Figure 10 shows PSAP optional interfaces and neighbouring entities.

Figure 10: PSAP optional interfaces
5.5 Location Information Server (LIS)
5.5.1 Overview
Location is fundamental to the operation of the emergency services, and the generic functional entity that provides
location is a Location Information Server (LIS) as specified in ETSI TS 103 479 [1].
5.5.2 Mandatory Interfaces
To be compliant with the procedures in the present document, a LIS shall support:
1) the HELD-1 interface as specified in ETSI TS 103 479 [1], clause 6.5.1;
2) the HELD-2 interface as specified in ETSI TS 103 479 [1], clause 6.5.2.
Figure 11 shows LIS mandatory interfaces and neighbouring entities.

Figure 11: LIS mandatory interfaces
5.5.3 Optional Interfaces
In addition to all mandatory interfaces, a LIS may support any other specific interface as listed in ETSI TS 103 479 [1].
ETSI
17 ETSI TS 103 698 V1.2.1 (2026-02)
5.5.4 Location Representation
Location is represented by content in a PIDF-LO document (IETF RFC 4119 [8]). All geodetic data shall use WGS84
as the datum. The representation of the location object within the PIDF document shall utilize the tuple element as
defined in IETF RFC 4119 [8].
5.6 Chat Application (APP)
5.6.1 Overview
The APP implements the LMPE interface including the chat capability as specified in the present document. Other
backend services required by the APP are out of scope of the present document.
5.6.2 Mandatory Interfaces
To be compliant with the procedures in the present document, an APP shall support:
1) the SIP-1 interface as specified in ETSI TS 103 479 [1], clause 6.1.1;
2) the SIP-2 interface as specified in ETSI TS 103 479 [1], clause 6.1.2;
3) the IM-2 interface as specified in clause 6.2.
Figure 12 shows APP mandatory interfaces and neighbouring entities.

Figure 12: APP mandatory interfaces
5.6.3 Optional Interfaces
In addition to all mandatory interfaces, an APP may support any other specific interface as listed in ETSI
TS 103 479 [1] and below:
1) the LOST-1 interface as specified in ETSI TS 103 479 [1], clause 6.4.1;
2) the HELD-1 interface as specified in ETSI TS 103 479 [1], clause 6.5.1.
Figure 13 shows APP optional interfaces and neighbouring entities.

Figure 13: APP optional interfaces
5.6.4 Location Representation
Location is represented by content in a PIDF-LO document (IETF RFC 4119 [8]). All geodetic data shall use WGS84 as
the datum. The representation of the location object within the PIDF document shall utilize the tuple element as
defined in IETF RFC 4119 [8].
ETSI
18 ETSI TS 103 698 V1.2.1 (2026-02)
6 Interfaces
6.1 Signalling
6.1.1 SIP Transport (SIP-1)
SIP signalling within the ESInet shall be carried over TCP with TLS as defined in IETF RFC 8446 [17]. When a TLS
connection already exists, either peering entity shall reuse that TLS connection for all SIP messages within a chat (refer
to clause 6.2.3) by utilizing a proper session timeout of at least 3 minutes. Fallback to UDP is allowed. However,
emergency call messages have many large elements, for example, a PIDF-LO, and are more likely to be fragmented
when carried in UDP. Fragmentation and reassembly shall be supported by all ESInet elements. If TLS establishment
fails, fallback to TCP without TLS is allowed.
If fallback with TLS occurs, additional security weaknesses should be considered, and implementations should be
prepared to deal with the security risks when TLS protection is not available. Known
...