LoRaWAN is an encrypted, energy-efficient wireless communication protocol used for transmitting data from sensors. A LoRaWAN message (telegram) consists of multiple headers, an encrypted payload, and four additional bytes used as a MIC (Message Integrity Code) to verify the sender. This article describes the structure of a LoRaWAN uplink telegram with all its components and demonstrates the creation of an FRM payload, as it would be generated by an end device in practice.

Physical LoRaWAN Telegram

The LoRaWAN physical payload consists of several components that are used for data transmission at the physical layer. First, a preamble signals to the receiver that a LoRa telegram is being sent, establishing synchronization between the sender and receiver. Following that, a PHDR (Physical Header) contains metadata for the transmission, such as modulation settings. The PHDR_CRC ensures the integrity of the header. The actual PHYPayload contains the encrypted LoRaWAN message and control information. Finally, the CRC (Cyclic Redundancy Check) ensures the integrity of the entire message in both uplink and, in some cases, downlink. While some of these components, such as the preamble, PHDR, and the CRCs, are generated directly by the LoRa chip, the PHYPayload, including encryption and formatting, must be provided by the application. In summary, a LoRaWAN telegram, as transmitted over the air, looks as follows:

Overview of PHYPayload

The Physical Payload (PHYPayload) consists three segments: MHDR, MACPayload or JOIN Request/Response, and a MIC. The MHDR have a length of one byte and the MIC have 4 bytes. The size of the MACPayload depends on the size of the actual payload and any additional options, which are limited to a maximum of 15 bytes. The Join Request and Join Response have a fixed size but will be explained in detail in a future article and are therefore not further explained here.

MHDR - MAC Header

MHDR is the first part of the PHYPayload in a LoRaWAN message and consists of a single byte. It contains essential information about the message type and protocol version. The byte is divided into three fields:
MType (Message Type): Specifies the type of message, e.g. Join-Request, Unconfirmed Uplink and much more.
RFU: Reserved for future extensions.
Major: Indicates the version of the LoRaWAN protocol. The value is typically 00 in current versions (LoRaWAN 1.0.x).

The MHDR thus establishes the basic framework for communication and is considered during decryption and processing of the message.

Practical Example: In the remainder of this article, a payload will be created based on the available information. In practice, an Unconfirmed Uplink telegram sets the first three bits to 010. The next three bits are RFU, which are set to 000. The last two bits define the LoRaWAN version (00 = R1). This results in the binary value 01000000, which converts to the hexadecimal value 0x40. Therefore, the first byte in hexadecimal is 40.

MACPayload

The MACPayload is the central part of a LoRaWAN message. It contains the actual data as well as control information and consists of three components:

Device Address: The first four bytes in the Frame Header (FHDR) represent the Device Address (DevAddr). Sensors operating in ABP mode have a fixed address, while sensors in OTAA mode are assigned this address by the network server during the JOIN response. The DevAddr is transmitted in little-endian format, meaning the Least Significant Byte (LSB) comes first and the Most Significant Byte (MSB) comes last. This format is typical for most LoRaWAN protocol fields, as it simplifies processing for microcontrollers. Many network servers use specific address ranges; for instance, every node address in TTN typically starts with 26 or 27.

In practice, the desired byte sequence is reversed. From 0xAA .. 0xDD, it becomes 0xDD .. 0xAA. The payload with MHDR (40) now reads: 40 DD CC BB AA.

FCTRL: The Frame Control contains control information for the network server and the end device:

There are differences in bit allocation between Downlink and Uplink telegrams. The following table describes the individual segments of the FCTRL byte:

If the end device supports ADR and the message is an Uplink telegram, the binary value of this byte would be: 1000000. In hexadecimal, this results in the following value: 0x80. The complete PHYPayload would look as follows: 40 DD CC BB AA 80.

FCNT: The Frame Counter increments by one with each message. Uplink and Downlink telegrams have their own counters. The Frame Counter consists of 2 bytes:

The Frame Counter is used for encryption and ensures that messages are unique. The network server verifies that the received counter value is greater than the previously stored value to ensure it is not an old message. When the counter reaches its maximum value (65,535), it resets to 0. In practice, the FCnt ensures the integrity and security of communication and protects against replay attacks.
For the practical example, an Uplink telegram is assumed, and the counter is set to 1. The Frame Counter consists of two bytes, which in this case represent the hexadecimal values 0x00 and 0x01. As with the DevAddr, the bytes are reversed, resulting in 0x01 and 0x00. The complete PHYPayload is now:40 DD CC BB AA 80 01 00

Frame Options: The FOpts field is an optional component of the Frame Header (FHDR) in a LoRaWAN message and can be up to 15 bytes in length. It is used to exchange MAC commands between the end device and the network, such as optimizing the connection or adjusting parameters. A practical example is time synchronization: the network can send a command through the FOpts field to provide the end device with a new system time. Control commands such as frequency changes, enabling ADR, or a request for acknowledgment can also be sent. The length of the field is specified by the FOptsLen field in FCtrl. Since the FOpts field is located before the encrypted payload, it does not affect the data integrity of the actual payload. It allows for efficient transmission of control information without requiring additional messages.
In the accompanying practical example, the Uplink message does not include any options, so the PHYPayload remains unchanged for now.

Frame Port: The Frame Port (FPort) is a 1-byte field in a LoRaWAN message that defines the purpose of the message and determines whether it contains application data or MAC commands. An FPort value of 0 indicates that the FRMPayload exclusively contains MAC commands, which are encrypted with the NwkSKey. For an FPort value between 1 and 223, the FRMPayload contains application data encrypted with the AppSKey. The port enables the association of messages with specific services or applications, such as transmitting sensor data or control commands.

For the practical example, the message will use FPort 01. The PHYPayload is thus structured as follows: 40 DD CC BB AA 80 01 00 01

FRMPayload: The FRMPayload is the part of a LoRaWAN message that contains the actual payload data. It can include either application data or, if the Frame Port (FPort) is set to 0, MAC commands. The payload is always transmitted in encrypted form to ensure the confidentiality and security of the data.

In uplink, the FRMPayload typically contains data generated by a sensor or end device, such as temperature or location information. In downlink, it can carry control data or configuration instructions from the network to the end device.

The encryption of the FRMPayload is performed with the AppSKey if application data is transmitted, or with the NwkSKey if MAC commands are included. This ensures that only authorized parties can decrypt and process the payload data. The specific content and purpose of the FRMPayload depend on the use case and are flexibly designed within the protocol.

The figure shows the unencrypted payload (01 23 AB CD F0). Using the App Session Key (AppSKey), the payload is encrypted and now it is: B4 3D 27 16 23. For this example, the PHYPayload is extended by 5 bytes and is structured as follows: 40 DD CC BB AA 80 01 00 01 B4 3D 27 16 23

MIC - Message Integrity Code

The MIC is a 4-byte field at the end of a LoRaWAN message that ensures the integrity and authenticity of the message. It is calculated using an AES algorithm that employs the NwkSKey (Network Session Key). The MIC protects the message from unauthorized modifications and helps the receiver verify that the message originates from a trusted source.

The MIC is calculated over the entire message, including the MHDR, FHDR, FPort and the FRMPayload. If the calculated MIC at the network server does not match the received MIC, the message is discarded.