Location Acquisition Alternatives and Comparisons to HELD

This section describes three location acquisition protocols, two of which are extensions of protocols that have their origins in enterprise networks, and the third being the HELD protocol. All three of the acquisition mechanisms are dependent on a central database to provide a mapping between physical location and a logical point of attachment (switch and port)-a.k.a., a wiremap. How and by which entities this information is accessed is discussed in the following sections.

Who Can Get Location?

Many people will answer this question by saying that only the end-point must be allowed to request its location. In reality, there is no right or wrong answer to the question of "who can get location?" since the acquisition of location very much depends on the application and circumstances. Existing free-phone services, such as those that allow you to dial to order a pizza, use location information attributed to your telephone number, yet this location isn't forwarded to the pizza shop even though the network needed to determine the phone's location. Requiring that location information only be made available to an end-point necessitates that all end-points in the network are location-capable. Being location-capable means that the end-point is able to request, acquire, and store location information. Furthermore, the end-point must recognize when location information is required by a service and make it available to the service or accept that the service will fail.

The majority of enterprises today do not have location-capable end-points, and the upfront cost to upgrade all end-points so that they are location-capable may be high. An example of exactly this kind of situation occurred around 2000 when cellular TDMA and GSM providers in North America were deciding what technology to endorse in order to meet the location requirement set by the FCC for Phase II emergency calls. If the phone helped in the location determination, using GPS, then it was a requirement that 95 percent of all phones would have to eventually be capable of GPS. This meant that the operator had to replace phones. Conversely, if the cellular operator used network-only determination, then the technology could service all existing and new phones. The estimated cost by some cellular operators to replace non-GPS-capable phones with GPS-capable phones to meet the 95-percent target was in the order of several billion dollars. Quite prohibitive! While most enterprises do not have millions of staff, many have thousands or even tens of thousands. Insisting on a wholesale swap-out or purchased upgrade of devices to make them location-capable is likely to be unpalatable in the short term.

The most commonly accepted alternative is to have a trusted network element request location on-behalf-of the end-point. This is referred to as an OBO request (see Figure 5.12). Take for example an IP-based PABX that terminates 5000 IP-phone extensions. If someone were to make an emergency call, the PABX could make a request to the LIS for the location of the calling device. The PABX would identify the device for which the LIS is to provide the location by including the IP address of the calling device in the location request. The PABX can then either direct the call based on the location or provide the location to the necessary emergency authorities. This requires a software upgrade in the PABX to perform this OBO request without necessitating changes to the IP phones.

Figure 5.12: PABX on-behalf-of location request.

Link Layer Discovery Protocol Media Endpoint Discovery (LLDP-MED)

Link Layer Discovery Protocol Media Endpoint Discovery (LLDP-MED) is part of the IEEE 802.AB standard suite. The aim of LLDP-MED is to allow devices connecting to networks using the IEEE 802 suite of layer-2 protocols to advertise and discover capabilities of "logical" adjacent network nodes (see Figure 5.13). The technical recommendation in Reference 8 (TR-41.4) describes three Endpoint classes and the range of element capabilities for each class of Endpoint. We shall direct discussion to class III Endpoints, which are targeted towards end-user communication appliances, such as IP phones and the like, and specifically the ability to provide location information to these devices.

Figure 5.13: An LLDP-MED Class III device network.

LLDP-MED requires location information to be published to an edge-device (switch) from a centrally managed database.

 NOTE: While SNMP is not mandated by the LLDP-MED specification, it is used extensively in examples and will likely be the common deployment mechanism.

Once published to the edge-device, the location information is stored in an SNMP MIB inside the switch. The switch will need to maintain location information for each discrete location that it serves. This may be a single location for an area with a cluster of office desks, or it may be a discrete location for each desk. Location information in LLDP-MED is delivered using the "Emergency Call Service Location Identifier Discovery Extension" and is targeted principally for emergency services usage. The amount of data that needs to be stored in the switch therefore is dependent upon local emergency regulations, the switch capability (capacity to store data), and the capability of the enterprise to accurately provide and maintain location data. Location formats available in LLDP-MED are aligned with those available over DHCP, namely the LCI geodetic form described in Reference 9 and the civic form described in Reference 10.

The intended use of LLDP-MED is that when a node attaches to the network it advertises its capabilities to its logically associated neighbors, and the neighbors reciprocate to the newly attached node. In this way, a node can learn, amongst other things, its location from the edge-switch to which it is connected. Location information is designed to be sent with an emergency call which requires the end-point to take the raw data received from LLDP and format it into a PIDF-LO. The end-point will need to have sufficient smarts and configuration data to allow this to occur so that the necessary mandatory fields are populated correctly. All this requires the node attaching to the network to be LLDP-MED-capable. So what happens if it isn't? The simple answer is that either the services are provided in a different way or they are unavailable.

As indicated earlier, while LLDP-MED does not stipulate SNMP must be used, employing it has the advantage that changes in network and switch configurations can be relayed back to a central NMS, allowing a network topology to be created. In this case, information about a specific device or hardware address connecting to the network is published to the NMS. If the end-device is not location-capable, then a LIS may use this information along with IP and MAC address bindings to determine the location of a device. This would allow support for things such as a PABX on-behalf-of location request to occur when location is not provided by the end-device, as illustrated in Figure 5.12.

