Document

TS004-2.0.0 Fragmented Data Block Transport

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

Contents of this Issue

Navigation

Page 12 of 31

LoRaWAN ® Fragmented Data Block Transport Specification TS004-2.0.0 ©2022 LoRa Alliance ® Page 13 of 32 The authors reserve the right to change specifications without notice. FragSize (fragment size) is the size of each fragment, in octets. The data block size is 329 NbFrag × FragSize – Padding. 330 331 Control consists of the following fields 332 333 Bits 7 6 5:3 2:0 Control Fields RFU AckReception FragAlgo BlockAckDelay Table 11: FragSessionSetupReq Control format AckReception encodes how the end-device behaves once the data block has been 334 completely received. If AckReception is set to 1, the end-device SHALL transmit the 335 FragDataBlockReceivedReq command once the data block is fully received. If 336 AckReception is set to 0, the end-device SHALL do nothing and directly proceed to 337 processing the data block. 338 339 FragAlgo encodes the type of fragmentation algorithm used. This parameter is simply 340 passed to the fragmentation algorithm. FragAlgo values are defined in section 5. 341 342 BlockAckDelay encodes the size of the random delay that end-devices have to wait 343 between the reception of a downlink command and the transmission of their answer. 344 BlockAckDelay is only applicable to some commands, as defined in this specification. 345 This parameter is a function of the group size and the geographic spread and is used to 346 avoid too many collisions on the uplink due to many end-devices simultaneously answering 347 the same command. The actual delay SHALL be () × 2 +4 seconds, where 348 () is a random real number in the [0:1] interval. When the end-device is made to reboot 349 automatically at the end of this fragmentation session, the same random delay SHALL be 350 observed before rebooting the end-device. This reboot delay will avoid a massive number of 351 end-devices from restarting synchronously. 352 353 The Padding field encodes the number of padding octets used. The binary data block size 354 may not be a multiple of FragSize. Therefore, some padding octets SHALL be added to 355 fill the last fragment. Once the data block has been reconstructed by the receiver, it SHALL 356 remove the last Padding octets in order to get the original binary file. 357 358 The Descriptor field is a freely allocated 4-octet field describing the data block that is 359 going to be transported through the fragmentation session. For example, this field MAY be 360 used by the end-device to decide where to store the data block, how to treat it once 361 received, etc. If the data block transported is a FUOTA binary image, this field MAY encode 362 the version of the firmware transported to allow end-device-side compatibility verifications. 363 The encoding of this field is vendor specific. 364 365 The SessionCnt field is used to denote the fragmentation session. An end-device MAY 366 support multiple (up to four) fragmentation sessions. For each of those possible 367 fragmentation sessions, the end-device keeps a SessionCntPrev[FragIndex] counter, 368 where FragIndex (between 0 and 3) corresponds to the index of the fragmentation 369 session. The end-device SHALL reject a FragSessionSetupReq command if its 370 SessionCnt field value is less than or equal to SessionCntPrev[FragIndex] and 371 SHALL set the SessionCnt replay bit to 1 in FragSessionSetupAns. For each 372 fragmentation session, the first FragSessionSetupReq command MAY use 373 SessionCnt=0. 374

Articles in this issue

view archives of Document - TS004-2.0.0 Fragmented Data Block Transport