1、 ETSI TS 103 478 V1.1.1 (2018-03) Emergency Communications (EMTEL); Pan-European Mobile Emergency Application TECHNICAL SPECIFICATION ETSI ETSI TS 103 478 V1.1.1 (2018-03)2 Reference DTS/EMTEL-00036 Keywords application, emergency ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE T
2、el.: +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 enregistre la Sous-Prfecture 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 av
3、ailable 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 on
4、ly 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 ot
5、her 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 u
6、tilized 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 t
7、o reproduction in all media. ETSI 2018. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are trademarks of ETSI registered for the benefit of its Members. 3GPPTM and LTETMare trademarks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. oneM2M
8、 logo is protected for the benefit of its Members. GSMand the GSM logo are trademarks registered and owned by the GSM Association. ETSI ETSI TS 103 478 V1.1.1 (2018-03)3 Contents Intellectual Property Rights 6g3Foreword . 6g3Modal verbs terminology 6g3Executive summary 6g3Introduction 6g31 Scope 8g3
9、2 References 8g32.1 Normative references . 8g32.2 Informative references 9g33 Definitions and abbreviations . 9g33.1 Definitions 9g33.2 Abbreviations . 10g34 PEMEA architecture and functional entities 11g34.1 Introduction 11g34.2 Functional entities overview. 11g34.2.1 Application (App) . 11g34.2.2
10、Application Provider (AP) 11g34.2.3 PSAP Service Provider (PSP) . 12g34.2.4 Aggregating Service Provider (ASP) 12g34.3 Interface definitions 12g34.3.1 Application Interface (Pa) . 12g34.3.2 Application Provider to PSAP Service Provider Interface (Ps) 12g34.3.3 PSAP Service Provider Interface to Aggr
11、egating Service Provider Interface (Pr) . 12g34.3.4 PSAP Service Provider to PSAP Interface (Pp) 13g35 PEMEA functional entity requirements . 13g35.1 Introduction 13g35.2 Application requirements . 13g35.3 Application provider requirements . 14g35.4 PSAP service provider requirements 14g35.5 Aggrega
12、ting service provider requirements 14g36 PEMEA Message Element Definitions 15g36.1 Introduction 15g36.2 emergencyDataSend Information Elements . 16g36.3 emergencyDataReceived Information Elements 17g36.4 error Information Elements 17g36.5 PEMEA Confirmation Messages . 17g37 PEMEA Message Flows . 17g
13、37.1 Introduction 17g37.2 Ps message flows 18g37.2.1 Ps message flow description . 18g37.2.2 Ps basic flow . 18g37.2.3 Ps error flow . 19g37.2.4 Ps routing flow 20g37.3 Pr message flows 21g37.3.1 Pr message flow description . 21g37.3.2 Pr terminating-PSP basic flow 21g37.3.3 Pr error flow 22g37.3.4
14、Pr end to end routing flow 23g38 PEMEA alignment with ETSI TS 103 479 25g38.1 General alignment 25g38.2 PEMEA to border control function 25g3ETSI ETSI TS 103 478 V1.1.1 (2018-03)4 8.3 PEMEA to Legacy Network Gateway 27g39 Message transportation and processing 28g39.1 HTTP usage 28g39.2 Authenticatin
15、g and authorizing PEMEA entities . 29g39.3 PEMEA Securing a PSAP Retrieving Data By Reference or a reach-back URI 29g39.4 PEMEA XML Processing Rules 30g310 PEMEA XML structures and messages . 30g310.1 Ps Introduction . 30g310.2 Timestamps 30g310.3 General types 31g310.3.1 pemea:posIntType . 31g310.3
16、.2 pemea:nodeType . 31g310.3.3 pemea:hopsType . 31g310.3.4 pemea:routeType 31g310.3.5 pemea:destinationType . 32g310.3.6 pemea:destinationNodeType. 32g310.3.7 pemea:deliveryType 32g310.3.8 pemea:typeOfCallerIdType. 32g310.3.9 pemea:callerIdType 33g310.3.10 pemea:callerIdListType 33g310.3.11 pemea:in
17、formationType 33g310.3.12 pemea:apMoreInfoType 34g310.3.13 pemea:accessDataType . 35g310.3.13.1 pemea:accessDataType structure 35g310.3.13.2 network . 35g310.3.13.3 wifi 35g310.3.14 pemea:accessData . 36g310.3.15 pemea:msgInfoType . 36g311 PEMEA Message Definition 36g311.1 emergencyDataSend Message
18、36g311.1.1 emergencyDataSend message structure 36g311.1.2 emergencyDataSend example . 38g311.1.3 onErrorPost usage details 39g311.1.4 onCapSupportPost usage details . 40g311.2 emergencyDataReceived message 41g311.2.1 emergencyDataReceived message structure . 41g311.2.2 emergencyDataReceived example
19、42g311.3 error message 42g312 PEMEA PIDF-LO Profiling . 43g312.1 Rationale. 43g312.2 entity . 44g312.3 tuple 44g312.4 status . 44g312.5 geopriv 44g312.5.1 geopriv element profile . 44g312.5.2 location-info 44g312.5.2.1 location-info profile 44g312.5.2.2 Confidence 45g312.5.3 usage-rules 45g312.5.4 m
20、ethod 46g312.5.5 provided-by . 46g312.6 timestamp . 46g312.7 PIDF-LO example 46g313 PEMEA Additional-Data Profiling 46g313.1 Rationale. 46g313.2 Additional-Data :- provided-by 47g313.3 EmergencyCallDataValue 47g313.4 EmergencyCallData.ProviderInfo 47g313.4.1 EmergencyCallData.ProviderInfo profile .
21、47g3ETSI ETSI TS 103 478 V1.1.1 (2018-03)5 13.4.2 DataProviderContact :- vcard . 48g313.4.2.1 DataProviderContact :- vcard profile 48g313.4.2.2 DataProviderContact :- org . 48g313.4.2.3 DataProviderContact :- adr . 49g313.4.2.4 DataProviderContact :- email 50g313.4.2.5 DataProviderContact :- URL . 5
22、0g313.4.3 EmergencyCallData.ProviderInfo:- Complete Example . 50g313.5 EmergencyCallData.DeviceInfo . 51g313.6 EmergencyCallData.SubscriberData 51g313.6.1 EmergencyCallData.SubscriberData profile . 51g313.6.2 SubscriberData :- vcard 52g313.6.2.1 SubscriberData :- vcard profile . 52g313.6.2.2 Subscri
23、berData :- Callers name 52g313.6.2.3 SubscriberData :- home address 53g313.6.2.4 SubscriberData :- language . 54g313.6.2.5 SubscriberData :- gender . 54g313.6.2.6 SubscriberData :- bday 54g313.6.2.7 SubscriberData :- tel 55g313.6.2.8 SubscriberData :- email . 56g313.6.2.9 SubscriberData :- Emergency
24、 Family Contacts 56g313.6.3 EmergencyCallData.SubscriberData :- Complete Example 57g313.7 Additional-Data :- EmergencyCallDataReference . 59g313.8 provided-by : Complete Examples . 59g314 Operating Procedures . 60g314.1 Application Provider Operating Procedures . 60g314.1.1 AP sending an EDS to the
25、PSP . 60g314.1.2 AP reach-back URI queries 61g314.1.3 Call termination (ending) and URI invalidation . 62g314.2 PSAP Service Provider Operating Procedures . 62g314.2.1 PSP receiving an EDS message over Ps . 62g314.2.2 PSP sending an EDS message over Pr 64g314.2.3 PSP receiving an EDS message over Pr
26、 64g314.3 Aggregating Service Provider Operating Procedures . 65g314.3.1 Overview of Pr 65g314.3.2 ASP receiving an EDS message over Pr . 65g314.3.3 ASP sending an EDS message over Pr . 66g315 Example message Flows 67g315.1 Description . 67g315.2 AP to PSP EDS 67g315.3 oPSP to AP EDR 68g315.4 oPSP t
27、o ASP EDS 68g315.5 ASP to oPSP EDR 70g315.6 ASP to tPSP EDS . 70g315.7 tPSP to ASP EDR . 72g316 PEMEA Schema . 72g3Annex A (informative): Route Determination . 77g3Annex B (informative): Caller Data . 79g3Annex C (informative): Additional AP Information . 80g3History 81g3ETSI ETSI TS 103 478 V1.1.1
28、(2018-03)6 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
29、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 inves
30、tigation, 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 documen
31、t 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
32、 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 do
33、cument “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 excep
34、t 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 implementa
35、tions 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 existin
36、g 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 l
37、ack a common framework for easy interconnection. This limitation prohibits a users 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 Ap
38、plication (PEMEA) architecture provides a solution to interconnect these applications. ETSI ETSI TS 103 478 V1.1.1 (2018-03)7 The present document amalgamates the European Emergency Number Association (EENA) PEMEA Requirements and Functional Architecture document i.2 and it companion document the PE
39、MEA Protocol and Procedures Specification i.3 providing a single comprehensive document detailing PEMEA. ETSI ETSI TS 103 478 V1.1.1 (2018-03)8 1 Scope The present document is divided into two parts. The first part provides the requirements and functional architecture while the second part provides
40、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 sec
41、ond 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
42、 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
43、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.
44、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 (inclu
45、ding 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 ter
46、m 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
47、 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 Presenc
48、e 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 C
49、ivic 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 ETSI TS 103 478 V1.1.1 (2018-03)9 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
