Next Article in Journal
Laser-Based People Detection and Obstacle Avoidance for a Hospital Transport Robot
Next Article in Special Issue
Intent Detection and Slot Filling with Capsule Net Architectures for a Romanian Home Assistant
Previous Article in Journal
Phase Compensation of the Non-Uniformity of the Liquid Crystal on Silicon Spatial Light Modulator at Pixel Level
Previous Article in Special Issue
Blockchain and Demand Response: Zero-Knowledge Proofs for Energy Transactions Privacy
Order Article Reprints
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:

Reliable Link Level Routing Algorithm in Pipeline Monitoring Using Implicit Acknowledgements

GI-IoE Internet of Every Things Research Group, Escuela Politécnica Nacional, Quito E11-253, Ecuador
atlanTTic Research Center for Telecommunication Technologies, Universidade de Vigo, Information Technologies Group, 36310 Vigo, Spain
Department of Electrical and Computer Engineering, INESC Coimbra, University of Coimbra, P-3030 Coimbra, Portugal
Author to whom correspondence should be addressed.
Sensors 2021, 21(3), 968;
Received: 31 December 2020 / Revised: 28 January 2021 / Accepted: 28 January 2021 / Published: 1 February 2021


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.

1. 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.

2. 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-to-end delay, reliability, or deployment requirements. Therefore, we can conclude that LWSNs require specifically designed communication stacks. In this sense, there are different proposals for new MAC layer protocols for LWSN. LC-MAC [13] is a long-chain MAC protocol where the forwarding nodes schedule the transmission of packets to reduce the delay of an end-to-end extended sensor network without sacrificing energy efficiency. CH-MAC, a delay-aware MAC protocol with implicit control frame Request to Send (RTS) employed in the medium access control, is proposed and compared with eACK in [14]. The authors conclude that it prevents the “avalanche” effect, and the use of iACK optimizes the use of energy. In [15] a token-based MAC protocol for linear sensor networks has been proposed to manage the access to the medium and improve the network performance. Also, many protocols have been presented to optimize the energy consumption of large WSNs. For example, in [16] MI-MAC, a new link level protocol, is proposed. Finally, reference [17] includes an analysis and comparison of different MAC protocols for linear LWSN such as Dual mode MAC, Disc-MAC, LC-MAC, MFT_MAC, CMAC-T, AC_MAC/DPM, and WiWi protocols.
Different routing protocols have also been suggested to meet the specific LWSN needs. In [10] a robust discovery, addressing and routing protocol for dynamic LWSN is proposed. The application of LWSN to rail transport is considered in [18], and energy efficient routing protocols for linear wireless sensor networks are also studied. The authors recommend two energy efficient routing protocols, Minimum Energy Relay Routing (MERR) and Adaptive MERR (AMERR). A Chain-based Anonymous Routing (CAR) unicast-based broadcast to send data is studied in [19]. In this proposal, each node can only sense the adjacent nodes on the same chain, and the traceability of the system has been enhanced; thereby increasing network security. In [20] a new routing algorithm is proposed for wireless sensor networks for post-disaster road monitoring. For this approach, the nodes are arranged in a linear topology. It includes route establishment, packet forwarding, and route maintenance. This proposal assumes that the nodes are previously identified in sequence. Finally, the AODV Routing Algorithm in Linear Topological Wireless Sensor is studied in [21].
Transport and application protocols have been also developed for WSNs to guarantee reliability, flow control, and congestion control. However, large-scale networks require a complex implementation complicated by the limited processing and power resources of the nodes. For pipeline monitoring the main issue is reliability, since controlling the monitoring period helps to minimize other problems such as congestion or flow control. For example, a comparative analysis of the transport and application protocols CODA, ESTR, RMST, PSFQ, GARUDA, and ATP, proposed for large-scale WSN networks, is presented in [22]. The comparison includes the use of end-to-end ACK and NACK, but the studied protocols do not use eACK or iACK at the link level. The Rate-Controlled Reliable Transport (RCRT) protocol is presented in [23]. It uses a base station or receiver to discover missing packets and explicitly requests the packets from the sensor nodes for end-to-end recovery. The Stream Control Transmission Protocol-WAN (SCTP-WSN) [24] adopts the concept of Multihoming and adopts the SCTP transport protocol combined with the AODV routing protocol to provide network reliability with eACK. GARUDA [25] studies the reliability of the delivery of point-to-multipoint data in the downstream direction, from a sink to the sensor nodes using NACK. The Aggregation and Transmission Protocol (ATP) transport protocol [26] includes an end-to-end feedback control algorithm assisted by the receiving node and the network to counteract packet loss, using selective ACK.
Nevertheless, using end-to-end mechanisms for reliability has also drawbacks, such as a higher delay because of the end-to end retransmissions. In [27], the authors study the advantage of using hop-to-hop, instead of end-to-end acknowledgment, and in [28,29] the authors study the advantage of using iACK, instead of eACK in wireless sensor networks. Based on these conclusions, our proposal decreases the energy consumption and minimizes the delays using iACK for the communication. It provides the same reliability, end-to-end connectivity, and scalability as previous proposals that implement high level routing protocols and eACK mechanisms.
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.

