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