Nordic Connect Thread - CoAP vs. UDP for short range connectivity

[Farhang]

Hello peer developers,

This is a general question and dilemma I am dealing with and I wanted to get your opinion.

I am working on a project to implement a short range radio Mesh network of "things" within a few hundred meters with the nRF52840 and an FEM (+20dBm). Currently internet connectivity is not in the scope of the project.

Thread in NCS sounds promising, specially if we can have BLE coexistence as well.

These devices don't fit the "client" and "server" model very well. as they can be both initiator of a request or on the receiving end of a request. So in a way each node is equally both a client as well as as server. e.g. in the lightswitch and light bulb example, imagine they are combined into one, i.e. a bulb that has a switch on it, and when pressed turns all other lights nearby. Any switch can turn all bulbs on or off.

Therefore I am concluding CoAP is an overkill and it may not be the best approach. Is that a true statement? Or can I have both client and server in one node (1 nRF chip), without complicating the firmware.

The other approach is to go down a level and implement connectivity based on UDP, from what i understand this gets rid of the server/client roles. Under openthread samples of NCS there is no "sample" (example) for this. Any suggestions where to start? CLI?

Since I am new to both NCS and OpenThread protocol any advice would be appreciated.

Also is BLE mesh a better solution possibly?
Messages are small - sub 40 Bytes. Reducing latency is a priority.

Thanks in advance!

[Edvin]

Hello,

Just some pointers:

 

Thread in NCS sounds promising, specially if we can have BLE coexistence as well.

 Right now, Thread in NCS is in a developer state, and not production. It is fairly new, and does not yet support BLE coexistence.

 

These devices don't fit the "client" and "server" model very well. as they can be both initiator of a request or on the receiving end of a request. So in a way each node is equally both a client as well as as server. e.g. in the lightswitch and light bulb example, imagine they are combined into one, i.e. a bulb that has a switch on it, and when pressed turns all other lights nearby. Any switch can turn all bulbs on or off.

 In that case, we even have a demo (running on the nRF52 Thingy (nRF52832) that uses Bluetooth Mesh for this. In Bluetooth Mesh it is fairly easy to set up virtual channels that the devices will listen to. A node can both subscribe to and publish on a virtual channel. Please check out the youtube video linked to in this readme file:

https://github.com/NordicPlayground/thingy52-mesh-provisioning-demo

Best regards,

Edvin

[Achim Kraus]

"Therefore I am concluding CoAP is an overkill and it may not be the best approach. Is that a true statement? Or can I have both client and server in one node (1 nRF chip), without complicating the firmware."

CoAP uses the same message format for requests and responses. The difference is the value of the code byte, class-0 for request, class-2, class-4, and class-5 for responses. Therefore it works brilliant to run a coap-client and a coap-server on the same device, you may even use the same socket/port. For DTLS it's different, but there it's more the question on starting the communcitation than on exchange messages afterwards.