4.3 MAC Payload of Data Messages (MACPayload)

The MAC payload of the data messages, a so-called ―data frame‖, contains a frame header

3 (FHDR) followed by an optional port field (FPort) and an optional frame payload field

(FRMPayload).

4.3.1 Frame header (FHDR)

The FHDR contains the short device address of the end-device (DevAddr), a frame control
octet (FCtrl), a 2-octets frame counter (FCnt), and up to 15 octets of frame options (FOpts)
used to transport MAC commands.

Size (bytes)	4	1	2	0..15
FHDR	DevAddr	FCtrl	FCnt	FOpts

10 For downlink frames the FCtrl content of the frame header is:

Bit#	7	6	5	4	[3..0]

FCtrl bits	ADR	RFU	ACK	FPending	FOptsLen

11 For uplink frames the FCtrl content of the frame header is:

Bit#	7	6	5	4	[3..0]

FCtrl bits	ADR	ADRACKReq	ACK	RFU	FOptsLen

4.3.1.1 Adaptive data rate control in frame header (ADR, ADRACKReq in FCtrl)
LoRa network allows the end-devices to individually use any of the possible data rates. This
feature is used by the LoRaWAN to adapt and optimize the data rate of static end-devices.
This is referred to as Adaptive Data Rate (ADR) and when this is enabled the network will be
optimized to use the fastest data rate possible.

17 Adaptive Data Rate control may not be possible when the radio channel attenuation

changes fast and constantly. When the network is unable to control the data rate of a device
, the device‘s application layer should control it. It is recommended to use a variety of
different data rates in this case. The application layer should always try to minimize the
aggregated air time used given the network conditions.
If the ADR bit is set, the network will control the data rate of the end-device through the
appropriate MAC commands. If the ADR bit is not set, the network will not attempt to control
the data rate of the end-device regardless of the received signal quality. The ADR bit may
be set and unset by the end-device or the Network on demand. However, whenever
possible, the ADR scheme should be enabled to increase the battery life of the end-device
and maximize the network capacity.

28	Note: Even mobile end-devices are actually immobile most of the time.
29	So depending on its state of mobility, an end-device can request the
30	network to optimize its data rate using ADR.

If an end-device whose data rate is optimized by the network to use a data rate higher than
its lowest available data rate, it periodically needs to validate that the network still receives
the uplink frames. Each time the uplink frame counter is incremented (for each new uplink,

34	repeated transmissions do	not	increase the counter), the	device increments	an
35	ADR_ACK_CNT counter.	After	ADR_ACK_LIMIT uplinks	(ADR_ACK_CNT	>=

ADR_ACK_LIMIT) without any downlink response, it sets the ADR acknowledgment request
bit (ADRACKReq). The network is required to respond with a downlink frame within the
next ADR_ACK_DELAY frames, any received downlink frame following an uplink frame

The authors reserve the right to change specifications without notice.

			LoRaWAN Specification
1	resets the ADR_ACK_CNT counter. The downlink ACK bit does not need to be set as any
2	response during the receive slot of the end-device indicates that the gateway has still
3	received the uplinks from this device. If no reply is received within the next

ADR_ACK_DELAY uplinks (i.e., after a total of ADR_ACK_LIMIT + ADR_ACK_DELAY), the
end-device may try to regain connectivity by switching to the next lower data rate that
provides a longer radio range. The end-device will further lower its data rate step by step
every time ADR_ACK_DELAY is reached. The ADRACKReq shall not be set if the device
uses its lowest available data rate because in that case no action can be taken to improve
the link range.

10	Note: Not requesting an immediate response to an ADR
11	acknowledgement request provides flexibility to the network to
12	optimally schedule its downlinks.
13

14	Note: In uplink transmissions the ADRACKReq bit is set if
15	ADR_ACK_CNT >= ADR_ACK_LIMIT and the current data-rate is
16	greater than the device defined minimum data rate, it is cleared in
17	other conditions.

