ATIS 0500033-2017 Overview and Operational Considerations for an IMS-based Next Generation 9-1-1 (NG9-1-1) Service Architecture based on ATIS-0500032.pdf

《ATIS 0500033-2017 Overview and Operational Considerations for an IMS-based Next Generation 9-1-1 (NG9-1-1) Service Architecture based on ATIS-0500032.pdf》由会员分享，可在线阅读，更多相关《ATIS 0500033-2017 Overview and Operational Considerations for an IMS-based Next Generation 9-1-1 (NG9-1-1) Service Architecture based on ATIS-0500032.pdf（29页珍藏版）》请在麦多课文档分享上搜索。

1、ATIS-0500033 ATIS Standard on Overview and Operational Considerations for an IMS-based Next Generation 9-1-1 (NG9-1-1) Service Architecture based on ATIS-0500032 Alliance for Telecommunications Industry Solutions Approved February 21, 2017 Abstract This document provides an overview and operational

2、consideration for an IMS-based Next Generation 9-1-1 (NG9-1-1) Service Architecture based upon ATIS-0500032, ATIS Standard for Implementation of an IMS-based NG9-1-1 Service Architecture. This document includes considerations related to IMS Emergency Service Networks that are considered terminating

3、networks. ATIS-0500033 ii Foreword The Alliance for Telecommunication Industry Solutions (ATIS) serves the public through improved understanding between carriers, customers, and manufacturers. The Emergency Services Interconnection Forum (ESIF) provides a forum to facilitate the identification and r

4、esolution of technical and/or operational issues related to the interconnection of wireline, wireless, cable, satellites, Internet and emergency services networks. The ESIF Next Generation Emergency Services (NGES) Subcommittee coordinates emergency services needs and issues with and among SDOs and

5、industry forums/committees, within and outside ATIS, and develops emergency services (such as E9-1-1) standards, and other documentation related to advanced (i.e., Next Generation) emergency services architectures, functions, and interfaces for communications networks. The mandatory requirements are

6、 designated by the word shall and recommendations by the word should. Where both a mandatory requirement and a recommendation are specified for the same criterion, the recommendation represents a goal currently identifiable as having distinct compatibility or performance advantages. The word may den

7、otes a optional capability that could augment the standard. The standard is fully functional without the incorporation of this optional capability. Suggestions for improvement of this document are welcome. They should be sent to the Alliance for Telecommunications Industry Solutions, ESIF, 1200 G St

8、reet NW, Suite 500, Washington, DC 20005. At the time of consensus on this document, the committees responsible for its development, had the following leadership: S. Sherwood, ESIF Chair (Verizon Wireless) R. Hixson, ESIF First Vice-Chair (NENA) R. Marshall, ESIF Second Vice-Chair (Comtech) C. Milit

9、eau, ESIF NGES Co-Chair (West Safety Services) T. Reese, ESIF NGES Co-Chair (Ericsson) ATIS-0500033 iii Table of Contents PREFACE 1 1 SCOPE, PURPOSE, Multimedia Resource Function Controller (MRFC) - Multimedia Resource Function Processor (MRFP) Mp interface: Procedures Descriptions.5Ref 6 NENA 04-00

10、1, Recommended Generic Standards for E9-1-1 PSAP Equipment.4Ref 7 NENA 04-005, NENA ALI Query Service Standard.4Ref 8 RFC 5222, LoST: A Location-to-Service Translation Protocol.6Ref 9 RFC 6753, A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD).63This document is available f

11、rom the Alliance for Telecommunications Industry Solutions (ATIS), 1200 G Street N.W., Suite 500, Washington, DC 20005 at: . 4This document is available from the National Emergency Number Association (NENA) at: . 5This document is available from the Third Generation Partnership Project (3GPP): . 6RF

12、C text is available at . ATIS-0500033 3 Ref 10 3GPP TS 23.228, Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2.5Ref 11 3GPP TS 23.167, Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS) emergency sessions.53 Info

