1、 ATIS-0700031 ATIS Standard on - Location and Routing Support for Non-Operator-Managed Over the Top (OTT) Citizen-to-Authority Emergency Services As a leading technology and solutions development organization, the Alliance for Telecommunications Industry Solutions (ATIS) brings together the top glob
2、al ICT companies to advance the industrys 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, n
3、etwork evolution, quality of service, 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
4、testing. ATIS is accredited by the 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 Internat
5、ional Telecommunication Union (ITU), as well as a member of the Inter-American Telecommunication Commission (CITEL). For more information, visit www.atis.org. Notice of Disclaimer Functional Stage 2 description of Location Services (LCS).31This document is available from the Alliance for Telecommuni
6、cations Industry Solutions (ATIS), 1200 G Street N.W., Suite 500, Washington, DC 20005 at: . 2This document is available from the Internet Engineering Task Force (IETF) at: . 3This document is available from the Third Generation Partnership Project (3GPP) at: . ATIS-0700031 2 3 Informative Reference
7、s 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 Standard are encouraged to in
8、vestigate the possibility of applying the most recent editions of the standards indicated below. Ref 100 NENA 08-003, Detailed Functional and Interface Standards for the NENA i3 Solution, June 14, 2011.4Ref 101 NENA ADM 000, NENA Master Glossary of 9-1-1 Terminology.54 Definitions, Acronyms, alterna
9、tive S2 can be used when the UE does not detect that a user is invoking an emergency call or does not have enough time to obtain location information prior to sending an emergency service request to the OTT SP. Both S1 and S2 may be used in the same session. For example, using alternative S1, a UE m
10、ay provide whatever location value it currently has in the initial SIP INVITE and may also indicate support for an in-call request and response mechanism. During the call, the OTT SP may use this mechanism to request location information. The UE would then respond with updated location. The emergenc
11、y Location Server for alternatives S1 and S2 could be an Location Retrieval Function (LRF) since this already supports an external interface for location dereferencing and could have access to location determination capability inside a serving MNO using a control plane solution and/or user plane sol
12、ution. 7.1.1 High Level Analysis of Alternatives S1 particular sub-fields in the IP address may be configured by the OTT service provider or other parameters to be used to map to a particular AN or PCN. For S3, when the UE initiates an emergency request, the request is forwarded to the OTT SP throug
13、h the PCN. Once the location server has been discovered, the OTT SP queries it directly using the client IP address to obtain the UE location. For S3a and S3b, when the UE initiates an emergency request, it is forwarded to the OTT SP through the Packet Core Network. The OTT SP then queries the CMRS
14、network (either the AN or PCN) for location. The OTT SP may query with MSISDN or the UE IP address. The AN or PCN then interrogates the location server for the UE location. 7.2.1 High Level Analysis of Alternatives S3, S3a, alternative S2 can be used when the UE does not detect that a user is invoki
15、ng an emergency call or does not have enough time to obtain location information prior to sending an emergency service request to the OTT SP. The ELS for alternatives S1 and S2 could be an LRF since this already supports an external interface for location dereferencing and could have access to locat
16、ion determination capability inside a serving MNO using a control plane solution and/or user plane solution. In order to solve a number of problems described further down here, alternatives S1 and S2 are extended further here to allow a UE to provide additional location related information to an OTT
17、 SP and not just LbyV or LByR. In addition, while the UE remains the source of all initial location information to the OTT SP, the OTT SP is allowed to receive additional location related information and/or other assistance from the serving MNO as well. The end result is to make alternatives S1 and
18、S2 more generic and more capable than was earlier proposed. 7.3.2 Limitations on Supporting Location it can be initiated by a malicious attacker who either infiltrates the OTT SP, or spoofs the OTT SP NNI to the application running on the device to obtain the emergency location. This attack vector c
19、an be present in alternatives S2, S3, and S4 in clause 7. 8.2.3 Fake Location Reporting This attack vector is characterized when an OTT communication on the device is able to report a false location for the caller in an emergency service call. It can be initiated either by the user deliberately modi
20、fying the location that is reported or can be the result of malware or other attack infiltrating the device affecting applications running on the device. This attack vector is enabled when the location to report is processed in the user application level on the device or transferred over the user pl
21、ane in an unsecured and unauthenticated fashion. This attack vector can be present in alternatives S1 and S2 described in clause 7. ATIS-0700031 23 8.3 Security & Privacy Solutions Further work on approaches need to address the security capabilities listed below: Trust and security on the mobile dev
22、ice. Trust, security, and authentication between networks (NNI). Compliance with CPNI and privacy regulations. DDoS mitigation. 9 Conclusions This clause provides conclusions and recommendations. Five alternative solutions are identified and summarized in clause 7 for supporting location acquisition
23、 and routing of an emergency services call in a Public Switched Telephone Network (PSTN)-interconnected OTT SP. These alternatives are labelled S1, S2, S3, S4, and S5. Detailed examples of solutions S1 and S2 are also described and evaluated in clause 7. The summaries and detailed examples show that
24、 supporting location acquisition and routing of an emergency services call in an OTT SP may be technically possible with routing to the correct PSAP and providing of a potentially accurate initial UE location also supported. However, there has not been any detailed evaluation of the relative merits
25、of the different alternatives (e.g., in terms of impacts to the access network operator, OTT SP, and UE) nor has there been an evaluation of security and privacy aspects. Finally, there has not been any consideration for non-PSTN interconnected OTT SPs such as those highlighted in the high-level use
26、 cases in annex A.1. It is therefore recommended that as a next phase in developing a preferred solution or solutions that further more detailed evaluations be performed to provide a solution(s) suitable for access network operators and at least PSTN-interconnected OTT SPs, as well as identifying so
27、lutions that may apply to non-PSTN interconnected OTT SPs. ATIS-0700031 24 Annex A: Use Cases (informative) A.1 High Level Use Cases A.1.1 OTT User Identity Use Cases These use cases describe different ways that OTT VoIP and ToIP services identify service users. These scenarios will need to be consi
28、dered when the user of the OTT service invokes an OTT emergency service (voice or text messaging) and location acquisition, conveyance, and dereferencing is needed for the emergency service request. Note for the use cases in this clause: 1. These use cases apply equally to VoIP and ToIP. 2. The PSTN
29、 is assumed to be either CS or regulated and interconnected VoIP service8. 3. An OTT service provider may support several different user identity scenarios simultaneously. 4. An OTT service user may have multiple identities, each fitting in a different user identity scenario. A.1.1.1 Interconnected
30、OTT Uses a Separate E.164 Number Description This OTT service assigns a unique E.164 number to the user. Pre-conditions The OTT service is interconnected to the PSTN or an SMS routing gateway. The OTT service assigns a unique E.164 number to users who want to communicate with non-OTT service users t
31、hrough the PSTN or SMS. This number is different from the E.164 number assigned to the UE by the CMRS provider for CMRS voice, SMS, or Multimedia Messaging Service (MMS) services. The same user identity (E.164 number) can be used on multiple devices. The user identity can be used on any IP-capable d
32、evices without any CMRS network support such as Wi-Fi only tablets without Universal Subscriber Identity Modules (USIMs) or IP Multimedia Services Identity Module (ISIMs). Actors User A is using an OTT service through his UE. Post-conditions User A is communicating with a call taker in the PSAP desc
33、ribing the emergency over a VoIP or ToIP session at least to the OTT service Point of Presence. Normal flow 1. User A initiates an OTT emergency call or text messaging session using his OTT service provider assigned E.164 number, not the CMRS provider E.164 number assigned to the UE. 2. The OTT serv
34、ice initiates an emergency call through the PSTN or SMS routing gateway using the OTT service provided E.164 number. 3. The OTT service Point of Presence establishes an emergency session to a call taker in the PSAP using the OTT service-provided E.164 number. 8At the time of publication of this spec
35、ification, the FCC had not provided a regulatory definition for VoIP that is not capable of interconnecting to the CS PSTN but may interconnect with other non-interconnected VoIP services. Non-interconnected VoIP services and in particular emergency VoIP calling have yet to be explored fully from a regulatory and technical perspective.
