 Okay, so 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 gonna give you an introduction into what we have leased 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 disclaimers So Linux is you know stored straight marks. Zephyr is a Linux foundation thread mark and Bluetooth is a bit of sick trademark Everything else are trademarks as well if I forgot to actually mark them correctly Um 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 phone a 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'd 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 spending a lot of boring time on review specs and standards And I've contributed massively to the mesh standard that I'm going to introduce you today So it has been Something around three years right actually getting 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 is maybe not in the phone Your phone is with you it on a daily basis and so on and so forth So when we set out around three years ago to actually do Bluetooth measures 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 mesh 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 have I think we approaching next their 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 say look We actually gonna have to do something for low power devices We have to do stuff off power footprint on this one and the memory footprint to actually make them run on coin cell battery for a year or even longer and as is thought called Bluetooth low energy or Bluetooth smart and So back in the days the sick came up with some weird terminology and okay We have Bluetooth classic we have blue to smart when we are 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 the energy devices You always need one in the middle that I can shoot both 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 so 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 We have a location positioning and so on and so forth so you can basically broadcast your location or any information like URLs Eddy stone I beacon etc And then on top of that one now you had mesh you can span mesh topologies and actually do something for this for lighting or something else It gets a lot more complicated and 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 all 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 eight to ten 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 this 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 your 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 Prepended 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 20 on octets That the alternate bearers if you actually interconnection 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 mesh or Bluetooth mesh and 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 20 nanok tets. We had to do a segmentation and reassembly layer And then we had to have a level that actually encrypts the other 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 me with the message formats Then you need to configure this whole network because if you don't know how to build your network configured 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 Lightning 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 term 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 in your Mac layer. We just built a network topology So you 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 like 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 I will bridge you into this network if you can't do anything else Which is great So you can take a 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 coins for batteries and we need to manage hundred and or thousand nodes You don't have the memory capacity in your controller to actually do these so we broadcasting every packet out Which means we actually use the advertising feature of Bluetooth for energy to just send a packet and whoever's 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 say look 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 topology is built in a 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 else you have done before so on the middle side You see the good old Bluetooth low energy stack. You have a link layer of your to cap You have security manager you have add you have got you have gap and that's pretty much Everything runs today Nordic always has some extra specifics around but there's 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 that 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 where 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 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 Your power you consume on your receiver side But the interesting one that X they forgot to mention on this one I said we also have the legacy entry point we have a point-to-point connection So the Bluetooth mesh stack on the left side Fundamentally, you 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 one for legacy purposes So it gets shrink-wrapped 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 note So the roles don't really match because it's more like an all feature than an Exhaust so you have a low power feature if you actually build a mesh topology and one around a coin cell battery You need to consider the devices that really only have a coin cell battery And then say look I want to be only on air When I need to be because every time you have to be turn your receiver on you consume so much power that you actually can't Stay on your battery for long So you have this devices that really have a tiny battery and they're 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're pretty much edge nodes and then go as a 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 tell Always on power and they're happy to give other Low power nodes the packets 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 on half a phone bridged into your network that is not mesh capable. It needs to do this over Get connections for Bluetooth and this is pretty much of the proxy does okay I'm along you and you can actually send the message and then I will lay everything back to you If you draw this up you get a pretty much easy topology feature of this one Where you have like 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 sorry of proxy Capable light bulbs and they can then know the phone can talk to them and then say oh I'm on a part of your network But you already see that the proxy is a little bit of an outside because it doesn't do anything else It talks to one specific friend and the friend that has to bridge everything So you can't have a different path into the network once you choose your proxy You're going through that proxy and don't say I'm just sending the message to everybody and hopefully someone's gonna Need 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 notes 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 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 that you don't have and if you need a lot of memory You need to consume also more powers. It gets very tricky. So pretty much if you decided I'm Have 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 you've arranged 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 basically flooding everything out It is considered what's called a managed flood In general you can 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 main network is really small You can 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. We just see how this is actually Possible to do these kind of things Security sorry 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 authenticated with the MIG a SCCM 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 you the only thing you gain with the network keys that you can play in relay and your home owner might actually Thank you. 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 man on the middle attraction on actually setting up the network as well So you can't really get easily in there and say I'm just pretending to be inside Keys are rotated when needed. So if you have to take a device out I don't know much feeling with 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 actually capable of extracting keys or broken hardware can actually take the key back and attack your network That's called called a trash can attack One is 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 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 separated network keys But we also have application key and device keys So if you have a lighting applications 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 pair-wise 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 sprinkler outside 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 Asymmetric 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 on board it 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 initial 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 a yes And then you get network keys distributed and application keys distributed as needed Obviously you will only install application keys into the device then you know them So if your light should only know what the application key for your lighting and your door should only know But the application key of your door if you install application key in every device then you actually are avoiding this or Breaking the separation that you actually would need So if we actually break this down how these packets looks like how they go over the year So as I said we have 29 octets. That's pretty tiny But we have a network identification at them at the top. It's an or not one octet or actually to be priced seven bit plus in IV index bit That will give you basic Identification on is this packet for my network or not. So you have a seven bit probability to actually figure out Do I need to decrypt this packet or not? It's good if you have your neighbor has three network set up You have three network set up so actually 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 mick actually succeeds We have an obfuscator spit 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 plaintext 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 addresses All in the network really easy So they are obfuscated with a single a s 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 a full obfuscated and not encrypted and then your destination address is encrypted and actually your whole PDUs are completely encrypted and then you have a mick at the end of it that protects it and Then the destination as I said is encrypted the PDUs encrypted Then you will be cryptid 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 it the packet fundamentally goes over there. 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? So it takes a lot of time to actually Crack any of this one Well, 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 a network on board it the basic ideas if a device is brand new out of the box it beacons with the identification I'm unprovisioned. Please go and provision me and then you either use 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 Actually get the whole device Securely on board it but the device you will send invitation you will exchange keys with public ecography You get your authentication and then you distribute all the information for that device inside 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 sorry 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 in 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 dress a group if you stick a switch and your room has five six light bulbs You want to have them all go on at the 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 mesh network Working while cramming the everything in 29 octets is complicated But then also actually make your logic work is even more complicated So a note is pretty much a single device or whatever it does But a note can have multiple elements and this goes similar to what the 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 pricey I want 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 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 in what's happening So the states are I'm 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 never really discover it because you don't actually have the capacity in that What do you say? Oh, what do you support? Or you support zero to ten the other ones bought zero to eleven then you actually make sense out of this So 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 10 go really quickly and the other 10 go 250 millisecond delay than the other one to me single 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 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 you and their vendor models at wall if you want to do something that is not specced in the standard I'm more interestingly the models also have a client server model, but also 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 questing the temperature 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 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 a 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 more than 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 a 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 device it's assigned to action 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 so 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 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 you ID labels that are hashed and they will give 128 bit label Obviously, there's some uncertainty there, but the general Same considering is that you actually have conflicts really solemnly and even if you have conflicts that don't really matter There are few limitations so these limitations gets really 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 seven trillion of them so you can go Knock yourself out and based on the fact that we have a 128-bit network key that is a sole identification of your network You have three hundred forty any digital mesh networks. I can't even print that number I think it's only 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 off many application keys to storage thing But 4k different applications that gets you already pretty far same as go for the subnets and then you can have 65 64k of scenes There's one interesting part if you stay away from the mesh network for 48 weeks You need to be really 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 nouns 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 being having to get to a key refresh procedure announce update is 24 hours plus four so even with the sun rising and setting on different times you can be fully solar powered and get Still stay with that network So you get your power battery powered up on your solar and then the wake up get your messages and you go back down Um, 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 Zephyr OS, which is an abetted RTOS back by the Linux Foundation and we have an open source Bluetooth 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 micro bit 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 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 and walk around you can provision 20 of them and then send message to the other etc Funny enough that stack has been also ported to minute and other embedded Operating system 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 to 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 built 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 re-released so far what is called mesh control, which is a gut-based Provisioner on top of bluesy 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 a 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 will 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 things. 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 specification is public on bluetooth.com. It's a public specification. You can download it Yeah, so there's a packet cache based on the sequence number in there Yeah, right and then you 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 concern 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 measures caching that has a little bit more power and a little more memory You have to unmute the microphone to make this fly Otherwise, I'm just gonna repeat it. Go ahead. Oh Yeah, so the announce is Specific to your note So you don't really need to store too much to actually do an efficient relay Rough estimate is you probably need depending on a TTL. You only need to care about a few So I think the rough estimates we did one initial implementation around 16 or something to keep you make it bigger you avoid that you actually have any attack vectors, but Worst comes to worse. You really that packet and someone else decides up. That's already in my cash So yes, that's obviously not a perfect system because they cost an almost amount of memory same as routing wisdom So it's a You pick your right value 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 are all together So if someone just sends you something stupid or sends you a lot of message and overflows your message cast You will probably relay again So you build your device on how much how free or fast you can actually can send the packet over the air and how many You actually have to cash. So it's not a perfect system, but it actually helps a lot to Reduce the unwanted Relays into a national network. So you can build a dumb one and you will always be relaying which is not what we want You want to actually click look you already see this stop doing this again or someone else relate 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 note that 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 matter 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 notes It actually functions really well and really fast I 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 a message I've been 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 Reliability mechanism where then have to actually is send an act and there you 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 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? Yet the fact that you want is you want to get your light bulb and forth and yes You might it buck you might crazy Lee 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 how things are done Okay, so if you're 20s light bulb So I agree if you are 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 in the high latency So as I said, it's depending on the model if you need reliable unreliable communication and what you're gonna accept So if you say oh, I need super high reliable light bulbs also build 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's some sort of certification for this one. Yes, the blue to sick has a certification for this one So with every Bluetooth device you 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 let me answer this differently this is a network topology specification and Mendating what hardware to use would be out of scope. It would be this is not Apple This is a standards organization that says okay, you can you can do whatever chip you want once you want because it has to be vendor neutral If you like say I'm Apple homekit 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 question. Thank you very much