LoRaWAN 1.0.4 Specification in Depth For End Device Developers

All end devices must listen for a response from the network server (a downlink) after sending any further uplinks, including end devices which also support Class B or Class C operations. Whilst listening for a response, no further uplinks may be broadcast, and Class B and Class C listening must be paused. This process of sending an uplink and then listening for a downlink is a Class A feature which all devices are required to implement.

At the end of the uplink transmission, the end device must start two timers, RECEIVE_DELAY1 and RECEIVE_DELAY2, as shown in Figure 1 and described below.

• RECEIVE_DELAY1:

  This is a period that begins at the end of the transmission. When this period ends, the end device begins listening for a downlink in what is referred to as receive window 1 (RX1), described below. The network server is aware of the RECEIVE_DELAY1 value, and so begins broadcast at the same time, meaning the end device begins to listen as the broadcast commences.

  Following device reset, RECEIVE_DELAY1 must be set to one second, as defined in Section 2.3, ‘Default Settings’ (page 27) of the RP002-1.0.4 LoRaWAN® Regional Parameters specification.

  If the end device since joined the network using OTAA, this value should have been updated to the value communicated in the RXDelay field in the Join Accept, as described in section Handle the Downlink Configuration Settings (DLSettings and RXDelay) of the End Device Activation Book.

  The network server may also request an update to this value at any time using the Del field in the MAC command RXTimingSetupReq, as described in section Receive Window Timing Request (RXTimingSetupReq) of the Receiving Messages Book. If the end device received a RXTimingSetupReq and responded with an RXTimingSetupAns, then it must use this Del value as the RECEIVE_DELAY1.

• RECEIVE_DELAY2:

  This is a period that begins at the end of the original uplink transmission. When this period ends, the end device begins listening for a downlink again in what is referred to as receive window 2 (RX2). The network server is aware of the value of RECEIVE_DELAY2, and so begins another broadcast at this time. RECEIVE_DELAY2 must be set to RECEIVE_DELAY1 + 1 second, as defined in Section 2.3, ‘Default Settings’ (page 27) of the RP002-1.0.4 LoRaWAN® Regional Parameters specification.

When the RECEIVE_DELAY1 period ends, the end device must open the first receive window (RX1) by beginning to listen for a downlink preamble using the RX1 data rate and channel identified in the ‘Receive Windows’ subsection for the region in Section 2 of the RP002-1.0.4 LoRaWAN Regional Parameters specification.

Inside the Receive Windows section of the Regional Parameters specification, you will find that the data rate used for listening depends on the data rate used to send the uplink, as well as a RX1DROffset value.

The default value of RX1DROffset is 0. If the end device joined the network using OTAA, the RX1DROffset should have been updated to the value communicated in the RX1DROffset bits of the DLSettings field in the Join Accept, as described in section Step 3D: End Device Handles Join Accept of the End Device Activation Book.

The network server may request an update to the RX1DROffset value at any time using the MAC command RXParamSetupReq, as described in section Receive Windows Parameters Request (RXParamSetupReq) of the Receiving Messages Book. If the end device received a RXParamSetupReq MAC command and responded with an RXParamSetupAns, then it should be using the RX1DROffset value in the MAC command instead of the default.

The duration for which the window is open must be as long as required to detect a downlink preamble. Figure 2 shows the RX Window opened.

As shown in Figure 3, if a preamble is detected, the radio receiver must be kept active until the downlink frame is demodulated. After the downlink frame has been demodulated, if the end device address verification and MIC check identifies that the frame is for this device, the process must be ended, and the end device must not open the second receive window.

If no preamble was detected in RX1, when the RECEIVE_DELAY2 period has ended, the end device must open the second receive window (RX2) as shown in Figure 4. To open RX2 the end device must begin to listen for a downlink preamble once again, but this time on the RX2 data rate and channel.

The default data rate and channel to use for RX2 are found in the ‘Receive Windows’ subsection for a given region in Section 2 of the RP002-1.0.4 LoRaWAN Regional Parameters specification. The network server may request an update to the RX2 data rate and frequency at any time using the MAC command RXParamSetupReq, described in section Receive Windows Parameters Request (RXParamSetupReq) of the Receiving Messages Book. If the end device received a RXParamSetupReq MAC command and responded with an RXParamSetupAns then it must use the RX2DataRate and Frequency values in the MAC command instead of the defaults.

RX2 then follows the same rules as RX1. The duration for which the window is open must be as long as required to detect a downlink preamble. If a preamble is detected, the radio receiver must stay active until the downlink frame is demodulated. If no preamble is detected inside the window, the radio receiver must be deactivated, closing the window. At this point, there are no further downlink windows opened until the next uplink is sent, or the end device moves into Class B or Class C mode.

Learn more about receive windows in Section 3.3, ‘Receive Windows’ (page 12) of the TS001-1.0.4 LoRaWAN® L2 1.0.4 Specification.

The explanation of how to process a downlink, if received, is explained in the Receiving Messages Book.