Reliable Link Level Routing Algorithm in Pipeline Monitoring Using Implicit Acknowledgements

End-to-end reliability for Wireless Sensor Network communications is usually provided by upper stack layers. Furthermore, most of the studies have been related to star, mesh, and tree topologies. However, they rarely consider the requirements of the multi-hop linear wireless sensor networks, with thousands of nodes, which are universally used for monitoring applications. Therefore, they are characterized by long delays and high energy consumption. In this paper, we propose an energy efficient link level routing algorithm that provides end-to-end reliability into multi-hop wireless sensor networks with a linear structure. The algorithm uses implicit acknowledgement to provide reliability and connectivity with energy efficiency, low latency, and fault tolerance in linear wireless sensor networks. The proposal is validated through tests with real hardware. The energy consumption and the delay are also mathematically modeled and analyzed. The test results show that our algorithm decreases the energy consumption and minimizes the delays when compared with other proposals that also apply the explicit knowledge technique and routing protocols with explicit confirmations, maintaining the same characteristics in terms of reliability and connectivity.


Introduction
Many industrial applications require the deployment of sensor networks that follow straight lines. For example, in applications such as monitoring water, oil, or gas pipelines, roads, tunnels, borders, etc., wireless communication technologies provide clear advantages (such as self-organization, rapid deployment, cost, or flexibility) for the creation of highly reliable and self-healing industrial systems that can respond to new events [1]. This problem has been studied in recent years, and different authors proposed the deployment of Linear Wireless Sensor Networks (LWSN) [2], characterized by sparse node deployment along the linear infrastructure. It is assumed that nodes cannot move after being deployed. One of the main constraints in linear topology is the reduced number of neighbor nodes that limits the feasible transmission routes [2]. Such limitations make traditional solutions for Wireless Sensor Networks (WSNs) inapplicable to LWSNs [3]. For example, complex routing protocols may adversely affect the performance of the sensor network [4], and the limited number of transmission routes may increase the data loss probability [5].
Nevertheless, there are still important challenges that must be addressed. For example, in order to avoid changing batteries (which may be a complex or expensive procedure), power consumption must be optimized [6]. Such infrastructures may cover hundreds or thousands of kilometers, so it is necessary to consider end-to-end delay, node placement, and routing. Different proposals have been developed to optimize the power consumption of the nodes and minimize delays. Many studies have focused on minimizing energy consumption during transmission and reception [7], while others have focused on minimizing the processing of information in the sensor node [8], a task which can also increase the delay.
In LWSNs, nodes may be placed in a thin (one dimension, forming a line) or thick (two or three dimensions around a line) configuration, and can have identical (one-level) or differentiated (multiple-level, creating a hierarchical network) functionalities [9]. In the applications such as pipeline monitoring, a thin one-level network is cheaper and simpler to build and maintain, this being the configuration considered in this paper to propose solutions for the minimization of energy consumption and delays (while maintaining reliability and connectivity) in LWSNs. Nevertheless, a direct transposition of classical protocols on LWSN is not efficient, as linear topologies are the worst cases for hierarchical networks (spoilage) and for stochastic distribution (time for reparation) [10]. Hence, routing protocols designed for nonlinear WSNs should not be directly applied to LWSNs with hundreds or thousands of nodes due to their special topology and application requirements [11]. For example, IEEE 802.15.4 nodes can use ACKs to confirm the reception of a frame. This technique is known as explicit confirmation (eACK), but the transmitting node can also receive an implicit confirmation (or iACK) when it receives the same information after the receiving node retransmit it to the next hop.
By using implicit acknowledgements (iACKs), we can address two challenges: reducing energy consumption and latency. This technique helps to decrease the packet exchange between nodes, and to reduce the communication stack by removing most of the functions usually implemented at network level layer (OSI layer 3). This is possible because in a wireless network when a node transmits a frame, all the active nodes in the coverage area receive it and in addition, in a linear topology, the routing is very simple, as packets can only go in one of the two directions of the linear infrastructure, and nodes just have to decide if they have to retransmit a packet or not. Thus, networking functions that are typically implemented in a separated layer, can now be integrated within layer 2 (link) functionalities. The proposed algorithm for LWSN was validated through real-world testbeds and contributes to the following aspects: • Reliability of the transmission, using iACK. • Reduction of the delay time caused by using acknowledgement frames. • Alternative nodes are selected to transmit when failed nodes or links occurs, without using routing. • Reduction of computation in the node thanks to the elimination of routing tasks. • Automatic assignation of addresses to nodes using link level processes. • Reduction of the energy consumption during the end-to-end reliability transmission process. • Improvement of the scalability with a large number of sensor nodes in LWSN, allowing for the insertion of new nodes automatically. • Maximization of the entire system's lifetime due to the energy efficiency in each node.
The paper is organized as follows: Section 2 discusses the related research; Section 3 presents the proposed algorithm; Section 4 analyzes the energy and the transmission time; and Section 5 describes a real implementation. We conclude our paper in Section 6.

Related Work
WSNs have been widely studied, and there are different protocols that have been designed to support a wide range of network topologies (star, mesh, etc.), for example, 6LowPAN and ZigBee, which can use IEEE 802.15.4 for the lower layers. Nevertheless, linear networks have very specific requirements which are not well addressed by generic protocols, as shown in [12], where the authors review and compare different aspects of routing protocols (addressing policies, discovery mechanisms, routing, etc.) designed specifically for LWSNs or for more traditional WSNs, by analyzing metrics such as end-toend delay, reliability, or deployment requirements. Therefore, we can conclude that LWSNs We take advantage of the previous work and we propose a new cross-layer algorithm for LWSNs, which unifies MAC, routing, and address assignation. This algorithm also provides end-to-end reliability and solves the hidden nodes problem without requiring ACK, RTS, or CTS signaling. Nevertheless, our proposal combines several advantages compared with previous proposals, such as the presented in [12], where the authors review different LPWAN protocols considering static and mobile nodes. Table 1 compares our proposal with the protocols presented for static nodes and some other proposals specifically designed for large scale linear infrastructures. It is important to note that all the studied protocols at the link level use eACK, while our proposal uses iACKs because of the benefits provided for linear infrastructures.
Thus, our work is essential to facilitate the deployment of simple and cheap LWSNs, pave the way for the implementation of new services and applications [30] and take advantage of new paradigms such as fog computing [31], cloud computing [32], and the analysis of large amounts of data [33] also in LWSNs.

Proposed Algorithm
Our algorithm is specifically designed to address the capture of data and its transmission in linear infrastructures. Although many infrastructures are not strictly linear (e.g., a pipeline or a road may have branches), they can be separated in linear segments. Therefore, we make the following assumptions:

•
We consider a linear structure, without branches, with n nodes and two border nodes or base stations, v 0 and v n+1 , which are responsible for sending information to the central monitoring using long-range communication protocols.  [43]), without obstacles and transmission conditions in the line of sight, and is associated with four nodes, two on the left and two on the right.

•
The nodes are deployed with a separation of 25 m. Therefore, a node has at least 4 nodes in range.

•
The participating nodes use a predefined PAN identifier to prevent the connection to other nodes that are not part of the linear infrastructure.

•
Each node has an identifier assigned sequentially and automatically using processes at the link level, as indicated in [44].

