Why a Book on IP Location?

At this moment in history, it is not really possible to talk about IP location without discussing Internet telephony or voice over IP (VoIP) and the manner in which emergency services can be contacted using VoIP. This is described in more detail later but it stems from the fact that whether it's 911 in North America, 112 in Europe, 000 in Australia, or any of the many regional variants on the number, there is an almost global expectation and indeed critical need that emergency services be contactable via the most common publicly accessible voice ^[*] service. Up until now, that has been the public switched telephone network. We have entered a period where the plain old telephony service (POTS), and the switched circuit network behind it, have gone into decline and are being replaced by broadband Internet access as the standard all-purpose communication network. It is similarly inevitable that ubiquitous and reliable mechanisms for contacting emergency services using Internet telephony ^[*] will be required, both for practical and legal reasons.

So what does geo-location have to do with IP telephony usurping POTS, and emergency services being a requirement for both? It is relevant for the simple fact that location information is fundamental to the delivery of a single-number emergency calling service. In many jurisdictions, it is necessary to route the call to a different emergency call center depending on the location of the caller. In almost all jurisdictions it is a requirement to automatically deliver the caller's location to the emergency call center operator, without relying on the caller to provide it verbally. For better or worse, and no matter what applications for location follow in its wake, emergency service for IP telephony establishes the fundamental requirement for an IP location component of Internet access.

The authors have worked for a number of years through the development of the cellular-location industry, in the development of requirements, architectures, protocols, and, ultimately, deployed technology to support location determination in mobile phone networks. What was the driver for this technology? Once more the imperative was established because of the need to provide location for emergency calls originating from arbitrary locations within those cellular networks.

When the Federal Communications Commission (FCC) in the United States issued a mandate in 1996 that cellular networks should support the enhanced-911 (E911) functionality including location-based routing and location delivery, there was a scramble by different players to come up with a magic solution to this imperative. Every other week another new company would announce some technology that "solved the cellular E911 challenge." In the end, though, there was no "magic" solution. Location services (or LCS as it is commonly, if puzzlingly, abbreviated) as a network function is complex. It's not just about how to measure where someone is-whether it's with GPS, or the triangulation of measured radio signals, or some other clever invention. This is just a small element and, often, it's not where the greatest industry investment ends up being spent. In order to provide consistent and reliable LCS, an entire network architecture must be developed. This must not only involve what's happening between the device and the radio access network, but the whole core network that is responsible for routing request messages telling the appropriate systems when a location needs to be determined. The location information has to have a standard and consistent way of being delivered through networks so that it reaches the application of interest-for example, the emergency call center operator display. It has to be able to work for all manner of devices and not just those fitted with some specific vendor's technology.

In the end, for cellular, this meant the painstaking definition of an end-to-end network architecture with all the necessary protocols and parameter underpinnings. It touched everything from the application through the core network switches down through the radio controller elements, and the devices themselves. Without an end-to-end architecture based on open standards, there is no reliable, ubiquitous, and consistent location service.

With a history in the development of the LCS industry for cellular networks, the authors came to the emerging IP telephony and associated emerging emergency services imperative with a view that there could be no effective piecemeal solution to putting LCS in place for Internet services. In developments that, in many ways, reflected the same early days of cellular LCS, there were a number of concurrent, though somewhat uncoordinated, proposals. Examples include Reference 4 for DHCP and the LLDP-MED specification.

While the device's geo-location is not actually a piece of network configuration information, it is seductively tempting to just add it as another parameter that can be provided by DHCP. After all, that allows a device connecting to an IP network to utilize a standard mechanism, in order to "discover" its new location. The IETF specification, Reference 4, describes such an approach. However, the view of it is limited to the relationship between two single entities-the IP device and the DHCP server. There is no end-to-end network perspective on how this relationship fits into the larger picture of access technologies, applications, and the entities which may, in practice, be responsible for determining and underwriting the location of an Internet user. It does not facilitate any interaction with the device in terms of determining location, nor does it deal with the many public Internet access service considerations, such as the fact that DHCP is not a protocol typically used to deliver configuration from a broadband access network to the subscriber's device. And it does not provide any way to securely fix location information as being from a recognized and/or answerable entity; this last part being quite important to the operators of emergency services.

