# Reliable Link Level Routing Algorithm in Pipeline Monitoring Using Implicit Acknowledgements
## 5 Implementation  
We have performed a practical validation of the proposed architecture using an Atmel RCB256 RFR2 device [53], which includes a compatible IEEE 802.15.4 transceiver (Figure 16). \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Payload** & \(AE_{RXN}\) & \(AE_{TXN}\) & \(AE_{TXN}\) \\ \hline
18 & 22.5\% & 36\% & \(-\)8\% \\
114 & 8\% & 14\% & \(-\)2\% \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Variation of energy consumption in the node with ID = 16 bits  
Figure 16: Atmel RCB256 RFR2 node. Figure 15: Reduction in energy consumption. The MAC layer was implemented with Atmel Software Framework (ASF) [54], which simplifies the control of the contents of the payload and the header of the frame. In our test, nodes operate as Full Function Devices (FFDs), and are arranged in a linear topology with seven nodes, as shown in Figure 17.  
Figure 18a shows the hardware used in the experiments (Atmel RCB256 RFR2 nodes). One of the environments where the measurements were completed is shown in Figure 18b). Previously, we validated the algorithm in the laboratory with three nodes working as TXN, RXN, and INTN, in a controlled environment, where sniffers were used to analyze the traffic among the nodes. Then, we used 7 nodes to build a larger structure. Although the expected communication range with IEEE 802.15.4 would be approximately 70 m, we placed each node 50 m (line of sight) from each other to ensure connectivity. The obtained measurements can be used to estimate the results in an infrastructure of hundreds of nodes, like the required for a scenario such as the shown in Figure 18c). Figure 17: Tested network. Figure 18: (**a**) Used hardware. (**b**) Scenario for the tests. (**c**) Typical pipeline implementation. Table 5 shows the power levels and duration of the frames used in different the tests. A sniffer was used to capture IEEE 802.15.4 frames in order to check the correct operation of the algorithm to transmit information to the control center, even when there are retransmissions or interruptions due to damaged nodes, noisy links, or links that work intermittently. Such scenarios are forced by modifying the code of some nodes. Failures in the link are simulated by forcing the nodes to not transmit the information when they should (according to the algorithm), and some nodes are disconnected to simulate a node that failed completely. Different tests were completed to check the correct operation of the algorithm in those scenarios. For example, Figure 19 shows a test where the connectivity recovery is performed when a node is damaged. In this scenario, node \(v_{o}\) transmits data to node \(v_{2}\), using a broadcast frame, node \(v_{2}\) retransmits it to node \(v_{4}\), since node \(v_{4}\) is broken, node \(v_{2}\) does not receive an iACK and therefore retransmits the frame three times. Node \(v_{o}\) received the iACK from node \(v_{2}\) so it does not retransmit the information. After the third attempt, node \(v_{2}\) transmits a unicast frame to node \(v_{1}\) indicating that node  
Figure 19: Test with a failing node. \begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter** & **Description** \\ \hline Transmission power & 0.5 dBm \\ Distance between nodes & 25 m \\
802.15.4 broadcast frame TXN & 0.384 ms, 12 bytes \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Design parameters. \(v_{4}\) is damaged. Therefore, node \(v_{1}\), which was operating as an INT node, will operate as a TXN node and retransmit the frame to node \(v_{3}\) that, in turn, transmits to node \(v_{5}\), solving the problem of the failed node \(v_{4}\). In case the node \(v_{3}\) is also broken, node \(v_{1}\) will discover that nodes \(v_{3}\) and \(v_{4}\) are failing and it will change the direction of the flow of the transmission. In our approach, the delay for a frame in the node, with a payload of 12 bytes is 2.43 ms (without considering the frame processing time), the average time in the RXN node to retransmit a frame, operating with iACK is 3.4 ms.