Notice

335 views
291 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
335
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Notice

  1. 1. 1 2 3Document Type: Technical Report 4TITLE: Location Acquisition and Location Parameter Conveyance for Internet Access 5Networks in Support of Emergency Services 6DOCUMENT NUMBER: ATIS-XXXXXX. 7SOURCE: Emergency Services Interconnection Forum 8CONTACT: Anand Akundi, Telcordia Technologies, (732) 699-6031; Christian Militeau, 9Intrado Inc., (720) 494-5245 10 1.1 11 Abstract 12 This ATIS Technical Report is not intended to be seen as an American National Standard. 13 Rather it is intended to be used as input to further decision-making processes leading to 14 any necessary policy and/or American National Standards formulation. It will be used as a 15 vehicle for communicating concepts in liaisons with other relevant SDOs. 16 This document describes the specific areas of location acquisition and location parameter 17 conveyance in Internet Protocol (IP) access networks. It concerns itself with both the 18 architectures and protocols for supporting these functions. In brief, this is about the 19 manner in which IP devices such as Voice over Internet Protocol (VoIP) clients obtain 20 location information from an access network – location acquisition. It also describes an 21 example method by which a entity acting as a Location Information Server (LIS) could 22 obtain the value of parameters from access networks pertinent to the requesting IP device, 23 should it require this data to provide the device’s location. 24 For emergency services to work as envisioned by the National Emergency Number 25 Association (NENA)-defined i2 architecture for VoIP, location must be available to route 26 the call to a PSAP and to provide the call taker with the caller's location. This information 27 is required in the i2 architecture and will continue to be required in i3. This document 28 starts by describing the mechanisms by which a client might obtain location or by which a 29 network might provide location to or on behalf of a client. There are a number of protocols 30 which might be used, including DHCP, LLDP-MED, SIP presence, HELD, MLP, and LCP. 31 This document provides a targeted analysis of each, but it does not presume that any 32 single protocol will be used universally. In deployments where DHCP is already 33 ubiquitous, for example, it will likely not be replaced. Similarly, the mobile environments 34 described in 3GPP [32] and 3GPP2 [33] already have specified solutions which meet or 35 could be extended to meet these functional requirements; duplication of those functions 36 may be unnecesary.
  2. 2. 1 ATIS-XXXXXXX 1.2 1 Notice 2 This is a draft document and thus, is dynamic in nature. It does not reflect a consensus of 3 ESIF members and it may be changed or modified. Neither ATIS nor ESIF makes any 4 representation or warranty, express of implied, with respect to the sufficiency, accuracy or 5 utility of the information or opinion contained or reflected in the material utilized. ATIS and 6 ESIF further expressly advise that any use of or reliance upon the material in question is at 7 your risk and neither ATIS nor ESIF shall be liable for any damage or injury, of whatever 8 nature, incurred by any person arising out of any utilization of the material. It is possible 9 that this material will at some future date be included in a copyrighted work by ATIS. 10 2 2
  3. 3. 1 ATIS-XXXXXXX 1 2 Document ATIS-XXXXXX. 3 Prepared by 4 Emergency Services Interconnection Forum 5 Working Group 6 Next Generation Emergency Services Subcommittee (NGES) Issue 50 71.3 Foreword 8 The rapid rise of Voice over IP telephony services was anticipated by the National 9 Emergency Number Association (NENA). In 2003, it established working groups to define 10 a “migratory” architecture (i2) and an “end game” architecture (i3) to provide the ability to 11 reliably deliver and process emergency calls originated by Internet-based VoIP telephony 12 users. Both the i2 and i3 architectures depend on the ability to determine and 13 communicate the location of the caller so that a) the call can be routed to the correct 14 PSAP and b) the location can be delivered to the PSAP operator for dispatch and other 15 procedural purposes. A functional entity called the Location Information Server (LIS) is 16 introduced in the NENA i2 documents. These documents [1] [18] define requirements and 17 the form of location information provided, however they do not provide the detailed 18 protocol specifications associated with LIS functionality. 19 In practice, the role of the LIS can be split into two key functions: 20 • Location acquisition – the method by which IP devices and applications obtain 21 location information. 22 • Location measurement and determination – the method by which a server 23 providing location information associates the IP device making an emergency call 24 with a location 25 Many networks have already developed infrastructures suitable for the delivery of location 26 information. Distribution of location using existing infrastructure cuts down operator costs, 27 reduces the time needed for deployment, and improves reliability by ensuring that the 28 basic mechanisms are in consistent use. It would be valuable, however, to provide a 29 network-infrastructure independent mechanism for networks where no infrastructure is 30 currently available. Even where such a network-independent acquisition protocol is in use, 31 however, it must be recognized that the manner in which location is calculated and the 32 form of location will vary significantly depending on the nature of the access technology. 331.4 Revision History Revision Date Remarks 1.0 April 5, 2007 Version 1 34 2 3
  4. 4. 1 ATIS-XXXXXXX 1 Table of Contents 2 1.1 Abstract..............................................................................................................................................1 3 1.2 Notice.................................................................................................................................................2 4 1.3 Foreword............................................................................................................................................3 5 1.4 Revision History.................................................................................................................................3 62 Introduction/Executive Summary ...........................................................................................................6 73 Abbreviations, Acronyms, and Symbols...................................................................................................8 84 NENA i2 Stage of Evolution...................................................................................................................10 9 4.1 Summary of LIS Functions in the NENA Architecture......................................................................11 10 4.2 LIS Requirements Prescribed By NENA..........................................................................................11 11 4.3 The NENA IP Architectures..............................................................................................................13 125 LIS Operational Considerations.............................................................................................................14 13 5.1 Types of LIS and LIS Operators.......................................................................................................14 14 5.1.1 Access Infrastructure Provider Network....................................................................................15 15 5.1.2 Internet Service Provider..........................................................................................................15 16 5.1.3 Geo-distributed LAN.................................................................................................................15 17 5.1.4 Geo-point LAN..........................................................................................................................15 18 5.1.5 Summary..................................................................................................................................16 19 5.2 Certificate Security and Management..............................................................................................16 20 5.3 OSS Integration Considerations.......................................................................................................16 216 Location Acquisition Protocols...............................................................................................................18 22 6.1 Protocol Descriptions ......................................................................................................................18 23 6.1.1 Dynamic Host Configuration Protocol (DHCP) RFC3825.........................................................18 24 6.1.2 Link Layer Discovery Protocol for Media Endpoint Devices (LLDP-MED)................................18 25 6.1.3 HTTP Enabled Location Delivery (HELD).................................................................................18 26 6.1.4 Retrieving End-System LOcation information (RELO)..............................................................18 27 6.1.5 A Location Reference Event Package for the Session Initiated Protocol (LREP-SIP)..............19 28 6.1.6 Location Configuration Protocol (LCP).....................................................................................19 29 6.2 Location Protocol Gap Analysis Against NENA i2 Requirements.....................................................19 30 6.3 Findings............................................................................................................................................22 31 6.4 Protocol Status.................................................................................................................................23 327 Specific Recommendations...................................................................................................................24 33 7.1 LIS Recommendations....................................................................................................................24 34 7.2 Location Acquisition Protocol Recommendations.............................................................................24 35 7.3 Location Parameter Conveyance Protocol Recommendations........................................................25 368 References............................................................................................................................................25 37 2 4
  5. 5. 1 ATIS-XXXXXXX 1 2 Table of Figures 3 4Figure 4-1 NENA i2 architecture................................................................................................................10 2 5
  6. 6. 1 ATIS-XXXXXXX 1 22 Introduction/Executive Summary 3 The NENA VoIP migratory working group defined the i2 network architecture 4 designed to support emergency service calls originating from VoIP services on the 5 Internet. The architecture requires location to be used to route a call to the 6 appropriate PSAP and to provide location information to PSAP operator terminals. 7 The architecture describes the method by which location is obtained in terms of a 8 function associated with a “Location Information Server” or LIS.. 9 The i2 specification does not detail the method by which the VoIP device or proxy 10 server provides location, nor does it describe how location should be determined.. 11 NENA requested ATIS/ESIF to provide recommendations for the protocol and 12 implementation specifics of the LIS function for the broadband access and 13 emergency services industry. ATIS/ESIF has responded to NENA’s request by 14 publication of this document, which is comprised of multiple parts, those being; 1) 15 Background, 2) Discussion and Analysis, 3) Recommendations. 16 This document divides the subject into two areas. The first is “Location Acquisition” 17 which describes the manner in which VoIP devices or proxy servers obtain 18 location. Among the likely methods are DHCP, LLDP-MED, SIP presence, LCP, 19 MLP, and HELD. Given that several of these protocols are already deployed by 20 operators to configure those accessing their networks, it is likely that more than 21 one protocol will be deployed, depending on the network architecture of the 22 deployment. The development of a single protocol for use in networks without 23 deployed infrastructure for host configuration is recommended. Candidate 24 protocols for this functionality are compared against the NENA defined 25 requirements.. Candidate location acquisition protocols (DHCP, LLDP-MED, 26 HELD, LREP-SIP and LCP) are compared against the NENA defined 27 requirements. The second area of discussion is “Location Determination”, which is 28 the manner in which a network determines the location of a device. For cases 29 where the existing network architecture does not provide a suitable method of 30 determining and communicating this data, a generic architecture based on the 31 functional mechanisms in the LIS and an access location entity (ALE) is described. 32 A protocol called the Flexible LIS-ALE Protocol (FLAP) is described which supports 33 this architecture. 34 The results of this analysis are provided as a basis for discussion and decision- 35 making. Input from a range of major SDOs and other interested parties were taken 36 into consideration in development of this document. 37 The following summarizes the recommendations of this Technical Report. The 38 expanded recommendations and rationale are contained in Section 7. 39 1. The LIS function should be implemented in networks which do not already 40 provide methods for configuring location in attached hosts, either by 41 extending existing configuration methods or the use of a access-technology 42 independent protocol. 43 2. Different types of devices may serve as a LIS in different network 44 deployments; they will use protocols developed for those environments in 2 6
  7. 7. 1 ATIS-XXXXXXX 1 most cases, but may use an access-technology independent protocol 2 where there is no available infrastructure. 3 3. ESIF recommends that the need for standards for Operations Support 4 Systems associated with a LIS be liaised to the appropriate standards 5 committee. 6 4. For the NENA i2 architecture, ESIF recommends HELD as specified in the 7 IETF as the access technology independent protocol to be used where no 8 other protocol has been specified or deployed. 9 5. Within the procedural framework of ATIS, ESIF intends to initiate the 10 standards development and formal specification of a location parameter 11 conveyance protocol (FLAP) for use in conjunction with HELD in networks 12 where no existing architecture support location acquisition.. 13 It should be noted that this Technical Report does not evaluate certain alternative 14 solutions – for example, solutions applicable to cases where the VSP has direct or 15 indirect knowledge of the access network (e.g. has a business relationship with the 16 access network or with some proxy to the access network) and for which location 17 acquisition by the VSP could be an effective substitute for some of the solutions 18 considered here. 19 2 7
  8. 8. 1 ATIS-XXXXXXX 13 Abbreviations, Acronyms, and Symbols Term Brief Definition ALE Access Location Entity ATM Asynchronous Transfer Mode BEEP Blocks Extensible Exchange Protocol (RFC3080, RFC3081) BRAS Broadband Regional Access Server BSSLAP Base Station System Location Assistance Protocol CMTS Cable Modem Termination System DHCP Dynamic Host Configuration Protocol DSL Digital Subscriber Line DSLAM DSL Access Module FLAP Flexible LIS-ALE Protocol GGSN Gateway GPRS Support Node GMLC Gateway Mobile Location Center GPRS General Packet Radio Service HELD HTTP Enabled Location Delivery ISP Internet Service Provider L2TP Layer 2 Tunneling Protocol LIS Location Information Server LMU Location Measurement Unit MAC Media Access Control NAS Network Access Server PVC Permanent Virtual Circuit RADIUS Remote Authentication Dial In User Service 2 8
  9. 9. 1 ATIS-XXXXXXX Term Brief Definition RANP Regional Access Network Provider RBP Regional Broadband Provider SGSN Serving GPRS Support Node SLP SUPL Location Platform SMLC Serving Mobile Location Center SNMP Simple Network Management Protocol SUPL Secure User Plane Location VESA Valid Emergency Service Authority VPC VoIP Positioning Center 1 2 9
  10. 10. 1 ATIS-XXXXXXX 1 BACKGROUND 24 NENA i2 Stage of Evolution 3 The NENA i2 stage of evolution, as described in the NENA 08-001 document 8 was 4 proposed with the intent of addressing the immediate need of providing standard 5 emergency services support to next generation Residential Broadband VoIP phone users. 6 A strong requirement of i2 from the onset was to make little or no change to the existing 7 emergency infrastructure, in particular any solution was to impose no change to PSAPs. 8 The data sets associated with location of an IP device, when investigated further were 9 found to be similar to location parameters associated with wireless cellular networks. The 10 resulting architecture for i2 therefore adopted concepts from wireless Phase 2 . 11 Access Carrier Emergency Network Network Network Call-Server/ Proxy ISUP CAMA V1 V4 ESGW Selective Router V0 VEP IP PAM Network V2/V5 ALI LIS Local PSAP E2+ PAM V3 VPC ESP ALI National V8 ERDB V7 VDB 12 13 Figure 4-1 NENA i2 architecture 14 The NENA i2 architecture (see Figure 4-1) identified 5 new functional elements, 9 new 15 interfaces, and made minor changes to the E2+ to support VoIP class of service indicators 16 between the new VoIP Positioning Center (VPC) and the existing ALI infrastructure. While 17 the detailed functions of each of the new 5 network elements is defined in the i2 18 specification, not all of the interfaces between nodes are specified. Specifically, the V0 and 19 V1 interfaces were deemed out of scope for i2. 20 There is a fundamental principle in the i2 architecture that location is required to route calls 21 to the correct PSAP and should also be conveyed to the call taker. Any architecture which 2 10
  11. 11. 1 ATIS-XXXXXXX 1 handles emergency calls should meet these requirements, not just for i2, but going 2 forward. 3 Within the i2 architecture the V2 interface to the VPC is well described and specified. 4 Similarly the function of the ESGW is well understood.. In addition, the VPC and ESGW 5 are migratory solution constructs. They don’t necessarily have a long term role into a 6 future where emergency calling occurs IP end-to-end between VoIP devices and VoIP 7 enabled emergency call centers. 8 In contrast to the VPC and ESGW functions, the LIS interfaces (V0 and V1) have the least 9 level of detail in the i2 specification. The V1 interface is recognized to be VoIP-protocol 10 specific so the only requirement cited by i2 is the ability of that interface to convey location 11 in the form of a Presence Information Data Format-Locaton Object (PIDF-LO) or as a URI 12 from which a PIDF-LO can be retrieved. The V0 LIS function can be served by existing 13 provisioning mechanisms (e.g. DHCP, LLDP-MED) or by any architecture that meets the 14 functional requirement. Individual networks will likely vary on their choice of mechanism, 15 as networks have already deployed provisioning mechanisms for other purposes. There 16 should, however, be a single preferred (or) defined protocol for use in networks where new 17 infrastructure support has been provided..This document focuses on the LIS functionality 18 and recommends HELD as the preferred protocol for this purpose. 194.1 Summary of LIS Functions in the NENA Architecture 20 While the i2 architecture did not elaborate on the form of the V0 interface protocol(s) or the 21 manner in which the LIS is expected to determine device location, the i2 working group did 22 provide supporting technical documents describing the requirements for the V0 interface 23 and for the LIS function. One such document is the NENA Technical Requirements 24 Document (TRD) for Location Information to Support IP-Based Emergency Services 25 NENA 08-752, Issue 1, December 21, 2006 8. 26 The requirements for the LIS were divided into three areas 27 • Location determination and acquisition (DA) 28 • Location representation (Rep) 29 • Location security and dependability (LocSec) 30 The following section lists these requirements. 314.2 LIS Requirements Prescribed By NENA 32 The following requirements come from the NENA Requirements for the location 33 information to support emergency services 8. 34 DA1– The access network shall provide a mechanism for determination and acquisition of 35 location information, and support queries for location. 36 DA2 – The location estimate used shall be that associated with the physically (wire, fiber, 37 air) connected network. 38 DA3 – Location may be requested at any time. Location information must be associated 39 with the device at the time the location is requested. 40 DA4 – Location acquisition should be provided by a consistent method across all network 41 configurations. 2 11
  12. 12. 1 ATIS-XXXXXXX 1 DA5 – Location determination and acquisition mechanisms should be applicable to 2 emergency calling; they may also be applicable to a wide range of value-added location- 3 based services. 4 DA6 – Location determination and acquisition techniques shall support both NENA i2 and 5 i3 network architectures. 6 DA7 – When measurement-based location determination mechanisms fail, the most 7 accurate location information available should be provided. Examples include: For mobile, 8 the Wireless Service Provider might provide tower/Access Point location, last known fix, 9 etc. For wireline, a LIS might provide a civic location that defines the serving area of an 10 access point, e.g., the State of Texas. 11 DA8 – Location determination and acquisition must have minimal impact on call setup 12 time in the event that location is not known ahead of time. 13 DA9 – Where a device is not location aware, the network should have the ability to 14 assert a location estimate on behalf of the device. 15 DA10 – Location acquisition methods should not require modification of 16 hardware/firmware in home-routers/modems. 17 DA11 – A location determination method must exist that does not require network 18 hardware replacement in the core network. 19 DA12 – The location acquisition protocol shall allow the requesting device to specify a 20 response time requirement to the LIS when requesting location information. The response 21 time is expressed as the maximum time that the requesting node is prepared to wait for 22 location information. The LIS is required to provide the most accurate location fix it can 23 within the specified response time. 24 25 Rep1– Location information may be provided by-value or by-reference; the form is subject 26 to the nature of the request. 27 Rep2 – Location determination and acquisition mechanisms must support all location 28 information fields defined within a PIDF-LO. 29 Rep3 – Location acquisition mechanisms must allow for easy backwards compatibility as 30 the representation of location information evolves. 31 Rep4 – All representations of location shall include the ability to carry altitude and/or floor 32 designation. This requirement does not imply altitude and/or floor designation is always 33 used or supplied. 34 LocSec1– Location information shall only be provided to authenticated and authorized 35 network devices. The degree of authentication and authorization required may vary 36 depending on the network. 37 LocSec2 – Location determination and acquisition methods should preserve privacy of 38 location information, subject to local laws and regulations applicable to the endpoint’s 39 geographic location. 40 LocSec 3 – The location or location estimate of a caller should be dependable. 41 LocSec4 – The location acquisition protocol must support authentication of the Location 42 Information Server, integrity protection of the Location Information, and protection against 43 replay. 2 12
  13. 13. 1 ATIS-XXXXXXX 1 LocSec5 – The location source shall be identified and should be authenticated. This 2 includes manually entered locations. 3 LocSec6 – Where a location is acquired and cached prior to an emergency call, it 4 SHOULD be refreshed at regular intervals to ensure that it is as current as possible in the 5 event location information cannot be obtained in real time. 6 LocSec 7 – Where location by-reference is used, the appropriate privacy policies MUST 7 be implemented and enforced by the LIS operator. 8 94.3 The NENA IP Architectures 10 The NENA i2 architecture is a transitional architecture defined in advance of the 11 deployment of NENA i3, which will handle VoIP natively. NENA has already put forward 12 functional requirements for i3 (NENA 08-751), which include specific requirements for the 13 use, conveyance, and validation of location. For both i2 and i3, the NENA architecture 14 must handle cases where the access network and the voice service provider may be 15 different. This, in turn, raises the possibility that the access network may be in one 16 jurisdiction and the voice services provider another. There are significant challenges 17 there, especially in light of the following assumptions set out in Section 3 of the NENA i3 18 requirements document: 19 “There is no assumption that a voice or other Communications Service 20 Provider is in the path from the originating end terminal to the PSAP. An enterprise 21 may directly offer calls to the system, and indeed an individual may, if they so 22 choose, route emergency calls to the proper PSAP. 23 24 Calls may be placed on the Internet, and the Internet does not respect national 25 boundaries, which means that calls can come from anywhere and be processed by a 26 routing element anywhere else. Furthermore, visitors from other countries roaming 27 into North America must be able to place calls to 9-1-1, and it is expected to be 28 common that equipment purchased outside the U.S. will be used on U.S. originating 29 networks. For these reasons, portions of the conforming i3 implementations (i.e. 30 CPE) must conform to international standards for emergency calls, such as those 31 promulgated by the IETF and others. “ 32 No single system architecture will serve individual, enterprises and carriers equally well, 33 nor will any single set of parameters meet the needs of every jurisdiction. Rather than 34 define that single architecture, NENA has set out functional requirements for the protocols 35 deployed in specific architectures to meet. Those broad functional requirements will be 36 relevant to emergency services in multiple jurisdictions. In particular, the use of location to 37 determine how to route a call to the correct part of the emergency infrastructure will be 38 common, as will the need to carry location to the call taker. 2 13
  14. 14. 1 ATIS-XXXXXXX 1 DISCUSSION 25 LIS Operational Considerations 3 The conceptual role of the LIS is to provide location information to its clients. As noted by 4 the NENA architecture documents, the only business relationship between an access 5 provider and a voice service provider may be that they share a customer. In architectures 6 where this is the only relationship, data shared between the access provider and voice 7 service provider may have to be relayed through the customer. Where there are existing 8 relationships between the access provider and the service provider (be it an Internet 9 service provider or voice service provider), there may be multiple, independent entities 10 involved.. 11 For example, broadband DSL subscribers establish a commercial relationship with an 12 Internet Service Provider (ISP) who, for the price of the subscription, undertakes to provide 13 the DSL service to that subscriber’s residential address. The ISP, however, may not own 14 the DSL infrastructure, the copper wires and DSLAM equipment that provides the physical 15 connectivity for the subscriber. This infrastructure may be owned by a quite independent 16 Regional Broadband Provider (RBP). 17 In this situation, the ISP pays the RBP for the physical access on behalf of, and quite 18 transparently to, the subscriber. 19 The RBP operates the physical access infrastructure from which the location can be 20 determined; i.e. the RBP can determine the physical DSLAM termination and residential 21 address associated with the copper pair on that termination. A practical deployment 22 topology, then, is to have the RBP operate the LIS which actually determines the location. 23 The ISP and the RBP business entities already have a commercial relationship and data 24 interconnection as part of the general provision of Internet access that is the purpose of 25 the relationship. And, in this case, the ISP LIS will also utilize the RBP LIS infrastructure to 26 perform the actual location determination. 27 The above, is just one example, of how a LIS implementation may be driven by 28 organizational and commercial relationships. In the example given, the ISP LIS services 29 the client requests but needs to be able to communicate with the RBP LIS in order to 30 resolve actual location information. The same considerations may apply for technologies in 31 which access is wholesaled by an infrastructure operator to an ISP. 32 The following sections examine some of the practical factors that affect the implementation 33 and deployment of LIS functionality. 345.1 Types of LIS and LIS Operators 35 The types of LIS operators (organizational entities that may own and operate a LIS) 36 include, though may not be limited to, the following: 37 ◦ Access infrastructure providers 38 ◦ Internet Service Providers 2 14
  15. 15. 1 ATIS-XXXXXXX 1 ◦ Geo-distributed1 LAN operators 2 ◦ Geo-point2 LAN operators 3 As described in the introductory text, the form and function of the LIS implementation in 4 each of the above cases will vary. They are taken in turn in the following sections. 55.1.1 Access Infrastructure Provider Network 6 In this case, we are dealing with the operator of the physical infrastructure (wired or 7 wireless) which is used by subscribers to gain access to the public Internet. The LIS in this 8 environment has the key task of determining location. It may provide location to the 9 devices themselves or it may serve a third-party device, such as an ISP LIS. 105.1.2 Internet Service Provider 11 Where the ISP owns and operates its own access infrastructure, then the LIS 12 implementation will be as described for an access infrastructure operator LIS. Where the 13 ISP purchases access infrastructure wholesale from another operator, the LIS may not 14 actually perform location determination itself. In this case the ISP LIS obtains the location 15 from the infrastructure operator. The ISP LIS supports one or more protocols for 16 provisioning location to the subscriber devices but it relies on the infrastructure operator to 17 obtain the location corresponding to those devices. 18 The protocol used from the ISP LIS to the infrastructure operator may be a standard 19 location acquisition protocol. 205.1.3 Geo-distributed LAN 21 An enterprise LAN is a common example of a Geo-distributed LAN. An LIS used in a 22 Geo-distributed LAN must be able to distinguish among the locations served by the LAN, 23 and it must be able to associate a location with the different parts of its topology. This may 24 be as simple as providing a wire-map database that covers mutliple campuses. It may be 25 more complex in cases where the LAN involves both wired and wireless points of 26 attachment.. 27 A large enterprise may actually be regarded as the equivalent of an access infrastructure 28 provider, in that its LIS may support all of the functions of a general LIS with the exception 29 of supporting other ISPs re-using its infrastructure. 305.1.4 Geo-point LAN 31 A typical Geo-point LAN might correspond to a residential home LAN where there is no 32 requirement to refine location to any finer degree than can be determined by the access 33 provider. It is not actually necessary to operate a LIS in such an environment. 21 No hard definition of “geo-distributed” or “broad geographic coverage is offered in this text. To an extent, this will be 3governed by circumstance and jurisdiction. For example, a LAN operating in a large building covering thousands of 4square feet may be considered a “geo-distributed” network if either the owner/operator of the building or the 5jurisdiction in which the building is located consider it necessary to resolve discrete locations within that building – as 6opposed to just a centroid geodetic location or overall civic address for the building. The local jurisdictions may 7require such large buildings to provide a more precise location than just the civic address in the case of emergency 8calls. If neither imperative exists, then the LAN, despite its actual size, may be regarded as a geo-point network. 92 As with “geo-distributed”, no hard definition of “geo-point” is provided in this text. Again, the question of whether a 10hotspot offered by a coffee shop, for example, is considered a geo-point network versus a geo-distributed one 11depends on circumstances including the question of how big the hotspot coverage actually is. 2 15
  16. 16. 1 ATIS-XXXXXXX 15.1.5 Summary 2 The form and function that a specific instance of a LIS has will vary depending on the 3 nature of the network it is supporting and the role that the operator of that network plays in 4 the larger picture of Internet access. The specifics of form and function will inevitably be 5 influenced by these aspects and the business and other relationships that exist between 6 network types. 75.2 Certificate Security and Management 8 The NENA i2 architecture identifies an agency labeled the Valid Emergency Services 9 Authority (VESA) which will control the generation, issuing, and maintenance of certificates 10 to delegate credential authorities (it may also serve as a delegate credential authority). 11 DCAs are responsible for issuing certificates to the operators of network entities that utilize 12 VESA certificates for the exchange of authenticated data on the i2 defined interfaces. 13 Examples of delegate credential authorities may be PSAP operators, state emergency 14 authorities, or regional 9-1-1 service providers. 15 It will be critical to the security of the emergency services infrastructure of each jurisdiction 16 implementing the i2 architecture to ensure that the certificates issued by the certificate 17 authority are managed with due care by both the authority and the recipient organizations. 18 Some LIS operators may require certification by a DCA and should, in that case take care 19 that access to the certificates is appropriately limited [26]. 20 The use of certificates only guarantees that the location data contained is authentic and 21 originated by the signer. Certificates do not protect against replay attacks, e.g. a 22 miscreant steals a signed location object and attaches it to any emergency call or multiple 23 calls. This attack could result in a PSAP being fooled into responding to what is thought a 24 real emergency as the location data passed the certification test. Emergency calls that 25 contain no location certification and/or a failed location certification also would need 26 careful handling so as to not deny services to a legitimate caller. 275.3 OSS Integration Considerations 28 Section 4 describes the manner in which the location of devices may be determined in 29 access networks based on a range of technologies. A common requirement in all of these 30 solutions is for the LIS to maintain data records which can be used to associate dynamic 31 network parameter values to information which ultimately indicates the location of the user. 32 Examples, of such records are ATM permanent virtual circuit IDs and the corresponding 33 DSLAM termination and residential address associated with them, or the MAC address of 34 a cable modem and the residential address associated with it. 35 In practice, there will be considerable effort and infrastructure associated with the 36 collection, grooming, provisioning and ongoing synchronization of such records into an 37 operator LIS. Typically, the necessary data may be stored in a range of back end 38 Operational Support Systems (OSS) ranging from network configuration platforms to 39 subscriber record databases. 40 Since OSS implementations are often operator specific with little standardization in terms 41 of data schema or provisioning interfaces, it may be that the data provisioning functions of 42 a LIS will need to be dealt with by each individual operator. The situation could be 43 mitigated to some extent with the specification of a standard provisioning protocol for LIS 44 functions. While this does not address the thorny aspect of grooming data from its 2 16
  17. 17. 1 ATIS-XXXXXXX 1 manifold sources, it would at least allow for a common implementation at the LIS end of 2 the data chain. This document does not describe a common provisioning protocol but it is 3 identified as a potential candidate for further study in an appropriate SDO. 2 17
  18. 18. 1 ATIS-XXXXXXX 1 ANALYSIS 26 Location Acquisition Protocols 3 The term “location acquisition” refers to the process by which a network provides location 4 information to a client. There are a number of approaches and philosophies related to this 5 acquisition process and the protocols that support it. This section looks at various 6 candidates: DHCP, LLDP-MED, HELD, RELO, LREP-SIP and LCP. Each of these may 7 be used in specific deployments, in order to fit in with the operator's existing architecture 8 and services. 96.1 Protocol Descriptions 106.1.1 Dynamic Host Configuration Protocol (DHCP) RFC3825 11 DHCP delivers network configuration information to an IP device. The intent is to provide 12 the device all the information it needs to utilize the IP network it has connected to; 13 information such as the IP address allocated to the device, the address of the gateway 14 through which the traffic destined beyond the LAN should be sent, and/or the identity of 15 the Domain Name Service (DNS) that can be requested to translate the names of network 16 hosts into their physical IP addresses in order to talk to them. RFC3825 describes an 17 option on DHCP that allows the device to request and receive a specific form of location 18 information (geodetic or civic). 196.1.2 Link Layer Discovery Protocol for Media Endpoint Devices (LLDP-MED) 20 TIA has defined extensions to the Link Layer Discovery Protocol (LLDP) to support 21 additional information elements applicable to Media Endpoint Devices (MED). These were 22 termed LLDP-MED and included the ability for those end point devices to be informed of 23 the location associated with, for example, the wiremap wall jack location to which they are 24 currently attached. The recommended usage for LLDP-MED is to provide the client location (e.g. 25 wiremap wall jack location), not the 802.3 switch port location since this can vary significantly due to 26 cable or fiber lengths. LLDP-MED supports three location types; the location of the DHCP server, 27 the location of the identifiable network element believed to be closest to the client, or the location of 28 the client. 296.1.3 HTTP Enabled Location Delivery (HELD) 30 HELD is a newly proposed protocol, specifically for the purpose of supporting location 31 acquisition. It uses HTTP or BEEP as transports and functions at layer 7, so the client 32 device and server do not need to be within the same subnet or broadcast domain to 33 communicate.. HELD is currently a Working Group item in the IETF GEOPRIV WG 8. 346.1.4 Retrieving End-System LOcation information (RELO) 35 RELO is another newly proposed protocol and also one aimed at supporting location 36 acquisition interaction above Layer 3. RELO is currently an Internet draft submitted to the 37 IETF 8. 2 18
  19. 19. 1 ATIS-XXXXXXX 16.1.5 A Location Reference Event Package for the Session Initiated Protocol (LREP-SIP) 2 LREP-SIP is a mechanism for using SIP's presence architecture for the retrieval of 3 location. It relies on the existing relationship between PIDF and PIDF-LO, as well as the 4 likelihood of SIP being used in devices making VoIP calls. It defines a new SIP event 5 package, locationref [30]. It is currently an Internet draft in the IETF GEOPRIV WG 8. 66.1.6 Location Configuration Protocol (LCP) 7 LCP was defined to provide the same functionality as 8 but replacing DHCP with a new IP- 8 based protocol to carry the location request and response. The form of location provided 9 by LCP is defined to be the same as 8. It is currently an Internet draft submitted to the 10 IETF GEOPRIV WG 8. 116.2 Location Protocol Gap Analysis Against NENA i2 Requirements 12 The following table illustrates the evaluation of various location protocols against NENA i2 13 location Requirements 8 . NENA DHCP LLDP-MED HELD RELO LREP-SIP LCP Requirement DA-1 – Yes – the Yes – location Yes - HELD Yes – the Yes – the Yes – the Mechanism for manner in which associated with provides manner in which manner in which manner in whic determining and location is the network port acquisition location is location is location is acquiring determined is not is configured (FLAP provides determined is not determined is not determined is n location defined by directly on the measurements defined by RELO defined but the defined by LCP DHCP host most for protocol supports commonly using determination) the provision of SNMP network parameters by the device – currently only supports switch chassis/port. DA-2 – Use Yes Yes Yes Yes Yes Yes location estimate DA-3 – Location Yes Yes Yes Yes Yes Yes requested any time 2 19
  20. 20. 1 ATIS-XXXXXXX NENA DHCP LLDP-MED HELD RELO LREP-SIP LCP Requirement DA-4 – Yes No Yes Yes Yes Yes Consistent method across DHCP can be Since LLDP- The network all network delivered in IP- MED is not identifier types configurations base network, applicable in all are important to but it is not network location preferred where technologies determination. new therefore this Currently only infrastructure acquisition supports switch would need to be mechanism chassis/port. deployedNo cannot apply to all access Since DHCP is networks. not applicable in all network technologies therefore this acquisition mechanism cannot apply to all access networks. DA-5 – Yes Yes Yes Yes Yes Yes Applicable to emergency Does not convey Does not convey Does not conve services uncertainty. uncertainty. uncertainty. DA-6 – Support Yes Yes Yes Yes Yes Yes i2 and i3 DA-7 – Provide Non Applicable Non Applicable Non Applicable Non Applicable Non Applicable Non Applicable fallback or last known DA-8 – Minimal Yes Yes Yes Yes Yes Yes call processing impact DA-9 – Assert on No No Yes (using third No No No behalf of party terminal address value – On Behalf Of type request) DA-10 – No NoYes No Yes Yes Yes Yes Hardware modification DA-11 – No Non Applicable Non Applicable Non Applicable Non Applicable Non Applicable Non Applicable Hardware replacement DA-12 – Request Non Applicable No Yes No No Non Applicable response time 2 20
  21. 21. 1 ATIS-XXXXXXX NENA DHCP LLDP-MED HELD RELO LREP-SIP LCP Requirement Rep-1 – Request Partial, DHCP Yes, via an ELIN Yes Yes Yes Partial, LCP by reference and does not support does not suppo by value by-reference location-by- reference Rep-2 – Support No No Yes Yes Yes No all fields of PIDF- LO Method, Method, Method, presentity, rules, presentity, rules, presentity, rule provided-by are provided-by are provided-by are not supported. not supported. not supported. Rep-3 – NoYes NoYes Yes (PIDF-LO Yes by Yes (PIDF-LO NoYes Backwards definition evolves indirection to definition evolves compatibility Can only support Can only support independently of GML and civilLoc independently of Can only suppo change through change through HELD acquisition forms LREP-SIP change through BIS of option or BIS of option or protocol) acquisition BIS of 8 a new option a new option protocol) Rep-4 – Provide Yes Yes Yes Yes Yes Yes altitude and floor LocSec-1 – Yes Yes Yes No No Yes Provide only to authorized and Can only provide Can only provide RELO is not Protocol forbids Can only provid authenticated location to the location to the designed to the use of location to the devices end-point end-point support authentication for end-point authentication or location authorization dereferencing LocSec-2 – Yes (except in Yes Yes No No Yes (except in Preserve privacy transmission transmission since location the device Protocol does since location can only be cannot inform not support the can only be transferred by- the LIS of its provision of transferred by- value and not by- privacy access rules value and not b reference) preferences reference) LocSec-3 – No No Yes (through No No No Location signed location Dependable No dependability No dependability request RELO has no There is no No dependabili mechanism mechanism mechanism with mechanism to support for mechanism exists for a exists for a PIDF-LO request a signed signed location exists for a PID PIDF-LO crafted PIDF-LO crafted delivered fully- or dependable or for provision LO crafted by t by the end- by the end- constituted by PIDF-LO of credentials on end-pointN/A pointN/A pointN/A the LIS)N/A dereferencingN/ A LocSec-4 - Partial No Yes (through No No No Authentication of encryption of LIS DHCP can appropriate provide integrity attributes in through 8, but creation of not secrecy location signatures) 2 21
  22. 22. 1 ATIS-XXXXXXX NENA DHCP LLDP-MED HELD RELO LREP-SIP LCP Requirement LocSec-5 – No No Yes (credentials No No No Source associated with authenticated signed location indicate the source of the location. A user provided location may be “asserted” and subsequently signed by the LIS) LocSec-6 – Yes Yes Yes Yes Yes Yes Refresh cached location LocSec-7 – Not applicable Not applicable Yes Not applicable No Not applicable Privacy policies for location by DHCP does not LLDP-MED does RELO does not LCP does not reference currently support not support support location support location location by- location by- by-reference by-reference reference – a reference new proposal to add it has been discussed in the IETF 1 26.3 Findings 3 Of the 23 NENA provided applicable requirements 8 on location acquisition and 4 determination: 5 • DHCP provides full support for 10 and partial support for 2, but cannot support the 6 remaining 8. Three requirements are not applicable. 7 • LLDP-MED provides full support for 10 and partial support for 1, but cannot support 8 the remaining 9. Three requirements are not applicable. 9 • HELD provides full support for 21, two requirements are not applicable. 10 • RELO provides full support for 12 and partial support for 1. It does not support 7 11 and 3 are not applicable. 12 • LREP-SIP provides support for 13 but does not support 8. Two requirements are 13 not applicable At time of writing, it was not clear whether the user agent identifier 14 exchange is fundamental to location determination or not. The compliance figures 15 assume it is not, or else there would be lower compliance. 16 • LCP provides support for 12 and partial support for 1. It does not support 7 17 requirements and 3 are not applicable. 2 22
  23. 23. 1 ATIS-XXXXXXX 1 In addition, to support mobile devices requiring a mid-call location update, a location 2 reference is the only practical solution and this mechanism is not supported by DHCP, 3 LLDP-MED, RELO, or LCP. 46.4 Protocol Status 5 The following provides the current status of each protocol at the time this document was 6 puiblished, although the status of those in Draft status are subject to change. 7 • DHCP is defined in IETF RFCs 3825, 4388, 3118, 4388 and 3046 8 • LLDP-MED is released TIA specification 1057 9 • HELD is IETF [correct as needed] Internet Draft 10 • RELO is IETF Internet Draft 11 • LREP-SIP is IETF Internet Draft 12 • LCP is IETF Internet Draft 2 23
  24. 24. 1 ATIS-XXXXXXX 1 2 3 RECOMMENDATIONS 47 Specific Recommendations 5 This section provides a synopsis of ESIF’s recommendations regarding LISs, location 6 acquisition protocols and location parameter conveyance protocols 77.1 LIS Recommendations 8 Since the LIS is a functional element defined in the NENA i2 architecture, ESIF’s 9 recommendations reinforce the use of LISs and extend the concepts as follows: 10 1. Any network architecture expecting to support emergency services with VoIP should 11 expect to be able to distribute location. The functional entity doing such distribution, the 12 Location Information Server, may be a part of the configuration infrastructure already 13 present in a network. Where the existing configuration infrastructure has a defined 14 location distribution solution, ESIF encourages operators to deploy the location-specific 15 extensions as soon as they are available. Where the existing configuration infrastructure 16 does not have a defined location distribution solution, ESIF encourages operators to use 17 location acquisitions protocol per the analysis of this Technical Report.The LIS should be 18 the primary network element from which the location of the user is acquired. ESIF 19 recognizes that legacy networks may have already implemented a location acquisition 20 function (e.g. a GMLC) and encourages the operators of those networks to include as part 21 of the capabilities of these pre-existing functions any of the location acquisition protocols 22 recommended in this Technical Report. 23 2. For infrastructures in which location determination will be performed by a different entity 24 than location distribution, methods must be developed and deployed to associate the 25 acquired location and the entityDifferent categories of LISs may be implemented based 26 upon required interactions between network providers because a carrier or Enterprise 27 network can have target-device specific information. This requires LIS to LIS 28 communications based upon business agreements between the parties (carriers and/or 29 Enterprises). 30 3. Recognizing that Operation Support Systems (OSSs) are often carrier specific, ESIF 31 recommends that the need for standards associated with a LIS be liaised to the 32 appropriate standards committee. This may be a joint activity between that committee 33 and ESIF. 347.2 Location Acquisition Protocol Recommendations 35 The table in Section 7.2 compares the attributes of various existing and proposed 36 protocols as they meet the NENA requirements. While ESIF recognizes that each protocol 37 will be presentmay have application in specific deployments, in order to minimize the 38 deployment of redundant protocol infrastructureinstances, HELD addresses the broadest 2 24
  25. 25. 1 ATIS-XXXXXXX 1 range of NENA requirements across network implementations . ESIF recommends 2 HELD as the location acquisition protocol for networks which do not have existing 3 infrastructure in this domaingoing forward, and specifically for the NENA i2 V0 interface 4 and similar interfaces going forward. In addition, ESIF recommends HELD as the protocol 5 for LIS to LIS communication. 67.3 Location Parameter Conveyance Protocol Recommendations 7 The analysis in this document has highlighted the need for a location parameter 8 conveyance protocol. Feedback received from other SDOs indicated no current overlap for 9 development of a location parameter conveyance protocol. ESIF plans to initiate the 10 standards development and formal specification of such a location parameter conveyance 11 protocol within the procedural framework of ATIS. 128 References 13[1]NENA VoIP-Packet Technical Committee, “Interim VoIP Architecture for Enhanced 9-1-1 Services (i2),” NENA 08-001, Dec 2005. 14 15[2]NENA Technical Committee Chairs, “Implementation of the Wireless Emergency Service Protocol E2 Interface,” NENA 05-001, Dec 2003. 16 17[3]TIA-1057 TIA, “Link Layer Discovery Protocol for Media Endpoint Devices (LLDP-MED),” TR 41.4 18 19[4]Winterbottom, J., Thomson, M., and B. Stark, “HTTP Enabled Location Delivery (HELD),” draft-winterbottom-http-location-delivery-05 (work in progress), March 2007. 20 21[5]Polk, J. and B. Rosen, “Session Initiation Protocol Location Conveyance,” draft-ietf-sip- location-conveyance-05 (work in progress), October 2006. 22 23[6]Droms, R., “Dynamic Host Configuration Protocol,” RFC 2131, March 1997 (TXT, HTML, XML). 24 25[7]Patrick, M., “DHCP Relay Agent Information Option,” RFC 3046, January 2001. 26[8]Polk, J., Schnizlein, J., and M. Linsner, “Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information,” RFC 3825, July 2004. 27 28[9]Peterson, J., “A Presence-based GEOPRIV Location Object Format,” RFC 4119, December 2005. 29 30[10]Thomson, M. and J. Winterbottom, “Revised Civic Location Format for PIDF-LO,” (work in progress), April 2006. 31 32[11]Thomson, M., “Geodetic Shapes for the Representation of Uncertainty in PIDF-LO,” (work in progress), May 2006. 33 34[12]Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information,” (work in progress), January 2006. 35 36[13]Winterbottom, J., Tschofenig, H., and M. Thomson, “GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations,” (work in progress), May 2006. 37 38[14]Winterbottom, J., Peterson, J., and M. Thomson, “Rationale for Location by Reference,” (work in progress), January 2006. 39 2 25
  26. 26. 1 ATIS-XXXXXXX 1[15]DSL Forum, “Core Network Architecture Recommendations for Access to Legacy Data Networks over ADSL,” Technical Report 025. 2 3[16]DSL Forum, “Migration to Ethernet-Based DSL Aggregation,” Technical Report 101. 4[17]Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, “Geopriv Requirements,” RFC 3693, February 2004. 5 6[18]NENA Technical Requirements Document (TRD) for Location Information to Support IP Based Emergency Services, NENA 08-752 Issue 1,December 21, 2006. 7 8[19]Droms, R. and W. Arbaugh, “Authentication for DHCP Messages,” RFC 3118, June 2001. 9[20]NENA Recommended Method(s) for Location Determination to Support IP-Based Emergency Services - Technical Information Document NENA 08-505, Issue 1, December 21, 2006 10 11[21]Woundy, R. and K. Kinnear, “Dynamic Host Configuration Protocol (DHCP) Leasequery,” RFC 4388, February 2006. 12 13[22]"IP Location; Geographic Location Measurement, Delivery and Conveyance", Dawson, Winterbottom , Thomson; Osbourne-McGraw-Hill; ISBN: 007226376 14 15[23]Wimer, W., “Clarifications and Extensions for the Bootstrap Protocol,” RFC 1542, October 1993. 16 17[24]Patrick, M., “DHCP Relay Agent Information Option,” RFC 3046, January 2001. 18[25]Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie, “Definitions of Managed Objects for Bridges,” RFC 1493, July 1993. 19 20[26]National Institute of Standards and Technology (NIST) – Federal Information Processing standard 140 version 140-2, May 2001. 21 22[27]Dawson, Winterbottom, Thomson, “IP Location”, McGraw-Hill Publishing, 2006 23[28]Schulzrinne, H., “RELO: Retrieving End System Location Information”, draft-schulzrinne- geopriv-relo-02.txt, December 17, 2006 24 25[29]Schulzrinne, H., “A Location Reference Event Package for the Session Initiated Protocol (SIP),” draft-schulzrinne-geopriv-locationref-00.txt, October 17, 2006 26 27[30]Rosenberg, J., “A Presence Event Package for the Session Initiation Protocol (SIP),” RFC 3856, August 2004. 28 29[31]Linsner, M. Schnizlein, J., “Location Configuration Protocol (LCP),” draft-linsner-geopriv- lcp-01, November 7, 2006 30 31[32]3GPP TS 23.167 IP Multimedia Subsystem (IMS) emergency sessions (Release 7) V7.3.0 (2006-12) 32 33[33]3GPP2 IMS Emergency Call: Stage 2 Specification: X.S0049 34 2 26

×