Inferring distance from Bluetooth signal strength: a deep dive

Published in

PersonalData.IO

10 min readMay 19, 2020

Contact tracing apps intend to predict exposure to a COVID-19 infection, where exposure is computed as some function of time and distance to an infected person. The distance is inferred from Bluetooth signal strength, which is a step that has not been empirically tested properly. We review evidence coming from the developing teams of what might or might not work to deduce distance from Bluetooth signal strength, and eventually question whether this is truly the goal of all those who implement contact tracing apps.

The goal of COVID-19 contact tracing apps is to calculate a risk of infection, based on exposure, and to notify users at risk. Exposure is calculated as a function of time and distance to an infected person. The public health recommendation for distance is that the COVID-19 risk decreases beyond 2m.

Inverse square law

If you are far away from an electromagnetic signal, it will lose strength. The idea is here to use this attenuation of the signal to infer distance. In principle, this is easy. Free from interference, the signal intensity should decrease like the square of the distance (the Power Loss Exponent would be different indoors).

The units for measuring signal intensity are a bit wonky. Here, we will use RSSI (“received signal strength indication”), which uses arbitrary units. It is therefore dependent on the measuring device, but the difference between such measurements can be productively compared, if taken from the same device. From the formula above, we see that a difference of 20 units (measured in dBm) should lead to a distance estimate multiplied by 10. Alternatively, you can use the rule of thumb that 6 units of RSSI multiply the length estimate by a bit more than 2 (the scale is logarithmic on the RSSI side).

What can affect the signal strength?

There are many factors that can affect the received signal strength:

emission power;
emitting device antenna path;
fight path;
receiving device antenna path;
receiver sensitivity.

The first two are tied to the emitter, the second two are tied to the receiver. The middle one is tied to what happens between the two.

The antenna path effects are due to path the signal has to take within the phones before getting out/after getting out. In particular it could be that the signal comes from/goes in a direction that is more shielded to the antenna due to other components, so we can’t really fold this effect into the emission power/receiver sensitivity effects, as it is directional.

We will now discuss the following points:

flight path interferences;
emission power;
receiver sensitivity;
noise in all those measurements.

Flight path interference

Body interference

The most natural type of interference to expect with smartphones is the human body. What effect might the body of the wearer or their hand have on the signal strength and hence the computed distance. This video shows it nicely.

In this video, the phone of the test subject emits signals, collected by the receiver set on the table. While the test subject has the phone in his front pocket, we see that the signal strength overs around a RSSI of -60, while it goes to -80 once the phone is in the back pocket. The difference in strength of 20 translates into a factor of 10 in the distance measured (here, from 1m to 10m). Holding the phone in the hand instead multiplies the inferred distance by 2 (this effect would be highly dependent on individual habits, as well as the phone model itself).

I have replicatedmyself, using iStumbler on my laptop and the “Pally BLE Scanner” app on my phone (with different experimental setups), that the shadowing due to a body is at least of 15dB (disclaimer: I should exercise more).

Another clear graph shows the impact of a body in a Bluetooth beam, again confirming the order of magnitude of the shadowing.

Plot of the RSSI impact of a body cutting through a Bluetooth channel. See Bluetooth for Proximity Detection.

Multi-path interference

The signals don’t just go in a straight line, and this will affect the strength perceived. For instance, apparently, a wet ground is highly reflective of the signals, and will lead to the distance being perceived as much closer to each other.

Emission power

The Singapore TraceTogether team used an anechoic chamber to measure the strength of the signals emitted by phones of different models.

They got to this chart, where we can see huge variation between models (up to 20dB, leading again to a factor of ten in distance).

Testing of different devices emission strength, in a highly consistent setup (same receiver, interference-free room).

The TraceTogether team (and indeed others) are doing these measurements so they can calibrate the devices. Indeed, when sending its beacons, a phone could also send as metadata its emission strength so the receiving phone can figure out accurately the difference. Indeed, this is what the Apple/Google protocol does, at least to some extent (see below).

However, there are two concerns jumping out from this graph:

the strength is not consistent at all, there is huge variability for the same device (will get to this more below);
iPhones tend to emit more strongly. This point might be concerning due to differential impacts that might result from this, as iPhone ownership correlates with many socio-economic indicators.

Receiver sensitivity

Similar variation is expected to be present on the receiving side, and to need similar calibration. We haven’t seen any public data about that side though, at the moment.

RSSI variability

All of the above was based on a fairly static view of the strength of the signal. We implicitly assumed that if we didn’t move the phones or interfered directly with the signal, the strength would be constant. That is however not the case (and I don’t exactly know why, but am assuming this comes from background electromagnetic noise or from imprecise definition of which effects are being considered). We got a hint of this from the Singapore data above, where we could see that even in an anechoic chamber, for the same device, we could see a variation of 10dB.

PACT collaboration

The PACT collaboration recently had a meeting, where Swarun Kumar of Carnegie Mellon made much of the same point as above.

Direct link to Swarun Kumar’s presentation.

Jennifer Watson of the MIT Lincoln Laboratory followed, and explained what could be done. I will just retell her presentation through slides.

In a real life setting, the test subject measures distance to a source with their phones placed in different pockets and orientation. We can see on the right, for each distance, that the signal strength is variable and follows some kind of Gaussian whose mean/mode decreases with distance.

This slide confirms that multiple observations will be needed.

This slide conveys two ideas. On the left, it quantifies the previous one, showing the difference when just one measurement is considered vs 100. On the right, it suggests that additional signals could be used such as screen status (to know whether the phone is in use, in hand), accelerometer data (to maybe know whether the phone is sitting in a pocket), etc.

