# Design and Evaluation of IoT-Enabled Instrumentation for a Soil-Bentonite Slurry Trench Cutoff Wall
## 4 Data Transport
The receiver acknowledges the send request and creates a zeroed bit array containing one bit for each fragment in the chunk. The size of the bit array depends on the number of fragments in the chunk, however, this bit array must be smaller than the MTU of the radio minus all headers, so that it can be transmitted in the payload of a single packet. For common low-power radios with a maximum payload size of 100 bytes, the resulting effective maximum number of fragments is 800 yielding a maximum chunk size of 80 KB. After the send request is acknowledged, the sender transmits all data fragments in the chunk without any individual acknowledgments or additional error checking. We assume the radio hardware supports minimal error detection sufficient to reject most corrupt packets. As a result, the fragment header is only three-bytes long which maximizes efficiency. The header is comprised of a one-byte packet type plus a two-byte fragment identifier. When a fragment is received from the radio, the data is stored and the corresponding bit in the bit array is set by the receiver. After all data fragments are sent, the sender then transmits an acknowledgment request. Upon receiving the acknowledgment request, the receiver transmits the bit array containing the received fragments. In response, the sender retransmits any data fragments where the corresponding bit in the array is not set followed by another acknowledgment request. The process is repeated until all fragments in the current chunk have been acknowledged. Figure 8: The XBee Transfer Protocol breaks a file into chunks with batched acknowledgments per chunk. Lost data packets are retransmitted (dotted lines) until all data fragments in each chunk are received. A final MD5 hash check provides a second-level verification of the transfer. The sender then continues the transfer by sending the remaining chunks in the file using the same process with a new send request message specifying the same filename and the appropriate beginning offset to each chunk. As a final check, after all chunks have been successfully received, the sender transmits a MD5 check message containing the filename and MD5 hash. The receiver computes the MD5 hash on the local file and compares it to the sender's transmitted hash. If they match, the file was successfully transferred. If not, the file transfer failed and the file is deleted. The retriever's MD5 hash is also sent back to the sender. If they do not match, the transfer is started over from the beginning by the sender. This additional check is necessary because most low-power radios (e.g., IEEE 802.15.4) use 16-bit checksums which has the possibility of false positive results. All messages other than the data fragments are considered control messages. Data fragments are sent without MAC-level acknowledgements and rely on XTP's batched acknowledgement mechanism. The control messages are sent using the radio's MAC-level acknowledgement mechanism. On the 900 HP radio module, the default value is 10 retransmissions. On the series 1 radio, the default value is 3 retransmissions. In addition to these retransmissions, XTP will retry each control message 15 times. If XTP's control message retransmissions are exhausted, XTP will abort the transfer and report failure. The protocol is intended to be very lightweight and does not have any inherent security features. Malicious messages could be constructed to corrupt or otherwise manipulate file transfers. However, security can be implemented with additional radio features. In our deployment, the radios are configured with a unique channel hopping sequence and encryption using the radio's built in 128-bit AES encryption for all packets making unauthorized access or manipulation of site data extremely difficult.