Hi everyone. Welcome to our Laura Alliance Technical webinar today. We do want to go ahead and get started on time, so we are going to kick off here right at the hour and we have a great technical webinar for you today. We're talking with some of our Members from the Technical committee and they're going to talk about the Lorawan standard expands to include relay specification. So just a quick few notes before we get started here and I hand over to the presenters. Just a reminder that there's no dial in number for the webinar today, so all the audio is through your computer. If you're having any technical issues, please go ahead and refresh your screen and that usually solves any issues. There's also a bar along the bottom of your screen. And there's a help box there if you do need any further help. The other really important box on your screen is the. A Q&A box. So throughout the webinar today, type in your questions into that Q&A box and our presenters will be answering those questions at the end of the webinar. And just a reminder that the webcast will be available on demand within the next 24 hours or so. So I am going to go ahead now and skip over and introduce and let our presenters introduce themselves. So Carlo, please go ahead and take over. Thanks, Megan. So hello everyone and thank you for taking the time to attend today's today's webinar about the Lorawan. Additional feature that we want to introduce and called relay. So I'm Carlo Tinell, I'm product manager, marketing manager for Semtech and especially for Laura Products catalog. I've been recent text since three years now and I'm a big fan of this new feature that we are introducing with the alliance. Reese? So everyone, embrace maitan. I'm a systems and I'm an embedded system engineer at Semtech, and I'm also one of the main editor of the Respecification. Some kind of. Thanks, breeze. So let's move on, on the on the presentation. So the first part of the presentation will provide you insights on the business rationale that has driven the activity and the definition of the specification itself. So we will see why the alliance converged on the idea that the relay was indeed needed. What are the main requirements of this relay really, what shape the specification and what are the use cases that are enabled or will benefit from from this additional future? Then Brace will describe the principle of operation of the relay, addressing the main topics like message forwarding, security and power consumption. So we would find finally end the session with a few takeaways and messages for you. So let's start understanding the problem that we want to solve with with relay now. The the problem is, it's basically a matter of cost and this explained on the on the on the left side of the slide. Our problem our ecosystem often finds, especially for large network deployments. But not only is the excessive increase of infrastructure costs when there is a need to ensure coverage for the last five or 10% of the sensor population. In most of the cases, this last percentage. Which is still very important. Is considered by by by small cluster of of devices at the very edge of of a network that sometimes can be already deployed. Just it's not just in the case that we have to deploy new new network when the only way to bring. To bring this coverage is. Only deploying new gateways the cost of coverage percentiles. May become too high and simply might not make sense. For the business case, so may be too high to be justified for the business case so. And do we clear, we are not just talking about the cost of the hardware of the gate itself a gateway must be fined also our power grid and an intent because so two quite heavy infrastructure that must be there for the gateway to be to be operational. So really and these those are additional costs on top of the gateways hardware. So our ecosystem found really the compelling need for a a low-cost network extender with reduced. Infrastructure CapEx to ensure the coverage at the extreme edge. So that's really the the main problem that we are solving lowering the CapEx, the investment needed to deploy and cover and provide a lot of our network at the very edge of of our deployments. Now let's see what are the main high level requirements that drove the definition of the relay specification. First, our relay must be low power and low cost. But what does it really mean? Low power and low cost. So low cost for us meant that the hardware architecture of the relay should be. Equivalent to the one of our standard lower, lower one and the device that's the let's say the main statement that stands behind the low cost assessor. Follow power the Alliance and vision at the A solution capable to be battery powered and brace will show you elements for that and with some fair assumption still capable to work for several years. So that's what really low power means. Again, we are adding a new device, a new feature there with the same, let's say high level. Capabilities or or specificities of our Lorawan and and device? The second main requirement was that the relay must be capable to handle at least 10 Laura one and devices. So we are envisioning here really small clusters of devices, OK? 3rd is that from a gateway standpoint the relay behaves as a standard Laura one and devices. This really simplifies also the the the the deployment of the relay. There is no need to big changes on the infrastructure itself. OK 4th requirement is that the relay and did note that it manages must be secure as a Laura one and device very sensitive topic and so with the relay we will keep the security. Of the lower one stand up at the same level, it's too late. And finally, the end device is working under a relay should be should should be capable to revert back to traditional Lorawan operational configuration when they simply realized that they could be covered by other one gateway because exposed at some point. When the population of this cluster grows enough, then we could find reasonable to install a new gateway and maybe reuse the relay for another, let's say extension farther at the edge. So in addition on the on the right side, you also can appreciate that. They are designing or we are envisioning the relay with the an operation through a single hub. So relay will the Lord one relay. It's not something meant for our aimed for a multi author machine network but really single hop extension coverage. But practically, let's see also what are the use cases that could be more more easily enabled or could take benefit from this protocol extension. So let's work through a collection of them in the next couple of slides. 1st, As you can see on the right side, typically relay would provide an efficient solution to extend the network network coverage for small clusters of devices in the periphery. Our network already deployed or in course of deployment, but another interesting case will be or let's say set of cases. Will be where the surrounding environment of the sensor introduces very high in social losses. So the sensor can be quite close to the gateway, but the environment introduces a high level of insertion losses which breaks the the the the coverage. So this happens for instance in very deep indoor scenarios where the for instance a meter is put behind the thick walls or placed into deep wells. But even generally when meters or sensors are deployed underground, OK, so. Those are three, let's say, use cases we have seen. Are requiring this kind of solution, but. When we start pitching the idea of our relate to to the Lord Amen ecosystem, we quickly also realized that there, there. This feature could be a key enabler also for a couple of new emerging use cases. For us to track and trace platforms, especially for logistics, there is a growing need to monitor the load inside the container and this must be done through multiple sensors placed into the container itself and sometimes also in different positions. OK, now the metallic container acts freely as an electric shield, so makes and it makes very difficult. For the wireless signal to be received, let's say 100 or meters away of the container. So reliably we can say that. The the signal can be transmitted or received to up to few 10s of metres outside the container. So as a solution our relay here, when it's placed on on the external surface of the container, it could easily collect all the information and sensing information coming from the different sensors inside the container and then. Retransmit everything to a standard or one gave. So really key enabler for this track and trace monitoring, use case into logistics and finally another very interesting use case. Enabled by by by by by by this new feature is. We can be found in the in the satellite IO T connectivity applications. We have a lot of customers now that are starting to deploy these kind of platforms and really with relay those kind of platforms platforms can extend a provide Dora 1 connectivity in remote areas even when it's required to reach indoor, indoor sensors. So really. With relay we can easily expand satellite ****** connectivity indoor. For all those application use cases where satellite connectivity can can play a critical role. Let me now pass the stage to to brace. It will describe you the principle of operation of the really protocol. Bryce, it's up to you now. So, thank you, Carlo. So now let's talk about the technical part about the relay specification. So like Carlos said earlier, one of the key requirement of the role was to be low power and low cost. So with that in mind, we designed the relay protocol around an end device radio chip to be low cost and we decided that continuous reception wasn't a valid option for a battery powered device. Instead. We decided to use. A feature of the lower chip called CAD which stands for channel activity detect. So this feature allows a radio to check if there is any LOA modulation ongoing. So. In order to reduce the power consumption drastically, the array will perform cat periodically and goes to sleep between 2 scan. So. Sets. It will do that if there is no law activity. If there is a lower activity detected during one of the CAD, he will switch to reception to receive the incoming frame. And. As shown on the figure, the relay can be configured to perform on one or two channels. The first, the first channel, also called default channel, is a mandatory channel where frequency and data rate are defined in the regional parameter specification. So basically we have two set of configuration. One at S10 bond with 500 for the US and Australia and the other one at SF 9 and bond with 125 for the rest of the world. Prior to any connection to the network. So before joining the lower network and divide will use the default channel. It's a little bit like the joint frequency. But. A second channel can also be configured by the network server. This channel. Can be configured to either increase frequency. All that data rate diversity. It is completely up to the network server to decide what configuration you want to use. You may want to have a high data rate to match. The application need or he may want to use a different frequency with the same data rate. To increase the frequency diversity. So now let's talk about the end device. So. Like I said, on one side we have a release that is doing a periodic card and on the other side we have an end device that need to communicate with this wrap. Our solution was to create a new frame called Wakan Radio to allow the end device to catch this cat. Basically the wagon radio frame is A-frame with the crumble up to one second. This long preamble is the heart of the Warframe and is what allows the end device to wake up the relay. So now we have two kind of weaken radio frame. The first one is for the join request and the other one is for the standard Laura one uplink. The main difference between them is that the one for the uplink is encrypted. The data inside the two Warframe are the same and basically are the frequency and data rate of the lower one uplinks that will need to be forwarded to the network. So. Let's resume so once the relay has been waking up by the long preamble. It will switch to Eric's mode and start to demodulate the incoming packet. In response to this frame. So this is the raw. This is the raw frame where we were talking about. In response to this frame, zole may send an acknowledgement. And then then device will send its lower one uplink. I studied before we wanted the relay. To not interfere with the lower one protocol. So this lower leg blink could also be received by a gateway and the north could decide to bypass the relay and send a downlink on Ericsson or Iris two directly to the end device. But in case where this frame is only received by role, we had to create a new reception windows called RXR to allow a dongling to be sent through a relay. So. Erics are defined. So we will more on that later. So as I addressed that the rule may reply with the War Act to a Warframe. So. The war hack is only set by the relay to the war uplink, because only the war uplink is encrypted and secure with the and the secure enough. This frame, so the war act frame serves multiple purposes. The first one is obviously to leads and device. Know that it's Warframe has been received and understood by the relay. The second one is to inform the end device about the relay whereabout such as such such as. Is that a rate between himself and the network server? The forward capacity, the external accuracy, the real capacity. The to offset so to offset is how many milliseconds of preamble the has received. And the dealer for the relay to switch from CAT to reception mode. So all the latest information will allow the end device to estimate when the relay is scanning the channel and thus reduce the preamble for its next message. If you want to know more about this mechanism to reduce the preamble length. There is a dedicated annex on the specification, with some with the calculation and some and an example. So. Let's resume. We have an antivirus that has sent a Warframe with a long preamble to wake up the relay. Really that I receive? This frame and reply. With our war back. Then then device has send its own uplink. Lower one uplink that has been received by the relay. So now the really has the law on uplink and need to forward it to the network server. So on top of the link, the relay will add some metadata like SNR and RSI and then send it. To the networks area on a dedicated airport. Zeus, the network server, will be able to know that this message. Is a forwarded message. Is that it need to be handled as a relayed message? So it is important to note that the delay between the end of the uplink. So I think here. And the forwarded message. Here. Is fixed to allow the network server to perform some calculation to determine when the end device has really signed the uplink. This is crucial for some application like time synchronization. So now the NS. The network server has a link. And know that it has been forwarded through a relay. So. If the network server want to send the downlink to the end device, it has to send it. To the either on Eric's one or Eric's two. And then the relay will send it. We'll send the downlink to the end device on the arix our windows. So the erics arandas is open 18 seconds after the end of the uplink. We choose this value to be. We choose these value to be after the maximum value of RX-2 which is 16 seconds. And the frequency and data rates of this windows is a mix of the Wakhan radio frame and the lower one uplink. So now. We have done the whole the complete interaction between the end device. From related to Network Server 2 related to back to relay and back to the end device. So we have seen every step to to enable communication between an end device. A relay and a networks. Now let's talk about some capabilities of the relay. So in order to control the forwarding ability of the relay, we have added some filtering and forwarding limitation. So by default I really will forward every join request. But his behavior could be changed and fine tune. We have implemented a filter and forward list based on the combination of the join UI and the Devi using the longest prefix match algorithm. The following the following table is an example of what can be done with it, and it should be a bit a little bit more explicit so. In this case, we have updated the first the Rule 0. To filter every joint request, so now the relay will filter will reject every joint request and receive. But we have added the Rule 1. 2. Able to to allow the relay to only forward. The join request from a specific OU I. But we also have added a rule. To filter a dedicated specific journey. And on this specific joint UI, we decided that we wanted to. Authorize a subset of Devoy except for one which is defined on the Rule 4. So it's quite flexible it it could allow the network server to manage. Which end device is or is not allowed to go to join through a relay and with that we can control the consumption of the relay and have a. A fix? Predictable battery life. About the forwarding, it's also the same thing. So to avoid to drain the battery too too quickly and have a predictable life estimation, we have added a forward limit. Depending on the type of the message and reset on an hourly basis. So basically it means that. We can configure the relate to forward a number a fixed number of joint requests, uplink new device detection each hour and update this limit dynamically. So it means that you can choose. To configure your roller to forward a lot of joint requests at first and a few uplink and then once your setup is done reduce the number of join requests and increase the number of uplink to match your need. So with this kind of flexibility. We think we can accommodate every needs. So let's talk about now. Let's talk about security. So. One of the key or command was to. Other really as secure as an end device. So based on that we have, we decided to create a new key, new relay session key called Rookworst Key. So this key is derived from the network session key. So this also means that the relation key are unique for each end device and need to be computed after every join. This key allows the. From this key, so we created let's say an intermediate key. This key will be need to be transferred to the relay. And the relay will derive the war S int key error as Anki. To. Logan. To check the validity of the MIC to encrypt and decrypt the Recon radio payload. So this key was added to limit the cost of transferring the relay, the relation key to the relay. So we have to transmit transmit only one key instead of two. Uh as a note on the on the key transfer. So it is recommended to only have the relay session key in one relay at a time travel multiple acknowledge at the same time coming from different relay because if this happens. The end device will not be able to receive a wallhack and this will not be able to send its lower one uplink. It is possible to have the relaxation key on several at the same time, but you need to be sure that they will never be in conflict with each other. OK. So now let's talk about the baytree. As I said in the beginning, the early protocol has been designed to be low power. So we run some simulation to estimate the battery life and come up with the following charts. So let's assume we are really doing a scan every 2nd and managing 10 and device. So with each end device sending 50 bytes every hour and receiving 20 bytes one per day, we suppose that all communication are done at F9 bond with 125. In this scenario, we could have up to 10 years of battery life if there really is only configuring 1 channel, and 7.5 years if a second channel is enabled. As you can see on the chart, the means of consumption is the cat, so even if it's very short, it add up quickly as it is done every second. So this simulation has been done on the SAT, LS30. On a D cell battery with a 17 empire per hour capacity. So it's quite a big cell, but not. It's possible to use this kind of cell for really? Now let's talk about the battery for the end device. So the cost of using the relay protocol on the end device depends mainly on three factor. The first one is the data rate and payload size that's need to be forwarded. The second one is the delay between uplink and the X style error of pause and device Android. The last two parameter are linked together as they will dictate the preamble left of the RAKON radio frame. The chart on the right. Shows that energy consumption could be increased by a factor of two to four, depending on the delay between uplink. So as we can see on this. Shots. The law the consumption is double and on each chart it's multiplied by 4. The main difference on the between these two chart is a delay between uplink and, as we can see the synchronization process. So basically the length of the preamble on the Recon radio frame. Change it is the only problem with parameters that change. So. If you speak regularly with your release, let's say 111 time per hour or more often. The thing the thing parts will be. Hello. As opposed to the law on the blink. So it is important to note that this chart only covers the consumption of the roller on the blink and not to the not the whole product. OK. And I think that's all for me. So Carlo, if you want to. And it. Thanks, Bruce. Let's conclude the presentation with the four main takeaways, the first one. Because we're not light, is that. Really lower one community keeps responding to market demand to further simplify adoption and and lower lower cost barriers and let me let me say that this dynamism is is is a key ingredient of the lot of our success in the market. So we are very proud of that. The second main message is they were not usually with is, is that relay will be low power, low cost and secure as a lot of 1 and device very important so. Rob, still striving to keep our main value proposition there, even adding and improving the protocol down the road. Now Laura, wanna ecosystem the Woodlawn ecosystem as an efficient standardized solution to extend the reliability the coverage to small cluster of devices at the very edge and with relay satellite connectivity in remote areas become much more affordable also for indoor use cases so. Those are the main messages that I wanted to share with you. Once again, thank you for your attention. And I'll hand over to Megan. Great. Thank you so much, Carlo. A lot of great but also useful information presented on the webinar today. So thank you to both of our presenters and this link that Carlo has on that take away slide there is also. In the resources box on your screen. So if you look at your screen, you'll see a box called resources and you can go ahead and click that link directly from there. And there's also a copy of today's slide deck in that same area. So just a reminder or in case you joined late, we do have plenty of time here for the panelists to answer your questions. So please type in that Q&A box any questions you have for our panelists today and we'll get to those very shortly. A quick invitation to our in person event in San Francisco next week. So there is a discount code on your screen as well. If you are able to join us at our Laura Wayne Live event in San Francisco next week, we'll have more great technical presentations there and we hope you can all join us. So more details if you click the Lorawan live image on your screen. That will take you directly to that website, and you can always reach out to events at laura-alliance.org For more information. So we'll go ahead and move into our Q&A section. Now Elper Yagin, the vice chairman of the Laura Alliance and also the Technical committee chair and the Vice President of Advanced Technology Development from activity will be joining us to moderate the Q&A session. So I'm going to go ahead and hand over to helper to go ahead and begin that Q&A. So submit those questions in that box labeled Q&A on your screen and. We'll get started here. _1664898319449

The LoRa Alliance® is expanding the LoRaWAN® standard with the support of a new feature called Relay. 

The new relay feature is addressing the issue that, in some instances, it may be economically difficult or not be materially possible to deploy full-size gateways to extend LoRaWAN coverage to a small portion of end-devices. This is especially apparent in use cases with sparse deep indoor connectivity, or for underground smart metering, or with a cluster of sensors around a LoRa satellite module, for example. 

In these cases, a low-cost and battery-capable Relay device is the ideal solution. 

During this webinar, you will learn: