ATIS 0700028-2016 Location Accuracy Improvements For Emergency Calls (Version 1 1 Includes Access to Additional Content).pdf

《ATIS 0700028-2016 Location Accuracy Improvements For Emergency Calls (Version 1 1 Includes Access to Additional Content).pdf》由会员分享，可在线阅读，更多相关《ATIS 0700028-2016 Location Accuracy Improvements For Emergency Calls (Version 1 1 Includes Access to Additional Content).pdf（86页珍藏版）》请在麦多课文档分享上搜索。

1、 Confidential | Copyright 2016 IHS Markit Ltd Access to Additional Content For: ATIS-0700028.v1.1, Dated: 10/2016 (Click here to view the publication) This Page is not part of the original publication This page has been added by IHS Markit as a convenience to the user in order to provide access to a

2、dditional content as authorized by the Copyright holder of this document Click the link(s) below to access the content and use normal procedures for downloading or opening the files. ATIS-0700028.v1.1 Information contained in the above is the property of the Copyright holder and all Notice of Discla

3、imer February 3, 2015.1Ref 2 3GPP TS 23.167, IP Multimedia Subsystem (IMS) emergency sessions.2Ref 3 ATIS/TIA J-STD-036-C, Enhanced Wireless 9-1-1 Phase II, June 2011.3Ref 4 ATIS-0700015, ATIS Standard for Implementation of 3GPP Common IMS Emergency Procedures for IMS Origination and ESInet/Legacy S

4、elective Router Termination.41This document is available from the Federal Communications Commission at: . 2This document is available from the Third Generation Partnership Project (3GPP) at: . 3This document is available from the Alliance for Telecommunications Industry Solutions (ATIS), 1200 G Stre

5、et N.W., Suite 500, Washington, DC 20005, at: . ATIS-0700028 v1.1 2 Ref 5 3GPP TS 36.355, LTE Positioning Protocol (LPP).2Ref 6 OMA TS OMA-TS-LPPe-V1_0, LPP Extensions Specification.5Ref 7 3GPP TS 23.271, Functional stage 2 description of Location Services (LCS).2Ref 8 3GPP TS 36.305, Stage 2 functi

6、onal specification of User Equipment (UE) positioning in E-UTRAN.2Ref 9 3GPP TS 29.171, LCS Application Protocol (LCS-AP) between the Mobile Management Entity (MME) and Evolved Serving Mobile Location Centre (E-SMLC); SLs interface.2Ref 10 3GPP 29.172, Evolved Packet Core (EPC) LCS Protocol (ELP) be

7、tween the Gateway Mobile Location Centre (GMLC) and the Mobile Management Entity (MME); SLg interface.2Ref 11 OMA-TS-MLP-V3_5, Mobile Location Protocol 3.5.5Ref 12 IETF RFC 6753, A Location Dereferencing Protocol Using HELD, October 2012.6Ref 13 NENA 05-001, NENA Standard for the Implementation of t

8、he Wireless Emergency Service Protocol E2 Interface. Ref 14 IETF RFC 3265, Session Initiation Protocol (SIP)-Specific Event Notification.6Ref 15 OMA-AD-SUPL-V2_0, Secure User Plane Location Architecture.5Ref 16 OMA-TS-ULP-V2_0_3, UserPlane Location Protocol.5Ref 17 OMA-TS-ILP-V2_0_3, Internal Locati

9、on Protocol.5Ref 18 3GPP TS 36.455, LTE Positioning Protocol A (LPPa).2Ref 19 3GPP TS 23.401, General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access.2Ref 20 OMA-ERELD-SUPL-V2_0_3, SUPL 2.0, UserPlane Location Protocol.5Ref 21 3GPP TS

10、23.060, General Packet Radio Service (GPRS); Service description; Stage 2.2Ref 22 3GPP TS 25.305, Stage 2 functional specification of User Equipment (UE) positioning in UTRAN.2Ref 23 OMA-TS-ULP-V2_0_3, SUPL 2.0, UserPlane Location Protocol.5Ref 24 3GPP TS 23.272, Circuit Switched (CS) fallback, Evol

11、ved Packet System (EPS); Stage 2.2Ref 25 3GPP 25.331, Radio Resource Control (RRC); Protocol specification.2Ref 26 3GPP 24.008, Mobile radio interface Layer 3 specification; Core network protocols; Stage 3.2Ref 27 3GPP 23.018, Basic call handling; Technical realization.2Ref 28 IETF RFC 5985, HTTP-En

12、abled Location Delivery (HELD), September 2010.6Ref 29 IETF RFC 6155, Use of Device Identity in HTTP-Enabled Location Delivery (HELD), March 2012.6Ref 30 IETF RFC 4119, A Presence-based GEOPRIV Location Object Format, December 2005.6Ref 31 IETF RFC 5139, Revised Civic Location Format for Presence In

13、formation Data Format Location Object (PIDF-LO), February 2008.6Ref 32 IETF RFC 5491, GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations, March 2009.6Ref 33 IETF RFC 7540, Hypertext Transfer Protocol Version 2 (HTTP/2), May 201

14、5.6Ref 34 Bluetooth Special Interest Group, Bluetooth Core Specification v4.2, December 2014.7Ref 35 NENA-STA-004.1.1-2014, NENA Next Generation 9-1-1 (NG9-1-1) United States Civic Location Data Exchange Format (CLDXF) Standard, March 2014.84This document is available from the Alliance for Telecommu

15、nications Industry Solutions (ATIS), 1200 G Street N.W., Suite 500, Washington, DC 20005 at: . 5This document is available from the Open Mobile Alliance (OMA) at: . 6This document is available from the Internet Engineering Task Force (IETF) at: . 7This document is available from Bluetooth Special In

16、terest Group at: . 8This document is available from National Emergency Numbering Association (NENA) at: . ATIS-0700028 v1.1 3 Ref 36 FCC 4thReport and Order on Location Accuracy.9Ref 37 FCC Code of Federal Regulations (CFR) 47CFR20.18, 911 Service.10Ref 38 IETF RFC 6848, Specifying Civic Address Ext

17、ensions in the Presence Information Data Format Location Object (PIDF-LO), January 2013.6Ref 39 3GPP 25.413, UTRAN Iu interface Radio Access Network Application Part (RANAP) signalling.2Ref 40 3GPP 25.453, UTRAN Iupc interface Positioning Calculation Application Part (PCAP) signalling.2Ref 41 3GPP 2

18、9.002, Mobile Application Part (MAP) specification.2Ref 42 IETF RFC 4122, A Universally Unique IDentifier (UUID) URN Namespace, July 2005.63 Informative References The following standards contain provisions which, through reference in this text, constitute provisions of this ATIS Standard. At the ti

19、me of publication, 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 100 NENA-STA-010.2, Detailed Fun

20、ctional and Interface Standards for the NENA i3 Solution, September 10, 2016.11Ref 101 NENA ADM 000, NENA Master Glossary of 9-1-1 Terminology.124 Definitions, Acronyms, when it is set to one, it is a random address (static, non-resolvable private, or resolvable private address). For beacons, the ad

21、vertisers address should always be a public address (TxAdd = 0). In Bluetooth Low Energy (BLE), the total length of the device address is considered 49 bits because one of the bits that describes the type of the address is located in the PDU header as described above (separate from the device addres

22、s). In this Standard only public device addresses are considered which require 48 bits. 7.3 Interfaces This clause defines interfaces to the NEAD and NEAM. ATIS-0700028 v1.1 13 NOTE: Np, Nm, and Nq interfaces defined in this standard are specifically to be associated with the architecture of heighte

23、ned accuracy location for indoor E9-1-1 calls in North America and as such are not related to interfaces/Reference Points having the same name specified in 3GPP specifications (e.g., Nq Reference Point between MME and RCAF or Np Reference Point between RCAF and PCRF (see 3GPP TS 23.401 Ref 19). 7.3.

24、1 NEAD Query (Nq) Interface The Nq interface is the interface between the NEAD and a serving core network. The Nq interface supports discrete queries by a serving core network element to accumulate one or more candidate Dispatchable Locations and geocoded location information associated with Referen

25、ce Points visible to a UE that has originated an emergency call. The query will support a single Reference Point as input into the Nq query. If multiple Reference Points are being requested, the serving core network will query the NEAD for each Reference Point individually. The Nq interface is an in

26、ter-domain interface in that the operator of the NEAD is not the same as the serving core network provider. The Nq interface may support VPN or IP direct connect. It is recommended that the connection be persistent TCP/IP. Per RFC 5985 Ref 28, the connection must support TLS. In this version of the

27、standard, the URI of the NEAD is known at configuration time and does not require discovery. A response message sent from the NEAD, if successful, provides data provisioned in the NEAD for the Reference Point provided in the query. The data provided by the NEAD for the Reference Point comprises (i)

28、a civic address plus additional information such as floor, suite, apartment, or similar information (if available); (ii) a geocoded location determined by the NEAM based on the civic address; or (iii) an error code if no other data can be returned. The NEAD will provide either (i) and (ii) or (iii).

29、 The originator of the query (i.e., a Location Server in the serving core network) is responsible for reconciling disparate location information that may be returned for different Reference Points that are associated with the same emergency call (e.g., by using additional measurements provided by a

30、location service for a target UE) and for selecting the final Dispatchable Location, and/or geodetic location information provided by a location determination technology other than the NEAD. The protocol for this interface query mechanism is standard HTTP with the response message using HTTP-Enabled

31、 Location Delivery (HELD) (RFC 5985) Ref 28. The serving core network will query the NEAD with an HTTP GET message containing the identifier of the Reference Point. The NEAD will respond with a HELD locationResponse message providing a candidate Dispatchable Location and derived geocoded location13.

32、 If the NEAD responds with a civic location it will be in the form of Presence Information Data Format Location Object (PIDF-LO) (RFC 4119 Ref 30, updated by RFC 5139 Ref 31, RFC 6848 Ref 38, and RFC 5491 Ref 32). The PIDF-LO supplied from the NEAD contains a civic address along with a geocoded loca

33、tion determined by the NEAM based on the civic address. The response will also contain an IANA registered method token value as referenced in RFC 4119 Ref 30. The Nq interface only supports an HTTP GET method for which the identifier of the Reference Point is included as a parameter in the request m

34、essage. Since the HTTP GET contains a single Reference Identifier, the LS will create a Correlation Identifier parameter, Corr-ID, that will be associated with all of the Access Points and Bluetooth beacons observed by the UE. For all of those Access Points and Bluetooth beacons, the LS will send th

35、e same Corr-ID as a parameter in the GET Request Line to the NEAD. The Corr-ID, will be a UUID of the format ?Corr-ID=457e4567-e89b-12d3-a456-42665532873. Note that in response to location update requests from the emergency services network, the LS may obtain a new set of Access Point and Bluetooth

36、beacon identifiers and therefore will use a new Corr-ID in the requests to the NEAD. The Corr-ID UUID will be logged within the NEAD and may be used to perform post-query analysis of Access Point and/or Bluetooth beacon addresses. Note that, for example, if an Access Point or Bluetooth beacon is vis

37、ible to a UE, but has a location that is not within some geographic vicinity of the locations of other Access Points and/or Bluetooth beacons visible to the UE, the Access Point or Bluetooth beacon location is probably incorrect (e.g., because the Access Point or Bluetooth beacon was moved and not u

38、pdated within the NEAD). The Nq interface implements HTTP/2 as defined in RFC 7540 Ref 33 which allows asynchronous requests and responses. Streams in HTTP/2 allow the ability to 1) interleave multiple requests in parallel without blocking any one and 2) interleave multiple responses in parallel wit

