Skip to main content
JAN R
JAN R
Associate III
February 7, 2018
Question

LRWAN - Which activation use OTAA or ABP

  • February 7, 2018
  • 2 replies
  • 2334 views
Posted on February 07, 2018 at 11:27

Dear,

I am working on end-devices which will not be configurable (no LCD, no buttons..). You can imagine it like simple thermometer which periodically send the new measured data to Gateway.

I read many topics about ABP/ OTAA activation, but it is still not clear to me which activation for this my device is possible.

My existing knowledge:

1) When I use the OTAA - I will have to set in my end-device AppKey, AppEUI and maybe DevEUI which I get from TTN - So it looks like inapplicable for me, is not it? Because In first I will program my device (with HEX file), but the AppKey, App EUI, DevEUI I (user) will know much much later.

2) Whe I use the ABP - I will have to set in my end-device Device Adress which I get also from TTN and Network Session Key with App Session Key I can probably know in advance but also I have to guarentee that these 2 keys will be unique - but how?

I hope my question is clear.

Thank you very much for advice 

Jan.

#otaa-abp #lrwan #lorawan
This topic has been closed for replies.

2 replies

After Forever
After Forever
Senior III
February 7, 2018
Posted on February 07, 2018 at 12:07

Quote from the SPEC.

6.3 Activation by Personalization

Under certain circumstances, end-devices can be activated by personalization. Activation by

personalization directly ties an end-device to a specific network by-passing the join request-join accept procedure.

Activating an end-device by personalization means that the DevAddr and the two session

keys NwkSKey and AppSKey are directly stored into the end-device instead of the DevEUI,

AppEUI and the AppKey. The end-device is equipped with the required information for

participating in a specific LoRa network when started.

Each device should have a unique set of NwkSKey and AppSKey. Compromising the keys of

one device shouldn’t compromise the security of the communications of other devices. The

process to build those keys should be such that the keys cannot be derived in any way from

publicly available information (like the node address for example).

If you don't know in advance your AppEUI and you don't have a way of remotely setting it in your devices it seems ABP is the way to go.

Just randomly generate the NwkSKey and AppSKey keys and save them in some kind of database or CSV file. Have a placeholder in your firmware for the keys, for example. ZZZZZZZZZZZNwkSKeyZZZZZZZZZZZZZZ and ZZZZZZZZZZZAppSKeyZZZZZZZZZZZZZZ, then write a PC software which will get the compiled binary and find & replace the placeholders with the real keys and save/flash the unique binary to a specific device, keeping the track of which keys went to which devices.

JAN R
JAN RAuthor
Associate III
February 7, 2018
Posted on February 07, 2018 at 13:42

Thank you.

Yes, I do not have any way of remotely configure my device after flashing. 

But when I will generate randomly the NwkSkey and AppSKey - so how can I guarantee the unique keys? Or it is not necessary?

After Forever
After Forever
Senior III
February 7, 2018
Posted on February 07, 2018 at 14:07

It is necessary for good security.

When you generate a bunch 16 bytes of random values (keys in this case) it is virtually guaranteed that they will be unique for your application (of course you should use a good random number generator for that).

For example here's a simple code in PHP for generating a random key (both binary and hex variants):

<?php
$key_bin = openssl_random_pseudo_bytes(16);
$key_hex = bin2hex($key_bin);�?�?
�?�?�?�?�?�?�?�?�?

ab val
ab val
Associate III
February 7, 2018
Posted on February 07, 2018 at 12:07

I would go with OTAA. As it requires less configuration in the device. Can you save data in flash (or eeprom) ? Because with OTAA it is better to save the keys so that you don't have to join every time you want to send something. 

Do you have a uart exposed? In this case, you could program all your end-device with the same .hex but then change the Dev EUI simply by sending uart command. 

If you go with ABP, you can create the keys in TTN first, then hardcode them in your end-device. But that means more config, so potentially more mistakes. 

JAN R
JAN RAuthor
Associate III
February 7, 2018
Posted on February 07, 2018 at 13:51

Thanks,

Ye I have eeprom for save keys.

It means that OTAA is possible only when the device will be configurable (example via UART)?

ab val
ab val
Associate III
February 8, 2018
Posted on February 08, 2018 at 15:53

No, it means it is easier to setup with UART. You can build for each end-device a hex file with the same AppEUI, AppKey but different DevEUI (that can be a 64bits serial number).

Terms & ConditionsAccessibility statement