ATIS 0500017-2009 Considerations for an Emergency Services Next Generation Network (ES-NGN).pdf

《ATIS 0500017-2009 Considerations for an Emergency Services Next Generation Network (ES-NGN).pdf》由会员分享，可在线阅读，更多相关《ATIS 0500017-2009 Considerations for an Emergency Services Next Generation Network (ES-NGN).pdf（31页珍藏版）》请在麦多课文档分享上搜索。

1、 TECHNICAL REPORT ATIS-0500017 Considerations for an Emergency Services Next Generation Network (ES-NGN) ATIS is the leading technical planning and standards development organization committed to the rapid development of global, market-driven standards for the information, entertainment and communic

2、ations industry. More than 250 companies actively formulate standards in ATIS 20 Committees, covering issues including: IPTV, Service Oriented Networks, Home Networking, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, Billing and Operational Support. In addition, numerous

3、Incubators, Focus and Exploratory Groups address emerging industry priorities including “Green”, IP Downloadable Security, Next Generation Carrier Interconnect, IPv6 and Convergence. ATIS is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a member and maj

4、or U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications Sectors, and a member of the Inter-American Telecommunication Commission (CITEL). For more information, please visit . Notice of Disclaimer IMS Emergency Sessions (Release 7.11), December 2008.12 3GPP

5、 TR23.868, 3GPP Technical Specification Group Services and System Aspects; IMS Emergency Sessions (Release 9.0), December 2008.13 ATIS-1000018, NGN Architecture, February 2007.24 ATIS Next Generation Network (NGN) Framework, Part I: NGN Definitions, Requirements and Architecture, November 2004.25 AT

6、IS Next Generation (NGN) Framework Part II: NGN Roadmap 2005, August 2005.26 ATIS Next Generation (NGN) Framework Part III: Standards Gap Analysis, May 2006.27 Framework for Emergency Calling using Internet Multimedia, IETF, draft-ietf-ecrit-framework-06, July 2008.38 LoST: A Location-to-Service Tra

7、nslation Protocol, RFC 5222, IETF, August 2008.39 A Presence-based GEOPRIV Location Object Format, RFC 4119, IETF, December 2005.310 Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO), RFC 5139, February 2008.311 NENA 08-001, Interim VoIP Architecture for En

8、hanced 9-1-1 Services (i2), December 6, 2005.412 NENA 08-505, Recommended Methods for Location Determination to Support IP-Based Emergency Services, December 21, 2006.413 NENA 08-751, Technical Requirements Document i3 (Long Term Definition), September 28, 2006.414 NENA 08-002, NENA Functional and I

9、nterface Standards for Next Generation 9-1-1, NENA, December 18, 2007.415 NENA 08-xxx, Detailed Functional and Interface Standards for Next Generation 9-1-1 Version 1.0 (i3), To be published.416 3GPP2 X.P0049-000-01, All-IP Emergency Services, 3GPP2, December 2006.517 Security Threats and Requiremen

10、ts for Emergency Call Marking and Mapping, RFC 5069, IETF, January 2008.318 HTTP Enabled Location Delivery (HELD), IETF, September 8, 2008.319 ATIS-1000009.2006, IP Network-to-Network Interface (NNI) Standard for VoIP, May 2006.220 ATIS-1000026.2008, Session/Border Control Functions and Requirements

11、, April 2008.221 ATIS-1000025.2008, US Standard for Signaling Security UNI Access and Signaling Standard, March 2008.222 Location Conveyance for the Session Initiation Protocol, IETF, November 19, 2008.323 Best Current Practice for Communications Services in support of Emergency Calling, IETF, Novem

12、ber 3, 2008.324 Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments, IETF, October 23, 2008.325 ETSI ES 282 004, Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Functional Architecture; Network Attachment Sub-S

13、ystem (NASS).61This document is available from the Third Generation Partnership Project (3GPP) via http:/www.3gpp.org 2This document is available from the Alliance for Telecommunications Industry Solutions (ATIS) via https:/www.atis.org/docstore 3This document is available from the Internet Engineer

14、ing Task Force (IETF) via http:/www.ietf.org 4This document is available from the National Emergency Number Association (NENA) via http:/www.nena.org 5This document is available from the Third Generation Partnership Project 2 (3GPP2) via http:/www.3gpp2.org 6This document is available from the Europ

