In order to get around the first and third of these problems, it makes sense to derive indoor location from the devices that people already carry. Mobile phones in particular are ubiquitous in many societies, feature an increasing array of communications technologies and are carried everywhere by their owners who find them useful and are motivated to ensure they remain charged and functional. Although it has been suggested that mobiles are sometimes farther from their owners than one might expect [162], they are more likely to be carried than any other device that could be used for location tracking.
To obtain in-building tracking using unmodified mobile telephones it is necessary to over-lay location tracking on established technologies. Such tracking has been demonstrated using signals from the mobile telephony networks, using WiFi and using Bluetooth; these systems are surveyed in depth in Section 2.8. At present, positioning from the telephony networks is too coarse for in-building location (Section 2.8.4). WiFi-based tracking has received much attention in recent years (Section 2.8.5), but it is not ideal for general tracking. It is associated with high power demands (and the resultant difficulty in con-vincing users to leave handset WiFi turned on), difficulty in set up and maintenance, small market penetration of suitable (WiFi-enabled) handsets.
Bluetooth-based systems are particularly attractive as they have low power requirements by design and almost everyone already carries a mobile phone that supports Bluetooth and has a computer on his or her desk. This is therefore the option adopted here to build example location systems suitable for personal energy metering.
Radio Baseband Link manager (ACL/SCO)
HCI
SDP RFCOMM
Applications
L2CAP
OBEX
Figure 5.2: The Bluetooth protocol stack.
Directly above the ACL is the Logical Link Control and Adaptation Protocol (L2CAP) layer. This is a packet-based layer that provides guaranteed packet sequencing and a selectable degree of delivery reliability. Once established, an L2CAP connection remains open until either end explicitly closes it, or the Link Supervision Time Out (LST) expires.
The LST is the time for which communicating devices are out of range before the ACL connection is reported as destroyed. The default LST is 20 s in many stacks, but can be configured dynamically per-ACL.
Above L2CAP sits the Radio Frequency Communications (RFCOMM) layer, which is the reliable stream-based protocol used by most Bluetooth applications. It represents the type of connection most people mean by ‘Bluetooth connection’.
5.2.2 Adherence to the specification
The Bluetooth specification is large, complex, and ever evolving. Implementations of it are not completely consistent in their interpretation and furthermore manufacturers have chosen to adapt some parts of the protocols to increase security. Only a few stack imple-mentations are mature enough to be considered stable. This can lead to unpredictable behaviour, especially when using consumer devices with embedded Bluetooth stacks. A number of the mobile phones tested here exhibited occasional instability and unexplained Bluetooth behaviour, some of which appears to be intentional. The Nokia 6300, for ex-ample, appears to have a connection timeout associated with L2CAP connections—after 20 s, the ACL is dropped if no RFCOMM connection has been established.
5.2.3 Paging and inquiry
Bluetooth uses frequency hopping within the 2.4 GHz radio band for channel robustness.
Every device retunes its transceiver every 625 µs to one of 79 Bluetooth channels. The precise sequence of changes is derived from its address and its local Bluetooth clock. For two devices to communicate they must have the same hopping sequence and phase at any given moment. To reach this state, Bluetooth defines a protocol that the two devices must follow. The protocol is known as paging and involves the master device sending search packets (‘pages’) addressed to the slave device until it replies. It is useful to consider the behaviour of the master and the slave separately; Figure 5.3 illustrates the process.
Slave. The slave device periodically listens for page requests on a particular radio channel for 11.25 ms. A total of 32 channels are used for paging, and the frequency the slave listens on is changed every 1.28 s according to a sequence also derived from its clock and its device address. If the slave does not detect a page, it sleeps for set period of time, Tpg scan. The Bluetooth specification defines threeSR modes which a device can adopt and which provide a limit on Tpg scan. These modes are R0 (Tpg scan = 0), R1 (Tpg scan ≤ 1.28 s) and R2 (Tpg scan ≤ 2.56 s). The default mode is R1, but some mobile devices adopt R2 to save power.
Master. With each page sent out, the master needs to estimate the frequency that the slave will be listening on. The device’s address tells it the hopping sequence, but it can only know the current sequence position by having an estimate of the Bluetooth clock on the slave. Once it has such an estimate, it then computes the most likely frequency to transmit on. However, in the 11.25 ms that the handset listens for, it has time to send pages to 16 channels. Thus it chooses a set of 16 frequencies that are adjacent in the hopping sequence and centred on its best estimate of the listening frequency. This set of 16 frequencies is known as ‘train A’ and allows for a degree of error in the estimate of the slave’s clock. It then cycles over this train
Figure 5.3: The paging process with parameters marked. A slave periodically listens on a single frequency for Tw pg scan. When paging, the master pages the 16 A frequencies in turn, each cycle taking 10.24 ms. After Npage cycles, it repeats using the B frequencies.
In this example, shaded cycles for the master indicate the cycles needed to connect to the slave shown [87].
of frequencies continuously for some for Twindow ≥ Tpg scan seconds. Assuming the slave is listening on a train A frequency, it will hear the page and respond, implicitly syncing the two devices. On average this should take 12Tpg scan to complete.
5.2.4 Radio interference
Whenever a device is paging or inquiring, it is flooding the 32 channels used for those purposes. In fact, the specification recommends (but does not require) that any estab-lished connections be temporarily parked during a page or inquiry. Inevitably estabestab-lished connections will be disrupted by continuous scanning or paging, meaning that tracking in this manner may limit the use of Bluetooth as the communications medium it was intended to be.
This was evaluated using three machines: one a nominal master; one a slave; and one used to provide interference in the same area (a nominal ‘external’ machine). Figure 5.4 depicts how long it took to transfer a 1 MB file from the master to the slave and back again under different conditions, which showed that external scanning or paging had little effect. However, when either the master or slave were continuously scanning or paging, the data throughput for the established connection fell dramatically. The connection was slowed rather than severed or permanently parked. These data apply only to the BlueZ stack, but indicate that the tracking techniques may be able to co-exist with ‘normal’
Figure 5.4: Measuring connection disruption. The chart shows the mean time taken to transfer a 1 MB to and from a Bluetooth device whilst the master, slave or an external device was continuously scanning or paging a fictional device address. The error bars show ±1 standard deviation.
Bluetooth usage, albeit reducing the data throughput.