 Mae'n arweinio iddo i'r pwrddwyr ymlaen chi. Mae'r pethau sydd wedi'i'n gwybod iawn yn gyffredinol yn y bwysig i'r cyfnod ymlaen i mewn profesiol i ymlaen i'r ffordd. A hynny oedd y pethau yn ymlaen i'n gwybod i'r reitio i mi, ond mae ydyn nhw'n fathaf. Mae'n ddiwrnod. Felly mae'n ddiwrnod! Mae'n ddweud! Mae'n ddweud i'r wneud i'r bwysig, i'r anodd i'n ddweud yn dweud, ond rwy'n dweud ei wneud am ystod. So, mae'n ddweud eich bod ni'n meddwl ar gyfer y gwaith. Rwy'n agor i'r peirchaf y cysylltu. Rwy'n i'n meddwl, ond mae'n ddweud itfau. Fel rhai arall, rwy'n meddwl, rwy'n meddwl ar gyfer. Rwy'n meddwl. Rwy'n meddwl. Rwy'n meddwl. Rwy'n meddwl ar gyfer y gallwn, ac rwy'n meddwl i'n meddwl i'r meddwl. ac mae'r prynhwys eich gwybodaeth ein bod ni'n ffordd a'r lawr ac mae'r cyfrannu a'r ysgol yw wedi'u gyrstyn fel y byddai chi wedi gweld y Cymru a'r ysbrydill ac mae angen i'r wrtho'r ysgol yn gydybi'r arser ac mae'n mfartyn ac rwy'n gyfer ar gyfer ar y bleut collaborations yng Nghyrch Gwybeth Gwyrd oherwydd, mae'r gwaith y dylunio yma i bleutydd technologi. Felly, rydyn ni'n ddaraf i ddweud beth o'r cyfrannnol gyda'r cyairyig yr un i'r cyfrannnol rydynrif Onw. So if I'm talking here about Bluetooth mesh with a bit of a nod to zipher, see a bit of code later on, I'm talking this afternoon about a much newer Bluetooth feature which is Rageo Direction Finding and Location Services at 225. So, lots to cover. Let's make a start. Just to get orientated then. There are kind of three main Bluetooth technologies now. Bredr, sy'n bwysig rhagwyr cyntaf gan data gwahaniaeth. Mae'r bwysig yw'r original Bluetooth. Bluetooth yn y ffordd yw 20 yma, felly mae'r ffordd yn ddweud. Mae'n rhewb bod yn gwneud yn gwneud rwy'r ddweud o ddataeth gyda'r un modd a'r ddweud, rwy'r ddweud i gael unig ddyfyn sy'n ddweud o ddweud o ddweud o'r ddweud, ddweud o'r ddweud o ddweud o ddweud o ddweud. Bluetooth yn ddweud o ddweud o ddweud, Can of can do the same things, it can do point to point connections, but it can also broadcast so that's connectionless communication, something I'll mention later on in the context of Bluetooth mesh. Of course it's very power efficient, it's a low power wireless communication technology that's the category. And then we have this thing called Bluetooth mesh, the specification for which was released two years ago. It's not a wireless communication technology, it's a networking stack which uses Bluetooth low energy for radio communications. Talk more about that in a moment. I think there are something like 200 Bluetooth mesh products certified now which is actually huge in that sort of time period relative to other things I've seen in the market with other technologies. So press this button, thank you, naughty laptop wasn't behaving, there we go. So let's start here. It's kind of almost not valid now to talk about the Bluetooth stack because in fact there are several standard configurations of stack that we have in the spec and the one on screen right now is the one you have on your smart phones and in things like smart watches and activity trackers and heart rate monitors and those kinds of kind of connectable Bluetooth devices. As always the architecture breaks down into two major parts, we've got a controller at the bottom, there are choices of controllers, that's the Bluetooth low energy controller. In this case it takes care of stuff, interfaces directly with the radio takes care of analog things such as modulation schemes blah blah blah and then the other major architectural component is called the host. In this case you can see layers from the Bluetooth stack which enable communication and interaction with those connectable devices like activity trackers. Who's worked with Bluetooth low energy maybe on projects? So quite a few of you are already familiar with terms like gap and gap and act. These are acronyms from that variant of the Bluetooth stack. So that's what you do have on devices like phones. What you don't have though is this variant of the stack, this is Bluetooth mesh. So all of the Bluetooth mesh stack layers live inside the host and there they are depicted on screen. If you're a stack developer you're interested in all of them and you will need to read the spec. If you're a developer who creates firmware for products then you're probably mostly interested in the very top of the stack, you'll be working with things called models, talk more about that in a moment. Importantly down at the bottom of the stack we have bearers and they define how Bluetooth low energies controller is used for radio communication and there's a couple of different bearers defined today with possibilities for the future to do other things. Some mesh devices have both these stack variants and we'll see that hopefully later on. So when I start you off kind of assuming that it's in use subject for you with some basic concepts starting with some sort of network level things, some terminology and kind of network level behaviours. So three words all start with multi so remember that for the test that follows, multi hop, multi path and multi cast. Everything's message oriented so devices communicate with each other by sending messages. There are lots of types of messages that are all in a spec as you'd expect. But messages can travel right across the network far further than radio range would normally suggest. So normally we're constrained by the range that our radio has for wireless communication but in a mesh network messages hop across the network from device to device to device process called relaying which I'll talk more about in a moment. So that gives us enormous coverage. We can have big networks containing up to 32,000 plus devices covering very large areas, whole buildings, buildings like this one, collections of buildings, maybe even neighbourhoods. I know someone working on a project looking at Bluetooth mesh in a neighbourhood context. So that's multi hop gives us very, very wide coverage. We can do up to 127 hops by the way and the point to point range between devices is far larger than you perhaps think it is. If you look at bluetooth.com today you'll see we've got a thing going on, looking to dispel myths about Bluetooth and range. It's not 20 metres, it's over a kilometre these days okay. Not saying you'll get that in a building but the basic building blocks relating to range are very, very positive, very healthy with Bluetooth these days. So we can do up to 127 hops but you can control that. You wouldn't want all your messages travelling all the way across the network so you can configure kind of maximum number of hops and you can control that from code as well. If I was controlling, I was programming a switch to control all the lights in this room they're almost certainly all in direct range so I actually don't want any hopping to take place at all so I can make sure that's the case. Oh sorry. So that was multi hop. Multi hop actually is about reliability. Like any networking technology you kind of have to do some thinking about network design. It's not too hard to be honest with the Bluetooth mesh network but one of the things you'll do is think about reliability and with not a great deal of brain power required your network will work such that without any extra effort on the part of the developer and without centralised complex routing tables multiple copies of every message sent will travel via different paths through the network to the destination devices that are being targeted. So this gives us kind of redundancy. One of those paths is broken not a problem because one of the other copies will make it through one of the other paths to its destination and when duplicates arrive the first is acted upon the rest just get ignored. Multi cast means exactly what it always means. This is about one device addressing multiple devices. It's going to be quite a complex engineering problem in the world of wireless communication. Read RFC and I'm looking at my notes here 3170 because I can never remember the number 3170 that's IP multicast applications it's got nothing to do with Bluetooth but it does lay out some of the problems to do with multicast communication really really nicely. Bluetooth takes a really interesting approach to multicast communication in mesh networking and in fact it's kind of assumed that all operations are multicast apart from a small number. Ty systems built around this idea multicast communication gives you immense scalability. Your probably number one constraint in scaling a wireless mesh network concerns how efficiently or otherwise you use the radio spectrum. How long you're occupying a frequency for such that some operation is initiated in the network. So big messages transmitted slowly are going to occupy a frequency for a long time stop other devices from communicating during that time slot. Small highly optimized messages transmitted quickly through the air with a very fast symbol rate which Bluetooth has and addressing multiple devices all in one hit that's how you get best scalability. One tiny message to control all the lights in this room. So that's about scalability. We talk about individual devices now. So devices that are members of our network in terms of terminology. We call them nodes. I'll tell you how they become a member later on. And we don't really have any special kind of black box networking devices defined or needed in the world of Bluetooth mesh. There's some special roles that devices can have providing network services various sorts within the network but it's all software. So in principle any device running a Bluetooth mesh stack through configuration can be told we want you to have this particular special role in the network please. Four of them in the first one I've kind of hinted at already and that's the relay. So that multi hop capability where we hop across the network. That's a consequence of devices acting as relays. And actually so is multi path. All the relay does is it will receive any mesh communication going on that's in range of it in terms of radio range and it will repeat it it'll broadcast it again. I've got two relays different ends of this room maybe. That are in range of every transmitting device in this room. They'll both retransmit the messages they receive. And that's how we get multi path. It's really really simple but very effective. The point is we don't need routing tables to be centrally maintained and replicated across the network and fixed when they break which is how some other things do it. It's a whole world of complexity. One issue with relays. Some of you probably already thinking is that given the importance of looking after our finite radio spectrum. Relays of course repeat things that they hear. So they're going to use some of your radio spectrum. So you don't have too many of them. Rough rule of thumb. Five percent of your nodes are probably going to be relays but you have to figure that out on a case by case basis. Too many. It's not going to scale well. You kind of create a little storm if you're not careful. Next two roles kind of work together. We've got things for low power nodes and friends. Again, this is a configuration flag you switch on on devices that you choose. The point here is that some devices are going to be kind of very power poor. Maybe they run off batteries. Others will be what we call power rich. They're connected to the mains, to the grid. Power availability not a problem. The power poor devices. In some situations, not relating to Bluetooth mesh, maybe we don't have to worry about that too much because they only use the radio, which is what uses our power occasionally. They transmit a message twice a year. We're not generally worried about devices like that but in the context of Bluetooth mesh, we still are. Because even those devices need to be able to receive messages from across the network. There are system messages flowing around the network from time to time, for example. Consequently, the radio has to be on in receive mode. Some proportion of the time such that messages can be received and that's going to use power. So it's seemingly a dilemma. How do we take a power efficient approach to power poor devices that are perhaps battery powered? And the answer comes through this thing called friendship. I kid you not, that is the technical term, it's in the spec. So you, in setting up your network, will designate some devices as low power nodes and some as friends, meaning devices that are not power poor and can lend some assistance to the low power nodes. And the stack defines a protocol whereby when you first switch on your low power node, it can dynamically discover nodes that are friends and which are in range. They have a little conversation, establish a relationship called friendship and after that point, the two work together with the friend doing the heavy lifting. The low power node goes to sleep, its radio is now off using next to no power, doing whatever it needs to do, excuse me. And then any messages that need to be delivered to the low power node, in this case I've got a sensor, actually get delivered to the friend where they're stored for safe keeping and according to some frequency you configure, maybe once a day, the low power node is going to wake up, switch its radio on, use the protocol to send a message to its friend to say, have you got any messages stored for me? Stay awake, now in receive mode, those messages get delivered back. I'll now go back to sleep again. So that's how low power nodes and friends work together so that power can be efficiently used. So our last role is called the proxy and I kind of hinted at proxies earlier on because proxies, excuse me as I walk away from the microphone and keep talking, proxies are the type of Bluetooth mesh device that have both of those stack variants that I showed you at the beginning on them. They both support the world of gaps, gap and the attribute protocol which are connectable devices used which are smartphone support which my laptop supports and so on and they have a mesh stack on them as well. Bit more memory needed but they are dual role and consequently proxy nodes which can either be dedicated devices or it could be something convenient like a light can provide a kind of interface from one version of Bluetooth to the other and in fact there's a protocol called the proxy protocol that lets me encapsulate mesh network PDUs inside these proxy things which I can write to my proxy device. It unwraps them and relays them into the mesh network and vice versa. If you're familiar with Bluetooth notifications mesh messages will be turned into notifications by your proxy and delivered to the connected Bluetooth device, your smartphone, your laptop or whatever. Sometimes we need graphical user interfaces as part of our mesh network not tiny micro controller stuff. We need people to be able to monitor and control systems in industry and smart buildings or wherever our network has been deployed. So communication interaction again already hinted at some of this stuff. Again it's all message oriented so there are several specifications three in total actually that cover the entirety of Bluetooth mesh. One of them defines things called models which I'll come on to. Messages and states. So states are data items that have names, take certain values, reflect some aspect of a device. Messages act upon those state values so for every state type that there is in the spec there are at least or there are four message types defined. The four types are set which of course lets me change a given state in one or more remote devices so the simplest example is on off. There's a state called generic on off. If I send a set message a generic on off set message I can change the state of remote target devices from off to on from on to off. Simple stuff, right? There are get messages which let me query the state of remote devices and they will reply with a status message that contains that value. You can send status messages anytime you want just to report your state and so on. So that's three but in fact there are two types of set message which gives us our four because we have acknowledged set messages if I send one of those I'm going to get a reply to confirm it was received and acted upon that reply is a status message but I also have set unacknowledged messages where I send my message and I get no reply. Now I'm fairly sure everyone who's ever worked with a protocol has worked with a request response style protocol that's the most common form that they are from HTTP onwards. So you might assume that that's what we use in Bluetooth mesh but in actual fact it's not it's rare that you use acknowledged messages. Generally speaking you're going to use unacknowledged messages and as briefly as I can here's the reason. Complexity grows very, very rapidly in mesh networking especially with multicast operations. If I flick a switch on the wall to switch all the lights in this room for example and how many lights there are in here let's say there are 50 and I send an acknowledged message I will get 50 acknowledgements back assuming all those messages are received and acted upon the first time around. That's immediately that's a spike in traffic. Of course I might not receive responses from all of them so I'm going to have to have some timeout processing now while I wait. I'm also going to need to know the identities of every device that I expected to respond to that message so that's information I have to have somewhere. Hmm okay getting a bit more complicated and having realised after my 10 second timeout window or whatever that three of them didn't reply I now need some kind of retry logic and the same it kind of repeats itself. So very quickly complexity scales and we start to eat bandwidth really quickly you can generate storms very, very quickly indeed if you're not careful. Read that RFC which is not about Bluetooth but it talks about all this stuff. So we take a different approach because one of the kind of subject headings here is reliability how do I know it worked? Well you don't have to know that it worked. What you have to do is take steps to ensure that it almost certainly does. Whilst communication that's the best you can ever hope for almost certainly okay there's always going to be a probability that communication fails. Someone could have half a dozen microwave ovens switched on with the door open saturating that part of the radio spectrum you might find your stuff doesn't work anymore okay. So we take a probabilistic is that how you say it? Probabilistic stochastic I can say that kind of approach to reliability here and low down in the stack at the network layer you can configure your device to send the same message handed from higher in the stack multiple times maybe two times maybe three times in rapid succession maybe with 20 or 160 millisecond gaps between them and here's what that does. Imagine and these are not real numbers but imagine the probability of my message not being received is 0.01% because usually they are but there's a small probability. Consecwntly the probability that the original message and the duplicate follow it's followed by very quickly also not being received is 0.01 squared. Ooh small number now if I send two duplicates it becomes a really small number and all we're looking for really is a kind of fit for purpose degree of reliability. Think about availability figures for big systems used to talk about five nines availability in the world of high availability systems blah blah blah never entirely sure how anyone ever proved this stuff but that was the mindset and the mindset I suppose is similar here but this is a simple approach that's effective I'm going to do a demonstration later it's called the kiss of death saying all these things effective and doesn't consume loads of bandwidth. So states acted upon by messages is where we got to. There's an addressing scheme so each device has a unique address as you'd expect but we hardly ever use them. There are also group addresses that identify collections or sets of devices. Those are the ones we use even when we think there's only one member in that set. We use a publish and subscribe system this means that sending devices know nothing about the recipients of their messages. I refer the learned audience back to my comments earlier about complexity and managing acknowledgements and stuff you need to know who's receiving your messages. We don't. When I configure my light switch I'm going to use lighting as an example because we all know about lighting. I'm going to say when the button's pressed you're going to transmit or publish a message to this group address. Meanwhile, when I set up all of my lights through a process called provisioning and configuration they will be subscribed to that same address. All that means is that they will listen and respond to messages with that address on them. They don't know where they're coming from. They have no idea where the 10 switches might send those messages to that address or just one. They're completely decoupled, which is great because I can make changes without having to reconfigure, change loads of things, maybe wait overnight for tables to rebuild. There's one mesh networking technology that does that. Not good, okay? Bad enough in a domestic context but this is really for big commercial buildings. You can't have that. Hotels can have tens of thousands of lights. So that's how addressing works. Let's look a bit more closely at nodes. I'm slightly concerned about time. So nodes are things, devices that are members of our network but nodes can have more than one addressable part and we call those things elements. And again, every device does have a unique address. It's a 16-bit number. That address belongs to the element or elements your node has. Now sitting inside each element we have things called models. Models are actually standard software components. It's standard in the sense that they're defined by our specification. They do one thing. They take care of one type of operation, handling on-offs, changing levels, changing colours, those sorts of things. That's what models define. They define the behaviours, the message types associated with them and the states that represent the various conditions associated with that aspect of the device. There's an example. So we've got a big LED unit there. That would be one node in my network but it's got three elements because the individual LEDs are individually controllable. Okay? Make sense? So in my code, I'm going to have some sort of structure that defines my node and the fact that it has three elements and that each element implements two particular models. In this case I've got the generic on-off server model. Yes, we have clients and servers. Clients don't have any state values. They just send messages. Servers contain state. But I've also got the light-likeness server model because that's to do with brightness control and my LEDs are dimable. So as a kind of firmware developer working with product management, you're looking at equipping products with certain behaviours. Those behaviours are a consequence of the models the device has, which you will either implement in code or your vendor will have implemented them for you and you'll just be adding the device-specific stuff in response to messages that model has associated with it. So security. Absolutely no time to talk about this subject properly. It's at least two or three presentations in its own right, but here's a summary. Take a device out of the box that you just bought from Amazon or some other shop. It's not a member of your mesh network. It's just a thing, a device. To turn it into a member of your network, you go through a process called provisioning, which usually involves a smartphone application or something like that. What actually happens is you equip over a secure communication channel, the new device with a number of security keys, one of which is called the network key. Possession of that key is what makes it part of your network. There are other keys as well I'll kind of come on to in the next slide. So that's provisioning. Analogus to pairing, but it isn't pairing. Imagine if you had to pair every member of your 32,000 node network with every other member of your 32,000 node network. It would take quite a long time. So a new process called provisioning. Some bullet points on security to tax my technical knowledge and public speaking skills. But number one, it's mandatory. With the other Bluetooth stuff that's on the stack diagram earlier on, it's not mandatory. It's up to manufacturers to decide what security features they use for their products because they understand it and the context it's used in and the threats. Bluetooth mesh is mandatory so everybody has to do the same thing. You can't have one device coming in with weak security and ruining the security of the whole network. All messages are encrypted and authenticated. That's AESCCM. We've got separate sets of security keys that encrypt network layer related fields in PDUs and application layer PDUs. So in the context of a Bluetooth mesh network an application is anything you want it to be but it's things like lighting, air conditioning, heating, again smart building example to you decide and you make devices part of applications by giving them appropriate application keys that you've created during the whole setup process. You can do things like area isolation, quite like this one. So with different subnet keys you can kind of draw cryptographic boundaries around physical areas. So think about rooms in hotels. You can issue different network subnet keys for different rooms. You know when you check in your phone gets issues with some stuff you can control the smart devices in your room but not the devices in the room next door. Hopefully that's the idea. All messages have some head of stuff that's not encrypted, has to stay that way but we do obfuscate it so that any kind of pattern analysis to try and track patterns of behaviour maybe track people in the network won't work very difficult to do thanks to that obfuscation. There's protection against some of the standard things like replay attacks, trash can attacks and so on. And it all derives from that first thing that you do which is provisioning, that's how devices get their keys and everything stems from there. It's demonstration time. I've managed very well too to completely clear my mind of the horror of demonstrations. So I've got this thing. Let me quickly introduce it because I'm really short of time now. 16 independent devices here with the Bluetooth module inside them running Zephyr. I'm assuming everyone knows what Zephyr is. Open source, embedded OS framework whatever you want to call it with Bluetooth mesh stack and some associated APIs. So the mesh stack is doing all the things that it does. I've implemented the kind of models and I've implemented the generic on-off server model because there were some LEDs I want to switch on and off and the light HSL server model. HSL of course is huge saturation and lightness. It's a colour scheme. The coloured LEDs I'd quite like to change the colour of the LEDs. This has got the generic on-off clients on it and it's got two buttons one of which I've programmed to send generic on-off set unacknowledged brackets one which means switch on and the same bracket zero which means switch off. And oh look, it works. Okay, well I'm pleased. And press that one and they all go off. Now in terms of addresses every node in my network has been subscribed to three addresses because this is how I decided I wanted to do it. There's an address that every node has subscribed to so that's a whole panel and then each node subscribes to a distinct address for the column it's in and the row that it's in. So I'm transmitting here to the all panel address. What I've also got and I've just realised I haven't switched it on so I'm doing that now is a device that actually is only acting as a proxy so in a way it's a black box and I'll quickly show you this if I can. So this is a web application. If you're looking at a web page here I've used the web Bluetooth JavaScript APIs. Hopefully it's going to discover that thing. This always freaks me out at this part. There we go. So it's found my proxy which as far as it's concerned is a Bluetooth device with the gap and at layers that we saw earlier on. I've just hopefully connected to it. I have. So now I can start injecting messages into the network and if you look at the top right there, DST that's one of the fields in PDUs and the destination address. By clicking around I can change it. That's the all nodes address. How do you press to there you go? And switch off. If I click on a column, that's boring, let's do that one. Then only that column should respond and it did. I click on a row. I can just switch on that row. So you can see how the publish and subscribe stuff works and I can change colours, stay with that row. There we go. This is the light HSL server model isn't that thrilling? I'm quite thrilled. I can tell that you are too. Disconnects moving swiftly on. I think we've got a bit of a 20 minute buffer after my talk actually so maybe I'll just steal that. So joyous news, the demo works. Let's look at code now. So obviously now this is straying out of my world really. We're a standards organisation. We don't define APIs or products or software or any of that kind of stuff. But I've mucked around with Zephyr quite a lot, I think is the right way of saying it. And we have some educational resources that we based on Zephyr kind of like a lot about it, not least of which is the fact that it's hardware agnostic. You can build for lots and lots and lots of different boards. I want to say about 200. Someone in the audience correct me. Is it around 200 now, anyone? Not looking at anyone in particular. Thank you, someone gave me a thumbs up to loads of different boards, different hardware manufacturers supported. We are like Switzerland. We have no favourites. So this works well in terms of my kind of diplomacy. Just give you a sense of what coding looks like here. So if we start here, this is this kind of node composition stuff. And if you look at the code from the bottom up, I've got, so you've got lots of data types and structs and macros that you work with in Zephyr. So at the bottom here, I'm defining essentially my nodes. So this is kind of the kind of root of my node composition hierarchy. And it's saying that my node consists of an array of elements. And if we look at the elements array above it, I've defined actually only one element. So I've got a single element. There's only one addressable part in each of these devices. That element though comprises a list of an array of models. If we go to the models array above it, you'll see that I'm using various macros to define models. Now there are some system models defined in the spec. We call them foundation models. There's the configuration server model. That's what lets you configure your device. And there's the health server model, which is about fault reporting. And then there's other stuff for which we have a macro called btmesh model. And you can probably see there I've defined the generic on off server model and the generic level server model. Now, all well and good, but I need to map message op codes that uniquely define individual message type to functions that will handle them, which is partly what I'm doing with the highlighted reference in that code. So if we move on to the next slide there, you'll see that I've got some constants defined. Again, using some nice macros, you can see that message op codes are 16 bit values. Again, you get all the numbers from the spec. And then sitting underneath that for particular model highlighted on the previous slide, I've listed functions which must be called if we receive a message with this op code. So that's how we kind of route inbound messages by op code and model to functions which then respond to them. And this is where it gets implementation specific because you now need to decide what it is you're going to do in response to receiving that message. So we have various nice Zephyr APIs available to us. Your stuff arrives in a network buffer, so you're going to use the network buffer APIs. You're going to have the Bluetooth mesh models specification open at page whatever so you can see the message structure. You'll use the network buffer APIs to take fields according to their size and type out of the network buffer. And once you've got them set up in variables, you then initiate some work to respond. And I've used a worker so I don't block the main threads too to get that done. Sending messages is pretty much the same, but in reverse. So I'm going to populate a network buffer with the fields that my message must contain to be a valid mesh message. And again, I'm consulting the spec to know what that means. So I'm creating a network buffer at the bottom of the slide there. And then I'm populating it with some messages down at the bottom with things like NetBuff Simple Add U8 unsigned 8-bit integer down at the bottom there. We've also got a context that we need to define which has various parameters in it. If you can read at the back, we've got NetIDX and AppIDX. These are actually indexes two various security keys which I've registered in code you haven't seen. I could have lots of different security keys for lots of different applications, lots of different subnets. I have to say which ones I want to be used to encrypt the different parts of my PDU. So I'm saying that there in my context. I'm also setting the destination address for my message. And TTL is the name of the field which controls how many hops maximum we'll do across the network. If I know nothing's more than one hop out of range, then when I configure my switch, I'm going to say by default, set TTL to one so you only do one hop. And what I'm saying in the code there is use the default, it's fine, but I could override it in my code if I wanted to. Maybe there's some conditional stuff that I wanted to do. So that's sending messages. And there's the actual send message there. Sorry, my last slide on that subject. BTMeshModelSends, brackets and parameters, message send. The whole point here is not to absorb the detail. It's hopefully to go, oh, that looks quite easy because it's quite rational, quite... There's a learning curve regarding some of the concepts, but putting it into practice isn't hard and Zephyr ships with loads of samples for all sorts of things, including all supported flavours of Bluetooth, which of course includes mesh. So there's some good stuff in there to help you get started. That said, it's not your only source of information because we've got some stuff as well. So our website is www.bluetooth.com, which I'm sure you can all remember. Highly recommended, if you click on resources, then study guides, that's the term we use for developer resources, which actually will come on to in a moment. But we've got some papers picked out a couple for you here. One is the Bluetooth mesh networking intro for developers. It's sort of the stuff I've been talking about, but more. It might look like it's 20-odd pages, but I think mostly it's pictures. I think in reality it's like eight pages. You'll read it on the train in half an hour and it's like, oh, okay. Pretty good place to start. The mesh model's technical overview focuses specifically on models. It's like, what models do we have? What have we defined? What do I need to know to understand them? You just read the bits that make or of interest to you. Ultimately, you've got to read the spec or at least parts of it. That's where you absolutely have to go. This should make it easier. If you want hands-on practice, two things. We've got the Bluetooth mesh developer study guide, is what we call it. That's the one on the left. Click on, again, resources study guides. You'll see it there. We'll do some coding, a whole series of projects, all based on Zeffa, slightly out of date Zeffa, actually, which I need to update. Guilty conscience forcing me to confess to you all there, but I'll get to that, I promise. And there's also a resource specifically about the proxy function, which I use to make my web Bluetooth application. And in fact, all the code for that demo is in there. I'm being bombed by an insect here. All the code for that demo application is there and also an iOS smartphone application, which does the same thing. So lots of stuff to help you make progress up the learning curve with Bluetooth mesh. And that, my friend, is slightly out of time on time, a terrible human being, but I did give you a sticker. Is it for me? Thank you very much for listening. I don't know if we have time for questions. Let's do questions unless somebody tells us to stop. Shall we do that? Yes. I don't know. I've got no idea how this works, but I'm happy to repeat the questions. Or you could come up here. Come up here. What is the current support of Bluetooth mesh in upstream Linux kernel, if you know? Oh, I'm going to say it's partially supported, but I'm not good to answer this question. However, I do happen to know somebody in the audience who probably absolutely does know. Without wishing to single him out, would anyone like to volunteer and answer to that question is better than mine? Yohan. See, wasn't that a good answer? See, I knew he was going to be here. And secretly we arranged this whole thing. It's good to have someone in the audience who knows what they're talking about. Thank you very much. Anyone else got a question? Who knows? I might know the answer. Might not. Yeah, at the back. All right, no, it wasn't. So the moving parts in this demo, is that on screen? Is that on screen at the moment? Yeah, so the moving parts here is, I have a web page, HTML, CSS, JavaScript, like always. That happens, I couldn't have opened it from the file system. I have a local web server, okay? I'm using an API, which is not supported by all browsers. It's Googler driving it, so it's in Chrome on everything except iOS. And it's in Samsung's browser and it might materialize in Microsoft's new browser soon. It's called Web Bluetooth. So it's not for mesh. It's for those other types. Those are the categories of Bluetooth devices. Let's me discover, connect to, and then interact with connectable devices, of which this is one. So this is a Zephyr device, and it's got both of those snap variants on it. So as a kind of connectable Bluetooth device, it's advertising, that's broadcasting package, to say hello, I am here, and this is what kind of device I am. The advertising packets actually include a 16-bit ID that says I'm a mesh proxy. So my web Bluetooth app is scanning for those packets, finding them. That's the first thing I did when I clicked the button at the top, I'm currently connected already. Once I've formed that connection, in my code, which I won't show you because we'll get kicked out of the room in a moment, I am creating mesh network PDUs. I am encrypting them in the required way using some JavaScript APIs. My application has the network and application keys. It's been provisioned manually, by which I mean, in this case, I hard-coded them. Yes, I'm a bad person. You wouldn't do that in real life. You can see them in my... If you do show source, you'll see my security keys there, so that's not how you do it, but it's a demo. And then I'm wrapping what is essentially a byte array with some encrypted parts in another layer of protocol called the proxy protocol, and I'm writing it to my proxy device. There's a write operation supported by GAT. And proxy devices will take the contents of GAT rights, unwrap the proxy PDU layer, take out the mesh networking PDU and relay it. That's how that works. So no web server in here. I hope that made sense, but the code's available. Anyone else? Do I have to stop yet? Yes. Could you repeat that please, a bit louder? Yes, it can, yes. Of the four roles, you can be all four or none, or anything in between. It's a software configuration flag subject to implementation limitations. Some devices won't allow you to... Proxies need more memory, for example, so I did try to make a proxy out of one of these things once, and they have 16k ram, and it didn't work. I couldn't do it, so... But aside from implementation constraints, yes, you can have multi-roll nodes. Anyone else? Yes? Yes and no. So the question was about limits regarding power consumption or network congestion. So now we're outside the spec. We don't specify anything about power consumption. That's an implementation issue. So really you need to look at products or modules from vendors to really get a good answer to that question. Probably best up and give you on that one. Network congestion, there's some benchmarking data available. I think Ericsson did a lot of benchmarking, which you'll find on our websites. I've done some, but only with small networks, 64 nodes I did some stuff with, but that's all I've got. I have to say anecdotally, my impression is that Bluetooth mesh scales way beyond the other usual suspects. There are other low-power mesh networking technologies. I'm not an expert in any of them, but anecdotally. Because I get asked questions like, oh, we did some stuff with XYZ mesh networking technology, and we started to struggle when we had more than 10 devices. I'm like, oh dear, yeah, that sounds pitiful. This was designed for commercial buildings in the first instance. Those are the large-scale networks, as opposed to going smart home, residential sector, 10, possibly 11 devices to control, one is a thermostat, and then trying to make whatever you come up with work on large-scale, and they did it the other way around. I think it scales pretty well. I'm feeling like I'm probably supposed to be stopping any moment now, but again, we'll keep going, yes? What will yes and no, so first of all to be pedantic, which of course is our job as engineers, and there are no routers or even routers, so there are no things like that in a Bluetooth mesh network, and there is no routing, okay? It's the relay process and the published subscriber thing that, yeah, forgive me. I know you know that, you were listening. But can you buy certified, qualified Bluetooth mesh products? Absolutely. So I was at an event in Paris in, I think it was February this year, and someone did a presentation on one of the other mesh networking technologies which is older than Bluetooth mesh. I'm not going to name it because I kind of don't like being mean about the competition. At that time, there were two qualified products for it, and it's older than Bluetooth mesh. We've got over 200 now, which might not sound a lot. The spec came out two years ago. People have to read it. They have to discuss with product management. They have to think about new products or impact on product roadmap. Schedule engineering sources, eventually, stuff starts coming out, so stuff's coming out. So I think it's growing. I always get mixed up with exponentially. Yeah, I think it's one of those words. Logarithmically, yeah, I think it's exponential. That's that one. So they're sort of doubling every three months, I want to say. I think that's what we've been seeing. So it's growing quite quickly. But you know, as always, we'll see what happens. The market decides. Yes. Good point. Yeah, thank you. That's a really good point. So in a sense, despite being new in the context of standardisation processes, which can be quite lengthy, it's actually maturing very quickly, I think it's fair to say. I think people are coming in for the next talk, and I'm still here. So I'm going to stop now. If that's OK with you guys, thanks for the questions. But I'm not disappearing. If you want to talk more, I'll look outside until it seems I don't need to look anymore. Thank you again. Cheers.