Document

LoRaWAN® Specification v1.0.3

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

Contents of this Issue

Navigation

Page 16 of 71

LoRaWAN 1.0.3 Specification ©2018 LoRa™ Alliance Page 17 of 72 The authors reserve the right to change specifications without notice. 4.3.1 Frame header (FHDR) 415 The FHDR contains the short device address of the end-device (DevAddr), a frame control 416 octet (FCtrl), a 2-octets frame counter (FCnt), and up to 15 octets of frame options (FOpts) 417 used to transport MAC commands. 418 419 Size (bytes) 4 1 2 0..15 FHDR DevAddr FCtrl FCnt FOpts For downlink frames the FCtrl content of the frame header is: 420 Bit# 7 6 5 4 [3..0] FCtrl bits ADR RFU ACK FPending FOptsLen For uplink frames the FCtrl content of the frame header is: 421 Bit# 7 6 5 4 [3..0] FCtrl bits ADR ADRACKReq ACK ClassB FOptsLen 4.3.1.1 Adaptive data rate control in frame header (ADR, ADRACKReq in FCtrl) 422 LoRa network allows the end-devices to individually use any of the possible data rates. This 423 feature is used by the LoRaWAN to adapt and optimize the data rate of static end-devices. 424 This is referred to as Adaptive Data Rate (ADR) and when this is enabled the network will be 425 optimized to use the fastest data rate possible. 426 Adaptive Data Rate control may not be possible when the radio channel attenuation changes 427 fast and constantly. When the network is unable to control the data rate of a device , the 428 device's application layer should control it. It is recommended to use a variety of different data 429 rates in this case. The application layer should always try to minimize the aggregated air time 430 used given the network conditions. 431 If the ADR bit is set, the network will control the data rate of the end-device through the 432 appropriate MAC commands. If the ADR bit is not set, the network will not attempt to control 433 the data rate of the end-device regardless of the received signal quality. The ADR bit MAY be 434 set and unset by the end-device or the Network on demand. However, whenever possible, the 435 ADR scheme should be enabled to increase the battery life of the end-device and maximize 436 the network capacity. 437 Note: Even mobile end-devices are actually immobile most of the time. 438 So depending on its state of mobility, an end-device can request the 439 network to optimize its data rate using ADR. 440 If an end-device whose data rate is optimized by the network to use a data rate higher than 441 its lowest available data rate, it periodically needs to validate that the network still receives the 442 uplink frames. Each time the uplink frame counter is incremented (for each new uplink, 443 repeated transmissions do not increase the counter), the device increments an 444 ADR_ACK_CNT counter. After ADR_ACK_LIMIT uplinks (ADR_ACK_CNT >= 445 ADR_ACK_LIMIT) without any downlink response, it sets the ADR acknowledgment request 446 bit (ADRACKReq). The network is required to respond with a downlink frame within the next 447 ADR_ACK_DELAY frames, any received downlink frame following an uplink frame resets the 448 ADR_ACK_CNT counter. The downlink ACK bit does not need to be set as any response 449 during the receive slot of the end-device indicates that the gateway has still received the 450 uplinks from this device. If no reply is received within the next ADR_ACK_DELAY uplinks (i.e., 451 after a total of ADR_ACK_LIMIT + ADR_ACK_DELAY), the end-device MAY try to regain 452 connectivity by switching to the next lower data rate that provides a longer radio range. The 453 end-device will further lower its data rate step by step every time ADR_ACK_DELAY is 454

Articles in this issue

view archives of Document - LoRaWAN® Specification v1.0.3