 Okay, in this section we're going to take a look at the laura theory or the ST part of the laura theory. Remember, Sentech control half of the laura theory because it's all related to the radio and the modulation side. So we don't have all those details as it's still protected IP. So we're only looking at the elements where ST can actually control and make an influence with the laura theory. So what we're going to look at in this section is the modulation method that laura is using. We're going to have a look at the physical layer that we send the information over. We're going to have a look at the end node classes. So the different classes that we have available within the laura protocol for types of end nodes. We'll have a quick look at the security side so that you can see what passwords and keys are needed. And we'll also take a look at how an end node will join a network or gets activated on a network. So if you look at the various communication technologies that are available today. We've got the high data rate technologies, so Bluetooth, Wi-Fi and all the cellular technologies. Bluetooth and Wi-Fi are the short range variants but high data rates. Cellular are longer distances, high data rates. Then in the short range area, we have low data rate. We've got Bluetooth, low energy, Zigbee, NFC. And then in the longer low data rate arena, we've got laura and sigfox. So we're focusing on this area of 1 to 5 kilometers, potentially up to 10 or 15 kilometers depending on the environment. Where we can send 5 kilobits per second, something like that. So this is the area where we're going to be involved in for the laura type applications. This particular frequency band, the sub gigahertz band at 868 megahertz in Europe is regulated. So it's a free to use band, so there's no licensing needed. But there are some restrictions on what we can do in this band. Biggest restriction is duty cycle. So we're using this free of charge band. We can't fill it up with all our laura nodes. So we're limited on how much time we can spend on what's called on the air. So that means if our device talks for 1 second on the air, we then have to be quiet for 99 seconds. So this is one of the biggest restrictions on the sub gigahertz band we're using, the 868 band. Also, if you're making devices that's going to cover multiple regions, so Europe or Americas, then you have to make sure that your device will abide by the American rules, which are slightly different. So in America, I think they are the same with us. It's the 1 second, 1% duty cycle. But their rules are slightly different. Also, if you're making products that's going to go out into Asia Pacific, then they really don't really group together. All the rules and regulations are based on country by country. And usually there's some mix between the European rules and the America rules. So these are the two main issues that you've got to abide by. So what is Laura? So Laura is a sub gigahertz low data rate radio communications designed to transmit over long distances. It's really aimed at IoT applications or machine to machine. So where you want to send information from one machine to a central processing machine of some sort. The technology is designed to be long distance. And the reason we can get the long distance is because of the Laura modulation method, which under optimal conditions can get minus 148 dBms. So this gives us the range that we're promising from the Laura protocol. So it's been designed to be long range. So we're saying from 2 km up to 15 km. Environmental conditions will be the biggest deciding factor on this range. If you're out in the countryside or at sea, 15 km is quite easy. Whereas when you're in urban areas or cities, the sub gigahertz noise floor can be quite high. So your range will be reduced significantly inside cities. Same goes for when you're doing it in buildings that have got lots of steel and lots of reinforced concrete as well. So that will limit your range of the device. We're stating there more than 10 years without changing a battery. Well, that's depending on what your application is doing and the type of battery you've installed in your application. So it's a bit of a generalized statement. There are a couple of deciding factors in there. Laura is a star network. So therefore the nodes or notes as they're called in Laura terms cannot talk to each other. Everything has to talk to a gateway. And depending on which type of gateways you're using, you can get a lot of throughput on these gateways. So you can get up to 4 million transactions per day per gateway. The length of your transaction will control the number of transactions you're going to get. So the time on air will decide that factor. But if you're on very short messages, you can get up to 4 million transactions per day on a gateway. Laura is also quite a robust communication. So it's been designed so that jamming is not that easy on Laura. So we'll show you that in the coming few slides. And it can coexist with other networks. So there are different networks available, like the Sigfox network, which is on the same frequency. Because the protocol for or modulation method is different, they should not interfere with each other because of the different frequency steps that they're using. Laura nodes can also be mobile. So they can join any gateway, wherever they are. So if they're moving around, then they can join any gateway, which is the closest to them. They can be nomadic. So they can sit on one gateway for a few weeks, then move and connect to a different gateway for a few weeks and so on. Or you can actually have them fixed. So you can actually link them to one particular gateway. So you've got the flexibility with the Laura protocol. Also, you've got ability to use it indoors and outdoors. Remember, indoors, if there's a lot of steel and concrete in the building, your range will be significantly restricted. Whereas outdoors, it will decide on the background noise floor of the sub gigahertz frequency band that you're working in. So some of the differentiators of Laura. We have true location available. This is an add-on software from Semtech. So it's not free of charge. You have to pay for this software. And you will need multiple gateways so that you can help decide where your actual node is located in real terms. Laura is bi-directional, so as well as being able for the node to send information to the gateways. The gateway can reply back to the node with information. So we can have a proper handshake of data between the two areas. Mobility, as I said earlier, you can be mobile within the Laura network. So you can get your information from wherever you are. And there's also security built in, which we'll discuss later on in this section. So the modulation method that the Laura protocol uses. So Laura is actually a spread spectrum technology. It was originally developed by Cycleo, who were then acquired by Semtech. And then Semtech have developed it further into what is now the Laura protocol and the Laura stack. It is a chirped frequency. So you'll see this on the next slide. Which means that each step that we have or each symbol or each chip is a changing frequency. So each element that makes up part of your message is what's called chirp. So it starts at one frequency and then will increase by a delta of 125 kilohertz. So this is where we said that it's very robust to jamming is because of this chirp frequency. It's not just one frequency you're jamming. You've got to jam a whole section of the sub gigahertz bandwidth so that this message would not get through. One of the other modulation factors we've got is the spreading factor. So spreading factor of seven is the shortest, which means you can see the chirps are fairly steep. But you can vary the spreading factor, depending on environmental issues, up to a value of 12, which means then each chirp takes a lot longer to do the sweep from wherever you're starting at to the plus 125 kilohertz. This will improve your sensitivity so you'll get a better sensitivity on the system. But it will also massively increase your time on air. As you can see there, one symbol on a spreading factor of 12 takes the equivalent of four symbols on a spreading factor of seven. So therefore your message will spend a lot more time transmitting and therefore more time on air, which means under the EU regulations then you have to be quiet for a lot longer on the air. So you've got to have a look at your environmental conditions and decide which is the best configuration that you're going to need. So it will make a big difference. So some of the other variables that we are looking at, so spreading factor we've just mentioned, the bandwidth that we're using, so you saw there we were using 125 kilohertz. There are settings to increase this to 250 or 500 kilohertz. This will means that your receiver sensitivity is improved, but your time on air will become longer as well. So again, as you're doing each of those chirps you saw from there, if you're chirping for 250 or 500, therefore your chirp will take a lot longer or each symbol, sorry, will take a lot longer. So it has the same effect as increasing the spreading factor as well. So again, the bandwidth is something that you will have to have a look at and decide which is the best that suits your environmental conditions. Time on air is the variable I keep mentioning a lot. The shorter the time on air, the more messages you can send when you're complying with the regulations. But you might decide that due to the sensitivity you might want to increase your time on air based on the environmental conditions you've got. Bit rate is the number of bits per second that we're transmitting, fairly easy one. Integrated into this protocol is forward error correction. And inside there you have a coding ratio for your error correction. So the coding ratio of 4 over 5 means that 20% of our payload is the error correction. You can increase that, but the downside of increasing your error correction means that more of your payload is for error correction than your data. Therefore, you go back to this time on air again. It means the longer you spend on the air, which means you're bound by the rules of the duty cycle, which means you have to be quiet for a lot longer. Range, we don't actually give in kilometers or meters. We always mention it in the RF world as DBMs, so we'll always mention that. Receiver sensitivity is always measured in DBMs. So the lower the sensitivity, the better the actual radio is. So the better the sensitivity, it means it's the largest negative number that you will see on the slides. Data rate, this is the Laura modulation method. So this is what type of data rate we're using. And inside the Laura software stack, we have something called adaptive data rate. So the adaptive data rate can vary some of the different elements we've just spoken about to maximize battery life, make the network function a lot better, and provide the best throughput of data for getting your information from your node to your gateway. So we have a feature for adaptive data rate. You'll see this in some of the examples as we go on this afternoon, where we make sure that adaptive rate rate is set to 1, so it's enabled in the software stack. So the physical layer, so we're a spread spectrum chirp cyclic shift modulation. That's a mouthful. So it is patented. So this is why we don't have all the information about what goes on inside the Laura physical layer. So this is all Semtex protected IP. But we've got different data rates available from 18 bits per second up to 37.5 kilobits per second. Now depending on what bandwidth you're using, your spreading factor and things like that will depend on how much data you get through and what type of sensitivity you're going to get out of your system. So what we're using normally, we use a bandwidth of 125 kilohertz, which means we get about 9.3 kilobits per second at a sensitivity of minus 118 dBm. So if we increase our spreading factor, we can get 130, minus 136 dBm, but we're down then at 300 bits per second. So our nominal data throughput is reduced. Our time and air will go up, but the sensitivity, which means the distance we can get our message potentially can go a lot further. So the specifications at the moment are all to do with limited duty cycle transmissions. So as I said, the regulations limit us to only 1% per subband. So every time a frame is transmitted on a particular subband, we then have to be quiet for the 99% of the time. But if you're using multiple subbands, you can then potentially send the same message one after the other on each of the subbands that make up the 600 kilohertz frequency range that we have available to us. And when you change subbands, the 1% duty cycle doesn't count until you've sent your message on that subband. So potentially you could send free messages very quickly on different subbands. So there are ways around if you use the different subbands that are available in the frequency range. So the classes that we have for the lower nodes. There are three classes available. Our software stack today is only supporting class A, but that will change at some point. Class A is designed for battery powered sensing type nodes. So it's the most energy efficient class. So it spends most of its time asleep or in low power modes. And it sends small amounts of data infrequently. So it's mainly designed for sensing of temperature, other information, movement or whatever. And then transmits the information over to the gateways into the servers. Class B is more for battery powered items again. So again energy efficient items. But this is more where you need the bidirectional parts. So this is where you need the return information to actually be controlling something at the battery sensing end of the application. So it's more like actuators where you want to switch, say, a radiator or a heater on or off. So you send the temperature information. The server then decides, right, we'll send the information back so that you can close the actual actuator or close the valve to reduce the heat in that area now. And then Class C, these are more for mains powered devices. So this device will transmit its information and then we'll sit there permanently listening. So it won't go to sleep. It'll be permanently sat there on the network listening for any responses that have to come in from the gateway. So here's more of a visualization of a Class A device. So we have our end device here. It sends its uplink packet to the gateway or the network. And then after a programmed wait time, so at this time it's asleep, it'll wake up again, open a receive window for about 200 milliseconds. Then it'll go back to sleep again. If it didn't hear anything in the first receive window, it'll repeat the receive window after its second program waits time for another 200 milliseconds. And then the device will go back to sleep again at that point. So if it doesn't receive its response back in those two windows, then it'll go back to sleep until it's time to transmit its next piece of information. Class B, so this is the one where you've got more chance of receiving information. So when you do need the bi-directional communications to happen. So your end device will transmit its information and then synchronized with a beacon coming from the gateway, it will open at regularly defined intervals a receive slot. So at this point then it will always be listening on the network for a fixed amount of time over the duration of a longer period of time. And the beacons will come from the network to resynchronize the end device so that it can always receive its data that it needs to do to switch off the valve in the heater or whatever it's been programmed to do. And then finally Class C, so this is where we transmit and then we are then permanently listening on the network so that we can always receive our information that we've got. So this is the true bi-directional communication where it already sits there and listens. Class B is the more power-sensitive bi-directional class that's available. So this is the topology of the Laura protocol. On the left hand side we've got all our devices. So there can be thousands of these devices transmitting information at their programmed intervals abiding by all the regulations in whatever territory you're in. Then we have the gateways. So the gateway is just a channel to get the information from the device onto the network. So the gateways can be connected to whatever. You can get to 3G, Ethernet, whatever type of network infrastructure you've got to get all the information back to your network server. The network server, there's only one in the system and this is what controls the whole of the Laura network. So there's only one of them there. And it will then receive from multiple gateways all the different messages coming in. It's basically a postman as well. So each message will have a destination application server address and that message will then get posted via the network server to the relevant application server which is what is going to do the analysis of all the data coming in. In our example here that we have in the workshop, our multi-tech gateway as we call it is a combined gateway network server and application server. So our module is doing all three items in one particular block. This is more for simplicity for us when we're doing these workshops. You can separate things out as you wish for your particular system that you want to install. Security. So all communication channels need some form of security. By default we have AES128 inside the system. So what we have that we send across the network, we have a device address and then we will have two particular session keys. So these session keys are what you get given when you're doing the join process and one comes from the network which is saying that yes, you're a valid device address. I will allow you onto my network. The second session key is the application session key and that is the application server that you want your device to talk to. So in your system you can have multiple devices talking to different application servers. So say you were managing lighting as an example. You might have street lighting nodes. They will want to talk to one application server in the local authority. You might have the lighting for building architectural lighting for buildings. This will be going to a different application server and you might have lighting that's illuminating street signs as an example and that might be going to a third application server. All of it is managed by one network server in the local authority but each department in the local authority for road signs, street lights and architectural might have their own application servers. So each of them is a key that can uniquely link a node to a server. So here's a more visualised view of it. So you'll have multiple gateways in your local authority. Each of the different end nodes will be talking to whichever gateway is closest. It might be talking to multiple gateways if they're all in range. And then all of these gateways then get connected back through network infrastructure to the single network server that's controlling the whole of the Lora network. And then that routes the various information from each of the nodes to whichever of the application servers it's required to do so. So the network key or network session key is between the end node and the network server to make sure you're a valid device allowed to be on this particular network. And then the application session key is the process that the application uses to communicate with the end node. So there's two ways of end nodes to join the system. We have over-the-air activation. So this means that you send out a message to the network server when you power up your node. It'll then communicate with the network server, the relevant application server that's there as well to decide are you allowed to talk to these two servers and then eventually you'll join the network. And the second method of joining a Lora network is by personalisation. So activation by personalisation. So therefore there's no over-the-air handshaking as soon as you power up your node it already has the network session key and application session key programmed in and therefore can instantly send messages straight onto the network so it can broadcast its message straight out. So personalisation means there's no joining process required unfortunately this means roaming is not possible with this particular method. So you can't go roaming around because you're looking for a particular network server and a particular application server. So it can't actually roam around whereas the over-the-air activation ones because you go through the joining process so when you send out your request to join you send out your unique ID to the network and you send out the address of the application server you want to talk to. These two pieces of information are encrypted using an application key and then the network server and application server will decrypt those messages route it to whichever application server it is. If the network server and the application server are both happy and you are a valid device that's allowed to join the network it will then take your device address and generate two session keys one from the network one from the application and then send them back out to the node so that you can then start sending your data across the network. Okay, any questions on the Laura protocol?