 Hydiwch nhw'n gwybod a'i gweld i chi i chi'n gweithio. Mae'n nesaf, Martin. Mae'n gwych gyda'r Gruff Slyf i Bluetooth. Fy oedd chi'n ffordd i chi'n gweld i chi'n gweithio, yn yr organ i Bluetooth cyflawni. Mae'r gwybod a'r cyfrwyr sydd wedi'u cyfrwyr sydd i'w cyfrweithio. Mae'r gwybod sy'n gweithio. Wysaeth y cwmniadau i chi ei wneud ei wneud i'r cyfrwyr sydd i'u cyfrwyr, i chi i bwysig yw ymddai'u cyfrwyr. oedd gyrraeddol i'r llad. Fwyl iawn. Fy yw'r bobl o'r Fyryd, ac rwy'n oes eu gymrydau meintau, ac mae'r camau ffyrddau meintau. Mae dda i'r gwy explores, wrth gwrs, yn rhoi'r gwrth i'r ceiswm, ac chi'n rhoi'r ceiswm y chwer i'r gwygon, rwy'n cais i'r gwyedd o'r bellie i'r gwaith, ond mae'r gwyiversary ymddeidwch yn lle o'r lle, ond mae'r gwy instrwydd daethaeth newydd yn gyflwynt gyda'r meintau. yspech was released just over a year ago. So, I'm going to give you a kind of introduction to Bluetooth mesh and what it is and how it differs in some ways from other things. Then, take a look at Zephyr's support for mesh. And I'm assuming you all kind of know what Zephyr is, but we'll come on to that later on. So, let's start here then with a bit of context. There are actually three Bluetooth technologies now. We've got BREDR, Basic Rate Enhanced Data Rate. That's the original. It's 20 years old. It's a cable replacement technology. You can create one-to-one kind of point-to-point wireless connections between devices. Quite good at handling streams of data if you've got wireless headphones. It's probably using that. Then, Bluetooth Low Energy. I'm not allowed to say BLE or things like that. Oh, I just said it. Oh, no. Which is newer, about eight years old now. Optimised to use as little power as possible. Better with smaller amounts of data, things like sensors and monitoring and control. Kind of applications. In terms of topologies, yes, you can create point-to-point connections, but it also has this ability to broadcast, which gives us a kind of one-to-many communication capability. That's how Bluetooth beacons work. They broadcast data. And then we have the newest kid on the block, Bluetooth Mesh. Spec was released last year. So, Bluetooth SIG, we don't make anything by the way. We don't develop software. We don't make products. We just look after the process that delivers the specifications. 3,000 pages of core spec and so on. And the spec for Mesh was released towards the end of last summer. And Mesh is about many-to-many communication, so you can have networks of tens of thousands of devices. It's really intended at this stage for things like smart buildings, where every light and switch and air conditioning unit and so on is a node in a mesh network. Relationship between those three amigos is this. So we've got essentially two distinct radio communication stacks, VR, EDR, and Bluetooth Low Energy at the bottom of the slide. There, and we've got Bluetooth Mesh, which is a networking stack, which actually sits on top of and makes use of Bluetooth Low Energy for wireless communication. So that's the relationship between those three things. Start looking at Mesh with some network-level concepts, and then we'll kind of drill down from there. So three handy words, easy to remember, all begin with multi. Multi-hop, multi-path, and multi-cast. So multi-hop's interesting. If you've worked with other mesh networks, you're probably familiar with it. But typically with wireless communication, you're constrained by the range of the radio communications stack. With a mesh network, that's not the case, because other devices will act as intermediaries, and messages can be relayed across the network so you can communicate with devices that are a long way out of radio range. Bluetooth Low Energy actually has a pretty good point-to-point range anyway. It's hundreds of metres. I kind of don't really care what specs say and stuff like that. I do my own testing because I'm a cynic. I've experienced hundreds of metres with cheap smartphones and things like BBC microbits in open spaces like a park. So not an optimal environment, but not a building either. Potential, though, is a fairly impressive point-to-point range compared to other Low Energy radios. Bluetooth Mesh lets you do up to 127 hops, so you can span a very large area, a large building, a collection of buildings like a campus. Somewhere I was talking to the other days looking at creating a Bluetooth mesh for his neighbourhood. In fact, this thing I've got around my neck is a node in a mesh network here at the conference as well. Multi-path is about reliability. So reliability in complex environments, light buildings is quite tough to achieve. There are a variety of mechanisms and strategies all aimed at achieving highly reliable communication in Bluetooth Mesh. I don't have time to talk about them all, but one of the primary ones is multi-path. The way multi-path works is when a device transmits a message. It's all message-oriented, provided you've done a teeny bit of network design and got some things right. Copies of that message will travel via different paths through the network to the destination. So this is architectural redundancy. If one of those paths fails, don't worry, another copy of your message should make it through to the other side as well. It's a race, the first duplicate that arrives gets processed to the others, will get discarded. Multi-cast is, for my money, the unsung hero of the multi. Multi-cast is all about scalability ultimately. The entire system is built around the basis, the assumption that almost all the operations that we'll ever want to carry out, the kind of use cases, will involve one device talking to numerous devices. So we have a group addressing scheme, groups contain essentially one or more devices. Tell you more about how that works a bit later on. And one of the benefits with multi-cast messaging is that you make incredibly efficient use of the radio medium with respect to the work you're trying to get done in the network. The number one constraining factor in scaling a wireless network like this is how efficiently you use the radio medium. So we have a number of frequencies we're going to be using, we use three. And how long you transmit on a given frequency four is how long you're stopping other devices from transmitting because you get collisions. Therefore, great big packets to get some job done on the slow radio, very bad because you're holding that frequency for a long time. Tiny, highly optimized, highly compressed packets to get the same type of work done. Transmitted on the fastest radio going, Bluetooth is four times faster than others. That's good because you're holding that frequency for a tiny fraction of the time. You'll get a lot done and because it's a multi-cast system, one tiny message transmitted in a very short burst could control hundreds of lights all in one go. So it gives you real scalability benefits. Let's talk about devices in the network we call nodes. I'll tell you a little about what the difference between a device and a node is later on, what constitutes membership of a network. There are special roles that devices can be asked to take on, and one of them concerns relaying, which have hinted us in talking about both multi-path and multi-hop. Important thing to understand is that we don't have to buy special black boxes that perform these special network roles like access points and relays and range extenders and those specialized network bits and pieces we might have at home. It's all software, therefore any mesh device give or take has the potential to take on any of these four roles I'm about to tell you about because it's just software and configuration. So if we start here, and I pretend I'm pausing dramatically so I can have some water like that. So relaying is something I've already hinted about. We can ask devices to act as relays and that means they will retransmit any messages that they hear on the radio. And this is the mechanism by which messages hop across the network. It's also the mechanism that allows that multi-path capability to take place. If a transmitting device is in range of more than one relay, then it will travel by more than one path. So for small networks, there's almost no design work to do, no thinking, something at home is just going to work. You don't need to give a lot of thought to it. For a big network, tens of thousands of devices like in a hotel, you do some design work. This is proper grown-up networking and one of the things you'll do is figure out what devices need to be relays, where they need to be so that you get the range extension and multi-path reliability that they give you. You don't want to go mad with this though because every relay will introduce repetition of messages into the network and consume radio bandwidth. Rule of thumb is 5% of your nodes will be relays. Give or take, but it's something you really do figure out at the time for your network in your building. So there's some testing and optimization methodology you have to apply. That's what relays do. Let's talk about friendship. It's a nice term, is it? It's my favourite technical term and it's a real technical term. I didn't just make it up. So one of the ways of categorising devices in a mesh network is there are those that are power rich, like lights that are plugged into the grid, mains power, and those which are power poor. They run off small batteries, they're embedded in the walls or under the floor. They have to run off that small battery for years and years and years, so power conservation is absolutely critical. Let me give you an example to kind of build an understanding of the property of friendship around. So imagine, per the slide here, I've got a temperature sensor and its job is to report the current environmental temperature only if it exceeds a certain upper level or falls below a certain threshold. So most of the time this device is quiet. Using the radio is what we're concerned about as engineers. That's what consumes power. But this device, it probably transmits four bytes every year. Okay, we need that on a hot day or very cold in the winter, that's all it does. So at this stage in the description of my device, I don't have a power problem, it's fine. This is a very efficient device. But unfortunately, it also needs to receive messages so I can change the configuration so it can respond to some system messages that exist so it can instigate key rotation procedures, all sorts of stuff like this. So now I've got a problem because now I have to have the radio on a high proportion of the time so it can receive messages and not miss them. And 99.9% of the time it's not going to receive anything because no one's talking to it. So this is a real conundrum. So friendship solves that problem. And again, the friend role and the low power node role, the configuration flag, so you just configure your devices as you install them. And the mesh specification includes a protocol which allows low power nodes to dynamically discover nodes that can be its friend, okay? In range, somewhere else in the room is a light or something, it's like it can be its friend. They then work together and this is how it works. Any messages sent to our low power node address to it, we have an addressing scheme. And by the way, as a low power node it's now a sleep, okay? So it's sleeping, not using the radio, doesn't need to worry because it knows it's got a friend. So any messages addressed to it will actually go to the friend where they get stored. Every now and again, sub to us how often, maybe once every three days, the low power node is going to wake up. It's going to transmit a special message part of that friendship protocol to its friend and say, hey, have you got anything for me? At which point we're in to receive mode, the radio's still on, we receive our messages. But we've used the radio for 100 milliseconds or something like that, okay? So that's how friendship works, helps to solve that power consumption conundrum. And the last role is called the proxy. So it may amaze you to know, you may already know that 10 million Bluetooth devices ship every day, oh, it's a marketing stat, oh no. But I think it's pretty amazing. So there are lots of them already out there, lots of them out there before Bluetooth mesh came along and we all have both flavours of Bluetooth in our phones, low energy and BREDR. Naturally, and not surprisingly, we wanted to make it possible for devices like smartphones, tablets with Bluetooth applications and so on to be able to interact with the mesh network securely, be part of that network in fact, so we can create monitoring and control dashboards for smart buildings, for industrial applications and so on. And that's what the proxy node gives you. It gives you a device that understands both the old Bluetooth low energy, the world of Gatt and Gap if you're familiar with that stuff and it has a mesh stack as well. So those are those four special roles that we're doing for time. How do these things talk to each other? Well, it's all message oriented and the spec contains a whole list of message types with individual unique op codes. Devices have what we call states, which are essentially data items which again are in the spec, they all have names, they take certain values which have meaning. Messages act upon states in devices, so I might send a message and it changes the state from on to off. The actual state name is the generic off state by the way that's its formal name. Big list of message types, as I said, but they fall into different categories. We've got set messages which will change a value, two types of set will come on to. I can send a get message and I'll get a reply that contains the current value of the state item that I'm targeting. We have status messages which are used to publish or announce a state value or in replies to get messages. Two types of set, we've got acknowledged messages. I send a set message that means please change to this value. I'll get a reply which is a status message containing the new value and unacknowledged messages where I don't get a reply. Now, believe it or not, if you're familiar with an accustomed to request response protocols, in fact, we hardly ever use the acknowledged variants. We use the unacknowledged ones almost all the time. A typical configuration of your devices in your network will have messages published several times in rapid succession. So rather than trying to manage responses from potentially very large numbers of devices if I'm addressing a group address with hundreds of devices in that group and having to figure out whether I received acknowledgements from all of them and then retransmitting when I find that I didn't from three of them and very quickly creating a storm, there's an RFC called, I think it's IP group multicast. Talked about all these problems in an IP world. Group multicast is quite hard with acknowledgements. It really doesn't scale very well, so we don't do it. We played the probabilities game. So if there's a 0.05% of a packet collision, for example, just to make up some numbers to try and explain the argument here, then the probability that two packets transmitted in rapid succession will collide is 0.05 times 0.05, quite a small number. If I actually transmit three at 20 millisecond intervals, now we're into teeny tiny probabilities of collisions and therefore message failure. So we play the probabilities game with this repeated message injection thing very fast and that is one of the ways, that plus multi-path that you get really reliable performance. He said about to do a live demo. Let's tempt fate. So moving on. So there you go, I just sent a message and on the slide there changed on to, sorry, off to on. Furthermore, so the other messaging systems based around the publish and subscribe model, so you're probably familiar with that already but the essence of it is that things like the lights down at the bottom there, say in one room, will be configured to subscribe to a particular group address. So any messages addressed to that address they will respond to. The switches at the top there will be configured to publish or transmit messages addressed to that same group address. So I hit the switch and message gets published in that group address, the appropriate lights respond. But the switches don't know the identity of the lights they're controlling. There are unicast unique addresses but we don't know them at the stage and the lights don't know anything about the switches that control them. This is good because it means I can make all sorts of changes to my network without having to reconfigure. Hotels have tens of thousands of lights. If every time you changed a light bulb or something like this, you had to reconfigure all the switches, never work. They'd never accept this technology, okay? So that's why that works like that. Another concept for you, the node composition. Composition I've included this because you'll probably see this in code when you come to do your own stuff. So far I've talked about nodes as devices in a Bluetooth mesh network but they actually have a broadly hierarchical breakdown or composition. Inside a node we have one or more things we call elements and each element actually has a unicast address. So an element is an individually addressable part of a device. Okay, I'll show you an example in a moment. But inside each element we have things called models and models contain those state data items that I mentioned earlier on. Models are essentially standard as in they're in the spec, software components. And what a product does or can do wirelessly is a consequence of the combination of models that it implements in its element, okay? That's what gives its capabilities. Big list of models in the spec. Some are very generally applicable using for any type of product, generic on-off server, for example. Some are specifically to do with commercial lighting which has got all sorts of weird requirements you wouldn't believe. The stuff for sensors and other things besides. So big list of models, more to come. Here's an example. I'm using the simplest possible ones here. Got the generic on-off clients implemented by my light switch and the generic on-off server model implemented by the lights. Yes, we have clients and servers. Clients produce and consume messages but they don't have state. Servers have state that gets acted upon by messages that clients send. Okay, so that's the concept. There's a graphic. So I've got an LED unit there. I think in the world of lighting, they call them luminaires. I'm trying to learn the proper terminology there. I hope you're impressed. And it's got three individual lamps in it. They also don't ever say light bulb to a lighting person. They freak out. We don't call them light bulbs anymore. But consequently, the composition in my code will be, I've got a node, that's the whole unit. I've got three elements because they're individually addressable. You can see the addresses there. 16 bit numbers, they're not MAC addresses. You might expect. And each element has, in this case, a couple of different models, generic on-off servers so I can switch them on or off. And lightness server, lightness is their term for brightness. So I can dim them, okay? So we can have lots of combinations of models to create different behaviours and capabilities. It's very flexible. Oh, it says demonstration there. If you could see my heart right now through some sort of Bluetooth gizmo, it just went up. Isn't that exciting? So, get my brain in gear. I have a demo and I made it. Can you tell? I'll show you what it looks like behind, actually. So, yeah, that's the back. So it's got a single power source, loads and loads of wires, Daisy chaining the power. And I've got, on the panels here, 8x8, 64, BBC micro bits, each one a node in a mesh network. In total, I've got 67 nodes in my network. I'll introduce them one at a time. So these babies each have a unicust address, which you might not see from the back, but if a presser button will announce its address, that's number one. This is also reassuring to me that they've still got power to number eight, as you can see across here and eventually down the bottom there. This one is number 64, okay? So that's where they are. They've each implemented or I've implemented the generic on off server, so I can switch them on or off in the generic level model, which lets me do various things with levels and I'm indicating level by illuminating fewer or more of the 25 LEDs on each of the micro bits. So that's what's in these things. Now, as far as the published subscribe stuff's concerned, each one of these nodes has subscribed to three group addresses. So each one is on a nicely coloured Lego panel. I'm keeping the Lego industry alive. So I've got four group addresses for panel membership. I've got a group address for each column and a group address for each row, so they each know about three group addresses that have each subscribed to it. Now, node number 65 is this thing here, which is a generic on off client. It's going to publish to the group address that these guys have subscribed to. And this is kind of the normal case that we're using other microcontroller-based products, devices to switch things on off, change the levels, that kind of stuff in a smart building. If I press button A, what do you know they came on because it published to the group address they've subscribed to? If I press button B, what do you know they switched off? I feel secretly relieved. But I'll keep that in my head so you don't know. So that's 65 nodes. But I've also got, hang on, I'm going to throw in place here, a web Bluetooth application, what I wrote. And as you can see, the UI reflects the demo-e thing itself. I've also got an NRF 52 board up here, which is my proxy node. That's my 67th, I hope you're counting. And what I'm going to do now is hit scan. This always takes ages and freaks me out. So what's happening now is the web Bluetooth application has asked the browser to find Bluetooth. It freaks me out every time this bit. Bluetooth, low-energy devices that are advertising. Come on. And we'll eventually find this device, which I might need to reset actually because I'm beginning to panic now. Come on. I've a feeling the advertising frequency sort of settles down actually after a while. It's been stuck there doing nothing. So that's an plausible excuse. There it is. So I'm going to select it. So this is web Bluetooth, no mesh at the moment. As far as my web Bluetooth app is concerned, this is just a standard Bluetooth low-energy gap device that I'm now connected to. Now, top right hand side of the screen, it says DST. That's the name of one of the fields in PDUs. It's the destination address. It says FFF right now. That's a special destination address, which means all nodes, which we don't recommend you ever use. So I'm going to use that. It's good for demos. But equally, if I click around on individual panels, it will change. So C1 is top left, C2 top right, and so on. There's the one I've been using, C3. I can select individual columns, as you'd expect, and individual rows. So let's start with the whole panel FFFF and send a generic on-off set unacknowledged message, brackets one. So one means please switch on. And what do you know? They all switched on. I'm not hearing much applause here, people. Was that particularly needy? It was a bit, but thank you so much. So they're all on now. I could muck around with them about at timekeeping. So I need to be a bit careful here. I go off script all the time as well. So there you go. I can switch them all off. Maybe not. It's a work in progress. I'm still testing it. I made this on my kitchen table. Give me a break. So there you go. There's a row. So I'm publishing to specific group addresses. The ones that subscribe to that address are responding to them. So if I go back to all nodes, just for thumb, and switch on. So that was the generic on-off server model that was in play there. Now I'm going to switch to the generic level server model, which actually has more sophistication than you might imagine. So I've got the ability to set levels to absolute values. That's the level set message types. So if I click on my selector here, I don't work this mouse very well. There we go. So now that's reduced the level to some absolute value. I can increase it up to here, or I can decrease it down to one or something like that. We've got deltas. So generic delta set is the message name. I can say by how much I want to increase or select a very tiny increment there that the message is to slowly increment it like so. So that's deltas. And we've got message types called move generic move set. It's the message name. And this is a dynamic transition where I can say, please change by a certain amount, and I've selected big, and do it in a certain time. So an amount in a certain time, that's speed, right? So I'm going to control how fast this transition takes place. And off it goes. So that's a transition to a new state, and you're allowed in the spec to decide whether to wrap around or stop. So I'm going to hit zero now, and sending a message of delta of zero stops the transition. So that's my demo over with. So now back to PowerPoint. There we go. So some theory. You kind of know what Bluetooth message is all about. So Zephyr, again, I assume at the start you all know what it is. It's open source OS intended to allow you to confirm where for all sorts of different devices. Last time I looked, there were 100 different boards currently supported. I suspect that's out of date now. Anyone want to confirm? What's the latest number? 115. Thank you, see. Loads of support from the Linux Foundation. It's very dynamic. I see changes all the time. It's very interesting. And it has a mesh stack, which I was pretty happy about. Pretty well documented. Seem like a natural place for me to go to take a look. I've been dabbling with it like a complete amateur for six months now, but I've gone on OK. So I'm sure you guys will have no trouble at all. So all I want to do now is show you some code fragments, some examples, so you see in essence the kinds of things you're going to need to do. So let's start with node composition. I mentioned earlier on, because I took a drink, you probably looked at the code and said, OK, I see. I don't even need to explain it. I'm basically declaring that hierarchical relationship between the node at the very bottom there, the elements it contains and the models each element contains. So in this case, single node, it has a single element and the element has a number of models declared for it. So we're working with macros quite a lot. There's all these really handy macros that make life nice and easy. At the top where I'm declaring my models, you'll see that there are two of that have special names because there are some mandatory models you always have to have. One is the configuration server model, so you can configure your devices wirelessly, which you want to do. The other is the health server model, which is about diagnostics and fault reporting. The other one is more general purpose and allows me to declare whatever models I've decided to implement and there we have generic on-off server and generic level server. Easy peasy. You also need to map op codes of messages that you might receive to functions that will handle those message types. Again, very logical. So I've used handy macros here to declare the op codes of the ones I'm interested in and given them names. As you can see at the top there, hopefully the names are self-explanatory. Then I've got an array here of BT mesh model op types where I'm basically mapping each of these rows here at the bottom is an op code of a message type that's generic on-off get. The second parameter is the minimum payload length that we expect. This is so the stack can do some validation for you and kind of reject rogue messages and then the name of a function which should be called if one of these messages is received. Moving on, here's what one of those messages, message handling functions looks like. So you get a standard kind of function signature. You can see there's a parameter that's clearly relates to the model, the type of model that's involved here. There's a context which has things like the source address and destination address in it. And there's a network buffer that contains the payload. That's the data that I want to process. Now at this point I've got the Bluetooth spec open. There are actually three specs for mesh. The one I've got open now is called the mesh model spec. That's where all the models are defined or the messages are defined or the states are defined. I know how many bytes to expect minimum in the buffer. I know that subject to some conditions there might be more and so on. So all I'm doing here is I happen to have asked the buffer how long it is and then I'm doing things like calling netBuffSimplePullUH which pulls a single unsigned octet off the buffer for me and I put it in a variable and I do stuff with it. Pretty simple. I've used workacues to serialise my response to messages there in this function. Then what you do starts to get device specific because you need to know what you're going to be doing with your hardware in response to the request to switch on, change the level, change the hue if it's alight and so on. Sending messages, a few more slides to show you the whole of this but it's essentially the same kind of stuff but in reverse, big surprise. So this time around I'm going to create a network buffer which I'll populate with data which constitutes the payload of my message. So a nice handy macro at the bottom there, netBuffSimpleDefine and I do some stuff calculating the length. I've put some comments there to show you how you figure out how long it needs to be or messages have a message integrity code at the end for example, that's four bytes so that's included in my count there. You've got to create a context. That's where things like my network address, my destination address will be. There's also a concept of TTL so multi hop maybe it's a massive building, maybe I could if I wanted to take 100 hops to get to the far corner of the building or to the building next door or something but maybe I really don't want to, maybe I know that every single device that I want this switch to control is right here in this room in direct radio range or at most one hop away so TTL lets me say don't do more than this many hops for efficiency purposes. So that's where I could set that. There's an initialisation call and then I use net buff simple add this time to start to populate my network buffer with the values that I want and again I'm looking at the mesh model spec to know what the structure of this message type is and eventually a presto I've got a function here BT mesh model send was a surprise it sends messages associated with a model. Pretty good naming standard I would say it's fairly clear but it's all quite well documented and it says job done at the bottom now as well good comment. Rights running short of time now so I'm going to talk about security really briefly if you want to talk afterwards I'm here until bedtime as it were so let's start at the beginning Bluetooth mesh networks are secure and cannot be not secure in the sense that you can't switch things on or off with respect to security so device you take out of the box that you just bought is not part of your network until you make it so and so process you go through for every new device called provisioning which is usually followed immediately by something we call configuration and you do this with the same smartphone application that one of the manufacturers gave you all they'll be generalised tools available for that as well. BlueZ already has a generalised tool for provisioning in it so you kind of take your phone out you discover the device and hold provisioning protocols part of the stack point one at the other and the net effect is that the smartphone application equips the new device with a series of security keys and it's possession of one of those keys in particular that makes that device part of your network as opposed to your neighbours network or something like that some headline points about security I mean who here has worked with bluetooth low energy I'm guessing a lot of you okay good one so bluetooth low energy so bluetooth low energy the philosophy's different you are provided with a security toolbox so you can decide to encrypt things different approaches to pairing different association models as they're known and so on but if you choose to you can have no security and the essence of the philosophy is that we the bluetooth sig know nothing about your product the use you're putting bluetooth to the risk model associated with your product and the users and the information involved and so on so the product manufacturer has to do that assessment and decide which of the security toolbox tools to use in that product including none if that's what they think is sensible not the case with bluetooth mesh because you can't let one weak device that's decided I won't bother with that security stuff it's too complicated weaken the security of the whole network so it's all mandatory all messages are both encrypted and authenticated that's AES CCM we separate network network layer security in terms of stack layers now from application layer security so if you consider a PDU some of the fields are from the network layer some of them are application layer stuff to do with the mesh model messages I've been talking about different security keys are used to encrypt them the reason for doing that is it means that or I should explain what an application is an application in the world of bluetooth mesh is whatever you decided is but it's probably going to be examples like lighting air conditioning controlling the blinds that sort of stuff you'll decide which applications your devices are a part of and you'll equip them with keys specific to that application but what it means is that network services like relaying can be carried out by any device because they have the network key which allows them to decrypt part of every PDU but something like a light cannot decrypt messages associated with the air conditioning system it has no business knowing about that application layer stuff and it can't know it because it doesn't have the right keys we can also do things called area isolation you can create subnets and best example think of hotels what we're really doing is cryptographically drawing a boundary around physical areas by having different keys associated with the devices in those physical spaces so you walk into a hotel your smartphone gets provisioned by a front desk that's giving you your key and the ability to control all the smart devices in your room and critically not the room next door so that's what that's about all messages are also subject to an obfuscation process so that stuff like network pattern analysis can't easily reveal patterns and figure out movements of people and things like that, it's like a privacy protection and some of the more obvious attacks like replay attacks that seem still to be used to steal cars from what I'm reading protection against that through sequence very long sequence numbers and trash attacks where you reverse engineer extract keys from discarded devices we have a way of responding to and dealing with other key rotation stuff can take place whenever you need it to and all of the bedrock is secure device provisioning which in a sense bears some resemblance to pairing but you can't do pairing with a mesh network because it's about pairs of secure relationships and you'd be there forever if you had to pair with every possible combination of device in your network but it uses some similar techniques elliptic curve cryptography to protect the kind of key exchange so that was fast so here are the keys that are involved don't often need to know all this stuff but here they are to the network key and some subnet keys that are related to it they define the network your device belongs to application keys for each application and you decide what that means because application keys are mathematically related to the network key so you can't take a network key from one network and use it with another one so every device does have each one of these has its own unique security key only ever used when you're configuring the device it's the only real time when two devices talk directly to each other and to secure that communication is a unique device key and they're all created and given to devices during the provisioning and configuration process ok so I'm not quite behind schedule that's good if you found this remotely interesting and none of you have left yet perhaps the stickers bought your loyalty for a few extra minutes excellent what can you do next? well obviously you can download Zephy because as I said it's a pretty good place to start got some good sample code it's quite well documented for our part if you point your QR codes readers at the screen I've never done this before let's see if it works got lots of reading material and the one I recommend that's just rather hard to read on the screen there is called the Bluetooth Mesh Technology Overview it looks like it's about 20 or 30 pages but really it's only 8 but they put lots of pictures in it to pad it out so in other words it's an easy read it's quite short 8 pages read it on the train you're like ok you get all the concepts if you want to do some hands on stuff we've got two resources for developers we've got the Bluetooth Mesh Developer Study Guide it's quite substantial I think it's 100 pages but it's a series of hands on coding exercises with some theoretical foundational stuff at the beginning and you will build something not far off what I brought today albeit with fewer devices you'll get some real hands on experience again using Zephy the proxy stuff that I did with web Bluetooth that's what you learn about in the Mesh Proxy Kit and to make that work with this demo I more or less took that code I don't think I found this is so unlike me I don't think I found anything in the tutorial that like didn't work when I tried it in a real device so so there you go that seems to be a fairly good example of how the proxy communication protocol works and that my friend plural I'm hoping there's more than one brings me to one minute from the end so thank you for listening does anyone have any quick questions yes sir so the question for the video was have we done any comparisons with ZigBee particularly asking about power consumption there so we at the Bluetooth SIG have done no comparisons with respect to power consumption because that would be more of an implementation type thing I think and you probably better off talking to people like Nordic about that we have of course done some thinking about differences at the level of the specification and the one I know very little about ZigBee I'll say that right now but one that I point to straight away is the reliance on 802.15.4 makes the radio quite slow 250k bits per second Bluetooth mesh relies on Bluetooth low energy 4.0 or later such 1 megabit per second Bluetooth 5 you may know can go at 2 megabits per second but we don't require a Bluetooth 5 stack Bluetooth 4 is enough but that's four times faster and the packets I believe are significantly smaller than those used by ZigBee and consequently the comments I made right at the very beginning about scalability being the devil's in the detail right it's all about how you use that radio medium at the end of the day you use it for a very short amount of time to get a lot of work done with a very richly encoded but highly compressed packet that's the approach we've taken beyond that I don't know I'll tell you what though I did find a paper someone else has done it if you google for a tail I can't remember if I'm on the wifi let's try it a tail of not cities not Charles Dickens he knew nothing about bluetooth mesh as far as I know a tail of five protocols so you need to kick me off if I keep talking by the way and that would be fine I wouldn't be offended so this is a really interesting paper it does a comparative evaluation in summary form of ZigBee, Z-Wave, Threads can't remember probably some other stuff in there but the interesting story is that the company that did this at the time that they did this work were completely agnostic and they make components for commercial lights and they wanted to find the right wireless communications technology for commercial lighting systems that are very demanding way more than residential stuff that we have at home very large numbers of devices very stringent reliability requirements and security so they looked at all of them concluded there wasn't anything that met their requirements there are things like I get the mix of others ZigBee or Z-Wave, one of them has a restriction that you can't transmit more than nine messages on the second window not good enough for power consumption ask any of the implementers people like that will know more than I do all I was going to say was they concluded there was nothing available at that time that met their requirements for high end commercial lighting control so they joined the bluetooth special interest group they proposed bluetooth mesh with some others ultimately the CTO from this company became the chair of the mesh working group spent three years working on it produced it their entire building is now a mesh network hundreds and hundreds of devices loads of bluetooth in the environment mice, keyboards and so on so that's why they did this but the background is that they were completely agnostic and just thought there is nothing that meets the high end scalability and security needs of commercial systems so it's a very good read, it's quite short as well it's pretty easy one last short question one more question 64 nodes and it works pretty well what is the capacity of such mesh network it's my favourite question so I hope you all heard that, how many nodes can I have, I've been asked that one before which I really like, by the way it's 67 64, 65, 66 and the web application itself is part of my network because it's been provisioned so short answer with little value is 32,767 that's the maximum number of nodes you can have in a single bluetooth mesh network but then, our brains kick into gear and we start to ask questions about density verbosity, how much messaging is going on, is it sensors that are communicating a lot all the time is it light switches that get pressed once a day entirely different scenarios so if you were for example to google for I don't know if I'll find it here on our websites this thing is called putting the large in large scale or some horrible title excellent title that one of my colleagues thought of so this thing is on our blog it's a fairly lengthy examination of that question which I'd recommend you read and yes I did write it so I take all blame it's a fairly extensive examination of the question first of all let's try and ask the right question about scalability in mesh networks what's the real question because the number is 32767 but all of them in this room all talking every 50 milliseconds entirely different proposition to more realistic scenarios so yeah I'd recommend you read that look it's got pictures as well and that I think is probably it so listen thanks a lot for your time thanks for listening and if you want to talk more I'll be outside