ATIS 0500032-2016 ATIS Standard for Implementation of an IMS-based NG9-1-1 Service Architecture.pdf

《ATIS 0500032-2016 ATIS Standard for Implementation of an IMS-based NG9-1-1 Service Architecture.pdf》由会员分享，可在线阅读，更多相关《ATIS 0500032-2016 ATIS Standard for Implementation of an IMS-based NG9-1-1 Service Architecture.pdf（145页珍藏版）》请在麦多课文档分享上搜索。

1、 ATIS-0500032 ATIS Standard on - ATIS STANDARD FOR IMPLEMENTATION OF AN IMS-BASED NG9-1-1 SERVICE ARCHITECTURE As a leading technology and solutions development organization, the Alliance for Telecommunications Industry Solutions (ATIS) brings together the top global ICT companies to advance the ind

2、ustrys 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 services, M2M, cyber security, network evolution, quality of servic

3、e, 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 solutions, and interoperability testing. ATIS is accredited by the

4、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. contributor to the International Telecommunication Union (ITU)

5、, as well as a member of the Inter-American Telecommunication Commission (CITEL). For more information, visit www.atis.org. Notice of Disclaimer LPG Establishes Conference with Conferencing AS/MRFC 105 Figure 8-36: Primary Legacy PSAP Disconnects from the Conference Secondary PSAP is an I3 PSAP . 10

6、8 Figure 8-37: Primary Legacy PSAP Disconnects from the Conference Secondary PSAP is a Legacy PSAP 109 Figure 8-38: Legacy PSAP Establishes Conference with Conferencing AS/MRFC . 111 Figure 8-39: Primary Legacy PSAP Drops out of Conference with Secondary i3 PSAP . 114 Figure 8-40: Primary Legacy PSA

7、P Drops out of Conference with Secondary Legacy PSAP115 Figure 8-41: IMS Based Call to i3 PSAP PRF Example . 118 Table of Tables Table 9-1: Mapping at LNG . 124 Table 9-2: SS7 Wireline to SIP Header Mapping Example 124 Table 9-3: CAMA MF Wireline to SIP Header Mapping Example 125 Table 9-4: FG D MF

8、Wireline to SIP Header Mapping Example 125 Table 9-5: SS7 WCM to SIP Header Mapping Example 126 Table 9-6: CAMA MF WCM to SIP Header Mapping Example 126 Table 9-7: FG D MF WCM to SIP Header Mapping Example 127 Table 9-8: SS7 NCAS to SIP Header Mapping Example . 127 Table 9-9: CAMA MF NCAS to SIP Hea

9、der Mapping Example . 128 Table 9-10: FG D MF NCAS to SIP Header Mapping Example . 128 Table A-1: SIP INVITE Header Profile Legend 132 Table A-2: SIP INVITE Header Profile . 133 1 Preface ATIS has developed a Next Generation 9-1-1 network and emergency call processing architecture based on contribut

10、ions received since 2011 and based on requirements by a number of wireless carriers to have an IP Multimedia Subsystem (IMS)-compatible NG9-1-1 design1. Additionally, the NENA i3 Architecture Working Group2deferred the IMS-based ESInet development to ATIS. ATIS goal in developing this standard has b

11、een transparent interoperability between the two network designs. ATIS intent in this development work was to produce a standard method for IMS-based carriers to offer NG9-1-1 services wholly within their IMS platforms, while maintaining consistency and interoperability with the NENA i3 ESInet/NGCS

12、(Next Generation Core Services) design goals. This kind of standards approach allows IMS-based carriers to take advantage of complete IMS interoperability and features found in their existing IMS ecosystems, while still remaining interoperable with downstream i3 PSAPs that implement NENA i3 standard

13、s and interfaces. It is also ATIS goal to assure that terminating NG9-1-1 entities, such as i3 PSAPs, find the upstream networks that are built on the ATIS IMS-based NG9-1-1 Service Architecture to be as completely interoperable with their systems and networks as that of a NENA i3 NG9-1-1 standard S

14、IP-based architecture. This goal of transparency, both upstream and downstream between architectures, ensures that an i3 PSAP should find no difference whether the i3 PSAP interconnects to a NENA i3 ESInet with NGCS, or interconnects to an ATIS IMS-based NG9-1-1 Service Architecture. This consistent

15、 interoperability principle has guided all of ATIS development work since the beginning, as documented within the original Issue Statement underlying this work. The ATIS IMS-based NG9-1-1 Service Architecture provides compatibility for IMS-based carriers acting as an NG9-1-1 System Service Provider

