# Adaptive Data Synchronization Algorithm for IoT-Oriented Low-Power Wide-Area Networks
## 3 Remote File Synchronization in IoT LPWANs
### Reference Scenario  
Let us refer to an IoT scenario where a cloud server stores the updated data sent by multiple devices (smartphones, sensors, wearables) connected to the network [30]. Direct connection between cloud and IoT devices (DIoT) is assumed, considering a long-range communication infrastructure such as the one typically used in LPWANs (Figure 1). Therefore, the single DIoT-cloud interaction is depicted as follows. Let us consider two files \(F_{C}\) and \(F_{DIoT}\) at cloud and DIoT side, respectively (Figure 2). \(F_{DIoT}\) is newer than \(F_{C}\), therefore the cloud must receive from the DIoT the information to update \(F_{C}\) to the latest version, that is \(F_{DIoT}\). Without loss of generality, equal size is assumed for \(F_{C}\) and \(F_{DIoT}\). The steps performed for file synchronization are derived from the _rsync_ algorithm, the essentials of which are reported below (see [23; 31] for details). First, the cloud organizes \(F_{C}\) in non-overlapping blocks, named in the following as _chunks_, of size \(d\) bytes. Given the file dimension \(L\), \(N=L/d\) chunks are obtained. For each chunk \(B_{C,i}\) (with \(i=1,2,\ldots,N\)) two checksums \(R_{C,i}\) and \(S_{C,i}\), a weak one and a strong one respectively, are calculated and sent to the DIoT side. Checksums are used to compress the chunks information so that the bytes to be transmitted are reduced. The received sets \(\mathcal{R}=\{R_{C,1},R_{C,2},\ldots,R_{C,N}\}\) and \(\mathcal{S}=\{S_{C,1},R_{S,2},\ldots,R_{S,N}\}\) are used by the DIoT as a reference to process \(F_{DIoT}\) and find potential matchings with \(F_{C}\). Specifically, a moving window \(B_{DIoT,k}\) of dimension equal to \(d\) bytes (\(k\) refers to the window offset along \(F_{DIoT}\), with \(k=1,2,\ldots,L\)) is used to scan \(F_{DIoT}\). The DIoT calculates the checksums \(R_{DIoT,k}\) and \(S_{DIoT,k}\) of the current chunk \(B_{DIoT,k}\) and searches for a matching with any element in \(\mathcal{R}\) and \(\mathcal{S}\) (the weak checksums are analyzed first, then, if there is a positive feedback, the strong checksums are compared to have the proof of chunks matching). If \(B_{DIoT,k}\) is recognized to be already present in \(F_{C}\), the DIoT saves the chunk index, referred as _token_. Otherwise, if no matching is found, the \(k\)-th byte of \(F_{DIoT}\) is evaluated as _new_ and therefore marked to be necessarily sent to the cloud. As the scanning of \(F_{DIoT}\) goes on, the DIoT creates a delta file \(\Delta\) containing tokens and literal bytes that will be ultimately transmitted to the cloud. Once \(\Delta\) is received, the cloud performs the update of \(F_{C}\) and recomputes the checksums on the new file chunks  
Figure 1: Typical IoT scenario where multiple devices are directly connected to the Cloud in a LPWAN. Figure 2: _rsync_ procedure between DIoT and Cloud. that will be used for the next synchronization events. Since the generated \(\Delta\) reports the differences between \(F_{DIoT}\) and \(F_{C}\) files, the _rsync_ algorithm is also named _rdiff_. The good performance of _rsync_ relies on the hypothesis that part of the file to be updated is sufficiently smaller than the entire file dimension. Furthermore, the size of chunks \(d\) and checksums \(R\), \(S\) is set as fixed. As reported in [23], blocks dimensions between 500 to 1000 bytes are optimal. Regarding checksums, two 32-bit and 128-bit signatures are employed respectively to represent each chunk, therefore allowing a significant compression (\(32+128=160\) bits, that is 20 bytes, are transmitted in place of a chunk of size equal to 500 bytes or more). Computer systems for which _rsync_ was initially designed usually consider files of sufficiently large size (tens of megabytes and more), therefore the introduced parameter configuration is appropriate. However, this fact may not be verified in IoT scenarios where limited amounts of data are managed.