Document

ERRATA_L2_1_0_4_D2D

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

Contents of this Issue

Navigation

Page 1 of 2

ERRATA Allow Downlink TransmissionsThe LoRa Alliance © 2021 2 Other deliverables affected: 1. Discussion The description of downlink is overly restrictive, but not normative. Clarify to remove the restriction which imply that D2D is prohibited (same text as 1.2.0). Relax other prohibitions. 2. Proposed changes (normative/informative) ************************ Start of proposed change for 3.2 ************************* 3.2 Downlink Messages Downlink packets are sent to one or more end-devices, typically transmitted by a Network Server through one or more gateways. Each downlink message is sent by the Network Server to only one end-device and is relayed by a single gateway. 1 ************************* End of proposed change for 3.2 **************************** 4.3.1.5 Frame counter (FCnt) There are two frame counters for each end-device. FCntUp is incremented by an end-device when a data frame is transmitted to a Network Server (uplink). FCntDown is incremented by a Network Server when a data frame is transmitted to an end-device (downlink). The Network Server tracks the uplink frame counter and generates the downlink counter for each end- device. Whenever an OTAA end-device successfully processes a Join-Accept frame, the frame counters on the end-device (FCntUp) and the Network side (FCntDown) are reset to 0. For ABP (activation by personalization) end-devices, the frame counters are initialized to 0 by the manufacturer. ABP end-devices SHALL NOT reset the frame counters during the end- device's lifetime. If the end-device is susceptible to losing power during its lifetime (battery replacement, for example), the frame counters SHALL persist during such an event. Subsequently, FCntUp is incremented with each uplink and FCntDown is incremented with each downlink. At the receiver side, the corresponding counter is kept in sync with the received value, provided the received value has been incremented compared to the current counter value, and the frame MIC field matches the MIC value computed locally using the appropriate network session key. FCntUp SHALL NOT be incremented in the case of multiple transmissions of a confirmed or unconfirmed frame (see NbTrans parameter). Network Servers SHALL drop the application payload of the retransmitted frames and only forward a single instance to the appropriate Application Server. A first uplink with FCntUp=0 sent by an ABP or an OTAA end-device after a successful Join procedure SHALL be accepted by a Network Server, provided the MIC field is valid. 1 This specification does not describe the transmission of multicast messages from a network server to many end-devices. Commented [DK1]: Remove footnote, it is incorrect (says we don't describe multicast, but we do)

Articles in this issue

view archives of Document - ERRATA_L2_1_0_4_D2D