39、hout blocking any one. The Nq interface implements streams to facilitate the advantages of HTTP/2. 13This document refers to a geodetic position produced via a geocoding process as “geocoded location”. ATIS-0700028 v1.1 14 locationRequest Parameters The following request parameters are supported: Ge

40、tAddress This parameter represents the identifier of the Reference Point. The Reference Point identifier shall be represented as a string of hexadecimal digit pairs separated by hyphens or colons. Corr-ID This parameter correlates all Access Points and Bluetooth beacons observed by the UE at one pos

41、itioning instance. The Corr-ID shall be represented as a UUID per RFC 4122 Ref 42. locationResponse Parameters The following response parameters are supported: Presence parameter This is the PIDF-LO format that contains the candidate Dispatchable Location and geocoded location. Code For error codes

42、see below. Message The message parameter is free format and not standardized. Method element parameter associated with the geocoded location included in the PIDF-LO. The following response parameters are not supported: None. Method Element Parameter The following Method Element Parameter values are

43、supported. The Method Element Parameter, or “token” is defined within the IANA Method Token registry per RFC 4119 Ref 30 and conveyed in the HELD location response message. It describes the way the location information was derived or discovered. Table 7.1 Supported Method Element Parameters Token De

44、scription Reference Registration Date NEAD-WiFi Civic Address representing the provisioned location of a Wi-Fi Access Point to support the dispatching of emergency services. ATIS/WTSC-ELOC* TBD NEAD-BLE Civic Address representing the provisioned location of a Bluetooth beacon to support the dispatch

45、ing of emergency services. ATIS/WTSC-ELOC* TBD An xml example: NEAD-BLE * NOTE: Reference IANA registry URL for location method token values: https:/www.iana.org/assignments/method-tokens/method-tokens.xhtml#method-tokens-1 This registry value is added on a first-come, first-served basis. Error Resp

46、onse Messages ATIS-0700028 v1.1 15 HELD errors are application level errors and returned in a HTTP 200 OK response. The following table describes the error codes from RFC 5985 Ref 28 (except as noted) applicable to this standard. Table 7.2 Applicable Error Codes from RFC 5985 Error Code Description

47、Comment RequestError “This code indicates that the request was badly formed in some fashion (other than the XML content).” xmlError “This code indicates that the XML content of the request was either badly formed or invalid.” Not used in this standard. generalLisError “This code indicates that an un

48、specified error occurred at the LIS.” LIS in this context corresponds to the NEAD. locationUnknown “This code indicates that the LIS could not determine the location of the Device. The same request can be sent by the Device at a later time. Devices MUST limit any attempts to retry requests.” This er

49、ror code is not used in this standard. It implies that the requestor may re-query for location. unsupportedMessage “This code indicates that an element in the XML document for the request was not supported or understood by the LIS. This error code is used when a HELD request contains a document element that is not supported by the receiver.” LIS in this context corresponds to the NEAD. Timeout “This code indicates that the LIS could not satisfy the