3 - Receiving Messages
Messages sent from a network server to an end device are referred to as downlinks. These are sent to the end device via a single gateway. If there are multiple gateways near a device, the network server will select the most suitable gateway to broadcast from. This means the end device does not need to consider de-duping.
Devices operating in Class A mode only receive downlinks during the receive windows opened following an uplink, as described in the section Opening Receive Windows of the Sending Messages Book.
Devices that support Class B mode as well as Class A can receive additional downlinks in receive windows opened at fixed time slots. Read more about Class B mode in the Class B Book.
Devices that support Class C mode as well as Class A can receive additional downlinks at any time. Read more in the Class C: Continuously Listening for Downlinks book.
Todo
Fix link
In this book, you learn how to receive and handle downlink packets using the LoRaWAN® 1.0.4 specification.
Handling MAC Commands
MAC commands are used to manage the network. There are 13 types of commands, each having a request command and an answer command. There are ten request commands that the end device may receive from the network server, each requiring processing, the outcome of which may require an action to be taken, and a possible answer to be sent. There are three answers that the end device may receive from the network server in return from requests it has initiated. Sending answers and requests from the end device was covered in the section Sending MAC Commands of the Sending Messages Book.
MAC commands can be received individually or in a group of concurrent MAC commands. All MAC commands begin with a single octet containing a Command Identifier (CID). This CID indicates which MAC command type follows in the subsequent octets. The length of the subsequent octets depends on the type of MAC command, as identified in the preceding CID. MAC commands are received in the same way, regardless of whether they are a request or answer.
The diagram below shows the structure of three different MAC command requests and illustrates how each command can have a different length. As mentioned, all MAC commands start with a CID octet. The LinkCheckReq MAC command contains only the CID octet and has no payload. DutyCycleReq contains two octets in total, the CID octet followed by a single octet containing data related to the request. LinkADRReq has a total of five octets, the CID octet followed by four octets containing the data.
The subsequent sections contain details about each MAC command request or answer the end device may receive. The table below lists each command and links to each section.
Note
Some commands are only supported in certain regions. Depending on the regions you intend to sell your device in, you may not need to support all the commands.
Some commands are only used in Class B operations, and only require supporting if Class B operations will be used.
Command Type |
Command Pair |
CID |
Operation Mode |
Regional Support |
---|---|---|---|---|
LinkADRReq |
|
All Classes |
All Regions |
|
RXParamSetupReq |
|
All Classes |
All Regions |
|
RXTimingSetupReq |
|
All Classes |
All Regions |
|
NewChannelReq |
|
All Classes |
Dynamic Channel Plan Regions Only |
|
DlChannelReq |
|
All Classes |
Dynamic Channel Plan Regions Only |
|
TXParamSetupReq |
|
All Classes |
Certain Regions Only |
|
DutyCycleReq |
|
All Classes |
All Regions |
|
DevStatusReq |
|
All Classes |
All Regions |
|
PingSlotChannelReq |
|
Class B Only |
All Regions |
|
BeaconFreqReq |
|
Class B Only |
All Regions |
Command Type |
Command Name |
CID |
Operation Mode |
Regional Support |
---|---|---|---|---|
LinkCheckAns |
|
All Classes |
All Regions |
|
DeviceTimeAns |
|
All Classes |
All Regions |
|
PingSlotInfoAns |
|
Class B only |
All Regions |