1、 ATIS-0700015.v004 ATIS Standard on - ATIS Standard for Implementation of 3GPP Common IMS Emergency Procedures for IMS Origination and ESInet/Legacy Selective Router Termination As a leading technology and solutions development organization, the Alliance for Telecommunications Industry Solutions (AT
2、IS) brings together the top global ICT companies to advance the industrys most pressing business priorities. ATIS nearly 200 member companies are currently working to address the All-IP transition, 5G, network functions virtualization, big data analytics, cloud services, device solutions, emergency
3、services, M2M, cyber security, network evolution, quality of service, billing support, operations, and much more. These priorities follow a fast-track development lifecycle from design and innovation through standards, specifications, requirements, business use cases, software toolkits, open source
4、solutions, and interoperability testing. ATIS is accredited by the American National Standards Institute (ANSI). The organization is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a founding Partner of the oneM2M global initiative, a member of the Intern
5、ational Telecommunication Union (ITU), as well as a member of the Inter-American Telecommunication Commission (CITEL). For more information, visit www.atis.org. Notice of Disclaimer fixed, mobile or nomadic) and terminating at an ESInet, or, for appropriate media, legacy emergency services network t
6、o support Multimedia Emergency Services (MMES). It is the intent of this standard to support a full multimedia experience; therefore, simultaneous text, voice, pictures, and video are supported in this standard. ATIS-0700015.v004 Foreword As a leading technology and solutions development organizatio
7、n, the Alliance for Telecommunications Industry Solutions (ATIS) brings together the top global information and communications technology (ICT) companies to advance the industrys most-pressing business priorities. ATIS serves the public through improved understanding between carriers, customers, and
8、 manufacturers. This standard was developed jointly between ESIF, PTSC, and WTSC. The Emergency Services Interconnection Forum (ESIF) provides a forum to facilitate the identification and resolution of technical and/or operational issues related to the interconnection of wireline, wireless, cable, s
9、atellites, Internet and emergency services networks. The Packet Technologies and Systems Committee (PTSC) develops and recommends standards and technical reports related to services, architectures, and signaling, in addition to related subjects under consideration in other North American and interna
10、tional standards bodies. PTSC coordinates and develops standards and technical reports relevant to telecommunications networks in the U.S., reviews and prepares contributions on such matters for submission to U.S. ITU-T and U.S. ITU-R Study Groups or other standards organizations, and reviews for ac
11、ceptability or per contra the positions of other countries in related standards development and takes or recommends appropriate actions. The Wireless Technologies and Systems Committee (WTSC) develops and recommends standards and technical reports related to wireless and/or mobile services and syste
12、ms, including service descriptions and wireless technologies. WTSC develops and recommends positions on related subjects under consideration in other North American, regional, and international standards bodies. Suggestions for improvement of this document are welcome. They should be sent to the All
13、iance for Telecommunications Industry Solutions, WTSC, 1200 G Street NW, Suite 500, Washington, DC 20005. At the time of initiation or issuance of the letter ballot for this document, the committees responsible for its development had the following leadership: R. Hixson, ESIF Chair (NENA) R. Marshal
14、l, ESIF First Vice Chair (Comtech) J. Green, ESIF Second Vice Chair (Sprint) M. Dolly, PTSC Chair (AT Stage 3.3Ref 3 3GPP TS 22.101, Service aspects; Service principles.3Ref 4 3GPP TS 23.002, Network architecture.3Ref 5 3GPP TS 23.271, Technical Specification Group Services and System Aspects; Funct
15、ional Stage 2 description of Location Services (LCS).3Ref 6 IETF RFC 5222, LoST: A Location-to-Service Translation Protocol, August 2008.4Ref 7 J-STD-036-C, Enhanced Wireless 9-1-1 Phase II, June 2011.5Ref 8 OMA-TS-MLP-V3_4-20131217-A, Mobile Location Protocol 3.4, Approved Version 3.4.6Ref 9 IETF R
16、FC 6753, A Location Dereferencing Protocol Using HELD, October 2012.4Ref 10 IETF RFC 6155, Use of Device Identity in HTTP-Enabled Location Delivery (HELD), March 2011.4Ref 11 OMA-TS-ULP-V2_0-20120417-A, UserPlane Location Protocol.6Ref 12 3GPP TS 36.300, Evolved Universal Terrestrial Radio Access (E
17、-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2.3Ref 13 3GPP TS 36.331, Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification.3Ref 14 3GPP TS 23.401, General Packet Radio Service (GPRS) enhancem
18、ents for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access.3Ref 15 3GPP TS 23.402, Architecture enhancements for non-3GPP accesses.3Ref 16 3GPP TS 24.301, Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3.3Ref 17 3GPP2 TS X.S0057-A Version 1.0, E-UTRAN - eH
19、RPD Connectivity and Interworking: Core Network Aspects.3Ref 18 3GPP TS 23.237, IP Multimedia Subsystem (IMS) Service Continuity; Stage 2.3Ref 19 3GPP TS 23.216, Single Radio Voice Call Continuity (SRVCC); Stage 2.3Ref 20 3GPP TS 36.305, Evolved Universal Terrestrial Radio Access Network (E-UTRAN);
20、Stage 2 functional specification of User Equipment (UE) positioning in E-UTRAN.3Ref 21 3GPP TS 25.401, UTRAN overall description.3Ref 22 3GPP TS 25.331, Radio Resource Control (RRC); Protocol specification.3Ref 23 3GPP TS 23.060, General Packet Radio Service (GPRS); Service description; Stage 2.3Ref
21、 24 3GPP TS 24.008, Mobile radio interface Layer 3 specification; Core network protocols; Stage 3.3Ref 25 3GPP TS 25.305, Stage 2 functional specification of User Equipment (UE) positioning in UTRAN.3Ref 26 RFC 7852, Additional Data related to an Emergency Call.4Ref 27 3GPP TS 24.237, IP Multimedia
22、Subsystem (IMS) Service Continuity; Stage 3.33This document is available from the Third Generation Partnership Project (3GPP) at . 4This document is available from the Internet Engineering Task Force (IETF). 5This document is available from the Alliance for Telecommunications Industry Solutions (ATI
23、S), 1200 G Street N.W., Suite 500, Washington, DC 20005. 6This document is available via the Open Mobile Alliance at . ATIS-0700015.v004 3 Ref 28 3GPP TS 29.163, Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks.3Ref 29 ATIS-1000679, Interwork
24、ing between Session Initiation Protocol (SIP) and Bearer Independent Call Control or ISDN User Part.5Ref 30 IETF RFC 6442, Location Conveyance for the Session Initiation Protocol.4Ref 31 IETF RFC 4119, A Presence-based GEOPRIV Location Object Format.4Ref 32 IETF RFC 3265, Session Initiation Protocol
25、 (SIP) Specific Event Notification.4Ref 33 IETF RFC 3261, SIP: Session Initiation Protocol.4 Ref 34 3GPP TS 23.228, IP Multimedia Subsystem (IMS); Stage 2.3Ref 35 IETF RFC 5491, GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendation
26、s.4 Ref 36 IETF RFC 5139, Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO).4Ref 37 3GPP TS 26.114, Multimedia Telephony; Media handling and interaction.3Ref 38 IETF RFC 4975, The Message Session Relay Protocol (MSRP).4Ref 39 IETF RFC 4976, Relay Extensions
27、 for the Message Session Relay Protocol.4Ref 40 ITU-T T.140, Protocol for multimedia application text conversation.7Ref 41 IETF RFC 5031, A Uniform Resource Name (URN) for Emergency and Other Well-known Services.4Ref 42 IETF RFC 3455, Private Header (P-Header) Extensions to the Session Initiation Pr
28、otocol (SIP) for the 3rd-Generation Partnership Project (3GPP).4Ref 43 IETF RFC 4244, An Extension to the Session Initiation Protocol (SIP) for Request History Information.4Ref 44 IETF RFC 3325, Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks
29、.43 Informative References The following standards contain provisions which, through reference in this text, constitute provisions of this ATIS Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this ATIS
30、 Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. Ref 100 NENA-STA-010.2, NENA Detailed Functional and Interface Standards for the NENA i3 Solution, September 10, 2016.8Ref 101 NENA-ADM-000, NENA Master Glossary of 9-1-1 Te
31、rminology.84 Definitions, Acronyms, IMS aspects are mostly access-independent and not limited to mobile. Clause 6 provides basic assumptions, defines requirements via reference to 3GPP specifications, and includes any differences (e.g., extensions or restrictions) to these specifications. Clause 7 p
32、rovides an architectural description that is based on the IMS architecture defined for 3GPP and the ESInet architecture for NENA i3 Ref 100. Clause 7 also describes some extensions to the 3GPP IMS architecture applicable to operation in North America, and provides a brief definition of each of the m
33、ain architectural entities within the IMS originating network and the emergency services networks. Clause 8 provides a description of the procedures and signaling applicable to location retrieval and emergency call origination to a NENA i3 ESInet and legacy emergency services network. Clause 9 provi
34、des a description of any differences to existing standards including use of particular options regarding treatment of different access types for support of IMS Emergency Calls in North America. Annex A provides a normative SIP INVITE profile for the ici reference point between the IBCF in the IMS or
35、iginating network and the BCF in the ESInet. Annex B provides a normative description of using MLP between the LRF and LS for L0. Annex C provides an informative description of location acquisition and conveyance based on the 3GPP Control Plane and OMA User Plane location solutions for LTE and HSPA
36、access. ATIS-0700015.v004 8 Annex D provides an informative description of emergency call routing by an IMS originating network. Annex E is an informative Annex that describes message examples for various use cases. Annex F is an informative Annex that describes some of the access network types for
37、which the procedures and requirements in this document are applicable, with specific reference to IMS interaction, handover, and support of location. For each access type, capabilities and requirements are summarized with references to the applicable standards in which they are fully defined. Annex
38、G is an informative Annex that describes a set of use cases for an IMS emergency call origination, to legacy PSAPs as well as IP-capable PSAPs, routing on geographic location or cell site/sector, and use of location-by-value or location-by-reference. Annex H is an informative Annex that describes th
39、e UE originating a call with location-by-reference. 6 Assumptions with North American extensions/restrictions. 3. Emergency calls egress to either a legacy emergency services network or an IP-based emergency services network (i.e., NENA i3/NG9-1-1 ESInet Ref 100). 4. For MMES sessions, the Common IM
40、S network will determine the appropriate emergency services network (e.g., a NENA i3 ESInet). 5. MMES sessions beyond voice and GTT cannot be routed to legacy emergency services networks. 6. Each User Equipment contains an IMS client. 7. A UE may or may not be location aware. 8. Methods of location
41、determination are outside the scope of this standard. 9. If there is a civic address associated with the UE, it is validated; the validation process is out of the scope of this standard. 10. An Associated Location is used in some wireless routing scenarios where the cell address or cell centroid can
42、not be used to route a call to the ESInet or the Selective Router. 11. An originating network and user equipment (UE) may support some or all media types. 12. It may be possible to negotiate the users indicated desired language(s), per media stream and/or session, in order of preference. 13. Voice a
43、nd GTT sessions are expected to be maintained when a UE with an active IMS MMES moves out of IMS emergency coverage. 14. This standard only addresses emergency service use of IMS services. It does not address use of legacy services (e.g., SMS to 9-1-1) in an emergency or the interworking of legacy s
44、ervices with IMS. 6.2 Requirements The Architectural Principles defined in section 4.1 of 3GPP TS 23.167 Ref 1 and 3GPP TS 24.229 Ref 2 apply to this standard with the differences and clarifications noted below. Parts of that section are copied as required to illustrate the differences and clarifica
45、tions. _ 3GPP TS 23.167 Ref 1, section 4.1: “If required, the E-CSCF shall be able to forward the location information to the LRF for validation of geographical location information in the case that the geographical location information is included by the UE over any access network type.” ATIS-07000
46、15.v004 9 Architecture-Principles-010 The LRF shall not validate geographical location information during an emergency session. NOTE: Any civic location must be validated against an emergency services validation database prior to the origination of an emergency session. Geo-coordinate locations cann
47、ot be validated. Geo-coordinate locations can only be verified to be within expected boundaries. _ 3GPP TS 23.167 Ref 1, section 4.1: “The E-CSCF is the IMS network entity, which is responsible to route the request to an emergency center/PSAP or BGCF based on location information and additionally ot
48、her information such as type of emergency service in the request.” Architecture-Principles-020 The E-CSCF shall route the emergency session (e.g., to the MGCF via BGCF for the legacy ES network or IBCF for the ESInet) based upon routing information received from the LRF. _ 3GPP TS 23.167 Ref 1, sect
49、ion 6.2.1: “Reject/allow anonymous emergency requests.” P-CSCF-010 Based on the operators policy, the P-CSCF shall allow anonymous emergency requests. _ The Emergency-CSCF section 6.2.2, of 3GPP TS 23.167 Ref 1 applies to this standard, with the clarifications noted below. 3GPP TS 23.167 Ref 1, section 6.2.2: “If the UE does not have credentials, a non-dialable c
