Uplink: The terminal sends its data, which is then relayed to the network server via one or more gateways.

Downstream: Data is sent from the network server to a specific terminal device. Each message is uniquely addressed and only passes through one gateway.

LoRaWAN defines three classes of devices: Class A, Class B, and Class C.

Class A: The terminal initiates transmission and then opens a receiving window for a short period. It can only receive downlink messages after sending an uplink packet. This results in the lowest power consumption (ideal for battery-powered devices).

Class B: The terminal and server synchronize to open receiving windows at specific times. This allows the device to receive multiple packets during scheduled intervals, offering moderate power efficiency.

Class C: The terminal keeps its receiving window open continuously, except when transmitting. While this offers the lowest communication delay, it also consumes the most power, making it suitable for devices with constant power supply.

The complete packet structure includes several components:

Note that the preamble, PHDR, PHDR_CRC, and CRC are all generated by hardware and not handled by software. The PHYPayload portion is where the software comes into play.

Uplink message:

Downlink message:

The uplink message ends with a CRC check, while the downlink does not. PHDR, PHDR_CRC, and CRC are calibration data generated by the RF chip, not user data.

As shown in the diagram, the MAC layer data consists of three main parts:

MHDR (MAC Header)

MACPayload (MAC Payload)

MIC (Message Integrity Code, 4 bytes)

The MACPayload itself is made up of three sections:

FHDR (Frame Header)

FPORT (Application port number)

FRMPayload (Encrypted user data)

The FHDR contains four fields:

DevAddr (4-byte device address)

FCtrl (1-byte frame control field)

FCnt (2-byte frame counter)

FOpts (Optional frame configuration, variable length, often 0 bytes)

From this protocol structure, we can see that any uplink or downlink packet will contain the terminal ID, the frame sequence number, and encrypted user data — no explicit control commands are included.

For example, here's a captured packet:

\x40 \x7f \xf8 \x8a \x29 \x80 \x2a \x00 \x02 \x07 \x42 \x87 \x3f \xc7 \xb4 \x22 \x04 \x00 \x84 \x8d \x1b \x06 \x2f \x5b \xbc \x57 \xdb \xf2 \x31 \xde \x49 \x61 \x00 \x86 \x99 \xec \x08 \x61 \xf0 \xb7 \xda \x54 \x0a \xfa \xd1 \x31 \xac \xd0 \x44 \x1b \x4d \xfa \x48 \x77 \x19 \xee \x61 \x14 \xbf \x23 \x52 \xd1 \xe9 \x93 \x79 \x6e \x16 \xd7 \x13 \x2e \x58 \x06 \x54 \xc3 \xd2 \x04 \xba \x52 \xa7 \xc8 \x7a \x0b \x8e

This represents a full MAC layer frame, specifically the PHYPayload section. Keep in mind that LoRaWAN uses little-endian byte order by default.

Here's a breakdown of the packet:

MHDR: \x40

FHDR - DevAddr: \x7f \xf8 \x8a \x29

FHDR - FCtrl: \x80

FHDR - FCnt: \x2a \x00

FPORT: \x02

FRMPayload (encrypted): \x07 \x42 \x87 \x3f \xc7 \xb4 \x22 \x04 \x00 \x84 \x8d \x1b \x06 \x2f \x5b \xbc \x57 \xdb \xf2 \x31 \xde \x49 \x61 \x00 \x86 \x99 \xec \x08 \x61 \xf0 \xb7 \xda \x54 \x0a \xfa \xd1 \x31 \xac \xd0 \x44 \x1b \x4d \xfa \x48 \x77 \x19 \xee \x61 \x14 \xbf \x23 \x52 \xd1 \xe9 \x93 \x79 \x6e \x16 \xd7 \x13 \x2e \x58 \x06 \x54 \xc3 \xd2 \x04 \xba \x52 \xa7

MIC: \xc8 \x7a \x0b \x8e