good morning good afternoon good evening depending where you're connecting from my name is pedro mendoza i'm a solution psychic tech in the aws iot team and today is my pleasure to present a session on how to set up a private dota1 network using aws iot this is the agenda for today we will start doing some introductory explanation of the lora and lorawan concepts and then we will move into explaining the benefits of bringing together lora1 and aws iot next we will dive a bit deeper into the process to actually set up the gateways and device in order to be able to connect to aws iot core follower one and we will dive deep into the different components that build up the aws iot core follower one service we will also inspect some of the key flows within the service finally we will do a demonstration of a solution that is used in the service and we will finish the session by including some reference to what our customers are already doing using the service so let's start with the lora under one introduction these are basically the technologies underlying the technology that we are explaining today laura is one of the technologies in the lp-1 family lp-1 that stands for low-power white indian networks is a technology set of technologies that are intended for devices that needs to send a small amount of data over long distance in addition to lora there are other technologies in this family you can find as well narrowband iot ltm or sigfox as i mentioned before these are technologies that are aimed for devices that are really constrained in terms of usage of power that's why these devices need to run for example over 10 years and are typically battery operated what makes lora special in the family of lp1 technologies is the fact that it uses unlicensed frequency spectrum as a consequence it is possible for the lora users to set up their own private networks lora and lora1 are terms that are typically used together so let's spend few seconds to explain the difference between them lora is the communication protocol that is used to translate the data captured by the sensors into electromagnetic signals that can send to the gateways on the other hand lora1 is the set of open standards that are used to interconnect these devices to form larger networks lora1 technologies are basically managed by the lore alliance that includes over 500 members and aws is one of these let's take a deeper look into the different components in the typical lorawan network from left to right you can see the lora devices these are sensors or actuators that will be actually capturing the physical signals and sending it over using the loader protocol this message will be received by the lora gateways that will basically be devices that are connected using cellular connectivity or wi-fi or ethernet and will be basically forwarding this message coming from the devices into the lora1 network servers there are two main packet for water technologies the legacy packet for water which is using a udp protocol and the newer basic station that uses tcp and specifically secure websockets to send the data to the dota 1 network servers the next component in the diagram the lns or lora1 network server is the component responsible for actually receiving that data from the gateways and sending it to the consuming applications in addition to that the lns is also responsible for duplicating the data as you can see in the diagram the same device can reach the lns using different or more than one gateway so that's why important that the lns perform this data due duplication it will also be responsible for ensuring the authenticity of the devices connecting as well as the integrity of the data complementing the lora1 network server we have the join server who is a component responsible for generating the security keys that are going to be used to ensure the confidentiality of the communication we are using in loro1 technologies two different keys the first one is the network session key that ensure confidentiality between the device and the lns and the second is the application session key that does the same but in this case between the device and the application server these keys make use of the standard advanced encryption standard cryptography so what is the application server the application servers were actually the solutions are built based on the data ingested from the lora devices these solutions can range from simple storage and visualization solutions up to more complex things like for example doing machine learning based on the data ingested from the devices now let's dive a bit deep once we have the concepts around lore and lorawan let's dive a bit deeper into the actual integration between these technologies and aws iot core combining the benefits of these low-power long-distance characteristics of lore and lorawan technologies with the richness of the aws ecosystem is a very strong value proposition for our customers that's the reason why we have designed aws iot core folder one as a managed service to enable the deployment of private door one networks that can easily and securely connect to aws iot core on top of it our customers can then leverage the richness of the integration between aws iot core and the rest of the aws platform some of the characteristics of this managed service are x-high scalability and security so by providing these dimensions to the customer we allow them to actually focus on what make the problem unique which is basically generating business value using this technology i would like to double down on the fact that the customer will don't need to worry about any operational concerns that is actually undifferentiated from one problem to another we will take care of patching the software underlying the service we'll take care of dealing with an increase in the the traffic coming from devices and all these dimensions finally uh if we refer to the previous diagram as you can imagine now the the overall aws platform is replacing the role the traditional role of the application server so let's dive a bit deeper into the process to set up and integrate both gateways and devices into the aws iot core folder one service first let's talk about the gateways as we mentioned before the gateway's responsibility is actually forwarding this package that are coming from the devices towards the lower one the door server in the specific case of aws iot core folder one will require that these gateways are running basis station packet for water protocol and it will use tls 1.2 and specifically mutual authentication to secure the communication channel from the gateway to the lms it will implement this motor authentication based on x-549 certificates in terms of protocols for the data plane it will use secure web sockets and we'll use https for the management and configuration connectivity with the cops component in the lora1 network server in terms of gateway selection you can basically choose between two options first of all we have been working with the major gateways manufacturers in the industry to qualify a set of gateways so it's very easy to set this up and integrate with aws iot core follower one these are gateways that are pre-configured with the right endpoints as well as the required certificate for implementing this tls motor authentication so it will be a single configuration step to get this up and running alternatively you can also use of the shelf gateways in that case you will need to make sure that you are filling all the requirements and you will also be responsible for configuring the endpoints in order to connect to the aws iot core follower one service you will also need to upload the vendor provided certificates at the bottom of the slide you can find a link with all the devices that are already qualified to properly work with aws iot core follower one this is just a sample command that shows what are the input parameters required to configure a gateway in aws iot core follower one as you can see it's a really simple command all you need to provide is the gateway eui and in this case we are referring to one of these pre-configured gateways so it is also provisioned with the writing points and also the required certificate moving to the devices in this case we are talking about devices that supports either the 1.0 point x or 1.1 1 specification right and we support both over the air activation as well as activation by personalization mechanism the main difference is that in abp or activation by personalization the keys the security keys that guarantee the confidentiality of the data transmission are pre-programmed so it is less flexible on the other hand ota is using keys that are dynamically generated these are keys that we will dive a bit deeper are generated by the joint server and it is the joint server responsibility to actually distribute this to both the lns as well as the application server finally i would like to mention that as happens with the gateway once the device has been registered with aws iot core follower one it will be listed as another thing in the aws iot core thing registry this is an example for how you can actually run a command that will register a new device in aws iot core follower one in this case if this is a device using ota or which which basically stands for over-the-air activation which is the mechanism for generating these keys in a dynamic way in addition to the devices uae ui application key and application eui you can see in this command line that you should also provide a destination which is basically the name of the wool in aws iot core that will be responsible for processing the message that will be ingested coming from that device we will dive deeper into the intent of this rule in a second now that we understand what is the process to set up the gateways and devices let's take a deeper look into the different components that are inside the aws iot core follower one service we can see we have three main components first of all we have the lns as we mentioned it will be responsible for doing data decryption it will also be responsible for duplicating the message in case the device are using or our vision is reaching more than one gateway it will also take care of validating the authenticity of the device as well as the integrity of the data being transmitted last but not least it is responsible to forward the uplink message coming from the device to the downstream consumers in this case iot core and also doing the opposite one so being able to send the device the messages coming from aws iut core down to the devices what we call the downlink messages in addition to dna lns we have two other components in the service we have the cops which is responsible for gateway firmware and configuration task and we also have the join server that as we mentioned before is the one that use or generates the security keys both the network session key and the application session key to ensure the integrity of the communication between the device and the other components in the lora1 technology okay so let's take a quick look at the uplink data flow as we mentioned this is the flow that comes from the device up to the aws iot core folder one service first of all as we mentioned the device during the configuration phase has been configured with a destination that is where the actual message will be processed this is part of the aws iot core rules engine which is basically a component intended to ingest large amounts of data at low cost the rules engine has capabilities for filtering transforming and finally routing this message into final destinations what did what we call actions these actions include storing in dynamodb or s3 but also integrating with other services like sqs or sns for alarming or notification use cases uh and can also do more complex tasks like for example sending messages to edwards iot analytics or aws iot events we will dive a bit deeper as part of the demo an important characteristics of the integration of the lorawan devices and the rules engines is the fact that due to the bandwidth constraint that is associated with the lora1 devices they will typically send data in an encoded format that's why as you can see in the diagram the very first step is to decode that payload so it can be properly consumed by the downstream consumers that's actually the role of the lambda function that you can see in the diagram once decoded there is a rule that will be republishing that message into another topic and then it can be consumed like for example by amazon s3 or amazon sqs in the example it could be any other of the actions supported by the modules engine in addition to the task or the features to ingest the data and also send downloading messages to the devices edwards iot core follower one also includes features for monitoring the status of the gateways and devices specifically you can have information about the frequency being used by the device but also about the data rate the different gateways that are receiving the the signal and also the standard strains other indicators such as the signal to noise ratio in addition to this management task the gateway firmware can also be updated using the cops component and you can also use as we have been discussing the aws iot core follower one features for sending messages down to the device what we call the downloading messages so now let's take a quick look into the demonstration before we actually get into the architectural diagram on the console i would like to show a bit of the context so the demo today is about monitoring the health of a plan right so we'll be basically uh sensing the level of moisture in the soil where the plant is living and we will use that information in order to model whether or not the plant is healthy so let's first introduce our components today so we have our plan right we have our sensor in this case it's as i mentioned it's a soil moisture sensor right we'll be sensing the signal here and it will be connecting over the the lora network and finally we have our gateway this is one of these pre-configured gateways that has been already configured to be able to connect to aws iot core follower one correct this is coming from one of our partners so let's go first into the architectural diagram as i mentioned uh the intent here is uh to basically uh sense the the level of moisture in the in the soil where the plant is leaving and we'll be using a lot of one sensor for that this sensor uh will be basically sending the data uh to a gateway that uh would basically forward that information as as the as the gateway's role into the lora1 network server in this case this data is eventually going to be ingested in the adobe iot core folder one as you might imagine both the gateway as well as the device has been already registered with aws iot core follower one using commands similar to what we saw before the in order to be able to actually process this message this device has also been configured in order to target a specific rule in aws iot core rules engine as we mentioned before we are going one of the attributes in the message is actually the level of moisture in the soil that's exactly what we are doing well as we explained the previous uh diagram uh one of the first tasks that we need to do once we are once we have ingested the data is actually proceed and decode this payload because of the restrictions associated to the bandwidth of the lora devices we basically need to transform it into something that the downstream consumers can actually use we do that by invoking a lambda function that is associated to a rule in iot core once we have the code the payload using the lambda we can then republish that information into another topic this topic is also associated with the second rule that will simply forward the recorded payload into a detector model implemented in aws iot events this is the model where we'll basically identify what is the state of our plant finally whenever this model transition from one state to another we will see that in a second we will be sending a notification to the user we do that by sending an sms message that is actually coming from an sns notification topic in addition to getting this notification over sms the user is able to also monitor the status of the of the plan and actually even inspect the message by using a web application that has a subscription into the mqtt topic that contains the already decoded payloads in addition to that there is another data flow that is about sending data down to the device but i suggest that now we move into the actual console and we see the application in action we can then later get back to the downlin use case so this is the web application that the user will basically see it is composed by two different views first we have the business user view which as you can see simply render the level of moisture in the soil and is complemented by a technical user view where we are actually dumping the message both the encoded as well as the decoded version of the message you can see in the upper section we have we we have the encoded um the encoded payload and then in the bottom of the of the page we can see the already recorded attributes including the level of moisture complementing that you can see that we also have some metadata information including the message as i was referring before you can see there which gateways has received the message and you can also see other indicators like for example the frequency or the signal to noise radio as you can see now we are really getting a zero reading from the sensor and the reason is because the sensor is just not inserted into the soil let's take a look into the actual message by using the mqtt client that is a part of aws iot core and we can see here both the encoded as well as the recorded payloads now let's follow the trail of the data so the first thing we do is basically we have a rule that as we explained before will be associated to the topic where the data is still encoded and will invoke a lambda function using as input some of the attributes contained in the message this lambda function will be responsible to actually decoding that payload into something that can be used by our downstream consumers if we take a look at that into the landing implementation you will see that the first thing we do is perform a base64 decoding and then we take the basis for the coded version of the message through a series of transformation in order to eventually produce a json document that contains all the recorded attributes now that we have to decode a payload the next step will be actually sending it down to uh to a new a new topic we are basically republishing that into uh into a new topic which is a quite simple action we have a second rule that is associated to this decoded topic and we are not really doing any transformation or filtering here instead we are simply forwarding it to our detector model implemented in aws iot events aws iot events is a is a service which is part of the adobe srt family of services and it's intended for doing complex event processing it is something that you can use to basically model the different states that your model uses and also the transition between this in this specific case we have three main states we have a state that where we don't really have any information we have not received data from the sensor yet and as you as you might expect you have two additional states when the plant is healthy and when the plant is dry the transition between these states are basically conditioned by messages that are coming from aws iot core ultimately from the device and as you might expect we have a condition associated to this transition in this case we are comparing the observed value for our moisture with a pre-configured threshold right now we assume that anything above 20 is considered a healthy status and anything below is considered a dry status as you might imagine the corresponding transition in the opposite direction use the opposite condition in addition to this transition each of these states can have actions associated to entering the state we take a deeper look into these actions we can see that we are executing or we are sending a notification using sms this is the mechanism that will enable you to actually send an sms message to the user whenever a transition between healthy and dry or the opposite happens you can see also the payload being used if we inspect the corresponding action entering the dry state it will be very similar the main difference will be that here we're sending a different message we can take a quick look at the current value for the state as well as the input variables and as you might expect right now we are in a dry status right we are not really sensing any moisture in the soil so now i will basically plug in the device into the plan okay and we should be getting a signal here we are sending data every 10 seconds so we should get a new reading quite soon okay as you can see here our level of moisture is above the threshold is about 20 percent so our iot advanced detector model should have transition into the healthy state let's take a look into that but i know it already happens because i have received a notification on my phone okay now you can see that because the the level of moisture is above that ratio we have transition into the healthy state okay so that's basically about the uplink data flow as i mentioned before is complemented with a downlink data flow in this case the user can use the web application to send messages done to the device this message will be sent into a command and control a topic that is also associated to analytical rule that will be invoking a lambda this lambda will simply use the api coming from aws iot core follower one service in order to send messages down to the device this message will be sent by aws iot core 401 to the gateways and eventually we reach out the device in the specific case of the device we can send downlink message to control the frequency of the transmission right now we are sending data every 10 seconds but let's take a quick look into how you can control that let's increase the frequency to 5 seconds and let's edit now we should be able to see that message in the corresponding command and control topic and here you here you can see the encoded version of that command and as i explained before there is a rule a third rule that is associated to that topic and will basically invoke a lambda function that we'll use the api for aws iot core 401 in order to send the message down to the device this is the statement that we just saw now we should validate that the frequency has been increased by basically taking a look into the message that are now being sent hopefully every five seconds we compare the timestamp we can see that now the frequency has increased to 5 seconds instead of 10. so that basically concludes the demonstration as a as i have been showing you can see both the uplink and dot link message flow so now let's go back to the presentation to finish i would like to refer to what some of our customers are doing already with aws iot core follower one first i would like to talk about compliance made which is a company in the food safety industry compliance mate has built a system that allows their customers to maintain compliance to food safety regulation compliance mate is using aws iot core folder one to connect temperature and humidity sensors in refrigeration units inside restaurants and they are doing that for monitoring and reporting purpose the second customer is quex quix is a company in the property management software sector that are using lorawan technologies as part of their home automation solutions they have built that solution around a single dragon gateway that connects to aws iot core folder one providing connectivity within the entire property in order to provide a full range of wireless devices that includes smart thermostats and door locks okay so that's basically what i want to present today my invitation is to please go and start using aws iot code for lorawan to build your own private networks and turn the data into business value you can build solutions by leveraging the whole richness of the aws ecosystem you can find additional information in the links provided in the slide you can access the console you can also check some of the samples that will help you to start building solutions and you can also definitely access the devices that has been validated in order to connect with aws iot core follower one thanks a lot and i hope that you keep enjoying reinvent
2021-02-08