15、ean Telecommunications Standards Institute via http:/www.etsi.org ATIS-0500017 4 3 DEFINITIONS, ACRONYMS, or any combination of those. Emergency Services IP network (ESInet) - NENA i3 introduces the concept of an Emergency Services IP network (ESInet), which is designed as an IP-based inter-network

16、(network of networks) shared by all agencies which may be involved in any emergency. Location Information Server (LIS) (3GPP uses the term Location Server) - - (per NENA): A Location Information Server (LIS) is a functional entity that provides locations of endpoints. A LIS can provide Location-by-R

17、eference, or Location-by-Value, and, if the latter, in geo or civic forms. A LIS can be queried by an endpoint for its own location, or by another entity for the location of an endpoint. In either case, the LIS receives a unique identifier that represents the endpoint, for example an IP address, cir

18、cuit-ID or MAC address, and returns the location (value or reference) associated with that identifier. The LIS is also the entity that provides the dereferencing service, exchanging a location reference for a location value. - (per 3GPP): The 3GPP version of a LIS is called a Location Server (e.g.,

19、GMLC). Location Retrieval Function (LRF): This functional entity handles the retrieval of location information for the UE including, where required, interim location information, initial location information and updated location information. The LRF may interact with a separate RDF or contain an int

20、egrated RDF in order to obtain routing information. The LRF may interact with a separate GMLC or contain an integrated GMLC in order to obtain location information. The LRF may interact with or contain other types of location server functions in order to obtain location information. Routing Determin

21、ation Function (RDF): The functional entity, which may be integrated in a Location Server (e.g. GMLC) or in an LRF, provides the proper PSAP destination address to the E CSCF for routing the emergency request. It can interact with a location functional entity (e.g. GMLC) to manage ESQK allocation an

22、d management, and deliver location information to the PSAP. - (Per IETF): A Location Information Server stores location information for retrieval by an authorized entity. Location Object (LO) The LO is the physical location of the emergency caller that may be used for routing decisions and is delive

23、red to the IP PSAP with the call. It may be expressed in civic ATIS-0500017 5 or geodetic formats and is represented as the Presence Identifier Data Format Location Object (PIDF-LO) and defined in 9. Location Reference The Location Reference may be passed in the SIP signaling as a location key and u

24、sed to acquire (dereference) the Location Object. Public Safety Answering Point (PSAP) PSAP is used generically in this Technical Report to mean the entity that receives the emergency call for the purpose of managing an incident. The PSAP consists of a collection of equipment, procedures and resourc

25、es to process the emergency call and may receive emergency calls via legacy signaling methods or via IP connections defined within the context of NG9-1-1. This use is not intended to restrict the application to physical premises. Primary PSAP The primary PSAP is the PSAP that is determined through P

26、SAP selection to receive the emergency call. It is determined to be the “appropriate” PSAP to manage the request. 3.2 Acronyms Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS) emergency sessions (Release 7) 1defines the stage-2 service description for emergenc

27、y services in the IP Multimedia Core Network Subsystem (IMS), including the elements necessary to support IP Multimedia (IM) emergency services. This document covers also the Access Network aspects that are crucial for the provisioning of IMS emergency services. 3GPPs specification does not address

28、IMS as the emergency services network, but as the originating network. Figure 4-3 below is extracted from 1 and is the reference architecture from that specification. There are two attributes to this architecture: 1) routing functional elements and 2) location retrieval and routing determination fun

29、ctional elements. The Location Retrieval Function (LRF) is responsible for retrieving the location information of the UE that has initiated an IMS emergency session. It shall be possible to support configurations where the Location Retrieval Function (LRF) may consist of a Routing Determination Func

30、tion (RDF) and a Location Server (e.g. GMLC), the interface between Location Server and RDF is out of scope of this specification. The LRF utilizes the RDF to provide the routing information to the E-CSCF for routing the emergency request. The RDF can interact with a location functional entity (e.g.

31、, GMLC) and manage ESQK allocation and management. The ESQK is used by the PSAP to query the LRF for location information and optionally a callback number. The LRF-PSAP interactions are outside the scope of this specification. Information provided by the LRF to the E-CSCF includes the routing inform

32、ation and other parameters necessary for emergency services, which are subject to local regulation. For example, this information may include the ESQK, ESRN, LRO in North America, location number in EU, PSAP SIP-URI or TEL-URI. In order to provide the correct PSAP destination address to the E-CSCF,

33、the LRF may require interim location information for the UE. In some regions, for example in the North American region, it may be a requirement to provide the PSAP with an accurate initial location estimate for the UE and possibly to provide an accurate updated location estimate for the UE if reques

