ATIS 0500036-2018 ATIS Standard for IMS-based Next Generation Emergency Services Network Interconnection.pdf

1、 ATIS-0500036 ATIS Standard for IMS-based Next Generation Emergency Services Network Interconnection Alliance for Telecommunications Industry Solutions Approved July 2018 Abstract This Standard defines the Stage 2 (architecture) and Stage 3 (protocol) specifications for the interconnection of an IMS

2、-based NG9-1-1 Emergency Services Network with legacy and other Next Generation NG9-1-1 Emergency Services Networks for initial emergency call origination and call transfers (bridging). This Standard is incremental to ATIS-0500032, ATIS Standard for Implementation of an IMS-based NG9-1-1 Service Arc

3、hitecture, in that it focuses on the interactions between the IMS-based NG9-1-1 Emergency Services Networks and other emergency services networks. ATIS-0500032 includes the architecture, functional elements, call flows, protocols and interfaces which were derived from the Stage 1 requirements in ATI

4、S-0500023, Applying Common IMS to NG9-1-1 Networks. This Standard expands upon those principles to specify interactions between emergency services networks. ATIS-0500036 ii Foreword The Alliance for Telecommunication Industry Solutions (ATIS) serves the public through improved understanding between

5、carriers, customers, and manufacturers. The ESIF IP Multimedia Subsystem for 9-1-1 (IMS911) subgroup led the development of this document. This is a joint effort with the Emergency Services Interconnection Forum Next Generation Emergency Service (ESIF NGES) Subcommittee, Packet Technologies and Syst

6、ems Committee (PTSC), and the Wireless Technologies and Systems Committee Systems and Network Subcommittee (WTSC SN). The Emergency Services Interconnection Forum (ESIF) provides a forum to facilitate the identification and resolution of technical and/or operational issues related to the interconnec

7、tion 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 industry forum/committees, within and outside ATIS, and develops emergency

8、 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 Packet Technologies and Systems Committees (PTSC) develops and recommends standards and technical rep

9、orts related to services, architectures, and signaling, in addition to related subjects under consideration in other North American and international standards bodies. PTSC coordinates and develops standards and technical reports relevant to telecommunications networks in the U.S., reviews and prepa

10、res contributions on such matters for submission to U.S. ITU-T and U.S. ITU-R Study Groups or other standards organization, and reviews for acceptability or per contra the positions of other countries in related standards developments and takes or recommends appropriate actions. The Wireless Technol

11、ogies and Systems Committee (WTSC) develops and recommends standards and technical reports related to wireless and/or mobile services and systems, including service descriptions and wireless technologies. WTSC develops and recommends positions on related subjects under consideration in other North A

12、merican, regional, and international standards bodies. The WTSC Systems and Networks Subcommittee (WTSC SN) develops, maintains, amends, and enhances American National Standards and ATIS deliverables related to systems aspects, networks, and terminals within the GSM family (GSM/EGPRS/UMTS) such as c

13、ircuit-switched, packet-switched, and IP Multimedia services including future developments. Suggestions for improvement of this document are welcome. They should be sent to the Alliance for Telecommunications Industry Solutions, ESIF, 1200 G Street NW, Suite 500, Washington, DC 20005. At the time of

14、 consensus on this document, the committees responsible for its development, had the following leadership: R. Hixson, ESIF Chair (NENA) R. Marshall, ESIF First Vice-Chair (Comtech) J. Green, ESIF Second Vice-Chair (Sprint) C. Militeau, ESIF IMS911 Co-Chair (West Safety Services) T. Reese, ESIF IMS91

