Message Types

Info:
For information on The Things Stack specific data formats, check The Things Stack documentation.

In this chapter, you will learn about different message types used in LoRaWAN 1.0.x and 1.1. These message types are used to transport MAC commands and application data. The Things Fundamentals Certification exam expects you should have basic knowledge on the following topics with regards to the message types:

  • Uplink and downlink messages.
  • MAC Message types and their uses.
  • Sending MAC commands in the FOpts field.
  • Sending MAC commands and application data in the FRMPayload field.
  • Keys used to encrypt each field that carries MAC Commands and application data.
  • Keys used to calculate the Message Integrity Code (MIC) of each message.

LoRa messages can be divided into uplink and downlink messages based on the direction they travel.

Uplink messages - Uplink messages are sent by end devices to the Network Server relayed by one or many gateways. If the uplink message belongs to the Application Server or the Join Server, the Network server forwards it to the correct receiver.

Downlink messages - Each downlink message is sent by the Network Server to only one end device and is relayed by a single gateway. This includes some messages initiated by the Application Server and the Join Server too.

MAC Message Types #

LoRaWAN defines several MAC message types.

The following table presents MAC message types that can be found in LoRaWAN 1.0.x and 1.1.

LoRaWAN 1.0.x LoRaWAN 1.1 Description
Join-request Join-request An uplink message, used by the over-the-air activation (OTAA) procedure
Join-accept Join-accept A downlink message, used by the over-the-air activation (OTAA) procedure
Unconfirmed Data Up Unconfirmed Data Up An uplink data frame, confirmation is not required
Unconfirmed Data Down Unconfirmed Data Down A downlink data frame, confirmation is not required
Confirmed Data Up Confirmed Data Up An uplink data frame, confirmation is requested
Confirmed Data Down Confirmed Data Down A downlink data frame, confirmation is requested
RFU Rejoin-request 1.0.x - Reserved for Future Usage

1.1 - Uplink over-the-air activation (OTAA) Rejoin-request

Proprietary Proprietary Used to implement non-standard message formats

Join-request, Rejoin-request, and Join-accept messages #

In LoRaWAN 1.0.x, two MAC message types are used by the Over-The-Air-Activation (OTAA) procedure:

  • Join-request
  • Join-accept

In LoRaWAN 1.1, three MAC message types are used by the Over-The-Air-Activation (OTAA) procedure and for roaming purposes:

  • Join-request
  • Join-accept
  • Rejoin-request

Join-request #

The Join-request message is always initiated by an end device and sent to the Network Server. In LoRaWAN versions earlier than 1.0.4 the Join-request message is forwarded by the Network Server to the Application Server. In LoRaWAN 1.1 and 1.0.4+, the Network Server forwards the Join-request message to the device’s Join Server. The Join-request message is not encrypted.

Join-accept #

In LoRaWAN versions earlier than 1.0.4 the Join-accept message is generated by the Application Server. In LoRaWAN 1.1 and 1.0.4+ the Join-accept message is generated by the Join Server. In both cases the message passes through the Network Server. Then the Network Server routes the Join-accept message to the correct end-device. The Join-accept message is encrypted as follows.

  • In LoRaWAN 1.0, the Join-accept message is encrypted with the AppKey.
  • In LoRaWAN 1.1, the Join-accept message is encrypted with different keys as shown in the table below.
If triggered by Encryption Key
Join-request NwkKey
Rejoin-request type 0, 1, and 2 JSEncKey

Rejoin-request #

The Rejoin-request message is always initiated by an end device and sent to the Network Server. There are three types of Rejoin-request messages: Type 0, 1, and 2. These message types are used to initialize the new session context for the end device. For the Rejoin-request message, the network replies with a Join-accept message.

Data Messages #

There are 4 data message types used in both LoRaWAN 1.0.x and 1.1. These data message types are used to transport both MAC commands and application data which can be combined together in a single message. Data messages can be confirmed or unconfirmed. Confirmed data messages must be acknowledged by the receiver whereas unconfirmed data messages do not need to be acknowledged by the receiver.

A data message is constructed as shown below:

alt_text

MAC payload of the data messages consists of a frame header (FHDR) followed by an optional port field (FPort) and an optional frame payload (FRMPayload).

7 to 22 bytes 0 to 1 byte 0 to N bytes
FHDR FPort FRMPayload

The frame header (FHDR) of the MAC payload consists of the following fields.

4 bytes 1 byte 2 bytes 0 to 15 bytes
DevAddr FCtrl FCnt FOpts

The maximum length of the MAC Payload field is region and data rate-specific and can be found in the Regional Parameters chapter.

Sending MAC Commands and Application-Specific Data #

A data message can contain any sequence of MAC commands. A data message can carry both MAC commands and application data simultaneously in separate fields.

MAC commands can be sent either in the frame options field (FOpts) field or frame payload field (FRMPayload) field of a data message, but not both simultaneously.

Application data can be sent in the frame payload (FRMPayload) field of a data message. The FRMPayload field CAN NOT contain MAC commands and application data simultaneously.

