Issue link: https://read.uberflip.com/i/1428395
LoRaWAN ® L2 1.0.4 Specification © 2020 LoRa Alliance ® Page 22 of 90 The authors reserve the right to change specifications without notice. 4.3.1.4 Frame pending bit (FPending in FCtrl, downlink only) 671 The frame pending bit (FPending) is used only in downlink communication. For Class A end- 672 devices, FPending indicates that the Network Server has more data pending to be sent and 673 therefore the end-device MAY send an uplink frame as soon as possible. For Class B end- 674 devices, FPending indicates the priority of which conflicting ping slots the end-device SHALL 675 listen to in case of a collision 6 . 676 An example use of the FPending bit is described in Section 16.4. 677 4.3.1.5 Frame counter (FCnt) 678 There are two frame counters for each end-device. FCntUp is incremented by an end-device 679 when a data frame is transmitted to a Network Server (uplink). FCntDown is incremented by 680 a Network Server when a data frame is transmitted to an end-device (downlink). The Network 681 Server tracks the uplink frame counter and generates the downlink counter for each end- 682 device. 683 Whenever an OTAA end-device successfully processes a Join-Accept frame, the frame 684 counters on the end-device (FCntUp) and the Network side (FCntDown) are reset to 0. 685 For ABP (activation by personalization) end-devices, the frame counters are initialized to 0 by 686 the manufacturer. ABP end-devices SHALL NOT reset the frame counters during the end- 687 device's lifetime. If the end-device is susceptible to losing power during its lifetime (battery 688 replacement, for example), the frame counters SHALL persist during such an event. 689 Subsequently, FCntUp is incremented with each uplink and FCntDown is incremented with 690 each downlink. At the receiver side, the corresponding counter is kept in sync with the received 691 value, provided the received value has been incremented compared to the current counter 692 value, and the frame MIC field matches the MIC value computed locally using the appropriate 693 network session key. FCntUp SHALL NOT be incremented in the case of multiple 694 transmissions of a confirmed or unconfirmed frame (see NbTrans parameter). Network 695 Servers SHALL drop the application payload of the retransmitted frames and only forward a 696 single instance to the appropriate Application Server. 697 A first uplink with FCntUp=0 sent by an ABP or an OTAA end-device after a successful Join 698 procedure SHALL be accepted by a Network Server, provided the MIC field is valid. 699 Analogously, a first downlink with FCntDown=0 sent by a Network Server to an ABP or an 700 OTAA end-device after a successful Join procedure SHALL be accepted by the end-device, 701 provided the MIC field is valid. 702 Frame counters are 32 bits wide. The FCnt field SHALL correspond to the least-significant 703 16 bits of the 32-bit frame counter (i.e., FCntUp for data frames sent uplink and FCntDown 704 for data frames sent downlink). 705 The end-device SHALL NOT reuse the same FCntUp value with the same application or 706 network session keys, except for retransmission. 707 The end-device SHALL NOT process any retransmission of the same downlink frame. 708 Subsequent retransmissions SHALL be ignored without being processed. 709 710 6 Cf. Section 9.2.