1、 TECHNICAL REPORT ATIS-0500012 LOCAL ACQUISITION FOR INTERNET ACCESS NETWORKS IN SUPPORT OF EMERGENCY SERVICES The Alliance for Telecommunication Industry Solutions (ATIS) is a technical planning and standards development organization that is committed to rapidly developing and promoting technical a
2、nd operations standards for the communications and related information technologies industry worldwide using a pragmatic, flexible and open approach. Over 1,100 participants from more than 350 communications companies are active in ATIS 23 industry committees and its Incubator Solutions Program. NOT
3、E - The users attention is called to the possibility that compliance with this standard may require use of an invention covered by patent rights. By publication of this standard, no position is taken with respect to whether use of an invention covered by patent rights will be required, and if any su
4、ch use is required no position is taken regarding the validity of this claim or any patent rights in connection therewith. ATIS-0500012, Local Acquisition for Internet Access Networks in Support of Emergency Services Is an ATIS Standard developed by the Next Generation Emergency Services (NGES) Subc
5、ommittee under the ATIS Emergency Services Interconnection Forum (ESIF). Published by Alliance for Telecommunications Industry Solutions 1200 G Street, NW, Suite 500 Washington, DC 20005 Copyright 2007 by Alliance for Telecommunications Industry Solutions All rights reserved. No part of this publica
6、tion may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher. For information contact ATIS at 202.628.6380. ATIS is online at . Printed in the United States of America. ATIS-0500012 Technical Report for LOCAL ACQUISITION FO
7、R INTERNET ACCESS NETWORKS IN SUPPORT OF EMERGENCY SERVICES Secretariat Alliance for Telecommunications Industry Solutions Abstract This ATIS Technical Report is not intended to be seen as an American National Standard (ANS). Rather it is intended to be used as input to further decision-making proce
8、sses leading to any necessary policy and/or American National Standard formulation. It will be used as a vehicle for communicating location acquisition concepts in liaisons with other relevant Standards Development Organizations (SDOs). This document describes the specific areas of location acquisit
9、ion in Internet Protocol (IP) access networks. It concerns itself with both the architectures and protocols for supporting these functions. In brief, this is about the manner in which IP devices such as Voice over Internet Protocol (VoIP) clients obtain location information from an access network lo
10、cation acquisition. For emergency services to work as envisioned by the National Emergency Number Association (NENA) defined i2 architecture for VoIP, location must be available to route the call to a PSAP and to provide the call taker with the callers location. This information is required in the N
11、ENA i2 architecture and will continue to be required in the NENA i3 architecture. This document starts by describing the mechanisms by which a client might obtain location or by which a network might provide location to or on behalf of a client. There are a number of location acquisition protocols w
12、hich might be used, including DHCP, LLDP-MED, LREP-SIP, HELD, RELO, and LCP. This document provides a targeted analysis of each, but it does not presume that any single protocol will be used universally. For example, in network deployments where DHCP is already ubiquitous, it will likely not be repl
13、aced. Similarly, the mobile network environments described in 3GPP 11GAN 16, 3GPP2 12, and OMA SUPL 2.0 17 already have specified solutions which meet or could be extended to meet these functional requirements; duplication of those functions may be unnecessary. ATIS-0500012 ii FOREWORD The Alliance
14、for Telecommunications Industry Solutions (ATIS) serves the public through improved understanding between carriers, customers, and manufacturers. The mission of the Emergency Services Interconnection Forum (ESIF) is to provide a forum that facilitates the identification and resolution of technical a
15、nd/or operational issues related to the interconnection of wireline, wireless, cable, satellites, internet and emergency services networks. The rapid rise of Voice over IP telephony services was anticipated by the National Emergency Number Association (NENA). In 2003, NENA established working groups
16、 to define a “migratory” architecture (i2) and an “end game” architecture (i3) to provide the ability to reliably deliver and process emergency calls originated by Internet-based VoIP telephony users. Both the i2 and i3 architectures depend on the ability to determine and communicate the location of
17、 the caller so that a) the call can be routed to the correct PSAP and b) the location can be delivered to the PSAP operator for dispatch and other procedural purposes. A functional entity called the Location Information Server (LIS) is introduced in the NENA i2 documents. These documents 01 04 defin
18、e requirements and the form of location information provided, however they do not provide the detailed protocol specifications associated with LIS functionality. In practice, the role of the LIS can be split into two key functions: Location acquisition the method by which IP devices and applications
19、 obtain location information. Location measurement and determination the method by which a server providing location information associates the IP device making an emergency call with a location. Many networks have already developed infrastructures suitable for the delivery of location information.
20、Distribution of location using existing infrastructure cuts down operator costs, reduces the time needed for deployment, and improves reliability by ensuring that the basic mechanisms are in consistent use. It would be valuable, however, to provide a network-infrastructure independent mechanism for
21、networks where no infrastructure is currently available. Even where such a network-independent acquisition protocol is in use, however, it must be recognized that the manner in which location is calculated and the form of location will vary significantly depending on the nature of the access technol
22、ogy. Suggestions for improvement of this document are welcome. They should be sent to the Alliance for Telecommunications Industry Solutions, Emergency Services Interconnection Forum, Next Generation Emergency Services Subcommittee, Secretariat, 1200 G Street NW, Suite 500, Washington, DC 20005. At
23、the time it approved this document, ESIF, which is responsible for the development of this Technical Report, had the following members: B. Montgomery, ESIF Chair D. Irwin, ESIF 1st Vice Chair J. Shepard, 2nd Vice Chair C. Underkoffler, ATIS Chief Editor The NGES Subcommittee was responsible for the
24、development of this document. A. Akundi, NGES Co-Chair C. Militeau NGES Co-Chair T. Breen, NGES Technical Editor ATIS-0500012 iii TABLE OF CONTENTS 1 SCOPE, PURPOSE, they will use protocols developed for those environments in most cases, but may use an access-technology independent protocol where th
25、ere is no available infrastructure. 3. ESIF recommends that the need for standards for Operations Support Systems (OSSs) associated with a LIS be liaised to the appropriate standards committee. 4. For the NENA i2 architecture, ESIF recommends HELD as specified in the IETF as the access technology in
26、dependent protocol to be used where no other protocol has been specified or deployed. It should be noted that this ATIS Technical Report does not evaluate certain alternative solutions for example, solutions applicable to cases where the VSP has direct or indirect knowledge of the access network (e.
27、g. has a business relationship with the access network or with some proxy server to the access network) and for which location acquisition by the VSP could be an effective substitute for some of the solutions considered here. 2 DEFINITIONS, ACRONYMS, they may also be applicable to a wide range of va
28、lue-added location-based services. DA6 Location determination and acquisition techniques shall support both NENA i2 and i3 network architectures. DA7 When measurement-based location determination mechanisms fail, the most accurate location information available should be provided. Examples include:
29、For mobile, the Wireless Service Provider might provide tower/Access Point location, last known fix, etc. For wireline, a LIS might provide a civic location that defines the serving area of an access point, e.g., the State of Texas. DA8 Location determination and acquisition must have minimal impact
30、 on call setup time in the event that location is not known ahead of time. DA9 Where a device is not location aware, the network should have the ability to assert a location estimate on behalf of the device. DA10 Location acquisition methods should not require modification of hardware/firmware in ho
31、me-routers/modems. DA11 A location determination method must exist that does not require network hardware replacement in the core network. DA12 The location acquisition protocol shall allow the requesting device to specify a response time requirement to the LIS when requesting location information.
32、The response time is expressed as the maximum time that the requesting node is prepared to wait for location information. The LIS is required to provide the most accurate location fix it can within the specified response time. Rep1 Location information may be provided by-value or by-reference; the f
33、orm is subject to the nature of the request. Rep2 Location determination and acquisition mechanisms must support all location information fields defined within a PIDF-LO. Rep3 Location acquisition mechanisms must allow for easy backwards compatibility as the representation of location information ev
34、olves. Rep4 All representations of location shall include the ability to carry altitude and/or floor designation. This requirement does not imply altitude and/or floor designation is always used or supplied. LocSec1 Location information shall only be provided to authenticated and authorized network
35、devices. The degree of authentication and authorization required may vary depending on the network. LocSec2 Location determination and acquisition methods should preserve privacy of location information, subject to local laws and regulations applicable to the endpoints geographic location. LocSec 3
36、The location or location estimate of a caller should be dependable. LocSec4 The location acquisition protocol must support authentication of the Location Information Server, integrity protection of the Location Information, and protection against replay. ATIS-0500012 6 LocSec5 The location source sh
37、all be identified and should be authenticated. This includes manually entered locations. LocSec6 Where a location is acquired and cached prior to an emergency call, it SHOULD be refreshed at regular intervals to ensure that it is as current as possible in the event location information cannot be obt
38、ained in real time. LocSec 7 Where location by-reference is used, the appropriate privacy policies MUST be implemented and enforced by the LIS operator. 3.3 The NENA IP Architectures The NENA i2 architecture is a transitional architecture defined in advance of the deployment of the NENA i3 architect
39、ure, which will handle VoIP emergency calls natively. NENA has already put forward functional requirements for i3 (NENA 08-751), which include specific requirements for the use, conveyance, and validation of location. For both i2 and i3, the NENA architecture must handle cases where the access netwo
40、rk and the voice service provider may be different. This, in turn, raises the possibility that the access network may be in one jurisdiction and the voice services provider in another jurisdiction. There are significant challenges there, especially in light of the following assumptions set out in Se
41、ction 3 of the NENA i3 requirements document as listed below: “There is no assumption that a voice or other Communications Service Provider is in the path from the originating end terminal to the PSAP. An enterprise may directly offer calls to the system, and indeed an individual may, if they so cho
42、ose, route emergency calls to the proper PSAP. Calls may be placed on the Internet, and the Internet does not respect national boundaries, which means that calls can come from anywhere and be processed by a routing element anywhere else. Furthermore, visitors from other countries roaming into North
43、America must be able to place calls to 9-1-1, and it is expected to be common that equipment purchased outside the U.S. will be used on U.S. originating networks. “ No single network architecture will serve individual, enterprises and carriers equally well, nor will any single set of parameters meet
44、 the needs of every jurisdiction. Rather than define that single architecture, NENA has set out functional requirements for the protocols deployed in specific network architectures to meet. Those broad functional requirements will be relevant to emergency services in multiple jurisdictions. In parti
45、cular, the use of location to determine how to route a call to the correct part of the emergency infrastructure will be common, as will the need to carry location to the call taker. 3.3.1 LIS Operational Considerations The conceptual role of the LIS is to provide location information to its clients.
46、 As noted by the NENA architecture documents, the only business relationship between an access provider and a voice service provider may be that they share a customer. In architectures where this is the only relationship, data shared between the access provider and voice service provider may have to
47、 be relayed through the customer. Where there are existing relationships between the access provider and the service provider (be it an Internet service provider or voice service provider), there may be multiple, independent network entities involved. For example, broadband DSL subscribers establish
48、 a commercial relationship with an Internet Service Provider (ISP) who, for the price of the subscription, undertakes to provide the DSL service to that subscribers residential address. The ISP, however, may not own the DSL infrastructure, the copper ATIS-0500012 7 wires and DSLAM equipment that pro
49、vides the physical connectivity for the subscriber. This infrastructure may be owned by a quite independent Regional Broadband Provider (RBP). In this situation, the ISP pays the RBP for the physical access on behalf of, and quite transparently to, the subscriber. The RBP operates the physical access infrastructure from which the location can be determined; i.e. the RBP can determine the physical DSLAM termination and residential address associated with the copper pair on that termination. A practical deployment topology,
