Bluz DK and Mesh Networking


#1

A little background and history: mesh networking is actually not part of the Bluetooth 4.1 protocol (nor is it in 4.2). Because it is not part of the protocol, but people still want it, different vendors and suppliers have come up with their own implementations. Nordic Semiconductor has done this for the nRF58122, on which bluz is based.

Some Nordic engineers have actually gone as far as hooking up a Spark Core to the mesh network to control is from the cloud, you can read about it here: https://devzone.nordicsemi.com/blogs/672/accessing-the-ble-mesh-via-the-spark-cloud/.

This is a great first step for us, but we have a few goals we want to add:

  • In the mesh, each node should still have it’s own unique access to the Spark cloud (own ID, own credentials, etc). This will still allow each node to get FW updates from the cloud or be controlled vis a REST API
  • In the mesh, each node can still talk to eachother.

Once we hit the stretch goal, we are going to merge the mesh code into the bluz code and start to modify thing to work with the above goals. We will post any updates and progress on this thread. We will also try and open up the repository at that time so people interested can start to follow along.


#2

What will be the inter-node communication API be ?

How will the address spaces overlap/interact ?

I assume that from the REST API perspective each node will have a spark device id, but what is the address space for the intra-mesh communication.

I can see that we could use the REST API to map between the two, if required.


#3

Still working on those details. Yes, each node will have a Spark ID for the cloud and REST API. The current Nordic Mesh implementation has its own addressing scheme, so we will need to see if we can merge the two or they must stay separate


#4

Ack. If I go browse around the nordic site, will I find details of their intra-mesh API ?

I assume you’re using the nordic API to communicate back to the gateway, so the nordic addressing is always going to be part of the mix, and the spark device id for each mesh node is actually the synthetic value, right ?


#5

Yes, you can see details about their mesh API here: https://github.com/NordicSemiconductor/nRF51-ble-bcast-mesh/

One note, it is not officially part of the Nordic SDK, it is a separate item, but the Nordic engineers are some of the people working with it.

To send values out to the mesh, they simply write to GATT characteristics. So we will provide a wrapper around all of this and make it easy from an API perspective. Same with the addressing. I don’t have all the details right now, but we will post updates and status here as we go.


#6

thanks for this discussion thread. even the thread is old I think the addressed topic is still actual. for me the availability of a standardized mesh protocoll based on an open standard is essential and crucial for bluetooth based IoT growth.

I watched the [interview with Erret Kroeter, VP at the Bluetooth SIG] (http://iotdesign.embedded-computing.com/articles/bluetooths-third-trick-mesh-networking-for-iot/). He mentions, that the BT SIG will roll out a new mesh networking standard as part of BLE (“riding on BLE”) by 2nd half of 2016.

My questions: Will Bluz adopt this new mesh networking standard and will this standard be supported in tutorials? If yes this would be a compelling reason for me to jump on Bluz.


#7

This depends on what Nordic decides to support. If they include it with he nrf51, then we could support it at some point in the future.

If they don’t, or it moves to the nrf52, their new chipset, then we couldn’t (until we add support for the nrf52 :wink:)


#8

I ‘hear’ from your answer that Nordic did not give you a committed roadmap about supporting a unified bluetooth mesh protocol, what surprises me. Anyway, your answer is clear, thanks.