• State Not Answered
  • Replies 6 replies
  • Subscribers 73 subscribers
  • Views 4337 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 123466
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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,

Parents
  • 0

    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

Reply
  • 0

    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

Children
Related
Terms of service