Design Considerations for the TT Token Algorithm

The TraceTogether Token is a hardware device designed specifically for contact tracing purposes in our fight against COVID-19. It acts as the physical counterpart to the TraceTogether app and forms part of an inclusive effort for everyone to participate in TraceTogether programme.

The TraceTogether Token relies on a Bluetooth Low Energy (BLE) contact tracing protocol called BlueTrace Lite that we developed at GovTech. BLE has been chosen over other wireless communication mediums as it is capable of mid-range transmission and low power consumption.

Since there was little prior work on contact tracing BLE applications for us to refer to, we had to come up with our own design. The idea was for tokens to “see” any nearby tokens and store that information in its internal memory. This way, in the event of a COVID-19 positive case, it would help to facilitate contact tracing as we could tell that these two token holders were in close proximity just by extracting the information from the tokens.

BLE devices have two modes: 1) advertising and 2) scanning. When a BLE device is advertising, it sends out identifying packets to nearby bluetooth-enabled devices. If a device is not advertising, it would not be detectable. When a BLE device is scanning, it is actively listening for these advertisement packets to discover nearby BLE devices.

In order for two tokens to detect each other, one token has to be advertising and the other token has to be scanning. Therefore, we needed an algorithm that maximises the chance of tokens detecting each other, and this is done by balancing the time each token spends advertising and scanning.

Another important consideration for the design of the token was that the battery had to last a few months. For the TraceTogether Token to be fully effective, it had to be running 24/7. In addition, the token had to be small and light enough to be carried around easily. This meant the battery itself had to be small, yet carry enough power for the desired duration.

Finally the token had to be secure against potential attacks, and these additional security requirements required more processing time and power. The challenge was to achieve a fine balance between time spent sleeping, advertising, and scanning to preserve battery life and maximise detection rate.

All these requirements were in tension. Ideally, you would want a protocol that gives you the best detection rate, but this would mean a higher proportion of the time is spent scanning. However, scanning has a far higher current consumption than advertising and the longer you spend scanning, the shorter the battery life. You could solve this by increasing the battery capacity, but that meant a heavier device, which makes it less desirable as a small portable token.

To further illustrate, consider the following situation where there are two tokens in close proximity:

Imagine that both tokens are broadcasting at a ratio of 1:1:1 between broadcasting, scanning, sleeping. If they are slightly offset from each other, there is a small overlap where token B will “see” token A.

However, note that token A does not see token B because when it is scanning, it never overlaps with the advertising interval of token B (token B is always sleeping in this example). So, if there was a sleep mode, it would significantly reduce detection rates.

If we replaced sleep mode with an extended advertising duration, we would see the following result:

When the scanning duration of A overlaps with the advertising interval of B, A will be able to see B and vice versa.

However if both tokens are synchronised in their advertising intervals, both tokens will not be able to see each other at all! This is quite rare, but there is still a chance that it may happen.

To account for this, an element of randomness is added where instead of scanning during the scan-advertise cycle, a token will instead remain in advertising mode. This accounts for tokens whose cycles are completely synchronised.

The high volume of varying time combinations and the duration of each test required to test the viability of each timing interval made determining the best ratio a particularly challenging process, especially since we were hard pressed for time to produce the tokens.

Ultimately, we settled on a regular cycle of advertising and scanning with a randomised element which helped to improve token exchanges. We also experimented with various scan and advertising intervals and found that shorter intervals improved token exchanges. For more details about the implementation of BlueTrace Lite, please see the whitepaper under the reference section.

Moving forward, I personally think it would be great to have a rechargeable battery design incorporated that could address sustainability concerns. This would undoubtedly introduce added complexities to the design and there would need to be additional considerations for the overall robustness of the design and eventual deployment.

~ Zi Qi

Related posts:

Among all the bad advice out there, one article stands out in my memory. It was an article in The Chronicle telling grad students how to be more responsible with their money. There was one problem…

Are you an entrepreneur who began your personal business the previous couple of years? Then you’re a part of a large group of tens of millions of small business homeowners in the US. Document numbers…

If your architecture is based on microservices it’s a really good idea to buy a domain in Route 53 and make the connections with API gateway so that you can enjoy URL’s like: In this quick tutorial…