Sending MAC Commands in FOpts Field #

MAC commands can be piggybacked in the FOpts field of a data message for sending. The total length of the MAC commands MUST NOT exceed 15 bytes.

  • In LoRaWAN 1.0.x, these piggybacked MAC commands are always sent unencrypted.
  • In LoRaWAN 1.1, these piggybacked MAC commands are always sent encrypted using the NwkSEncKey.

Sending MAC Commands and Application-specific data in the FRMPayload field #

The FRMPayload field can contain MAC Commands or application data. If the FRMPayload field is not empty, the FPort field must be present. If the FPort field is present,

  • FPort value 0 indicates that the FRMPayload field contains only MAC commands. The total length of the MAC commands MUST NOT exceed the maximum FRMPayload length (region-specific).
  • FPort value 1-223 indicates that the FRMPayload field contains application data.

The following table shows the possible values for the FPort field depending on what it carries.

FPort Value Description
0 MAC commands only
1 to 223 Application-specific data
224 LoRaWAN MAC layer test protocol
255 Reserved for Future Use (RFU)

If the FRMPaylod field contains MAC commands or application data, the FRMPayload field must be encrypted before the Message Integrity Code (MIC) is calculated. This ensures message confidentiality. The following table shows which key is used to encrypt the FRMPayload field in different LoRaWAN versions.

FRMPayload Direction FPort 1.0.x 1.1
MAC Commands Uplink/Downlink 0 NwkSKey NwkSEncKey
Application-specific data Uplink/Downlink 1 to 223 AppSKey AppSKey

Calculating the Message Integrity Code (MIC) #

The Message Integrity Code (MIC) ensures the integrity and authenticity of a message. The message integrity code is calculated over all the fields in the message and then added to the message itself. The following list shows what fields are used to calculate the MIC for each message type in LoRaWAN 1.0.x and 1.1.

LoRaWAN version Message Type Fields
1.0.x Join-request MHDR | AppEUI | DevEUI | DevNonce
1.0.x Join-accept MHDR | AppNonce | NetID | DevAddr | DLSettings | RxDelay | CFList
1.0.x Data messages (up and down) MHDR | FHDR | FPort | FRMPayload
1.1 Join-request MHDR | JoinEUI | DevEUI | DevNonce
1.1 Join-accept MHDR | JoinNonce | NetID | DevAddr | DLSettings | RxDelay | CFList
1.1 Rejoin-request Type 0 and 2 MHDR | Rejoin Type | NetID | DevEUI | RJcount0
1.1 Rejoin-request Type 1 MHDR | Rejoin Type | JoinEUI | DevEUI | RJcount1
1.1 Data messages (up and down) MHDR | FHDR | FPort | FRMPayload

The following table presents which key is used to calculate the MIC of each message type in LoRaWAN 1.0.x and 1.1.

LoRaWAN version Message Type Key
1.0.x Join-request AppKey
1.0.x Join-accept AppKey
1.0.x Uplink data message NwkSKey
1.0.x Downlink data messages NwkSKey
1.1 Join-request NwkKey
1.1 Join-accept JSIntKey
1.1 Rejoin-request Type 0 and 2 SNwkSIntKey
1.1 Rejoin-request Type 1 JSIntKey
1.1 Uplink data messages FNwkSIntKey and SNwkSIntKey
1.1 Downlink data message SNwkSIntKey

When a LoRaWAN 1.1 device is provisioned with a LoRaWAN 1.0.x Network Server, the MIC of each message is calculated as shown in the following table.

Message Type Key
Join-request NwkKey
Join-accept NwkKey
Uplink data messages FNwkSIntKey
Downlink data messages FNwkSIntKey

Practice Questions #

  1. MAC commands can be transported in:

    • FOpts
    • FCtrl
    • FCnt
    • FPort

  2. Application data can be transported in:

    • FRMPayload
    • FOpts
    • FPort
    • FCtrl

  3. Which field can transport application payload or MAC commands?

    • FRMPayload
    • FOpts
    • FPort
    • FCtrl

  4. If the FRMPayload field transports MAC commands in LoRaWAN 1.0.x, it must be encrypted using the:

    • NwkSKey
    • AppSKey
    • NwkSEncKey

  5. If the FRMPayload field transports application data in LoRaWAN 1.0.x, it must be encrypted using the:

    • NwkSKey
    • AppSKey
    • NwkSEncKey

  6. If the FRMPayload field transports MAC commands in LoRaWAN 1.1, it must be encrypted using the:

    • NwkSKey
    • AppSKey
    • NwkSEncKey

  7. If the FRMPayload field transports application-specific data in LoRaWAN 1.1, it must be encrypted using the:

    • NwkSKey
    • AppSKey
    • NwkSEncKey

  8. Which message initiates the over-the-air-activation (OTAA) procedure?

    • Join-request message
    • Join-accept message
    • Uplink data message
    • Downlink data message
← LoRaWAN Relay Security →