Loomio
Thu 28 May 2020 9:12AM

What data should be collected for BLE proximity?

ALS Adam Leon Smith Public Seen by 19

I commented on the audit q's but moving the discussion to here.

ALS

Adam Leon Smith Thu 28 May 2020 9:16AM

I suggested that the strength of the signal should NOT be collected. Here's why... The Bluetooth type which is relevant here is Bluetooth Low Energy (LE). LE has a range of over
1km on newer devices. See https://www.bluetooth.com/learn-about-bluetooth/bluetooth-technology/range/

But this is not what's important in the context of a contact tracing application. We are interested in detecting smartphones which are much closer and in estimating their distance.


The general approach to this type of application is to alternate between adverting (broadcasting) "I am here" messages with a unique ID of some sort in them and scanning (listening for broadcast messages (from other devices). When receiving a message, you can use the RSSI (Received Signal Strength Indication) to estimate the distance of the receiving device from the transmitting device. This works best when the transmitted signal contains a reference power value, typically something like the power of the signal in dBm measured at distance of
say zero metres from the transmitter. Then you can perform a path loss calculation using the RSSI to estimate distance.

RSSI values will fluctuate, even in seemingly stable conditions, so it's common to include some data smoothing in the algorithm (e.g. low pass filter, moving averages etc).

Environmental conditions will affect signal strength and therefore distance estimates. Environments with lots of barriers (e.g. pillars) and in fact people (they contain water) are obvious examples. Also be aware that the "LE" aspect of Bluetooth LE indicates that this is the power efficient version of Bluetooth. But an application that drives Bluetooth scanning and transmission hard, will use more battery than one which takes a more measured approach.

So it might be wise to evaluate the application's efficiency as well as its functionality. Whether or not battery life is impacted to an extent that users notice it, will be entirely down to how the
application has been written.

So in summary, it's not RSSI that should be collected, but estimated distance. However perhaps additional data should be collected to help assess accuracy.

RC

Ryan Carrier Thu 28 May 2020 2:05PM

Awesome point Adam - let's get more specific in the audit and differentiate the signals, asking about all and then we will be able to highlight in the audit specifically, "best practice" and NOT best practice.

AM

Aaron Maxwell Thu 28 May 2020 8:22PM

There's also the technical aspect of what the radiative moments are in BT devices. I'm reaching back far into my radiation courses in university, but the design of the transmitter and receiver go a lot into dictating how which direction has the most power. So you'd need to smooth over the burst mode, and then also apply a longer analysis for the signal in between bursts. That suggests a passive approach using the LE-mode to differentiate between the various features in the 2D (time, distance) space that might arise.

RE

Ryan Eagan Wed 3 Jun 2020 1:21PM

Stumbled across this article a while ago that brings up the issues with BT signals and contact tracing software: https://www.technologyreview.com/2020/04/22/1000353/bluetooth-contact-tracing-needs-bigger-better-data/

RC

Ryan Carrier Wed 3 Jun 2020 2:04PM

Added that to the resource spreadsheet and I personally believe Bluetooth is the best we have now, but not without its faults

RE

Ryan Eagan Wed 3 Jun 2020 3:02PM

Agreed - BT provides a much more privacy by design approach to this problem than does rampant sharing and abuse of GPS data.