How to protect against overlapping signals?

[sslHello]

Which type of modulation, encoding and protocol makes sense to protect against or cope with overlapping signals? Radio Amateurs have developped types of modulation that use different tones on the same frequency to get more data transmissions on the same channel, e.g. FT8.

[lbarman]

Hi @sslHello; thanks for the question. In this case for interoperability I think we are stuck with the standard Bluetooth implementation (which uses GFSK).

Would this answer the question ?

[pzboyz]

https://github.com/DP-3T/documents/issues/170

[sslHello]

Hi @lbarman; I am sorry, I couldn't make it to answer earlier. Give me some time to answer, please. And let me know if you prefer to reopen this issue or if I should transfer it to #170? And I am sorry I don't know the standard features of bluetooth, but perhaps the following suggestions could help to solve some issues with crowded places and a lot of app users beeing close together.

1) Modulation: Thanks for the answer which modulation you use. Good news: Those modulation types as FT8, FT4 use GFSK, e.g. see FT4_Protocol. And yes, they do have a slower use case about speed, as they do have different aims there. On the other hand they have developed a very robust solution to use a frequency channel more effectively: "as many as 50 stations can operate in a 3 or 4 kHz passband with little interference, even when signal strengths differ by as much as 60 dB." This might get lower with higher speed, on the other hand you don't need to read signals below noise level. This should give you a margin for higher speed :-) Spreading the (tone) frequencies on the same passband helps to get a lot more parallel operable connections. Perhaps it could also help to reduce the risk of collisions between the same smart phones using different tone frequencys by the transmission/short session.

2) Timing: Another point may be timely collisions. Is it possible to define fixed timeslots where sender sends (x)or receives? As far as I can remember this is a lot better than using startegy like ethernet used a log time ago with the 'yellow cable'. They have used a random time to wait when they had detected a collision (Carrier-sense multiple access with collision detection (CSMA/CD). The protocols above use the exact time also to decode extreamly weak signals.

3) Encoding The encoding should include a forward error correction to be able to even read signals with fading or interferences. There should be an integrety check to only accept 100% recovered signals.

Radio Amateurs (=non profit) use these protocols for free.

[lbarman]

Hi @sslHello, no worries! Thanks for the message.

Actually my follow-up question concerns you 3 points: aren't these all fixed in Bluetooth / in the Bluetooth implementation / API provided to smartphone's app ? I don't even think the OS has control over these things as they are part of the Bluetooth chip.

So you're suggesting to not use phones/Bluetooth and you propose to investigate an alternative communication channel for contact tracing?

[pzboyz]

I have not thought how best yet to reply to this one, there is not a simple or quick reply to address every single issue raised by @sslHello . The requirements of a radio system used by Radio Amateurs (which is not a good name as often they understand the RF principles very well) is very different to the short range and low power requirements of BLE.

Another major consideration is there is no support for FT4 or FT8 in the phones, it can take a few years to agree on an IEEE or BT standard radio, then another 12 months for semiconductor support and another 18 months for it be designed into a phone. Then another 4 years until that becomes well established as older devices are replaced by new ones. Can we wait 6 years for a reliable contact tracing system to be viable?

Oh there is also a feature of BLE called Periodic Advertising, that has not been talked about at all for contact tracing. I have not got my brain around deciding if that helps at all. As I said in #170 when devices are close by, the radio rejects the weaker signals.

We have to use the radio schemes available and in active use today.

[sslHello]

Hi @lbarman @pzboyz, I see your concerns. I do not kow the Bluetooth libraries and if there are program interfaces (APIs) available where you can directly generate GFSK signals. If this is available, this can be an enhancement to stability and to solve issues with a lot of transceivers that should transfer data but interfering each other. So you had no need to wait for new standards nor to use a different communication channel. You could enhance the use of Bluetooth by defining and using an individual communication scheme to use the given bandwidth of a channel for more than one connection. I am a Radio Amateur and I have used FT8/FT4 myself on short wave. And yes it wouldn't fit 1:1, but from an abstract point of view it does not make a big difference if interferences come from phones that are very close on Bluetooth or radios that are very strong on short wave frequencies. So it might be a possibility to use a technique that has solved a similar issue and wich is tested under a harder environment than Bluetooth ;-) If this is interesting to you we could try to reach out the developers of this protocol if they could imagine to help...

[sslHello]

Additional to this are there any plans/strategy for the timing when the beacons are going to send, how long they listen. See nr 2) from yesterdays posting

[lbarman]

Thanks for your inputs.

I do not kow the Bluetooth libraries and if there are interfaces available where you can directly generate GFSK signals. If this is available, this can be an enhancement to stability and to solve issues with a lot of transceivers that should transfer data but interfering each other. So you had no need to wait for new standards nor to use a different communication channel. You could enhance the use of Bluetooth by defining and using an individual communication scheme to use the given bandwidth of a channel for more than one connection.

I don't think there is on current smartphones, we are stuck with the current implementation of Bluetooth. Our dev team will focus on Bluetooth for the first version.

So...

If this is interesting to you we could try to reach out the developers of this protocol if they could imagine to help...

I think it's great if we can get better technologies, but this sounds more like an extension / new concept than something we will focus on right now.

Additional to this are there any plans/strategy for the timing when the beacons are going to send, how long they listen.

I think this is being fixed in the reference implementations, I'd redirect you there for a first check.