Dynamic Host Configuration Protocol (DHCP) (see Reference 4)

DHCP delivers network configuration information to an IP device. The intent is to provide the device with all the information it needs to utilize the IP network it's connected to. This includes information such as the IP address allocated to the device, the address of the gateway through which the traffic destined beyond the LAN should be sent, and/or the identity of the Domain Name Service (DNS) that can be requested to translate the names of network hosts into their physical IP addresses in order to talk to them. RFC3825 describes an option on DHCP that allows the device to request and receive a specific form of location information.

Link Layer Discovery Protocol for Media End-Point Devices (LLDP-MED)

At much the same time that RFC3825 was working through draft stages in the IETF, the TIA was defining extensions to the link layer discovery protocol (LLDP) to support additional information elements applicable to media end-point devices. These were termed LLDP-MED (Link Layer Discovery Protocol for Media End-point Devices) and included the ability for those end-point devices to be informed of the location associated with-for example-the 802.3 Ethernet switch port to which they are currently attached.

As a generic LCS infrastructure solution, LLDP-MED is similarly constrained compared to DHCP. It has the advantage of supporting location provisioned to specific switch ports, but it is still highly specific to this family of access technologies-typically, enterprise deployments. It has no application, for example, to broadband Internet access via DSL. Neither does it address issues of location source security.

Despite their fairly narrow focus, both DHCP and LLDP, with their associated location information extensions, were actively proposed and discussed as solutions to the larger VoIP 911 challenge. The author's felt that both mechanisms-although valid for specific scenarios involving location acquisition-did not provide either the generality or the end-to-end integrity necessary to support a global and consistent LCS capability for Internet services and, in particular, did not support emergency services calls using Internet telephony.

Drawing on experiences from the development of the cellular LCS infrastructure for both emergency and commercial services, and by understanding requirements through participation in numerous forums such as the National Emergency Network Association (NENA), the IETF, and ETSI, as well as engaging in discussions with emergency network authorities and regulators globally, the authors developed what, in their view, is a complete architecture for LCS. It is based on end-to-end requirements, providing a logical model for LCS in IP networks and identifying the specific network elements, interfaces, protocols, and parameters necessary to support general LCS services.

Such an architectural perspective on LCS has a good deal of complexity associated with it. Understanding the individual parts is not adequate unless the overarching principles are also understood. Going from architecture to successful implementation in a particular IP access network type requires an application of those principles, lest the requirements get lost in the details. The relatively simple two-peer details of DHCP or LLDP can be understood from specifications without much elaboration. The authors recognize that understanding a complete IP location architecture demands more substantial support for someone new to the area. It is for this reason that we decided to write this book. It is our desire that it will give the reader a firm understanding of the architecture as well as guidelines on the best approach to successfully implementing it in their networks and using it with their applications. It is our earnest hope that this book will facilitate the deployment of location services for the Internet and provide the robust and consistent underpinnings to support important social functions such as reliable access to emergency services by those in need, and contribute to the general utility, power, and fun of the Internet in general.

^[*]Yes-TTY, or teletype, is used in support of deaf callers and it could be argued that this isn't "voice". The distinction is noted with the observation that this alphanumeric character transmission function is also carried over traditional voice circuits using the telephone network. Hopefully the intent of the point above is not obscured by this specific subtlety.

^[*]Many assert that IP emergency "call" centers will be able to be contacted in many other forms-such as instant messaging and video. No disagreement; at time of writing, however, it is essentially a voice service and, it is certain, voice will continue to be a significant form of communication with emergency call centers into the future.