DHCP Location Acquisition

DHCP location acquisition is described in 9and the DHCP civic draft described in Reference 10. Location data are treated the same as general network bootstrap data, and are provided to an end-point when the end-point first attaches to the network in the form of DHCP options. Location data can then be subsequently requested from the DHCP server either as part of a lease renewal, or network data refresh operation.

Reference 9 suggests that DHCP relay and Circuit-ID information is supplied to the DHCP server in the DHCP request, and that the DHCP server can use this information to determine the location of the end-point (see Figure 5.14). This mechanism for location determination was described in the earlier section titled "DHCP Relay Location Determination." Providing that end-points are not nomadic, then a static mapping from the end-point to the physical location can be used. The resulting key on which the mapping is performed may be a MAC address, IP address, or the "client identifier" defined in Reference 1. Where end-points may be nomadic and need to acquire a location at DHCP lease request time, the only viable option is to deploy a DHCP relay close to the point of network attachment since other mechanisms are likely to be too slow and result in DHCP client timeouts.

Figure 5.14: DHCP location acquisition.

As with LLDP-MED, in order to use DHCP location acquisition, end-points need to be location-capable. DHCP is an end-point-to-server-based protocol, consequently DHCP location acquisition is not suitable for OBO-based location requests as is required for legacy devices. However, aspects of DHCP information, as described in the earlier section "Location Determination in Enterprise Networks," can be used to provide ALE measurements to a LIS. One advantage that DHCP location acquisition does provide in an enterprise environment is that almost all enterprises deploy DHCP as the primary means for providing host configuration data to end-points. This means that the updates required to end-points to support acquiring location data may be small. However, it is also true that, no matter how minor, modifications to end-devices are required for Reference 9 to be useful.

HELD Location Acquisition

The inner workings of the HELD protocol were described in Chapter 4. In summary, the HELD protocol is an application layer protocol designed specifically to allow devices to request location in the same way regardless of the type of access network. The basic HELD protocol, as defined in Reference 11, provides support for location-capable devices to request their own location, either in the form of a PIDF-LO or as a location URI. The general operation is simple. Upon connection to the enterprise network, the HELD client discovers the LIS and makes a subsequent request for location (see Figure 5.15). For an enterprise LIS, discovery may be a hard-coded address, or it may be based on the access domain name, as described in Chapter 4.

Figure 5.15: A HELD location request.

The preceding description works well for location-capable devices, but the HELD protocol also addresses the problems experienced by LLDP-MED and DHCP, when devices are not location-capable and location needs to be obtained on-behalf-of these devices. To support OBO requests, a requesting node needs to be able to provide an identifier for the Target in the location request to the LIS, and there is no means to do this in the basic HELD specification.

The HELD protocol was designed to be extensible, and it was understood that certain network configurations and applications may require an on-behalf-of location query mechanism. This LIS requirement was identified and described in Chapter 4 as the Trusted-Party Query Interface. To support this capability, the HELD protocol messages were specified to allow extensibility through the inclusion of additional XML namespaces. Appendix D provides an XML schema that defines a variety of identifiers that can be used by an OBO requesting node to identify a Target end-point to the LIS.

Taking the example of the IP-based PABX depicted in Figure 5.12, assuming the use of the HELD protocol and the identity extensions defined in Appendix D, the information flow would look similar to Figure 5.16.

Figure 5.16: A HELD on-behalf-of location request.

The steps in Figure 5.16 are as follows:

1. End-point attaches to the network.

2. Network attachment is detected by an ALE, and the associated network measurements are passed to the LIS using FLAP.

3. The LIS uses the measurements contained in the FLAP message to determine the location of the end-point.

4. The end-point makes an emergency call.

5. The PABX determines that the call is an emergency call, and makes an OBO location request to the LIS using the IP address of the end-point as the Target identifier. The HELD protocol request would look something like the following:

    <locationRequest xmlns="http://sitacs.uow.edu.au/ns/location/held">    <locationType>any</locationType>    <heldDevice          xmlns="http://sitacs.uow.edu.au/ns/location/held:deviceIdentifiers">       <ipV4>192.168.1.5</ipV4>    </heldDevice> </locationRequest> 

6. The LIS trusts the PABX (this may be achieved through network provisioning or through the use of X.509 certificates) and uses the Target identifier contained in the location request, IP address 192.168.1.5, to retrieve the location of the end-point.

7. The LIS constructs a PIDF-LO and returns the location of the end-point to the PABX.

8. The PABX includes the PIDF-LO received from the LIS in the outbound emergency call.

The advantage of this configuration is that the number of devices and network elements that need to be location-capable is greatly reduced. It is in essence only the PABX. While the solution calls for a LIS, this function is also notionally required in both the LLDP-MED and DHCP location acquisitions since it provides the mapping between logical network identifiers and physical locations. The need for ALEs is very much dependent on the network configuration and how device attachments are detected and subsequently mapped to physical locations. In DHCP, the ALE is in essence a relay, while in LLDP-MED the ALE is an integral part of the switch and protocol design. Separating location acquisition from location determination enables OBO functionality to occur, and so reduces the cost of deploying location-aware and location-capable networks without the need to upgrade every end-point.