Issue link: https://read.uberflip.com/i/1464683
LoRaWAN ® Fragmented Data Block Transport Specification TS004-2.0.0 ©2022 LoRa Alliance ® Page 30 of 32 The authors reserve the right to change specifications without notice. is the maximum value of that the end-device can tolerate; if > , the 767 defragmentation fails and is aborted. 768 769 The required defragmentation memory overhead is a function of the maximum value 770 ( ) that the end-device is designed to tolerate. Interestingly, the memory overhead is not 771 a function of the total number of fragments used to convey the data block. This is because 772 the defragmentation implementation is optimized to recognize that the first M fragments 773 actually contain the original uncoded data block (P M i = B M i ≤ ). 774 775 The following table provides a few numerical examples: 776 777 Maximum allowable number of lost fragments ( ) Parity matrix memory (octets) 32 130 40 183 48 243 56 312 64 388 778 The total memory requirement is the sum of the full data block size and the parity matrix 779 memory size. 780 Example: A 50 kB data block must be received, as 1000x50 octet 781 fragments. The end-device is designed to be able to withstand the loss 782 of 64 fragments out of the first 1000 transmitted ( = 64). The end- 783 device requires 50 kB of available memory + 388 octets to store the 784 parity matrix. 785 786 The data block can be reassembled in the memory directly at its final address (this means 787 directly in the FLASH memory space for most end-devices), so there is no need for an 788 additional "data block" swap memory space. 789 790 The parity matrix memory space can be erased and reused once the defragmentation is 791 finished. 792 793 For the encoding process, there is no need to store the parity matrix, so the required 794 memory simply corresponds to the data block to be segmented and transmitted plus very 795 little fixed overhead for temporary calculations. 796 797