Together We Can

The Technical Approach

Introduction

With the exponential growth of the number of patients who are diagnosed with COVID-19, many countries including Sri Lanka have taken the approach to lockdown cities and all the public places enabling social distancing in the highest form possible. Identifying the infected patients and other potentially infected patients has become a tedious task mainly because of the complex process of interviews and its lack of authenticity.

In order to simplify and overcome this situation, Arimac in collaboration with the Government is presenting a solution where the tracking and identification of all traces of the infected and its close contacts, is merely an input through a smartphone application.

How does it work?

The mobile app uses Bluetooth to broadcast its status around the owner of the device. When that device is in close proximity with another person who has the same app installed will be detected and that data will be stored securely. If any of the users are detected as COVID-19 positive, the data captured from all the devices will be analyzed to identify the people who were in contact with the infected person. The application will reach its highest benefit when the entire society uses the app collaboratively.

One of the easiest ways to track a user’s close contact is to use the GPS and location tracking embedded into all the devices. This creates a major privacy issue as people would be having second thoughts to provide their movement information to the government. However, using the Bluetooth based tracking method does not collect user location information, but any potential close contact with another person.

Our solution uses Bluetooth Low Energy (BLE) technology which is embedded in most of the widely available smartphone devices. According to Statista [1], there are over 8.45 billion devices in the world in 2020 which is BLE enabled. Being able to provide communication through a considerably reduced power consumption and cost while maintaining a good communication range, BLE makes a suitable approach for the tracing implementation.

Managing user privacy as the priority

Being encouraged by the Sri Lankan government and an application intended to be in a large number of devices, the system is easily likely to be a destination for privacy theft. Therefore, one of the major challenges we face is how the whole tracking process is managed in a secure manner. This can be explained by providing the flow of the application as follows.

A user downloads the app and opens up, and is prompted to enter the mobile number at his/her consent.

Mobile number (MSISDN) is one of the quickest methods of contacting a user in a state of urgency and the authentication process will utilize it, making the registration and login process easier. The mobile number used in the authentication will be stored in a cloud infrastructure as a hash for the verification process and as an encrypted value to be decrypted for the analysis process. The user will be provided with a JWT token to be used for further authorized processes.

User is verified by an OTP sent to the provided mobile number

Once the user is registered, the following permissions and activations are requested

Turn on Bluetooth — for the whole tracking process

Enable notifications — to notify the user for any urgencies

With the necessary permissions provided by the user, the tracking of devices will be enabled. The process includes two components, the emitting device, and the receiving device. A single device will act as both an emitter and a receiver. The emitter component of the app will always emit its data through secure Bluetooth packets. The process is as follows for the emitter,

1. The app will request a public key from the server, which will be unique to the user
2. Hash unique user identifiable information with the public key and securely store within the app
3. The emitter will broadcast a unique Bluetooth UUID which can only be tracked by another device with the same app installed.
4. Once a receiving device is met and verified as a legit user, stored information of the emitter will be transferred as an anonymous ID.
5. The emitter will continue its emission until the next receiver connects.
6. The public key will cycle with time and the data packets that are emitted by a single user will change within a provided time frame.

The receiving component of the app has three main sessions. Scanning, data retrieval, and data storing. The receiver components process is as follows,

1. Initiate a scanning session to identify similar Bluetooth UUIDs, this ID can only be captured by a similar application. The scanned UUIDs are validated against the server to determine integrity.
2. Scanning sessions will be stopped and the receiver will connect to each emitter component and request its anonymous unique data. This connection will be done without a pairing request. As the messages passed through this Bluetooth channel are hashed with a cycling public key, ID spoofing is restricted.
3. The data retrieval session will go through each newly identified scan and collect information accordingly.
4. Once all raw data is captured, it will be sent to the cloud-hosted service through secure HTTP communication.

The following diagram shows the sessions managed by the application in a given timeframe.

The mobile app also contains additional features, mainly being a status update of each personnel. The user is asked to update his/her health status for the data analysts to be on alert.

The Back-end, data collection and analysis