4.3.1.2 Message acknowledge bit and acknowledgement procedure (ACK in FCtrl)
When receiving a confirmed data message, the receiver shall respond with a data frame that
has the acknowledgment bit (ACK) set. If the sender is an end-device, the network will send
the acknowledgement using one of the receive windows opened by the end-device after the
send operation. If the sender is a gateway, the end-device transmits an acknowledgment at
its own discretion.
Acknowledgements are only sent in response to the latest message received and are never
retransmitted.

26

27	Note: To allow the end-devices to be as simple as possible and have
28	as few states as possible it may transmit an explicit (possibly empty)
29	acknowledgement data message immediately after the reception of a
30	data message requiring a confirmation. Alternatively the end-device
31	may defer the transmission of an acknowledgement to piggyback it
32	with its next data message.

33	4.3.1.3 Retransmission procedure
34	The number of retransmissions (and their timing) for the same message where an

acknowledgment is requested but not received is at the discretion of the end device and
may be different for each end-device.

37	Note: Some example timing diagrams of the acknowledge mechanism
38	are given in Chapter 18.
39

40	Note: If an end-device has reached its maximum number of
41	retransmissions without receiving an acknowledgment, it can try to re-
42	gain connectivity by moving to a lower data rate with longer reach. It is
43	up to the end-device to retransmit the message again or to forfeit that
44	message and move on.
45

©2016 LoRa™ Alliance	Page 17 of 70	The authors reserve the right to change
		specifications without notice.

			LoRaWAN Specification

1	Note: If the network server has reached its maximum number of
2	retransmissions without receiving an acknowledgment, it will generally
3	consider the end-device as unreachable until it receives further
4	messages from the end-device. It is up to the network server to
5	retransmit the message once connectivity to the end-device in question
6	is regained or to forfeit that message and move on.
7

8	Note: The recommended data rate back-off strategy during re-
9	transmissions is described in Chapter 18.4

4.3.1.4 Frame pending bit (FPending in FCtrl, downlink only)
The frame pending bit (FPending) is only used in downlink communication, indicating that
the gateway has more data pending to be sent and therefore asking the end-device to open
another receive window as soon as possible by sending another uplink message.
The exact use of FPending bit is described in Chapter 18.3.
4.3.1.5 Frame counter (FCnt)
Each end-device has two frame counters to keep track of the number of data frames sent
uplink to the network server (FCntUp), incremented by the end-device and received by the
end-device downlink from the network server (FCntDown), which is incremented by the
network server. The network server tracks the uplink frame counter and generates the
downlink counter for each end-device. After a JoinReq – JoinAccept message exchange or
a reset for a personalized end-device, the frame counters on the end-device and the frame
counters on the network server for that end-device are reset to 0. Subsequently FCntUp and
FCntDown are incremented at the sender side by 1 for each new data frame sent in the
respective direction. At the receiver side, the corresponding counter is kept in sync with the

25 value received provided the value received has incremented compared to the current

counter value and is less than the value specified by MAX_FCNT_GAP¹ after considering
counter rollovers. If this difference is greater than the value of MAX_FCNT_GAP then too
many data frames have been lost then subsequent will be discarded. The FCnt is not
incremented in case of multiple transmissions of an unconfirmed frame (see NbTrans
parameter), or in the case of a confirmed frame that is not acknowledged.
The LoRaWAN allows the use of either 16-bits or 32-bits frame counters. The network side
needs to be informed out-of-band about the width of the frame counter implemented in a
given end-device. If a 16-bits frame counter is used, the FCnt field can be used directly as
the counter value, possibly extended by leading zero octets if required. If a 32-bits frame
counter is used, the FCnt field corresponds to the least-significant 16 bits of the 32-bits
frame counter (i.e., FCntUp for data frames sent uplink and FCntDown for data frames sent
downlink).
The end-device shall not reuse the same FCntUp value, except for retransmission, with the
same application and network session keys.

¹ Actual value for MAX_FCNT_GAP, RECEIVE_DELAY1 and RECEIVE_DELAY2 can be found at

Error! Reference source not found. for EU863-870 or Error! Reference source not found. forUS902-928.