16、(911SSP) to seamlessly interoperate with NENA i3 ESInet architectures. For entities early in the process of selecting ESInet solutions, the expectation within this ATIS development work was that the ATIS IMS-based NG9-1-1 Service Architecture would offer a choice for carriers that already had an IMS

17、 ecosystem, but not be considered a viable architecture choice for 9-1-1 service entities that had no plans for an IMS infrastructure. Public Safety entities should naturally understand the applicability of an IMS-based NG9-1-1 Service Architecture network approach to processing emergency calls, yet

18、 in this case, they can remain confidently focused on NENA i3-based NG9-1-1 architectures, (this is because IMS may be of interest to carriers, not to jurisdictions), which means that Public Safetys progress and momentum to adopt NG9-1-1 will not be impeded by the introduction of this ATIS NG9-1-1 S

19、ervice Architecture standard. 1 Scope, Purpose, IP Multimedia Subsystem (IMS) emergency sessions.3Ref 2 3GPP TS 24.229, Technical Specification Group Services and System Aspects; IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); St

20、age 3.3Ref 3 3GPP TS 22.101, Technical Specification Group Services and System Aspects; Service aspects; Service principles.3Ref 4 3GPP TS 23.002, Technical Specification Group Services and System Aspects; Network architecture.3Ref 5 3GPP TS 23.271, Technical Specification Group Services and System

21、Aspects; Functional 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 including the addendum in J-STD-036-C-1, Addendum to J-STD-036-C, Enhanced Wireless 9

22、-1-1 Phase II, October 2013.5Ref 8 IETF RFC 5139, Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO), February 2008.4Ref 9 IETF RFC 6753, A Location Dereferencing Protocol Using HELD, October 2012.43This document is available from the Third Generation Partne

23、rship Project (3GPP) at: . 4This document is available from the Internet Engineering Task Force (IETF) at: . 5This document is available from the Alliance for Telecommunications Industry Solutions (ATIS), 1200 G Street N.W., Suite 500, Washington, DC 20005 at: . ATIS-0500032 3 Ref 10 IETF RFC 5491,

24、GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations, March 2009.4Ref 11 3GPP TS 24.147, Technical Specification Group Core Network and Terminals; Conferencing using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3.3Re

25、f 12 IETF RFC 7852, Additional Data related to an Emergency Call, July 2016.4Ref 13 IETF 4353, A Framework for Conferencing with the Session Initiation Protocol (SIP), February 2006.4Ref 14 ATIS-1000679.2015, Interworking between Session Initiation Protocol (SIP) and Bearer Independent Call Control

26、or ISDN User Part.6Ref 15 IETF RFC 6442, Location Conveyance for the Session Initiation Protocol.4Ref 16 IETF RFC 4119, A Presence-based GEOPRIV Location Object Format.4Ref 17 IETF RFC 3265, Session Initiation Protocol (SIP) Specific Event Notification.4Ref 18 IETF RFC 3261, SIP: Session Initiation

27、Protocol.4Ref 19 3GPP TS 23.228, Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2.3Ref 20 IETF RFC 4112, Communications Resource Priority for the Session Initiation Protocol (SIP), February 2006.4Ref 21 IETF RFC 7134, The Management Policy of the Reso

28、urce Priority Header (RPH) Registry Changed to “IETF Review“, March 2014.4Ref 22 IETF RFC 4579, Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents, August 2006.4Ref 23 IETF RFC 7044, An Extension to the Session Initiation Protocol (SIP) for Request History Information, Feb

29、ruary 2014.4Ref 24 IETF RFC 3455, Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP), January 2003.4Ref 25 IETF RFC 3325, Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Netw

30、orks, November 2002.4 Ref 26 ATIS-0500023, Applying Common IMS to NG9-1-1 Networks, April, 2013.6Ref 27 NENA-STA-010.2, Detailed Functional and Interface Standards for the NENA i3 Solution, September 10, 2016.7Ref 28 IETF RFC 2616, Hypertext Transfer Protocol - HTTP/1.1, June 1999.4Ref 29 IETF RFC 4

31、103, RTP Payload for Text Conversation, June 2005.4Ref 30 IETF RFC 4975, The Message Session Relay Protocol (MSRP), September 2007.4Ref 31 IETF RFC 4575, A Session Initiation Protocol (SIP) Event Package for Conference State, August 2006.4Ref 32 3GPP TS 29.333, Technical Specification Group Core Net

32、work and Terminals; Multimedia Resource Function Controller (MRFC) - Multimedia Resource Function Processor (MRFP) Mp interface: Procedures Descriptions.3Ref 33 IETF RFC 7092, A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents, December 2013.4Ref 34 IETF RFC 7647, Clarification

