Good morning, good afternoon everybody. I am here on global Laura, one Networks director at Sentech in the local Lions. I'd share the operator community as well as the EMEA region Workgroup. I am pleased to open the second destination Laura one and running. Today we will move to a more comprehensive discussion on implementing and deploying Lorawan roaming. Let me introduce you to an speaker Alper Hagen. Albert is probably one of the most knowledgeable persons on law and warming. I'll play again has been actively contributing and leading development of Internet and telecom standard for the past 20 years in various forms, including ETF 3, GPP, SC and Zigbee Alliance. For the past 10 years he has been focusing on IoT. In the later half, more specifically on LT1 and Laura one. ALPA has been spearheading the law and technology and ecosystem development as the vice chair of the Board and Chair of the Technical Committee in Nora Lions. And director of Advanced Technology Development in activity. Before we begin, we would like to cover a few housekeeping items. At the bottom of your screen are multiple application engagement tools. Or move or resize if you like. If you have any questions during the webcast, you can submit them through the Queen Engagement tool. A copy of today's slide deck and additional materials are available in the Lore Alliance Resource list. We encourage you to download any resources or links that you may find useful. For the best viewing experience, we recommend using a wired Internet connection and your computer speakers or headset are turned on and volume up so you can hear the presenters. The webcast is being streamed through your computer, so there is no dial in number. Subnetworks called slides to advance more slowly than ovals. So if the slides are behind, pushing F5 on your keyboard will refresh the page. You can find additional answers to some common technical issues located in the help Engagement tool at the bottom of your screen. And on demand version of the web just will be available approximately 48 hours after the webcast and can be accessed using the same audience link that was sent to you or to attend the webcast so. No, let's dig into law one, roaming. To start with, I would like to make the transition with the previous January 21 destination or one on roaming. If you ask me the question, why low on roaming is so strategic? Let me say that. Anyway, this technology requires coverage to support business expansion. Running a neighbours Lohan devices to use multi level network coverage first. Loveridge, encourage potential from Earth to space. But local and roaming is far beyond this, and it will surely step change the world. Network providers implement IoT roaming in the coming years. Let me hand over to Alper, who's going to explain why Laura one roaming is so special. And how to set it up? Thank you very much for me for the great introduction. Once again, it's a pleasure to be here talking about one of the most advanced features of Lorawan, namely roaming. In this talk I will be talking about the use cases and the features of Laurel and roaming, and then I'll describe how it works technically, and then I'll go over how to set up roaming in a step by step fashion. And finally I will talk about the current deployments we have across across the globe. The very first use case we have is the international coverage extension, which is a very I would say traditional use case. Imagine you have a network in country one. Either it's your own network or you subscribe to a network and then you have devices going around in the neighboring countries. Because the each country has distinct network. When your device are in other countries you would like you will have to rely on other networks for providing coverage, and that's where such networks set up roaming agreements among them so that the radio coverage provided by the neighboring networks would appear as an extension to your so called home network. And this kind of roaming has been president with almost all wireless communication technologies, and obviously that's where we start from. By enabling this basic use case. And then in this subsequent use cases, you'll realize we start to go well beyond this this basic case. The second one is again we are in a country now. We have two networks. Neither of them would provide nationwide coverage, but the when the two are put together they can provide a unified nationwide coverage and by setting up roaming between these two or even maybe 3 or 4 specs, networks across the nation, we can achieve a nationwide coverage for for the subscribers of either network. Now in the seller world, most of the time operators have nationwide coverage. They rarely wrong with the others within the same country, so we already see a little bit of. Going beyond the traditional roaming here, but then with the next one you will see that we certainly start setting us apart from legacy and even the new generation. Mostly acelera IoT networks. In order to explain the next use case, let me let me provide a little bit more background on. How other technologies work? An however one works in terms of the radio networks providing connectivity service to the IoT devices. With the in urban IoT LTM, an even 5G and also Wi-Fi, there is a concept called attachment. The end device would attach to a base station or an access point depending on which technology used determines a little bit different, but this is attachment procedure and after that point on all the traffic transmitted by the device, like the sensor in this case would only be served by that single base station or single access point. That serves the end device. Even though there might be several other base stations within the coverage of this sensor, they would not be really listening to the frames or the packets transmitted by the sensor, and only one one base station would be in charge of providing that service. Given that the nature of RF can change the radio frequency based communication can change. Obviously, in an ideal setup one would like to leverage all the all the base stations within the coverage in order to receive the frames or the packets from such devices. And that's exactly what we do with Laura. When, unlike in those technologies where there's a, there's an attachment with a base station with dealer, when actually there's a so called joint procedure joining to a network where the network can have one or more base stations serving the end device. So in this case this sensor went transmits a so called up in frame. Now it can be received or D modulated by all of those four base stations. And every one of them would send the copy of the same frame to the typically cloud based network server, which will. Did duplicate the frames and then eventually would send a single copy of that frame to the application server. So with the changing our conditions the 1st frame might receive by 1 Gateway, the second one Microsoft by the other one. Given that we don't really luck in to a base station, any one of those gate base stations receiving the uplink frame would provide the full connectivity to that to that device. Now imagine those base stations belonging to. Distinct. Networks this basically brings us to a case where. Multiple Lorawan networks with overlapping coverage, as in this case we have the the red network and the Blue Network, and in this case the red one is the home network and blue one happens to be a visitor network, but they do have a coverage around the same area now with the kind of roaming we have. These two networks can adapt their radio network assets, meaning that both the red base stations and blue base stations would be. Simultaneously serving there's Laura Lam device. So in a way, the net effect looking at it from the end device perspective is the network is densified. Now we test twice as many base stations as before. So what does this really get us? Well, this kind of network densification by putting together multiple distinct and standalone networks. It provides us the net effect of bringing the gateways closer to the end device. So if the gateway or if the base station from the home network is not closed, but say a base station from the Visit network is closed, certainly this device would be taking full advantage of the closer base station. And through that proximity and now another great feature of lower ranks in the so called adaptive data rate. Now the device can start using higher data rate. And also lower is transmission power because it no longer needs to use a low data rate and high transmission power which are essential for communicating with afar base stations. So by lowering the transmission power an increasing the data rate, now the transmission from that device would create less interference for the other devices in its vicinity. And it will also elongate the better lifetime of that device. So this is very much beneficial for all the both the network and the end device. And then once we have more base stations or moral and gateways, being able to demodulate upping frames, now we can now for this. Another great feature of Lorraine kicks in this local jail location where by using time difference of arrival an also received signal strength indicator were able to locate the end device with that. Having to resort to a GPS or Wi-Fi fingerprinting or Bluetooth beaconing so for that feature, three or sometimes even four Lane gateways needs to be receiving the same frame now with the ability to add networks together, we increase our chances of having a high number of Lauren Gateways receiving the frame so that we can have a pretty accurate geolocation of such devices using. Little engine location feature now as as interesting as this feature might sound, Please note that this feature is not available to the other LP. One technologies like nearby OT and why son due to technical limitations they do attach to a single base station at a time, so they don't have this so called macro diversity effect to take full advantage of such. Densification and in case of Sigfox, where there is really a single network in any location, there's no chance of having multiple networks to jointly provide radio connectivity and this feature is not really limited to only having two networks with overlap coverage. But you can have 3/4, even five and more networks with overlap coverage and that will only make things better now. The gateways would feel even closer to the end device. And even more gateways will be receiving this same transmission. And if we look at this in a much simpler illustration, this is what you get. Imagine there are two nationwide networks network A&B and they have overlap coverage. Now such cases in Cecil Arieti would not be subjected to any kind of roaming because each network would say we have enough coverage right? But with Lora Wan the two would be compelled or would be I would say attractive to set up roaming because through that they can have this. The additive effect towards densification of their networks, which will be beneficial to their own customers and also it will be beneficial to their own radio resource management. So the next use case we have is where we're able to mix public and private networks. So in the in the legacy technologies that in other more specifically cellular IoT technologies roaming is typically between public networks only public networks would set up roaming with the other ones, and usually those are large networks. With Lorawan we have the ability to set up roaming between public and private. Networks. A specific example, we use such a use case is where we have a multinational enterprise network that has assets or devices in multiple countries and instead of having subscription with the public operator in every one of those countries and having to do proprietary interface based back end integration, we can enable such a network to have a so called core. Only infrastructure, meaning that no radio network at all, but instead have a roaming based interconnection with those public networks. An through that this enterprise network is able to aggregate the traffic coming from its devices in various countries with the help of public operators in those countries and get them all the way to its core network, from which it can push the data to the data platforms. Now, the reason we're able to do enable such a use case is the infrastructure is pretty low cost with Lorawan. Such that any enterprise can build its own Lorawan core network in the cellar case, building a core network is an expensive venture, and that's why enterprises would naturally make such an investment. But the kind of investment needed on the lower one end is pretty achievable, and we're already seeing several example such enterprise networks coming around and setting up this kind of roaming. Secondly, the interconnection is pretty straightforward. You don't need to be. Tier one public operator to set things up. Your IT department can easily set up roaming with the other networks, an obviously the collaborative nature of our ecosystem makes it pretty practical for this kind of roaming. The set up among the public operators and the private networks as well, and then obviously with the same token, we can set up private to private roaming as well. An here is an example. Imagine there's a car manufacturer an. It's working with parts suppliers in various countries and each one of these locations can have their own private network using a gateways that are built to provide connectivity for their own assets. But imagine those parts are being shipped from one part supplier to the car manufacturer and that shipment did the containers needs to be tracked, like when they leave the site one and when they enter site 2. Would like to have some trackers on them now by setting up roaming between those three private networks. Such assets can be enjoying the connectivity provided by the gateways in every one of these sites, whereas the data can be aggregated at the proper private network. And again, the low-cost infrastructure, easy interconnection and the collaborative nature of our technology and ecosystem play and very important role in this. And the last case we have is where we are able to interconnect the terrestrial networks with the satellites networks. The long range ability of Lora Wan and the highly scalable high scalability we get out of it makes this technology suitable for hosting Laurel and gateways or base stations on Leo. Low Earth orbiting satellites which are flying above ground. 500 to 600 kilometers, and such satellite networks provide connectivity in the most remote areas of the world, like the middle of the oceans and the desert and the force and the mountaintops. Now through that, any network, whether it's private or public, that may or may not have its own terrestrial coverage, can set up roaming with the satellite providers so that it can enjoy the extended coverage provided by the satellite providers. So we're able to not only deal with roaming on the on a terrestrial basis, but also we're able to take it to the space an interconnect satellite based networks with the terrestrial ones. So if we look at the collection of all these use cases, the very first one is the most legacy one. The most straightforward, but as you go down this list. You see, we have more and more very advanced use cases, and the reason we have all these advanced cases is to lower the cost of connectivity and also to provide flexibility for the various use cases and the and the connectivity ecosystem. We are nurturing. So now if we look at how this really works behind the scene, I only have two slides. I won't go into too much detail as you know a lot of 1 device. Has two types of procedures. One is the joint procedure, that's when the device. Connects to the network. It goes through as joint procedure by sending a join request and the other one is transmission of regular data. Traffic up and downlink right. For the joint procedure, when the device sends a join request, it has the device identifier and this frame also has an identifier of a so called Join server which is in charge of authenticating the end device and also keeping track of the home network of the end device. When such a joint frame is received by visited Network now this visited network by inspecting the payload identifies the joint server and then sends a request to join Server to discover the home network of that device and upon upon learning, upon discovering the home network, what it would do is to send this joint request all the way to the home network. Now that's how the home network received the John request and join answer would be traversing the same exact path in the reverse direction from the home network to the visit network to the gateway serving the device down to the device itself. And now if we look at how the data is transmitted following the joint procedure. By the way, this joint procedure happens. I would say very rarely. Once the device joins, it can continue that connect with the session for a pretty accent period of time like days, weeks and even months, during which it would be sending its regular data and receiving regular data as in this case this M device sending an uplink frame. Now this frame has a field called device address. And inside that device address we have a field that identifies who the home network is. So this is network. By inspecting that portion of the device address figures out who the home network is and it would push that up in frame to the home network. So that's how the end device public frame will find its way home, and the reverse direction. The dominant direction is just the just the total opposite of this where the downlink. Frame is sent from home Network to the Visit network down to the gateway and to the end device now. This kind of roaming in our lunch terminology is called passive roaming. The reason is the roaming is totally transparent to the end device at this point in time, the device doesn't know whether it's under the coverage of visited Network One or two, or if it is still under the coverage of home, or if it is under the coverage of multiple of these networks at the same time, it just keeps transmitting its uplink frames. An keeps receiving the dialing frames without having to know it's worry about. And, um. Again, that that feature is. Very advantages for the end device because that keeps the advice away from having to do lots of handshakes for for discovering networks and for doing synchronization, and then the data path that is set up between the end device and the home network. Whether it's going through one, this is network or the other or directly attached to the home, this data path is encrypted and integrity protected between the end device and the. Home network, so even if even if this traffic is going through some. Private network, some enterprise networks or some gateways that might be placed outside that might happen to be excellent. Physically accessible by the adversaries that would not create any any security issues with the with the data if the data is tempered, it will be detected and the content of the data cannot be cannot be read in in plain text because it's encrypted between the end device and a home network. So now let's talk about how one can go about deploying Lorawan roaming, so these are four simple steps an I will go and talk about them one by one. Just aware that whether you are deploying a public network or private network, the steps are just the same. There's no distinction. The first step is in order to use lower wrong man, you need to have a roaming capable infrastructure. What that means is on your network server and join server, you need to be implementing a part of the so called Lauren Beck and Interfaces Spec, and the parts that you need to be implementing is the so called stateless passive roaming. The version of the spec that has been implemented in the ecosystem and diploid is the version 1.0. Well, recently around 2 two months ago we have published a new version of this specification that comes with the support for jail location even for roaming devices. This right now the industry is working on implementing this version of the spec, so you can. I would say expect to see deployments using that spec in the coming four to six months. And that's just what you need to implement an on the end device. The end device all it needs to implement is the. Stan is the Laura one link. Their spec an any version of the link. Their spec can be used for passive roaming. Like I said, the roaming is totally transparent to the end device. It just sends uplinks as as usual and consumes downlink as usual. As such, it's not really a part of the roaming procedure that happens. Among the network infrastructure elements like the visited Network server, home network Server and the joint server. And as long as the end device is operating under the under the same RF region like say U 868. There's nothing the device needs to do. Obviously, if the device were to cross the border from say, EU region to US region or the Asian regions or the South Korean region because the regulations are different, the device needs to be aware of this change of location and it will need to use a different regional parameter set, but that is independent of the roaming, it's it's enjoying. We just handled behind the scene by the network elements. So this is first step and then the next step is. Now that you have an infrastructure that is ready for using roaming, then need to go and get the net net ID is a globally unique identifier assigned by the Lore Alliance, and this ID is used for for the networks to uniquely identify their roaming partners. And also this identifier Ora Ora transformation of that net ID is used. And embedded inside the device address. Remember the sliding and the visit network inspects the device address embedded inside the device addresses the so-called network ID, which gets mapped to the home network. And in order to generate the proper network ID for your own devices, you need to get your globally unique assigned. Net ID from lorelei's. And to get that assignment all you need is to become a member of the Laurel lines. Any alliance member. As part of their membership benefit would enjoy having their own net idea. Um, all they need to do is to send an email to help@lorialliance.org. And they would be assigned there. Not idea. And there are different types of net IDs depending on the membership level the Member has. There are type 0, Type 3 and Type 6 net IDs. The fundamental difference among these types is. How many devices they can uniquely identify? Other than that, all these types operate just the same way you configure it on your network server, and you let it assign device addresses using that assign NET ID. Then now that you have your network server join server setup, you have your net ID configured. The next next thing you need to do is to go find a partner. And for that I would like to take your attention to a video recent PR that Laura lines had issued where we have identified 27 countries with roaming capable public networks. All those green ones we are seeing on this map have at least one public operator that has the capability and the willingness to set up roaming with the other networks. And if you're wondering what those operators might be. Here is the list, so depending on which country you would like to have coverage you can. You can look at this list and identified operation name and get in touch with them for setting up roaming and just be aware this list is what we have as of today and it's come. Only growing, so keep checking with the Laura lines to get to know about the latest and the most comprehensive list. So you see the country names in here. That's where you have the public operators in those countries. And then you also see one operator here that provides connectivity through satellites. And then also another provider here for roaming hub that facilitates interconnection of networks which enables majority of the roaming interconnection in this list. And once you identify a partner, you need to have an agreement. Roaming is a mutual relationship with your partner. You need to agree with her. Each one of you would be allowing roaming in devices or roaming out devices so you can have BI directional roaming or unidirectional roaming. It's all part of your business case and your your needs, and then the roaming partners will also need to agree on whether the accounting will be based on counting frames or counting devices. And the service level agreement, and then the commercial aspects like pricing, which are all taken care of among the roaming partners in bilateral ways. And then once you have the agreements, the next step is the night job interconnecting networks now before interconnecting you want to make sure the network server of both parties can interoperate. Obviously they need to have implemented this standard back end spec, but even though two vendors I have implemented a standard spec, that doesn't mean that their platforms would interpret from the very beginning right before you roll out to your production network, you want to make sure the network server from both sides can interoperate. Now if the network servers are coming from the same vendor. Obviously interrupt comes for free, you don't have to worry about it, but if the network servers are coming from 2 distinct vendors you would like to ask them if they have done interrupt in the past for potentially other customers of theirs. If they have done that, then that's good. If they haven't, then you will need to ask these two vendors to carry out interrupt to make sure they're implementation of the backends. Spec is fully compliant, and there are no bugs and incompatibilities, and then once interrupt is achieved, the next is the interconnection, which is basically configuring one network server against each other against the other side of the traffic is transmitted towards the right endpoint. There's a security Association set up and the flows are opened. Imagine their firewalls in between. The firewalls should be allowing such flows, things like that. Printer connection there are two options. One of them is the peer to peer interconnect where the network server of 1 operator will need to have this interconnect with everyone of its roaming partners and then we have also adopted the well proven concept of running roaming hubs in our ecosystem where any new network that wants to set up running with the others if it chooses to go through a roaming hub, there will be only one time interconnection. And through that logical logical interconnections will be set up through this roaming hub, so both options are available for our ecosystem and a given network could choose one the other, or they can even they can even mix the two depending on who they are. Roaming partners are. So on this slide I would like to talk about a mistake that we do encounter in the ecosystem. So as I have explained earlier, the device address. One part of that device address signifies who the home network is. And then only join request side one part of the request signifies or identifies who the joint server is. As such, the way the device addresses form or the joint requests form a special attention needs to be given how these fields are populated. Meaning that if someone uses randomly chosen device address, they would obviously have the so-called network ID part being random. An when a device with a random device address happens to be roaming under other networks, those other networks, those visit networks cannot identify the home network, so your device would be basically lost, its traffic would never find home. So that means when assigning device address your devices you have to make sure. You form the device address using the network ID based on the net ID assigned to your network by the Laurel lines. You shall not use randomly chosen device addresses. Similarly, the join you I and also in the early version of our specifications we have called that you I shall not be a random value. It shall be a value assigned to a joint server that is meant to be identified by the visitor networks. If you were to use randomly chosen join, you guys in here that does not point to a real joint server. Once again, your devices cannot find home. When they try to activate under the coverage of visit networks and also the the value even if that value is assigned to a joint server, that value shall be generated from the so called IEEE. All UI, which is another unique ID, this time assigned by IEEE. So you should not just pick your own join, you own your own. Instead, you should generate join EY by using the. I should play assigned organization unique ID all UI so there all this ID management schemes behind the generation of these values and we would strongly advise you not to to to comply with such assignment to make sure your devices can take full advantage of forming and they don't get lost in the wilderness once they're running. So that's actually this is my last slide as you see it. We have a very powerful technology and we have a very collaborative ecosystem behind it. So whether you have a private network or a public network, we would like to invite you to build your network and join forces with the others through roaming and after all our objective is to enable massive IoT by bringing low-cost, low-cost low power an ever expanding Lowen coverage to to all use cases of IoT around the world. With that I would like to thank you for listening and now back to your me. Thanks, I'll perform this comprehensive an insightful presentation we will open for Queenie in a moment. But first, I would like to thank our destination Lauren sponsors who helped make this webcast possible? Thank you to matching your Comcast company as the destination. Lower 1 gold sponsor and our two silver sponsors, Birds and Charter Communications. Each. Well, we all know how Lions members who participated today please take a few moments to learn about the amazing benefits that are available to lower alliance members by viewing the membership benefits documents under the resources section. The Lions drive the future of Lorawan and we want all of you to help shape the future. The Lions will be bringing new content nearly every week to destination Norwood. Please visit the destination. Lower one engagement hub and sign up for notifications for upcoming webcast. If you or a colleague would like to view this webcast again, and undemanding session will be available in approximately 48 hours and can be accessed using the same audience link you used to attend to death today's webcast. No, we would like to open it up for clinic. Thank you. Alright, so let's see we already have. We already have a number of questions coming in, so please continue adding your questions to the chair in a box. And I will start reading anything from there. OK, let's see. The first one is from Nick. Nick said, say say I'm using a Lauren network of a telecom provider in a country. If I then go to another country where they're only public networks, then the telecom operator needs roaming agreements with all of those public networks, right? OK, so this is the scenario where you are a subscriber to a network, but your devices. Are either visiting other countries, other network coverage or they are permanently roaming in those countries and you being in a need of roaming. That you are a subscriber to an operator. You would have to rely on that operator setting up roaming with the others where your devices are located. Alternatively, if you were if instead of relying on a public operator to subscribe, if you had if you were running your own network. Then you would be responsible for setting up roaming with the other public networks in other countries. So the first case is that public to public roaming case. The second one is the private to public roaming case. In that second case, the private network is owned by you and you would be in charge of setting up roaming. I love me like this. OK. Alright, so then the next question is from Anna. Starting at which version of Laura when roaming is possible? In particular private public running and private to private? As I had covered the end device. Is nuts really part of the running signaling? The roaming is totally transparent to the end device. That's why we call it passive roaming. As such, any version of the Linkedlist spec implemented in the end device. Can be subject to roaming now. The whole scheme drawing scheme is working on the back end side, so you need to have a network server an working with joint server that are complying with the back end interfaces spec and the very first version of that specification already supports Ronnie. The question from Jim is. Does Laura when roaming support as roaming consortium model where an operator joins? The concerns seem to get running support on all other member networks right now. At the moment the roaming is bilateral, all the networks you see on that list. They do set up their roaming agreements in pairwise fashion, but obviously as the as the deployments evolve we will be adopting such such schemes from legacy assistance as well. Where networks will create consortium's and joining one will open roaming capability with any other network in the consortium in terms of the standard and the technology and and the implementations. As such, a scheme does not recording extension, it's just a measure of business setup. And configuring platforms accordingly. So in a way, all the implementations and the standard spec is already ready for such a case. It's a matter of the market evolving and demanding this be set up in a commercial sense. Um? OK. This question is from morality, moral? It are what is borderline troll in roaming agreements with operators. Actually the roaming agreement is as a matter among the networks. Loretta Lynns is not a part of that. Agreement, typically it involves a commercial agreement. An it is carried out independently by the Lora Lora Wan ecosystem players. Without the lower lines being involved. Um? OK, so this one is from a release from talk pool. My iPad. Is there a commercial strategy set up? In other words, what does it cost to use another network or what can we earn opening our network today to others? So again, there's there's a commercial method that is discussed and acted upon. By literally among two operators an it it differs from one to the other. There are several factors. One of which is the the radio. Network coverage of the network. The quality of the deployement, the types of Slas that can be provided, etc. And these are the factors shaping up. The commercial elements, but again, there are several other commercial elements, and this is a discussion for you to have with your roaming partner networks, whether they are public network, private networks. Hey I'm just. Managing the questions. Bear with me for a second. Yeah, OK, another question from Amado is very similar. What about billing young costs fees for roaming between different networks? Again, it's it's. It's a commercial matters. So Alliance or Lorelei standards do not have anything to say on that. It's left to the market to decide among themselves. OK, this question is from here useful. He is asking how can we change joint server ID once we deployed the server or is it possible so the joint server ID is the so called joint in UI or in the earlier version of our specification? It's called Fey. Now this value is set on the joint server and it's also set on the end device. Now you can change. You can change this value, but you would like to make the change in a coordinated way. Let's say you have provisions this join UI on a batch of devices and you have already diploid those devices. Now if you change this value only join server then you would lose synchronization. So you'll have to make sure the changes on the on device and join servers synchronized. If you choose to change it on join Server. On the other hand, you may have reasons to change it on the end device. Say you want to migrate the device. Device credentials from one joint server to the other. You can do so by changing the join. the UI on the on device. As long as you ensure the credentials are also migrated from Legacy join Server to the new one, everything will continue working as before. So just just remember join EY is a pointer that's set on the end device points to join Server. So when you're changing it you have to keep this in mind, but otherwise yes you can change this value. Just make sure to coordinate it in your system. Um? Please. OK, so this question is from Philip. What is the architecture for satellite Connection Direct uplink downlink connection from devices satellite yes. So with the new data rate called long range frequency hopping spread spectrum that comes up with the latest regional parameters document. We are able to set Direct Connection uplink connection from any devices on the ground with the Leo satellites. LRF HSS is used for uplink only. And downlink, if we are using. If the Department is using downlink and if it is using or when it left to be using the Laura data rates or lower modulation, but the uplink for Scalable Teresa. Would be LRFHSS. And the scalability reason is these satellites usually very very big coverage area in the order of hundreds and thousands of kilometers. Even that there would be so many devices within that coverage area uplinking their frames. We have this new data rates to accommodate super high scalability. That skin on one side provide provide. Uplink connectivity through satellites. And also in terms of deep indoor coverage that also significantly. It provides a significant boost to the scalability of deep indoor cases. But the rest of the system, whether the base. Station is mounted on Leo satellite or on the ground. It's just the same. They just need a backhaul. Obviously this satellite hovering above Sky. It's that cold is also a radio link which is not using more about some other satellite connected connected to technology to bring the demodulate frames down to the ground. And then those frames are pushed through a network server and from there on it's business as usual. Interconnecting to the Laurel and roaming fabric. Yeah, so an as is asking as an adapter member we have been assigned a Type 6 net ID. Does it mean that we may need to apply for a type zero or three that ID in order to other small devices? That is true that Type 3 has the largest largest address base. Then, or larger than text 3 which is larger than Type 6 as you grow your business. If you feel pressure. On the other space, then the option with providers or alliance. Is to upgrade your membership that will come with a larger address space. Anne Anne Anne Wilding should be aware that for those devices that are not roaming you can already use the reserves. Net ID value is zero and one. Which already comes with 25 bits of address space that can be used by anyone, as long as those devices are not roaming. You can freely or use those spaces, but for your roaming devices in order for them to find home, you would need to use your dedicated net ID. And the Type 6. Net ID has its own space that provides. Yeah, you make a device addresses. Anne and yes, you would need to upgrade your membership to to get larger and larger spaces. OK, Ann and Paolo is asking if I set up my own Lauren Network of devices, do I still need to put him in a tidy? Definitely not. If your devices are not roaming you do not have to have a dedicated net ID. You can instead use the net ID value 0 or net ID value one which is reserved for as a shared. That idea that can be used by anyone. OK, so let's see. Amado is asking could I rest any devices ID to the visiting network instead of using roaming scenarios like using a second hand device. Used the network before and definitely to be assigned to a new network forever, right? So as you might know we have. ABP device cenote devices. ABP devices come with their burnt in device address. And the OTA devices dynamically configured their device address from the network there attached to or joint. So if you are using an OTA device, obviously the next time the device joins. The network, the new one, can tell the device to change or to get a new device address. Now for. For your AVP device you will need to do this manually. But you can do that as well. So if you are buying a second. And device. That happens to be an ADP device. You will need to use some other friend mechanism to change its device address through USB port, serial port or NFC Bluetooth headsets or whatever interface it provides. And if it is an audio device, this can be done over the air over the low end join. The device will be performing, but in either case the quick short answer is yes. Yes you can do that. Your device is not stuck with the address it was configured from or by its previous. Network server. Um? OK so aleksandra. Has asked question, so here's how it goes. How do they extra? Processes affect to the joint procedure in terms of time. And later she elaborated, she said. I mean did not need to listen to the joint accepted from server for more time than in usual case with the extra process mean in risk for the time that window. So for the over the air activated devices the OTA device is the device. At the onset, sends a join request and then it awaits a joint accept to come in at a predefined time. If it does, and those predefined times are called RX1 RX to receive Windows if they join except does not come in time that it, it would attempt join again. And the device would keep trying. Join joining by sending join request until it receives a joint. Except obviously we have this backoff procedure to make sure the device does not drain its battery trying too hard. And on top of that, device can also have its own application policy to to take it easier or to to give it a break for awhile and then try again like a day or two later so. We did join except like I said, is expected within a well defined. Receive window and for that the device does not open up continuous reception. And visibility. Is for retaining the battery or or keeping the battery consumption under control so there is really no opening? Or listening more than. Usual case, I'm just referring back to the question, so yeah, but the system is very tight and designed to to preserve battery lifetime. So device device only opens a very short period of time. Listen to the preamble. If there's no preamble, it closes the reception window. If there's a preamble, it keeps listening and then it checks the join, except if it is. If it is for the end device it consumes and concludes to join procedure, if not. It goes back to sending the next train again, trying another attempt. I hope that answered the question Alexandra if not. Please ask again elaborate. Removed unwelcome um. Let's see do. Free construction. Um? OK, so this one is from Morrow, comparing with the regular GSM roaming services. Telcos has one agreement and the use of the extended network is built in balance among the telcos involved at the voice or data services. How about the business model for the lower one roaming service? Do we have any model in place to monetize the services? Right now there's ongoing work. Reflecting what what Morrow has mentioned here. Instead of having several wrong agreements or several billing and charging, having like another person that asked this question, could there be a consortium? Yes, there's ongoing work to set up consortiums where there will be a single bill at the end of the month, whereas there might be multiple parties involved in that consortium. Now, whenever applicable we are. We are importing such features from legacy systems. But given that we but we are not automatically importing every legacy approach to. Laura went roaming. 'cause for one we are building a massively scalable system for that. For that we're keeping the overhead low. An and for that we are keeping everything as simple as possible and we're only picking and choosing from legacy systems where there is immediate market demand and and also the cost of building that feature. Justify justify, I mean the benefit of building a feature justifies the cost, so that's why you would not see every bells and whistles in the legacy systems being reflected on too low and roaming from the get go, but instead will be mostly cherry picking and also developing our own native approaches because some of the features we have, like micro diversity, it doesn't exist in the legacy systems as such. It does present different benefits and also. Things we need to deal with and we do take care of them in our own way. I certainly expect to see what you just described my Rd to come up in the in the coming months. Thanks, this is answered as well. Um? Some of the questions, and that's really. I would say clear at the end. I'll come back to German and I'll actually let me let me ask. So Muhammad has asked a question about. Uh. Over is overseeing rights and administrative access I I think I would need some a bit more clarification on that one, but if you can re post your question with more clarification then I'll make an attempt at answering that. Thank you in advance. And similarly explain as asked in the mass deployment was kind of network setup. Do you recommend? I would need a little bit more clarification on that as well. 'cause it's a bit vague for me to answer right now. I will need your help. Um? Yeah, so OK, where is asking what is the RX late time window that is recommended for roaming like 5 four seconds. So well, we're working on a document that is about to be published. If it's a technical recommendation for. Operate operators in Europe for roaming. In that we are recommending a size 2nd. A second delay for the receive window and that seems like a safe window, but obviously what you like to do is to consult with your running partner in case they have a high latency backhaul, you would need to take this into account, but if things are typical. And then the 5 second delay should be should be fine. Hey. OK, so it's my is asking how can we build? How can we benefit from satellite gateways? Can we include them in our network, right? So actually we can have special web in our bilateral lines in the coming weeks on. On satellite networks. Please do join that, but until then, here's what I can tell you there are. There are satellite networks built by supply service providers and they are. They are independent standalone networks just like the terrestrial ones. So unless you're building your own satellite network, what you would like to do is. To to set up roaming with such satellite networks. It's just in the very same way as you would set up wrong with the telesia ones. You will identify your partner. You might remember there's already one on the slide that I had shown and then get in touch with them and and have a have an agreement to let your devices roam into their network and typically for those satellite networks the device needs to would have this standard Laura one stack, but it would have a special antenna. In order to maximize its chance of getting the modulated by the satellite, so there exists devices that can get some of their messages through even with regular antennas. But in order to increase your success, you would need to have a special antenna. And and and the rest is your device making his transmissions, and it's it being the modulated by the Lora Gateway mounted on the satellites, being beamed down to the ground station, going to the satellite provider Service Station, which feeds it into their so called Forward Network Server. And if you had set up a roaming with them that for in Network Server will push that uplink frame to your home network server and the rest is. Just as if you have received that uplink through a terrestrial gateway. OK, um any other questions? OK, it seems like we have. There is a set my specific question we have in document communication between device and just satellite. Um? Like I said, as far as we are concerned they would be using the LR FHSS data rates which you can find. Details are on that sand. References in the lorwyn. Regional premises documents and above that is standard floor when. This is as far as we can provide within the Lore Alliance. If you'd like to have more. Just for details about particular implementations, you would need to get in touch with the. With this specific satellite company. Alright, so we have. These are all the questions that. We have to answer now. Like I said, some questions who are not specific if the. If the people who posted those questions would like to elaborate, we have maybe a little less than that. A few more seconds, let's say to give you a chance. Otherwise. Device I would like to. Thank you for your participation and for your valuable questions. Please stay tuned for the future Laura Alliance webinars and we are looking forward to. Seeing you at the future events, thank you. _1615110192445

Join Alper Yegin, LoRa Alliance Technical Committee Vice Chair to learn about implementing and deploying LoRaWAN Roaming.

Through rich use cases, illustrating the LoRaWAN roaming feature, Alper will walk you through the technical details and inner workings to show the advanced features of LoRaWAN roaming that set it apart from competing LPWAN technologies. 

This is a great opportunity for infra vendors, public and private network operators, device makers and end-users that are seeking to use this feature to gain guidance. Alper will wrap up this session sharing some pro tips on how to maximize the effective use of roaming, and the current landscape of roaming capable networks available across the globe. 

_1615110192545