Concurent mode

[Di Piazza Alain]

Hi

Is it possible to imagine a system in which the radio bandwidth is split between Thread (802.15.4) and BLE on a device using a single radio ?
Are there some examples/documents which explain the feasibility of how to mix BLE and Thread together.

Thanks in advance

Best Regards,

[Jonathan Hui]

As you probably know, there are a number of SoCs that support (or will support) both Thread/802.15.4 and BLE with a single radio.  The capabilities of those SoCs vary, but generally it is possible to have both Thread and BLE sharing access to a single radio.  How well the system performs largely depends on your use cases, which drive the amount of radio resources each protocol stack requires.  A number of silicon partners that provide 802.15.4/BLE combo SoCs are working on demonstrating how to run both OpenThread and BLE stacks on the same radio in their SDKs.  You might try contacting silicon vendors directly for more information.

--
Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-users+unsubscribe@googlegroups.com.
To post to this group, send email to openthread-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/f1af821c-1b3d-4911-8ca2-ae265fe2bf13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Di Piazza Alain]

Hi Jonathan.

Yes, I agree with you that on the web, several companies claim to support 'concurrent mode', but is it real 'concurrent mode' with both stack running in parallel and sharing the same radio or just a kind of 'dual mode', meaning that time to time, the system switch from BLE to Thread and vice versa...On our device, we have ported a BLE stack and OpenThread. Both run properly independently, and now we are studying if if it possible to run these two stacks in //.
Thanks

[Jonathan Hui]

As I mentioned in my previous note, the capabilities of the 802.15.4/BLE combo SoCs vary between different vendors.  For example, there are SoCs that include two completely independent radios, allowing for true concurrent operations between both Thread and BLE stacks.  For other SoCs, the share the same physical radio and the Thread/BLE stacks must time slice their usage for both receive and transmit.  Other SoCs offer something some capabilities in between.

--

Jonathan Hui

--

You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-users+unsubscribe@googlegroups.com.
To post to this group, send email to openthread-users@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/fe402422-240d-4571-a266-25350242268e%40googlegroups.com.

[Jonathan Beri]

Hi Alain,

Can you share any more information about your device? Is it one of the known supported platforms or something else?

[Di Piazza Alain]

 

Hi

On a system which support BLE and Thread with a single radio, we can imagine at first a dual mode. In dual mode, we start for instance a communication on the BLE network, and then we switch to Thread. Once all the Thread requests has been performed, we can switch back to BLE.

a) Do you have real use case which ask for such a functionality ? 

When we stop BLE and start initiating a Thread network, it will take some time.
b) What is the minimum time required to setup a Thread network ?
Note : If you stop your BLE network, and you just need to power on a device located inside your Thread network, the reaction time may be considered too long if you need to setup the Thread network from scratch...

c) Are there examples on which time to time, Thread take over and interrupt BLE activity, just to keep the Thread network alive. Is it possible for example to have the “thread leader device” just sending Advertisement time to time to other devices (in order to keep the link with Thread network), and in between entering in a kind of ‘thread sleep mode’ where it is possible to perform BLE activity.

Thanks very much for your answers.

[Jonathan Hui]

On Mon, Mar 13, 2017 at 2:15 AM, Di Piazza Alain <dipiaz...@gmail.com> wrote:

On a system which support BLE and Thread with a single radio, we can imagine at first a dual mode. In dual mode, we start for instance a communication on the BLE network, and then we switch to Thread. Once all the Thread requests has been performed, we can switch back to BLE.

a) Do you have real use case which ask for such a functionality ? 

Many product developers desire to support both Thread and BLE, but what exactly that means is application-dependent.  Recent "combo" SoCs that can support both 802.15.4 and BLE are attractive.  As I mentioned in my previous note, the capabilities of the 802.15.4/BLE combo SoCs vary between different vendors.

When we stop BLE and start initiating a Thread network, it will take some time.
b) What is the minimum time required to setup a Thread network ?
Note : If you stop your BLE network, and you just need to power on a device located inside your Thread network, the reaction time may be considered too long if you need to setup the Thread network from scratch...

The time it takes to form a Thread network from scratch largely depends on the number of nodes you have and the network diameter (in terms of hops).  Each node needs to go through the attach process, which has O(N) complexity, where N is the number of nodes.  For each hop, a device needs to attach, become a router, and neighboring devices need to discover the presence of the new router, which has O(D) complexity, where D is the number of hops.

That all said, the most dependent factor is the discovery rate for end-devices, which is largely configured by the application, to satisfy power constraints.  Practical applications will probably back off the discovery process to minutes or even hours when a device is not attached to a network.

c) Are there examples on which time to time, Thread take over and interrupt BLE activity, just to keep the Thread network alive. Is it possible for example to have the “thread leader device” just sending Advertisement time to time to other devices (in order to keep the link with Thread network), and in between entering in a kind of ‘thread sleep mode’ where it is possible to perform BLE activity.

Thread routers (including the leader) are required to keep their receiver enabled except when transmitting packets.  The primary issue is that neighboring devices may choose to transmit at any time and routers need to be ready to receive those packets.  At the same time, Thread can afford the radio to disable its receiver for brief periods of time.  If a transmission occurs while the receiver is off, Thread will treat that just like any other dropped packet.  Because dropped packets are common in wireless networks, Thread provides resilience to that.  However, disabling the receiver for long periods of time can result in neighboring devices to declare the link as down.  In short, the Thread radio is occasionally disabled for tens of milliseconds, Thread should be able to handle that.  However, disabling the Thread radio for seconds would not be recommended.

--

Jonathan Hui

[Krzysztof Loska]

Hi Alain,

Recently Nordic Semiconductor released Thread/Bluetooth Low Energy dynamic multiprotocol solution which allows for concurrent operation of Thread and Bluetooth Low Energy utilizing OpenThread and SoftDevice (Nordic's Bluetooth Low Energy stack). For more details see this blog post. Even more information on multiprotocol can be found as part of nRF5 SDK for Thread ver.0.10.0 documentation.

Best regards,

Krzysztof Loska