The authors reserve the right to change specifications without notice.

			LoRaWAN Specification

1	Note: Since the FCnt field carries only the least-significant 16 bits of
2	the 32-bits frame counter, the server must infer the 16 most-significant
3	bits of the frame counter from the observation of the traffic.

4.3.1.6 Frame options (FOptsLen in FCtrl, FOpts)
The frame-options length field (FOptsLen) in FCtrl byte denotes the actual length of the
frame options field (FOpts) included in the frame.
FOpts transport MAC commands of a maximum length of 15 octets that are piggybacked
onto data frames; see Chapter 5 for a list of valid MAC commands.
If FOptsLen is 0, the FOpts field is absent. If FOptsLen is different from 0, i.e. if MAC
commands are present in the FOpts field, the port 0 cannot be used (FPort must be either
not present or different from 0).
MAC commands cannot be simultaneously present in the payload field and the frame
options field. Should this occur, the device shall ignore the frame.

4.3.2 Port field (FPort)

If the frame payload field is not empty, the port field must be present. If present, an FPort
value of 0 indicates that the FRMPayload contains MAC commands only; see Chapter 4.4
for a list of valid MAC commands. FPort values 1..223 (0x01..0xDF) are application-
specific. FPort value 224 is dedicated to LoRaWAN Mac layer test protocol.

19		Note : The purpose of Fport value 224 is to provide a dedicated Fport
20		to run Mac compliance test scenarios over-the-air on final versions of
21		devices, without having to rely on specific test versions of devices for
22		practical aspects. The test is not supposed to be simultaneous with live
23		operations, but the Mac layer implementation of the device shall be
24		exactly the one used for the normal application. The test protocol is
25		normally encrypted using the AppSKey. This ensures that the network
26		cannot enable the device‘s test mode without involving the device‘s
27		owner. If the test runs on a live network connected device, the way the
28		test application on the network side learns the AppSkey is outside of
29		the scope of the LoRaWAN specification. If the test runs using OTAA
30		on a dedicated test bench (not a live network), the way the Appkey is
31		communicated to the test bench, for secured JOIN process, is also
32		outside of the scope of the specification.
33		The test protocol, running at application layer, is defined outside of the
34		LoRaWAN spec, as it is an application layer protocol.
35
36	FPort values 225..255 (0xE1..0xFF) are reserved for future standardized application
37	extensions.
38
		Size (bytes)	7..22	0..1	0..N
		MACPayload	FHDR	FPort	FRMPayload

N is the number of octets of the application payload. The valid range for N is region specific
and is defined in the LoRaWAN Regional Parameters document [PARAMS].
N should be equal or smaller than:

42 N ≤ M - 1 - (length ofFHDRin octets)

The authors reserve the right to change specifications without notice.

LoRaWAN Specification

where M is the maximum MAC payload length.

4.3.3 MAC Frame Payload Encryption (FRMPayload)

If a data frame carries a payload, FRMPayload must be encrypted before the message
integrity code (MIC) is calculated.

5 The encryption scheme used is based on the generic algorithm described in IEEE

802.15.4/2006 Annex B [IEEE802154] using AES with a key length of 128 bits.
The key K used depends on the FPort of the data message:

	FPort		K
	0		NwkSKey
9	1..255		AppSKey
		Table 3: FPort list

The fields encrypted are:
pld =FRMPayload
For each data message, the algorithm defines a sequence of Blocks A_i for i = 1..k with k =
ceil(len(pld) / 16):

Size (bytes)	1	4	1	4	4	1	1

*A_i*	0x01	4 x 0x00	Dir	DevAddr	FCntUp or	0x00	i
					FCntDown

The direction field (Dir) is 0 for uplink frames and 1 for downlink frames.
The blocks A_i are encrypted to get a sequence S of blocks S_i:

S_i = aes128encrypt(K, _A_i) for i = 1..k
S = S₁ | S₂ | .. | S_k
Encryption and decryption of the payload is done by truncating
(pld | pad₁₆) xor S
to the first len(pld) octets.

4.3 MAC Payload of Data Messages (MACPayload)