Document

TS001-1.0.4 LoRaWAN® L2 1.0.4 Specification

Issue link: https://read.uberflip.com/i/1428395

Contents of this Issue

Navigation

Page 74 of 89

LoRaWAN ® L2 1.0.4 Specification © 2020 LoRa Alliance ® Page 75 of 90 The authors reserve the right to change specifications without notice. 15 Continuously Listening End-Device (Class C) 2252 Class C mode is used for applications that have sufficient power available such that they do 2253 not need to minimize the time the radio receiver is active as they do in Class A or Class B 2254 applications. 2255 Class C-capable end-devices SHALL NOT enable Class B and Class C concurrently. Class A 2256 downlink, however, are always available after an end-device uplink. 2257 A Class C-enabled end-device listens as often as possible using a combination of channel/DR 2258 parameters referred to as RXC. The end-device SHALL listen on RXC when it is not (a) 2259 transmitting or (b) receiving on RX1 or (c) receiving on RX2, according to the Class A 2260 definition. To do so, it SHALL open a short window on RXC parameters between the end of 2261 the uplink transmission and the beginning of the RX1 reception window. It SHALL open 2262 another RXC window between the end of the RX1 window and the beginning of the RX2 2263 window, and it SHALL switch to RXC reception parameters as soon as the RX2 reception 2264 window is closed. This final RXC reception window SHALL remain open until the end-device 2265 begins to send another packet. 2266 If the end-device is in the process of demodulating a downlink using the RXC parameters 2267 when the RX1 or RX2 window should be opened, it SHALL stop the demodulation and switch 2268 to the RX1 or RX2 receive window. This applies even when the RXC and RX2 parameters are 2269 identical. The purpose of this rule is to achieve a clear separation between downlinks received 2270 during RX1 and RX2 windows (called Class A downlinks) and downlinks received during a 2271 Class C window (called Class C downlinks). The same frame counter is incremented, whether 2272 the downlink uses RX1/RX2 or RXC. 2273 2274 Note: In order to take advantage of the network-initiated downlink 2275 capabilities provided by Class C, the network needs relatively recent 2276 information of how to best contact the end-device. This information is 2277 provided to the network through any and all uplinks received from the 2278 end-device. For this reason it is important for Class C enabled end- 2279 devices to send regular uplinks which implicitly inform the network of the 2280 best way to contact it as well as providing the network a chance to send 2281 new MAC commands which may be required for proper end-device 2282 operation. 2283 2284 A Class C downlink SHALL NOT transport any MAC command. If an end-device receives a 2285 Class C downlink containing a MAC command, either in the FOpts field (if FPort is either 2286 missing or >0) or in the FRMPayload field (if FPort=0), it SHALL silently discard the entire 2287 frame. 2288 In case a Class C confirmed downlink is received, the end-device SHALL NOT answer later 2289 than a time period equal to CLASS_C_RESP_TIMEOUT * NbTrans + RECEIVE_DELAY2 2290 * (NbTrans-1) when the end-device sets its uplink ADR bit, and CLASS_C_RESP_TIMEOUT 2291 when the end-device unsets its uplink ADR bit. The default value of 2292 CLASS_C_RESP_TIMEOUT is 8s. It can be modified in [RP002], it SHALL not be smaller 2293 than RETRANSMIT_TIMEOUT plus the maximum time on air of the uplink frame. 2294 2295

Articles in this issue

view archives of Document - TS001-1.0.4 LoRaWAN® L2 1.0.4 Specification