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 46 of 89

LoRaWAN ® L2 1.0.4 Specification © 2020 LoRa Alliance ® Page 47 of 90 The authors reserve the right to change specifications without notice. the end-device and retains full control over the AppSKey used for 1506 protecting its application data. 1507 1508 The format of the NetID is described in [TS002]. 1509 The DLSettings field SHALL contain the downlink configuration: 1510 1511 1512 Bits 7 6:4 3:0 DLSettings RFU RX1DROffset RX2DataRate Table 55: DLSettings field format 1513 1514 The RX1DROffset field sets the offset between the uplink data rate and the downlink data 1515 rate used to communicate with the end-device on the first receive window (RX1). The default 1516 offset is 0. The offset accommodates the maximum power density constraints for gateways in 1517 some regions and balances the uplink and downlink radio link margins. 1518 1519 The RX2DataRate field sets the downlink data rate that serves to communicate with the 1520 end-device on the second receive window (RX2). 1521 The RXDelay field sets the downlink RX1 delay and follows the same convention as the Del 1522 field in the RXTimingSetupReq command. 1523 Default RX data rates, default RX receive delays and the actual relationship between the 1524 uplink and downlink data rate are region-specific and detailed in the "LoRaWAN Regional 1525 Parameters" [RP002] document. 1526 The CFList parameters, when present, SHALL be used in combination with implicit 1527 parameters (defined in [RP002]) to emulate the receipt of existing MAC commands, such as 1528 NewChannelReq or LinkADRReq. The end-device behavior when processing CFList 1529 SHALL be identical to what would result from processing those MAC commands if they were 1530 received in a single downlink frame, after the processing of the non-optional Join-Accept 1531 parameters, with the exception that CFList processing does not generate a MAC answer. 1532 The standard behavior for processing MAC commands is defined in a subsequent section, 1533 and potentially adapted by [RP002]. 1534 If the Join-Accept frame is received following the transmission of a Join-Request, the end- 1535 device SHALL revert to its default channel and RF parameters definitions. All MAC layer 1536 parameters (except RXDelay, RX2DataRate, and RX1DROffset that are transported by 1537 the Join-Accept frame) SHALL be reset to their default values. If the CFlist is present, it is 1538 then applied as defined in [RP002]. 1539 It is RECOMMENDED that the first uplink that follows the reception of the Join-Accept frame 1540 uses the data rate of the successful Join-Request, or a lower data rate. The end-device SHALL 1541 then apply the adaptive date-rate control as defined in section 4.3.1.1. 1542 1543 6.2.7 Join procedure completion for Class C 1544 The end-device that expects to receive Class C downlink frames SHALL send a confirmed 1545 uplink frame or a frame that requires an acknowledgment as soon as possible after receiving 1546 a valid Join-Accept frame. The end-device SHALL continue to send such frames until it 1547

Articles in this issue

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