13、rmative 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 Standar

14、d are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. Ref 100 NENA-ADM-000.19-2016, NENA Master Glossary of 9-1-1 Terminology.74 Definitions, Acronyms, emergency call transfers involving legacy PSAPs; ALI queries from legacy PSAPs; and

15、 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., the PSAP) to query for the location of

16、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-1 An IP-based system comprised of managed IP-based networks (ESInets), functional elements (applications), and databases tha

17、t 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 emergency service organizations.8Non Call Ass

18、ociated 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 be used for retrieving location and addit

19、ional 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 Number parameter. (b) If the call is delive

20、red 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 Automatic Number Identification (ANI). pANI (Pseudo Automatic Number Identification) A telephone number used to support routing of wireless 9-1

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

22、e 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 4. It may be the Telephone Number that is used by the le

23、gacy 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 dereferencing

24、URI that is used by i3 functional elements and i3 PSAPs to obtain location.1010Use of an Emergency Services Query Key (ESQK) as a Reference Identifier is for further study, pending the definition of use cases and call flows that illustrate the circumstances under which an ESQK applies. ATIS-0500033

25、5 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 data. The originating MSC sends an emergency call origination from a legacy wireless caller to the Lega

26、cy 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 the LNG acquires location, converts the signaling, and forwards the call to the E-CSCF via the IBCF

27、 and I-CSCF. For egressing to legacy PSAPs, NENA i3 defines the LPG as described in section 7.1.4. The LPG receives the call signaling from the ESRP (via a BCF), acquires location if necessary, converts the signaling from SIP to the appropriate PSAP signaling, and responds to queries from the PSAP f

28、or callback (depending upon the type of signaling) and location (i.e., ALI). ATIS-0500032 adopted similar concepts by incorporating the i3 LPG into the ATIS IMS-based NG9-1-1 Service Architecture as described in section 5.2.9. 7.3 Dereferencing Capabilities If a call enters the NENA i3 ESInet with l

29、ocation-by-reference (LbyR) or from a legacy wireless network via the LNG, location information must be obtained to route the call and allow the PSAP to query for dispatch location. If the ESRP receives an LbyR, it must obtain the routing location (via a dereference procedure) in order to route the

30、call as described in section 7.1.2. The ESRP may obtain the routing location from either the LIS in the originating network or the associated location determined by the LNG. That location is then sent to the ECRF to obtain routing information. Once the call is delivered to the NENA i3 PSAP, it may d

31、ereference the dispatch location from either the LIS in the originating network or from the LNG. The legacy PSAP obtains location information by querying an LPG which dereferences the LbyR by querying a LIS or LNG. The ATIS IMS-based NG9-1-1 Service Architecture described in ATIS-0500032 must also s

32、upport location dereferencing. However, it is the responsibility of the LRF in the IMS-based Next Generation Emergency Services Network to obtain a location that can be used for routing. The LRF may obtain the routing location from either an LS (e.g., a LIS) in the originating network or from the LN

33、G. That location is then sent to the RDF to obtain routing information, which is returned by the LRF to the E-CSCF. If the call is delivered to the NENA i3 PSAP, the i3 PSAP may dereference the dispatch location from either the LS in the originating network or the LNG. If the call is delivered to a

34、legacy PSAP, the legacy PSAP obtains dispatch location by querying an LPG, which dereferences the LbyR by querying a LIS or LNG. 7.4 Route Determination Call routing is functionally equivalent in the NENA i3 and ATIS IMS-based NG9-1-1 Service Architectures. The routing determination function in NENA

35、 i3 is the ECRF, which is queried by the ESRP with location. The ESRP then uses the routing information to route the call towards the PSAP. The routing function in ATIS-0500032 is the RDF, which is queried by the LRF with location. The LRF returns the routing information to the E-CSCF so it can rout

