Location Measurements in HELD

The extensibility options provided in HELD permit the inclusion of arbitrary content. This flexibility means that devices are able to provide the LIS with location measurements. The LIS is able to then use these measurements to determine the location of the device. In some cases, like ad hoc wireless LANs, the LIS might even be able to use these measurements to determine the location of other devices in the network.

The capabilities indication extension to HELD can be used by the device to indicate that it is capable of providing different sets of measurements. This information is carried in the context creation response and includes enough information for the LIS to be able to receive these measurements. The way in which location measurements are given to the LIS is dependent on the type of access network. This means that suitable protocols can be developed for the specific type of measurement; each measurement access protocol needs to have appropriate features to address the nature of the measurements, from relatively static information from LLDP, to the complex Assisted-GNSS data exchanges provided in SUPL (see Reference 1 at the end of this chapter).

Location Assertion

The easiest way that a device can participate in location determination is through the use of location assertion, which is described in more detail in Chapter 4. When the device makes a location request to the LIS, it can include location information in the request. If the request is made with a reference to a LIS context, the LIS can store the device-created location and use it in response to later requests instead of relying on the location generation capability in the LIS. This means that applications are able to receive the more precise device-determined location information. If a device pushes this information to the LIS regularly, then this information is always available. Figure 9.5 shows how an assertion could be made and the location information could be cached for later use.

Figure 9.5: The LIS could cache location information for later use.

Asserted location information is only kept for a short time at the LIS to prevent the information from being invalidated as the device moves beyond the ability of the LIS to detect. Location assertion provides a crude, but effective, means of including the device as a part of location determination. The more precise location information from the device is only available to the LIS if the device has recently asserted location. This means that the device needs to push location information to the LIS regularly. It is more effective if the LIS is able to request location information directly from the device as it is needed. Having a way for the LIS to query the device for information is desirable.

Device Callback

HELD and HTTP requests are single operations; a persistent session between the LIS and device is not established. The communications are established in one direction only-the device contacts the LIS for information. However, a location URI causes requests to be directed to the LIS. Therefore, if the device is to provide location information or measurements for the LIS to use in serving a request, the LIS needs to be able to contact the device when the request arrives. To do this, the device either provides the LIS with a means for contact, or establishes a more permanent communications channel.

The concept of a callback URI provides a simple means for the LIS to retrieve location information from the device. The device includes a URI in a context creation request or context update request. Additional information is included in the request that assists the LIS in deciding when to use the URI, such as the expected amount of time that the device could take to create a response. The LIS can then use this callback URI to contact the device when it receives a request from an external location recipient. Figure 9.6 shows how a callback can be used to request location information when triggered by an external location recipient.

Figure 9.6: The LIS uses a callback to access device-based information on demand.

Using a URI for callback purposes has some limitations that could cause it to fail in a range of network configurations. For instance, a NAT device or firewall between the device and LIS can ensure that any contact information provided by the device is not usable by the LIS. In some networks, particularly residential broadband, a home router with NAT and a firewall is extremely common. In these situations, callback fails unless steps are taken to ensure that the LIS can contact the device. For current deployments, UPnP is a common feature of home NAT devices, which can be used by the device to enable a callback. Alternatively, a LIS "proxy" feature can be implemented in the NAT/firewall device that enables LIS communications and facilitates the creation of callback details.

In larger networks, the LIS needs to be able to access the network. That is, the LIS is required on the same network segment as the device, behind the same NAT/firewall device. These types of LIS can act autonomously, or they can use another LIS outside the network to provide services, in much the same way a device requests certain services of a LIS.

Capability Negotiation

If location measurements from the device are to be used, the LIS has to be aware that they exist. For an unknown device that enters the access network, the LIS cannot assume that it is able to provide measurements. Therefore, the device must first advertise its capabilities to the LIS. The device includes a capabilities indication parameter in the HELD context creation request. The LIS can then indicate which of these capabilities it is able to use in the response to this message. The LIS stores this additional information in the context that it creates; the device can update this information using the update context request if conditions change.

Figure 9.7 shows how capabilities are indicated at context creation, and how they can change using the context update procedure. In this scenario, the initial context is created when the device is able to provide LLDP and WiFi measurements; the LIS indicates that it will only be able to use the LLDP measurements. The context is updated when the device moves off the wired connection and LLDP is no longer available.

Figure 9.7: A capabilities indication is made so the device can be updated as circumstances change.

Along with a general indication of capabilities, both the LIS and device include enough additional information for the actual exchange to take place. Each capability indication can include additional information that expands on the basic capability, such as network addresses and ports that can be used, protocol requirements, any constraints on the information, and how long measurements will take to acquire. This additional information ensures that both the LIS and the device have adequate information to successfully communicate.

Once this capability indication phase has been completed, the location measurements are exchanged in a manner that is most suited to the type of measurement. This flexibility permits the use of more advanced protocols where those protocols are most appropriate. For instance, A-GNSS is a cooperative location determination technology that requires a specialized protocol for the exchange of assistance data and associated information. Using capability negotiation, the LIS and the device can agree to use SUPL, which defines advanced procedures specific to A-GNSS, and the LIS can provide the SUPL Location Platform (SLP) address for a SET-initiated SUPL session.

Capability indications make it possible for the LIS and device to cooperate in location determination. A few examples of this process are included later in this chapter.