Multiprotocol BLE/Thread

[Alain]

Hello,

I have read with a lot of interest the documentation associated to the "multiprotocol support" associated to the nRF5 SDK for Thread v0.10.0. As far as I understood, to show the behaviour of the "dynamic multiprotocol (BLE/Thread)" mode, you have an example where you have a board Client MTD which support BLE and Thread. This Client is able to receive BLE requests from a phone and is also able to send a COAP request to a Server. It uses time slicing to support both protocol in parallel.

My question is : a) In this example, does the Server supports also "dual mode" (BLE/Thread) or only Thread ? As far as I understood, in your example, the Server is only running the Thread stack. is it correct ?

b) Can this kind of application be performed also with a Server and supporting BLE and Thread using time slicing as done on the Client part ? If so how can we sure that the server receives the COAP request send by the Client? The first COAP request send by the Client is usually multicast of type Non Confirmable, and so it may happen that when the Client send this request to the Server, if this server is doing BLE activity, it may never receive this request...Is this assumption correct ?

Thanks a lot for your clarifications,

[Jørgen Holmefjord]

I'm not sure I fully understand your question. There are multiple examples of dynamic multiprotocol in the SDK for Thread. Anyone of these examples support both BLE and Thread concurrently, and is capable of maintaining an established connection on both protocols. You can read more about how the multiprotocol support works on this page.

[Alain]

Thanks a lot for your response.

In the example "BLE UART and Thread MTD CoAP Client Example" you need two nRF52840 boards. After reading your doc, it seems that both boards doesn't use the same firmware. The client (board 1) has a firmware which support BLE and Thread while the server (board 2) supports only Thread. Is it correct ? Is it possible to have the same kind of application with the Server supporting concurrently BLE and Thread and not only Thread. Thanks a lot, Best Regards,

[Jørgen Holmefjord]

The second board only needs to be a CoAP server, to test the receiption of data from CoAP Client (running on first board). In theory, any CoAP server example should work, but from the documentation it is mentioned that you can run BLE UART and Thread MTD CoAP Client Example with the following firmwares on second board:

This BLE-Thread dynamic multiprotocol example requires you to run the following example:

• Simple CoAP Server example or/and
• BLE Proximity and Thread CoAP Server Example

BLE Proximity and Thread CoAP Server Example is dynamic multiprotocol example running CoAP server on Thread concurrently with BLE.

Best regards,

Jørgen

[wbober]

Alain,

The assumption you're making in the second part of the question is correct: 15.4 packets will be dropped if the dual mode device is performing BLE activity.

There are, however, some mechanisms in the Thread stack that reduce the impact of such a situation: unicast packets use MAC layer acknowledgments and are retransmitted up to 3 times while multicast packets are disseminated using MPL (RFC 7731) which repeats each packet 3 times.

These mechanisms don't provide full reliability. This means that when you're using CoAP NONs you need to design your application in such a way that it can cope with message loss or introduce some reliability mechanism.

Note that a situation where a packet is lost isn't uncommon for 15.4 LLNs. In this respect the fact that a packet is dropped due to BLE activity doesn't differ that much from a situation where a packet is lost due to collisions or interference on 15.4.

Kind regards, Wojtek

[Krzysztof Loska]

Hi,

An assumption that "any CoAP server example should work" as a complementary side of "BLE UART and Thread MTD CoAP Client Example" is true. Quoted description which is part of nRF5 SDK for Thread documentation is misleading and will be changed.