33、s for the Use of REFER with RFC 6665, September 2015.46This document is available from the ATIS, 1200 G Street N.W., Suite 500, Washington, DC 20005 at: . 7This document is available from the National Emergency Number Association. ATIS-0500032 4 Ref 35 IETF RFC 3891, The Session Initiation Protocol

34、(SIP) “Replaces“ Header, September 2004.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 p

35、arties 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 101 NENA ADM 000, NENA Master Glossary of 9-1-1 Terminology.84 Definitions, Acronyms, emergency call transfers involving legacy PS

36、APs; ALI queries from legacy PSAPs; and location and additional data dereferencing functionality. Location by Reference (LbyR) Location by Reference refers to the option to deliver a location reference URI in a header of the call request (SIP INVITE) that may be used by the requesting entity (e.g.,

37、the PSAP) to query for the location of the caller. Location by Value (LbyV) Location by Value refers to the option to deliver the callers location to the PSAP within the body of the call request (SIP INVITE). NG9-1-111An IP-based system comprised of managed IP-based networks (ESInets), functional el

38、ements (applications), and databases that replicate traditional E9-1-1 features and functions, and provide additional capabilities. NG9-1-1 is designed to provide access to emergency services from all connected communications sources, and provide multimedia data capabilities for PSAPs and other emer

39、gency service organizations.8Non Call Associated Signaling (NCAS) NCAS is a signaling method for legacy wireless calls where the calling (E.164) number and the Reference Identifier are sent. The Reference Identifier is used for routing calls. Both the calling number and the Reference Identifier may

40、be used for retrieving location and additional data. (a) If the call is delivered over an SS7 trunk group, the call setup signaling includes the calling number sent in the Calling Party Number parameter, the Reference Identifier is sent in the SS7 GDP, and the digits “911” in the SS7 Called Party Nu

41、mber parameter. (b) If the call is delivered over an MF trunk group, the call setup signaling includes the Reference Identifier signaled as the called number, and the calling number signaled as the ANI. pANI (Pseudo Automatic Number Identification) A telephone number used to support routing of wirel

42、ess 9-1-1 calls. It may identify a wireless cell, cell sector, or PSAP to which the call should be routed. Also known as routing number. Policy Store A functional element in the ESInet that stores policy documents. Reference Identifier . The term “Reference Identifier“ is used in this standard to as

43、sociate the call with location information of the caller. For routing to a legacy emergency services network, a Reference Identifier may be an Emergency Services Routing Key (ESRK) or Emergency Services Routing Digit (ESRD) as defined in J-STD-036-C Ref 7. It may be the Telephone Number that is used

44、 by the legacy emergency services network to query for location information. In a legacy emergency services network, the Reference Identifier may also be used by the emergency services network to route the call to the PSAP. For calls routed to a NENA i3 ESInet, the Reference Identifier may be a dere

45、ferencing URI that is used by i3 functional elements and i3 PSAPs to obtain location.1211The term “NG911” used throughout this document is synonymous with the term “NG9-1-1”. 12Use of an Emergency Services Query Key (ESQK) as a Reference Identifier is for further study, pending the definition of use

46、 cases and call flows that illustrate the circumstances under which an ESQK applies. ATIS-0500032 6 . Wireline Compatibility Mode (WCM) WCM is a signaling method for legacy wireless calls where only the Reference Identifier is sent and used for routing, and for retrieving location and additional dat

47、a. The originating MSC sends an emergency call origination from a legacy wireless caller to the Legacy Network Gateway over an MF or SS7-supported trunk group. The call setup signaling includes the Reference Identifier (as the calling number) and the digits “911” (as the called number). 4.2 Acronyms

48、 & Abbreviations 3GPP Third Generation Partner Program ACM SS7 Address Complete Message ADR Additional Data Repository ALI Automatic Location Identification ANI Automatic Number Identification ANM SS7 Answer Message AS Application Server ATIS Alliance for Telecommunications Industry Solutions B2BUA

49、Back-to-Back User Agent BGCF Breakout Gateway Control Function CAMA Centralized Automatic Message Accounting cid Content-ID CdPN Called Party Number CPN Calling Party Number DTMF Dual Tone Multi-Frequency CSeq Command Sequence E-CSCF Emergency Call Session Control Function ECRF Emergency Call Routing Function (NENA i3) EIDD Emergency Incident Data Document ESInet Emergency Services IP network ESQK Emergency Services Query Key ESRD Emergency Services Routing Digits ESRK Emergency Services Routing Key FG F