Working logic of the BLE implementation

Given the framework above, it is obvious we can base the app on advertising and scanning continuously each other device. And also that we don’t need to establish a connection with other devices (paragraphs 3 and 4 are superfluous). But there is some more implicit functionality we could leverage in smartphones, to make a probability algorithm (calculating the individual risk index) even more precise:

- Distance of people: Every advertisement packet also includes a measure of the intensity of the signal which broadcasted itself. This allows the receiver to infer the distance from the sender device. We tested this feature with a Sony Xperia XZ2 and an iPhone 5: we clearly disambiguated when devices were closer than 4 meters or not;

- Duration of contacts: if the repetition of the advertisement signals is set within 15 seconds, the receiver can reliably infer how long they have been close for;

- Movement vectors: high redundancy of the advertising signals, could even allow to calculate movement vectors. So that a simple algorithm can distinguish between contacts crossing by on a sidewalk, and contacts sitting in a train next to each other. This would add much more precision in calculating the risk index in the smartphones without the need to share data;

- Count of people: whenever too many IDs are detected all together in the same place and time, every smartphone involved can notice its owner without any need to go through a central server;

- Static BLE beacons: a low cost device (e.g. this one), could be sticked in critical public spaces, and advertise itself the same as it was a smartphone, while being added to the logs of people being there. This could essentially help to trace contaminated places, like public transports, elevators, waiting rooms and so on: without this feature, it would be impossible to connect people that attended the place in slightly different hours. Again, without central identity storage and without geographical localization;

- Amount of advertised data: every advertisement packet (PDU), can bring a payload as long as 16 bytes (128 bits).

- Advertising formats: the data packet is precisely defined by the Bluetooth SIG but it includes a customizable payload (the anonymous ID of the citizen). There are some conventional formats for the payload, and two of them are the most famous: “iBeacon” by Apple , and “Eddystone” fostered by Google. Both can carry up to 16 Bytes of data payload (Eddystone in the “UID” flavor). To decide which one to use, if any, we installed some apps from the respective iOS and Android repositories (stores). We discovered that Android devices can send and receive both the formats, but iOS devices can identify Eddystone beacons, without being able to send. And obviously iOS devices can broadcast the iBeacon format. Both the operating systems showed us important limits, to be further discussed.

If you want to reproduce our proof of concept, in your own, these are the apps we used:

- Android, rx/tx, all the formats:
Beacon simulator, by Vincent Hiribarren

- iOS, tx, iBeacon:
iBeaconBroadcaster by Che Yuan Tsao

- iOS, rx, Eddystone:
eBeacon:BLE Scanner by JAALEE Inc.

None of the format is free from frictions, as Eddystone would be ok for Android and iBeacons the only option to send advertisements from iOS.

A balanced (but sub-optimal) solution, could be to have the smartphones sending multiple advertisements, at the same time, in all the formats they can, always including the same information payload. Anyway, iOS would be still unable to read other iBeacon payload without handshaking/connecting (limit to be discussed later).