5 MAC Commands
2 For network administration, a set of MAC commands may be exchanged exclusively
- between the network server and the MAC layer on an end-device. MAC layer commands
- are never visible to the application or the application server or the application running on the
- end-device.
- A single data frame can contain any sequence of MAC commands, either piggybacked in the
- FOpts field or, when sent as a separate data frame, in the FRMPayload field with the FPort
- field being set to 0. Piggybacked MAC commands are always sent without encryption and
- must not exceed 15 octets. MAC commands sent as FRMPayload are always encrypted
- and must not exceed the maximum FRMPayload length.
11 | Note: MAC commands whose content shall not be disclosed to an |
---|---|
12 | eavesdropper must be sent in the FRMPayload of a separate data |
13 | message. |
- A MAC command consists of a command identifier (CID) of 1 octet followed by a possibly
- empty command-specific sequence of octets.
16
CID | Command | Transmitted by | Short Description | |
---|---|---|---|---|
End- | Gateway | |||
device | ||||
0x02 | LinkCheckReq | x | Used by an end-device to validate its | |
connectivity to a network. | ||||
0x02 | LinkCheckAns | x | Answer to LinkCheckReq command. | |
Contains the received signal power | ||||
estimation indicating to the end-device the | ||||
quality of reception (link margin). | ||||
0x03 | LinkADRReq | x | Requests the end-device to change data | |
rate, transmit power, repetition rate or | ||||
channel. | ||||
0x03 | LinkADRAns | x | Acknowledges the LinkRateReq. | |
0x04 | DutyCycleReq | x | Sets the maximum aggregated transmit | |
duty-cycle of a device | ||||
0x04 | DutyCycleAns | x | Acknowledges a DutyCycleReq command | |
0x05 | RXParamSetupReq | x | Sets the reception slots parameters | |
0x05 | RXParamSetupAns | x | Acknowledges a RXSetupReq command | |
0x06 | DevStatusReq | x | Requests the status of the end-device | |
0x06 | DevStatusAns | x | Returns the status of the end-device, namely | |
its battery level and its demodulation margin | ||||
0x07 | NewChannelReq | x | Creates or modifies the definition of a radio | |
channel | ||||
0x07 | NewChannelAns | x | Acknowledges a NewChannelReq command | |
0x08 | RXTimingSetupReq | x | Sets the timing of the of the reception slots | |
0x08 | RXTimingSetupAns | x | Acknowledges RXTimingSetupReq | |
command | ||||
0x09 | TxParamSetupReq | x | Used by the network server to set the | |
maximum allowed dwell time and Max EIRP | ||||
of end-device, based on local regulations | ||||
0x09 | TxParamSetupAns | x | Acknowledges TxParamSetupReq command | |
0x0A | DlChannelReq | x | Modifies the definition of a downlink RX1 | |
radio channel by shifting the downlink | ||||
frequency from the uplink frequencies (i.e. | ||||
creating an asymmetric channel) | ||||
0x0A | DlChannelAns | x | Acknowledges DlChannelReq command |
©2016 LoRa™ Alliance Page 22 of 70
The authors reserve the right to change specifications without notice.
LoRaWAN Specification | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
CID | Command | Transmitted by | Short Description | ||||||||
End- | Gateway | ||||||||||
device | |||||||||||
0x80 | Proprietary | x | x | Reserved for proprietary network command | |||||||
to | extensions | ||||||||||
1 | 0xFF | ||||||||||
Table 4: MAC commands | |||||||||||
2 | Note: The length of a MAC command is not explicitly given and must | ||||||||||
3 | be implicitly known by the MAC implementation. | Therefore unknown | |||||||||
4 | MAC commands cannot be skipped and the first unknown MAC | ||||||||||
5 | command terminates the processing of the MAC command sequence. | ||||||||||
6 | It is therefore advisable to order MAC commands according to the | ||||||||||
7 | version of the LoRaWAN specification which has introduced a MAC | ||||||||||
8 | command for the first time. | This way all MAC commands up to the | |||||||||
9 | version of the LoRaWAN specification implemented can be processed | ||||||||||
10 | even in the presence of MAC commands specified only in a version of | ||||||||||
11 | the LoRaWAN specification newer than that implemented. | ||||||||||
12 | |||||||||||
13 | Note: Any values adjusted by the network server (e.g., RX2, new or | ||||||||||
14 | adjusted channels definitions) remain only valid until the next join of | ||||||||||
15 | the end-device. Therefore after each successful join procedure the | ||||||||||
16 | end-device uses the default parameters again and it is up to the | ||||||||||
17 | network server to re-adjust the values again as needed. |