0 1 00:00:00,960 --> 00:00:05,310 The second activation method is called OTAA, over the air activation. 1 2 00:00:06,150 --> 00:00:09,540 The purpose of this method is exactly the same as ABP. 2 3 00:00:10,230 --> 00:00:16,560 Indeed, after the activation process, the end device and the LoRaWan server will have the same device 3 4 00:00:16,560 --> 00:00:21,510 address, the same Network Session Key and the same Application Session Key. 4 5 00:00:22,620 --> 00:00:32,160 However, while in the ABP method, these session keys were always the same. When using OTAA, they will be regenerated 5 6 00:00:32,160 --> 00:00:34,170 after each activation procedure. 6 7 00:00:35,160 --> 00:00:41,490 That has a lot of advantages that we will see later, but for the time being, let us see how the session 7 8 00:00:41,490 --> 00:00:45,760 keys are generated. When we want to use OTAA, 8 9 00:00:46,200 --> 00:00:48,270 we need to define three parameters. 9 10 00:00:48,900 --> 00:00:55,910 First, there is the DevEUI, which is the unique identifier for LoRaWAN end-device. We use the 10 11 00:00:56,020 --> 00:00:59,700 DevEUI during the ABP activation, but it was not compulsory. 11 12 00:01:00,240 --> 00:01:03,030 This time it is a mandatory information. 12 13 00:01:04,170 --> 00:01:08,820 Then secondly, there is the AppEUI or JoinEUI. 13 14 00:01:09,450 --> 00:01:13,080 Depending on the LoRaWAN version you are using, the name is different. 14 15 00:01:13,470 --> 00:01:18,870 But to keep it simple and to avoid confusion, we will call it AppEUI JoinEUI. 15 16 00:01:19,650 --> 00:01:23,190 We will not use this parameter much during this course as it's supposed to be 16 17 00:01:23,190 --> 00:01:29,340 the Join Server identifier. The Join Server is useful for roaming or charging operators. 17 18 00:01:30,150 --> 00:01:35,910 And you can find a description of its functionality in the book if you are interested, but we will not explicitly 18 19 00:01:35,910 --> 00:01:38,220 use a join server during our demonstration. 19 20 00:01:38,700 --> 00:01:41,940 So, in this course we will often leave it at zero. 20 21 00:01:43,290 --> 00:01:46,380 Finally, the third parameter is the Application Key. 21 22 00:01:47,070 --> 00:01:49,920 This key must be kept secret because it's the root key. 22 23 00:01:50,730 --> 00:01:54,960 Root key means that it is the key that will be used to generate the two session keys. 23 24 00:01:55,830 --> 00:01:58,200 So, we have all the information we need. 24 25 00:01:58,470 --> 00:02:00,750 And again, there are two possibilities. 25 26 00:02:01,440 --> 00:02:07,470 We either have this tree information from the device maker and we just have to register them in the Network 26 27 00:02:07,470 --> 00:02:07,890 Server. 27 28 00:02:08,130 --> 00:02:12,840 Or, we can generate them on the network server, then copy them afterwards 28 29 00:02:12,870 --> 00:02:13,890 in the end-device. 29 30 00:02:14,460 --> 00:02:20,250 Once again, I insist that this tree parameters will just be used to obtain the useful information needed 30 31 00:02:20,250 --> 00:02:26,700 to the LoRaWAN transmission: the device address, the Network Session Key and the Application Session Key. 31 32 00:02:27,960 --> 00:02:29,610 To generate these session keys, 32 33 00:02:29,940 --> 00:02:33,930 the end-device needs to send what we call a Join-Request. 33 34 00:02:35,040 --> 00:02:41,460 This Join-Request frame is the first frame that will be emitted by the end-device when it starts. 34 35 00:02:41,460 --> 00:02:42,870 And after the join procedure, 35 36 00:02:43,530 --> 00:02:50,370 if it was successful, then the server and the end-device will both have the same device address, the same 36 37 00:02:50,370 --> 00:02:53,520 Network Session Key and the same Application Session Key. 37 38 00:02:54,720 --> 00:03:01,650 Of course, the first three parameters DevEUI, AppEUI, JoinEUI and App Key will remain in the end-device 38 39 00:03:01,650 --> 00:03:05,340 and in the server, but we will not use them anymore. 39 40 00:03:06,000 --> 00:03:10,920 However, if we want, we can launch a new join procedure to regenerate the session keys. 40 41 00:03:11,790 --> 00:03:16,530 We will explain later why and when it can be useful to regenerate the session keys. 41 42 00:03:16,800 --> 00:03:23,130 But for the moment, you can just consider that any successful join procedure leads to a proper LoRaWAN 42 43 00:03:23,130 --> 00:03:23,760 transmission. 43 44 00:03:25,080 --> 00:03:28,020 We can detail a bit the join procedure. 44 45 00:03:28,230 --> 00:03:36,690 First, the end-device sends a Join-Request. Inside a Join-Request, there will be the devEUI, the AppEUI/JoinEUI 45 46 00:03:36,690 --> 00:03:40,470 and a message to authenticate the Join-Request. 46 47 00:03:41,460 --> 00:03:47,790 The authentication is fundamental because for security reason, only a register end-device is allowed to 47 48 00:03:47,790 --> 00:03:54,510 send a Join-Request on a specific server. So the Network Server will authenticate the Join-Request frame 48 49 00:03:54,990 --> 00:03:58,400 and it would generate a device address, a Network 49 50 00:03:58,400 --> 00:04:05,010 Session Key, and an Application Session Key. But this LoRaWAN information are not yet present in the 50 51 00:04:05,010 --> 00:04:05,730 end-device. 51 52 00:04:06,300 --> 00:04:09,690 So how can we transfer them from the server to the end-device? 52 53 00:04:10,440 --> 00:04:12,480 This is done thanks to Join-Accept frame. 53 54 00:04:12,480 --> 00:04:15,840 In the Join-Accept frame, 54 55 00:04:16,230 --> 00:04:20,910 there will be the device address but it would be also a few other parameters. 55 56 00:04:21,450 --> 00:04:24,410 These parameters are really important for two reasons. 56 57 00:04:25,200 --> 00:04:29,490 First, they will be used by the end-device to generate the Network Session Key 57 58 00:04:29,490 --> 00:04:36,090 and the Application Session Key. Once again, that is mandatory to get a proper LoRaWAN transmission. 58 59 00:04:36,630 --> 00:04:42,750 But at this point, we can wonder why all this mess. Because we end up here with the same functionalities 59 60 00:04:42,750 --> 00:04:44,730 that we had in the ABP activation. 60 61 00:04:45,210 --> 00:04:50,340 The answer is that there is a second reason for why these parameters transmitted in the Join-Accept are 61 62 00:04:50,340 --> 00:04:50,910 important. 62 63 00:04:51,810 --> 00:04:55,170 It's because they also provide useful information on the LoRaWAN 63 64 00:04:55,170 --> 00:04:56,400 Transmission settings. 64 65 00:04:56,880 --> 00:04:59,580 That is what we will detail later when we will compare ABP 65 66 00:04:59,970 --> 00:05:01,560 and OTAA activation. 66 67 00:05:03,970 --> 00:05:08,200 So, I'm back on my console and in the device section 67 68 00:05:08,680 --> 00:05:12,460 I am going to manually register a new OTAA end-device. 68 69 00:05:13,270 --> 00:05:18,040 In our case, I choose the European 868 MegaHertz frequency band. 69 70 00:05:18,910 --> 00:05:22,580 I choose the right LoRaWAN version of my end-device. 70 71 00:05:22,600 --> 00:05:24,850 In my case, it is 1.0.3. 71 72 00:05:29,360 --> 00:05:32,630 I can check that I am already in OTAA activation mode. 72 73 00:05:34,660 --> 00:05:35,170 First, 73 74 00:05:35,290 --> 00:05:36,820 I need to give the DevEUI. 74 75 00:05:37,510 --> 00:05:41,050 I have got one for my device already, so I can copy it here. 75 76 00:05:41,440 --> 00:05:43,240 Otherwise, I could have generated it. 76 77 00:05:44,470 --> 00:05:46,960 Secondly, I need to provide the AppEUI. 77 78 00:05:47,740 --> 00:05:55,810 You can see that if I change the LoRaWAN version to 1.0.4, then the AppEUI name is changed 78 79 00:05:55,810 --> 00:05:56,220 to JoinEUI. 79 80 00:05:57,160 --> 00:06:01,060 We say that they are the same and indeed they just have a different name. 80 81 00:06:02,290 --> 00:06:05,650 So, I go back in the 1.0.3 version. 81 82 00:06:06,400 --> 00:06:08,800 As I said, we will not use it much. 82 83 00:06:09,610 --> 00:06:13,150 And, this LoRaWAN server even propose me to fill it in with zero. 83 84 00:06:13,660 --> 00:06:14,680 That is what I am going to do. 84 85 00:06:15,670 --> 00:06:18,880 So now we still have to provide the AppKey. 85 86 00:06:19,900 --> 00:06:21,970 In my case, I generate one. 86 87 00:06:22,930 --> 00:06:28,810 Finally, I can personalize my end-device with a name, and I call it device1-otaa. 87 88 00:06:30,550 --> 00:06:36,790 When I hit the register and device button, I have got the overview of my device information and obviously 88 89 00:06:36,970 --> 00:06:41,440 I can find the DevEUI, the AppEUI and of course the AppKey. 89 90 00:06:42,890 --> 00:06:47,330 So, it's the three parameters that I will have to configure in my end-device. 90 91 00:06:48,890 --> 00:06:52,160 My LoRaWAN end-device can be configured from a specific header 91 92 00:06:52,160 --> 00:06:52,640 file. 92 93 00:06:53,180 --> 00:07:00,830 So, for this demonstration I will use OTAA activation mode and I will send a temperature every 10 seconds. 93 94 00:07:01,430 --> 00:07:04,580 That is actually the same demonstration that we used for ABP. 94 95 00:07:05,780 --> 00:07:09,770 Then, for the LoRaWAN parameters, I can copy the DevEUI, 95 96 00:07:13,440 --> 00:07:14,870 the AppEUI, 96 97 00:07:18,320 --> 00:07:19,540 and the Application Key. 97 98 00:07:22,150 --> 00:07:25,020 I compile a project and send it to my end-device. 98 99 00:07:26,780 --> 00:07:30,580 And finally, I can pull up my end-device. On the left, 99 100 00:07:30,590 --> 00:07:37,610 I have got my device log and the first action on startup is to perform the join procedure. On the server, 100 101 00:07:38,120 --> 00:07:45,920 when I go on my gateway log, I can see the Join-Request, and a few seconds later the Join-Accept. 101 102 00:07:46,760 --> 00:07:49,100 I am going to pause just to see them a bit longer. 102 103 00:07:50,150 --> 00:07:57,410 On the Join-Request, we can see the DevEUI and the AppEUI. 5 seconds later, in the Join-Accept, 103 104 00:07:57,410 --> 00:08:03,320 we cannot see anything because of course the content is encrypted, but that is where there is 104 105 00:08:03,320 --> 00:08:04,580 all the information. 105 106 00:08:04,970 --> 00:08:10,370 So, the device can generate the keys and also extract the LoRaWAN transmission settings for this session. 106 107 00:08:11,540 --> 00:08:17,660 When the join procedure is successful, it means that the session keys have been exchanged and then the 107 108 00:08:17,660 --> 00:08:20,600 application sends the temperature every 10 seconds. 108 109 00:08:21,590 --> 00:08:29,300 Now, I resume my application and on the right, in the left console data, I can see the uplink packet. 109 110 00:08:30,290 --> 00:08:36,890 If you can see them there with the right value, then that proved that the OTTA activation was successful 110 111 00:08:37,610 --> 00:08:38,150 Anyway, 111 112 00:08:38,390 --> 00:08:43,430 the end-device would never start if it has not received the proper information in the Join-Accept. 112 113 00:08:44,090 --> 00:08:50,270 So, when you see the LoRaWAN packet on the server, it is certain that the session keys have been exchanged 113 114 00:08:50,270 --> 00:08:50,810 properly. 114 115 00:08:51,500 --> 00:08:56,750 Congratulation, you are now able to register either an ABP or an OTAA end-device. 115 116 00:08:57,740 --> 00:09:00,620 These two activation methods are really important in LoRaWAN. 116 117 00:09:00,620 --> 00:09:01,010 LoRaWAN. 117 118 00:09:01,250 --> 00:09:09,230 Most of the time, even if ABP seems easier to set up, OTAA has many advantages. I would always advise 118 119 00:09:09,230 --> 00:09:14,000 you to use OTAA and I will try to explain why in the next videos.