34、ted by the PSAP. When this requirement exists, the LRF may store a record of the emergency session including all information provided by the E-CSCF and shall only release this record when informed by the E-CSCF that the emergency session has terminated. The information provided by the LRF to the E-C

35、SCF (e.g. ESQK) shall then include correlation information identifying both the LRF and the emergency session record in the LRF. This correlation information shall be transferred to the PSAP during session establishment (e.g. in a SIP INVITE or via SS7 ISUP ATIS-0500017 10 signalling from the MGCF).

36、 The PSAP may use this information to request an initial location estimate from the LRF and/or to request an updated location estimate. Figure 4-3 E-CSCF in Reference Architecture The NENA i2 functionality is referenced in 11. TS 23.167 introduces the concept of an Emergency Call Server (ECS) to acc

37、ommodate the NENA i2 functionality in informative Appendices D1 and D2. The ECS functional entity consists of a Location Retrieval Function (LRF) and either a routing proxy or a redirect server. An Emergency Call Server (ECS) contains a VoIP Positioning Center (VPC) and a Routing Proxy or Redirect S

38、erver as defined in the NENA i2 architecture. For this option, location information is not needed to route the emergency call by the IMS core, optionally the emergency routing determination and location information retrieval may be performed by the Emergency Call Server as part of the emergency sess

39、ion establishment procedure. In this case, the IMS core does not need to obtain the location information. Figure 4-4 illustrates one of the call flows described in Annex D of 1. ATIS-0500017 11 Figure 4-4 TS23.167 Figure D.2 Annex C of 1 specifies normative standards for IMS emergency services using

40、 Fixed Broadband Access. These procedures described in this annex apply when the IP CAN contains a Network Attachment Subsystem with a CLF as specified in ETSI ES 282 004. 4.6 3GPP2 The 3GPP2 specification titled All-IP Emergency Services presents a recommended plan for providing Emergency Services

41、in a 3GPP2 Multimedia Domain (MMD) network 16. This document defines the stage-2 service description for emergency services in the IP Multimedia Core Network Subsystem (IMS), including the elements necessary to support IP Multimedia (IM) emergency services. This specification relies heavily on the w

42、ork within 3GPP that is defining IMS. This document covers also the Access Network aspects that are crucial for the provisioning of IMS emergency services. For the current phase of emergency call support, it is assumed that PSAPs support only Circuit-Switched (CS) calling capability, i.e. they are n

43、ot equipped for SIP based (VoIP) call origination and termination. In the future more capable PSAPs may come into being, which will have SIP based call handing and VoIP support, and possibly also the capability to send and receive other types of media (e.g. pictures with escape routes, video, etc).

44、This may be the subject of a future revision of this and other associated documents. ESIF acknowledges that IP capable PSAPs are closer to reality than might be implied by the 3GPP2 assumption shown here. 4.7 NENAs i3 Definition NENA has three primary working groups under the Voice over Internet Pro

45、tocol and Packet Committee. The Migratory Definition Working Group was responsible for defining NENAs i2 standard 11. The VoIP Location Working Group defines location determination methods 12. NENA ATIS-0500017 12 VoIP Long Term Definition Working Group has defined requirements for NENAs i3 architec

46、ture 13and a functional interface specification 14. NENA is currently working on the stage 3 for the i3 architecture in general, but that does not include IMS related stage 3 work. The NENA i3 architecture is shown in Figure 4-5. There are two primary components: the Emergency Control Routing Functi

47、on (ECRF) and the Emergency Services Routing Proxy (ESRP). The ECRF receives location information (either civic address or geo-coordinates) as input and uses this information to provide a URI that can be used to route an emergency call toward the appropriate PSAP with the callers location. Depending

48、 on the identity and credentials of the entity requesting the routing information, the response may identify the PSAP, or an Emergency Services Routing Proxy (ESRP) that acts on behalf of the PSAP to provide final routing to the PSAP itself. The same database that is used to route a call to the corr

49、ect PSAP may also be used to subsequently route the call to the correct responder, e.g., to support selective transfer capabilities. The ESRP is an i3 functional element which is a SIP proxy server that selects the next routing hop within the ESInet based on location and routing policy. There is an ESRP on the edge of the ESInet. There is usually an ESRP at the entrance to an NG9-1-1 PSAP. There may be one or more intermediate ESRPs between them. For the architecture of Figure 4-5 the Us