ImageVerifierCode 换一换
格式:PDF , 页数:145 ,大小:6.56MB ,
资源ID:541196      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-541196.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(ATIS 0500032-2016 ATIS Standard for Implementation of an IMS-based NG9-1-1 Service Architecture.pdf)为本站会员(hopesteam270)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

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

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

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1