36、e the call towards the PSAP. 7.5 Call Routing Call flows for ATIS-0500032 are shown in section 6. The primary differences in routing methodology between the NENA i3 architecture and the ATIS IMS-based NG9-1-1 Service Architecture relate to the placement of functionality. Using Figure 5.1 as a refere

37、nce, calls from legacy originating networks enter the LNG and the LNG forwards the call request to the E-CSCF. The E-CSCF queries the LRF for routing instructions and the LRF queries the RDF. When the E-CSCF obtains routing instructions, it forwards the call either to the NENA i3 PSAP or to the LPG.

38、 In comparison, when routing in an NENA i3 ESInet, calls from legacy originating networks enter the LNG and the LNG forwards the call request to the ESRP. The ESRP queries the ECRF for routing instructions. When the ESRP obtains routing instructions, it forwards the call either to the NENA i3 PSAP o

39、r to the LPG. Other call flow differences can be extrapolated from Figure 5.1. ATIS-0500033 24 8 Operational Considerations This section discusses operational considerations for the various stakeholders impacted by implementation of an IMS-based NG9-1-1 Service Architecture. 8.1 Originating Networks

40、 Originating networks supporting legacy interconnection methods will interface to the IMS-based NG9-1-1 Service Architecture through the LNG. IP-capable originating networks are expected to interconnect with the IMS-based NG9-1-1 Service Architecture through a BCF via a native SIP connection. Calls

41、originating in legacy wireline or wireless networks must undergo signaling interworking to convert the incoming MF or SS7 signaling to the IP-based SIP signaling supported by the IMS-based NG9-1-1 Service Architecture. Thus, the LNG supports a physical SS7 or MF interface on the side of the originat

42、ing network, and an IP interface which produces SIP signaling towards the IMS-based Next Generation Emergency Services Network, and must provide the protocol interworking functionality from the SS7 or MF signaling that it receives from the legacy originating network to the SIP signaling used in the

43、IMS-based Next Generation Emergency Services Network. Originating service providers are expected to deploy trunk facilities to the ingress side of the LNG. This may require moving trunks from existing Selective Routers to the LNG. Specifically, the originating service provider will deploy trunks to

44、the LNG in parallel with existing trunks connected to the Selective Router and then define a “cutover” date where the traffic is migrated. The appropriate databases must be provisioned before the transition. In general, the operational considerations are the same as for an LNG connected to a NENA i3

45、 ESInet. Calls originating from IP-capable originating networks will ingress to the IMS-based Next Generation Emergency Services Network via an IBCF. The originating service provider is expected to provide IP connectivity to the point of presence of the IMS-based Next Generation Emergency Services N

46、etwork. Specifically, the originating service provider will deploy IP connectivity and then define a “cutover” date where live traffic begins. In general, the operational considerations are the same as for IP traffic connected to a NENA i3 ESInet. 8.2 IMS-based NG9-1-1 Service Architecture Providers

47、 It is most likely that the provider of the IMS-based NG9-1-1 Service Architecture also offers a broader IMS implementation supporting IMS services. Therefore, operational considerations are incremental to the general network operations. Operations processes and procedures will need to be extended t

48、o support the gateways (LNG and LPG) and the IMS functional elements that play a critical role in providing 9-1-1-specific service capabilities (e.g. the LRF, LS, E-CSCF, etc.). In designing the IMS-based Next Generation Emergency Services Network that is part of the overall service architecture, th

49、e NG9-1-1 System Service Provider will need to make decisions regarding the way in which certain options described in ATIS-0500032 will be implemented. One such option is related to the mechanism used to support the transfer of emergency calls. ATIS-0500032 describes two alternatives for supporting emergency call transfer: one where B2BUA functionality is implemented in the originating network-facing IBCF, and a second where B2BUA functionality is implemented in the PSAP-facing IBCF. When transfer is implemented with B2BUA functionality at the originating network-facing IBCF