•
The bits of the header identified for future use are used to implement the control messages required by the proposed algorithm.
We propose using LWSN topologies as the one shown in Figure 1 which consists of n + 2 nodes, sequentially identified from 0 to n + 1. The sequential assignment of the identifiers is an essential feature on this research approach and solved as detailed in [44].

Proposed Algorithm
Our algorithm is specifically designed to address the capture of data and its transmission in linear infrastructures. Although many infrastructures are not strictly linear (e.g., a pipeline or a road may have branches), they can be separated in linear segments. Therefore, we make the following assumptions:


We consider a linear structure, without branches, with n nodes and two border nodes or base stations, v0 and vn+1, which are responsible for sending information to the central monitoring using long-range communication protocols.  Each node works with the IEEE 802.15.4 standard in beaconless mode (CSMA/CA).  Each node has a coverage area of 50 m (a reasonable distance for an IEEE 802.15.4 network in the 2.4 GHz band [43]), without obstacles and transmission conditions in the line of sight, and is associated with four nodes, two on the left and two on the right.  The nodes are deployed with a separation of 25 m. Therefore, a node has at least 4 nodes in range.  The participating nodes use a predefined PAN identifier to prevent the connection to other nodes that are not part of the linear infrastructure.  Each node has an identifier assigned sequentially and automatically using processes at the link level, as indicated in [44].  The bits of the header identified for future use are used to implement the control messages required by the proposed algorithm.
We propose using LWSN topologies as the one shown in Figure 1 which consists of n + 2 nodes, sequentially identified from 0 to n + 1. The sequential assignment of the identifiers is an essential feature on this research approach and solved as detailed in [44]. Nodes v0 and vn+1 are connected to the control center and do not have any limitation on energy or communication technologies, while nodes v1 to vn are nodes with sensors that capture information and also retransmit the frames of the neighboring nodes. Sensor nodes generate traffic when an event happens (e.g., the rupture of oil pipelines, unauthorized entry into borders, etc.). The information generated by node vi is transmitted to the neighboring nodes, creating two traffic streams simultaneously, Pl (left direction) and Pr (right direction), so it can reach the control center through vo and vn+1. This feature can be used to introduce redundancy in the network, but the operation with both flows is similar, so we are going to study only the Pr flow. The nodes are in fixed locations, and therefore, the topology does not change in time. Modifications to the topology will only be made when a node or several nodes fail, or a link failure occurs. This feature allows the use of simpler routing algorithms and facilitates the location of nodes.

Algorithm Implementation
Each node includes four buffers (buffertx, bufferrx, bufferok, and bufferadj) and will always check if the received frame is stored in one of them to perform the appropriate actions. Bufferok stores the transmitted frames that have successfully arrived at the destination node; buffertx stores the transmitted frames from which a successful transmission has not been confirmed; bufferrx stores the frames received; and bufferadj stores the frames that have been sent by an adjacent node. The node vj is adjacent to node vi, when |j − i| ≤ 2. Nodes v 0 and v n+1 are connected to the control center and do not have any limitation on energy or communication technologies, while nodes v 1 to v n are nodes with sensors that capture information and also retransmit the frames of the neighboring nodes. Sensor nodes generate traffic when an event happens (e.g., the rupture of oil pipelines, unauthorized entry into borders, etc.). The information generated by node v i is transmitted to the neighboring nodes, creating two traffic streams simultaneously, P l (left direction) and P r (right direction), so it can reach the control center through v o and v n+1 . This feature can be used to introduce redundancy in the network, but the operation with both flows is similar, so we are going to study only the P r flow. The nodes are in fixed locations, and therefore, the topology does not change in time. Modifications to the topology will only be made when a node or several nodes fail, or a link failure occurs. This feature allows the use of simpler routing algorithms and facilitates the location of nodes.