3. 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.

3.1. 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 |ji| ≤ 2.
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.
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.

3.2. 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 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 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 vi1 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 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.

3.3. 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.

3.4. 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
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:
14                case id_s == i+2 and id_d == broadcast:
15                if FailN == F then it has received an iACK, stores frame bufferok and transmits the following frame else
16                          case ChangeF == F, set ChangeF = T, transmit broadcast frame:
17                          case ChangeF == T, discard the frame:
18                end if
19          end if
20    else
21          case node INTN: retransmit unicast frame to i+1:
22          case node TXN:
23                if retransmission > Maxwait. then
24                       transmit unicast frame to node i-1 and set FailN = T
25                else retransmit frame broadcast
26                end if
27    end if
Figure 10, Figure 11 and Figure 12 also show the state diagram for nodes TXN, RXN, and INTN.

4. Energy and Transmission Time Analysis

4.1. 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.
  • If the transmitted data collides at the receiver, the macAckWait duration (an IEEE 802.15.4 attribute dependent on constants and attributes of the physical layer, which defines the maximum number of symbols to wait for an ACK frame) for the transmitting node is the sum of the turnaround time of 12 Ts and the ACK duration of 22 Ts, a total of 34 Ts considering Ts = 16 μs and 1 symbol is 4 bits.
  • A CCA is successful when no transmission is detected from any node, at the time of initiation of its CCA. In the IEEE 802.15.4 standard, the channel state is averaged over 8 Ts.

4.2. 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 vi and the arrival at the vi+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):
d e ( x ) = T B O + T C C A + T f r a ( x ) + T T A + T A C K + T I F S + τ
d e ( x ) = T f r a ( x ) + T I F S + T T A + T B O + T C C A + τ
where x represents the number of bytes that have been received from the upper layer, TBO is the back off period, T C C A means Clear Channel Assessment time, T f r a ( x ) is Transmission time for a payload of x byte, T T A is Turnaround time from TX to RX, T A C K is Transmission time for an ACK, T I F S (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, 2BE − 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, 23 − 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:
T f r a ( x ) = 8   ( L p h y   + L M A C H D R   L a d d r e s s     + x + L M A C F T R ) /   R d a t a
where L p h y   is the Length of the PHY and synchronization header in bytes (6 bytes), LMACHDR is Length of the MAC header in bytes (3 bytes), L a d d r e s s     is the length of the MAC address info field, L M A C F T R is the length of the MAC footer in bytes (2 bytes), and R d a t a is the raw data rate (250 kbps).
The transmission time for an acknowledgment can be formulated as:
T A C K = ( L p h y + L M A C H D R + L M A C F T R ) /   R d a t a
So, in summary, the delay can be expressed as:
d e ( x ) = a ( x ) + b
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.
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 T w e A C K time that the TXN node must wait to retransmit a frame when it does not receive an eACK.
T w e A C K = 54   T S
when iACK is used, the time that the TXN node must wait to start the retransmission process of the frame, T w i A c k , is equal to the time it takes for the RXN node to finish retransmitting the entire frame plus the T B O and T C C A times. This is because the TXN node must receive the frame retransmitted by the RXN node to validate the successful transmission.
T w i A c k =   T B O + T C C A +   T f r a m e
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 Pl and Pr flows):
d e l ( x ) = ( i )   d e ( x )
d e r ( x ) = ( n i )   d e ( x )
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 Pl or Pr 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%.

