LoRaWAN PHYPayload Utility

LoRaWAN Payload Decoder

Decode a LoRaWAN data PHYPayload into MHDR, message type, DevAddr, frame control flags, frame counter, FOpts, FPort, FRMPayload and MIC. Optionally decrypt LoRaWAN 1.0.x FRMPayload bytes using the appropriate application or network session key.

✓ MHDR ✓ DevAddr ✓ FCtrl ✓ FCnt ✓ FPort ✓ FRMPayload ✓ Optional Decryption

LoRaWAN PHYPayload

● Ready

LoRaWAN PHYPayload Hex Bytes Enter hexadecimal bytes separated by spaces, commas, colons or hyphens. Continuous hexadecimal input and 0x-prefixed bytes are accepted.

Frame Direction Direction is required for FRMPayload decryption.

FCnt Upper 16 Bits Optional upper half of the 32-bit frame counter. Enter decimal or 0x hex.

FRMPayload Decryption For FPort 1–255 use AppSKey. For FPort 0 use NwkSKey.

AppSKey 128-bit application session key used when FPort is 1–255.

NwkSKey LoRaWAN 1.0.x network session key used when FPort is 0.

Decoder scope: this page parses LoRaWAN data-message structure. Join-request, join-accept and proprietary frames have different layouts and are identified but not falsely decoded as ordinary FHDR data frames. MIC bytes are displayed but are not claimed valid unless a dedicated MIC verification implementation is used.

LoRaWAN Payload Decode Result Decoded

Decoded Frame —

Message Type —

Direction —

DevAddr —

FCnt16 —

FCnt32 —

FPort —

FOpts Length —

FOpts —

FRMPayload Bytes —

MIC —

Major —

Total Bytes —

FRMPayload / Decrypted Payload

—

Field	Offset	Bytes	Decoded Value	Meaning

Frame Decode Breakdown

—

What Is a LoRaWAN Payload Decoder?

A LoRaWAN Payload Decoder separates raw LoRaWAN PHYPayload bytes into the protocol fields contained in the radio frame. For ordinary data messages, these fields include MHDR, FHDR, DevAddr, FCtrl, FCnt, optional FOpts, FPort, FRMPayload and MIC.

The application payload carried inside FRMPayload is normally encrypted, so its bytes cannot be interpreted merely by looking at the hexadecimal radio packet.

LoRaWAN Data PHYPayload Layout

PHYPayload

+------+------------------------+------+
| MHDR |      MACPayload        | MIC  |
+------+------------------------+------+

MACPayload

+------+-------+------------+
| FHDR | FPort | FRMPayload |
+------+-------+------------+

FHDR

+---------+-------+-------+-------+
| DevAddr | FCtrl | FCnt  | FOpts |
+---------+-------+-------+-------+

LoRaWAN MHDR

MHDR is the first byte of the PHYPayload. Bits 7 through 5 contain MType, bits 4 through 2 are reserved for RFU in the classic layout, and bits 1 through 0 identify the LoRaWAN major version.

MType = (MHDR >> 5) & 0x07
Major = MHDR & 0x03

LoRaWAN Message Types

MType	Meaning	Direction
0	Join-request	Uplink
1	Join-accept	Downlink
2	Unconfirmed Data Up	Uplink
3	Unconfirmed Data Down	Downlink
4	Confirmed Data Up	Uplink
5	Confirmed Data Down	Downlink
6	Rejoin-request	Uplink
7	Proprietary	Application-defined

LoRaWAN DevAddr Byte Order

The DevAddr occupies four bytes in the FHDR. The octets are transmitted least significant byte first.

Frame bytes:

04 03 02 01

Decoded DevAddr:

0x01020304

This byte-order conversion is one of the most common sources of confusion when manually reading LoRaWAN packets.

LoRaWAN Frame Control — FCtrl

The meaning of individual FCtrl flag bits depends partly on whether the frame is uplink or downlink. The low four bits always contain FOptsLen.

FOptsLen
= FCtrl & 0x0F

Valid range:
0 through 15 bytes

The decoder reports the raw FCtrl value and interprets the major flag bits using the selected or automatically detected frame direction.

LoRaWAN Frame Counter

Only the least significant 16 bits of the frame counter are transmitted in the ordinary FHDR field. A receiver normally reconstructs the full frame counter using session state.

FCnt32
= (Upper16 << 16)
| FCnt16

The optional FCnt Upper 16 Bits field allows the calculator to reconstruct the 32-bit counter needed when decrypting a payload.

What Is FPort?

FPort identifies how FRMPayload should be interpreted cryptographically and logically.

FPort 1–255
→ Application payload
→ encrypted with AppSKey in LoRaWAN 1.0.x

FPort 0
→ MAC commands in FRMPayload
→ protected with a network session key

What Is FRMPayload?

FRMPayload is the variable-length encrypted portion following FPort. The raw radio bytes usually cannot be treated directly as ASCII, sensor values or JSON because LoRaWAN applies payload encryption.

After successful decryption, the resulting application bytes still require the device’s application-specific payload format to be known before fields such as temperature or humidity can be assigned meanings.

