In a previous post we explained how the Received Signal Strength Indication (RSSI) can be used to infer distance. Contract tracing apps provided by governments and workplace social distancing solutions use the RSSI to detect close contact. This post explores some factors that affect how well such systems work.
With Bluetooth LE the sender repeatedly sends out a small amount of data, called advertising, that takes of the order of 1ms to send. The repeat time, called the advertising period, is typically every 100 milliseconds to 10 seconds depending on the application.
A 1ms transmission uses a lot of battery power so there’s a tradeoff between the advertising period and battery life.
The receiver listens, called scanning, for Bluetooth advertising. Again this is battery intensive so scanning devices typically only do so for a few seconds. If they need to listen for a long time then there’s a gap of a few seconds between successive scans.
It can be seen that because the sender isn’t always sending and the receiver isn’t always listening the two might not align to cause detection. The advertising period, the scanning time and the time between scans all combine to cause a tradeoff between battery life and the responsiveness of the detection. In extreme cases detection can take a very long time or not at all.
Applying this to iOS and Android, the mobile OS manufacturers have exercised some control over what’s possible with apps so as to protect battery life. iOS is the strictest and doesn’t allow apps to advertise unless they are in the foreground and shown on the screen. There is a trick to cause advertising to wake up an iOS app to advertise for a very short time. However, it leads to poor triggering performance and can affect battery life.
Android is more capable and up until recent versions of Android, apps could advertise and scan in foreground and background. More recently, Google has restricted background activity such that Bluetooth is only advertised for a short time after the app has closed. There’s an even larger limitation on Android in that some manufacturers kill apps that work in background.
All this isn’t good for contact tracing apps. As previously mentioned , Google and Apple have implemented a new API to allow contact tracing apps to work well on iOS and Android. Some Governments, such as ours in the UK, have currently gone their own way with apps that use existing APIs. Such aforementioned restrictions stop smartphones seeing each other thus severely reducing their effectiveness. The apps won’t work properly and will provide very limited benefit. It has even been suggested the system might even be dangerous as it might be provide a false sense of security. There is a report that early trials of the UK tracing app and privacy concerns have caused the UK government to re-think their approach and are investing in research into a second Google/Apple centric app in case there’s a need to quickly change direction.
For our workplace social distancing solution we avoided use of apps for close-contact advertising and scanning. Instead we use smartband-like devices so that we are in full control of how and when the devices advertise and scan.
While wearable beacons only usually advertise, our custom firmware in social distancing wristbands performs both advertising and scanning so that devices can mutually detect one another. The heavy battery use means we still have to make a compromise between the responsiveness of triggering and battery use but at least it’s under our control rather than dictated by Google and Apple.