The configuration of LoRaWAN devices can be confusing. There’s two keys you have to keep track of, there’s EUIs and there’s all sorts of weird configuration parameters you have to use.

Device EUI, Network EUI, Application EUI and DevAddr

In the LoRaWAN stack the networks, applications and devices are identified by EUI64 identifiers. EUI64s are globally unique identifers. You can read more on these here: https://standards.ieee.org/develop/regauth/tut/eui64.pdf The EUIs are used to identify all of the (virtual) parts of the LoRaWAN inside the backend server.

The DevAddr value is an unique identifier for the device in a particular network. It is made up of two different parts called NwkID and NetAddr but for all intents and purposes this is a 32-bit unsigned integer you use to identify your device. This is the identifier that is used to identify your device once it has joined a network.

The network and application session keys

The encryption in LoRaWAN is relatively simple. There’s two keys you might have to worry about if you use ABP (aka “Activation By Personalisation” devices; devices that have pre-provisioned keys).

• The network session key is an unique key for each device that is known by the network and the device. This key is used for housekeeping messages that do not carry any payload. The key is used to add a checksum to the messages sent to the devices.
• The application session key is an unique key for each devices that is known by the application and the device. This is the key that is used to encrypt the payload from the device, making it very hard for anyone to eavesdrop on your communication with the backend server. This key is also used for checksums.

APB vs OTAA devices

There are two kinds of devices in a LoRaWAN network - “APB” devices and “OTAA” devices:

• APB (Activation By Personalisation) devices get three pieces of information: The network session key, application session key and device address. These devices can start sending immideately when they are powered up but each device needs an unique set of keys. If someone breaks into your device and grabs the keys you can easily deprovision just the one device that is affected without having to change all of the other devices. The biggest drawback with this device type is that you have to keep track of the frame counters for the messages going to and from the backend server between powerups. Normally the backend server ignores messages with frame counters different from the one expected but you can turn of this check when testing devices. Turning off this check makes the device susceptible to replay attacks so it is usually reserved for testing.
• OTAA (Over The Air Activated) devices are the most common device type. Each of these devices will get three pieces of information when you provision them: The application key, application EUI and device EUI. When the device is turned on it will start a join procedure where it negotiates a new set of keys based on the existing application key. Once the negotiation is done (usually in less than five seconds) it will behave just like an APB device. If you power off the device it will have to join the network again when it starts up. The biggest concern with OTAA devices is - not surprisingly - the application key. If someone manages to grab the key from one of your devices the attacker can potentitally impersonate any device in your network. On the other hand using OTAA devices makes it a lot easier to manage huge amounts of devices since you won’t have to manage a lot of keys.

Which device type you select depends on how you plan to provision new devices. If your devices might or might not be in range of a gateway when they’re turned on ABP devices will make more sense since they can start sending right away. If you on the other hand have devices that are mostly in range of a gateway and will be powered up and down frequently without any onboard storage you can use OTAA devices. When developing new devices OTAA devices are the most convenient.

What is a “Private network”?

If you see “private network” mentioned somewhere in the configuration files you - like so many others - have probably wondered what it really means since it’s a parameter you set but then never see again. A private network in LoRaWAN is a network of devices (and gateways) that accepts messages with a private preamble (the identifier sent as the first bits of a message) rather than the standard preamble. There’s only two kinds of preambles: The standard, public LoRaWAN preamble or the private preamble. If the private preamble is sent, all bets are off and the format of the data is entirely up to the device and the backend server. If you want to be compatible with different networks (and you probably do) just keep the private network flag turned off.

ADR

ADR (Adaptive Data Rate) is a trick the backend server can use to let devices transmit on as low power as possible. If the device is close to the gateway the device can transmit at lower power and at a higher data rate until it uses as little power as possible. If two or three gateways can hear the device it can turn back the transmission power and save energy.

Message types: Confirmed and unconfirmed messages

LoRaWAN defines two kinds of messages - confirmed and unconfirmed. The confirmed messages expects an acknowledgement from the backend server and if it doesn’t send one the message will be retransmitted with a different spread factor and bandwidth. Similarly the backend server will retransmit confirmed messages until the device responds with acknowledgement.

There’s only a single acknowledge flag in use so there’s no way of acknowledging old messages.

Upstream and downstream messages

Sooner or later someone is going to mention “upstream” and “downstream”. Keeping track of which direction isn’t completely intuitive if you work on the device but remember that upstream is up to the gateway’s antenna and downstream is down from the gateway’s antenna.

This will break spectactularly if you are putting devices in weather balloons.

My device doesn’t send a message when I tell it to!

If you schedule a message on your device sometimes you will experience that the message will stay on the device for a long time until it is sent but on other occasions it will be sent right away. This is caused by the duty cycle limitations (ie the ratio of time spent sending and not-sending) on the ISM band which the LoRaWAN devices must obey at all times. For some frequencies the max duty cycle is 1% while for other the max duty cycle is as little as 0.1%. If you spend one second sending a message you have to wait for 99 seconds before you can send another one when the duty cycle is 1% while you might have to wait for more than 15 minutes if the duty cycle is 0.1%.