15、1 Co-Chair (Ericsson) M. Dolly, PTSC Chair (AT IP Multimedia Subsystem (IMS) emergency sessions.3 Ref 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

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

17、em Aspects; Functional Stage 2 description of Location Services (LCS).3 Ref 6 IETF RFC 5222, LoST: A Location-to-Service Translation Protocol.4 Ref 7 J-STD-036-C, Enhanced Wireless 9-1-1 Phase II, June 2011 including the addendum in J-STD-036-C-2, Addendum to J-STD-036-C, Enhanced Wireless 9-1-1 Pha

18、se II.5 Ref 8 IETF RFC 6753, A Location Dereferencing Protocol Using HELD.4 Ref 9 3GPP TS 24.147, Technical Specification Group Core Network and Terminals; Conferencing using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3.3 3 This document is available from the Third Generation Partners

19、hip Project (3GPP) at: . 4 This document is available from the Internet Engineering Task Force (IETF) at: . 5 This document is available from the Alliance for Telecommunications Industry Solutions (ATIS), 1200 G Street N.W., Suite 500, Washington, DC 20005 at: . ATIS-0500036 3 Ref 10 IETF 4353, A Fr

20、amework for Conferencing with the Session Initiation Protocol (SIP).4 Ref 11 ATIS-1000679.2015, Interworking between Session Initiation Protocol (SIP) and Bearer Independent Call Control or ISDN User Part.5 Ref 12 IETF RFC 6442, Location Conveyance for the Session Initiation Protocol.4 Ref 13 IETF R

21、FC 3265, Session Initiation Protocol (SIP) Specific Event Notification.4 Ref 14 IETF RFC 3261, SIP: Session Initiation Protocol.4 Ref 15 3GPP TS 23.228, Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2.3 Ref 16 IETF RFC 4112, Communications Resource P

22、riority for the Session Initiation Protocol (SIP).4 Ref 17 IETF RFC 7134, The Management Policy of the Resource Priority Header (RPH) Registry Changed to “IETF Review“.4 Ref 18 IETF RFC 4579, Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents.4 Ref 19 IETF RFC 7044, An Ext

23、ension to the Session Initiation Protocol (SIP) for Request History Information.4 Ref 20 IETF RFC 3455, Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP).4 Ref 21 IETF RFC 3325, Private Extensions to the Session Initiation

24、 Protocol (SIP) for Asserted Identity within Trusted Networks.4 Ref 22 ATIS-0500023, Applying Common IMS to NG9-1-1 Networks.5 Ref 23 NENA-STA-010.2, Detailed Functional and Interface Standards for the NENA i3 Solution.6 Ref 24 IETF RFC 2616, Hypertext Transfer Protocol - HTTP/1.1.4 Ref 25 3GPP TS 2

25、9.333, Technical Specification Group Core Network and Terminals; Multimedia Resource Function Controller (MRFC) - Multimedia Resource Function Processor (MRFP) Mp interface: Procedures Descriptions.3 Ref 26 ATIS-0500032, ATIS Standard for Implementation of a 3GPP IMS-based NG9-1-1 Emergency Services

26、 Network.5 Ref 27 NENA-STA-010.3, Detailed Functional and Interface Standards for the NENA i3 Solution, pending publication.7 3 Informative References The following standards contain provisions which, through reference in this text, constitute provisions of this ATIS Standard. At the time of publica

27、tion, 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 101 NENA-ADM-000.21.1-2018, NENA Master Gloss

28、ary of 9-1-1 Terminology.6 Ref 102 NENA 03-003 NENA Recommendation for Implementation of Inter-Networking, E9-1-1 Tandem to Tandem, February 1, 2000.6 Ref 103 NENA-INF-008.1 NENA NG9-1-1 Transition Plan Information Document.6 6 This document is available from the National Emergency Number Associatio

29、n at: . 7 This document will be available upon publication from the National Emergency Number Association at: . ATIS-0500036 4 4 Definitions, Acronyms, emergency call transfers involving legacy PSAPs; ALI queries from legacy PSAPs; and location and additional data dereferencing functionality. Locati

30、on by Reference (LbyR) 1. 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 the caller. 2. Location by Value (LbyV) 3. Location by Value r

31、efers to the option to deliver the callers location to the PSAP within the body of the call request (SIP INVITE). 4. NG9-1-110 5. An IP-based system comprised of managed IP-based networks (ESInets), functional elements (applications), and databases that replicate traditional E9-1-1 features and func

32、tions 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.9 8 Refer to NENA-ADM-000.21.1-2018, NENA Master Glossary of 9

33、-1-1 Terminology Ref 101. 9 Refer to NENA i3/NG9-1-1 Ref 23. 10 The term “NG911” used throughout this document is synonymous with the term “NG9-1-1”. ATIS-0500036 5 6. pANI (Pseudo Automatic Number Identification) 7. A telephone number used to support routing of wireless 9-1-1 calls. It may identify

