When a LoRaWAN end device and a network server want to communicate with each other, they have to agree 1
on several parameters. 2
We'll give two examples of these parameters, but there are many more. 3
The first one we'll talk about is the channels that the end device is allowed to use. 4
There are three mandatory channels that all end devices must know. 5
These are 868.1 MHz, 868.3 MHz and 868.5 MHz. 6
But there can be up to eight channels overall. 7
So the question is how can the network server can share the other channels with the end device? 8
This LoRaWAN parameter is called the CF list for channel frequency list. 9
And the overall channel list is what we call the frequency plan. 10
The second parameter we'll talk about is the time between the uplink frame and the downlink slot. 11
We saw earlier that when the network server wants to send data to the end device, the gateway must transmit 12
the downlink frame during the RX1 or RX2 slot. 13
The different time between the uplink frame and the RX slot are 1 second for RX1 and 2 seconds 14
for RX2. 15
But what if the network server is configured with other values? 16
The end device will turn on its radio at one and 2 seconds because it is the default value. 17
Then it will turn it off. 18
If the gateway transmits outside of these slots using another RX delay, then the packet is lost. 19
This could happen with many network servers, because the default one second delay is often too short 20
in case of network overload or in case of roaming. 21
So these values are often updated to five and six seconds. 22
So the question is the same How do network server can share these parameters called RX delay with the 23
end device ? 24
Well, the first idea is to set up the parameters in the device firmware for a specific network. 25
If you know your network server frequency plan and if you know the RX delay used, then you can 26
configure these parameters during development. 27
When your end device will power up, everything will already be configured and the LoRaWAN communication 28
will be successful. 29
Okay, but what if now you want to use your device with another network server, then you will have 30
to update all your assets. 31
And that could be a big challenge because maybe you've deployed thousands of them. 32
Okay, so let's find another way to share these parameters. 33
The second idea is to configure the network server in order to send a specific frame to the end device with 34
the LoRaWAN parameters inside. 35
And you know what ? 36
You don't have to invent such a frame because the LoRaWAN specification already provides it. It's called 37
a LoRaWAN MAC command. 38
There are many of them for different purposes and we'll detail them later, but they are one for specifying 39
the frequency plan and there is also another one for specifying the RX delay. 40
Great. 41
That sounds good. 42
It's a good solution. 43
But there is something wrong. 44
How can I send a frame to a device if I don't even know when I can reach it? 45
Because we don't know its RX delay. 46
So if we want to set up this solution, we first need to know the original RX delay of the device and use 47
it to send the new parameters. 48
This process has to be done for all of them, and once again, we can do it. 49
But it's definitely time consuming, right? 50
There is one last possibility for that. 51
We need to change the activation mode. 52
While in ABP, there was no specific procedure on startup, in OTAA, 53
there is the join procedure and during this join procedure, a join accept frame is transmitted from 54
the network server to the end device. 55
The main purpose of this frame is to give the end device all the needed informations to compute the session keys. 56
But it also sends the LoRaWAN parameters and this is definitely the easiest way to share this 57
value without trouble. 58
So what we need to understand here is that once again, the OTAA activation mode is more powerful than ABP. 59
That's probably the activation mode you should consider when you want a seamless configuration.