LoRaWAN 1.0.x FRMPayload Decryption

For LoRaWAN 1.0.x data frames, FRMPayload encryption is based on AES-128 and a sequence of counter blocks containing direction, DevAddr, frame counter and a block number.

A[i] contains:

0x01
00000000
Direction
DevAddr
FCnt32
0x00
Block Counter

The generated AES stream is XORed with the FRMPayload bytes. Because encryption and decryption both use XOR with the same generated stream, the transformation is symmetrical.

AppSKey vs NwkSKey

FPort	LoRaWAN 1.0.x Key
1–255	AppSKey
0	NwkSKey

LoRaWAN 1.1 separates network-session key responsibilities further, so this simple 1.0.x key selection should not be assumed to represent every LoRaWAN 1.1 security operation.

What Are FOpts?

FOpts is an optional area inside FHDR that can contain MAC commands. Its length is encoded in the low nibble of FCtrl and is limited to fifteen bytes in the classic frame format.

FCtrl = 0x03

FOptsLen
= 0x03 & 0x0F
= 3 bytes

What Is the LoRaWAN MIC?

The Message Integrity Code is the final four bytes of the PHYPayload. It is used by LoRaWAN security processing to detect modification and authenticate the relevant frame context.

This decoder extracts and displays the received MIC. Displaying four MIC bytes does not prove that the MIC is correct. Verification requires the proper LoRaWAN version, session keys, direction and frame-counter context.

Example LoRaWAN Data Frame

40 04 03 02 01 00 01 00 01 48 69 AA BB CC DD

MHDR:
40

MType:
Unconfirmed Data Up

DevAddr bytes:
04 03 02 01

DevAddr:
0x01020304

FCtrl:
00

FCnt:
01 00
= 1

FPort:
01

FRMPayload:
48 69

MIC:
AA BB CC DD

The bytes 48 69 are intentionally shown as raw FRMPayload in this example. Without a valid session key, the decoder does not claim they represent the plaintext string “Hi”.

Why LoRaWAN Payload Bytes May Look Random

Application FRMPayload is encrypted, so encrypted bytes should normally look unrelated to the original sensor data. Seeing unreadable hexadecimal does not mean the radio packet is damaged.

To interpret encrypted application data, the correct AppSKey, DevAddr, direction and complete frame-counter value must correspond to the same LoRaWAN session.

LoRaWAN Payload Decoder vs Application Decoder

This page first decodes the LoRaWAN protocol envelope. That is separate from an application-specific payload decoder.

Stage 1:
Decode LoRaWAN PHYPayload

Stage 2:
Decrypt FRMPayload

Stage 3:
Interpret application bytes

Example application interpretation:
byte 0–1 → temperature
byte 2    → battery
byte 3–4 → pressure

Stage 3 requires the payload specification of the actual end device.

LoRaWAN Payload Decoder FAQs

What does this LoRaWAN decoder accept?

It accepts raw PHYPayload hexadecimal bytes and structurally decodes supported LoRaWAN data messages.

What is MHDR?

MHDR is the first LoRaWAN PHYPayload byte and contains MType, reserved bits and the Major field.

How do I decode DevAddr?

Read the four DevAddr octets from FHDR and reverse their transmitted little-endian byte order when displaying the conventional hexadecimal address.

What is FOptsLen?

FOptsLen is the low four bits of FCtrl and tells the receiver how many FOpts bytes follow FCnt.

What is FCnt16?

It is the lower sixteen bits of the LoRaWAN frame counter transmitted in the FHDR.

Why does the decoder ask for upper FCnt bits?

The full frame counter is required for correct payload decryption, while only its lower sixteen bits are present directly in the ordinary data frame.

Which key decrypts FPort 1?

For LoRaWAN 1.0.x, application FRMPayload on FPort 1 through 255 uses the AppSKey.

Which key is used for FPort 0?

For the LoRaWAN 1.0.x model implemented by this page, FPort 0 uses NwkSKey.

Does this decoder verify the MIC?

No. It extracts the MIC but does not falsely label it valid without performing the complete version-specific integrity calculation.

Can I decode LoRaWAN without an AppSKey?

Yes. All unencrypted protocol fields can still be parsed. The encrypted FRMPayload remains raw hexadecimal.

Is DevAddr encrypted?

No. DevAddr is part of FHDR and can be read from an ordinary LoRaWAN data frame without decrypting FRMPayload.

Is FPort encrypted?

FPort is part of the MACPayload structure and is available before application payload decryption.

Can the decrypted payload automatically tell me temperature?

Only if the device-specific payload format is known. LoRaWAN itself does not define how arbitrary application bytes represent sensor measurements.

Does this page fully implement LoRaWAN 1.1 security?

No. Optional FRMPayload decryption is intentionally labeled as the simpler LoRaWAN 1.0.x session-key model.

Inspect LoRaWAN PHYPayload Frames

Break raw LoRaWAN data packets into protocol fields and optionally decrypt LoRaWAN 1.0.x FRMPayload bytes when the correct session key and frame-counter context are available.