What’s new in LoRaWAN 1.0.4?

TheThings Network

The Things Network Global Team

Posted on 07-06-2021

In October 2020, LoRa Alliance released a new specification for the LoRaWAN networking protocol - LoRaWAN TS1-1.0.4, the latest version of the 1.0 series. The LoRaWAN 1.0.4 simplifies LoRaWAN development, deployment, management, and interoperability.

An overview of LoRaWAN specifications
An overview of LoRaWAN specifications

The LoRaWAN 1.0.4 Specification Package can be downloaded and consists of the following documents :

  • LoRaWAN Link Layer Specification v1.0.4 (TS1-1.0.4) - describes the LoRaWAN network protocol

  • LoRaWAN Certification Protocol v1.0.0 (TS9-1.0.0) - describes functional test for LoRaWAN certification, end device certification, and certification protocol commands

  • LoRaWAN 1.0.4 End Device Certification Requirement v1.1 - describes the minimum testing requirements for an end device to be designated “LoRaWAN Certified”

The LoRaWAN 1.0.4 specification can be used as a starting point for developing LoRaWAN products, and for using the LoRaWAN Certification Test Tool (LCTT) to verify whether your new product meets the requirements to become LoRaWAN Certified. This version also simplifies and automates device-claiming using QR codes.

The LoRaWAN 1.0.4 provides several security updates, improvements on Class B and various clarifications, and refinements. The complete list of changes in v1.0.4 can be found in the LoRaWAN L2 1.0.4 Specification document (see page 86). The following is a brief listing of notable updates.

Security improvements:

  • Mandating 32-bit frame counters (FCnt) and keeping them in the persistent part of the memory, for example, the non-volatile random-access memory (NVRAM). This will prevent the loss of frame counters across reboots and protect the end devices from various security threats such as replay attacks

  • Enforcing the frame counters for Activation-By-Personalization (ABP) devices cannot be reset during the device’s lifetime

  • The DevNonce should be monotonically (always) incrementing (previously it is a random value in the v1.0 series and counter value starting at 0 in v1.1). This will help the Join Server to keep track of DevNonce values for preventing replay attacks

  • Similar to the LoRaWAN 1.1, the AppEUI and AppNonce are replaced with JoinEUI and JoinNonce respectively

  • Requirement of using a Join Server that can assist in the processing of the Join procedure and the derivation of session keys

Class B improvements:

  • Explains the usage of Frame Pending bit (FPending) for unicast and multicast Class B downlink frames. If the FPending bit was set for Class B ping slot sequences (receive windows), they will take priority over ping-slot sequences for which FPending has not been set

  • Beacon frame formats defined for SF8 - SF12

  • Beacon transmission randomization for indoor getaways to avoid interference

  • Time precision field to the Beacon to describe the precision of the source

  • Latitude and longitude definition for the GPS coordinate fields of the beacon

  • Preventing ACKs to occur after a timeout for Class B and C confirmed downlinks

  • Preventing Class B and C downlinks to be sent after sending confirmed Class A downlink and before ACK is received

  • PingSlotChannelReq acknowledge mechanism modification - repeated in all uplinks, until next Class A downlink, a.k.a. Sticky answer

Clarifications and refinements:

  • Co-existence of Class A, B, and C

  • Handling FPort above 224 - FPort values above 224 are reserved for use and allocation by the LoRa Alliance. Now, these values are not discarded

  • Refined ADR management

  • Treating MAC commands as mandatory

  • AddrPrefix in DevAddr - how the AddrPrefix is defined in the link-layer specification in alignment with its backend specification

  • Channel selection during the join

  • CFList handling with respect to other configurable values

  • Retransmission backoff - retransmits the uplink message again by the end-device if there is no acknowledgement received from the network server or the application server. This can also be triggered by an external event causing synchronization across a large number of end-devices

  • Class C device to send uplink after join

  • MAC commands from the network are only sent in Class A downlink

In this video, Alper Yegin, the chair of the technical committee of the LoRa Alliance talks about LoRaWAN 1.0.4 at The Things Conference, 2021: