Why use Bluetooth for contact tracing?
Anonymous Bluetooth-based contact tracing is a hot topic at the moment. This blog post aims to open some of the technical background of why this method has become the weapon of choice.
The focus here is proximity detection — the technical problem of detecting when mobile devices come close to each other — which is a very closely related to the field of indoor positioning. Consequently, we at IndoorAtlas have been dealing with the technical issues related to it on a daily basis for several years.
The main factors in the technology choice are:
- Privacy: What data is exposed and to whom
- Accuracy: The spatial and temporal accuracy of the method
- Feasibility: What Apple & Google allow you to do with your own device
Bluetooth has been selected since it has the best combination of the above three when used alone. However, further improvements, especially in accuracy, could be possible with the fusion of several technologies.
The recent announcement of Google and Apple to join forces and launch an interoperable solution is a game changer in terms of feasibility: reasonable background operation would not have been possible otherwise, due to platform restrictions.
Could GPS be used?
There are quite many misconceptions about GPS on mobile phones. This is a longer topic that we may cover in another blog post later. The main point is that, most of the time, it’s not used to find the location of your phone, because it does not work indoors or near large buildings.
If you’re indoors or in a big city, the location of your phone that you see on, e.g., Google Maps, is computed based on signals from ambient WiFi access points. Through crowd-sourcing techniques, Apple and Google, along with some other players, have built automatically updating maps with the locations of practically all the WiFi access points in the world. If your phone tells what WiFi access points it hears, a WiFi scan, they can pinpoint your indoor location on a map, with an accuracy of about 50 meters or less. Note that this is not the same as connecting to a WiFi network. This works even if you have “turned off” the WiFi on your phone.
Contrary to a popular belief, phones can monitor your location in the background all the time without consuming all the battery. If you have an Android phone, you can test this by turning on the Location History feature and looking at the Timeline. Each place you visit is accurately recorded in the background without a major effect on your battery. If satellite navigation was used all the time, then the battery would be drained, and that’s why it’s not used all the time, but your location is still recorded — all the time. Admittedly confusing.
There are also a few other techniques the phones use, such as cell tower localization and AGPS, but those are not relevant here. The relatively accurate locations come either from WiFi or GNSS (= GPS & other sat-nav systems supported by the phone). 5G will change the situation, but it’s not here yet.
Anyway, could the GPS-that-is-actually-WiFi be used for contact tracing? The biggest issue seems to be altitude information, which is not consistently provided by the built-in location services (apparently Google’s WiFi world is 2-dimensional) so people on different floors of the same building could be incorrectly detected as being close to each other.
The altitude issue would be fixable with access to raw WiFi scan data (which Apple and Google restrict everyone else from accessing and reserve it for their own business), which could help with horizontal accuracy too, but in any case, the WiFi + GPS solution would probably have somewhat lower accuracy than Bluetooth-based contact tracing. See, e.g., this publication for more details about WiFi-based proximity detection.
Enter Bluetooth
Bluetooth Low Energy (BLE) is a radio specification originally developed by Nokia. The key thing in this specification is that it allows battery-powered devices to communicate in very short radio bursts, which can allow them to operate highly energy-efficiently.
In 2013, Apple launched a protocol called iBeacon, which allows iOS applications to detect when they are in the proximity of a device that transmits iBeacon signals over BLE. The first applications were proximity-based marketing and advertising: a loyalty app may detect when you are near a certain store and send you coupons or just record that information and use it for profiling. This usually involves installing small battery-powered iBeacon devices in places or on objects whose proximity to the user’s phones one wants to monitor.
Right: proximity marketing use case
The iBeacon protocol, and some of its variants, are supported by both Android & iOS applications. It has consequently become the basic go-to technology for indoor location applications. However, I would like to stress that in many cases, installing thousands and thousands of such disposable devices could have been avoided (saving tons of natural resources and work hours) if Apple had not blocked other players in the business from accessing the WiFi data on their devices.
There are many innovative things one can do with iBeacons and BLE besides advertisement. The proposed contact tracing methods are a prime example. The idea is that the mobile devices do not only passively receive Bluetooth signals, but also transmit them so that the devices can detect when they are in the proximity of one another — without installing any BLE hardware.
Contact tracing methods where the nearby devices directly communicate with each other over BLE have the advantage of directly obtaining information about the distance between the devices. This is in contrast to the alternative where one would first compute the locations of potentially nearby devices (based on WiFi or BLE beacons) and then compare them.
Background processing limitations
The main practical issue in contact tracing is that you have to track the devices in the background all the time. If implemented naively, this would consume a lot of battery. There are also valid privacy concerns regarding access to location-related data, such as Bluetooth, during background operation (this is not specific to contact tracing).
The tech giants have chosen a rather simple solution: they mostly reserve these capabilities for their own business and severely limit the capabilities available to third-party apps. Both mobile platforms have severe restrictions on how the applications are allowed to use resources (network, GPS, Bluetooth, CPU) in the background — that is, when the user of the phone is not using the application.
Here’s a concrete example on how the restrictions affected the OpenTrace project, the Singaporean open source contact tracing application, and what kind of extreme workarounds they had to propose:
OpenTrace is bound by restrictions that iOS has on background Bluetooth functionality.
When in the background, the iOS app advertises in a proprietary advertisement format that is not part of the Bluetooth standard and thus not readable by non-iOS devices. It is also unable to scan for other BlueTrace devices in any meaningful way.
The current workaround is to encourage iOS users to keep their app in the foreground, especially when in higher-risk environments. Within the OpenTrace reference implementation, we have implemented a “power saver mode”, where users can flip the phone upside down to dim the screen so the app uses less battery power while in the foreground. Users, particularly inactive users, also receive push notifications to remind them to use the app, especially during commuting peak hours.
The European DP-3T project white paper has several pages of discussion around blockchain-ish decentralized privacy concerns, but all they say about the BLE protocol is this:
Easier said than done. The TCN Coalition — an umbrella for the efforts of researchers and experts from various universities, companies and other institutions— proposed an elaborate protocol of broadcasting and connection-oriented BLE communication, where:
iOS(B)-iOS(B): Nearby Android device acts as a bridge
In other words, the background encounter between two iOS devices could not be detected unless there is an Android device nearby. Covid Watch (also part of the TCN Coalition) stated they had met with Apple (and Google) before the release of the Apple-Google collaboration to discuss this.
The tech giants actually had to act before the platform restrictions — which, under normal conditions, can kill businesses but not people — became the bottleneck in deploying this tech. Good that they did.
Limitations of BLE
A BLE advertisement message has a small payload which practically is only a numeric identifier of the device (which could be varied randomly for privacy-enhanced contact tracing methods). In addition to the payload, the receiving device observes the signal strength (RSSI). The signal strength reduces with distance: the further the sender, the weaker the signal — until it is no longer detected. In theory, if one knows the transmission power of the source, one should be able to compute the distance between the sender and the receiver from the inverse square law.
Not quite. The received signal strengths also vary wildly depending on:
- Sending device model
- Receiving device model
- The geometry of the building
- The location of the devices within the building
- Number of people nearby
- Whether the device is in the pocket or held in hand
- The direction the person with the phone is facing
- The signals bleed through floors — probably unlike the virus.
Some of these factors can be modeled in mobile phone applications, some cannot. Many of the effects are caused by the phenomenon called multi-path propagation. Knowing this does not help you at all in practice, but it is nice to know that the laws of physics (like the inverse square) still hold.
Based on what we at IndoorAtlas have learned about BLE signals, reliably computing the distance between two devices using BLE only is very challenging. At the very least, RSSI biases caused by both the sending and receiving device have to be calibrated out. When working with iBeacons, we have noticed that, even if the sending device is the same (a fixed iBeacon), different devices observe very different RSSI patterns. Differences of 20 dBm (= 100x signal strength difference) are not unusual.
We have also mined some of the anonymous data that travels through our cloud, and have been able to estimate these biases for popular devices for the purpose of improving the accuracy of our positioning algorithms. The below figure shows an example of this.
The per-device RSSI biases were listed as one of the key challenges by the OpenTrace team, who aim at detecting encounters at proximity 2m or less, and have also published some great documents on how they approach the problem.
It would be interesting to hear more about what kind of proximity detection accuracy the various other projects are aiming at, and what kind of data they have to test if they can reach that accuracy. This could also help the epidemiologists to set their expectations on the accuracy of BLE-based digital contact tracing. For example, distinguishing between a 15-minute exposure at a 2-meter distance and at a 4-meter distance may not be feasible.
My guess is that the accuracy of the proximity event will not be very high. There will be both missed and false positive contacts (e.g., the infected person was always more than 10m away), which is probably fine as there is no need for the method to work perfectly in order to help at the population level.
Privacy
The cryptographic privacy aspects of the Bluetooth-based contact tracing methods are quite extensively discussed in the white papers [1, 2, 3]. They also propose various methods for handling the data in a decentralized way. In particular, it is possible to implement a tracing system so that the users’ location or BLE contact data remains only in their own devices until voluntarily uploaded in case of an infection. This is how the specification from Apple and Google also works.
An interesting question is, in which scenarios the handling of the random BLE tokens is more secure or private than handling GPS-like location data. For example, the OpenTrace white paper describes the Singaporean process where the human contact-tracers manually map these contact tokens back to actual locations through interviewing the infected. This, by definition, reveals the locations of the other users involved in these encounters too.
Broadcasting cryptographic random tokens over BLE is not without privacy risks either. Third party companies that listen to Bluetooth traffic through, e.g., mobile advertising SDKs or fixed BLE-sniffing equipment in public spaces, can be able to associate some of the tokens with actual locations (this concern was also raised here related to the PEPP-PT project). The TCN Coalition documents estimate that if wide-scale BLE contact tracing proliferates, the proliferation of BLE-sniffing equipment will quickly follow.
Furthermore, even if the payloads of the Bluetooth messages were random, some of the privacy details depend on the Bluetooth implementation in the operating system, which may be developed by either the OS vendor or the device manufacturer and cannot be changed by the applications. In particular, if the BLE MAC address randomization scheme is not properly implemented (or even missing), third parties can track the device movements by listening to the BLE signals. This especially concerns older Android devices, but the track record is not great on iOS either.
From the privacy point of view, the difference between the BLE tokens and location data may not be as significant as it initially seems, if even third parties may have the capability to map the tokens back to locations. As long as that data is shared only to trusted health authorities on a need-to-know basis, the privacy implications are similar.
Beyond Bluetooth
If the beginning of the post was relatively objective and educational, this part is openly promotional: Our company specializes in accurate indoor positioning using the fusion of several technologies. In addition to BLE, we use WiFi (when available), IMU (movement) sensors, and geomagnetic information.
The below video compares our indoor positioning system (IPS) to RSSI-based proximity detection — the technique used in purely BLE-based contact tracing. The RSSI values have been smoothed and optimally calibrated for this device pair, which, as far as we know, is the best you can do with such RSSI-only data.
Both methods have their pros and cons. Even though faster and more accurate, our current IPS is not a feasible option for population-wide contact tracing since it requires the each venue to be signal-fingerprinted (surveyed).
On the other hand, there are relevant use cases in the aftermath of the crisis that are not possible with the decentralized BLE solution from Apple & Google. For example
- monitoring in near real-time, if a certain space is occupied by too many people
- tracing the exact routes walked by potentially infected individuals in key venues, such as hospitals
- standard indoor navigation features such as wayfinding, which helps patients, other visitors, and employees to find the most efficient route to a destination — reducing unnecessary hovering in public spaces
Despite the above socially-distanced office demo, the solution does work outside our office too. The IndoorAtlas positioning SDK is currently installed to about a dozen million devices.
If you are interested in more accurate indoor contact tracing, or indoor positioning in general, let us know: https://www.indooratlas.com/contact-us/
