Device-Based Technologies

This section looks at how a number of location determination methods can be used. This includes information on the measurements that can be taken and some scenarios where those technologies are useful. A few examples are included to demonstrate how the LIS and the device communicate this information.

A User-Entered Location

While user-entered location information is not exactly a "technology," it cannot be disregarded as a way of providing accurate and precise location information. A user may be more readily able to provide precise information about their location than a network-based method with its potential inaccuracies. This method involves the user manually entering location information into a form, which the device is then able to provide to the LIS or location recipients. This information is usually in the form of civic address information because that form is most readily available to users. Geodetic information can still be entered by this method, particularly if the user has a means of measuring coordinates-for instance, they could source latitude and longitude measurements from a handheld GPS unit.

User-entered location information can be dynamic, but since this requires constant interaction from a user, it is more useful when location doesn't change over time. Therefore, fixed and nomadic devices are best suited to this approach. With HELD, this means that location assertion is used and the callback methods are rarely applicable. The assertion and validation process also provides a valuable "safety net" for when a user moves the location without updating the user-entered location information.

It is important to note that user-entered location is especially subject to location fraud unless basic checks are put in place. This means that the ability of a LIS to validate location information is particularly useful in protecting against fraud for manually entered data.

LLDP Measurements

The base LLDP specification (see Reference 1) includes mandatory parameters that are provided from any compliant device within a network. These values are not explicit indications of location, but identify the network attachment point for a device. This means the LIS is able to use a database to determine location based on the attachment information. The mandatory fields of interest in LLDP are:

• Chassis ID This can be used to uniquely identify a switch or LAN entity. A range of identifiers are possible, including MAC and IP addresses or a locally defined identifier.

• Port ID This unambiguously identifies a port on the switch.

• Time To Live This value is useful in determining when this information becomes stale and should be refreshed.

LLDP is a one-way protocol in that messages are triggered by a state change or the passage of time; LLDP messages cannot be solicited. If LLDP is used for location measurements, the device must provide an LLDP receive module. Other nodes on the LAN segment also need to implement an LLDP transmit module that transmits LLDP frames. The device uses the information in these frames to build a remote system MIB (Management Information Base) that contains this information. This information can then be provided to the LIS as location measurements. In this case, the information can often be retrieved using the Simple Network Management Protocol (SNMP) as direct SNMP queries, or possibly traps.

In the example shown in Figure 9.8, the device receives an LLDPDU (LLDP Data Unit) from a switch when it attaches to the network. The device then stores this information in its remote system MIB. It then creates a context on the LIS and indicates that it is capable of providing measurements from LLDP using SNMP, including the community string so that the LIS is able to access the information. The LIS indicates that LLDP is supported in the context response message. After this, when a request is made to the location URI at the LIS, the LIS is able to query the device using SNMP for the Chassis and Port IDs of the switch. The LIS uses these measurements and a database to determine location.

Figure 9.8: An LLDP-capable device can provide measurements using SNMP.

Note that this usage of LLDP demonstrates another possible way of using the LLDP primitives that differs from the descriptions of LLDP-MED in Chapter 5.

Wireless LAN Measurements

Chapter 7 described a number of measurements that could be acquired from a wireless LAN. The LIS can use these measurements to determine the location of a wireless terminal within a wireless network. One important observation about location measurements in WLANs is that they can be acquired by any participant in that network. For infrastructure networks, it makes sense for the LIS to rely on access points, whereas in an ad hoc network more information is required.

The device is a good source of location measurements in a WLAN. Many of the measurements described in Chapter 7 are available to all WLAN devices. The device is able to provide the LIS with information that is directly useful in determining its location. This area remains the subject of research.

RFID Beacons

Passive RFID tags in fixed locations can be used in location determination. If a device is able to read an identifier from an RFID tag that is in its proximity, then it can transmit this identifier to the LIS. The LIS can then use a database of known RFID tag locations to determine where the device is located. Alternatively, an RFID tag could include an encoded location value, which the device could use to determine location autonomously.

As an example, RFID tags can be used to provide desk-level precision in the absence of wired connections. Wireless LANs are used in place of wired Ethernet in enterprise networks due to their cost and deployment benefits. However, wireless location determination may not be able to resolve location with sufficient precision to identify a single desk. An RFID tag placed at each desk with either a unique identifier or an encoded location value can be read by a device. With a range of only a few meters, RFID provides a good desk-level resolution of location.

Figure 9.9 shows a possible request sequence where the device provides the LIS with a code from nearby RFID tags. The device indicates that it is capable of reading RFID tags when it creates the context at the LIS. The LIS then requests that the device take a measurement when a request is made. The protocol mechanisms used for this request are not yet specified, but may be indicated in the capability indication. The LIS uses its database to produce a location estimate based on the RFID codes.

Figure 9.9: A device that can read RFID tags can provide those codes as measurements.

Alternatively, the RFID tags could encode location information, which would make it possible for the LIS to provide location without a database. Either the LIS or the device can decode the location information from the RFID code.

GNSS and Assisted-GNSS

The term Global Navigation Satellite System (GNSS) is a generic term that is applied to location systems that use satellites to determine location. The prime example of this is the Global Positioning System, GPS, a system of satellites that are operated by the United States military (see References 2 and 3). There are a number of satellite constellations in space that provide navigation signals, including the European Union's Galileo, Russia's GLONASS, and a range of other constellations including those of Japan and China. This section deals with GPS and Galileo, which are very similar in function and features.

