scope:

The NENA VoIP migratory working group defined the i2 network architecture designed to support emergency service calls originating from VoIP services on the Internet. The architecture requires location to be used to route a call to the appropriate PSAP and to provide location information to PSAP operator terminals. The i2 architecture describes the method by which location is obtained in terms of a function associated with a "Location Information Server" or LIS.

The i2 specification does not detail the method by which the VoIP device or proxy server provides location, nor does it describe how location should be determined. NENA requested ATIS/ESIF to provide recommendations for the protocol and implementation specifics of the LIS function for the broadband access network and emergency services industry. ATIS/ESIF has responded to NENA's request by the publication of this document.

The results of this analysis are provided as a basis for discussion and decision-making. Input from a range of major SDOs and other interested industry associations were taken into consideration in the development of this document.

Purpose

This document provides an analysis for VoIP location acquisition protocols. The "Location Acquisition" describes the manner in which VoIP devices or proxy servers obtain location. Among the likely methods are DHCP, LLDP-MED, HELD, RELO, LREP-SIP and LCP. Given that several of these protocols are already deployed by operators to configure those accessing their networks, it is likely that more than one protocol will be deployed, depending on the network architecture of the deployment. The development of a single protocol for use in networks without deployed infrastructure for host configuration is recommended. Candidate protocols for this functionality are compared against the NENA defined requirements. Candidate location acquisition protocols (DHCP, LLDP-MED, HELD, RELO, LREP-SIP and LCP) are compared against the NENA defined requirements.

Application

The following summarizes the recommendations of this ATIS Technical Report. The expanded recommendations and rationale are contained in Section 6.

The LIS function should be implemented in networks which do not already provide methods for configuring location in attached hosts, either by extending existing configuration methods or the use of an access-technology independent protocol.

Different types of devices may serve as a LIS in different network deployments; they will use protocols developed for those environments in most cases, but may use an access-technology independent protocol where there is no available infrastructure.

ESIF recommends that the need for standards for Operations Support Systems (OSSs) associated with a LIS be liaised to the appropriate standards committee.

For the NENA i2 architecture, ESIF recommends HELD as specified in the IETF as the access technology independent 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.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.