Algorithm Implementation
Each node includes four buffers (buffer tx , buffer rx , buffer ok , and buffer adj ) and will always check if the received frame is stored in one of them to perform the appropriate actions. Buffer ok stores the transmitted frames that have successfully arrived at the destination node; buffer tx stores the transmitted frames from which a successful transmission has not been confirmed; buffer rx stores the frames received; and buffer adj stores the frames that have been sent by an adjacent node. The node v j is adjacent to node v i , when |j − i| ≤ 2.
As shown in Figure 2, the transmitting node v i is called TXN, node v i+1 is called INTN (intermediate node) and node v i+2 is called RXN (reception node). When a TXN node transmits a frame, a timer tx is started. When an INTN node receives a frame, it starts a timer int whose minimum value is equal to the time necessary for the RXN node to receive and retransmit the frame. When the node v i detects an event, it sends information to the control center, acting as a TXN node, transmitting a broadcast frame. When node v i+2 receives a broadcast frame with flow P r (towards v n+1 ) and if source address is v i , the node v i+2 it will work as a RXN node. The frame will include the variable FailN that will have been activated if the node v i+2 fails, and the variable ChangeF that indicates a change in the data flow; both variables are initialized with "FALSE". As shown in Figure 2, the transmitting node vi is called TXN, node vi+1 is called INTN (intermediate node) and node vi+2 is called RXN (reception node). When a TXN node transmits a frame, a timertx is started. When an INTN node receives a frame, it starts a timerint whose minimum value is equal to the time necessary for the RXN node to receive and retransmit the frame. When the node vi detects an event, it sends information to the control center, acting as a TXN node, transmitting a broadcast frame. When node vi+2 receives a broadcast frame with flow Pr (towards vn+1) and if source address is vi, the node vi+2 it will work as a RXN node. The frame will include the variable FailN that will have been activated if the node vi+2 fails, and the variable ChangeF that indicates a change in the data flow; both variables are initialized with "FALSE". There are two options to acknowledge the reception of the frame by the RXN node: using explicit ACKs (eACK) or implicit ACKs (iACK). In the first case, when the RXN node successfully receives a frame from TXN, it responds with an ACK, as shown in Figure 3. This approach increases the usage of energy (to explicitly transmit the ACK) and may even increase the latency if we wait for the ACK before transmitting a new frame. In 802.15.4, the additional time that node vi must wait to transmit another frame when an ACK is used is defined by the time to pass from transmission mode to reception (TTA), the duration time of the ACK frame (which involves the additional back off time in the node vi associated with the retransmission of the frame to the vi+2 node), and the time for the Clear Channel Assessment (CCA). Nevertheless, when the RXN node sends again the frame towards the destination (vn+1), the nodes in the surrounding (vi, vi+1, vi+3 and vi+4) will receive the information. Therefore, TXN will know that its frame has arrived at node vi+2 because it has retransmitted it. This works as an implicit acknowledgment (iACK) of the frame sent by node vi and avoids the need for the transmission of an ACK from vi+2 (RXN), as shown in Figure 4. There are two options to acknowledge the reception of the frame by the RXN node: using explicit ACKs (eACK) or implicit ACKs (iACK). In the first case, when the RXN node successfully receives a frame from TXN, it responds with an ACK, as shown in Figure 3. This approach increases the usage of energy (to explicitly transmit the ACK) and may even increase the latency if we wait for the ACK before transmitting a new frame. In 802.15.4, the additional time that node v i must wait to transmit another frame when an ACK is used is defined by the time to pass from transmission mode to reception (TTA), the duration time of the ACK frame (which involves the additional back off time in the node v i associated with the retransmission of the frame to the v i+2 node), and the time for the Clear Channel Assessment (CCA). As shown in Figure 2, the transmitting node vi is called TXN, node vi+1 is called INTN (intermediate node) and node vi+2 is called RXN (reception node). When a TXN node transmits a frame, a timertx is started. When an INTN node receives a frame, it starts a timerint whose minimum value is equal to the time necessary for the RXN node to receive and retransmit the frame. When the node vi detects an event, it sends information to the control center, acting as a TXN node, transmitting a broadcast frame. When node vi+2 receives a broadcast frame with flow Pr (towards vn+1) and if source address is vi, the node vi+2 it will work as a RXN node. The frame will include the variable FailN that will have been activated if the node vi+2 fails, and the variable ChangeF that indicates a change in the data flow; both variables are initialized with "FALSE". There are two options to acknowledge the reception of the frame by the RXN node: using explicit ACKs (eACK) or implicit ACKs (iACK). In the first case, when the RXN node successfully receives a frame from TXN, it responds with an ACK, as shown in Figure 3. This approach increases the usage of energy (to explicitly transmit the ACK) and may even increase the latency if we wait for the ACK before transmitting a new frame. In 802.15.4, the additional time that node vi must wait to transmit another frame when an ACK is used is defined by the time to pass from transmission mode to reception (TTA), the duration time of the ACK frame (which involves the additional back off time in the node vi associated with the retransmission of the frame to the vi+2 node), and the time for the Clear Channel Assessment (CCA). Nevertheless, when the RXN node sends again the frame towards the destination (vn+1), the nodes in the surrounding (vi, vi+1, vi+3 and vi+4) will receive the information. Therefore, TXN will know that its frame has arrived at node vi+2 because it has retransmitted it. This works as an implicit acknowledgment (iACK) of the frame sent by node vi and avoids the need for the transmission of an ACK from vi+2 (RXN), as shown in Figure 4. Nevertheless, when the RXN node sends again the frame towards the destination (v n+1 ), the nodes in the surrounding (v i , v i+1 , v i+3 and v i+4 ) will receive the information. Therefore, TXN will know that its frame has arrived at node v i+2 because it has retransmitted it. This works as an implicit acknowledgment (iACK) of the frame sent by node v i and avoids the need for the transmission of an ACK from v i+2 (RXN), as shown in Figure 4.
In order to summarize, Figure 5 presents a typical scenario. When node v i detects an event, its objective is to transmit this information to the central station, so it transmits the broadcast frame to the node v i+2 , and the node v i+1 also receives the frame. The node v i stores the frame in buffer tx . Nodes v i+1 and v i+2 store the received frame in buffer rx and v i+2 also verifies if it comes from an adjacent node to store it in buffer adj .  In order to summarize, Figure 5 presents a typical scenario. When node vi detects an event, its objective is to transmit this information to the central station, so it transmits the broadcast frame to the node vi+2, and the node vi+1 also receives the frame. The node vi stores the frame in buffertx. Nodes vi+1 and vi+2 store the received frame in bufferrx and vi+2 also verifies if it comes from an adjacent node to store it in bufferadj. The frame retransmission from node vi+2 to node vi+4 is also received by nodes vi, vi+1 and vi+3. When vi receives the retransmission from node vi+2 to node vi+4, it checks if the frame is stored in one of its buffers. If it is stored in buffertx, the node concludes that its transmission was successful without the need of an ACK from vi+2, so it stores the frame in bufferok and eliminates the buffertx frame. If the frame was stored in bufferok, it is discarded because it is confirmed that the frame was received by vi+2. When node vi+1 receives this frame, it verifies if the frame is already stored in any of the buffers. If the received frame is stored in bufferrx, node vi+1 stores the frame in bufferok and removes it from bufferrx. If it is stored in the bufferok, it discards it because it is confirmed that the frame was received by vi+2. Since this frame was not transmitted or retransmitted by the vi+1, it will not be stored in the buffertx.

Algorithm Robustness
A noisy link prevents the signal from being picked up by the receiving node and therefore the frame cannot be recovered and retransmitted to the next node. In 802.15.4 the unslotted mechanism may cause collisions. However, the unsynchronized behavior of the back off mechanism reduces the possibility of simultaneous transmissions, causing the Rx-to-Tx turnaround to be the main reason behind the collisions. The non-negligible Rxto-Tx turnaround time in the unslotted mechanism may cause collisions between data frames [45].
The behavior of the node in noisy links will depend on whether it is a TXN, INTN, or RXN node. We present some examples that depict how our algorithm solves link problems. Consider the case where vi+2 does not retransmit the frame to vi+4 because it did not receive it or received it with errors. So, the vi or vi+1 node will wait a given time for one of  In order to summarize, Figure 5 presents a typical scenario. When node vi detects an event, its objective is to transmit this information to the central station, so it transmits the broadcast frame to the node vi+2, and the node vi+1 also receives the frame. The node vi stores the frame in buffertx. Nodes vi+1 and vi+2 store the received frame in bufferrx and vi+2 also verifies if it comes from an adjacent node to store it in bufferadj. The frame retransmission from node vi+2 to node vi+4 is also received by nodes vi, vi+1 and vi+3. When vi receives the retransmission from node vi+2 to node vi+4, it checks if the frame is stored in one of its buffers. If it is stored in buffertx, the node concludes that its transmission was successful without the need of an ACK from vi+2, so it stores the frame in bufferok and eliminates the buffertx frame. If the frame was stored in bufferok, it is discarded because it is confirmed that the frame was received by vi+2. When node vi+1 receives this frame, it verifies if the frame is already stored in any of the buffers. If the received frame is stored in bufferrx, node vi+1 stores the frame in bufferok and removes it from bufferrx. If it is stored in the bufferok, it discards it because it is confirmed that the frame was received by vi+2. Since this frame was not transmitted or retransmitted by the vi+1, it will not be stored in the buffertx.

Algorithm Robustness
A noisy link prevents the signal from being picked up by the receiving node and therefore the frame cannot be recovered and retransmitted to the next node. In 802.15.4 the unslotted mechanism may cause collisions. However, the unsynchronized behavior of the back off mechanism reduces the possibility of simultaneous transmissions, causing the Rx-to-Tx turnaround to be the main reason behind the collisions. The non-negligible Rxto-Tx turnaround time in the unslotted mechanism may cause collisions between data frames [45].
The behavior of the node in noisy links will depend on whether it is a TXN, INTN, or RXN node. We present some examples that depict how our algorithm solves link problems. Consider the case where vi+2 does not retransmit the frame to vi+4 because it did not receive it or received it with errors. So, the vi or vi+1 node will wait a given time for one of The frame retransmission from node v i+2 to node v i+4 is also received by nodes v i , v i+1 and v i+3 . When v i receives the retransmission from node v i+2 to node v i+4 , it checks if the frame is stored in one of its buffers. If it is stored in buffer tx , the node concludes that its transmission was successful without the need of an ACK from v i+2 , so it stores the frame in buffer ok and eliminates the buffer tx frame. If the frame was stored in buffer ok , it is discarded because it is confirmed that the frame was received by v i+2 . When node v i+1 receives this frame, it verifies if the frame is already stored in any of the buffers. If the received frame is stored in buffer rx , node v i+1 stores the frame in buffer ok and removes it from buffer rx . If it is stored in the buffer ok , it discards it because it is confirmed that the frame was received by v i+2 . Since this frame was not transmitted or retransmitted by the v i+1 , it will not be stored in the buffer tx .

