Xamarin is the Best Choice for Bluetooth Mesh Networks

Bluetooth Low Energy (BLE) is what you are using to pair your phone to the awesome little Xamarin Bluetooth speaker that we all picked up at a Xamarin conference. 😉 Your phone can connect to the speaker, your car and your Fitbit, but the Fitbit and the car can’t communicate to one another via your phone. All of these connections are 1:1 between your phone and another BLE enabled device. 

BLE has a point-to-point (1:1 or piconet) network structure. The range of a BLE 5.0 radio is roughly about 240m or 800ft and BLE 4.2 radio range is 60m or 200ft. Beyond this range, BLE paired devices lose their connection.  

Bluetooth Mesh builds upon BLE, with a handful of high-level features. 

• Many-to-many network structure – you read that right – devices (nodes) are talking to one another, relaying messages.  
• Mesh networks can grow much larger than the range of the BLE radio connection because messages are relayed between nodes. 
• Devices (nodes) in the mesh play different roles. Low-Power (battery) nodes can rely upon wired Friend nodes to save and relay messages to conserve battery.  
• Robust security is required, not optional. 

So, how does the phone fit in?  

Mesh networks are created, assembled and configured using a Configuration Client. A Configuration Client can be any BLE enabled device, like a phone or a tablet.  

• Creation – In most cases, a mobile app will create the mesh network and the security keys required to protect it. 
• Assembly – Adding devices to the mesh network is called Provisioning. This is done by scanning for devices that are advertising that they support the BLE Mesh protocols. 
• Configuration – Grouping, configuring and customizing the way the devices in the mesh work together is also done in the mobile app by sending messages through the mesh, to specific devices or to groups of devices. 

The original focus of BLE Mesh technology was for lighting and sensors, but the spec supports all kinds of things. You can imagine a network of lights in a huge warehouse. The building is much larger than the range of a BLE radio, but if the lights can be grouped and relay messages to one another via a mesh network. To go one step further, mesh enabled motion sensors can be used to turn groups of lights on and off, as needed. 

To be perfectly honest, my brain has been overflowing with the cool ways that BLE Mesh sensors, both battery powered and wired, can be used in a mesh, even without lights. Imagine a network of solar powered motion sensors used for security systems on fences or light-harvesting sensors embedded in store shelves, alerting staff that products need to be replenished.

Or perhaps you want to monitor the heart-rate of all of the runners in a marithon. Those runners all are each wearing a BLE Mesh device (node) that collects their heart-rate and broadcasts it to the mesh network. Each runner’s device relays the messages and they reach Configuration Clients (phones) along the route who have subscribed to the messages on the mesh. The runners can be very far apart, but the messages are relayed through the mesh. If one runner’s heart rate reaches a dangerous threashold, that information can be relayed and collected, and someone can be alerted to the problem. Only want heart rate data to flow to a specific group of Configuration Clients? That can be done by dividing the mesh into subnets, or even smaller groups inside subnets. Remember, security is required, not optional.

The BLE Mesh Specification documentation also has a huge amount of information on Mesh Models, which define the way in which different devices communicate different types of information. There are a huge number of models relating to lighting and some for sensors. Device vendors can even create their own Vendor Models, but if you want to be able to mix and match devices in your mesh network, your devices should all support models that are described in this SIG specification.  

Why is Xamarin the best choice for BLE Mesh networks?  

Much of the spec requirements do not require the mobile device to do anything platform specific. Platform specific code is really only required for scanning and provisioning in that the BLE Radio is required.  The BLE Mesh security requirements can be built with the help of BouncyCastle in C#, in shared code!   

Another huge advantage is that the topology and settings of the mesh can be stored and transferred from one phone to another more easily when the objects are exactly the same between the two operating systems. This is easier if the data models storing the mesh topology are all stored in C#. Not to mention, this code is written ONCE, not TWICE!

How do I learn more?  

Read the Bluetooth Mesh Specification Documents (Might want to brew a pot of coffee… lots to read here!)

Any example code out there?

There aren’t any Xamarin plugins as of yet, but Nordic Semiconductor has open-sourced the code base for their native mesh apps.  

Nordic Semiconductor iOS BLE Mesh App on GitHub

Nordic Semiconductor Android BLE Mesh App on GitHub

How do I find bluetooth mesh devices?

There are a fair number of BLE Mesh light bulbs out there… but they are NOT all created equally! The best choice for playing around with the mesh yourself is the Sylvania Smart+ line of light bulbs. These bulbs advertise the mesh provisioning UUID and they follow the mesh spec pretty closely. Hopefully, I will get some time in the near future to detail my findings with the pile of mesh bulbs I have now collected!

If you are looking for boards that you can program yourself…

Nordic Semiconductor

Silicon Labs

I am frankly super-excited to see how this technology develops over the next few years! Happy coding!