The COVID-19 pandemic has affected every aspect of our lives, both as developers and human beings. With the increasing need to contain the virus, many developers and IT companies have tried to support the development of effective exposure-notification systems (also known as ENS).
Given the wide adoption of Bluetooth technology, it is no surprise that such technology has been immediately recognised as the most appropriate tool to use in achieving this goal.
This article focuses on Bluetooth features, providing an overview of several key issues (and how they have been addressed) in the implementation of reliable exposure notification systems, including distance estimation, privacy, and mobile OS support.
How Exposure Notification Systems Work
Before going into more detail, what follows is a general overview of how exposure notification systems work. The first point to note is that ENS systems use the power-efficient and more versatile of the available Bluetooth technologies, Bluetooth Low Energy (LE), which supports two fundamentally different wireless communication modes.
Connection-based VS Connectionless communication
The first method that can be used to enable information exchange takes the form of a connection-based communication. In this case, two devices connect point-to-point, building a reliable link between each other.
If the two devices are paired, this link can also allow a secure connection through encryption, which is crucial if the context demands high privacy standards. However, there are a couple of limitations to such an approach:
- Limited scalability: in the context of ENS, we can’t limit our scope to a single pair of devices. Increasing the numbers here means that each device needs to connect to all the others, which might become too demanding in terms of power and computational resources to be acceptable. Moreover, the connection itself requires a period of time that is not negligible, which becomes significant if the number of devices increases.
- Bluetooth implementation: most smartphones currently on the market limit the number of concurrent connections to 3 or 4 devices at most. Although this is neither a Bluetooth constraint nor a technological limitation, it remains an inescapable fact. Designing reliable ENS requires consideration of where the state of the art is at.
The alternative to connection-based communication is a connectionless approach. In this case, communication is based on broadcasting the information from one device to many, avoiding point-to-point connection (and the related overheads). This approach is much more scalable and allows high privacy standards to be maintained. However, this mechanism has several drawbacks:
- It is fully asynchronous, and consequently, there is no agreed timing between the broadcasting device and the receiver(s)
- No acknowledgement is made of packets received, which means that the broadcaster device cannot know if a receiving device has actually received the packets sent
- Standard Bluetooth specifications for broadcast do not define the use of encryption
Since the connectionless approach allows for high scalability, it is not surprising that ENSs make use of the idea.
ENS Basics
ENS communication is based on broadcasting two basic pieces of information:
- a unique ID that is used to identify the broadcasting device
- a TX power reference, representing the transmission power used by the device to send the packets
Every time a device receives such information, it computes a received signal strength indicator (RSSI), which is used in conjunction with the TX power reference to estimate the distance between the two devices. Indeed, the RSSI (although often noisy) is inversely proportional to the square of the distance from the transmitter.
With this in mind, let’s now delve into how an ENS works. Every device broadcasts its unique ID and TX power reference (a process also known as beaconing) and scans other devices’ information, sent using the same system.
When a device picks up such a message, it computes the RSSI, and thus the distance from the other device, in the most reliable way possible. If the distance is below a certain threshold, the broadcaster ID can be stored (for a limited time frame) to reference nearby devices.
If a person tests positive for COVID-19, the information stored on their device allows the other devices it has encountered in recent days to be notified about the risk of exposure.
Main issues in ENS development
Although this whole process might appear quite straightforward in principle, there remain several issues that need to be solved to develop a reliable ENS.
Distance estimation and accuracy
The first problem is the distance estimation. In the previous graph, we see a function that is not particularly complex to invert. However, the reality is different, and noise has a big impact on the estimation of RSSI. To give you an idea of noise impact in this area, take a look at the following graph, showing RSSI measurements from two stationary devices at a distance of 1.5 meters:
This result is due to many unpredictable factors (such as other physical objects, signal reflections, humidity etc.), and dealing with an issue of this kind demands some trade-offs.
For instance, instead of having finely-detailed information about distance, it might be easier (and more useful) to gather qualitative data with greater precision: knowing if the devices are within 2 meters of each other might be enough for this situation, and this is achieveable even in such noisy conditions.
In addition to the issue of noise, another factor that might complicate the distance estimation is the precision of the TX power reference sent by the broadcasting device. Sending an imprecise value could have a significant impact on distance estimation.
If you think about the tens of thousands of smartphone models in use around the world, each of which has its own precision issues, it is easy to understand the importance of using calibration data for each make and model.
Privacy
One of the most controversial issues raised by users when discussing ENS is privacy. ENS designers need to ensure that devices (and their users) cannot be tracked by exploiting the regular broadcasting of identifying information that occurs when a unique ID is transmitted from one device to another.
An unchanging device ID, together with a regular pattern of broadcasting, might remove the user’s anonymity. It is crucial to avoid such an issue becoming an opportunity for attackers.
Advertising and Scanning parameters
When looking at implementation details in depth, it is important to notice how many of the actions performed by a device need parameters. Setting such parameters usually requires a developer to look for several trade-offs.
For instance, ENS designers need to define a scan window, representing how long a device should scan for other broadcasters, as well as a scanning interval, i.e., how often a device should scan.
While long scan windows and high scan intervals allow nearby devices to be recognised more effectively, such parameters may impact power consumption, which can be another significant issue for mobile devices.
Centralised VS Decentralised Architecture
Considering ENS more generally, another controversial choice is the architecture it uses. There are two options here for ENS designers:
- Centralised architecture: implementing this concept requires all devices to share a list of the identifiers they have observed with a centralised system, which stores a record of every device encounter experienced by each device. Users inform the server if they test positive for COVID-19 or have symptoms. At this point, the central server makes all the required decisions about which users to inform about a possible exposure.
- Decentralised architecture: in this paradigm, a central server is informed when a user declares that they have COVID-19 (or symptoms), but the server has no data about encounters with other devices. All decisions about exposure notifications occur on local user devices, and this data is not shared with the central server.
Both choices have pros and cons in terms of privacy and effectiveness. Opting for a centralised architecture allows for better automation of notification management from the central system, which must adopt strict strategies to protect data and avoid the risk of device tracing in the case of an unexpected data breach.
On the other hand, decentralised architectures solve the root of the problem by storing only minimal information in a central system (users are required to declare their affected status).
OS support and APIs
A final issue, and a big one, is the limitations on the use of Bluetooth technology imposed by mobile operating systems. Application developers are usually able to utilise Bluetooth LE by using the Android or iOS APIs.
However, not all Bluetooth capabilities are actually made available by OS APIs. For instance, some OS versions may suspend Bluetooth activities, such as scanning for nearby devices or broadcasting information, when the application is switched into background mode to save battery power.
These limitations underline that implementing reliable and effective ENS is not solely the responsibility of the application developers. Stronger support from OS producers is required, along the lines of what Google and Apple have done to develop their ENS framework.
The ENS framework by Apple and Google
Many of the above issues (including the limitations imposed by OS constraints) have already been solved, thanks to the joint work of the two major mobile OS producers, Apple and Google. To help governments implement effective exposure notification systems, they defined a framework (also known as the Google/Apple Exposure Notification system, or GAEN) to offer consistency across smartphone makes and models.
This framework allows such systems to benefit from all the underlying features provided by Bluetooth LE, courtesy of a privileged code that can implement this on behalf of application developers.
The GAEN is designed to exploit a decentralised architecture, where there is no central database that stores encounter between devices. This choice represents a significant privacy benefit.
It is worth highlighting that Apple and Google built a framework supporting application development, but not the application itself (although reference implementations have been released as open-source material).
Moreover, this framework has not been made available to the general public, but is intended to be used by government-level institutions, such as public health authorities. These institutions can develop applications that exploit the framework’s features and processes the data collected and stored by each device.
In his talk “Bluetooth® Technology and the Response to the Covid-19 Pandemic”, Martin Woolley, Senior Developer Relations Manager of Bluetooth SIG, will describe how Google and Apple actually implemented this framework.
Martin will explain how this system works in terms of architecture design and how privacy and distance estimation issues have been solved. If you are interested, don’t miss the opportunity to attend his talk – registration closes in a few days, so make sure you book your seat.
Conclusions
Designing an effective and reliable ENS is not easy. It’s a process that requires compromises and strategic decisions in terms of architectural design.
The basics of ENS may appear relatively straightforward, and Bluetooth SIG is constantly working to improve standards and define newer versions (including one aimed at defining the role of wearable devices for exposure notification purposes).
However, the limitations introduced by OS vendors, along with the security and power-related requirements of users, makes the design process of any ENS a much more complex task than one might expect at first sight.
One of the most promising solutions involves exploiting the framework developed by Google and Apple to solve issues such as privacy and distance estimation. If you want to know more about such frameworks, don’t miss the opportunity to attend the Tech Speech “Bluetooth® Technology and the Response to the Covid-19 Pandemic” at the DevCast event on the 25th of May.