Issue link: https://read.uberflip.com/i/1428383
LoRaWAN 1.0.3 Specification ©2018 LoRa™ Alliance Page 19 of 72 The authors reserve the right to change specifications without notice. 499 Note: The recommended data rate back-off strategy during re- 500 transmissions is described in Chapter 18.4 501 4.3.1.4 Frame pending bit (FPending in FCtrl, downlink only) 502 The frame pending bit (FPending) is only used in downlink communication, indicating that the 503 gateway has more data pending to be sent and therefore asking the end-device to open 504 another receive window as soon as possible by sending another uplink message. 505 The exact use of FPending bit is described in Chapter 18.3. 506 4.3.1.5 Frame counter (FCnt) 507 Each end-device has two frame counters to keep track of the number of data frames sent 508 uplink to the network server (FCntUp), incremented by the end-device and received by the 509 end-device downlink from the network server (FCntDown), which is incremented by the 510 network server. The network server tracks the uplink frame counter and generates the 511 downlink counter for each end-device. After a JoinReq – JoinAccept message exchange or a 512 reset for a personalized end-device, the frame counters on the end-device and the frame 513 counters on the network server for that end-device are reset to 0. Subsequently FCntUp and 514 FCntDown are incremented at the sender side by 1 for each new data frame sent in the 515 respective direction. At the receiver side, the corresponding counter is kept in sync with the 516 value received provided the value received has incremented compared to the current counter 517 value and is less than the value specified by MAX_FCNT_GAP 1 after considering counter 518 rollovers. If this difference is greater than the value of MAX_FCNT_GAP then too many data 519 frames have been lost then subsequent will be discarded. The FCnt is not incremented in 520 case of multiple transmissions of an unconfirmed frame (see NbTrans parameter), or in the 521 case of a confirmed frame that is not acknowledged. 522 The LoRaWAN allows the use of either 16-bits or 32-bits frame counters. The network side 523 needs to be informed out-of-band about the width of the frame counter implemented in a given 524 end-device. If a 16-bits frame counter is used, the FCnt field can be used directly as the 525 counter value, possibly extended by leading zero octets if required. If a 32-bits frame counter 526 is used, the FCnt field corresponds to the least-significant 16 bits of the 32-bits frame counter 527 (i.e., FCntUp for data frames sent uplink and FCntDown for data frames sent downlink). 528 The end-device SHALL not reuse the same FCntUp value, except for retransmission, with the 529 same application and network session keys. 530 Note: Since the FCnt field carries only the least-significant 16 bits of the 531 32-bits frame counter, the server must infer the 16 most-significant bits 532 of the frame counter from the observation of the traffic. 533 4.3.1.6 Frame options (FOptsLen in FCtrl, FOpts) 534 The frame-options length field (FOptsLen) in FCtrl byte denotes the actual length of the frame 535 options field (FOpts) included in the frame. 536 FOpts transport MAC commands of a maximum length of 15 octets that are piggybacked onto 537 data frames; see Chapter 5 for a list of valid MAC commands. 538 1 Actual value for MAX_FCNT_GAP, RECEIVE_DELAY1 and RECEIVE_DELAY2 can be found at Error! Reference source not found. for EU863-870 or Error! Reference source not found. for US902-928.