PEPP-PT collaboration

Finally, the PEPP-PT collaboration has published a few documents on its own progress on the problem of distance inference. These documents are very long, so we will just extract two pictures:

Example data that fed the previous slide. We see that this leveraged different RSSI over time at a fixed distance (red step functions).

Note that the “True Risk Scores” in the PEPP-PT picture above are based on actual estimates of distance, together with a “Diffusion Infectiousness Function”.

Figure 5 in *Proximity Tracing App: Report from the Measurement Campaign 2020–04–09* *by the PEPP-PT collaboration*

The use of this function is justified through the following footnote:

Footnote 2 in the same PEPP-PT paper, referencing a draft out of Oxford titled “Defining an epidemiologically meaningful contact from phone proximity events: uses for digital contact tracing” by Christope Fraser et al.

I have been unable to find the paper this footnote refers to, and contacted the first author.

StopCovid

StopCovid is the name of the French application, which follows a centralized model. Recently, it was announced that CopSonic, a French startup specialized in ultrasonic no-touch payment, would be joining the consortium developing the app.

Interestingly, it is also — at the time of writing this (2020.05.20) — the most transparent of all the initiatives of how it intends to compute a risk score.

Sure enough, that leads to two bugs/concerns:

the calibration of RSSI does not take into account the variety of models;
the diffusion infectiousness function based on RSSI makes little epidemiological sense when re-thought as a function of distance (more precisely: it is very different from PEPP-PT’s, with no discernible argumentation on either side).

NHSx

Recently, the NHSx development team has explicitly stated “We sample very frequently because we think that’s what is necessary to get a sensible view of the risk of a physical contact through a set of models. We may need to sample less, but we need real world data to show that. We do know that ‘I saw a signal this strong in the last few minutes’ is not enough data to make any sort of sensible risk decision about a contact event.”

Apple & Google APIs

It is very hard at the moment to know how Apple & Google intend to let apps infer distance from signal strength. In fact, every indication seems to be that they don’t intend to do that. They seem to want the apps to instead infer transmission risk from signal strength directly.

Caveat: There seem to be changes, between v1.2 (cryptography, Bluetooth) and v1.3.1 (Android) of their protocol that relates to precisely this point. There is certainly divergence between Google and Apple, at least in the documentation available, since Google’s Android API v1.3.1 mentions AttenuationThresholds while iOS’ API doesn’t.

Update (May 23rd 2020): Indeed the caveat above is relevant. iOS API mentions attenuationValue. It looks like I wrote this post at the moment where the system was settled in v1, but the public documentation was not yet fully updated. Since I based my criticism on deep read of the technical system, all the comments still apply.

For the moment, one thing we can productively evaluate is the core of the API already made available. It shows how the risk calculation will be derived. We include a few screenshots below of Android vs iOS.

Android API for configuring the Exposure Risk calculation (taken from Android API v1.2, now superseded by v1.3 which doesn’t include the graphic anymore; v1.3 changes the way attenuationScores are computed)

iOS ENExposureConfiguration (no version number available) Note that there are subtle but significant differences between the two: the range of the parameter values start at 0 or 1, and more crucially the final risk is calculated multiplicatively resp. additively.

Definition of the parameters presented above, in the iOS API. We see that the attenuation is averaged to just one number, that is then passed to the app.

Based on the fact that a simple average is returned instead of the actual sampled signal attenuation values, and all the difficulties outlined above, I infer that the Apple and Google APIs intend only to help apps deduce the infection risk from Bluetooth measurements, and not the distance itself (which could then be fed into epidemiological models). The Apple and Google APIs thus change the definition of the notion of contact for epidemiological purposes.

Inferring infection risk from Bluetooth signal strength instead of distance is not a neutral act. Almost everyone is equal in understanding and assessing a recommendation of social distantiation of 2 meters, and able to discuss the politics of remediation for those who are not capable of following this rule. As a society, we also have much more common cognitive basis for discussing the politics tied to manual contact tracing and the consequences that follow from that process (for instance in carefully balancing false positives and negatives in manual contact tracing).

With Bluetooth-based proximity tracing leveraging the Google and Apple API, we lose that common cognitive basis. Apple and Google get to define the rules, and will progressively get to introduce new data as input (if indeed, like everyone else, they conclude this is a necessity). It also will lead to a substantive shift in what constitutes a false positive and a false negative.

Conclusion

We see that Bluetooth presents enormous challenges for inferring distance.

We see that some collaborations (PEPP-PT, PACT) are focused — at least up until April — on inferring distance, so they can then feed this into their epidemiological models. This might require adding new signals to the mix, ranging from ultrasound to light sensors.

We see that this does not seem to be the case with Apple and Google, at least at the moment. Instead, the Google and Apple APIs amount to a redefinition of the notion of contact for epidemiological purposes. More precisely, Google and Apple enable app developers to build their own evolving definition, but they limit the inputs app developers might use. We have seen above that the current input of just Bluetooth data is likely to be too poor. It is therefore quite possible that the amount of data accessible to apps would be expanded progressively, but Apple and Google would control that. This would add tremendous complexity to updating the consents obtained from users (both sides need to consent!), as well as the Data Protection Impact Assessments conducted by countries deploying those apps.

Additional references

Update (October 19th 2020)

After a while, the EPFL has made some raw data available on how they calibrated the app. You can see for instance the setup that was used to calibrate the app distance in a train.

I want to thank the PersonalData.IO volunteers who have contributed to the writing of this article, mostly through bibliographic work.