Algorithm Robustness
A noisy link prevents the signal from being picked up by the receiving node and therefore the frame cannot be recovered and retransmitted to the next node. In 802.15.4 the unslotted mechanism may cause collisions. However, the unsynchronized behavior of the back off mechanism reduces the possibility of simultaneous transmissions, causing the Rx-to-Tx turnaround to be the main reason behind the collisions. The non-negligible Rx-to-Tx turnaround time in the unslotted mechanism may cause collisions between data frames [45].
The behavior of the node in noisy links will depend on whether it is a TXN, INTN, or RXN node. We present some examples that depict how our algorithm solves link problems. Consider the case where v i+2 does not retransmit the frame to v i+4 because it did not receive it or received it with errors. So, the v i or v i+1 node will wait a given time for one of them to retransmit the frame to v i+2 . The node v i+1 will wait a time given by timer int , as seen in Figure 6, to retransmit the unicast frame to v i+2 , storing the frame in buffer tx and placing the node address v i+2 in the destination direction of the frame. The node v i+1 retransmits first, as timer tx > timer int , to take advantage of the highest level of the signal that reaches the node v i+2 . This retransmission will be heard by node v i concluding that the frame it previously sent did not reach v i+2 , and it will wait until node v i+2 retransmits the frame.
Additionally, when node v i+2 verifies that its address is in the destination address of the frame, it will understand that it is a retransmission made by the INTN node of the frame that TXN node sent to RXN node with broadcast address. them to retransmit the frame to vi+2. The node vi+1 will wait a time given by timerint, as seen in Figure 6, to retransmit the unicast frame to vi+2, storing the frame in buffertx and placing the node address vi+2 in the destination direction of the frame. The node vi+1 retransmits first, as timertx > timerint, to take advantage of the highest level of the signal that reaches the node vi+2. This retransmission will be heard by node vi concluding that the frame it previously sent did not reach vi+2, and it will wait until node vi+2 retransmits the frame. Additionally, when node vi+2 verifies that its address is in the destination address of the frame, it will understand that it is a retransmission made by the INTN node of the frame that TXN node sent to RXN node with broadcast address. When the frame sent by vi does not reach vi+2 (Figure 7), vi starts a timertx to retransmit the frame to vi+2. After this time, vi will understand that its transmission to vi+2 was not successful, regardless of whether the node vi+1 retransmitted or not the frame to vi+2. Therefore, node vi will retransmit the frame to vi+2 a maximum number of times (set by the aMaxFrameFRameRetries variable) using broadcast destination address in order to make information reach the nodes defined as INTN and RXN. If the maximum number of retransmissions is reached, node vi will understand that node vi+2 could not retransmit the frame and consequently will proceed to execute the damaged node or link procedure: changes the FailN variable to "TRUE" to indicate that the vi+2 node is failing and transmits a unicast frame to the node vi−1 indicating to act as a TXN node so it can transmit the information to node vi+1. In case node vi+1 also fails, vi−1 assigns the value "TRUE" to the FailN variable and transmits the frame to the node vi−1. When the frame transmitted by vi does not reach vi+1 but it reaches vi+2, vi+2 retransmits the frame to vi+4, so this frame is also received by vi+1. This node discards the frame because it has determined that the flow is Pr and that the transmitting node is vi+2, concluding that the frame goes from vi+2 to vi+4 with destination node vn+1. When the frame sent by v i does not reach v i+2 (Figure 7), v i starts a timer tx to retransmit the frame to v i+2 . After this time, v i will understand that its transmission to v i+2 was not successful, regardless of whether the node v i+1 retransmitted or not the frame to v i+2 . Therefore, node v i will retransmit the frame to v i+2 a maximum number of times (set by the aMaxFrameFRameRetries variable) using broadcast destination address in order to make information reach the nodes defined as INTN and RXN. If the maximum number of retransmissions is reached, node v i will understand that node v i+2 could not retransmit the frame and consequently will proceed to execute the damaged node or link procedure: changes the FailN variable to "TRUE" to indicate that the v i+2 node is failing and transmits a unicast frame to the node v i−1 indicating to act as a TXN node so it can transmit the information to node v i+1 . In case node v i+1 also fails, v i−1 assigns the value "TRUE" to the FailN variable and transmits the frame to the node v i−1 .
them to retransmit the frame to vi+2. The node vi+1 will wait a time given by timerint, as seen in Figure 6, to retransmit the unicast frame to vi+2, storing the frame in buffertx and placing the node address vi+2 in the destination direction of the frame. The node vi+1 retransmits first, as timertx > timerint, to take advantage of the highest level of the signal that reaches the node vi+2. This retransmission will be heard by node vi concluding that the frame it previously sent did not reach vi+2, and it will wait until node vi+2 retransmits the frame. Additionally, when node vi+2 verifies that its address is in the destination address of the frame, it will understand that it is a retransmission made by the INTN node of the frame that TXN node sent to RXN node with broadcast address. When the frame sent by vi does not reach vi+2 (Figure 7), vi starts a timertx to retransmit the frame to vi+2. After this time, vi will understand that its transmission to vi+2 was not successful, regardless of whether the node vi+1 retransmitted or not the frame to vi+2. Therefore, node vi will retransmit the frame to vi+2 a maximum number of times (set by the aMaxFrameFRameRetries variable) using broadcast destination address in order to make information reach the nodes defined as INTN and RXN. If the maximum number of retransmissions is reached, node vi will understand that node vi+2 could not retransmit the frame and consequently will proceed to execute the damaged node or link procedure: changes the FailN variable to "TRUE" to indicate that the vi+2 node is failing and transmits a unicast frame to the node vi−1 indicating to act as a TXN node so it can transmit the information to node vi+1. In case node vi+1 also fails, vi−1 assigns the value "TRUE" to the FailN variable and transmits the frame to the node vi−1. When the frame transmitted by vi does not reach vi+1 but it reaches vi+2, vi+2 retransmits the frame to vi+4, so this frame is also received by vi+1. This node discards the frame because it has determined that the flow is Pr and that the transmitting node is vi+2, concluding that the frame goes from vi+2 to vi+4 with destination node vn+1. When the frame transmitted by v i does not reach v i+1 but it reaches v i+2 , v i+2 retransmits the frame to v i+4 , so this frame is also received by v i+1 . This node discards the frame because it has determined that the flow is Pr and that the transmitting node is v i+2 , concluding that the frame goes from v i+2 to v i+4 with destination node v n+1 .
When the frame sent by node v i−2 reaches nodes v i , and the FailN variable is "TRUE", it assumes that nodes v i+1 and v i+2 are damaged and notifies the control station using the opposite route (P l ), and assigns "TRUE" to the variable ChangeF.
If the retransmitted frame by node v i+2 to node v i+4 does not reach v i (the situation would be similar for v i+1 ), v i waits timer tx and retransmits the frame. The receivers verify that it has already been stored in buffer rx or buffer ok and therefore they discard it. Nevertheless, node v i+2 will retransmit again the frame which will be discarded by the nodes v i+1 , v i+3 and v i+4 and node v i will store it in buffer ok and then eliminate it from buffer tx .
When a node v i sends information to the control station in the direction of the flow Pr, and there are at least two damaged nodes, as seen in Figure 8, the last node that works correctly (v k−2 ) will retransmit the frame in the flow towards the node v 0 . At that moment, when the frame passes through node v i , this node, knowing that the variable ChangeF is "TRUE", will change the flow direction, starting to use P l , as the flow Pr is interrupted. When a frame arrives at the central station with ChangeF set to "TRUE", it means that two adjacent nodes are damaged.
When the frame sent by node vi−2 reaches nodes vi, and the FailN variable is "TRUE", it assumes that nodes vi+1 and vi+2 are damaged and notifies the control station using the opposite route (Pl), and assigns "TRUE" to the variable ChangeF.
If the retransmitted frame by node vi+2 to node vi+4 does not reach vi (the situation would be similar for vi+1), vi waits timertx and retransmits the frame. The receivers verify that it has already been stored in bufferrx or bufferok and therefore they discard it. Nevertheless, node vi+2 will retransmit again the frame which will be discarded by the nodes vi+1, vi+3 and vi+4 and node vi will store it in bufferok and then eliminate it from buffertx.
When a node vi sends information to the control station in the direction of the flow Pr, and there are at least two damaged nodes, as seen in Figure 8, the last node that works correctly (vk−2) will retransmit the frame in the flow towards the node v0. At that moment, when the frame passes through node vi, this node, knowing that the variable ChangeF is "TRUE", will change the flow direction, starting to use Pl, as the flow Pr is interrupted. When a frame arrives at the central station with ChangeF set to "TRUE", it means that two adjacent nodes are damaged. It might also happen that the node is in a network segment that has no connection with the end nodes v0 and vn+1, because the nodes vg, vg+1, vk−1 and vk are damaged, as seen in Figure 9. Therefore, the frame would be circulating through the flows Pr and finally by Pl to be later discarded by vg+2. When two nodes want to transmit simultaneously and the nodes are separated by two or three nodes, the problem of the hidden nodes may appear. The collision of the frames due to the problem of the hidden nodes is resolved according to what is indicated in the noisy link scenario.