A device that is equipped with the appropriate antenna and circuitry can make measurements from GNSS satellites. The device measurements consist of a set of pseudorange measurements, which are determined by calculating how long the signal took to travel from the satellite. This is done by taking the known sequence transmitted by the satellite and comparing it against a local copy at various offsets and finding the offset where the two signals match. For GPS, each satellite uses a different 1023-bit pseudorandom sequence that repeats continuously. The observed Doppler shift in the signal is also included in measurements (the Doppler shift is used to calculate the velocity of the device).

GNSS signals are transmitted at low power to preserve the energy storage on the satellite and prolong its life. Satellites are also a significant distance from the Earth's surface. Therefore, signals are very weak when they reach the ground and they can be easily blocked by buildings or foliage. Receivers have to search for this weak signal in two dimensions: the offset of the pseudorandom sequence; and a range of Doppler shifts that arise because the satellites are moving. Finding this signal can be difficult, therefore sophisticated hardware has been developed that can search a larger area of space in a short time. The effectiveness of a GNSS receiver depends on how much of this sophistication is incorporated into its circuitry-for instance, one cost of improved speed is the greater amount of power that more complex circuitry consumes.

Once the signal is acquired, a device that is operating autonomously uses data that are overlaid on the signal at very low data rates to extract additional information. This information includes satellite ephemeris, the current position and speed of each satellite, time data, and other data that can be used in calculating the location of the device. This process can take a while because the information is transmitted at a very low data rate.

Both the search time and the time required to receive data can be reduced by using assistance data. Assistance data include the data that the device would otherwise have to receive from the satellites and this can also be used to reduce the size of the search window. Based on a rough estimate of where the device is, a server calculates a likely range of values for the sequence offset and Doppler shift and sends that to the device. The device can use assistance data to speed up the signal acquisition time. If the device is indoors, or the signal is weak for any other reason, assistance data can allow the device to more thoroughly search for the signal, meaning that weaker signals can be received. The server can also send satellite information using the higher bandwidth available in the access network, further reducing the time required for location determination. Using assistance data with GNSS is known as Assisted-GNSS (A-GNSS); due to the popularity of GPS, the term A-GPS is often used.

Devices that operate autonomously can use these measurements to determine their own location. This calculation provides the device with the precise time that the measurements were taken. However, the calculation phase can require significant processing resources be devoted to the measurements, which can be relayed to a server for the processing phase. This can avoid draining device resources and also allows the server to use network measurements in the calculation phase. Where a server performs the final calculation phase is known as device-assisted A-GNSS; if the device calculates its own location, it is termed device-based A-GNSS. In device-assisted A-GNSS, the device does not require as much satellite data, which can save network bandwidth, assistance data delivery time, and handset battery life.

Secure User Plane Location

Version 1.0 of the Secure User Plane Location (SUPL) Specification (see Reference 3) provides an architecture and protocol specification for cellular networks for GPS. Version 2.0, which is under development, includes support for Galileo. SUPL supports autonomous device-based GNSS, as well as device-assisted and server-assisted A-GNSS. SUPL can be invoked by either the device to determine its own location, or the network at the request of an external application, another device, or as needed for network operation.

From the network architecture perspective, SUPL is based on a closed model where roaming agreements must exist between access networks before the service can operate. This works for cellular access networks because those arrangements need to exist before network access can be provided, but these same agreements are contrary to the open architecture upon which the Internet is based. However, the assistance data exchanges and other core messages in SUPL are useful for either assisting the device in determining its own location or for acquiring A-GNSS measurements from the device. Reusing the protocol aspects of SUPL with some modifications is advantageous because specifications and implementations can be developed more rapidly.

The example SUPL flow in Figure 9.10 shows how the LIS can use SUPL messaging to deliver messaging information. This is a device-assisted scenario where it is assumed that the LIS also acts as a SUPL Location Platform (SLP).

Figure 9.10: Device-assisted A-GNSS using SUPL messaging that directly involves the LIS.

If a device indicates that it is a SUPL Enabled Terminal, or SET in SUPL terminology, the LIS can then initiate SUPL procedures to retrieve location measurements or location information from the device. The LIS indicates its intentions with a SUPL INIT, to which the device responds with a SUPL POS INIT. The LIS then needs to determine a coarse location estimate so that it can provide appropriate assistance data. Following this, the device uses the assistance data to acquire the satellite signals. In this scenario, the device returns the raw measurements to the LIS, but it is also possible for the device to calculate location and return this information to the LIS instead.

The advantage of using this configuration is that the LIS is given the pseudorange measurements determined by the device. These measurements can be combined with other forms of measurement to form hybrid location determination methods, which are likely to produce more accurate results with a lower chance of failure. The alternatives to this method involve the device calculating the final location, or a separate SLP could manage the SUPL messaging, assistance data, and calculation.

Utilizing SUPL in a LIS in this fashion calls for very minor modifications to the current specifications and SET implementations. In particular, it requires that the SET is able to communicate with an SLP in the access network rather than assuming it only uses its service provider's SLP. Interestingly, at the time of writing, this exact function was under discussion in the OMA with a view to supporting emergency service using SUPL-determined location in cellular networks.