1、 ATIS-0700015.v003 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, network functions virtualization, big data analytics, cloud services, device solutions, emergency serv
3、ices, 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 solu
4、tions, 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 and major U.S.
5、 contributor to the International 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 em
6、ergency services network to 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.v003 Foreword As a leading technology and solutio
7、ns development organization, 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 betwee
8、n carriers, customers, and 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 wi
9、reline, wireless, cable, satellites, 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
10、North American and international 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 organiz
11、ations, and reviews for acceptability 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
12、 mobile services and systems, 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
13、 should be sent to the Alliance 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: T. Reese, ESI
14、F Chair (Ericsson) J. English, ESIF First Vice-Chair (APCO International) 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; Function
15、al 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-20130220-D, Mobile Location Protocol 3.4, Candidate Version 3.4, February 2013.
16、 (pending approval)6Ref 9 IETF RFC 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, April 2012.6Ref 12 3GPP TS 36.300, E
17、volved Universal Terrestrial Radio Access (E-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,
18、General Packet Radio Service (GPRS) enhancements 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
19、3GPP2 TS X.S0057-A Version 1.0, E-UTRAN - eHRPD 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
20、Terrestrial Radio Access Network (E-UTRAN); 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 Servi
21、ce (GPRS); Service description; Stage 2.3Ref 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 draft-ietf-ecrit-additional-data, Additional Data
22、 related to an Emergency Call. (Work in progress.)4Ref 27 3GPP TS 24.237, IP Multimedia Subsystem (IMS) Service Continuity; Stage 3.3Ref 28 3GPP TS 29.163, Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks.3Ref 29 ATIS-1000679.2013, Interworki
23、ng 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
24、(SIP) Specific Event Notification.4Ref 33 IETF RFC 3261, SIP: Session Initiation Protocol.4 3This 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
25、 for Telecommunications Industry Solutions (ATIS), 1200 G Street N.W., Suite 500, Washington, DC 20005. 6This document is available via the Open Mobile Alliance at . ATIS-0700015.v003 3 Ref 34 3GPP TS 23.228, IP Multimedia Subsystem (IMS); Stage 2.3Ref 35 IETF RFC 5491, GEOPRIV Presence Information
26、Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations.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 IET
27、F RFC 4975, The Message Session Relay Protocol (MSRP), September 2007.4Ref 39 IETF RFC 4976, Relay Extensions for the Message Session Relay Protocol, September, 2007.4Ref 40 ITU-T T.140, Protocol for multimedia application text conversation, February 1998.7Ref 41 IETF RFC 5031, A Uniform Resource Na
28、me (URN) for Emergency and Other Well-known Services, 2008.4Ref 42 IETF RFC 3455, Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP), 2003.4Ref 43 IETF RFC 4244, An Extension to the Session Initiation Protocol (SIP) for Req
29、uest History Information, 2005.4Ref 44 IETF RFC 3325, Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks, 2002.43 Informative References The following standards contain provisions which, through reference in this text, constitute provisions of t
30、his 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 Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. Ref 100
31、NENA 08-003, Detailed Functional and Interface Standards for the NENA i3 Solution, June 14, 2011.8Ref 101 NENA-ADM-000, NENA Master Glossary of 9-1-1 Terminology.84 Definitions, Acronyms, IMS aspects are mostly access-independent and not limited to mobile. ATIS-0700015.v003 8 Clause 6 provides basic
32、 assumptions, defines requirements via reference to 3GPP specifications, and includes any differences (e.g., extensions or restrictions) to these specifications. Clause 7 provides an architectural description that is based on the IMS architecture defined for 3GPP and the ESInet architecture for NENA
33、 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 main architectural entities within IMS originating network and the emergency services networks. Clause 8 provides a description o
34、f the procedures and signaling applicable to location retrieval and emergency call origination to a NENA i3 ESInet and legacy emergency services network. Clause 9 provides a description of any differences to existing standards including use of particular options regarding treatment of different acce
35、ss 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 originating network and the BCF in the ESInet. Annex B provides a normative description of using MLP between the LRF and LS for L0. An
36、nex 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 access. Annex D provides an informative description of emergency call routing by an IMS originating network. Annex E is an informati
37、ve Annex that describes message examples for various use cases. Annex F is an informative Annex that describes some of the access network types for which the procedures and requirements in this document are applicable, with specific reference to IMS interaction, handover, and support of location. Fo
38、r each access type, capabilities and requirements are summarized with references to the applicable standards in which they are fully defined. Annex 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
39、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 the UE originating a call with location-by-reference. 6 Assumptions with North American extensions/restrictions. 3. Emergency calls egress to either a leg
40、acy 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 IMS network will determine the appropriate emergency services network (e.g., a NENA i3 ESInet). 5. The media type will have to be considered when selectin
41、g the appropriate emergency services network. 6. MMES sessions beyond voice and GTT cannot be routed to legacy emergency services networks. 7. Each User Equipment contains an IMS client. 8. A UE may or may not be location aware. 9. Methods of location determination are outside the scope of this stan
42、dard. 10. If there is a civic address associated with the UE, it is validated; the validation process is out of the scope of this standard. 11. An Associated Location is used in some wireless routing scenarios where the cell address or cell centroid cannot be used to route a call to the ESInet or th
43、e Selective Router. 12. An originating network and user equipment (UE) may support some or all media types. 13. It may be possible to negotiate the users indicated desired language(s), per media stream and/or session, in order of preference. ATIS-0700015.v003 9 14. Voice and GTT sessions are expecte
44、d to be maintained when a UE with an active IMS MMES moves out of IMS emergency coverage. 15. 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 services with IMS. 6.2 Requi
45、rements 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 clarifications. _ 3GPP TS 23.167 Ref
46、 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.” Architecture-Principles-010 The LRF s
47、hall 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 cannot be validated. Geo-coordinate locations can o
48、nly 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 other information such as type of emergency servi
49、ce 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, section 6.2.1: “Reject/allow anonymous emergency requests.” P-CSCF-010 Based on the operators policy, the P-CSCF shall allow anonymous emergency requ