Traffic Minimization
In linear structures, there is the possibility that several adjacent nodes detect the same event, up to five nodes that are located consecutively. Due to the value of the distance in which the nodes are separated, an event that occurred at a specific location in the linear infrastructure may cause the adjacent nodes to generate the same alarm, at the same moment in time. Therefore, they will try to notify the alarm generated to the central station, by sending a frame using the same predefined data flow, Pr for example. Our proposal prevents adjacent nodes from sending repeated alarms from the same event. Before sending information related to an event, the nodes will check if that information was already transmitted by an adjacent node, confirming that the frame has already been stored in the bufferadj and avoid retransmitting it. It might also happen that the node is in a network segment that has no connection with the end nodes v 0 and v n+1 , because the nodes v g , v g+1 , v k−1 and v k are damaged, as seen in Figure 9. Therefore, the frame would be circulating through the flows P r and finally by P l to be later discarded by v g+2 .
When the frame sent by node vi−2 reaches nodes vi, and the FailN variable is "TRUE", it assumes that nodes vi+1 and vi+2 are damaged and notifies the control station using the opposite route (Pl), and assigns "TRUE" to the variable ChangeF.
If the retransmitted frame by node vi+2 to node vi+4 does not reach vi (the situation would be similar for vi+1), vi waits timertx and retransmits the frame. The receivers verify that it has already been stored in bufferrx or bufferok and therefore they discard it. Nevertheless, node vi+2 will retransmit again the frame which will be discarded by the nodes vi+1, vi+3 and vi+4 and node vi will store it in bufferok and then eliminate it from buffertx.
When a node vi sends information to the control station in the direction of the flow Pr, and there are at least two damaged nodes, as seen in Figure 8, the last node that works correctly (vk−2) will retransmit the frame in the flow towards the node v0. At that moment, when the frame passes through node vi, this node, knowing that the variable ChangeF is "TRUE", will change the flow direction, starting to use Pl, as the flow Pr is interrupted. When a frame arrives at the central station with ChangeF set to "TRUE", it means that two adjacent nodes are damaged. It might also happen that the node is in a network segment that has no connection with the end nodes v0 and vn+1, because the nodes vg, vg+1, vk−1 and vk are damaged, as seen in Figure 9. Therefore, the frame would be circulating through the flows Pr and finally by Pl to be later discarded by vg+2. When two nodes want to transmit simultaneously and the nodes are separated by two or three nodes, the problem of the hidden nodes may appear. The collision of the frames due to the problem of the hidden nodes is resolved according to what is indicated in the noisy link scenario.

Traffic Minimization
In linear structures, there is the possibility that several adjacent nodes detect the same event, up to five nodes that are located consecutively. Due to the value of the distance in which the nodes are separated, an event that occurred at a specific location in the linear infrastructure may cause the adjacent nodes to generate the same alarm, at the same moment in time. Therefore, they will try to notify the alarm generated to the central station, by sending a frame using the same predefined data flow, Pr for example. Our proposal prevents adjacent nodes from sending repeated alarms from the same event. Before sending information related to an event, the nodes will check if that information was already transmitted by an adjacent node, confirming that the frame has already been stored in the bufferadj and avoid retransmitting it. When two nodes want to transmit simultaneously and the nodes are separated by two or three nodes, the problem of the hidden nodes may appear. The collision of the frames due to the problem of the hidden nodes is resolved according to what is indicated in the noisy link scenario.

Traffic Minimization
In linear structures, there is the possibility that several adjacent nodes detect the same event, up to five nodes that are located consecutively. Due to the value of the distance in which the nodes are separated, an event that occurred at a specific location in the linear infrastructure may cause the adjacent nodes to generate the same alarm, at the same moment in time. Therefore, they will try to notify the alarm generated to the central station, by sending a frame using the same predefined data flow, P r for example. Our proposal prevents adjacent nodes from sending repeated alarms from the same event. Before sending information related to an event, the nodes will check if that information was already transmitted by an adjacent node, confirming that the frame has already been stored in the buffer adj and avoid retransmitting it.

Pseudocode and State Diagram
The Algorithm 1 that determines the operation of a node is presented below. All nodes that are part of the linear infrastructure will run the same code. Algorithm 1 Pseudo-code for our proposal 1 Input: id_s is source address, 2 Input: id_d is destination address, 3 Input: Maxwait is maximum wait time for an iACK from of node TXN or INTN, 4 Input: FailN node is on 5 Input: ChangeF The direction of traffic flow has not change 6 if frame received then 7 if frame is stored in buffer adj or buffer ok then frame is discarded 8 else 9 case id_s == i−1, and id_d == broadcast: the node is INTN, and waits iACK from node i+1: 10 case id_s == i+1: 11 case id_d == broadcast: the node behaves as INTN and discards the frame clean buffer rx and stores frame in buffer ok : 12 case id_d == unicast: (i+3 node fail) node works as TXN and retransmits the frame with id_d = broadcast, stores the frame in buffer tx : 13 case id_s == i−2 and id_d == broadcast: behaves as an RXN node and retransmits the frame with id_d = broadcast, store the frame in buffer tx : 14 case id_s == i+2 and id_d == broadcast: 15 if FailN == F then it has received an iACK, stores frame buffer ok and transmits the following frame else 16 case ChangeF == F, set ChangeF = T, transmit broadcast frame: 17 case ChangeF == T, discard the frame:

