Which Activation ABP or OTAA

End Devices (Nodes)
1

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 in advance the 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. When 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 generate myself 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.

2

We want to produce products that typically have 1 GW and dozens of end-devices. Our customer will buy from us this set of GW and some pre-unknown quantity of motes.
We will use perharps commercional GW. But end-device will be from our factory.

Keep in mind that our End-devices is not configurable - no buttons, no LCD, no UART connection…
As network server we would like to use TTN.
We do not need the our GW to be public - we just want to communicate with only our motes.
We have a EEPROM in nodes, so we can save needed numbers.

Question:
We do not know how to activate our nodes - ABP/OTAA. Because (If I understand correctly) when activating ABP the TTN must first generate DevAddr in advance for us and after that we can hardcode it to our device (during the production process) - is not it? TTN can generate for us these DevAddr in advance?

When activating OTAA - there is the similar problem but instead of DevAddr we have to know in advance the AppEUI - is not it?

In these cases we have to know the DevAddr or AppEUI in advance, which we can get only from Network server manager (TTN)?

Are these my assumptions about activation correct?

Thank you very much for help.

Best Regards, Jan.

3

Hi Jan, I combined your 2 topics

what about the application… the use case , are you in control ?

1 Like
4

In brief:

our nodes will be senzors with active element. It means We will monitor the device and also then we can send from application the downlink back to the device - on cutomer request (i.e. turn on the light on the node). Nodes will be in class C.

5

You also do the hardware production.

So main question (if I’m not wrong) is ’ we want to produce nodes without preprogrammed dev adress / ap eui '
When a node is activated (switched on) at the clients location, they will be automagically added to the application

6

You are right, it would be perfect, but If I understand correctly it is not possible, or it is?

7

i’m afraid not … I just got a crazy idea… in the near future you can update firmware over the air… :roll_eyes:

8

OK, but have could I update the firmware via LRWAN if a device will not be able to connect to the network :slight_smile: ?

9

yes but if you supply every node with the same adress and firmware, the moment its powered on it ask for a firmware update with a ‘basic’ adres and application… at that moment it receives its final application and dev adr that is then stored on eeprom.
Maybe its not even possible, maybe you can’t change the dev adress with a fimware update…I was just thinking aloud :sunglasses:

10

OK, and when I woul preprogram the final firmware in production - what should I have to do?

11

Is LoRa the only way you can connect to the device? Or do they also have BLE or WiFi?
If for example, you’re using an ESP32 (or ESP8266) in the device you could have it default to acting as an WiFi access point, the client could then connect to it, add the needed keys, reset the device and be good to go.
Something like this but then instead of WiFi credentials you would add TTN credentials.

12

Hi, yes there will not be any WIFI or BLE, just LoRa… So it means, that I should request the TTN for the DevAddr in advance and after that I flash my Node with final firmware… Is this only one possibility?

13

You could also design something where you plug in some data storage peripheral (usb flash, memory card, etc) and your device automatically fetch its configuration from that.

Out of curiosity, will that be for a datacenter environment ? No wifi / wireless network is usually imposed by security constraint there indeed.

14

No, use OTAA:

More details in Registration of node with pre-configured LoRaWAN keys - #2 by arjanvanb.

(And wondering if TTN ever considered providing some paid service to manufacturers to make it easy for a buyer to register such nodes, like through some QR code.)

15

Thank you. Now it is little more clear.

Another question about “numbers”:
To the End node we will hardcode the AppEUI, DevEUI and AppKey.

From spec it looks like, that DevEUI and AppEUI should be the 64 bits unique numbers - it means I should bought them from database IEEE.
The AppKey is 128-bit number for encrypting the message - I suppose that there is not needed to have unique number but is recomended to use the random number generator for obtain it…

Are the my assumptions correct?

(For private networks, the procedure is the same?!)

Thank you, Jan.