4.3. 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.
A E eACK = P r T ACK
The percentage of additional energy consumed by the RXN node, AERXN, using eACK to receive the frame, transmit the ACK and be ready to retransmit the frame, can be calculated as, (Equation (11)):
A E R X N = P t T ACK   P r T f r a + P t T ACK + P i ( T T A + T B O + T C C A )
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)):
E e A C K = P t T f r a ( x ) + P r T ACK + P i ( T I F S + T T A + T B O + T C C A )
E iACK = P t T f r a ( x ) + P i ( T T A + T B O + T C C A )
The percentage of additional energy consumed by the TXN node, A E T X N , using eACK to send the next frame, can be calculated as Equation (14):
A E T X N = P r T A C K + P i ( ( T w a i t e T w a i t )   + 2 T T A + T B O + T C C A ) P t T f r a + P r T A C K + P i ( T w a i t e   + 4 T T A + T B O 0 + T B O 1 + 2 T C C A
The percentage of additional energy consumed by the TXN node, A E T X N f using eACK to retransmit the frame that did not reach the RXN node, can be calculated as Equation (15):
A E T X N f = P i ( T w a i t e T w a i t )   P t T f r a m e + P i ( T w a i t e   + 2 T T A + T B O 0 + T C C A )
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.
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.

5. 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.
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 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 that nodes v3 and v4 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. Table 6 and Table 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.

6. 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.

Author Contributions

Conceptualization, C.E.A.; Formal analysis, C.E.A.; Funding acquisition, F.G.-C.; Investigation, C.E.A., F.G.-C. and E.C.-M.; Methodology, F.G.-C., E.C.-M. and J.S.S.; Software, C.E.A.; Supervision, F.G.-C. and E.C.-M.; Validation, F.G.-C., E.C.-M. and J.S.S.; Writing—original draft, C.E.A., F.G.-C. and E.C.-M.; Writing—review & editing, C.E.A., F.G.-C., E.C.-M. and J.S.S. All authors have read and agreed to the published version of the manuscript.


This research was partially funded by Xunta de Galicia (GRC2018/053) and Escuela Politécnica Nacional (PIS-17-03).

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

The source code used for the practical validation of the proposed architecture is available at

Conflicts of Interest

The authors declare no conflict of interest.


  1. Kocakulak, M.; Butun, I. An Overview of Wireless Sensor Networks towards Internet of Things. In Proceedings of the IEEE 7th Annual Computing and Communication Workshop and Conference, Las Vegas, NV, USA, 9–11 January 2017. [Google Scholar] [CrossRef]
  2. Varshney, S.; Kumar, C.; Swaroop, A. Leach Based Hierarchical Routing Protocol for Monitoring of Over-ground Pipelines Using Linear Wireless Sensor Networks. Procedia Comput. Sci. 2018, 125, 208–214. [Google Scholar] [CrossRef]
  3. Zhang, M.; Wang, N.; Chen, L. Sensing Technologies and Automation for Precision Agriculture. In Women in Precision Agriculture. Women in Engineering and Science; Khemais, T.H., Ed.; Springer Nature Switzerland AG: Cham, Switzerland, 2021; pp. 34–54. [Google Scholar] [CrossRef]
  4. Singh, P.K.; Paprzycki, M. Introduction on Wireless Sensor Networks Issues and Challenges in Current Era. In Handbook of Wireless Sensor Networks: Issues and Challenges in Current Scenario’s. Advances in Intelligent Systems and Computing; Singh, P., Bhargava, B., Paprzycki, M., Kaushal, N., Hong, W.C., Eds.; Springer: Cham, Switzerland, 2020; Volume 1132. [Google Scholar] [CrossRef]
  5. Joshi, H.; Ravindra, E. MAC Protocols for Application-Specific Wireless Sensor Networks: A Study. Int. J. Res. Eng. Sci. Manag. 2018, 1, 2581–5782. [Google Scholar]
  6. Jawhar, I.; Mohamed, N.; Shuaib, K.; Kesserwan, N. An Efficient Framework and Networking Protocol for Linear Wireless Sensor Networks. Ad Hoc Sens. Wirel. Netw. 2009, 7, 3–21. [Google Scholar]
  7. Raja, M.K.; Chen, X.; Lei, Y.D.; Bin, Z.; Yeung, B.C.; Yuan, X. A 18 mW Tx, 22 mW Rx Transceiver for 2.45 GHz IEEE 802.15.4 WPAN in 0.18 μm CMOS. In Proceedings of the 2010 IEEE Asian Solid-State Circuits Conference, Beijing, China, 8–10 November 2010. [Google Scholar] [CrossRef]
  8. Farhad, A.; Zia, Y.; Hussain, F.B. Survey of Dynamic Super-Frame Adjustment Schemes in Beacon-Enabled IEEE 802.15.4 Networks: An Application’s Perspective. Wirel. Pers. Commun. 2016, 91, 119–135. [Google Scholar] [CrossRef]
  9. Jawhar, I.; Mohamed, N.; Agrawal, D.P. Linear wireless sensor networks: Classification and applications. J. Netw. Comput. Appl. 2011, 34, 1671–1682. [Google Scholar] [CrossRef]
  10. Sarr, M.D.; Delobel, F.; Misson, M.; Niang, I. Robust Discovery, Addressing and Routing Protocol for Dynamic Linear Networks. In Proceedings of the International Symposium on Wireless Communication Systems, Bologna, Italy, 28–31 August 2017. [Google Scholar] [CrossRef][Green Version]
  11. Varshney, S.; Kumar, C.; Swaroop, A. Linear Sensor Networks: Applications, Issues and Major Research Trends. In Proceedings of the International Conference on Computing, Communication and Automation, Greater Noida, India, 5–6 May 2015. [Google Scholar] [CrossRef]
  12. Varshney, V.; Rajput, P.K.; Singh, A.; Varshney, G. Routing Techniques Used for Monitoring the Linear Structures Using Linear Wireless Sensor Networks: An Overview. In Proceedings of the International Conference on Computing, Communication, and Intelligent Systems, Greater Noida, India, 18–19 October 2019. [Google Scholar] [CrossRef]
  13. Fang, C.; Liu, H.; Qian, L. LC-MAC: An Efficient MAC Protocol for the Long-Chain Wireless Sensor Networks. In Proceedings of the 3rd International Conference on Communications and Mobile Computing, CMC, Qingdao, China, 18–20 April 2011. [Google Scholar] [CrossRef]
  14. Li, Z.; Chen, Q.; Zhu, G.; Choi, Y. A Delay-Aware MAC Protocol with Implicit RTS. In Proceedings of the 2014 International Conference on Information and Communication Technology Convergence (ICTC), Busan, Korea, 22–24 October 2014; pp. 541–544. [Google Scholar]
  15. Ndoye, E.H.; Jacquet, C.; Misson, M.; Niang, I. Using a Token Approach for the MAC Layer of Linear Sensor Networks: Impact of the Node Position on the Packet Delivery. In Proceedings of the 2014 IFIP Wireless Days (WD), Rio de Janeiro, Brazil, 12–14 November 2014. [Google Scholar] [CrossRef]
  16. Wang, J.; Ren, X.; Chen, F.J.; Chen, Y.; Xu, G. On MAC optimization for large-scale wireless sensor network. Wirel. Netw. 2016, 22, 1877–1889. [Google Scholar] [CrossRef]
  17. Sokullu, R.; Demir, E. A comparative study of MAC protocols for linear WSNs. Procedia Comput. Sci. 2015, 52, 492–499. [Google Scholar] [CrossRef][Green Version]
  18. Vuletic, P. Application of WSN in Railway Intelligent Transportation System (RITS). In Proceedings of the 2015 23rd Telecommunications Forum, Belgrade, Serbia, 24–25 November 2015. [Google Scholar] [CrossRef]
  19. Shokri, R.; Yazdani, N.; Yazdani, N.; Khonsari, A. Chain-Based Anonymous Routing for Wireless Ad Hoc Networks. In Proceedings of the Consumer Communications and Networking Conference, Las Vegas, NV, USA, 11–13 January 2007; pp. 297–302. [Google Scholar]
  20. Sun, Z.Z.X.; He, J.; Chen, Y.; Ma, S. A New Routing Algorithm for Linear Wireless Sensor Networks. In Proceedings of the 6th International Conference on Pervasive Computing and Applications, Oulu, Finland, 11–13 May 2011; pp. 497–501. [Google Scholar]
  21. Chen, X.; Xu, L.; Xu, M.; Wang, L. Research on the AODV routing algorithm in linear topological wireless sensor networks. Int. J. Simul. Syst. Sci. Technol. 2016, 17, 29.1–29.5. [Google Scholar] [CrossRef]
  22. Malarselvi, G.; Sivajayaprakash, A. A Comprehensive Survey on Applications and Transport Layer Protocols in Wireless Sensor Networks. Int. J. Eng. Technol. 2018, 5, 146–150. [Google Scholar]
  23. Paek, J.; Govindan, R. RCRT: Rate-Controlled Reliable Transport for Wireless Sensor Networks. In Proceedings of the 5th International Conference on Embedded Networked Sensor Systems, Sydney, NSW, Australia, 6–9 November 2007; pp. 305–319. [Google Scholar] [CrossRef]
  24. Sadouni, S.; Benslama, M.; Mebarki, A.; Beylot, A. SCTP-WSN New Extension for More Reliable Sparse Wireless Sensor Networks. In Proceedings of the 13th International Wireless Communications and Mobile Computing Conference (IWCMC), Valencia, Spain, 26–30 June 2017; pp. 2109–2114. [Google Scholar] [CrossRef]
  25. Park, S.; Vedantham, R.; Sivakumar, R.; Akyildiz, I. GARUDA: Achieving Effective Reliability for Downstream Communication in Wireless Sensor Networks. IEEE Trans. Mob. Comput. 2008, 7, 214–230. [Google Scholar] [CrossRef]
  26. Sohraby, K.; Minoli, D.; Znati, T. Wireless Sensor Networks: Technology, Protocols, and Applications; Wiley-Interscience: Hoboken, NJ, USA, 2007; pp. 229–244. [Google Scholar]
  27. Gitman, I. Comparison of Hop-By-Hop and End-To-End Acknowledgment Schemes in Computer Communication Networks. IEEE Trans. Commun. 1976, 24, 1258–1262. [Google Scholar] [CrossRef]
  28. Rosberg, Z.; Liu, R.P.; Dong, Y.A.; Tuan, L.D.; Jha, S. ARQ with Implicit and Explicit ACKs in Wireless Sensor Networks. In Proceedings of the GLOBECOM—IEEE Global Telecommunications Conference, Taipei, Taiwan, 7–11 December 2008. [Google Scholar] [CrossRef]
  29. Rusli, M.E.; Harris, R.; Punchihewa, A. Performance Analysis of Implicit Acknowledgement Coordination Scheme for Opportunistic Routing in Wireless Sensor Networks. In Proceedings of the 2012 International Symposium on Telecommunication Technologies, Kuala Lumpur, Malaysia, 26–28 November 2012. [Google Scholar] [CrossRef]
  30. Ruiz, M.T.; Lytras, M.D.; Mathkour, H. Innovative services and applications of wireless sensor networks: Research challenges and opportunities. Int. J. Distrib. Sens. Netw. 2018, 14, 5. [Google Scholar] [CrossRef][Green Version]
  31. Rahbari, D.; Nickray, M. Low-latency and energy-efficient scheduling in fog-based IoT applications. Turk. J. Electr. Eng. Comput. Sci. 2019, 27, 1406–1427. [Google Scholar] [CrossRef][Green Version]
  32. Dwivedi, R.K.; Kumar, R. Sensor Cloud: Integrating Wireless Sensor Networks with Cloud Computing. In Proceedings of the 5th IEEE Uttar Pradesh Section International Conference on Electrical, Electronics and Computer Engineering, Gorakhpur, India, 2–4 November 2018. [Google Scholar] [CrossRef]
  33. Kim, B.S.; Il Kim, K.; Shah, B.; Chow, F.; Kim, K.H. Wireless sensor networks for big data systems. Sensors 2019, 19, 1565. [Google Scholar] [CrossRef] [PubMed][Green Version]
  34. Ali, S. SimpliMote: A Wireless Sensor Network Monitoring Platform for Oil and Gas Pipelines. IEEE Syst. J. 2018, 12, 778–789. [Google Scholar] [CrossRef]
  35. Zimmerling, M.; Dargie, W.; Reason, J.M. Energy-Efficient Routing in Linear Wireless Sensor Networks. In Proceedings of the IEEE International Conference on Mobile Adhoc and Sensor Systems, Washington, DC, USA, 7 November 2007. [Google Scholar] [CrossRef]
  36. Hammoudeh, M. A wireless sensor network border monitoring system: Deployment issues and routing protocols. IEEE Sens. J. 2017, 17, 2572–2582. [Google Scholar] [CrossRef][Green Version]
  37. Elnaggar, O.E.; Ramadan, R.A.; Fayek, M.B. WSN in monitoring oil pipelines using ACO and GA. Procedia Comput. Sci. 2015, 52, 1198–1205. [Google Scholar] [CrossRef][Green Version]
  38. Tong, F.; Ni, M.; Shu, L.; Pan, J. A Pipelined-Forwarding, Routing Integrated and Effectively-Identifying MAC for Large-Scale WSN. In Proceedings of the GLOBCOM, Atlanta, GA, USA, 9–13 November 2013; pp. 225–230. [Google Scholar] [CrossRef]
  39. Villordo, I.; Torres, N.; Carvalho, M.; Menchaca, R.; Rivero, M.; Menchaca, R. A Selective-Awakening MAC Protocol for Energy-Efficient Data Forwarding in Linear Sensor Networks. Wirel. Commun. Mob. Comput. 2018, 2018, 6351623. [Google Scholar] [CrossRef][Green Version]
  40. Khanh, H.; Ock, C.; Kim, M. RP-MAC A Cross-Layer Duty Cycle MAC Protocol with a Reduced Pipelined-Forwarding Feature for Wireless Sensor Networks. In Proceedings of the 11th International Wireless Communications and Mobile Computing Conference, IWCMC 2015, Dubrovnik, Croatia, 24–28 August 2015; pp. 1469–1474. [Google Scholar] [CrossRef]
  41. Khaliq, S.; Henna, S. HE-PRMAC Hop Extended Pipelined Routing Enhanced MAC Protocol for Wireless Sensor Networks. In Proceedings of the Sixth International Conference on Innovative Computing Technology (INTECH), Dublin, Ireland, 24–26 August 2016; pp. 392–397. [Google Scholar] [CrossRef]
  42. Malick, E.; Diallo, O.; Hakem, N.; Jacquet, F.; Misson, M. Interference-Aware clustering approach improving QoS for linear WSNs using token based MAC protocol. Int. J. Commun. Syst. 2020, 33, 2581–5782. [Google Scholar] [CrossRef]
  43. Lee, S.; Su, Y.W.; Shen, C.C. A Comparative Study of Wireless Protocols: Bluetooth, UWB, ZigBee, and Wi-Fi. In Proceedings of the Industrial Electronics Conference, Vigo, Spain, 4–7 June 2007. [Google Scholar] [CrossRef][Green Version]
  44. Egas Acosta, C.; Gil-Castiñeira, F.; Costa-Montenegro, E.; Silva, J.S. Automatic Allocation of Identifiers in Linear Wireless Sensor Networks Using Link-Level Processes. In Proceedings of the 2016 8th IEEE Latin-American Conference on Communications, Medellin, Columbia, 15–17 November 2016. [Google Scholar] [CrossRef]
  45. Wijetunge, S. Performance Analysis of IEEE 802.15.4 Based Wireless Sensor Networks. Ph.D. Thesis, University of Western Sydney, Sydney, Australia, 2013. [Google Scholar]
  46. Zhu, J.; Tao, Z.; Lv, C. Performance improvement for IEEE 802.15.4 CSMA/CA scheme in large-scale wireless multi-hop sensor networks. IET Wirel. Sens. Syst. 2013, 3, 93–103. [Google Scholar] [CrossRef]
  47. Zhou, H.-Y.; Luo, D.-Y.; Gao, Y.; Zuo, D.C. Modeling of Node Energy Consumption for Wireless Sensor Networks. Wirel. Sens. Netw. 2011, 3, 18–23. [Google Scholar] [CrossRef][Green Version]
  48. Rasheed, M.B.; Javaid, N.; Imran, M.; Khan, Z.A.; Qasim, U.; Vasilakos, A. Delay and energy consumption analysis of priority guaranteed MAC protocol for wireless body area networks. Wirel. Netw. 2017, 23, 1249–1266. [Google Scholar] [CrossRef]
  49. Bougard, B.; Catthoor, F.; Daly, D.C.; Chandrakasan, A.; Dehaene, W. Energy Efficiency of the IEEE 802.15.4 Standard in Dense Wireless Microsensor Networks: Modeling and Improvement Perspectives. In Design, Automation, and Test in Europe: The Most Influential Papers of 10 Years Date; Lauwereins, R., Madsen, J., Eds.; Springer Science Business Media B.V.: Dordrecht, The Netherlands, 2008; pp. 221–234. ISBN 978-1-4020-6487-6. [Google Scholar] [CrossRef]
  50. Yan, J.; Zhou, M.; Ding, Z. Recent Advances in Energy-Efficient Routing Protocols for Wireless Sensor Networks: A Review. IEEE Access 2016, 4, 5673–5686. [Google Scholar] [CrossRef]
  51. Fitriawan, H.; Susanto, M.; Arifin, A.S.; Mausa, D.; Trisanto, A. ZigBee Based Wireless Sensor Networks and Performance Analysis in Various Environments. In Proceedings of the 15th International Conference on Quality in Research (QiR): International Symposium on Electrical and Computer Engineering, Bali, Indonesia, 24–27 July 2017. [Google Scholar] [CrossRef]
  52. Atmel Corporation. 8-Bit AVR Microcontroller with Low Power 2.4GHz Transceiver for ZigBee and IEEE 802.15.4. 2014. Available online: (accessed on 30 January 2021).
  53. Atmel Corporation. Atmel AVR10004: RCB256RFR2—Hardware User ManuaL. 2013. Available online: (accessed on 30 January 2021).
  54. Atmel Corporation. Atmel AVR4029: Atmel Software Framework User Guide. 2013. Available online: (accessed on 30 January 2021).
  55. Hao, C. End-to-End Delay Analysis and Measurements in Wireless Sensor Networks; Mid Sweden University: Sundsvall, Sweden, 2012. [Google Scholar]
  56. Nefzi, B.; Song, Y.Q. Performance analysis and improvement of ZigBee routing protocol. IFAC Proc. Vol. 2007, 40, 199–206. [Google Scholar] [CrossRef][Green Version]
  57. Tall, H.; Chalhoub, G. ABORt: Acknowledgement-based opportunistic routing protocol for high data rate multichannel WSNs. J. Sens. Actuator Netw. 2017, 6, 23. [Google Scholar] [CrossRef][Green Version]
  58. Calveras, A.; Ludovici, A. Implementation and Evaluation of Multi-Hop Routing in 6LoWPAN. In Proceedings of the IX Jornadas de Ingeniería Telemática (JITEL 2010), Valladolid, Spain, 29 September–1 October 2010. [Google Scholar]
Figure 1. Linear Wireless Sensor Networks.
Figure 1. Linear Wireless Sensor Networks.
Sensors 21 00968 g001
Figure 2. Node identification.
Figure 2. Node identification.
Sensors 21 00968 g002
Figure 3. eACK.
Figure 3. eACK.
Sensors 21 00968 g003
Figure 4. iACK.
Figure 4. iACK.
Sensors 21 00968 g004
Figure 5. Node vi transmits to node vi+2.
Figure 5. Node vi transmits to node vi+2.
Sensors 21 00968 g005
Figure 6. Node vi+1 retransmits to node vi+2.
Figure 6. Node vi+1 retransmits to node vi+2.
Sensors 21 00968 g006
Figure 7. Frame does not reach node vi+2.
Figure 7. Frame does not reach node vi+2.
Sensors 21 00968 g007
Figure 8. Flow Pr interrupted.
Figure 8. Flow Pr interrupted.
Sensors 21 00968 g008
Figure 9. Pr and Pl flows are interrupted.
Figure 9. Pr and Pl flows are interrupted.
Sensors 21 00968 g009
Figure 10. INTN node state diagram.
Figure 10. INTN node state diagram.
Sensors 21 00968 g010
Figure 11. TXN node state diagram.
Figure 11. TXN node state diagram.
Sensors 21 00968 g011
Figure 12. RXN node state diagram.
Figure 12. RXN node state diagram.
Sensors 21 00968 g012
Figure 13. Delay according to the payload size.
Figure 13. Delay according to the payload size.
Sensors 21 00968 g013
Figure 14. Delay reduction when using iACK compared to eACK.
Figure 14. Delay reduction when using iACK compared to eACK.
Sensors 21 00968 g014
Figure 15. Reduction in energy consumption.
Figure 15. Reduction in energy consumption.
Sensors 21 00968 g015
Figure 16. Atmel RCB256RFR2 node.
Figure 16. Atmel RCB256RFR2 node.
Sensors 21 00968 g016
Figure 17. Tested network.
Figure 17. Tested network.
Sensors 21 00968 g017
Figure 18. (a) Used hardware. (b) Scenario for the tests. (c) Typical pipeline implementation.
Figure 18. (a) Used hardware. (b) Scenario for the tests. (c) Typical pipeline implementation.
Sensors 21 00968 g018
Figure 19. Test with a failing node.
Figure 19. Test with a failing node.
Sensors 21 00968 g019
Table 1. Comparison of LPWAN protocols.
Table 1. Comparison of LPWAN protocols.
Address Autoconfig.Same Net. and Link Addr.eACKiACKLinear Topology ClusteringEnd-to-End ReliabilityTopology DiscoveryEnergy EfficientConsiders End-to-End DelayLarge ScaleAccess ChannelProtection against Link and Node Failure
This proposalyesyesnoyesyesnoyesyesYesyesyesCSMA/CAyes
Application and transport level
RCRT [23]nonoyesnonoNoyesnoNoyesnon.ayes
GARUDA [25]nonoyes nonoYesyesnon.a.noyesn.ayes
ATP [26]nonoyesnonoNoyesnoNoyesyesn.ano
SCTPWSN [24]nonoyesnonoNoyesyesn.a.noyesn.a.yes
Network level
SimpliMote [34]noyesnonoyesNonoyesyesnoyesn.a.yes
MERR [35]
LDG [36]nonono nonoYesnoyesyesyesyesn.ano
DiscoProto [10]yesyesnononoYesnoyesnoyesyesTMACyes
ACO&GA [37]
LBHRP [2]nononononoYesnoyesnonoyesTDMAyes
ROLS [6]yesnonoyesyesYesnonononoyesn.a.yes
WTDP [29]yesnonononoNonoyesnononoalohano
Link level
PRIMAC [38]nonoyesnoyesNonoyesnonoyesn.ano
SA-MAC [39]nonoyesnoyesYesyesyesnoyesnoTDMAno
RP MAC [40]
HEPRMAC [41]nononononoNononoyesyesnoTDMAno
Token [42]nonoyesnoyesYesnonon.a.yesnoTokenno
LCMAC [13]nonoyesno
MIMAC [16]nonoyesnoyesNononoyesyesyesCSMA/CAno
Table 2. Number of hops required to balance out a retransmission with iACK compared to eACK according to the payload size.
Table 2. Number of hops required to balance out a retransmission with iACK compared to eACK according to the payload size.
PayloadRequired Hops
Table 3. Time for end-to-end transmission with 16 bits ID.
Table 3. Time for end-to-end transmission with 16 bits ID.
Intermediate NodesLWSN Length (Km)eACK Delay (s)iACK Delay (s)
Table 4. Variation of energy consumption in the node with ID = 16 bits
Table 4. Variation of energy consumption in the node with ID = 16 bits
Payload A E R X N A E T X N A E T X N f
Table 5. Design parameters.
Table 5. Design parameters.
Transmission power0.5 dBm
Distance between nodes25 m
802.15.4 broadcast frame TXN0.384 ms, 12 bytes
Table 6. Frame processing time (RXN node).
Table 6. Frame processing time (RXN node).
Processing Time at Node RXN
Measured [ms]Calculated
% error
Table 7. Frame processing time (TXN node).
Table 7. Frame processing time (TXN node).
Processing Time at Node TXN
Measured [ms]Calculated
% error
Table 8. Comparison of the end-to-end delay between 6LowPAN and our proposal.
Table 8. Comparison of the end-to-end delay between 6LowPAN and our proposal.
End to End Delay
HopOur proposal6LowPANLWSN length
13.43 ms13.88 ms50 m
1034.3 ms138.8 ms275 m
100343 ms1.38 s2.525 km
10003.43 s13.88 s25 km
28009.06 s38.86 s70 km
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Share and Cite

MDPI and ACS Style

Acosta., C.E.; Gil-Castiñeira, F.; Costa-Montenegro, E.; Silva, J.S. Reliable Link Level Routing Algorithm in Pipeline Monitoring Using Implicit Acknowledgements. Sensors 2021, 21, 968.

AMA Style

Acosta. CE, Gil-Castiñeira F, Costa-Montenegro E, Silva JS. Reliable Link Level Routing Algorithm in Pipeline Monitoring Using Implicit Acknowledgements. Sensors. 2021; 21(3):968.

Chicago/Turabian Style

Acosta., Carlos Egas, Felipe Gil-Castiñeira, Enrique Costa-Montenegro, and Jorge Sá Silva. 2021. "Reliable Link Level Routing Algorithm in Pipeline Monitoring Using Implicit Acknowledgements" Sensors 21, no. 3: 968.

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop