Developing Bluetooth Mesh networks with Rust
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61801 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2023478 / 542
2
5
10
14
15
16
22
24
27
29
31
36
43
48
56
63
74
78
83
87
89
95
96
99
104
106
107
117
119
121
122
125
126
128
130
132
134
135
136
141
143
146
148
152
155
157
159
161
165
166
168
170
173
176
180
181
185
191
194
196
197
198
199
206
207
209
210
211
212
216
219
220
227
228
229
231
232
233
236
250
252
256
258
260
263
264
267
271
273
275
276
278
282
286
292
293
298
299
300
302
312
316
321
322
324
339
341
342
343
344
351
352
354
355
356
357
359
369
370
372
373
376
378
379
380
382
383
387
390
394
395
401
405
406
410
411
413
415
416
421
426
430
437
438
440
441
443
444
445
446
448
449
450
451
458
464
468
472
475
476
479
481
493
494
498
499
502
509
513
516
517
520
522
524
525
531
534
535
537
538
541
00:00
Vermaschtes NetzElectric currentVertex (graph theory)Data modelLatent class modelMaizeEndliche ModelltheorieStack (abstract data type)Computer networkServer (computing)Message passingClient (computing)Virtual realityLocal GroupTopologyAddress spaceComplex (psychology)Element (mathematics)Computer hardwareRange (statistics)Extension (kinesiology)Food energyPersonal digital assistantPairwise comparisonGateway (telecommunications)Cloud computingBuildingData managementOpen sourceEmbedded systemMereologyComputer architectureLevel (video gaming)Endliche ModelltheorieComputing platformBitVermaschtes NetzCASE <Informatik>Message passingSoftwareArithmetic meanKey (cryptography)Network topologyServer (computing)Cartesian coordinate systemClient (computing)Thread (computing)Computer configurationProcess (computing)Range (statistics)Stack (abstract data type)Address spaceProduct (business)Element (mathematics)Pairwise comparisonSpacetimePower (physics)Computer hardwareMoment (mathematics)Analytic continuationFood energyMicrocontrollerGroup actionDenial-of-service attackPointer (computer programming)Data managementLink (knot theory)HierarchyDifferent (Kate Ryan album)Connected spaceMultiplicationCloud computingUnicastingverfahrenOpen source
08:13
Communications protocolVermaschtes NetzDemonElectric currentMotion blurData storage deviceData managementComputer networkGateway (telecommunications)Cloud computingBuildingPhysical systemIdeal (ethics)Computer programmingRun time (program lifecycle phase)Read-only memoryEmbedded systemFormal languageLocal GroupFlash memoryResource allocationComponent-based software engineeringComputer hardwareScheduling (computing)AbstractionBinary space partitioningWhiteboardFirmwareTelecommunicationFood energyMemory managementSoftwareSystem programmingVermaschtes NetzEndliche ModelltheorieCartesian coordinate systemCuboidAbstractionProjective planeAddress spaceComputer hardwareSpacetimeOrder (biology)Proper mapMultiplication signTerm (mathematics)FirmwareDemonGroup actionRegular graphLatent heatStack (abstract data type)Port scannerDifferent (Kate Ryan album)Library (computing)State of matterArithmetic meanState diagramMessage passingPhysical systemCASE <Informatik>Goodness of fitMicrocontrollerTelecommunicationComputer programmingMereologyInterface (computing)Task (computing)Integrated development environmentInternet der DingeRepresentation (politics)Formal languageClient (computing)Scheduling (computing)Cloud computingSoftware developerComputing platformProgrammer (hardware)Run time (program lifecycle phase)Pointer (computer programming)
16:20
Logic gateCommunications protocolInterface (computing)Food energyVermaschtes NetzRun time (program lifecycle phase)ArchitectureTask (computing)Service (economics)Connectivity (graph theory)ScalabilityFirmwareCloud computingOpcodeDegree (graph theory)Analog-to-digital converterComputer wormEmbedded systemData managementInternet der DingeService (economics)DemonGateway (telecommunications)Cartesian coordinate systemVermaschtes NetzRange (statistics)Computer simulationCodeCloud computingCASE <Informatik>Twin primeRun time (program lifecycle phase)Data managementComputer architectureVolume (thermodynamics)Configuration spaceWindows RegistryMessage passingData storage deviceState of matterServer (computing)Computer wormRevision controlData conversionSimilarity (geometry)Shift operatorAreaProcess (computing)Single-precision floating-point formatMoment (mathematics)Computer-generated imageryPerspective (visual)Physical systemMetric systemMereologyJava appletBitFirmwarePlanningCommunications protocolGroup actionProjective planeTelecommunicationGreatest elementNetwork socketWeb 2.0
24:27
Program flowchart
Transcript: English(auto-generated)
00:06
Hey everyone, thanks for coming and yeah today I would like to talk a little bit about the Bluetooth mesh and what we did in the Rust ecosystem to basically support it both on the embedded and on the Linux side and
00:22
it's a good continuation on the topic that we had in a previous session because it's a little bit comparable and there's a lot of material, so basically what I will, and a little time, 20 minutes, so what I will basically give you today is a lot of teasers and a lot of pointers and I hope
00:42
you know you'll get interested and could follow the links to further investigate things. So let's get started with what the Bluetooth mesh is. Bluetooth mesh is based on the BLE, so Bluetooth Low Energy Technology,
01:04
but it's designed to create a mesh network or devices on top of it, meaning that you should be able to connect nodes or devices directly in dynamic hierarchies basically. What's different between the
01:29
Bluetooth mesh and the thread for example is that Bluetooth mesh doesn't use any routing, it's based on the managed flooding principle meaning that
01:40
the device will try to publish messages to all the devices in the range and those devices will then figure out what to do next with those messages that have been received and it supports published subscribe model as we will see in a minute. So this is how it basically looks like
02:05
and it's a similar what Stefan showed us with the thread, so we have regular nodes that can send and receive messages, we have relay nodes which are only there to extend the range of the network, so they are just relaying
02:23
things that they are receiving and in a similar fashion as thread we can have a low power nodes that are mostly sleeping and are not active and which are accompanied by the friend nodes which will buffer messages
02:42
addressed over these low power nodes. The stack looks something like this, so as I said like we have a Bluetooth low energy as a basic layer, there's a networking layer that's responsible for creating
03:03
networks and exchanging keys and all that kind of things and then we have an application layer which is completely defined in the Bluetooth mesh meaning that all our models are predefined and we can use it as we
03:20
will see now. So as I said the models are defined, so for example all the things that are talking like sensors or on-off switches are defined as a model on the application level on the
03:44
mesh and we can have a client and the server models meaning that the client and the server will exchange the messages and communicate like that. So how does it work then is that each device, each node
04:05
can have multiple elements and those elements can have a multiple client or server models between them and each element has its own unicast address that can be used to address an element
04:24
within the device. We can also create more complex hierarchies by defining a group of addresses and defining the virtual addresses which provides us with a way to create more complex topologies
04:42
and to have like a full power of publish subscribe architectures on the mesh level and every device is part of the particular network and the particular application within that network meaning that all the messages
05:02
that are exchanged between the devices are double encrypted with the network and the application key. To onboard device onto the network we need to go through something like a provisioning process meaning that
05:20
we need to have a special node that will behave like a provisioner of the network and that node will be responsible for creating and managing the keys, setting the addresses and things like that. So what are
05:41
the use cases on top of the Bluetooth low energy? We can have an extended range and more flexible topologies but we can also have existing hardware that so this is just another application on existing Bluetooth low
06:04
energy hardware that can be applied but with more with more flexible technologies and providing an option to connect larger number of devices. So I don't want to go too deep into this because it's probably a session of
06:24
its own we heard a lot about thread here but this is just a small comparison between the all the competing technologies in the space and their respective solutions in all the different layers. So when we
06:50
started playing with this we had one goal in mind and that is to create like a full stack meaning that we can create application based on the
07:02
product mesh that will cover the full stacks going from the embedded microcontrollers to the Linux and having support for these applications in the cloud and try to do all that in Rust. We will talk about that a bit more in a moment and the idea was to create a platform
07:27
that could be easy to build these applications both on the devices and on the cloud side but also provide a way to ease the management of the
07:40
Bluetooth mesh networks. But before we dive into what we did in Rust, let's go a little bit through the current state and on the embedded side the Zephyr is the only thing that I found in the open
08:04
source that had support for the Bluetooth mesh. Of course all the vendors had their own support as the case that can be used out of the box. On the Linux side everything related to the Bluetooth is basically
08:21
under the BlueZ project and the BlueZ defines the DBaaS APIs for communicating with the Bluetooth daemon on the different kind of things and of course they have the mesh API as well for the DBaaS and it's used to send messages between the Bluetooth daemon and the
08:45
applications that want to talk a Bluetooth mesh on the Linux side. The daemon is different so if you want to use the mesh on the Linux box you need to install the different package and basically disable and stop
09:04
the regular Bluetooth daemon and enable the specific Bluetooth mesh daemon. There's also a provisioner tool included which is
09:22
called the mesh CFG client and it's an interactive tool that allows us to do all the provisioning things so create new networks, scan for the unprovisioned devices, add those devices to the network and create addresses for their models. One of the downsides of this tool is that it's too interactive so
09:46
it's not that easily scriptable and it's making it hard to create reproducible networks and environments that you want to do. The final state is then how do we
10:05
create these applications on the Linux side that will do this and there's even less examples of that on the network. All that I could find when I started
10:21
looking into it was some of the Python examples done in the Bluetooth white papers and basically those are just simple Python applications that use the C++ interface to basically communicate with the mesh daemon over it. So coming from
10:47
this kind of state you could see the end goal that we tried to do is to try to see how far can we go with this stack and try to re-implement most of
11:01
these things in Rust. And now the question is why Rust, of course, and we found it a very good solution for system programming so it basically allows us to create it's statically compiled and strongly typed
11:21
which means that it has a strong performance safe programs without introducing runtimes and VMs.
11:43
Again, very suitable for system programming for this kind of applications. And finally, it's a fairly modern language with a lot of good tooling so people coming from other areas, for example, I don't consider myself an embedded programmer
12:03
but I feel much more comfortable playing with Rust for these use cases than I would be if I would try to do the same thing in the C. So first thing we did is to create a BT mesh crate
12:22
and that's a basic crate that we tried to do is to implement all the traits that are needed for implementing the Bluetooth mesh specification. So as you remember all the layers of the Bluetooth mesh so everything needed for
12:44
representing the application models or the networking layer traits should be defined in this one crate and as you can you will see we will be able to reuse that in all different layers of the stack. But in order to be able to
13:06
reuse it in the embedded space that this crate needs to be a no std meaning that it shouldn't rely on a standard library. And this is a kind of
13:24
a go-to example to show how the sensor data representation could look like in a defined by the BT mesh crate.
13:41
So Rust embedded, I think it's growing so how many people here are using Rust today for embedded programming? Let's go. So what's the goal here? There's a Rust embedded working group that are dedicated for to this task and its goal is to enable people to run
14:06
firmwares using Rust. Firmwares targeted to the microcontrollers with the small RAM and ROM capabilities without operating system and without
14:22
memory allocator. As I said like we have only 20 minutes and there's a lot of things. So I'm just giving you the pointers. There's a lot more to be said about embedded Rust but we don't have that much time. And the next thing, the next cool thing as I said doing
14:42
embedded with Rust is that it enables you to do quite a lot of programming things even for the firmware. So there's a project called Embassy which allows us to use basically async programming for the firmwares. It provides a scheduler and the hardware abstractions that we can use to
15:03
build quite capable asynchronous applications in Rust and it has a hardware support for all the major hardware platforms today. On top of that, the project that we are involved in is building on top of the Embassy
15:22
and trying to add more IoT things on top of the basic embedded development. So communication with the cloud in in terms of MQTT or HTTP, trying to support use cases like Bluetooth mesh and try to create a more advanced applications like OTA firmware
15:45
updates. And you can see here one of the examples from the workshop that we did that I'll mention later on is for example how we can use the btmesh create on the firmware to basically every
16:04
time we read the sensor data we can package that sensor data in the proper sensor Bluetooth mesh message and send it over the Bluetooth. Then on the Linux side there's a project called Blur which is part of the BlueZ Linux
16:26
official group which tries to implement all the Linux Bluetooth protocol stack in Rust and at the moment it provides support for all the major features of the Bluetooth
16:40
like get or Bluetooth love energy. So what we try to do here is to provide a support for the Bluetooth mesh in a similar way as the rest of the Blur works. So again a nice thing about Rust is
17:01
that you can use a lot of crates and existing technologies that are there for different use cases. So for example a Blur uses a Tokio runtime, a very frequently used runtime for building all kind of server applications in Rust and communicates with the mesh daemon over the
17:24
using the DBAS crate. The good thing is and that was the part of the plan is to use the btmesh crate here as well to use for the mesh traits that we would need it. So this is the quick architecture of how things work on the Linux so
17:45
I hope you can see it well. So you have a mesh daemon which communicates directly with the devices. It has its own state in the mesh config and the mesh storage volumes and it communicates with
18:02
using the system DBAS to random applications being the gateway application or some device simulator on the Linux as well. But the good thing is that you can see here is that
18:21
and this is one of the things that I personally like a lot about using Rust for these use cases is that this code running on Linux looks pretty much similar like the code running on the firmware. So here we are receiving the Bluetooth message, we are parsing it, we are creating a JSON out of it and sending
18:41
it over the MQTT to the cloud. But you know it's very easy for a single person to jump back and forth over the different stack layers and using the similar creates and a similar style code then it would be if we go from the
19:03
writing a C for the firmware and then a Python code for the for the gateway and then doing something in Java in the cloud for example. So the mesh support is not officially landed in Blur and this is all my fault and due to my laziness and other priorities but hopefully this PR
19:24
will be merged in the in the coming weeks let's say. The final part of the project that we have been building is to build a kind of IoT friendly cloud platform again done in Rust.
19:41
Here we try to provide all the services that your typical IoT application is needing so being able to do a lot of connectivity, having a capable device registry and being able to integrate further into the cloud applications and using digital twinning and
20:00
all these kind of things on the other side. But again I'm coming back to the same thing so there's a thing called payload converter in the cloud that can actually intercept our messages coming from the gateways and if you can remember in the previous example we already
20:22
parse the Bluetooth messages and send them as a JSON but if your gateway is sending just the raw bytes you can do that thing on the cloud again with the same crates and with a very similar code so we will parse the bytes,
20:41
get the message, do some JSON processing and forward that message deeper into the cloud. So we were playing with this for a while and then there was a chance to actually try to put this all
21:01
into the work at the EclipseCon. We had a hackathon and a workshop where we tried to do something to cover the whole area with the Bluetooth mesh network, provide the micro bits for the people to play around with and provide some basic applications in
21:21
the cloud that will talk to each other. But the basic big architecture looks like this so we have a public sandbox for our draw cloud consisting of Kafka and all this kind of stuff and we wrote the gateway based on the bluer.
21:40
We provided some examples of how to use micro bits with the Rust embedded draw device and the embassy and provided a couple of applications that will talk with the cloud using the web socket in the background. So just a quick recap how this architecture looks
22:04
on the firmware. So you have a couple of layers, the embassy and the Bluetooth radio on the bottom. Then we have a draw device and the BT mesh support next on and on top of that we can write our own
22:22
application that will do things with these messages. On the gateway side we implemented the gateway using the bluer and we also tried to use some of the
22:40
latest edge technologies to deploy and manage those gateways so trying to use a micro shift which is the red case version of the single node Kubernetes cluster paired with the open cluster management to deploy these gateways to appropriate nodes. And I must say to my surprise it all worked pretty well.
23:05
So we had like four or five gateways based on the Intel Nux and some Raspberry Pis. Those Raspberry Pis didn't run the Kubernetes, we used the basic Podman and the Docker images to run the gateways and that provides a very good
23:21
coverage of a very large space. What we needed to do is to provide a couple of relay nodes as you can see on this other picture is to just to basically extend the range over some longer corridors that were there. But everything worked pretty good from this perspective.
23:48
So that's all what I have to cover today. So as I said there's a lot of teasers, we didn't get into anything too much deeply, but these are the communities.
24:01
So hit us on the on the Drogue IoT metrics channel, that's where we all hang and are happy to talk about these things. If you're interested in embassy I would suggest to take a look at that and the bluer thing hopefully with the official BT image support very soon. Thanks.