34、 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. 8. Reference Identifier 9. The term “Reference Identifier“ is used in this standard to associate the call with locati

35、on 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 by the legacy emergency ser

36、vices 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 URI that is used b

37、y i3 functional elements and i3 PSAPs to obtain location.11 4.2 Acronyms specifically, what information is sent between the networks. There are two sets of scenarios: initial calls that are received by one emergency services network and forwarded to another and calls that are transferred between a P

38、SAP served by one network and a PSAP served by another. The terms Upstream IMS-based NG9-1-1 Emergency Services Network and Downstream IMS-based NG9-1-1 Emergency Services Network are used in the discussion. For an initial call that enters the Upstream IMS-based NG9-1-1 Emergency Services Network th

39、ere may be a need to forward that call to another IMS-based NG9-1-1 Emergency Services Network (i.e. the Downstream IMS-based NG9-1-1 Emergency Services Network). There may also be a need for a PSAP served by the Upstream IMS-based NG9-1-1 Emergency Services Network to transfer a call to a PSAP in a

40、nother IMS-based NG9-1-1 Emergency Services Network (i.e. Downstream IMS-based NG9-1-1 Emergency Services Network). For the interactions between an IMS-based NG9-1-1 Emergency Services Network and a legacy Emergency Services Network or i3 NG9-1-1 Emergency Services Network there may be a need to eit

41、her send initial calls or bridged calls in either direction. 8.1 Initial Call to an Upstream IMS-based NG9-1-1 Network Emergency Services Forwarded to a Downstream IMS-based NG9-1-1 Emergency Services Network Figure 8.1 and Figure 8.2 illustrate a scenario where a call enters the Upstream IMS-based

42、NG9-1-1 Emergency Services Network and is delivered to the Downstream IMS-based NG9-1-1 Emergency Services Network. Specifically, when the LRF in the Upstream IMS-based NG9-1-1 Emergency Services Network queries the RDF (Step 5) the RDF determines that, for this location, the call should be handed o

43、ff to the Downstream IMS-based NG9-1-1 Emergency Services Network for processing. There may also be a scenario where the Policy Routing ATIS-0500036 18 Function (PRF) in the LRF determines the call should be handed off to the Downstream IMS-based NG9-1-1 Emergency Services Network. Therefore, the LR

44、F returns a Route URI that specifies the Downstream IMS-based NG9-1-1 Emergency Services Network. The call is delivered to the Downstream IMS-based NG9-1-1 Emergency Services Network and it routes the call based upon the location provided. In this call flow example, the SIP INVITE from the Upstream

45、IMS-based NG9-1-1 Emergency Services Network to the Downstream IMS-based NG9-1-1 Emergency Services Network (Step 9) contains (at a minimum) the following headers: sos in the Request Line Route URI that points to the well-known ingress IP address (domain) of the Downstream IMS-based NG9-1-1 Emergenc

46、y Services Network From representing the callback number To as sip:911domain P-Asserted-Identity representing the callback number Location by Value in the INVITE body represented by a Geolocation header Geolocation-Routing header set to “yes” NENA Call ID in a Call-Info header NENA Incident ID in a

47、Call-Info header Potentially Additional Data in the body represented by a Call-Info header. Other normal SIP INVITE headers (e.g., Via, Call-ID, etc.). Figure 8.1: Initial Call Upstream IMS-based NG9-1-1 Emergency Services Network to Downstream IMS-based NG9-1-1 Emergency Services Network 1 Step 1.

48、The IBCF in the originating network sends an emergency call origination to an (ingress) IBCF in the IMS-based NG9-1-1 Emergency Services Network. The SIP INVITE message includes a Route header that contains the I-CSCF URI, an emergency services service URN (urn:service:sos), callback information, Lb

49、yV, and Additional Data (by value). Step 2. The (ingress) IBCF forwards the received INVITE message to the I-CSCF. ATIS-0500036 19 Step 3. The I-CSCF forwards the SIP INVITE to the pre-configured E-CSCF. The SIP INVITE message sent to the E-CSCF by the I-CSCF contains the E-CSCF URI in the Route header, and includes the callback information, “sos” service URN, LbyV, and Additional Data (by value), as received in the incoming SIP INVITE message. Step 4. The E-CSCF forwards the SIP INVITE to the LRF.