Introducing Bluetooth Mesh
CC Attribution 3.0 Unported:
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.
Holtmann, Marcel
Bluetooth technology has been extended with a brand new mesh feature. This presentation gives an introduction to Bluetooth Mesh and its impacts on the ecosystem. It shows the new and exciting use cases that a mesh enabled Bluetooth low energy enables. The presentation will also put a focus on Linux and Zephyr operating systems and its integration with Bluetooth Mesh.
 Welcome everybody, good morning. After a little bit of technical differences I think we have this pretty much working. So my name is Marcel Holtmann and I'm going to give you an introduction into what we have released a couple of months ago which is a brand new Bluetooth standard. So before I go any further, as usual, since I work for Intel blah blah blah, this claim is. So Linux is the most stored trademark, Zephyr is the Linux foundation trademark and Bluetooth is the Bluetooth sync trademark. Everything else are trademarks as well if I forgot to actually mark them correctly. Quick one about myself, so I've been doing the Linux Bluetooth stack since 2004 which is already an awful long time. In the meantime I created Conman, a connection manager, Ophona, cellular stack, pack runner for handling proxy setups, L embedded Linux library and also IWD which you can actually hear about tomorrow if you care about what we have done in the last year on that one. I joined into in 2007 so it's pretty much 10 years right at Intel so far. I share the internet working group so we're trying to actually get more IP networks over Bluetooth and integrate it more properly. I'm sitting on the architecture review board as well so I'm spending a lot of boring time on reviews, specs and standards and I've contributed massively to the mesh standard that I'm going to introduce you today. It has been something around three years right to actually get even the standard out the door including getting some implementations of it around as well. So why actually redoing everything and all over again? So pretty much this weird hype term of Internet of Things drives a lot of innovation. Fundamentally breaks down is that we want to actually connect everything and you're not going to connect anything with cables so we need to start picking the wireless standard we want to use and there's so multitudes of wireless standards around for any kind of embedded device or Internet of Things standards. The really only problem is that which ones you're going to pick and if you pick one you can't do the other one, if you pick this one it's maybe not in the phone, your phone is with you on a daily basis and so on and so forth. So when we set out around three years ago to actually do Bluetooth Smashers like look we want to actually get something that is in the phone so either do Wi-Fi or you do Bluetooth or you do cellular 5G for example but the lowest power one is Bluetooth so we actually focus on let's get Bluetooth going instead of trying to make 15.4 better and get it integrated into the phones or use Lora or any kind of light based standard etc. And obviously the choice is pretty obvious since everything is better with Bluetooth anyway so we picked on trying to do the next generation of Bluetooth. Before we actually introduced Bluetooth Smash Bluetooth was rather boring technology. It was point to point and had it's around since before 2000 so it's a really old standard so we are I think we're approaching next 20 years of Bluetooth. But if you see the left hand side you see Bluetooth Classic which is pretty much used for in-car communication, headsets and so on and so forth. And then about seven years ago they actually set out and said look we're actually going to have to do something for low power devices. We have to use the power footprint on this one and the memory footprint to actually make them run on a coin cell battery for a year or even longer. And that's what's called Bluetooth Low Energy or Bluetooth Smart and so back in the days the sick came up with some weird terminology like we have Bluetooth Classic, we have Bluetooth Smart, we have Smart Ready and Smart Ready just means you have the dual mode devices combined that can talk to both side. But classic devices can't talk to low energy devices you always need one in the middle that can actually pose. So until about beginning of this year that was a standard how we had it, point to point dual mode devices, your phone was a dual mode device, your headset was a single mode for classic and your heart rate monitor was a single mode for low energy. That got completely turned around and made a lot more complicated beginning of the year. So they keep classic around, it stays point to point but for low energy we actually introduced multiple extra things. You can still do point to point, read your sensor data from your heart rate monitor etc. But you can also do massive broadcasting because we have all this beacon market where you have your location positioning and so on and so forth. So you can basically broadcast your location or any information like URLs, Eddy Stone, iBeacon etc. And then on top of that one now you had mesh, you can actually span mesh topologies and actually do something for this for lighting or something else. It gets a lot more complicated and I go through this in a little bit detail but fundamentally on the left side classic is what it is. There's no innovation happening on classic or the innovation happens in low energy. You will still use classic if you use a Bluetooth headset for a really long time. My prediction is at least the next 8 to 10 years but every new development will happen on Bluetooth LE. The thing is when you actually have a point to point technology and one extent is with mesh, you can't do this just by saying I'm going to build a mesh technology and that I'm done with it. You need a lot more. So even if you're a network layer is mesh capable that doesn't mean you can't do anything without. You need to actually lay us on top that actually know how to do certain things. When we set out to do Bluetooth mesh the fundamental problem was if we actually have to broadcast data the maximum PDU size is 31 octets. You have to subtract two octets for actually get the basic information. I've pre-pended on this once you're left with 29 octets to do a secure mesh capable network. So that's quite a challenge and that's what actually led to this whole stack that we actually had to do on these multiple levels. So the bearer is pretty much where you have the minimum of 29 octets. The alternate bearer is if you're actually in a connection or if your connection less then you have your network layer that will define your basic PDU formats and I have a diagram of this one later so don't worry I'll show you this one as well. But it does addressing how you address one node in a network, how you do encryption, decryption and especially also make sure that everything is authenticated and secure. So Bluetooth mesh in specific there's no unsecure network. The network is always encrypted and authenticated. We can't actually do any unsecure networks. And we separate in network encryption from application encryption because that's two independent things. You have because you're operating 29 octets we had to do a segmentation and reassembly layer and then we had to have a level that actually encrypts the application messages and authenticates them. We need to define how you do the data formats because if you only have 29 octets and you want to tell a lamb to go on you don't want to spend over three messages because then they keep waiting for these messages to arrive. So you want to keep them as short as possible so you also need to play a little trickery with the message formats. Then you need to configure this whole network because if you don't know how to build your network configure and use it it's pretty much uses then you just have a network and can't do anything with this one and then you want to have actually do lighting models on this one or power models or something else. So actually you can switch on something off you can switch something off or you can get sensor data like your HVAC is at this time at this operational mode etc. What is really important mesh is not a new radio. We didn't build a new radio. We didn't build a new Mac layer. We just built a network topology. So we actually have Bluetooth or energy as the basic radio around it and then the topology on how you actually turn that one into mesh network is what we have defined. And if we recap this we get to the level that we actually have the old classic pairing side of things where you have one device and otherwise so pretty much point to point. Mesh can use this as well for backwards compatibility. So if you have a device that doesn't know how to do broadcasting or doesn't know how to do mesh you can use a point to point connection as a single entry hop into the network and say look I will bridge you into this network if you can't do anything else which is great. So you can take your current phone that you have, install an application and you can get access to a mesh network. But fundamentally if you want to build the mesh you need to broadcast the packets because we can't do any point to point connections anymore and actually building start topology or mesh topology based on point to point connections is really complicated because you spend a lot of time actually managing this one and you actually need a lot of memory. So assume we want to run this on coin cell batteries and we need to manage 100 or 1000 nodes. You don't have the memory capacity in your controller to actually do these. So we are broadcasting every packet out which means we actually use the advertising feature of Bluetooth for energy to just send a packet and whoever is in vicinity will receive that packet. And based on that one then you finally enter the level where you actually get a mesh topology where you actually say all these devices have the same keys and the same network and they can successfully talk to each other and we can actually have addresses assigned to any of these nodes. I will get back to this one how the topologies build in a slide or two but this is just the basic idea. I grabbed a stack diagram from Nordic to just show you how they actually this is fundamentally different than what we have done before. So on the middle side you see the good old Bluetooth low energy stack. You have a link layer, you have a security manager, you have add, you have get, you have gap and that's pretty much how everything runs today. Nordic always has some extra specifics around but this is good for demonstration purposes on how they actually had to integrate this because you fundamentally have to do the same if you want to build this. So on the left side you have a Bluetooth mesh stack that pretty much circumvents everything because it only actually needs to talk to your radio and actually put your packets on the air and receive the packets from the air because it builds the packets in a specific format. Well the format is still the low level format of Bluetooth LE but it doesn't really say that you have to go to the link layer, you just have to format them correctly. And there's a lot of extra timing involved with this one so you don't repeat packets too often because the more you put the packet on the air the more power you consume, the more power you consume on your receiver side. But the interesting one that they forgot to mention on this one is that we also have the legacy entry point, we have a point to point connection. So the Bluetooth mesh stack on the left side fundamentally also have to put this on the middle side where you actually have a gut or connection oriented channel and stack this on top of this on for legacy purposes. So it gets shrink-wrapped in multiple ways. But it's good for demonstration purposes that you pretty much have two things side by side. Before I show you the topology slide we actually ended up with four different features. You can call them roles but they can also happen, you can have multiple features on the same node so the roles don't really match because it's more like an OR feature than an XOR. So you have a low power feature. If you actually build a mesh topology and want to run on a co-insult battery you need to consider the devices that really only have a co-insult battery and then say look I want to be only on air when I need to be because every time you have to turn your receiver on you consume so much power that you actually can't stay on your battery for long. So you have these devices that really have a tiny battery and they pretty much say I'm on now, someone needs to help me to get my data. So that's what's called LPNs or low power nodes and they always have to talk to someone else. They have pretty much edge nodes and then go say look I'm setting up a friend of mine and I'm waiting for them to forward me the messages in case I'm offline and miss them. And the friend is just the opposite role where they actually have to always on power and they're happy to give other low power nodes the packages. And a friend can talk to multiple low power nodes but a low power node generally only have a single friend. And then we have a mesh network so messages need to be read because we want to span the extra width of the network so if you want to cover whole building, 10 meter range of a Bluetooth radio is not going to cut it so you need to have multiple of them and they have to relay the messages one to another one and go through this. The proxy one is what I mentioned earlier for backwards compatibility. If you want to have a phone bridged into your network that is not mesh capable, it needs to do this over a gut connections for Bluetooth and this is pretty much the proxy does okay I'm along you and you can actually send the message and then I will relay everything back to you. If you draw this up you get a pretty much easy to apology feature of this one where you have fans, ceiling fans, light bulbs and switches etc. What is generally considered is that the light bulbs and ceiling fans are always powered so they can easily relay messages, they can easily be friends and so on and so forth. Then you have proxies like a phone that will talk to a proxy capable light bulbs and they can then know the phone can talk to them and then say I want a part of your network. But you already see that the proxy is a little bit often outside because it doesn't do anything else. It talks to one specific friend and the friend then has to bridge everything so you can't have a different path into the network. Once you choose your proxy you are going through that proxy and don't say I'm just sending the message to everybody and hopefully someone is going to pick it up so you have to find a dedicated proxy. Friendship is pretty much the similar concept you find a single friend and then you go through that one through the network. But all the other nodes, the route from the switch on the right to the light bulb on the left, there's no specific route it goes. It can go to the top, go through another switch, it can go to a ceiling fan and so on and so forth. So we really rely on that the messages are relayed through the whole network and everybody can see them. And coming to this point, the relaying in Bluetooth matches is actually kept on purpose simple because the more complex you make it and you have routing in there you actually need memory and that memory you don't have and if you need a lot of memory you need to consume also more power so it gets really tricky. So pretty much if you decided I'm having enough power I will relay messages then you actually do and retransmit these messages as needed. You can do maximum of 127 hops and generally that's a pretty large area if you consider if you're range between 10 and 100 meters on a Bluetooth radio. We do flooding so it's a flooding based mesh network so every message you get gets back to everybody else so you're basically flooding everything out. It is considered what's called a managed flood. In general you retransmit the message to other devices but you actually put a TTL on this one so you don't have circular flooding so it doesn't get back to you and will stop eventually and you can manage that TTL on your network when you really realize that your network is really small you decrease the TTL and then it doesn't get flooded too far. And there's an implicit message cache that is mandatory that will avoid you actually taking messages up and stupidly repeating them. So once you've seen it before you're actually not going to repeat it again. And I have a little bit of a PDU diagram later on there where you'll see how this is actually possible to do these kind of things. Security has to be in there so we actually put the security at all layers so as a network layer security that is every packet is encrypted and authenticated. With the MIG, ASCCM, 120 and bit fully encrypted that key is shared for all devices in the whole network. So you have one shared key for your network. If you lose that key then attackers can get in your network and see parts of the network but since the application and the models are actually protected with different keys the only thing they can see packets in the network. If you have the network key you can pretend to be a relay. So if you're some sort of an attacker the only thing you gain with the network keys is that you can play in relay and your homeowner might actually think you were thanks for actually helping me out. Sequence numbers are at all levels as well so we actually avoid replay text. You can't really replay a packet because the sequence number has to be always increased. If you run out of sequence numbers there's a procedure to rotate the keys and then you rotate the keys. There's a manual on the middle detection on actually setting up the network as well so you can't really get easily in the same as pretending to be inside. Keys are rotated when needed so if you have to take a device out I don't know much, you can't really get trash can attacks but pretty much your light bulb breaks, you throw it in a trash can, it still has the key in there so people are actually capable of extracting keys out of broken hardware can actually take the key back and attack your network that's called a trash can attack. Once you actually take a device out we rotate the keys so even if they get the key out of the broken device they can't use it anymore because the network started using a new one. And on a general basis if there's something going on the keys actually are refreshed. It's a procedure that is a little more complicated in a large network but it's the only way to protect against these things and it can happen really easily. The access layer is the more interesting part because we actually as I said we separate it in network keys but we also have application key and device keys. So if you have a lighting application you have 10 lights and one switch they all share the same application key because they need to talk to each other. But they're also device keys, they are pairwise keys so the provisioner device that sets up your network can have a dedicated key with your device so they can reprogram it to do something else. So meaning even if you get an application key it doesn't mean you can actually compromise the specific device. The only thing you can actually do is oh my set of light bulbs I can attack and switch them on and off as I please. But it doesn't mean that you can actually use your switch on your spring cloud side or open the door because you only got the key for the lights. And you see where I'm going with this one. The provisioning to actually bring as I said the network is always encrypted to bring the device into the network is protected with asthmatic cryptography so it's ECDH P256 which is standard in Bluetooth since 4.2 for secure connections so we use the same basic cryptology to actually get the device onboarded. And as we know as today if you trust the NIST then P256 curves are pretty safe and we don't have quantum computers. This is as good as it gets. It's only used for a natural step but it will generate a unique device key that is derived so it's not even some random number that you can get wrong. It's really something that you have to get right and it's 100 bit strong key for AS and then you get network keys distributed and application keys distributed as needed. Obviously you will only install application keys in 30 devices then you know them so if your light should only know about the application key for your lighting and your door should only know about the application key of your door if you install application key in every device then you're actually avoiding this or breaking the separation that you actually would need. So if we actually break this down how these packets look like how they go over the years. So as I said we have 29 octets that's pretty tiny but we have a network identification at the top it's an R0 octet or actually to be priced 7 bit plus an IV index bit that will give you basic identification on is this packet for my network or not. So you have a 7 bit probability to actually figure out do I need to decrypt this packet or not. It's good if you have your neighbor has 3 networks set up you have 3 networks set up so actually you have some sort of chance that you don't try to decrypt a packet that is not for you because the only way to decide if the decryption was successful is if your network MIG actually succeeds. We have an obfuscator bit and encrypted bit so generally with the most part of the message you wanted to be encrypted. We can't encrypt everything because if I don't know what the source is and the sequence number and the TTL I have no idea what I'm decrypting against because the TTL sequence number and source is actually used as nouns so you don't you have proper sequence counter for your encryption. So they need to be in plain text they need to part of your packet but we actually didn't want to put the source address into the packet because then everybody can learn the source address is all in the network really easy. So they obfuscated with a single AS and a dedicated privacy key that really only you can know when you know the network key. So they're not encrypted but they're so hard to guess that it becomes almost unlikely but it's in theory possible hence only if you obfuscated and not encrypted. And then your destination address is encrypted and actually your whole PDUs are completely encrypted then you have a MIG at the end of it that protects it. And then the destination is as I said encrypted the PDUs encrypted and you will decrypt it and then you have your transport PDUs and you're going to all lay up. As I said in your lower transport layer you actually have segmentation reassembly so then we do segmentation reassembly but at that point the payload has its separate encryption on top of this one. So this is how the packet fundamentally goes over the AS. So even if you see a mesh network you can't really know is this the same mesh network what are the addresses in it etc. So it takes a lot of time to actually crack any of this one. While the lower level PDUs are really easy to get you don't even need any special hardware you can get an off the shelf Bluetooth dongle and start scanning for the network and you will see that there's some mesh network ongoing. No dedicated sniffers needed. Provisioning is a little more complicated since network is fully encrypted so we actually need to play a lot of extra steps to get the network onboarded. The basic idea is if a device is brand new out of the box it beacons with the identification I'm unprovisioned please go in provision me and then you either use an authenticate procedure. It's somebody you have a code on the box or a barcode that you can scan and then you have out of band protection and actually get the whole device securely onboarded but the device you will send an invitation you will exchange keys with public ecopterofe you get your authentication and then you distribute all the information for the devices at the network. This includes basic models basic configuration its address and so on and so forth and additionally application keys and so on. Pretty straightforward procedure really complicated. Totally not enough time to actually talk to this one if you're in cryptography that's really interesting because it's quite complicated but on a basic level it follows the same that we have done with Bluetooth 4.2 where we actually introduce secure connections and make sure that we actually use eCDH and P256 correctly and get this all working. For actually using the network we actually also had to go different ways because the main focus is like home automation, lighting, doors etc. We had to actually figure out a way how you address the devices because you don't really want to address a single device you want to address a group. If you stick a switch and your room has five six light bulbs you want to have them all go on at same time but you don't want to repeat your message six times because that's just cost bandwidth and it's complicated. So it's really a model publish and subscribe. Basic model says you actually have address assignments that allows you to actually address a single device and you give it the address and then the six lights actually take this as oh this is all for me and then they've changed their state and switch on. So pretty straightforward but to actually make this work the whole design gets a lot more complicated when it comes to how we actually have the inner working. So getting the mesh network working while cramming everything in 29 octets is complicated but then also actually make your logic work is even more complicated. So a node is pretty much a single device or whatever it does but a node can have multiple elements and this goes similar to what services have been in Bluetooth Classic. You have a primary element and you have additional elements. So in a simple case you have a light bulb that has a single element that is automatically the primary element and then you have the functionality in it. So what you can do with a light bulb on off and you can maybe adjust the brightness if it's a little more pricier one and then you have the conditions of these elements. Okay you can do on or off obviously and the brightness levels from one zero to ten and this is described with your models and this is where it gets pretty much right into the next one. Oh model and states okay. So everything is pretty much a models and the model defines the format as well and then you have the state and like what state it is currently and what's happening. So the states are on off and what's my brightness it's between zero and ten. Not of much of this one is defined that you can do dynamically discovered because you don't actually have the capacity in that work to say oh what do you support or you support zero to ten the other one supports zero to eleven then you actually make sense out of this. Everything is a lot of statically fine to actually do switching something on really quickly and you need to do this with lighting otherwise you have this popcorn effect where one light if you have 20 light bulbs in your room and you press the switch and the first ten go really quickly and the other ten go a ton of 50 millisecond delay and the other one too and you're thinking like what's going on there. They need to relatively go on at the same time so you need to cram everything in a small PDU so you want a single message and everybody receives that at the same time so they can react at the same time. So you need to keep things small and the only way to do this if you statically define this. So if you want to build a different light bulb that has different brightness states or whatever and can do other fancy things you pretty much have to inherit the model and build a different model on top of this one so they can talk to each other and there are vendor models as well if you want to do something that is not specced in the standard. More interestingly the models also have a client server model but also a control model. So the server model is obviously what you expose and the definition on how it's exposed. The client model is how you're going to use it, pretty much what message you're going to send and what implication that message has. So it means that octet you're going to send means I'm turning the light on and maybe also doing additionally something else that is possible. More interesting is the definition of a control model where you actually have some behavior that is more complicated. As an example you're requesting the temperature or the temperature changes that means it goes too high then you actually have to turn your machinery off because it's dangerous or you can build scenes like this one. You say I'm watching TV now that means my blinds go down, my lights are dimming, my TV goes on and the VCR goes on or something like that. So you can build something really complicated like that. Obviously this gets even more complicated when you actually start building, look we have these models and this is an overview how you have multiple servers and it happens on different devices and a client talking to control model and the control model then talking to the server models. This can be all designed and you need to be designed to be really efficient and really quickly over the air. Otherwise you're not going to make this fly in something that is low bandwidth and has to reach a lot of devices even through relays in an appropriate time. I mentioned addressing a couple of times before so it has multiple types of addresses that get really complicated. So you have an unassigned address that is when the device is unconfigured. You have a unique cast address but the unique cast address is not assigned to a node so a device is assigned to actually an element. So every element in your node can actually have a different address so you can address the element specifically. Virtual addresses you have then a set of elements that then get a label and then you have group addresses where you can define groups for publish and subscribe or you have these magically defined groups where you can oh I want to target all proxies so if you want to send the TTL definitely in all proxies you can send a single message and target more proxies to all friends or relays or even send something to the whole network. Say look I'm changing the TTL value from 7 to 8 you can send this to everybody and everybody just picks it up. So you can do these things. Given that you have the right application key to do these things of course. Addresses are generally 16 bit. The virtual addresses are UID labels that are hashed and they will give 128 bit label. Obviously there's some uncertainty there but the general thing considering is that you actually have conflicts really seldomly and even if you have conflicts they don't really matter. There are few limitations so these limitations get really funky. So the number of elements in a network is 32k. The number of group addresses is 16k pretty much easy but then it gets virtual addresses you can actually have 7 trillion of them so you can go knock yourself out and based on the fact that we have 128 bit network key that is a sole identification of your network you have 340 unidiscual mesh networks. I can't even print that number. I think it's not going to fit on the screen. So you can have as many networks as you want there's really no limitations you just create a new network key. There's an application level limitation because we can't hand out as many application keys. It's a storage thing but 4k different applications that gets you already pretty far. Same as go for subnets and then you can have 64k of scenes. There's one interesting part. If you stay away from the mesh network for 48 weeks you need to be re-provisioned because then you pretty much have no idea what your announces are anymore and you will never get back to this one. If you come back earlier your announce can be recovered. After that one you kind of lost. We also have some magic bits in there that the time that you can be off without talking to the network and still get a valid packet without having to get to a key refresh procedure. Announce update is 24 hours plus 4. So even with the sun rising and setting different times you can be fully solar powered and still stay with that network. So you get your battery powered up on your solar and then you wake up, get your messages and you go back down. So that's pretty much what you have there on the limitations. It's kind of funky limitations but it gets you pretty far. So projects that we actually have done this on. So we focused on ZephyrOS which is an Abetted Artox backed by the Linux Foundation and we have an open source low energy controller source code in there. We have an open source Bluetooth stack in there and we also have an open source Bluetooth mesh stack in there now that can be used in all possible roles. It works best on Nordic small devices like the BBC Microbit. So it's all available and you can just play with it and toy with it. It supports advertising and guts. You can build a proxy to talk with your phone to it or you can use a native advertising mesh. It supports the foundation models for basic configuration and setup and has a bunch of demos where you can actually have devices walk around. You can provision 20 of them and then send messages to the other etc. Funny enough that stack has been also ported to minute and other embedded operating systems. So it seems a lot of people make the effort and actually taking that stack building an operating system abstraction. Zephyr doesn't have any kind of abstraction. It's built really as similar as the Linux kernel. All is natively integrated and they go through the effort in porting this over. The only thing it doesn't really have at the moment is you can't provision it. So if you build a measure Zephyr mesh node, put it on a micro bit, you can't do much with it because it's unprovisioned. It stays unprovisioned. For this one we released so far what is called mesh control which is a gut based provisioner on top of Bluezy. So you can just install its command application with a read line interface and then you can actually provision your nodes, manage them, send commands, turn off lights and so on. So if you find a commercial mesh light bulb, you can actually use that one to toy with it. Native mesh for Linux is coming. We are working on actually building an optimized controller specification. So you would have to use Zephyr as a Bluetooth controller and then you can actually talk to this one. I'm expecting this to be released in about a month or two. So then we actually have also native mesh on Linux and can use it. The reason why it's actually not that easy is because we can't on a standard controller, we can't get the timings good enough that you would actually have good operational process. So we need to build a controller first that allows you to use it. We will open up the extensions and make them available for everybody to use. If you do turn the Bluetooth logo around and may turn it into M, you have your Bluetooth mesh. Some people did this funny thing. I actually found this yesterday and that was kind of interesting. With this one I'm actually done. Thanks for your attention. Do we have any questions? Please. The specifications are public on Bluetooth.com. It's a public specification. You can download it. So every node in the mesh is connected to each other. It's a mesh. They keep a cache with packet cache. So they will forward it again. So there's a packet cache based on the sequence number in there. And then you hash them and you will not forward them if you already forwarded it or seen it. That's true. But the assumption is that if you're really low power and concerned about your power, then you operate as low power node and then you don't need the message caching because you will only talk to your friend and your friend will do the message caching that has a little bit more power and a little bit more memory. You have to unmute the microphone to make this fly. Otherwise I'm just going to repeat it. Go ahead. So, I'm going to repeat it. I'm going to repeat it. So, I'm going to repeat it. So, the now is specific to your node. So you don't really need to store too much to actually do an efficient relay. Rough estimate is you probably need, depending on your TTL, you only need to care about a few. So I think the rough estimates we did on the initial implementation around 16 or something to keep. You make it bigger. You avoid that you actually have any attack vectors. But worse comes to worse. You relay that packet and someone else decides that's already in my cache. So, yes, that's obviously not a perfect system because that costs an enormous amount of memory. Same as routing. So you pick your right value that you think for your memory use cases value. The interesting part is you don't want to actually send, you don't want to relay everything altogether. So if someone just sends you something stupid or sends you a lot of message and overflows your message cache, you will probably relay again. So you build your device on how much, how fast you can actually send the packet over the air and how many you actually have to cache. So it's not a perfect system, but it actually helps a lot to reduce the unwanted relays into a network. So you can build a dumb one and you will always be relaying, which is not what we want. You want to actually look, you already see this, stop doing this again or someone else relay this. The spec also has a little bit of flexibility there. So if you want, if you have enough memory and want to be smart, you can actually be a better relay node than everybody else, which is then we have to be a competitive. So if you want to innovate on top of this one and make a better implementation that is smarter, that's great. But the basic standard needs to ensure that the network actually functions. And this network, we have been tested with thousands and thousands of nodes that actually functions really well and really fast. I don't think we can talk about offline on the technical details, but there's a lot more in there that I can actually spend in a 40 minute talk. Yes, please. It's unreliable. So define what you mean with unreliable. The message. Okay, try it without the microphone and then I repeat it. Okay, so yes, so the message might not read, sorry, reach the destination what you said. So yes, that's true. Generally, if you send a message, it might not reach your destination. So you have the choice between reliable and unreliable. So if you don't really care, you just want to send this and whoever hears it should act. You can do that or you actually have a reliability mechanism where you then have to actually send an act. And there's a support for block hacking messages. You can do this well. So you can, if you have a unique cast one, you can actually send a reliable message over the network, but then you need an acknowledgement mechanism that will send the acknowledgement back and you can build a reliable channel. That's interesting for one to one communication through the network. It doesn't really help you much if you have 20 light bulbs in your room and you want to switch them on. Do you really care that the 20th doesn't make it? The fact that you want is you want to get your light bulb on fourth. And yes, you might it buck you might crazy that the 20s one doesn't get on, but then you can switch it off and turn it on again. So there's something where you have, where you happily accept the human error or the error in the system compared to when you actually did fully reliable. If you need it fully reliable, you can do this, but you need more bandwidth in the network. So if you would do it unreliable, you need less bandwidth and you can get it done faster. So it's your choice, but it depends on the model. The model defines and all things are done. Okay. So if you're 20s light bulb, so I agree. If you're 20s light bulb never gets switched on because the network is built really, really poorly, I completely agree. That's absolutely annoying. But maybe then you should rethink your network topology and think realize that you've a missing relay. Yes, it can all happen. And if you think that a lot of other network topologies are better in that regard, some of them are, but they come at a really high cost and the high latency. So as I said, it's depending on the model, if you need reliable or unreliable communication and what you're going to accept. So if you say, oh, I need super high reliable light bulbs, also built a model for this one that actually does that. But the reality is the lighting model is defined as unreliable. Okay. We're giving up on the microphone. So yes, please. So the question is there some sort of certification for this one? Yes, the blue to sick has a certification for this one. So with every blue to stick I have to certify this. The security, let me put it this way, there's no test for the security besides it actually works, because the network is always encrypted. If you can't get it right, you will not talk to anybody ever, which means that solves it by itself. So if there's a weak device of the network that is built really stupidly. So yes, you have a device that actually has the network key application key or device key, and then it broadcast it out over ethernet to everybody to listen for more something. Yes, that's a dumb device, but that's out of scope to actually certify. That's just a really bad device that should be shamed on and never be bought by anybody. Tell me any system where that kind of security certification is present. Let me answer this differently. This is a network topology specification and mandating what hardware to use would be out of scope. This is not Apple, this is a standards organization that says, okay, you can do whatever chip you want once, you want because it has to be vendor neutral. If you like say, I'm Apple home kid and I'm demanding you to use XYZ chip, that's a manufacturer choice. And a manufacturer specification. This is an open specification, you can't do this. And I've not seen any open standard doing that one. The other people are waiting. Find me offline if you have a further question. Thank you very much.
 Welcome everybody, good morning.  After a little bit of technical differences I think we have this pretty much working.  So my name is Marcel Holtmann and I'm going to give you an introduction into what we have  released a couple of months ago which is a brand new Bluetooth standard.  So before I go any further, as usual, since I work for Intel blah blah blah, this claim  is. So Linux is the most stored trademark, Zephyr is the Linux foundation trademark and  Bluetooth is the Bluetooth sync trademark. Everything else are trademarks as well if  I forgot to actually mark them correctly.  Quick one about myself, so I've been doing the Linux Bluetooth stack since 2004 which  is already an awful long time. In the meantime I created Conman, a connection manager, Ophona,  cellular stack, pack runner for handling proxy setups, L embedded Linux library and also  IWD which you can actually hear about tomorrow if you care about what we have done in the  last year on that one.  I joined into in 2007 so it's pretty much 10 years right at Intel so far. I share the  internet working group so we're trying to actually get more IP networks over Bluetooth  and integrate it more properly. I'm sitting on the architecture review board as well so  I'm spending a lot of boring time on reviews, specs and standards and I've contributed massively  to the mesh standard that I'm going to introduce you today. It has been something around three  years right to actually get even the standard out the door including getting some implementations  of it around as well.  So why actually redoing everything and all over again? So pretty much this weird hype  term of Internet of Things drives a lot of innovation. Fundamentally breaks down is that  we want to actually connect everything and you're not going to connect anything with  cables so we need to start picking the wireless standard we want to use and there's so multitudes  of wireless standards around for any kind of embedded device or Internet of Things standards.  The really only problem is that which ones you're going to pick and if you pick one you  can't do the other one, if you pick this one it's maybe not in the phone, your phone is  with you on a daily basis and so on and so forth.  So when we set out around three years ago to actually do Bluetooth Smashers like look  we want to actually get something that is in the phone so either do Wi-Fi or you do  Bluetooth or you do cellular 5G for example but the lowest power one is Bluetooth so we  actually focus on let's get Bluetooth going instead of trying to make 15.4 better and  get it integrated into the phones or use Lora or any kind of light based standard etc.  And obviously the choice is pretty obvious since everything is better with Bluetooth  anyway so we picked on trying to do the next generation of Bluetooth.  Before we actually introduced Bluetooth Smash Bluetooth was rather boring technology. It  was point to point and had it's around since before 2000 so it's a really old standard  so we are I think we're approaching next 20 years of Bluetooth.  But if you see the left hand side you see Bluetooth Classic which is pretty much used  for in-car communication, headsets and so on and so forth.  And then about seven years ago they actually set out and said look we're actually going  to have to do something for low power devices. We have to use the power footprint on this  one and the memory footprint to actually make them run on a coin cell battery for a year  or even longer. And that's what's called Bluetooth Low Energy or Bluetooth Smart and  so back in the days the sick came up with some weird terminology like we have Bluetooth  Classic, we have Bluetooth Smart, we have Smart Ready and Smart Ready just means you  have the dual mode devices combined that can talk to both side.  But classic devices can't talk to low energy devices you always need one in the middle  that can actually pose. So until about beginning of this year that was a standard how we had  it, point to point dual mode devices, your phone was a dual mode device, your headset  was a single mode for classic and your heart rate monitor was a single mode for low energy.  That got completely turned around and made a lot more complicated beginning of the year.  So they keep classic around, it stays point to point but for low energy we actually introduced  multiple extra things. You can still do point to point, read your sensor data from your  heart rate monitor etc. But you can also do massive broadcasting because we have all this  beacon market where you have your location positioning and so on and so forth. So you  can basically broadcast your location or any information like URLs, Eddy Stone, iBeacon  etc. And then on top of that one now you had mesh, you can actually span mesh topologies  and actually do something for this for lighting or something else.  It gets a lot more complicated and I go through this in a little bit detail but fundamentally  on the left side classic is what it is. There's no innovation happening on classic or the  innovation happens in low energy. You will still use classic if you use a Bluetooth headset  for a really long time. My prediction is at least the next 8 to 10 years but every new  development will happen on Bluetooth LE. The thing is when you actually have a point to  point technology and one extent is with mesh, you can't do this just by saying I'm going  to build a mesh technology and that I'm done with it. You need a lot more. So even if you're  a network layer is mesh capable that doesn't mean you can't do anything without. You need  to actually lay us on top that actually know how to do certain things.  When we set out to do Bluetooth mesh the fundamental problem was if we actually have to broadcast  data the maximum PDU size is 31 octets. You have to subtract two octets for actually get  the basic information. I've pre-pended on this once you're left with 29 octets to do  a secure mesh capable network. So that's quite a challenge and that's what actually led to  this whole stack that we actually had to do on these multiple levels. So the bearer is  pretty much where you have the minimum of 29 octets. The alternate bearer is if you're  actually in a connection or if your connection less then you have your network layer that  will define your basic PDU formats and I have a diagram of this one later so don't worry  I'll show you this one as well. But it does addressing how you address one node in a network,  how you do encryption, decryption and especially also make sure that everything is authenticated  and secure. So Bluetooth mesh in specific there's no unsecure network. The network is  always encrypted and authenticated. We can't actually do any unsecure networks. And we  separate in network encryption from application encryption because that's two independent things.  You have because you're operating 29 octets we had to do a segmentation and reassembly  layer and then we had to have a level that actually encrypts the application messages  and authenticates them. We need to define how you do the data formats because if you  only have 29 octets and you want to tell a lamb to go on you don't want to spend over  three messages because then they keep waiting for these messages to arrive. So you want  to keep them as short as possible so you also need to play a little trickery with the message  formats. Then you need to configure this whole network because if you don't know how to build  your network configure and use it it's pretty much uses then you just have a network and  can't do anything with this one and then you want to have actually do lighting models  on this one or power models or something else. So actually you can switch on something  off you can switch something off or you can get sensor data like your HVAC is at this  time at this operational mode etc. What is really important mesh is not a new radio.  We didn't build a new radio. We didn't build a new Mac layer. We just built a network topology.  So we actually have Bluetooth or energy as the basic radio around it and then the topology  on how you actually turn that one into mesh network is what we have defined. And if we  recap this we get to the level that we actually have the old classic pairing side of things  where you have one device and otherwise so pretty much point to point. Mesh can use this  as well for backwards compatibility. So if you have a device that doesn't know how to  do broadcasting or doesn't know how to do mesh you can use a point to point connection  as a single entry hop into the network and say look I will bridge you into this network  if you can't do anything else which is great. So you can take your current phone that you  have, install an application and you can get access to a mesh network. But fundamentally  if you want to build the mesh you need to broadcast the packets because we can't do  any point to point connections anymore and actually building start topology or mesh topology  based on point to point connections is really complicated because you spend a lot of time  actually managing this one and you actually need a lot of memory. So assume we want to  run this on coin cell batteries and we need to manage 100 or 1000 nodes. You don't have  the memory capacity in your controller to actually do these. So we are broadcasting  every packet out which means we actually use the advertising feature of Bluetooth for energy  to just send a packet and whoever is in vicinity will receive that packet. And based on that  one then you finally enter the level where you actually get a mesh topology where you  actually say all these devices have the same keys and the same network and they can successfully  talk to each other and we can actually have addresses assigned to any of these nodes.  I will get back to this one how the topologies build in a slide or two but this is just the  basic idea. I grabbed a stack diagram from Nordic to just show you how they actually  this is fundamentally different than what we have done before. So on the middle side  you see the good old Bluetooth low energy stack. You have a link layer, you have a  security manager, you have add, you have get, you have gap and that's pretty much how everything  runs today. Nordic always has some extra specifics around but this is good for demonstration  purposes on how they actually had to integrate this because you fundamentally have to do  the same if you want to build this. So on the left side you have a Bluetooth mesh stack  that pretty much circumvents everything because it only actually needs to talk to your radio  and actually put your packets on the air and receive the packets from the air because it  builds the packets in a specific format. Well the format is still the low level format of  Bluetooth LE but it doesn't really say that you have to go to the link layer, you just  have to format them correctly. And there's a lot of extra timing involved with this one  so you don't repeat packets too often because the more you put the packet on the air the  more power you consume, the more power you consume on your receiver side. But the interesting  one that they forgot to mention on this one is that we also have the legacy entry point,  we have a point to point connection. So the Bluetooth mesh stack on the left side fundamentally  also have to put this on the middle side where you actually have a gut or connection oriented  channel and stack this on top of this on for legacy purposes. So it gets shrink-wrapped  in multiple ways. But it's good for demonstration purposes that you pretty much have two things  side by side. Before I show you the topology slide we actually ended up with four different  features. You can call them roles but they can also happen, you can have multiple features  on the same node so the roles don't really match because it's more like an OR feature  than an XOR. So you have a low power feature. If you actually build a mesh topology and  want to run on a co-insult battery you need to consider the devices that really only have  a co-insult battery and then say look I want to be only on air when I need to be because  every time you have to turn your receiver on you consume so much power that you actually  can't stay on your battery for long. So you have these devices that really have a tiny  battery and they pretty much say I'm on now, someone needs to help me to get my data. So  that's what's called LPNs or low power nodes and they always have to talk to someone else.  They have pretty much edge nodes and then go say look I'm setting up a friend of mine  and I'm waiting for them to forward me the messages in case I'm offline and miss them.  And the friend is just the opposite role where they actually have to always on power and  they're happy to give other low power nodes the packages. And a friend can talk to multiple  low power nodes but a low power node generally only have a single friend. And then we have  a mesh network so messages need to be read because we want to span the extra width of  the network so if you want to cover whole building, 10 meter range of a Bluetooth radio  is not going to cut it so you need to have multiple of them and they have to relay the  messages one to another one and go through this. The proxy one is what I mentioned earlier  for backwards compatibility. If you want to have a phone bridged into your network that  is not mesh capable, it needs to do this over a gut connections for Bluetooth and this is  pretty much the proxy does okay I'm along you and you can actually send the message  and then I will relay everything back to you. If you draw this up you get a pretty much  easy to apology feature of this one where you have fans, ceiling fans, light bulbs and  switches etc. What is generally considered is that the light bulbs and ceiling fans are  always powered so they can easily relay messages, they can easily be friends and so on and so  forth. Then you have proxies like a phone that will talk to a proxy capable light bulbs  and they can then know the phone can talk to them and then say I want a part of your  network. But you already see that the proxy is a little bit often outside because it doesn't  do anything else. It talks to one specific friend and the friend then has to bridge everything  so you can't have a different path into the network. Once you choose your proxy you are  going through that proxy and don't say I'm just sending the message to everybody and  hopefully someone is going to pick it up so you have to find a dedicated proxy. Friendship  is pretty much the similar concept you find a single friend and then you go through that  one through the network. But all the other nodes, the route from the switch on the right  to the light bulb on the left, there's no specific route it goes. It can go to the top,  go through another switch, it can go to a ceiling fan and so on and so forth. So we  really rely on that the messages are relayed through the whole network and everybody can  see them. And coming to this point, the relaying in Bluetooth matches is actually kept on purpose  simple because the more complex you make it and you have routing in there you actually  need memory and that memory you don't have and if you need a lot of memory you need to  consume also more power so it gets really tricky. So pretty much if you decided I'm  having enough power I will relay messages then you actually do and retransmit these messages  as needed. You can do maximum of 127 hops and generally that's a pretty large area if you  consider if you're range between 10 and 100 meters on a Bluetooth radio. We do flooding  so it's a flooding based mesh network so every message you get gets back to everybody else  so you're basically flooding everything out. It is considered what's called a managed flood.  In general you retransmit the message to other devices but you actually put a TTL on this  one so you don't have circular flooding so it doesn't get back to you and will stop eventually  and you can manage that TTL on your network when you really realize that your network  is really small you decrease the TTL and then it doesn't get flooded too far. And there's  an implicit message cache that is mandatory that will avoid you actually taking messages  up and stupidly repeating them. So once you've seen it before you're actually not going to  repeat it again. And I have a little bit of a PDU diagram later on there where you'll  see how this is actually possible to do these kind of things. Security has to be in there  so we actually put the security at all layers so as a network layer security that is every  packet is encrypted and authenticated. With the MIG, ASCCM, 120 and bit fully encrypted  that key is shared for all devices in the whole network. So you have one shared key  for your network. If you lose that key then attackers can get in your network and see  parts of the network but since the application and the models are actually protected with  different keys the only thing they can see packets in the network. If you have the network  key you can pretend to be a relay. So if you're some sort of an attacker the only thing you  gain with the network keys is that you can play in relay and your homeowner might actually  think you were thanks for actually helping me out. Sequence numbers are at all levels  as well so we actually avoid replay text. You can't really replay a packet because the  sequence number has to be always increased. If you run out of sequence numbers there's  a procedure to rotate the keys and then you rotate the keys. There's a manual on the middle  detection on actually setting up the network as well so you can't really get easily in  the same as pretending to be inside. Keys are rotated when needed so if you have to take  a device out I don't know much, you can't really get trash can attacks but pretty much  your light bulb breaks, you throw it in a trash can, it still has the key in there so  people are actually capable of extracting keys out of broken hardware can actually take the  key back and attack your network that's called a trash can attack. Once you actually take  a device out we rotate the keys so even if they get the key out of the broken device they  can't use it anymore because the network started using a new one. And on a general basis if  there's something going on the keys actually are refreshed. It's a procedure that is a  little more complicated in a large network but it's the only way to protect against these  things and it can happen really easily. The access layer is the more interesting part  because we actually as I said we separate it in network keys but we also have application  key and device keys. So if you have a lighting application you have 10 lights and one switch  they all share the same application key because they need to talk to each other. But they're  also device keys, they are pairwise keys so the provisioner device that sets up your  network can have a dedicated key with your device so they can reprogram it to do something  else. So meaning even if you get an application key it doesn't mean you can actually compromise  the specific device. The only thing you can actually do is oh my set of light bulbs I  can attack and switch them on and off as I please. But it doesn't mean that you can actually  use your switch on your spring cloud side or open the door because you only got the key  for the lights. And you see where I'm going with this one. The provisioning to actually  bring as I said the network is always encrypted to bring the device into the network is protected  with asthmatic cryptography so it's ECDH P256 which is standard in Bluetooth since 4.2  for secure connections so we use the same basic cryptology to actually get the device  onboarded. And as we know as today if you trust the NIST then P256 curves are pretty  safe and we don't have quantum computers. This is as good as it gets. It's only used  for a natural step but it will generate a unique device key that is derived so it's  not even some random number that you can get wrong. It's really something that you have  to get right and it's 100 bit strong key for AS and then you get network keys distributed  and application keys distributed as needed. Obviously you will only install application  keys in 30 devices then you know them so if your light should only know about the application  key for your lighting and your door should only know about the application key of your  door if you install application key in every device then you're actually avoiding this  or breaking the separation that you actually would need. So if we actually break this down  how these packets look like how they go over the years. So as I said we have 29 octets  that's pretty tiny but we have a network identification at the top it's an R0 octet  or actually to be priced 7 bit plus an IV index bit that will give you basic identification  on is this packet for my network or not. So you have a 7 bit probability to actually figure  out do I need to decrypt this packet or not. It's good if you have your neighbor has 3  networks set up you have 3 networks set up so actually you have some sort of chance that  you don't try to decrypt a packet that is not for you because the only way to decide  if the decryption was successful is if your network MIG actually succeeds. We have an  obfuscator bit and encrypted bit so generally with the most part of the message you wanted  to be encrypted. We can't encrypt everything because if I don't know what the source is  and the sequence number and the TTL I have no idea what I'm decrypting against because  the TTL sequence number and source is actually used as nouns so you don't you have proper  sequence counter for your encryption. So they need to be in plain text they need to part  of your packet but we actually didn't want to put the source address into the packet  because then everybody can learn the source address is all in the network really easy.  So they obfuscated with a single AS and a dedicated privacy key that really only you  can know when you know the network key. So they're not encrypted but they're so hard  to guess that it becomes almost unlikely but it's in theory possible hence only if  you obfuscated and not encrypted. And then your destination address is encrypted and  actually your whole PDUs are completely encrypted then you have a MIG at the end of it that  protects it. And then the destination is as I said encrypted the PDUs encrypted and you  will decrypt it and then you have your transport PDUs and you're going to all lay up. As I  said in your lower transport layer you actually have segmentation reassembly so then we do  segmentation reassembly but at that point the payload has its separate encryption on  top of this one. So this is how the packet fundamentally goes over the AS. So even if  you see a mesh network you can't really know is this the same mesh network what are the  addresses in it etc. So it takes a lot of time to actually crack any of this one. While  the lower level PDUs are really easy to get you don't even need any special hardware you  can get an off the shelf Bluetooth dongle and start scanning for the network and you  will see that there's some mesh network ongoing. No dedicated sniffers needed. Provisioning  is a little more complicated since network is fully encrypted so we actually need to  play a lot of extra steps to get the network onboarded. The basic idea is if a device is  brand new out of the box it beacons with the identification I'm unprovisioned please go  in provision me and then you either use an authenticate procedure. It's somebody you  have a code on the box or a barcode that you can scan and then you have out of band protection  and actually get the whole device securely onboarded but the device you will send an  invitation you will exchange keys with public ecopterofe you get your authentication and  then you distribute all the information for the devices at the network. This includes  basic models basic configuration its address and so on and so forth and additionally application  keys and so on. Pretty straightforward procedure really complicated. Totally not enough time  to actually talk to this one if you're in cryptography that's really interesting because  it's quite complicated but on a basic level it follows the same that we have done with  Bluetooth 4.2 where we actually introduce secure connections and make sure that we actually  use eCDH and P256 correctly and get this all working. For actually using the network we  actually also had to go different ways because the main focus is like home automation, lighting,  doors etc. We had to actually figure out a way how you address the devices because you  don't really want to address a single device you want to address a group. If you stick a  switch and your room has five six light bulbs you want to have them all go on at same time  but you don't want to repeat your message six times because that's just cost bandwidth  and it's complicated. So it's really a model publish and subscribe. Basic model says you  actually have address assignments that allows you to actually address a single device and  you give it the address and then the six lights actually take this as oh this is all for me  and then they've changed their state and switch on. So pretty straightforward but to actually  make this work the whole design gets a lot more complicated when it comes to how we actually  have the inner working. So getting the mesh network working while cramming everything  in 29 octets is complicated but then also actually make your logic work is even more  complicated. So a node is pretty much a single device or whatever it does but a node can  have multiple elements and this goes similar to what services have been in Bluetooth Classic.  You have a primary element and you have additional elements. So in a simple case you have a light  bulb that has a single element that is automatically the primary element and then you have the functionality  in it. So what you can do with a light bulb on off and you can maybe adjust the brightness  if it's a little more pricier one and then you have the conditions of these elements.  Okay you can do on or off obviously and the brightness levels from one zero to ten and  this is described with your models and this is where it gets pretty much right into the  next one. Oh model and states okay. So everything is pretty much a models and the model defines  the format as well and then you have the state and like what state it is currently and what's  happening. So the states are on off and what's my brightness it's between zero and ten. Not  of much of this one is defined that you can do dynamically discovered because you don't  actually have the capacity in that work to say oh what do you support or you support  zero to ten the other one supports zero to eleven then you actually make sense out of  this. Everything is a lot of statically fine to actually do switching something on really  quickly and you need to do this with lighting otherwise you have this popcorn effect where  one light if you have 20 light bulbs in your room and you press the switch and the first  ten go really quickly and the other ten go a ton of 50 millisecond delay and the other  one too and you're thinking like what's going on there. They need to relatively go on at  the same time so you need to cram everything in a small PDU so you want a single message  and everybody receives that at the same time so they can react at the same time. So you  need to keep things small and the only way to do this if you statically define this.  So if you want to build a different light bulb that has different brightness states  or whatever and can do other fancy things you pretty much have to inherit the model  and build a different model on top of this one so they can talk to each other and there  are vendor models as well if you want to do something that is not specced in the standard.  More interestingly the models also have a client server model but also a control model.  So the server model is obviously what you expose and the definition on how it's exposed.  The client model is how you're going to use it, pretty much what message you're going  to send and what implication that message has. So it means that octet you're going to  send means I'm turning the light on and maybe also doing additionally something else that  is possible. More interesting is the definition of a control model where you actually have  some behavior that is more complicated. As an example you're requesting the temperature  or the temperature changes that means it goes too high then you actually have to turn your  machinery off because it's dangerous or you can build scenes like this one. You say I'm  watching TV now that means my blinds go down, my lights are dimming, my TV goes on and the  VCR goes on or something like that. So you can build something really complicated like  that. Obviously this gets even more complicated when you actually start building, look we  have these models and this is an overview how you have multiple servers and it happens  on different devices and a client talking to control model and the control model then  talking to the server models. This can be all designed and you need to be designed to  be really efficient and really quickly over the air. Otherwise you're not going to make  this fly in something that is low bandwidth and has to reach a lot of devices even through  relays in an appropriate time. I mentioned addressing a couple of times before so it  has multiple types of addresses that get really complicated. So you have an unassigned address  that is when the device is unconfigured. You have a unique cast address but the unique  cast address is not assigned to a node so a device is assigned to actually an element.  So every element in your node can actually have a different address so you can address  the element specifically. Virtual addresses you have then a set of elements that then  get a label and then you have group addresses where you can define groups for publish and  subscribe or you have these magically defined groups where you can oh I want to target all  proxies so if you want to send the TTL definitely in all proxies you can send a single message  and target more proxies to all friends or relays or even send something to the whole  network. Say look I'm changing the TTL value from 7 to 8 you can send this to everybody  and everybody just picks it up. So you can do these things. Given that you have the  right application key to do these things of course. Addresses are generally 16 bit.  The virtual addresses are UID labels that are hashed and they will give 128 bit label.  Obviously there's some uncertainty there but the general thing considering is that you  actually have conflicts really seldomly and even if you have conflicts they don't really  matter. There are few limitations so these limitations get really funky. So the number  of elements in a network is 32k. The number of group addresses is 16k pretty much easy  but then it gets virtual addresses you can actually have 7 trillion of them so you can  go knock yourself out and based on the fact that we have 128 bit network key that is a  sole identification of your network you have 340 unidiscual mesh networks. I can't even  print that number. I think it's not going to fit on the screen. So you can have as many  networks as you want there's really no limitations you just create a new network key. There's  an application level limitation because we can't hand out as many application keys. It's  a storage thing but 4k different applications that gets you already pretty far. Same as  go for subnets and then you can have 64k of scenes. There's one interesting part. If  you stay away from the mesh network for 48 weeks you need to be re-provisioned because  then you pretty much have no idea what your announces are anymore and you will never get  back to this one. If you come back earlier your announce can be recovered. After that  one you kind of lost. We also have some magic bits in there that the time that you can be  off without talking to the network and still get a valid packet without having to get to  a key refresh procedure. Announce update is 24 hours plus 4. So even with the sun rising  and setting different times you can be fully solar powered and still stay with that network.  So you get your battery powered up on your solar and then you wake up, get your messages  and you go back down. So that's pretty much what you have there on the limitations. It's  kind of funky limitations but it gets you pretty far. So projects that we actually have  done this on. So we focused on ZephyrOS which is an Abetted Artox backed by the Linux Foundation  and we have an open source low energy controller source code in there. We have an open source  Bluetooth stack in there and we also have an open source Bluetooth mesh stack in there  now that can be used in all possible roles. It works best on Nordic small devices like  the BBC Microbit. So it's all available and you can just play with it and toy with it.  It supports advertising and guts. You can build a proxy to talk with your phone to it  or you can use a native advertising mesh. It supports the foundation models for basic  configuration and setup and has a bunch of demos where you can actually have devices  walk around. You can provision 20 of them and then send messages to the other etc. Funny  enough that stack has been also ported to minute and other embedded operating systems.  So it seems a lot of people make the effort and actually taking that stack building an  operating system abstraction. Zephyr doesn't have any kind of abstraction. It's built  really as similar as the Linux kernel. All is natively integrated and they go through  the effort in porting this over. The only thing it doesn't really have at the moment  is you can't provision it. So if you build a measure Zephyr mesh node, put it on a micro  bit, you can't do much with it because it's unprovisioned. It stays unprovisioned. For  this one we released so far what is called mesh control which is a gut based provisioner  on top of Bluezy. So you can just install its command application with a read line interface  and then you can actually provision your nodes, manage them, send commands, turn off lights  and so on. So if you find a commercial mesh light bulb, you can actually use that one  to toy with it. Native mesh for Linux is coming. We are working on actually building an optimized  controller specification. So you would have to use Zephyr as a Bluetooth controller and  then you can actually talk to this one. I'm expecting this to be released in about a month  or two. So then we actually have also native mesh on Linux and can use it. The reason why  it's actually not that easy is because we can't on a standard controller, we can't get  the timings good enough that you would actually have good operational process. So we need  to build a controller first that allows you to use it. We will open up the extensions  and make them available for everybody to use. If you do turn the Bluetooth logo around  and may turn it into M, you have your Bluetooth mesh. Some people did this funny thing. I  actually found this yesterday and that was kind of interesting. With this one I'm actually  done. Thanks for your attention. Do we have any questions? Please. The specifications  are public on Bluetooth.com. It's a public specification. You can download it.  So every node in the mesh is connected to each other. It's a mesh. They keep a cache  with packet cache. So they will forward it again. So there's a packet cache based on  the sequence number in there. And then you hash them and you will not forward them if  you already forwarded it or seen it. That's true. But the assumption is that if you're  really low power and concerned about your power, then you operate as low power node  and then you don't need the message caching because you will only talk to your friend  and your friend will do the message caching that has a little bit more power and a little  bit more memory. You have to unmute the microphone to make this fly. Otherwise I'm just going  to repeat it. Go ahead.  So, I'm going to repeat it. I'm going to repeat it. So, I'm going to repeat it. So,  the  now is specific to your node. So you don't really need to store too much to actually do  an efficient relay. Rough estimate is you probably need, depending on your TTL, you  only need to care about a few. So I think the rough estimates we did on the initial implementation  around 16 or something to keep. You make it bigger. You avoid that you actually have any  attack vectors. But worse comes to worse. You relay that packet and someone else decides  that's already in my cache. So, yes, that's obviously not a perfect system because that  costs an enormous amount of memory. Same as routing. So you pick your right value that  you think for your memory use cases value. The interesting part is you don't want to  actually send, you don't want to relay everything altogether. So if someone just sends you something  stupid or sends you a lot of message and overflows your message cache, you will probably relay  again. So you build your device on how much, how fast you can actually send the packet  over the air and how many you actually have to cache. So it's not a perfect system, but  it actually helps a lot to reduce the unwanted relays into a network. So you can build a  dumb one and you will always be relaying, which is not what we want. You want to actually  look, you already see this, stop doing this again or someone else relay this. The spec  also has a little bit of flexibility there. So if you want, if you have enough memory  and want to be smart, you can actually be a better relay node than everybody else, which  is then we have to be a competitive. So if you want to innovate on top of this one and  make a better implementation that is smarter, that's great. But the basic standard needs  to ensure that the network actually functions. And this network, we have been tested with  thousands and thousands of nodes that actually functions really well and really fast. I don't  think we can talk about offline on the technical details, but there's a lot more in there that  I can actually spend in a 40 minute talk. Yes, please.  It's unreliable.  So define what you mean with unreliable.  The message.  Okay, try it without the microphone and then I repeat it.  Okay, so yes, so the message might not read, sorry, reach the destination what you said.  So yes, that's true. Generally, if you send a message, it might not reach your destination.  So you have the choice between reliable and unreliable. So if you don't really care, you  just want to send this and whoever hears it should act. You can do that or you actually  have a reliability mechanism where you then have to actually send an act. And there's  a support for block hacking messages. You can do this well. So you can, if you have  a unique cast one, you can actually send a reliable message over the network, but then  you need an acknowledgement mechanism that will send the acknowledgement back and you  can build a reliable channel.  That's interesting for one to one communication through the network. It doesn't really help  you much if you have 20 light bulbs in your room and you want to switch them on. Do you  really care that the 20th doesn't make it? The fact that you want is you want to get  your light bulb on fourth. And yes, you might it buck you might crazy that the 20s one doesn't  get on, but then you can switch it off and turn it on again. So there's something where  you have, where you happily accept the human error or the error in the system compared  to when you actually did fully reliable. If you need it fully reliable, you can do this,  but you need more bandwidth in the network. So if you would do it unreliable, you need  less bandwidth and you can get it done faster. So it's your choice, but it depends on the  model. The model defines and all things are done.  Okay. So if you're 20s light bulb, so I agree. If you're 20s light bulb never gets switched  on because the network is built really, really poorly, I completely agree. That's absolutely  annoying. But maybe then you should rethink your network topology and think realize that  you've a missing relay. Yes, it can all happen. And if you think that a lot of other network  topologies are better in that regard, some of them are, but they come at a really high  cost and the high latency. So as I said, it's depending on the model, if you need reliable  or unreliable communication and what you're going to accept. So if you say, oh, I need  super high reliable light bulbs, also built a model for this one that actually does that.  But the reality is the lighting model is defined as unreliable.  Okay. We're giving up on the microphone. So yes, please.  So the question is there some sort of certification for this one? Yes, the blue to sick has a  certification for this one. So with every blue to stick I have to certify this. The  security, let me put it this way, there's no test for the security besides it actually  works, because the network is always encrypted. If you can't get it right, you will not talk  to anybody ever, which means that solves it by itself.  So if there's a weak device of the network that is built really stupidly. So yes, you  have a device that actually has the network key application key or device key, and then  it broadcast it out over ethernet to everybody to listen for more something. Yes, that's  a dumb device, but that's out of scope to actually certify. That's just a really bad  device that should be shamed on and never be bought by anybody.  Tell me any system where that kind of security certification is present.  Let me answer this differently. This is a network topology specification and mandating  what hardware to use would be out of scope. This is not Apple, this is a standards organization  that says, okay, you can do whatever chip you want once, you want because it has to  be vendor neutral. If you like say, I'm Apple home kid and I'm demanding you to use XYZ  chip, that's a manufacturer choice. And a manufacturer specification. This is an open  specification, you can't do this. And I've not seen any open standard doing that one.  The other people are waiting. Find me offline if you have a further question. Thank you  very much.
2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_0_155.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_156_587.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_588_911.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_912_959.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_960_1079.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_1080_1127.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_1128_1175.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_1176_1235.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_1236_1283.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_1284_1331.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_1332_1487.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_1488_2339.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_2340_3779.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_3780_4031.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_4032_5951.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_5952_7295.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_7296_10643.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_10644_13247.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_13248_18107.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_18108_19811.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_19812_21815.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_21816_22043.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_22044_22931.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_22932_25739.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_25740_27119.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_27120_30743.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_30744_32111.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_32112_32231.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_32232_32531.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_32532_33203.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_33204_33707.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_33708_34931.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_34932_36947.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_36948_37019.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_37020_38327.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_38328_39107.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_39108_41087.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_41088_43667.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_43668_45707.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_45708_45755.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_45756_45803.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_45804_45911.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_45912_45971.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_45972_46019.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_46020_47303.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_47304_47555.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_47556_47711.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_47712_47771.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_47772_47843.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_47844_49475.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_49476_50663.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_50664_60623.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_60624_60683.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_60684_60731.png 2017_Introducing_Bluetooth_Mesh_4N6qyaWSne0_60732_60875.png