 Hi, welcome to the KubeCon Europe session from the Kubernetes IoT Edge Working Group. I'm Steve Wong. I'm a co-chair of the IoT Edge Working Group. I'm employed as a software engineer working on Kubernetes by VMware. And I'm coming to you in this recording from Los Angeles, California. Hello, my name is Dan. I'm a software engineer with EarthHit. I'm also a colleague of Kubernetes IoT Edge Working Group and coming from Belgrade, Serbia. So here's today's agenda. We're going to give contact information in a link to the deck at the end. I'm going to start with a really quick overview of what's different about communications for edge applications and edge devices. Then we're going to move on with an introduction to some technology called LoRa, along with network architecture based on it called LoRaWAN. About halfway through, Dion is going to take over with a talk on the Drogue Cloud project, followed by a demo. Hopefully you'll like the talk. And if you do, we're going to wrap up with details on how you can become a member of the Kubernetes IoT Edge Working Group, where we host ongoing discussions on subjects like what's in this talk. Edge applications are often isolated, but they're generally going to be part of a bigger picture multi-tier architecture if Kubernetes is involved. You know, if you're using standalone edge devices that don't talk to anything else, you're unlikely to really have Kubernetes involved. But if you are connecting up edge devices to feed into applications and servers on a regional or global basis, that's going to be the scenario where it makes sense to utilize Kubernetes and that's what we're going to be here to address today. So if you try to do communications at edge the same way it's done in a large cloud data center, be prepared for some challenges and even a few roadblocks, particularly in mobile and in remote places that have wiring difficulties. Radio-based communication is an alternative to hard wire, and we're all familiar with the radio-based options like Wi-Fi, Bluetooth and LTE. Today we're going to talk about another wireless option, Lora. Lora, by the way, stands for long range. Of course this conference is also about Kubernetes, so we're also going to show how information or events can be collected from edge nodes to feed Kubernetes-hosted apps. I'm going to start with a technical overview and then later Dan will move on to cover the DROG project. So we're all familiar with Wi-Fi, which is an example of a local area network. Its reach is limited to perhaps tens or low hundreds of meters. Wide area networks bridge much longer distances. It always limits imposed by physics. So what you have here in this chart showing support of these different technologies measured in bandwidth versus range is going to face a situation where you've got to choose the right technology for the job. No technology provides all the attributes at once. For example, there isn't the technology that has maximum bandwidth at the same time that has maximum range. And by the way, this graph is two dimensions, so it only compares bandwidth versus range, and it's missing an important third dimension, which is power consumption. With regard to power consumption, older people remember AM radio stations, which could carry for huge distances, particularly at night. These AM radio stations use tens of kilowatts of power, so even 100 years ago people had figured out how to go long distances using high power. But what if you want to go long distances using low power as something you might have available in a low-powered battery device? LoRa is a technology that uses something called chirp modulation, which is capable of communicating at low power on potentially congested unlicensed spectrum. Instead of using a constant base frequency, it uses rising and falling pitch as a basis for transmission. It's robust against interference because it can filter out anything that doesn't have the rising and lowering pitch characteristics and ignore it. Interestingly enough, this changing pitch concept is something that's used in nature by whales, dolphins, and bats. The important thing to notice, by the way, is that with LoRa, the frequency used, unlike Wi-Fi, is not globally harmonized. This is because it uses unlicensed spectrum, and in different parts of the world, the unlicensed spectrum falls into different frequency bands. We don't have time today to go into a deeper dive detail about LoRa, but it features something called a link budget. And this is a budget that can be spent either to achieve long range or better than average penetration through building walls or a little of each at the same time. And this is very important when you're dealing with a low power radio technology. This is an example of a device that we're going to demo later in this talk to give you an idea of what's out there. This is one that I bought here in the US called an Adafruit Feather. The device features 300 microamps of power consumption while it's asleep at its peak during transmission at maximum power, this can go up to 120 milliamps of power consumption. And it would average about 40 milliamps of power consumption during active radio listening. There are alternate forms of LoRa that might even use less power. But these are potentially devices that could operate on a battery for as long as a year, if you vigorously engaged in going into deep sleep and waking a device up only when you needed to measure or transmit something. And we've only talked about the radio link from the device to whatever links do and that would be LoRa. But even though LoRa stands for long range, long range here isn't infinite. You know, let's call it line of sight up to 10 kilometers for common use cases and LoRa is the physical layer. LoRa is the radio plus the LoRa modulation, but in a practical scenario, you would often want to go longer distances than even the tens of kilometers. So, what you do here is put together a big picture architecture and if you compare this to what you've got in physical Ethernet links. The Ethernet can be used to build a point to point link, but this isn't really a practical network in an Ethernet scenario. You need to bring in switches, routers, higher level protocols, and management tooling. You also, you need these sorts of things that so that you can join devices together with other things. Coming back to the early Ethernet days, somebody called Metcalf proposed something called Metcalf's law that says that the value of the network goes up with the square of the number of connected nodes. LoRa is no different. We need to add a few more things to make this super valuable. What's shown in this slide is something called LoRaWAN. It defines a communication protocol and the system architecture for a network using LoRa to connect the devices along with allowing alternate transports like IP up at higher levels. LoRaWAN is managed by the LoRa Alliance, which is an open nonprofit association that currently has over 500 members. LoRaWAN is designed to incur very little overhead for a device to simply be present on a network. So it's great for devices that are usually in deep sleep most of the time to save power. Note that you can have devices that have LoRa but also have Wi-Fi at the same time and selectively use Wi-Fi on an as needed basis under relatively rare circumstances once again to save power. An example of a LoRaWAN network is the Things Network, which we're going to use later in the demo. This is a global cloud sourced example of an implementation of a LoRaWAN network. But it's possible to run your own private LoRaWAN network rather than to join into these alternatives like crowdsourced implementations or commercial implementations. So today we're going to use the Things Network and this is commonly abbreviated as TTM. So as part of this LoRaWAN architecture, moving from devices at the left, you have these connected to gateways. The LoRaWAN gateway receives LoRa-modulated RF messages from any end device that's within hearing distance and forwards these data messages up to the LoRaWAN network server that is just to the right of the gateways. There's no fixed association between an end device and a specific gateway. Instead, the same sensor could be served by multiple gateways in the area. The gateways operate entirely at the physical layer and in essence, there are nothing but LoRa radio message forward. They only change the data integrity of LoRa RF messages. If the CRC is incorrect, the messages drop. Otherwise, the gateway forwards it up to the network server together with some metadata that includes the received signal strength and an optional time stamp. For downlanks, a gateway executes transmission requests coming from the network server without any interpretation of the payload. It's just forwarding it on. Since multiple gateways could be in a position to receive the same LoRa RF message from a single end device, the LoRaWAN network server performs data deduplication and deletes all copies, typically saving the version that came from the gateway that reported the highest signal strength. The LoRaWAN network server, the LNS manages network and establishes secure AES connections for the transport from end devices to user applications in the cloud. The network server cannot see or access application data or at least can't access it in clear text. So here's a wrap of what we've learned. We've got some, we've got a technology called LoRa and higher level protocol built upon it called LoRaWAN. The suitable use cases for this are use cases where you need long range in multiple kilometers and with that LoRaWAN backbone, you can go worldwide on this stuff. The best use cases are ones that demand low power and this is capable of supporting devices that could last a year or more on a single battery change. It also supports low cost devices and here we're talking about 60 euros of capex per node and tiny amounts of operational expense. They are constrained to have low bandwidth so there are clearly use cases that demand higher bandwidth that aren't suitable but for things like event or measurement reporting that are in the range of reports once every five minutes or even less frequently demanding bandwidths in the range shown in the slide. This is a good match. Coverage is achievable essentially everywhere. If not, if there's not already a gateway in the area you can add your own and just like the devices are low cost, these LoRaWAN gateways are also relatively low cost. It does feature 128 bit encryption and the higher level network server can integrate data and event screens to apps using TCP, MQTT, HTTP, cloud events, etc. What's not suitable for LoRaWAN real time data, it can only send devices in small packets every few minutes, not continuous data streams. You can't use this for phone calls. You should use it something like LTE instead. It's nominally, at least in the LoRaWAN case, not designed for home automation, although SimTech does have some alternate technology for operating a private LoRaNet that can be used for home automation. Also not useful for sending photos, watching videos, you'd want to use Wi-Fi here. Thanks, Steve. So, we come with an idea to bring two worlds together with a drug IoT cloud. The rising interest in using Rust programming language to do embedded work and on the other side to do a serverless on the cloud side is what brought us to try to bring these two worlds together. So, the drug IoT project is all about providing on one side the tools for embedded developers to use asyncrust framework to do firmers and also try to use off the shelf platform built on top of the K-native eventing and try to build a seamless experience for people to build end-to-end applications. So, just a couple of words about the drug device. It tries to provide an actor framework for embedded devices, meaning that developers will have a concept of actors communicating and isolating their context and their state by passing messages between each other. On the other side, the draw cloud is built on, as I said, on top of the Kubernetes K-native and cloud events. We also are using cloud native Rust to build the accompanied services as we will see at the moment. And as you know, K-native eventing supports multiple brokering and messaging options as a backing technology. We prefer Apache Kafka for data plan and the message passing through the system as we will see. So, if we look at the data plan and how things look on this side. At the last session at the KubeCon North America, we talked in detail about the theory of using K-native eventing and the cloud events for IoT use cases. I encourage you to take a look at that video if you're interested in more into that topic. Here we can see that from the central part of the system we have a K-native and Kafka as a core of this serverless IoT solution. But you need a lot more services to make this really usable of the shelf IoT cloud platform. So, if you go on the southbound side on device side, we need a lot of devices connecting to our K-native and for that we need a protocol endpoints. For example, you know, transforming the MQTT messages or things that work payloads as we will see soon into the cloud events and pushing it to the K-native channels. But also we need a device authentication in our authorization so that we know that devices we are communicating with are actually our devices. On the other side, if you take a look at things, we also need to provide a way for to have a user authentication and authorization. Meaning that we need to authorize the access to the streams of messages coming from our devices. But even if we have that assuming that everything runs in a single Kubernetes cluster, we can deal with providing appropriate serverless services to deal with our data. But, you know, having all this as a hosted solution and potentially having IoT applications running in different clusters, then the cluster that is hosting the draw cloud, we need to provide different integration endpoints. For example, you know, the most usual ones are that people will usually either consuming data directly from the Kafka. And for that we will probably use something like a service binding operator to expose that Kafka cluster to the outside world and to the other clusters. Most IoT developers are very familiar with MPTT so we can provide them with an option to subscribe to the draw cloud as it was an MPTT broker. And in the final case, using the web sockets to develop web applications is something that's very, very common in this space. From the from the control plane side. In order to have all this authentication authorization both on the devices sites and on the applications and the user sites. We need to have some kind of a central registry of identities, and that's identities for for the devices and identities for for for the users for for the users and applications we basically use and single sign on instance. Based on on the or backed by the by the key code project and we provide a data device management API which allows us to use a UI or CLIs to actually manage our device data as you will see in the in the moment. One more important part of this is is the change events as we see on the arrow here. A typical, typical, I have this solution. Never consists of a single project. It's a distributed system by the nature. And each of these systems has its own their own registry of, of, of identities that needs to be to be managed. The idea behind the change events is to basically have, have a change event stream that will be able to provide operators and controllers, controllers on so that we can, we can sync multiple multiple registers. So, for example, in the future, it will be possible that once you, you're, you know, set your device in the draw cloud that device and you, you, you annotate the device that it's a it's a thing that were device that your things network service will be configured out automatically by the system. So, let's talk a little bit about types of devices that that we have and what we will use in the demo today. So, the simplest way is to have a single device connecting directly to the to the cloud. Right. That's a simple possible case. In some cases, as Steve mentioned, for example, using using the BLE or or or Z wave. We have devices that are not capable of reaching out to the public internet for and in that case, we need to have some kind of the gateway. And basically doing an IP onboarding of that device and being able to, to, to out be authorized by the cloud to send and receive data in, in behalf of, of, of device. And the most complicated case and the one that that we will, we, we set our minds on today is is some kind of long, long range scenario with Laura, where we have a device, we have a gateway. And that gateway gateway talk to some kind of a service things network, we can call it the, the, the, you know, IOT cloud gateway in this case, which is from, from the cloud perspective, actually a device and it's authorized to send data on behalf, behalf of, of a device. So, let's see how all these works in a, in a, in a very simple, simple, simple demo. So, we have a device that Steve showed sitting in his home in LA right configured properly in the, in the things network console so so here here is device. And what we need to do in order to connect to the cloud is actually to, to, to connect this, this device as an, as an, as an, as an device in the draw cloud. And for that, we need to do a proper integration. In this case, we will use an HTTP integration. And, and, you know, simply configure it that for every message that that the things service receives from device, it will forward to our cloud solution. And for that we need to specify a couple of parameters, which is like a URL, the authorization it will use and we will see that that that in the moment. But you can see that that already here we have two different identities. So we have an identity of the things network service that the authorize itself. And that's, that's our application here, and the actual device belonging to that application that will send data data to the cloud draw cloud. And for this demo, we will use the sandbox of the draw cloud which comes with a with a simple console and and we will see how to use the CLI at the moment. So what we need to do here, in order to make it make all this work is basically create an appropriate appropriate, sorry, is to create appropriate data in in our device registry. For starters, we are creating our application so so that's the concept of the draw cloud, which allows us to group multiple devices into a simple into a simple single single application. Next, we will create an actual device, we will call call it the TTN service, and it will represent our gateway or service connecting to the cloud. And we will pass this, set it up to be able to connect with the appropriate appropriate credentials and provide additional metadata about the payload it expects from the device. But the job here is not done, because we also need to create an actual representation of the device that will send the data. And you can see in this case that we are not specifying the credentials for for device, but but we are just saying that this device will connect to appropriate gateway, which is the name of the previously defined device in the in the draw cloud. Now, with all this properly set. We can actually expect to receive data from from from the from the from the device. This is configured to send data every five minutes. So hopefully it will, we will not wait that long for for the for the next for the next message, the data. Let's give it a, I think, a couple more seconds and things should should. Well we'll cut this down when we edit the video but what was the time stamp on the last data and we should get another one five minutes after that. I think it's, it's just, yeah, and here it is. Here's the data in the console. And here's the data in the in the entity client. And as you can see, the, the, in the both cases, the data is is a properly structured cloud event with its own source and type. So, so that applications can can be easily written and and consume this data for for their own. So, I'll get back to Steve at this point. You're muted Steve. Thanks for that great demo and just to point out my device here that I'm holding up is coming from Los Angeles and the on and I are a 1313 hour flight away. So, this is definitely long range although Laura can carry it the bulk of that range it. Once it hit the things that work I think that it went over the backhaul. If you like the presentation today and you like topics like this that relate to using Kubernetes for applications, either running on the edge, or supporting data and events collected from the edge with Kubernetes hosted applications and services at a mezzanine tier or a cloud tier. So, in this group we have meetings twice a month, they're at alternating time so we have one series that is optimized for people in North America, and the North American meetings report, repeat every four weeks. We have another series that was optimized for Asia, Asia, Eastern Europe. And once again there. We're in the center middle of the night if you're in North America but a better time for other locations, and they repeat every four weeks. We've also got a slack group. In addition to the meetings. So you can go on there and ask questions. The content that the user group meetings is intended to be user driven. So if you've got any subjects that you'd like to see presented on or talked about. And you're a member. We invite you to nominate topics and as co chairs will attempt to drive that to please the user base. It's the next slide. Yeah. So, here's a link to where the deck is published on the sketch site. We're both on GitHub, and we're both available in the slack channel. We're going to hang around in case you have questions. So, thanks for attending.