Bluetooth proximity tracking

From Appiaplus
Revision as of 08:35, 15 May 2020 by Bram.vandenholen (talk | contribs) (Created page with "= Bluetooth = * BLE is a battery-friendly technology * BLE is not a true peer-to-peer protocol: it makes a distinction between a peripheral and a central. A peripheral can br...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


  • BLE is a battery-friendly technology
  • BLE is not a true peer-to-peer protocol: it makes a distinction between a peripheral and a central. A peripheral can broadcast information, so it can be discovered by a central during a scan. After discovery, the central can try to establish a connection (pairing) with the peripheral to exchange information. In most cases, pairing is followed by bonding, which establishes a long term association. In this protocol, the peripheral can be considered the “server” and the central the “client”.
  • Apps on iOS and Android can act both as a peripheral and as a central at the same time. In a “peer-to-peer discovery” scenario, that is also necessary: each device needs to broadcast its own information and periodically scan for the signals of other devices.
  • On Android, pairing only is not supported. As there is a cap on the number of bonded devices this limits the number of simultaneous encounter detections possible.
  • Both iOS and Android impose restrictions on using BLE while an app is in the background. In particular, iOS does not allow standard peripheral advertisements in the background, but instead uses a proprietary BLE advertisement. This breaks compatibility between iOS and Android devices, since Android devices are no longer able to detect iOS devices. Only the recently announced Apple/Google contact tracing APIs do not suffer from this incompatibility.
  • This results in three options:
    • Using the Apple/Google framework with its imposed requirements (only for official apps, no capture of location data)
    • Using BLE and instructing users to run the application in the foreground (cfr UK, Singapore, Australia). Variations exist, with the most sophisticated being the Australian app which keeps the app in the foreground but goes black and does not accept user interactions while preventing the operating system to put the device in standby. The app gets reactivated when the accelerometer detects relevant manipulation of the device.
    • Falling back to handshakes via BLE connections (GATT) instead of advertisements. This is less impacted by the advertisement incompatibility (iOS devices can still detect other iOS devices and Android devices), but comes with its own share of limitations (limited number of simultaneous connections, limited number of bonded devices, ..) - See

Accuracy of Bluetooth for detecting encounters

Strictly speaking what is detected is the fact that a device observed a signal of a certain magnitude, which was captured (hence was not fully blocked by some obstacle). Duration, at least in Apple/Google and in DP3T is derived from the number of times the same signal was captured (knowing the signals are advertised at regular intervals). The distance between the devices is estimated from the delta between the transmitted signal strength (TX power) and the observed signal strength (RSSI - Received Signal Strength Indication). This is only a distance estimation, as the only 2 values that the receiving app knows are the transmitted power of the sender and the maximum received RSSI. From these 2 values an attenuation value is calculated which gives in indication to distance, but attenuation can be due to other factors as well, like phone being in a bag, an obstruction between the sender and receiver like a wall, or interference from other signals.


With this way of working, following false negatives and false positives can happen.

False Negatives:

  • Non-users are not advertising and cannot be detected.
  • Signal strength can be below a usable threshold or attenuated due to the obstacles and absorbing material like the body, the environment, ...
  • The encounter might have happened just in-between signal advertisements.
  • The encounter might be short but high-intensity.
  • ...

False Positives:

  • The other device is at the other side of a wall or partition from material that does not block the signal completely (light material, plexiglass, glass, …) but blocks the spread of the virus.
  • The other device was detected at multiple intervals but did not stay within distance between those advertisements, counting for a long duration. This could happen e.g. with shop personnel circulating through the shop.
  • If both participants in the encounter were wearing protective gear.