Being encouraged by the government authorities, the app is targeted to be installed in a large number of smartphones within the country. Being a continuous data communication application, it is expected to generate a considerably large load to the back end servers running. The app is also prone to generate millions of records in short periods of time. In order to overcome these challenges, we are using Microsoft Azure managed services coupled together to work efficiently and rigorously to provide the optimum performance. Following is the distribution of all the services,

1. The services are decoupled into two major sections, the back-end services and the analytical services.
2. Back-end services manage user authentication, data verification and encryption, data retrieval and all other processing tasks. All the private keys and hashing keys used for encryption and hashing are securely stored in a key vault. These services also utilize Azure SQL managed services to store anonymous user data. An Azure Cosmos DB instance will be available to store processed analytical data, which will be retrieved by the administrators and analysts.
3. All the service calls are passed through the Azure front door to assure the best performance and high availability. The collected data is directly passed through the API manager to the Analytics services. It uses the Event hub to stream the data passed and processed into a data lake as Avro files. These files will be processed by Databrix for analysis.
4. The services are hosted as containers and are managed by a Kubernetes cluster. We utilize Gitlab for our code repositories and the deployment will be managed through continuous integration and continuous deployment.
5. Alternative services added to the resource group are Azure Monitor for containers/VMs which features application insights. This reduces the load on our DevOps personnel of manual monitoring processes. These services are used to monitor the performance and failures of the services running.

Data retrieval process

The next process of the system is the retrieval of data in an informative format. Event-hub will be passing out large encrypted datasets to the data lake and to Databricks. Retrieval and processing of this large dataset and providing the processed information will be a time-consuming process. Therefore, the process of data retrieval is decoupled into several processes.

1. Data request will be passed by the administrator, requesting close contacts for a given MSISDN (Mobile Number of the infected person)
2. The provided number will be matched with a hashed value for the verification process and the request is sent to the Databricks instance.
3. Since the retrieval process is time-consuming, a response is sent back to the Administrator to wait and recheck until the process is completed.
4. Once the data is fetched through the data bricks instance, a finished response will be sent to the application microservice to continue with the process.
5. Fetched data will be stored in the Cosmos DB, and the process status will be set to complete.
6. The next request from the Administrator will be passed to the services to check the status of the data fetch. If the fetch is completed, the stored data in the cosmos DB will be decrypted and sent to the administrator panel.
7. Administrators will get a list of mobile numbers of who was in close contact with the infected person. This data will be manually realized and determined for future potential infected people.

Conclusions and Optimizations

The data which is being processed will be matched with a threshold time that an infected person was in contact with another. However, the range of Bluetooth can go up to 100 meters which might generate larger noise (people who are further away will have the chance to be tracked). Therefore, measuring the approximate distance between the two devices is paramount. The data that is emitted as packets to the receiving device also contains all other metadata as well including the signal strength (RSSI) and measured power.

The distance approximation can be done by measuring the amount of power reduced in the transmission, added with a depreciation factor due to external interference [2]. The interference factor can also be reduced by implementing a software low pass filter to clear out the noises and fluctuations in the environment. [3]

Distance = 10 ^ ([Measured Power-RSSI]/[N * 10])

N is a constant that can depend on the environment factor and data can be retrieved for different conditions by changing the value of N.

As the number of COVID-19 cases increases exponentially, it is the citizen’s responsibility to proactively engage in social distancing practices and be vigilant of the surroundings. Together We Can, the tracing app will be an added tool for the government authorities to perform their tasks more effectively. It is our duty to use these tools and be a helping hand to their operations.

Check out all our offerings to assist the government and corporates to fight against this pandemic; https://www.arimaclanka.com/covid-19

References

1. https://www.statista.com/statistics/750569/worldwide-bluetooth-low-energy-device-market-volume/
2. https://iotandelectronics.wordpress.com/2016/10/07/how-to-calculate-distance-from-the-rssi-value-of-the-ble-beacon/
3. Jung, Joon-young, Dong-Oh Kang and Changseok Bae. “Distance Estimation of Smart Device using Bluetooth.” ICSNC 2013 (2013).