This is a quick post to document one of the question I had about LoRaWAN, namely what is the overhead for sending 1 byte of useful application payload when using LoRaWAN, versus using LoRa directly.

LoRaWAN frame payload format

In the above diagram "8b" refers to 8 bits, while "8B" refers to 8 bytes.

LoRaWAN encoding

Assuming that the "App Layer" is 1 byte, the amount of extra bits needed for encoding the frame from the LoRaWAN device to the LoRaWAN gateway consists of the following items:

LoRaWAN layer:

  • 4 bytes for the device address  (inside the header) - used for the cloud to identify the emitting device.
  • 2 bytes for the frame counter (inside the header) - used for packet loss detection (and rejoin with OTTA), as well as to prevent replay attacks.
  • 1 byte of control bits (inside the header), used for adaptive data rate (ADR) and acknowledge request control.
  • 1 byte for the  port - which can be any value from 1 to 223; the other values beeing reserved for protocol payload handling.

Medium  Access control (MAC) layer:

  • 1 byte for the header - which includes the frame type, and a version number known as the major. The most basic header is defined as an uplink data message, with a major equal to zero.
  • 4 bytes for the message integrity code, aka "MIC". The MIC is not a CRC (which instead, sits at the physical layer level). Instead the MIC is used for authentication. It is the computed as the  AES-CMAC crypto based on the network session key (NwkSKey) over the MAC header and payload.

So, this is 13 bytes overhead needed to transmit a single 1 byte useful payload.  And considering that out of those 13 bytes, 10 are used for addressing, authentication, and sequence control, this is actually a pretty efficient  protocol encoding implementation.

LoRa encoding

Let's continue the analysis of with the LoRa physical frame.

The overhead when using the LoRa physical frame encoding consists of those additional bits:

  • 8 bytes for the preamble. The preamble, which is needed for the LoRa receive to start detecting a frame, can vary in length.  For LoRaWAN, it is 8 bytes. Other modulation, such as GSFK, uses 5 bytes.
  • 2.5 bytes for the header - I could not find any explicit description for this header payload, expect from this fascinating reverse engineering (section 4.6)
  • 2 bytes for the CRC.

Actually, there are two transmitions modes for the physical layer: Explicit and Implicit. The later implicit mode assumes that the payload length, CR, and CRC are known in advance by both the sender and receiver, in which case the CRC and header are not transmitted, thus saving 4.5 bytes. However, while the implicit mode can work for specific frames with known length, it is not suitable to generic frames when ADR is used, since the coding rate can vary dynamically.

So, assuming an explicit physical frame, it takes 25.5 bytes overhead to transfer one byte of useful application data.

Conclusion

The graph below shows the actual encoding efficiency, measured for the 3 different encoding.

LoRaWAN frame encoding efficiency

The efficiency is defined as PL/(O+PL), where PL = is the useful application payload, and O the Overhead.

As a conclusion, sending 1 byte of useful application data has an efficiency of 3.8% when using LoRaWAN. And to achieve 80% encoding efficiency (eg overhead length smaller than one fifth of the application payload), LoRaWAN application need to send at least 100 bytes.