Pseudocode and State Diagram
The Algorithm 1 that determines the operation of a node is presented below. All nodes that are part of the linear infrastructure will run the same code.

Algorithm 1 Pseudo-code for our proposal 1 Input:
id_s is source address, 2 Input: id_d is destination address, 3 Input: Maxwait is maximum wait time for an iACK from of node TXN or INTN, 4 Input: FailN node is on 5 Input: ChangeF The direction of traffic flow has not change 6 if frame received then 7 if frame is stored in bufferadj or bufferok then frame is discarded 8 else 9 case id_s == i−1, and id_d == broadcast: the node is INTN, and waits iACK from node i+1: 10 case id_s == i+1: 11 case id_d == broadcast: the node behaves as INTN and discards the frame clean bufferrx and stores frame in bufferok: 12 case id_d == unicast: (i+3 node fail) node works as TXN and retransmits the frame with id_d = broadcast, stores the frame in buffertx : 13 case id_s == i−2 and id_d == broadcast: behaves as an RXN node and retransmits the frame with id_d = broadcast, store the frame in buffertx:

System Model
To build the model, we consider a linear structure described in Section 3. For the analysis, ideal conditions are assumed: no collision, no overhead for turning on the transceiver, and prompt response in the MAC layer. Note that these assumptions are especially realistic for many LWSN networks that monitor some parameters to know the state of the infrastructure (pressure, vibrations, leaks, etc.) in vast areas: small amount of traffic, few nodes within the coverage area, environments where the presence of interference is minimal (e.g., in networks for pipe monitoring, road borders, etc.). Our proposal does not support sensors that require large bandwidths, such as cameras, radars, or lidars, that could be used to monitor especially relevant areas. Nevertheless, a separate network could be easily deployed for such traffic in the required locations.
Although the processing of the frame for its forwarding is not negligible, we do not consider that time for the analysis because the delay caused is the same for scenarios that use iACK and eACK. Other considerations are presented below.


All the frames have the same length, so the transmission times are fixed.  Distance between transmitter and receiver is 50 m.  Probability of error when transmitting a frame in each link is the same. We include a model for comparing the latency added by a retransmission using eACK or iACK. Nevertheless, for the sake of simplicity, we did not consider retransmissions in the end-to-end analysis.  ACK frames have a constant length.

System Model
To build the model, we consider a linear structure described in Section 3. For the analysis, ideal conditions are assumed: no collision, no overhead for turning on the transceiver, and prompt response in the MAC layer. Note that these assumptions are especially realistic for many LWSN networks that monitor some parameters to know the state of the infrastructure (pressure, vibrations, leaks, etc.) in vast areas: small amount of traffic, few nodes within the coverage area, environments where the presence of interference is minimal (e.g., in networks for pipe monitoring, road borders, etc.). Our proposal does not support sensors that require large bandwidths, such as cameras, radars, or lidars, that could be used to monitor especially relevant areas. Nevertheless, a separate network could be easily deployed for such traffic in the required locations.
Although the processing of the frame for its forwarding is not negligible, we do not consider that time for the analysis because the delay caused is the same for scenarios that use iACK and eACK. Other considerations are presented below.


All the frames have the same length, so the transmission times are fixed.  Distance between transmitter and receiver is 50 m.  Probability of error when transmitting a frame in each link is the same. We include a model for comparing the latency added by a retransmission using eACK or iACK. Nevertheless, for the sake of simplicity, we did not consider retransmissions in the end-to-end analysis.  ACK frames have a constant length.

System Model
To build the model, we consider a linear structure described in Section 3. For the analysis, ideal conditions are assumed: no collision, no overhead for turning on the transceiver, and prompt response in the MAC layer. Note that these assumptions are especially realistic for many LWSN networks that monitor some parameters to know the state of the infrastructure (pressure, vibrations, leaks, etc.) in vast areas: small amount of traffic, few nodes within the coverage area, environments where the presence of interference is minimal (e.g., in networks for pipe monitoring, road borders, etc.). Our proposal does not support sensors that require large bandwidths, such as cameras, radars, or lidars, that could be used to monitor especially relevant areas. Nevertheless, a separate network could be easily deployed for such traffic in the required locations.
Although the processing of the frame for its forwarding is not negligible, we do not consider that time for the analysis because the delay caused is the same for scenarios that use iACK and eACK. Other considerations are presented below.

•
All the frames have the same length, so the transmission times are fixed. • Distance between transmitter and receiver is 50 m. • Probability of error when transmitting a frame in each link is the same. We include a model for comparing the latency added by a retransmission using eACK or iACK. Nevertheless, for the sake of simplicity, we did not consider retransmissions in the end-to-end analysis.

End-to-End Transmission Time
It is important to know how much time is necessary to transmit information from a sensor to the control station. We can approximate the end-to-end delay by the sum of the time between the arrival of information at a node v i and the arrival at the v i+2 node [46]. In this scenario the information (alerts) is just transmitted using a single frame, and the probability that other nodes that are part of the lineal infrastructure generate alarms at the same time is very low. Therefore, this simplification will be realistic in many situations.
Then, it is necessary to determine the time to transmit a frame when using explicit ACK, Equation (1), or implicit ACK, Equation (2): where x represents the number of bytes that have been received from the upper layer, T BO is the back off period, T CCA means Clear Channel Assessment time, T f ra (x) is Transmission time for a payload of x byte, T TA is Turnaround time from TX to RX, T ACK is Transmission time for an ACK, T IFS (Interframe Space time) is the Frame Processing time, τ is Propagation delay.
The back off period is calculated as the product of the number of back off slots and the time for each slot (20 symbols or 320 µs). The number of back off slots is a random number uniformly in the interval (0, 2 BE − 1), with BE the back off exponent which has a minimum of 3. As we only assume one sender and a Bit Error Rate (BER) of zero, the BE value will not change. Hence, the number of back off slots can be represented as the mean of the interval: (2, 2 3 − 1) or 3.5. Regarding IFS, Short IFS (SIFS) is used when the Media Access Control Protocol Data Unit (MPDU) is smaller than or equal to 18 bytes (192 µs). Otherwise, Long IFS (LIFS) is used (640 µs). Then, the transmission time of a frame with a payload of x bytes can be formulated as: where L phy is the Length of the PHY and synchronization header in bytes (6 bytes), L MACHDR is Length of the MAC header in bytes (3 bytes), L address is the length of the MAC address info field, L MACFTR is the length of the MAC footer in bytes (2 bytes), and R data is the raw data rate (250 kbps). The transmission time for an acknowledgment can be formulated as: So, in summary, the delay can be expressed as: In Equation (5), a and b depend on the length of the data bytes (SIFS or LIFS) and the length of the address used (64 bit, 16 bit, or no addresses). Then, the delay in the communication between a node and the edge node is a linear function of the number of bytes in the payload and the number of nodes. The MPDU is set to a maximum of 127 bytes, but the maximum number of payload bits depends on the usage of short or long addresses. Figure 13 shows the time required by the RXN node to retransmit a message, and the time required by TXN to send a second frame using eACK and iACK, B0 = 3 and short addresses scheme.

021, 21, x FOR PEER REVIEW
14 of 24 Figure 13 shows the time required by the RXN node to retransmit a message, and the time required by TXN to send a second frame using eACK and iACK, B0 = 3 and short addresses scheme. The results indicate that in the different scenarios the delay is lower when iACK is used. With a payload of 114 bytes and eACK, the delay in RXN is 5.88 ms while with iACK it is 5.53 ms. With a 12-byte payload and eACK, the delay is 2.62 ms and with iACK it is 2.27 ms. Thus, delays increase with payload length, but they are always lower with iACK. Figure 14 shows how the delay decreases with the use of iACK instead of eACK, in percentages that depend on the payload, the length of the node's address and the mode of operation of the node, TXN or RXN. The delay reduction by using iACK is higher in the TXN node. In RXN, the percentage is smaller when the payload decreases. When the TXN node sends a frame to the RXN node, the node expects to receive an eACK or an iACK. The node must wait a maximum time to receive these confirmations, before concluding that the sent frame did not reach its destination because of errors in the transmission. The channel error probability is independent of the acknowledgment method used, however when there are erroneous frames, the retransmission time of the frames varies according to the approach used. IEEE 802.15.4 defines the MacAckWaitDuration parameter, with a value of 54 Ts, as the time that the TXN node must wait to retransmit a frame when it does not receive an eACK. The results indicate that in the different scenarios the delay is lower when iACK is used. With a payload of 114 bytes and eACK, the delay in RXN is 5.88 ms while with iACK it is 5.53 ms. With a 12-byte payload and eACK, the delay is 2.62 ms and with iACK it is 2.27 ms. Thus, delays increase with payload length, but they are always lower with iACK. Figure 14 shows how the delay decreases with the use of iACK instead of eACK, in percentages that depend on the payload, the length of the node's address and the mode of operation of the node, TXN or RXN. The delay reduction by using iACK is higher in the TXN node. In RXN, the percentage is smaller when the payload decreases.

021, 21, x FOR PEER REVIEW
14 of 24 Figure 13 shows the time required by the RXN node to retransmit a message, and the time required by TXN to send a second frame using eACK and iACK, B0 = 3 and short addresses scheme. The results indicate that in the different scenarios the delay is lower when iACK is used. With a payload of 114 bytes and eACK, the delay in RXN is 5.88 ms while with iACK it is 5.53 ms. With a 12-byte payload and eACK, the delay is 2.62 ms and with iACK it is 2.27 ms. Thus, delays increase with payload length, but they are always lower with iACK. Figure 14 shows how the delay decreases with the use of iACK instead of eACK, in percentages that depend on the payload, the length of the node's address and the mode of operation of the node, TXN or RXN. The delay reduction by using iACK is higher in the TXN node. In RXN, the percentage is smaller when the payload decreases. When the TXN node sends a frame to the RXN node, the node expects to receive an eACK or an iACK. The node must wait a maximum time to receive these confirmations, before concluding that the sent frame did not reach its destination because of errors in the transmission. The channel error probability is independent of the acknowledgment method used, however when there are erroneous frames, the retransmission time of the frames varies according to the approach used. IEEE 802.15.4 defines the MacAckWaitDuration parameter, with a value of 54 Ts, as the time that the TXN node must wait to retransmit a frame when it does not receive an eACK. When the TXN node sends a frame to the RXN node, the node expects to receive an eACK or an iACK. The node must wait a maximum time to receive these confirmations, before concluding that the sent frame did not reach its destination because of errors in the transmission. The channel error probability is independent of the acknowledgment method used, however when there are erroneous frames, the retransmission time of the frames varies according to the approach used. IEEE 802.15.4 defines the MacAckWaitDuration parameter, with a value of 54 Ts, as the T weACK time that the TXN node must wait to retransmit a frame when it does not receive an eACK.
when iACK is used, the time that the TXN node must wait to start the retransmission process of the frame, T wiAck , is equal to the time it takes for the RXN node to finish retransmitting the entire frame plus the T BO and T CCA times. This is because the TXN node must receive the frame retransmitted by the RXN node to validate the successful transmission.
Even though the delay to retransmit the erroneous frame is greater with iACK, we must bear in mind that with iACK the retransmission of the frame in each node when there are no errors is 34 Ts faster, as mentioned above. As such, the time that is lost with iACK when the frame is retransmitted is compensated in the following hops. The number of hops required to make up the time lost due to iACK retransmission is shown in Table 2.
Having into account that a typical linear infrastructure includes hundreds or thousands of nodes, there will not probably be any extra delay caused by using iACK instead of eACK. In linear structures with n nodes, the time to transmit information from node i to the extreme of the network, without collisions or lost frames in the transmission, is (for P l and P r flows): Since each node knows its position or address (i) within the linear infrastructure, it will select the shortest path to reach the extreme of the network, so it will select the P l or P r flow that minimizes the delay. Table 3 shows the time to transmit from a node to the extreme of the network with a variable number of intermediate nodes. By using the iACK mechanism the time can be reduced by 9%.

Energy Consumption
WSN nodes are composed of several functional modules that should be modeled in order to estimate the energy consumption: microprocessor, transceiver, sensor, and power supply. The most relevant is the communication model that considers the energy consumption of the transmitter and receiver [47]. Most sensor nodes support the states Idle, Transmit and Receive.
To model the energy consumed by transceiver, the average active ratio has been used. It is defined as the average active time divided by the total time spent [48]. It is a reasonable measure since energy consumption for transmission and reception (including idle listening and channel sensing) are similar in many transceivers compared to the energy consumption for standby or sleep mode [49].
An analysis has been performed to evaluate the energy consumption using iACK or eACK. Considering typical scenarios for linear structures where only alarms are transmitted, making the traffic generated very low. Let P t , P r , P i be the power consumed during transmission, reception and idle states respectively, and let the duration of a transmission be the sum of the duration of the data frame, ACK frame, back off, IFS, turnaround, CCA and TA.
When using eACK, the RXN node consumes an additional amount of energy to confirm the reception of the frame.
The percentage of additional energy consumed by the RXN node, AE RXN, using eACK to receive the frame, transmit the ACK and be ready to retransmit the frame, can be calculated as, (Equation (11)): The energy consumed in the TXN node to know that the frame sent was received can be calculated for the eACK (Equation (12)) and iACK schemes (Equation (13)): The percentage of additional energy consumed by the TXN node, AE TXN , using eACK to send the next frame, can be calculated as Equation (14): The percentage of additional energy consumed by the TXN node, AE TXN f using eACK to retransmit the frame that did not reach the RXN node, can be calculated as Equation (15): Many research works have evaluated sensor node energy consumption while transmitting, receiving, or idle. In most cases energy consumption is similar in transmission or reception mode (processing and waiting) [50,51] and slightly larger than the idle mode consumption. In our experiments, and according to the specifications of our hardware [52], our node uses 55.8 mW, 49.9 mW, and 12.3 mW for P t , P r , and P i respectively, in non-beacon mode. In all cases, these values depend on the particular sensor node. Figure 15 shows how energy consumption in the TXN and RXN nodes is reduced when iACK is used in comparison with eACK. Percentages depend on payload, node address length, and mode of operation. The percentage decrease in power consumption at the RXN node is better with small payload as opposed to the TXN node, where it is better with large payload. 021, 21, x FOR PEER REVIEW 17 of 24 Figure 15. Reduction in energy consumption. Table 4 shows the percentage of energy saved when using iACK compared to the use of eACK. The reduction in energy consumption in the RXN node using iACK to retransmit the frame depends on interframe spacing. With SIFS it is about 22.5%, and with LIFS is about 8%. In TXN mode, the reduction in consumption to transmit two frames using iACK depends on the payload. With a payload of 18 bytes, it is possible to save 36% of energy, and with a payload of 114 bytes about 14%. In the RXN node the use of iACK to detect the loss of frames implies an increase of energy consumption that depends on the payload. With a payload of 18 bytes the increase is about 8% of the total energy consumed by the node and with a payload of 114 bytes the increase is about 2%. Thus, by confirming the reception of the information using iACKs we can reduce the consumption of energy [28]. When the transmission reliability is left for superior layers, where the vn+1 node confirms the message reception to the node vi, the energy consumption affects all the intermediate nodes that transmit the ACK confirmation.

Implementation
We have performed a practical validation of the proposed architecture using an Atmel RCB256RFR2 device [53], which includes a compatible IEEE 802.15.4 transceiver ( Figure 16). 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.  Table 4 shows the percentage of energy saved when using iACK compared to the use of eACK. The reduction in energy consumption in the RXN node using iACK to retransmit the frame depends on interframe spacing. With SIFS it is about 22.5%, and with LIFS is about 8%. In TXN mode, the reduction in consumption to transmit two frames using iACK depends on the payload. With a payload of 18 bytes, it is possible to save 36% of energy, and with a payload of 114 bytes about 14%. In the RXN node the use of iACK to detect the loss of frames implies an increase of energy consumption that depends on the payload. With a payload of 18 bytes the increase is about 8% of the total energy consumed by the node and with a payload of 114 bytes the increase is about 2%. Thus, by confirming the reception of the information using iACKs we can reduce the consumption of energy [28]. When the transmission reliability is left for superior layers, where the v n+1 node confirms the message reception to the node v i , the energy consumption affects all the intermediate nodes that transmit the ACK confirmation.

Implementation
We have performed a practical validation of the proposed architecture using an Atmel RCB256RFR2 device [53], which includes a compatible IEEE 802.15.4 transceiver ( Figure 16).  Table 4 shows the percentage of energy saved when using iACK compared to the use of eACK. The reduction in energy consumption in the RXN node using iACK to retransmit the frame depends on interframe spacing. With SIFS it is about 22.5%, and with LIFS is about 8%. In TXN mode, the reduction in consumption to transmit two frames using iACK depends on the payload. With a payload of 18 bytes, it is possible to save 36% of energy, and with a payload of 114 bytes about 14%. In the RXN node the use of iACK to detect the loss of frames implies an increase of energy consumption that depends on the payload. With a payload of 18 bytes the increase is about 8% of the total energy consumed by the node and with a payload of 114 bytes the increase is about 2%. Thus, by confirming the reception of the information using iACKs we can reduce the consumption of energy [28]. When the transmission reliability is left for superior layers, where the vn+1 node confirms the message reception to the node vi, the energy consumption affects all the intermediate nodes that transmit the ACK confirmation.

Implementation
We have performed a practical validation of the proposed architecture using an Atmel RCB256RFR2 device [53], which includes a compatible IEEE 802.15.4 transceiver ( Figure 16). 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. 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. 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 RCB256RFR2 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 18a shows the hardware used in the experiments (Atmel RCB256RFR2 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). 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 RCB256RFR2 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).    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. 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 vo transmits data to node v2, using a broadcast frame, node v2 retransmits it to node v4, since node v4 is broken, node v2 does not receive an iACK and therefore retransmits the frame three times. Node vo received the iACK from node v2 so it does not retransmit the information. After the third attempt, node v2 transmits a unicast frame to node v1 indicating that node v4 is damaged. Therefore, node v1, which was operating as an INT node, will operate as a TXN node and retransmit the frame to node v3 that, in turn, transmits to node v5, solving the problem of the failed node v4. In case the node v3 is also broken, node v1 will discover 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 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. This value is similar to the average retransmission time in a TelosB node running TinyOS, which is 3.63 ms [55].
To measure the frame processing time, we used a RCB256RFR2 node, which includes an IEEE 802.15.4 transceiver. The MAC layer was implemented using Atmel Software Framework (ASF), which provides direct access to the payload and the header of the frame, without requiring an operating system in the node. This feature allowed us to measure delays using iACK and eACK with IDnode = IDPAN = 2 bytes, BO = 3 and with a frame processing time equal to LIFS 0.640 microseconds. Tables 6 and 7 show how there is also a small reduction in the processing time when using iACK both in the node working as TXN or the node working as RXN. This also helps saving energy. The difference in the frame processing time is related to the low-level operation of the software stack of the node. Other protocols, such as AODV, HTR [56] COLBA, ABORT [57], RPL, or 6LowPAN [58] require higher times. For example, we can compare our proposal with 6LowPAN, a protocol that also provides address autoconfiguration, is robust against link failure or device unavailability, and that is designed for large multi-hop networks. Table 8 shows the end-to-end delay measured in [58] using 6LowPAN and using our proposal. 6LowPAN is a protocol designed for multi-hop networks, but it is not specifically adapted to large-scale multi-hop linear topologies, causing high delays because of retransmissions in higher transport layers.
It is also possible to place nodes closer than the maximum communication range to reduce the transmission power and reduce the probability to require retransmissions. For example, nodes can be placed in each one of the segments that are used to build the pipeline. Typically, those segments have a maximum length of 15 m.

Conclusions
This paper presents a new proposal for sensing linear infrastructures with WSN to send alerts. By taking advantage of the physical topology imposed by the infrastructure, we use implicit ACKs (iACKs) to reduce energy consumption and the time to transmit information to the edge of the linear segment (connected to the control center of the infrastructure). The routing also takes advantage of the particularities of the linear topology. We described the operation of the algorithm in a typical scenario and in the presence of problems such as noisy links or with inoperative nodes, showing how the algorithm can solve the problem to forward the information to the edge of the network.
After studying different existing proposals, we observe that our algorithm covers almost all the functions typically related to the network layer. Therefore, by using our algorithm at the link level layer allows for eliminating the network layer in a linear topology, leaving the few functions that are not performed, such as flow control, to the transport or application layer.
We have modeled the time required to transmit alerts from a node to the control center in order to check if this is a suitable algorithm for large infrastructures. The results show that our algorithm requires approximately 1 s to cross a 10 Km section, and that by using iACKs we can reduce the time by a 9% compared to using eACKs. Furthermore, the use of iACKs also decreases the energy consumption.
Finally, we have implemented our algorithm using Atmel RCB256RFR2 nodes to test its operation in a real scenario. We have completed different tests that included noisy links and failing nodes. We could check how our proposal provides reliable transmission and low latency for linear sensor networks, supporting failing nodes or noisy links, while simplifying the network layer. Thus, this algorithm is especially interesting for implementing pipeline monitoring applications over a 802.15.4 physical layer.  Data Availability Statement: The source code used for the practical validation of the proposed architecture is available at https://github.com/cegas/routinglinklevel.