Delay-efficient MAC protocol with traffic differentiation and run-time parameter adaptation for energy-constrained wireless sensor networks

Abstract

This paper presents an asynchronous cascading wake-up MAC protocol for heterogeneous traffic gathering in low-power wireless sensor networks. It jointly considers energy/delay optimization and switches between two modes, according to the traffic type and delay requirements. The first mode is high duty cycle, where energy is traded-off for a reduced latency in presence of realtime traffic (RT). The second mode is low duty cycle, which is used for non-realtime traffic and gives more priority to energy saving. The proposed protocol, DuoMAC, has many features. First, it quietly adjusts the wake-up of a node according to (1) its parent’s wake-up time and, (2) its estimated load. Second, it incorporates a service differentiation through an improved contention window adaptation to meet delay requirements. A comprehensive analysis is provided in the paper to investigate the effectiveness of the proposed protocol in comparison with some state-of-the-art energy-delay efficient duty-cycled MAC protocols, namely DMAC, LL-MAC, and Diff-MAC. The network lifetime and the maximum end-to-end packet latency are adequately modeled, and numerically analyzed. The results show that LL-MAC has the best performance in terms of energy saving, while DuoMAC outperforms all the protocols in terms of delay reduction. To balance the delay/energy objectives, a runtime parameter adaptation mechanism has been integrated to DuoMAC. The mechanism relies on a constrained optimization problem with energy minimization in the objective function, constrained by the delay required for RT. The proposed protocol has been implemented on real motes using MicaZ and TinyOS. Experimental results show that the protocol clearly outperforms LL-MAC in terms of latency reduction, and more importantly, that the runtime parameter adaptation provides additional reduction of the latency while further decreasing the energy cost.

1 Introduction

1.1 Problem statement and contribution

Nowadays wireless sensor networks (WSN) applications, ranging from health-care, to industrial monitoring, transportation, and automation [15], are complex and have several requirements. In addition to the energy constraint that was almost the only metric for consideration in earlier applications, new constraints appear with emerging monitoring system applications, such as latency, security, and reliability. Given that the MAC layer manages the medium access and controls the radio interface, it plays a key role in determining the system performance in terms of e2e packet latency, and power-consumption (network lifetime). Energy saving is achieved at the MAC layer by duty-cycling the radio and switching between active/sleep modes. That is, repeatedly switching the radio off/on. In active mode, a node can receive and transmit packets, while in the sleep mode, it completely turns off its radio to save energy. Hence, a node needs to be aware of its neighbors’ wake-up time to tune its transmission accordingly. This has a direct impact on the forwarding delay, also known as sleep delay, which is the delay spent at every hop by the transmitter waiting for the receiver to wake up.

The forwarding delay problem is targeted herein, where a novel dual-mode asynchronous cascading wake-up scheduled MAC protocol, called DuoMAC, is presented. In absence of realtime (RT) traffic, DuoMAC runs in a low duty-cycling (LDC) mode and behaves as an energy-efficient MAC following an EEF (Energy Efficiency First) strategy. However, when an RT event is detected, a node enters in a high duty-cycling (HDC) mode and behaves as a delay-efficient MAC to forward RT traffic following a delay efficiency first (DEF) strategy. In addition to operating in two modes, DuoMAC precipitates packet forwarding by adopting a dynamic cascading of active periods and adjusting the wake-up time of a node according to, (1) its parent’s wake-up time and, (2) its estimated load. To meet the dynamic traffic requirements of each class of traffic, DuoMAC processes every packet according to its degree of importance. This is achieved by applying an effective service differentiation based on a hybrid prioritization scheme, where the contention window size is adapted by implementing an effective link quality estimator. The proposed solution also integrates a runtime parameter adaptation mechanism and formulates a convex optimization problem with energy consumption as the objective function constrained by the delay required for realtime traffic.

1.2 Illustrative system scenario

For illustration and without loss of generality, a typical scenario of an urban traffic monitoring system is depicted in Fig. 1. The proposed protocol can be used in any monitoring system with a joint time/energy constrained application, where sensed data must be gathered and forwarded to a central station within a specific time proportional to the application requirements. In the given example, nodes are uniformly distributed to perform real-time monitoring of traffic, measurement of road conditions such as glaze, weather condition, etc., which helps optimizing traffic management and avoiding urban traffic jams. The monitoring system is typically connected to an intelligent traffic system (ITS) that provides collision avoidance services and might display the crash warning messages to the drivers as soon as crash-prone conditions are detected. In this scenario, sensor samples should be communicated to the control center for being analyzed. Some data such as traffic flows must reach the central station within a short delay, no later than a predefined deadline $L_{max}$. This is known as realtime traffic, $RT$, while the traffic that is less delay-prone is named non-realtime traffic, $NRT$. The system should be able to satisfy the delay constraints on $RT$ traffic, while considering minimizing energy consumption, E, subject to achieve maximum network lifetime.

Fig. 1

Wireless sensor network for urban traffic monitoring system with runtime parameters adaptation

In this paper, a comprehensive design approach that embraces the factors mentioned above is presented. DuoMAC protocol is presented along with a comprehensive mathematical analysis that shows the effectiveness of the proposed protocol from the energy-delay perspective in comparison with some state-of-the-art energy-delay efficient duty-cycled MAC protocols: (1) DMAC [20], (2) LL-MAC [34], and (3) Diff-MAC [33]. Further, the proposed protocol has been enhanced with a runtime parameter adaptation based on solving an optimization problem. This allows to dynamically find the optimal MAC tunable parameters to achieve better performance for the concurrent objectives. The proposed protocol enhanced with the runtime parameter adaptation has been implemented in MicaZ sensor motes with TinyOS and evaluated both by simulation, and in a testbed experimentation. The remainder of the paper is organized as follows. Section 2 presents the related work. Section 3 provides a detailed description of DuoMAC. Section 4 presents a mathematical analysis through generalized network and traffic models, and some numerical comparisons. Section 5 illustrates the DuoMAC parameter optimization, while Sect. 6 validates the optimization approach through extensive simulation and experimentations with real sensor motes. Finally, Sect. 7 draws the conclusions.

2 Related work

Existing WSN MAC protocols are basically grouped based on the access management to the shared medium [2, 6, 9, 16, 29], or according to some targeted performance metrics such as energy, delay, and reliability [28]. One possible classification is to split the protocols into three classes contention-based, scheduled, and hybrid, based on the mechanism employed to avoid collision. The authors in [17] propose to categorize MAC protocols based on how nodes are organized to access the shared channel into three classes random-based, slotted-based, and frame-based. Depending on how contention-based MAC protocols schedule the node’s duty-cycle (turning the radio on/off), authors in [10] and [11] have grouped duty-cycled contention-based MAC into two schemes; Synchronous vs. Asynchronous based on how the senders join their intended receivers. Following this principle, synchronous protocols like SMAC [32] specify and coordinate active/ sleep periods by exchanging SYNC packets for synchronization. Many recent protocols are based on SMAC, such as Diff-MAC [33], which integrates traffic differentiation to reduce the delay for realtime traffic. Asynchronous duty-cycling schemes have the advantage over synchronous ones to eliminate the need of clock synchronization. Furthermore, their contention-based feature makes these protocols conceptually distributed and more dynamic compared to scheduled protocols, notably TDMA-based ones. However, the communicating nodes are prone to spend more time waiting for the active period of each other, which inevitably influences the cumulative e2e delay. In [10], different categories of asynchronous protocols like preamble-based protocols (e.g., X-MAC [3] and WiseMAC [12]) and beacon-based protocols (e.g., receiver-initiated protocols such as RI-MAC [27]) have been reported and discussed from the delay-efficiency perspective. The analysis also reveals that collaborative scheduled wake-up protocols, e.g. LL-MAC [34] and DMAC [20], provide better e2e delay reduction among other classes of protocols. The principle is that neighbor nodes collaborate to set their wake-up offset in a cascading way. However, none of these protocols consider traffic load of intermediate nodes when targeting the delay. CyMAC [24] is yet another asynchronous receiver-initiated protocol that targets to reduce the idle-listening of nodes by employing a rendezvous mechanism. Each node learns about the upcoming traffic from its neighbors and schedules the wakeup beacons to the appropriate time. Generally, the delay requirement is expressed in terms of absolute e2e delay in time critical applications [28] and the packet has to arrive as fast as possible and thus is not a question of relative delay, but a question of spend more energy for arriving faster. Furthermore, the delay requirement may not be the same for each kind of traffic which has not been taken into account in most of these protocols.

The most compelling purpose for performance analysis through protocol modeling techniques is the capability to design optimized protocol parameters for a given application. While most of the energy-efficient MAC protocols for WSNs had taken pure experimental approaches, few works have attempted to model and analyze MAC protocols. First, the analytical model of well known preamble-sampling protocols, B-MAC and X-MAC, have been derived by Polastre et al. [25], and Buettner et al. [3], respectively. Langendoen and Meier [18] consider traffic and network models for very low data rate applications, analyzing energy consumption and average latency of well known MAC protocols. Markov models have been developed to evaluate the energy consumption of some MAC protocols, such as SMAC [30], and DMAC [35]. Protocol optimization have been investigated by Ye et al. [31], but this work is limited to optimize parameters for energy minimization in SCP-MAC protocol. Ergen et al. [13] propose a protocol engine that selects the adequate protocol with optimized parameters satisfying the application requirements for a fixed network topology. Those approaches are inefficient; yet their results are used at compile time, ignoring thus the high dynamic change of the network state at runtime.

Lately, numerous efforts to support MAC optimization at run-time have been published. First, Breath, by Park et al. [23], is a randomized protocol for control systems where parameters are controllable by the central coordinator. Meier et al. [21] propose the provision for dynamic calibration of MAC parameters at runtime, taking into account of topology variability. Zimmerling [36] presents an automatic centralized parameter adaptation framework in which MAC protocol parameters are abstracted in a protocol-independent way to meet a given application requirements in term of energy, delay, etc. This abstraction is chosen to match any protocol-dependent parameters. In this paper, a new asynchronous cascading wakeup MAC is proposed, and the modeling methodology given in [18] is extended and applied to the proposed protocol, which permits to set the parameters at runtime in order to improve the performance by considering the heterogeneous traffic support; RT and NRT. The performance is achieved by maximizing the network lifetime while satisfying the application requirement in terms of e2e delay constraints on RT traffic.

3 DuoMAC protocol description

DuoMAC is a contention-based MAC protocol inspired from a control loop system. It adapts its wake-up schedule to the network traffic conditions and switches between two operating modes, (1) a LDC state whose aim is energy-efficiency for non-real-time (NRT) traffic and, (2) a HDC state to accelerate real-time (RT) packet forwarding. To gather the sensed data, the sink node first runs the tree construction. When a node is powered-on, it runs the connection phase and tries to join the network. The node monitors the channel and receives beacons from its neighboring nodes, choosing the parent with minimum hop-count, best link quality, and storing its wake-up scheduling information. Once connected, the node is ready to send and receive beacons and data packets. For simplicity, we assume the use of a routing protocol with an established tree topology rooted at the sink, where the nodes are classified according their distance to the sink in terms of the number of hops. Consequently, the sink is at level $d=0$, nodes at one hop are at level $d=1$, and the furthest nodes are at level $d=D$. The choice of the routing protocol does not impact the MAC protocol performance since nodes at level d assume that they will receive packets from children nodes at level $d+1$, that they will forward packets to parent nodes at level $d-1$, and that there will be background nodes that interfere at level d. In the following, the main features of DuoMAC are discussed.

3.1 LDC and HDC operation modes

Every cycle, $t_m$, contains an active period $T_{active}$, a sleep period, $T_{sleep}$, and $N_{cp}$ channel polling periods of size $T_{cp}$. The later checks for possible incoming RT traffic in the middle of the sleep period. The number of quick channel polling periods must trade-off energy with delay. By default, Fig. 2(a), nodes run in LDC mode, where $T_{recv}$ and $T_{send}$ respectively limit the reception and transmission of NRT data packets.

Fig. 2

a LDC operation mode. b HDC operation mode

A node wakes up exactly at its scheduled time, updated at each cycle, and sends a $B_w$ beacon indicating the beginning of $T_{recv}$ period. The receive period is terminated when a node receives a $B_w$ beacon of its parent. At the end of the $T_{recv}$ period, a node calculates its next wake-up time schedule according to the node’s NRT time traffic, which is then broadcasted in a $B_{nw}$ beacon. After sending this beacon, a node then proceeds to forward its queued packets.

As depicted in Fig. 2(a), the $B_w$ beacon signals a current wake-up time of the transmitting node. The $B_{nw}$ beacon’s role is twofold. First, it indicates the end of the $T_{recv}$ period and the beginning of the $T_{send}$ period. Second, it contains information about the next wake-up time $W_{n_i}(t_m)$, as well as the distance $d_{n_i}$ of a node $n_i$ from the sink. Nodes contend to send NRT packets using CSMA and each transmission includes a data packet and its acknowledgment (ACK).

In order to detect RT traffic, nodes wake up in every $T_{cp}$ period for $T_{on}$ seconds to poll the channel, then return back to sleep if there is no activity. A node can detect a RT event and then trigger its own RT packets, or it can receive RT packets from other nodes during its periodic channel polling. In both cases, a node switches to the HDC mode, Fig. 2(b). To send a RT packet, a node transmits a sequence of RTS strobes of size $T_{rts}$ as a wake-up preamble, containing the identifier of the receiver, to reach its forwarder node. Strobes continue for a period sufficient to make at least one strobe overlap with a receiver wake-up. When this happens, the receiver replies with a CTS packet of size $T_{cts}$ as an acknowledgment, and it keeps the radio on awaiting the transmission of the data packet. The sender transmits the data packet upon receiving the CTS and waits for the ACK from the receiver. Note that $T_{on}$ must be at least equal to the transmission time of RTS, $T_{rts}$, plus the interval time, $T_{cl}$, between two RTS strobes where the sender waits to a CTS. This ensures the wake-up packet to be heard, Fig. 2(b). Once the flag More_bit contained in the data frame is set to $0$, then, each node receiving this packet will be aware that it is the last RT packet, and it consequently switches back to LDC mode.

3.2 Cascading wake-up schedule

To reduce the delay wasted when a transmitter remains waiting for the receiver to wake-up (in idle listening), the active time of both nodes must be proportional to the propagation time value plus the time required to receive a packet, which represents the idle listening interval when perfect synchronization is assured. DuoMAC is based on adaptive self-adjusting cascading wake-up scheduling. The dynamically updated cascading wake-up feature of DuoMAC permits to wake up nodes asynchronously and independently from their neighbors (Fig. 2(a)). If $parent_{n_i}$ is the selected next forwarder (parent) of node $n_i$, then, the wake-up time, $W_{n_i}$, must be shifted $\sigma _{n_i}$ (amount of time) before $W_{parent_{n_i}}$. Consequently, the closer the node is to the sink, the more its corresponding $\sigma _{n_i}$ time will increase. The wake-up time $W_{n_i}$ of a node is not static, but it depends on the traffic load to be handled at the current cycle $t_m$ and the wake-up time of its parent, which makes the wake-up schedule adaptive to the traffic to be handled at each node. As a result, $W_{n_i}(t_{m+1})$ can be calculated as a function of $\sigma _{n_i}$ and $W_{parent_{n_i}}$, i.e., $W_{n_i}(t_{m+1})=f \left( \sigma _{n_i}(t_{m}), W_{parent_{n_i}}(t_m) \right)$. For an operation cycle $t_{m}$, $\sigma _{n_i}(t_m)$ is the required time to receive the estimated load (NRT traffic load), $L(t_m)$, by node $n_i$, from its children during the next cycle, which may vary in time. For instance, a node needs to estimate the upcoming traffic load for the next operation cycle so that it can calculate its next wake-up time.

3.3 Estimating the traffic load

Each node in the network has to estimate the load it expects to receive in the coming period in order to calculate the wake up schedule. To determine the best traffic load estimator, we rely on the fact that the average input traffic depends linearly on the data traffic rate, Sect. 4.1, Eq. (10), which justifies the choice of a linear estimator for traffic. To validate this assumption, we have performed extensive experimentations using a 20 MicaZ testbed, where the traffic load flowed by the nodes has been tracked. In the testbed, each node generates traffic with a frequency of 2 pkt/sec. The estimated and received average loads in some nodes are plotted in Fig. 3. The selected nodes are labeled and depicted in Fig. 4. Figure 3(a) shows that the traffic load has a linear form. At a given operation cycle $t_m$, the node gathers information about the received traffic, $L_{n_i}(t_m)$ at node $n_i$. In the following, $n_i$ is omitted for clarity. To calculate the estimated traffic for the next cycle $t_{m+1}$, the current load value of the nodes are predicted according to the $m$ previous load values, using a linear prediction scheme. Assume that the load values $L(t_k)$ at times $t_k$ ($k$ = 1, ..., $m$) are known, and that the load value at time $t_{m+1}$, $L(t_{m+1})$, has to be predicted. This load is calculated using the least mean square (LMS) method: $L(t_{m+1})= at_{m+1}+b$, where coefficients $a$ and $b$ are obtained from solving the system equations of Eq. (1):

$$\begin{aligned} {\left\{ \begin{array}{ll} \sum _{k=1}^{m} t_k L(t_k) &{}= a \sum _{k=1}^{m} t_k^2 + b \sum _{k=1}^{m} t_k\\ \sum _{k=1}^{m} L(t_k) &{}= a \sum _{k=1}^{m} t_k + bm \\ \end{array}\right. } \end{aligned}$$

(1)

Resolving the above system yields the following solution for $a$ and $b$:

$$\begin{aligned} a =&\frac{ \sum _{k=1}^{m} L(t_k) \sum _{k=1}^{m} t_k - m \sum _{k=1}^{m} t_k L(t_k)}{ \left( \sum _{k=1}^{m} t_k \right) ^2 - m \sum _{k=1}^{m} t_k^2 },\end{aligned}$$

(2)

$$\begin{aligned} b =&\frac{ \sum _{k=1}^{m} t_k L(t_k)}{ \sum _{k=1}^{m} t_k} \nonumber \\&- \left( \frac{ \sum _{k=1}^{m} t_k^2}{ \sum _{k=1}^{m} t_k}\right) \left( \frac{ \sum _{k=1}^{m} L(t_k) \sum _{k=1}^{m} t_k - m \sum _{k=1}^{m} t_k L(t_k)}{ \left( \sum _{k=1}^{m} t_k \right) ^2 - m \sum _{k=1}^{m} t_k^2 } \right) \end{aligned}$$

(3)

In the experiment, $m$ has been fixed to $100$, $a$ and $b$ have been accordingly calculated. To investigate how the linear estimator performs, the estimated load, Fig. 3(b), has been recorded in the same intermediate nodes as in the experiment i.e. nodes 1,2,11,12, and 30, and under the same traffic rate of 2 pkt/sec. The results show a smooth increase in time, an approximative approach to the real values, Fig. 3(a), for all nodes. These results confirm the effectiveness of a linear estimator. In general, other topologies such as random deployment, [18] also present linear dependency with respect to the data rate. Further, topologies that produce other traffic profiles and require other estimators, e.g. non-linear, can be easily integrated in the proposed protocol.

Fig. 3

a Received load and b estimated load at intermediate nodes (1, 2, 11, 12, 30) with traffic rate = $2$ $pkts/sec$ and parameters $a/b = 0.9710/0.3735$

Fig. 4

Network topology and local node traffic flowing

3.4 Adjusting the wake-up time

As discussed earlier, the wake-up time $W_{n_i}$ of node $n_i$ can be calculated as a function of two parameters; $W_{n_i}(t_{m+1}) = f \left( \sigma _{n_i}(t_m),W_{parent_{n_i}}(t_m) \right)$, where $\sigma _{n_i}(t_m)$ is as defined in Sect. 3.2. Suppose $TX_i$ is the time required to transmit one packet from an arbitrary node, $n_i$, including contention and acknowledgement times: $TX_i = T_{cw} + T_{data}$. $T_{cw}$ is the contention window time and it is calculated as the contention window size multiplied by the time-slot, and $T_{data} = T_{hdr} + P/R + T_{ack}$. Definitions and values for $T_{cw}$, $T_{hdr}$, P, R and $T_{ack}$ depends on the protocol, they are given in Table 2. Then $\sigma _{n_i}(t_m)$ can be calculated as follows,

$$\sigma _{n_i}(t_m) = T^{B_w}_{tx} + TX_i *L(t_m) + T^{B_w}_{rx}$$

(4)

where $T^{B_w}_{tx}$ and $T^{B_w}_{rx}$ are the required times to send and receive the wake-up beacon, $B_w$, including contention, $L(T_m)$ is the number of packets that the node estimates it will receive in the coming cycle, and TX is the time that a children node needs to transmit every packet. Given the value of $\sigma _{n_i}(t_m)$, the next wake-up time, $W_{n_i}(t_{m+1})$, can be calculated as:

$$W_{n_i}(t_{m+1}) = W_{parent_{n_i}}(t_m) - \sigma _{n_i}(t_m)$$

(5)

3.5 Service differentiation and CW adaptation

In order to provide hybrid prioritization levels between the traffic type and the traversed hop-count, an effective service differentiation scheme that relies on contention window ($CW$) size adaptation mechanism is proposed. Saxena et al. [26] propose a $CW$ adaptation algorithm based on loss probabilities by defining for each traffic class a targeted contention window, $CW_{target}$, to be reached after several steps. Yigitel et al. [33] propose a $CW$ adaptation approach that initiates the $CW$ of each traffic class from the medium value, i.e., $\frac{cw_{min}+cw_{max}}{2}$, then it moves it up and down according to PRR (Packet Reception Ratio) measurements. We propose a $CW$ adaptation algorithm that differs from those in [26] [33] in two main points. First, the PRR is combined with a link quality metric called link burst length, which uses the concepts of $b_{min}$ and $b_{max}$ as defined in [22]. With this metric, a good link is characterized with a short $b_{max}$, which defines the maximum consecutive packet transmission errors in a burst, and with a long $b_{min}$, which defines the minimum consecutive successful packet transmissions between two bursts of packets. For example, for a burst of 10 transmitted packets, in the sequence 0110010011, a 0 at position i indicates that the ith packet transmission has failed, where 1 indicates that the packet transmission has been successful. In this example, $b_{max}=2$ and $b_{min}=1$ for packet bursts of window size equal to 3. Authors in [22] show that these two parameters outperform PRR and capture better the link quality. Second, our $CW$ adaptation scheme is initiated to $cw_{min}$ (to reduce e2e delay), and it is then moved up and down based on the estimated link quality $P_{LQ}(t_i)$ given by Eq. (6).

$$P_{LQ}(t_i) = PRR * \frac{b_{min}}{b_{max}}$$

(6)

To summarize, DuoMAC runs a $CW$ adaptation scheme, as described in Algorithm 1, for each $N$ traffic samples that constitutes a burst of length $N$. For every burst $t_i$, the algorithm computes $P_{LQ}(t_i)$, and accordingly moves the $CW$. Finally, DuoMAC implements the same principle as introduced in [33] for setting non-overlapping $CW$ sizes, where $CW^{RT} < CW^{NRT}$. The adaptation coefficient are chosen to fulfil the following conditions: $\alpha ^{RT}_{up}<\alpha ^{NRT}_{up}$ and $\alpha ^{RT}_{down}>\alpha ^{NRT}_{down}$.

3.6 Dealing with topology changes

Due to the use of wireless communication channels, WSNs are prone to frequent link breakdown, which causes routes changes. To deal with this problem in DuoMAC, every node stores information about its potential forwarders during its connection phase, and connects to one parent (the one with best link quality). In case a node has not received beacons from its parent for a number of consecutive cycles (set in our implementation to 3), DuoMAC considers this as an indication of that the link was broken down and the parent becomes unreachable. In this case, the node must chose another parent from the forwarder list and follows its schedule. It is obvious that frequent link breakdown deteriorates the performance of MAC protocols, especially those based on scheduling. Nonetheless, DuoMAC is relatively less affected by this problem, since (1) it is not based on schedule establishment, and (2) the wakeup time to receive NRT traffic is updated at every cycle, which permits a fast re-connection after link breakdown.

4 Comparative analysis

A comprehensive analysis of the proposed MAC protocol is given in the following, in comparison of some competitors from the literature. The chosen protocols are DMAC [20], LL-MAC [34], and Diff-MAC [33], which are all energy-delay efficient duty-cycled MAC protocols, and thus the most relevant for comparison. We first define the network and traffic models, which permit to determine the topology information and the traffic load at each node. Then, the protocols are analyzed through their operating modes (idle, transmission, receiving, and sleep modes). For every protocol, the energy consumption function, E, and the maximum e2e (end to end) packet delay, L, are derived.

4.1 Network and traffic model

An unsaturated network with low traffic is considered, as a typical scenario of WSN applications. A grid topology is adopted for the sake of simplification, and which is also suitable in scenarios similar to that presented in Fig. 1. However, the analysis can be easily adapted to other irregular deployments, as well as regular topologies by reformulating the input, output, and background traffic handled by each node in the network (e.g., the network and traffic models derived in [18] for ring topologies). A spanning tree is constructed, where nodes are static and maintain a unique path to the sink. The shortest paths to the sink are used, which are generally time-varying depending on the link quality. The maximum path length is denoted by D, i.e., the depth of the tree. A uniform node density on the plane domain and a unit disk graph communication model are used, with $C+1$ nodes supposed to be on the unit disk. That is, all nodes are in communication range with C neighboring nodes,¹ except those in the boundary of the grid as depicted in Fig. 4. The nodes are layered into levels according to their distance to the sink, in terms of minimal hop count, d.

Table 1 CC2420 Radio constants [4], network and traffic model with typical parameter values

In the following, the traffic model derived in [18] is extended for our network model. Let us consider periodic traffic generation, where every source node generates traffic with frequency, $F_s = F_{RT} + F_{NRT}$ for protocols that consider heterogeneous traffic, e.g., DuoMAC. Then, for every node, the input $F^d_I$, output $F^d_{out}$, background $F^d_B$ traffic, and average number of input links $I^d$ are derived accordingly. The background traffic is defined as the traffic overheard by a node that is submitted by neighboring nodes not selected as children. Background nodes may be peers at the same level of the tree, as well as nodes at adjacent (below or above) levels. The latter group includes (among others) the parent node forwarding a node’s outgoing traffic further up in the tree. Figure 4 shows an example, in which node $22$ is the parent of nodes $44$, $45$ and $46$. The parent of node $22$ is node $7$. Neighboring nodes 6, 7, 8, 21 and 23 are background nodes. The different symbols introduced in the analysis related to network and traffic model are summarized in Table 1 with typical values. The neighboring nodes can be classified as the set of children (input) nodes, $I$, and the set of overheard (background) nodes, $B$, such as, $C = |I|+|B|$. Since the first level contains C nodes (refer Fig. 4), the number of nodes $N_d$ at level d can be expressed by $Cd$, except for $d=0$where it is $1$ (reserved to the sink). This permits to compute the average number of input links, $I_d$, of a node at level, d, as:

$$\begin{array}{ll} &{} I_d= \left\{ \begin{array}{ll} 0,&{} if \,\,d=D,\\ C,&{} if \,\,d=0,\\ \frac{N_{d+1}}{N_d} = \frac{d+1}{d}, &{} if \,\, 0<d<D . \end{array}\right. \end{array}$$

(7)

Every input link among the $I_d$ links of a node at level d transfers both RT and NRT traffics. The average output traffic frequency of a node at level d, $F^d_{out}$, is thus given by,

$$F^d_{out} = F^d_I + F_s = I_d.F^{d+1}_{out} + F_s$$

(8)

By iterating Eq. (8) at each level starting from leave nodes to the sink, the following generalized traffic equation is obtained,

$$\begin{aligned} F^d_{out}&= \left\{ \begin{array}{ll} F_s & if \,\,d=D,\\ 0 & if \,\,d=0,\\ \frac{D^2-d^2+D-d}{2d}F_s & if \,\, 0<d<D. \end{array}\right. \end{aligned}$$

(9)

From Eqs. (8), and (9):

$$\begin{aligned} F^d_I&= \left\{ \begin{array}{ll} 0 & if \,\,d=D,\\ C\frac{D^2+D}{2}F_s & if \,\,d=0,\\ \frac{D^2-d^2+D-3d}{2d}F_s & if \,\, 0<d<D. \end{array}\right. \end{aligned}$$

(10)

For the background traffic, $B$ nodes are generating the same load $F^d_{out}$ as the node itself [18]. Therefore, the average background traffic frequency of a node at level d, say $F^d_B$, is given by,

$$\begin{aligned} F^d_B&= (C-|I_d|)F^d_{out} \nonumber \\&= \left\{ \begin{array}{ll} C*F_s & if \,\,d=D,\\ 0 & if \,\,d=0,\\ \frac{(Cd-d-1)(D^2-d^2+D-d)}{2d^2}F_s & otherwise. \end{array}\right. \end{aligned}$$

(11)

The traffic model is valid for low data rate applications in which the sampling rate $F_s <$0.1 Hz. The radio model uses realistic hardware values, Table 1, based on the CC2420 chipset. Since the objective is to compare the relative performance of the DuoMAC protocol with respect to other MAC protocols, we do not compute absolute energy consumption values and only effective duty cycles. That means that energy consumption is computed as a fraction of the time the radio is switched on. Thus, the radio can be modeled using the time needed to power up the radio, the radio baud rate, and the time needed to do a carrier sense. We refer to paper [18] for a discussion on the radio model and traffic model. The same traffic model may be adapted to other topologies, including irregular ones. The traffic model assumes that there are no losses, i.e., no retransmissions, and thus the free-space propagation model is used. The traffic model has been validated in [18] through intensive simulations. The authors show that the analytical model provides results with <5 % of delivery ratio and energy consumption. This represents a powerful tool for comparing MAC protocols for low data rate applications.

4.2 Energy and delay model

Let Network Energy Consumption be defined as the amount of energy consumed by the radio duty of each node in the network according to its position and the amount of traffic it handles. Thus, the node’s energy consumption is the sum of energy consumed in each operating mode, which depends on the exchanged traffic load and the MAC intrinsic parameters. For example, let $E^n_{idle}$, $E^n_{tx}$, and $E^n_{rx}$ be the energy consumed fractions in idle listening,² transmitting and receiving modes, the node’s energy consumption can be calculated as $E^n = E^n_{idle} + E^n_{tx} + E^n_{rx}$. The normalized energy consumption (in Joules) can be calculated by multiplying the obtained expressions in each mode by the current draws of the radio defined in the datasheet for each mode (eg. $I_{idle}$, $I_{tx}$, and $I_{rx}$). Given the energy consumption, $E^n$, of node, $n$, the Network Energy Consumption $\varvec{E}$ for all nodes in the network can be expressed as,

$$\varvec{E} = {\mathop { \varvec{\sum }}\limits _{{\varvec{n}} \in {\varvec{N}}}} \left( E^n \right)$$

(12)

The end-to-end (e2e) packet delay (latency), $L^n$, is defined as the expected time between the first transmission of a packet at node $n \in N$, and its reception at the sink. It is then a per-topology parameter, in the sense that it depends on the position of the node that generates the data. $L^n$ denotes the sum of per-hop latencies of the shortest path ${\mathcal {P}}^n$ from node $n$ to the sink, where $L_l^n$ is one-hop latency on each link $l \in {\mathcal {P}}^n$. The maximum end-to-end latency, $\varvec{L}$, is defined as the maximum latency from any node to the sink:

$$\varvec{L} = {\mathop {\varvec{\max }}\limits _{\varvec{n} \in \varvec{N}}} \left( L^n \right) = {\mathop {\varvec{\max }}\limits _{\varvec{n} \in \varvec{N}}} \left( { \sum _{l\in {\mathcal {P}}^{\varvec{n}}}} L_l^n \right)$$

(13)

The network energy consumption as well as the maximum e2e packet delay are MAC dependent. Expressions for Eqs. (12) and (13) for some canonical MAC protocols are developed in the following subsections and details are given in “Appendix: MAC energy-delay models” of Appendix.

4.3 DMAC protocol

Data-gathering MAC (DMAC) [20] is a synchronous protocol that addresses the delay of convergecast based data delivery, by scheduling the receiving and sending slots in a wave-like chain according to the nodes level in the gathering tree. Referring to Fig. 5, DMAC’s frame has a size of $T_w$; the wake-up period. It is composed by a receive slot, a transmission slot, and a number of sleep slots (1). The receive slot of each node coincides with the transmission slot of down-level nodes (children) (2), whereas the transmission (3) slot coincides with the receive slot of the parent. Nodes must contend in each slot $T_{slot}$ using CSMA with acknowledgments (4), and they compensate for clock drift with a guard time $T_{guard}$, $T_{guard} = 4\theta T_{sync}$ (5). Synchronization messages are exchanged every $T_{sync}$ interval using regular sending and receiving slots (6). Additional slots are added in the sleep period when there is more data to be sent using a data-prediction scheme (7). In DMAC, energy is consumed in transmission, $E_{tx}$, reception, $E_{rx}$, and in data prediction, $E_{dp}$, modes [18]. The per-node energy consumption based on the protocol operation modes and the e2e packet delay are provided in “DMAC Protocol” of Appendix. From Eqs. (28) and (29), we define the following energy-delay functions, where $T_w$, and $T_{sync}$ are the key DMAC’s parameters:

• (a) The network energy consumption function:

  $$\varvec{E^{DMAC}} = \frac{\alpha _1}{T_w} + \alpha _2 \frac{T_{sync}}{T_w} + \alpha _3 T_{sync} + \frac{\alpha _4}{T_{sync}} + \alpha _5$$

  (14)

  where $\alpha _1 = \varvec{\displaystyle \sum _{n=1}^{N}} \left( T_{up} + T_{cw} + T_{data} \right)$, $\alpha _2 = \varvec{\displaystyle \sum _{n=1}^{N}} 2\theta$, $\alpha _3 = \varvec{\displaystyle \sum _{n=1}^{N}} 2\theta F^n_I$, $\alpha _4 = \varvec{\displaystyle \sum _{n=1}^{N}} \left( 2\theta I^n + \left( T_{cs} + T_{data}\right) F^n_{out} + (T_{up} + T_{cw} + T_{data}) F^n_I \right)$, and $\alpha _5 = \varvec{\displaystyle \sum _{n=1}^{N}} \left( T_{cs} + T_{hdr} + \left( T_{up} + T_{cw} + T_{data} \right) I^n \right)$.

• (b) The e2e packet delay function:

  $$\varvec{L^{DMAC}} \,=\, {\mathop {\varvec{\max }}_{\varvec{n} \in \varvec{N}}} \left( \beta _1 T_w + \beta _2 T_{sync} + \beta _3 \right)$$

  (15)

where $\beta _1 = 1/2$, $\beta _2 = \varvec{ \sum _{i=1}^{d^n}} 2\theta$ and $\beta _3 = \varvec{ \sum _{i=1}^{d^n}} \left( T_{cw}/2 + T_{data}\right)$. Parameters used in the formulas for the D-MAC protocol are defined in Table 2.

Fig. 5

DMAC’s transmission, receiving, and data prediction modes

4.4 LL-MAC protocol

LL-MAC (Low Latency MAC) [34] is an asynchronous protocol that uses the same staggered active times of nodes– similarly to DMAC– to reduce sleep delay in a multi-hop transmissions. Referring to Fig. 6, nodes wake-up every $T_w$ to receive and send packets (1). If $\Delta$ is the necessary time to transmit one packet (slot duration), then the node’s reception time will be shifted $\Delta$ time before its parent’s wake-up time (2). Due to the asynchronous scheme of LL-MAC, nodes must compensate with a guard time $T_{guard}$ ($T_{guard} = 4\theta T_w$) for clock drift in every operation cycle $T_w$ (3). The transmission slot includes contention, guard time, and data transmission with acknowledgment. Energy is spent in transmitting and receiving modes, respectively $E_{tx}$ and $E_{rx}$. The LL-MAC per-node energy consumption based on the protocol operation modes and the e2e packet delay are provided in “LL-MAC Protocol” of Appendix . From Eqs. (30) and (31), the following energy-delay functions are derived, where $T_w$ is the key LL-MAC’s parameter:

• (a) The network energy consumption function:

  $$\varvec{E^{LLMAC}} = \frac{\gamma _1}{T_w} + \gamma _2$$

  (16)

  where $\gamma _1 = \varvec{ \sum _{n=1}^{N}} \left( T_{up} + T_{cw} + T_{data} \right)$ and $\gamma _2 = \varvec{ \sum _{n=1}^{N}} \left( 2\theta + \left( T_{cs} + T_{data}\right) F^n_{out} \right)$.

• (b) The e2e packet delay function:

  $$\varvec{L^{LLMAC}} = {\mathop {\varvec{\max }}_{{\varvec{n}} \in {\varvec{N}}}} \left( \delta _1 T_w + \delta _2 \right)$$

  (17)

where $\delta _1 = 1/2 + \varvec{ \sum _{i=1}^{d^n}} 2\theta$ and $\delta _2 = \varvec{ \sum _{i=1}^{d^n}} \left( T_{cw}/2 + T_{data}\right)$ Parameters used in the formulas for the LL-MAC protocol are defined in Table 2.

Fig. 6

LL-MAC’s transmission, receiving, and sleep modes

4.5 Diff-MAC protocol

Diff-MAC [33] is QoS-aware MAC protocol that adopts a service differentiation through inter and intra queue prioritization. It also uses contention window ($CW$) adaptation for different traffic: multimedia traffic (RT), non realtime traffic (NRT), and best effort (BE) traffic. This is to provide energy-delay application efficiency as described in Sect. 3.5. In this paper, the analysis is limited to only RT and NRT traffics. Diff-MAC is implemented on the top of a well-known slotted duty-cycled sensor MAC protocol (SMAC) [32], and it adopts all its features [33]. As depicted in Fig. 7, nodes are synchronized to a common slot structure of a fixed length $T_w$ (1). The slots are divided into an active period $T_{active}$ (2), a sync phase $T_{sync}$ (3), and a sleep phase $T_{sleep}$ (4). Nodes broadcast SYNC beacons to keep the network synchronized (5). The nodes are therefore synchronized every $(C + 1)$ slots and require a clock-drift compensation of $T_{guard} = 2\theta T_w(C + 1)$. The sync phase has a length of $T_{sync} = T_{guard} + T_{cw} + T_{hdr}$. In the active phase, the nodes contend for the channel using RTS/CTS handshake with acknowledgment to send RT and NRT data packets. A different contention window is used for each traffic category used, respectively $CW_{RT}$ and $CW_{NRT}$ (6). Nodes switch off their radios for the duration indicated in RTS/CTS packets to avoid overhearing. In Diff-MAC, energy is spent in the synchronization and in active phases, except when background traffic is exchanged [18]. Diff-MAC per-node energy and RT/NRT e2e packet delay are provided in “Diff-MAC Protocol” of Appendix. From Eqs. (32) and (33), the following energy-delay functions are defined, where $T_w$, $T_{active}$, and $T_{sleep}$ are the key Diff-MAC’s parameters:

• (a) The network energy consumption function:

  $$\varvec{E^{\text {Diff-MAC}}} = \frac{\lambda _1}{T_w} + \frac{T_{active}}{T_w} + \frac{\lambda _2}{T_{sleep}} + \lambda _3$$

  (18)

  where $\lambda _1 = \varvec{ \sum _{n=1}^{N}} \left( T^{NRT}_{cw} + T_{hdr} \right)$, $\lambda _2 = \varvec{ \sum _{n=1}^{N}} \frac{1}{T_{ 0}}$, and $\lambda _3 = \left( 2\theta - \left( T_{data} - T_{hdr} - T_{up}\right) F^n_B \right)$.

• (b) The e2e packet delay function:

  $$\begin{aligned} {\varvec{L}}^{\text {Diff-MAC}}{\varvec{(RT)}}\,= \,& {\mathop {\varvec{\max }}\limits _{{\varvec{n}} \in {\varvec{N}}}} \left( \mu _1 T_w + \mu _2 T_{sleep}\right. \nonumber \\+ \,& {} \left. \mu _3 \frac{T_w}{T_{active}} + \frac{\mu _4}{T_{active}} + \mu _5 \right) \end{aligned}$$

  (19)

  where $\mu _1 = \theta$, $\mu _2 = 1/2$, $\mu _3 = \varvec{ \sum _{i=1}^{d^n}} \left( \frac{T^{RT}_{cw}}{2} + T_{data} \right)$, $\mu _4 = \varvec{ \sum _{i=1}^{d^n}} \left( \frac{T^{RT}_{cw}}{2} + T_{data} \right) ^2$, and $\mu _5 = \frac{T^{NRT}_{cw} + T_{hdr}}{2}$.

  $$\begin{aligned} {\varvec{L}}^{\text {Diff-MAC}}{\varvec{(NRT)}}\,= \,& {\mathop {\varvec{\max }}\limits _{{\varvec{n}} \in {\varvec{N}}}} \left( \varepsilon _1 T_w + \varepsilon _2 T_{sleep} \right. \nonumber \\&+\left. \varepsilon _3 \frac{T_w}{T_{active}} + \frac{\varepsilon _4}{T_{active}} + \varepsilon _5 \right) \end{aligned}$$

  (20)

  where $\varepsilon _1 = \theta$, $\varepsilon _2 = 1/2$, $\varepsilon _3 = \varvec{ \sum _{i=1}^{d^n}} \left( \frac{T^{NRT}_{cw}}{2} + T_{data} \right)$, $\varepsilon _4 = \varvec{ \sum _{i=1}^{d^n}} \left( \frac{T^{NRT}_{cw}}{2} + T_{data} \right) ^2$, and $\varepsilon _5 = \frac{T^{NRT}_{cw} + T_{hdr}}{2}$. Parameters used in the formulas for the Diff-MAC protocol are defined in Table 2.

Fig. 7

Diff-MAC’s synchronization, active, and sleep modes

4.6 DuoMAC protocol

DuoMAC protocol handles two kinds of traffic, namely RT and NRT. Consequently, it uses two operation modes, LDC and HDC, to forward data packets. In this analysis, both LDC and HDC modes are considered to derive the delay and the energy equations. Details concerning the per-node energy and e2e packet delay for RT (HDC mode) and NRT (LDC mode) traffic of DuoMAC are given are in “DuoMAC Protocol” of Appendix (description of every term used in the formulas can be found in Table 2). From Eqs. (34–37), we define the following energy-delay functions, where $T_{cp}$ and $T_w$ are the key DuoMAC’s parameters to be considered.

• (a) The network energy consumption function:

  $$\varvec{E^{DuoMAC}} = \zeta _1 T_{cp} + \frac{\zeta _2}{T_{cp}} + \zeta _3 T_w + \frac{\zeta _4}{T_w} + \zeta _5$$

  (21)

  where $\zeta _1 = \varvec{ \sum _{n=1}^{N}} \frac{F^{RT}_{out}}{2}$, $\zeta _2 = \varvec{ \sum _{n=1}^{N}} \left( T_{on} + \frac{T_{rts} + T_{cl} + 2T_{cts} + 2T_{data}}{4} 3T_{rts}.F^{RT}_B \right)$, $\zeta _3 = \varvec{ \sum _{n=1}^{N}} 4\theta F^{NRT}_I$, $\zeta _4= \varvec{ \sum _{n=1}^{N}} \left( T^{B_w}_{rx} + T^{B_{nw}}_{rx} + T^{B_w}_{tx} + T^{B_{nw}}_{tx} \right)$, $\zeta _5 = \varvec{ \sum _{n=1}^{N}}$ $\left( \left( T_{on} + \frac{T_{rts}+T_{cl}}{2} + T_{cts} + T_{data}\right) F^{RT}_{out} + E^d_{rx} + \frac{3}{4}T_{rts}F^{RT}_B + \left( T_{cw}+T_{data}\right) F^{NRT}_I + \left( T_{cs}+T_{data}\right) F^{NRT}_{out} \right)$.

• (b) The e2e packet delay function:

  $$\varvec{L^{DuoMAC}(RT)} = {\mathop {\varvec{\max }}_{{\varvec{n}} \in {\varvec{N}}}} \left( \upsilon _1 T_{cp} + \upsilon _2 \right)$$

  (22)

  where $\upsilon _1 = \varvec{ \sum _{i=1}^{d^n}} 1/2$, $\upsilon _2 = \varvec{ \sum _{i=1}^{d^n}} \left( \frac{T^{RT}_{cw}}{2} + T_{data} \mathcal {P}_{lq} \right)$.

  $$\varvec{L^{DuoMAC}(NRT)} = \varvec{\max _{n \in N}} \left( \eta _1 T_w + \eta _2 \right)$$

  (23)

where $\eta _1 = 1/2,\, \eta _2 = \varvec{ \sum _{i=1}^{d^n}} \left( T^{B_w}_{rx} + T^{B_{nw}}_{tx} + \left( \frac{T^{NRT}_{cw}}{2} + T_{data} \mathcal {P}_{lq} \right) \frac{F^i_{I,NRT}}{F_{NRT}} \right)$.

Table 2 DMAC, LL-MAC, Diff-MAC, and DuoMAC symbols used in energy & Delay equations with typical values [18, 33, 34]

4.7 Analytical results

The equations derived thus far for each protocol are used in the following to compare the protocols under different network, traffic and MAC parameters configurations.

4.7.1 The wake-up period

The network energy, E, and the maximum e2e delay L are measured when varying the wake-up period, $T_w$. The network connectivity, C, and depth, D, are set to, $8$ and, $10$, respectively. The traffic generation rate of both RT and NRT is fixed to 0.5 pkt/min. The synchronization period of DMAC is $T_{sync} =60s$, and the active period of Diff-MAC is set to $0.4*T_w$, while the channel polling period of DuoMAC is set to $0.1*T_w$. The wake-up period $T_w$ is varied from 1 to 10 s, and the results are depicted in Fig. 8(a, b). The results show that LL-MAC outperforms all MACs from the energy perspective. This is because LL-MAC does not rely on synchronization and handles only a single packet per cycle. DuoMAC consumes lower energy compared to Diff-MAC when increasing the wake-up period, due to the use of the cascading scheme. With respect to latency, DuoMAC outperforms the other protocols for RT traffic and it performs better than DMAC and closer to LL-MAC for NRT traffic [Fig. 8(b)]. From both figures, the conclusion is that although LL-MAC offers better performance with respect to energy consumption it does not have the possibility to differentiate between NRT and RT traffic. On the other hand, DuoMAC, for NRT offers similar latencies than LL-MAC and trade-offs energy consumption to offer lower latencies for RT traffic. Diff-MAC also offers similar trade-offs than DuoMAC; it offers better energy consumption but worst RT latency than DuoMAC. The main conclusion of this set of plots is that in order to offer better RT e2e delay, it is necessary to sacrifice energy. Section 5 is devoted to optimize DuoMAC parameters in order to improve energy consumption without penalizing too much the RT e2e delay.

Fig. 8

a Energy E obtained by varying $T_w \in [1000, 10,000]$ms. b e2e Latency L obtained by varying $T_w \in [1000, 10,000]$ms

4.7.2 The network depth

Here the network depth D is varied from 1 to 10 levels to measure the performance metrics that are depicted in Fig. 9(a, b). The network connectivity, C, is set to 8. The traffic generation of RT and NRT is fixed to 0.005 pkt/min. The wake-up period of all protocols is set to 1000 ms, the synchronization period of DMAC to 60 s, the active period of Diff-MAC to 200 ms, and the channel polling period of DuoMAC to 200 ms. The results show that the energy consumption of DuoMAC is higher than LL-MAC and DMAC and lower than Diff-MAC in all the network depth configurations. The reason again is that LL-MAC and DMAC does not differentiate between RT and NRT traffic. However, these protocols offer worst latencies than the DuoMAC for RT traffic. On the other hand, Diff-MAC consumes more energy and produces higher latencies than DuoMAC.

Fig. 9

a Energy E obtained by varying $D \in [1, 10]$ levels. b e2e Latency L obtained by varying $D \in [1, 10]$ levels

4.7.3 RT traffic frequency

In this part, the RT traffic generation frequency, $F_{RT}$, is varied from 0.5 to 20 pkt/min. The network connectivity and depth are set to 8 and 10, respectively. The wake-up period of all protocols is set to 5000 ms, while the traffic generation of NRT is fixed to 1 pkt/min. The results are depicted in Fig. 10(a, b). The energy consumption of DuoMAC is normally affected by increasing the RT traffic rate, while those of the other protocols increase slightly. This is because DuoMAC switches more frequently to HDC mode as the RT rate rises to quickly forward realtime packets. The benefit from this is the lower latency compared to all the other protocols, Fig. 10(b). Note that due to the low data rate, delays related to retransmissions and buffering are not considered in the analysis, which justifies independency of the e2e delay with traffic variation.

Fig. 10

a Energy E obtained by varying $F_{RT} \in [0.5, 20]$ $pkt/min$. b e2e Latency L obtained by varying $F_{RT} \in [0.5, 20]$ $pkt/min$

4.7.4 NRT traffic frequency

Here, the RT traffic generation is set to 1 pkt/min, and the NRT traffic $F_{NRT}$ is varied from 0.5 to 20 pkt/min. The results are depicted in Fig. 11(a, b). In this case, DuoMAC’s energy is not affected by NRT traffic variability, as it becomes less delay sensitive. DuoMAC performs better than Diff-MAC, while LL-MAC achieves the best results in energy consumption. The same results as when varying RT traffic can be observed for the e2e delay. The results show that DuoMAC outperforms all the other protocols by assuring the lowest latency for RT, but at the price of an increase in power consumption. The results also show that there is an important gap in power consumption between RT and NRT modes of DuoMAC, which justifies the switching strategy between the two modes adopted by DuoMAC. The results also reveal that some intrinsic parameter such as, $T_w$, have significant effect. So there is ample room for improvement by optimizing such parameters, which is the aim of Sect. 5. Finally, the results show that LL-MAC has the best performance with respect to power consumption, so it will be used as a reference for comparison in the testbed/simulation protocol evaluation.

Fig. 11

a Energy E obtained by varying $F_{NRT} \in [0.5, 20]$ $pkt/min$. b e2e Latency L obtained by varying $F_{NRT} \in [0.5, 20]$ $pkt/min$

4.7.5 Delay versus energy gain

We have shown the comparison between MAC protocols for different network, traffic and MAC parameters configurations. The results reveal that DuoMAC protocol can reduce much better the e2e delay over other MAC protocols especially for RT traffic at the cost of some energy consumption. Given that the energy and the delay are the conflicting performance metrics, an efficient MAC protocol must be tuned with the optimal parameters that permit to achieve the trade-off between them. Figure 12(a) depicts the energy and the e2e delay resulted for different wake-up periods $T_w$ which represents the key MAC parameter that affects both performance metrics (energy and delay). It can be observed that for values of $T_w \in [1000, 1500)$ms, DuoMAC can achieve best tradeoff between the two metrics. Quantitatively speaking, we propose a metric, $G$, unifying the energy and the delay performance metrics that expresses the gain of our protocol over other MAC protocols. This metric represents the ratio between what we win in terms of e2e delay reduction ratio, and what we pay in terms of additional energy consumption ratio. This metric relating DuoMAC, to some other protocol, say $MAC_X$, is calculated as follows:

$$G = \frac{ R_L}{ R_E}$$

(24)

where $R_L$ represents the ratio of the delay reduction ($L^{MAC_X} / L^{DuoMAC}$) and $R_E$ represents the ratio of the cost ($E^{DuoMAC} / E^{MAC_X}$). Figure 12(b, c) depict the gain of DuoMAC over other MAC for RT and NRT traffic respectively. It can be observed that the gain is much better for RT than NRT traffic. The gain for instance is more important when comparing with LL-MAC than DMAC and Diff-MAC. It can be observed also that this gain decreases generally with the increase of $T_w$ values where the reduction in delay and the additional energy spent become less important.

Fig. 12

a Delay versus energy for different values of wakeup periods $T_w$ and b the gain under RT traffic for different values of wakeup periods $T_w$ and c the gain under NRT traffic for different values of wakeup periods $T_w$

5 Parameters optimization

5.1 Optimization problem

Given the application requirements in terms of initial energy budget and the tolerated e2e packet delay, the choice of MAC parameters is of great importance; yet their choice is currently done by system designers based on repeated real experiences [5], which may be optimal for one objective that is not necessarily optimal for others and can yield a performance far off the desired results. DuoMAC protocol is optimized dynamically as a constrained optimization problem. Key performance metrics of the system scenario are considered, namely energy consumption, $\varvec{E}$, and the e2e latency of RT traffic, $\varvec{L}$. The MAC parameter optimization problem involves optimizing the network energy $\varvec{E}$ as objective function subject to e2e latency $\varvec{L}$ as constraint. In long-term traffic monitoring systems, the major concern is typically the system lifetime expressed by the energy consumption, but at the same time with some bound guarantee on delay in delivering measurements of RT traffic $L^{DuoMAC}(RT) \leqslant L^{max}_{RT}$. The link quality represents the only network state information used as input for our protocol optimization. It is expressed by $\mathcal {P}^n_{lq}$, the probability of successful transmission over a link at node $n$, and it is calculated using the effective link quality estimation metric defined in Sect. 3.5.

There are two specific and adjustable parameters in DuoMAC implementation that affect the protocol performance, (1) the channel polling period to check for possible incoming RT traffic, $T_{cp}$ and (2) the wake-up period to send beacons and NRT traffic, $T_w$. Both variables are expressed as a vector $X=[T_{cp}, T_w)$. Based on this approach, minimizing the energy consumption subject to a minimum e2e latency on RT traffic is specified as,

$$\begin{aligned} \begin{array}{lll} \varvec{(P1)} &{} Minimize &{} \varvec{E} \left( X \right) \\ &{} S.\,t. &{} \varvec{L_{RT}}(X) \leqslant L^{max}_{RT} \\ &{} Var. &{} X, \end{array} \end{aligned}$$

(25)

From the network energy $E^{DuoMAC}$ and the e2e latency functions on realtime traffic $L^{DuoMAC}(RT)$ defined by Eqs. (21,22), the optimization problem (25) becomes:

$$\begin{aligned} \begin{array}{lll} \varvec{(P2)} &{} Minimize &{} \left( \zeta _1 T_{cp} + \frac{\zeta _2}{T_{cp}} + \zeta _3 T_w + \frac{\zeta _4}{T_w} + \zeta _5 \right) , \\ &{} S.\,t. &{} T_{cp} \leqslant \frac{L^{max}_{RT} - \upsilon _2}{\upsilon _1}, \\ &{} Var. &{} T_{cp}, T_w \end{array} \end{aligned}$$

(26)

The solution of the optimization problem $\varvec{(P2)}$, $\left( T^*_{cp}, T^*_w\right)$, is derived in the following. The objective function of $\varvec{(P2)}$ is a function of two independent variables, $T_{cp}$ and $T_w$, where $\zeta _i$ and $\upsilon _i$ are positive constants. Let us denote the function by $f(x,y)$, which is in the form of: $\zeta _1x + \frac{\zeta _2}{x} + \zeta _3y + \frac{\zeta _4}{y} + \zeta _5$. This two-variable function has a global minimum at point $(x_c,y_c) = \left( \sqrt{\frac{\zeta _2}{\zeta _1}} , \sqrt{\frac{\zeta _4}{\zeta _3}}\right)$, which represents the solution of the system. Therefore, the global optimal parameters $(T^*_{cp},T^*_w)$ of DuoMAC are given by,

$$\begin{aligned} \begin{array}{llll} T^*_{cp}&{}= {\left\{ \begin{array}{ll} x_c = \sqrt{\frac{\zeta _2}{\zeta _1}} &{} if \,\,\, x_c \leqslant \frac{L^{max}_{RT} - \upsilon _2}{\upsilon _1},\\ \frac{L^{max}_{RT} - \upsilon _2}{\upsilon _1} &{} otherwise \end{array}\right. } &{}\,\,\,\,\,\,\,\,\,\,\,\,T^*_w &{}= y_c = \sqrt{\frac{\zeta _4}{\zeta _3}}\\ \end{array} \end{aligned}$$

(27)

5.2 Collection and dissemination

In DuoMAC, collection of network state information is achieved using data packet headers and the dissemination of new MAC parameters $T^*_w$ and $T^*_{cp}$ is realized using regular $B_w$ beacons exchange. First, the optimization is triggered periodically by the sink. It includes a start command in the $B_w$ beacon, which is propagated by each node to a connected children. Every node runs in one of the protocol operation modes (LDC or HDC) and forwards data packets from level $d_i$ to level $d_{i-1}$. When a node $n$ receives a $B_w$ beacon with the start command, it piggybacks its network state information $\mathcal {P}^n_{lq}$ in the data packet header. By receiving this information from all nodes, the sink is responsible of calculating and disseminating the new optimal MAC parameters ($T^*_w$ and $T^*_{cp}$) to all the network using $B_w$ beacons. The time of a complete optimization round depends on the necessary time to propagate the start command and receive the input information to and from all the nodes. The propagation of new parameters from the sink to all nodes necessitate $D\times T$, where T is the cycle duration and D is the network depth. We believe that despite the existence of many collection and dissemination mechanism like CTP [14] and Dip [19] that can be integrated, the choice of using the built-in packet exchange of DuoAMC is reasonable and will achieve better performance since it does not require any additional overhead, so no more energy is consumed.

6 Experimental performance evaluation

The protocol optimization is evaluated through an extensive set of experiments under the considered traffic and network model, using MicaZ platform. The optimized DuoMAC, termed in what follows DuoMAC*, has been compared with a non-optimized version DuoMAC (without parameter optimization module), and LL-MAC [34], which is shown to be the best candidate among other MAC protocols in the analytical comparison (Sect. 4) with respect to the energy consumption. The evaluation is carried out with both simulations using Avrora [1], which accurately emulates MicaZ, i.e. the AVR cycle execution and the RF CC2420 physical layer [4], and with experimentations on MicaZ real motes using a Testbed. The testbed contains 20 MicaZ motes placed on top of walls in several offices in our building as depicted in Fig. 13. The figure also shows the communication links between the deployed nodes. We point out, from the experiments performed, that the communication links have relatively high loss rates (up to 20 %). Every node acts as source and generates RT and NRT packets periodically, respectively with frequency $F_{RT}$ and $F_{NRT}$. Very low data rates are considered (0.32–20 packet/min) which is common in low data rate applications [18]. In the simulation, a grid topology as depicted in Fig. 4 is used, with maximum range of 15 m [1], and the unit disk with C = 8. The delay requirement of RT traffic was chosen according to the representative monitoring system, urban traffic monitoring, and set to $L^{max}_{RT}=1s$. Tables 1 and 2 sketch all the setup configuration of the considered network and traffic model as well as the typical parameter values for the CC2420 radio from [18]. In both simulation and experimentation, a phase of neighbors discovery and tree construction with a minimum hop-count routes, according to the network model of Sect. 4.1, is executed before starting experiments. Each experiment is repeated 30 times and each point in the following curves comes from the average result of all experiments, where bars are represented with 95 % of confidence interval.

Fig. 13

TestBed platform with MicaZ motes placement and communication links

6.1 Optimal parameters

First, the simulation results of the protocol optimization with parameter adaptation are presented. The RT and NRT traffic generation frequency has been varied from 0.32 to 20 pkts/node/min. The resulted optimal parameters are traced for different network sizes and diameters (D = 2, 3, 4, and 5). Figure 14(a, b) depict the optimal channel polling $T^*_{cp}$ and the optimal wake-up period $T^*_w$ parameters, respectively.

Fig. 14

a Optimized channel polling period $T^*_{cp}$ and b optimized wakeup period $T^*_w$ of DuoMAC for different network depths D: 2, 3, 4, and 5 and varying the RT traffic rate in [0.32–20] $pkts/node/min$

$T^*_{cp}$ and $T^*_w$ progressively decrease with the increase of traffic rate and have lower values for large networks (D = 4, D = 5) compared to small network diameters (D = 2, D = 3). This can be explained by the fact that the increase in NRT and RT traffic causes the increase of the node active period, which requires to imperatively lower the duration of $T_{cp}$ and $T_w$. On the other hand, it is obvious that the farther the node is from the sink (D = 4, D = 5), the more the wakeup period will be lowered to meet the delay requirement.

6.2 The e2e delay

Figure 15(a) shows the average e2e delay of DuoMAC*, DuoMAC, and LL-MAC for RT packets. These results are obtained using Avrora and by fixing the network size to $55$ nodes, and increasing the traffic rate from $0.32$ to $20$ packet/node/min. The resulted average e2e delay of DuoMAC*, DuoMAC, and LL-MAC for NRT packets is depicted in Fig. 15(b). The results show that the average delay decreases with the increase of the traffic rate, and that DuoMAC* outperforms DuoMAC with regard to RT traffic (about $79ms$ lower for RT and 1.06 s lower for NRT on average), and the difference is much more important when compared with LL-MAC for both RT and NRT traffic (2.4s in LL-MAC vs. 0.3 in DuoMAC, and 0.22 s in DuoMAC*, as average RT latency). This is due to the automatic decrease of $T_{cp}$ and $T_w$ periods. The same scenario was investigated in real motes using the TestBed, where the results are depicted in Fig. 16(a) for RT traffic, and in Fig. 16(b) for NRT traffic, respectively. Results confirm superiority of DuoMAC* regarding the delay reduction.

Fig. 15

The average e2e delay of a RT traffic and b NRT traffic obtained by DuoMAC*, DuoMAC, and LL-MAC when increasing the traffic rate using Avrora

Fig. 16

The average e2e delay of a RT traffic and b NRT traffic obtained by DuoMAC*, DuoMAC, and LL-MAC when increasing the traffic rate using TestBed

In a second scenario, traffic rate has been fixed to 20 pkts/min, and the average e2e delay is measured using Avrora, for different network depths (D = 2, 3, 4, 5). Note that this scenario cannot be tested in our testbed due to limitation in number of motes, which prevents construction of 4 and 5 levels networks. The resulted average delay for RT and NRT traffic is depicted in Fig. 17(a, b), respectively. It can be noted that the average delay increases with the network depth, and DuoMAC* delay is much lower than DuoMAC for RT traffic. The delay of DuoMAC* and DuoMAC gets close to each other for NRT traffic, for which there is no delay constraint. Both protocols clearly outperform LL-MAC. This confirms the results obtained in Sect. 6.1 and shows that DuoMAC* tunes adequately its parameters $T_{cp}$, and $T_w$, to meet delay requirements.

Fig. 17

The average e2e Delay of a RT traffic and b NRT traffic obtained by DuoMAC*, DuoMAC, and LL-MAC when varying the network depth (D = 2, 3, 4, and 5) with Traffic rate = 20 pkts/min

6.3 The duty cycle

The duty cycle of a node is defined as the ratio of the active time to the sleep time. It is obvious that the lower is the duty-cycle, the better is the performance of the protocol in terms of energy consumption. So in the following, energy consumption is expressed in terms of duty cycle. Protocols are compared using Avrora under a network configuration with 55 nodes and a maximum depth $D = 5$. We vary the traffic generation rate of RT and NRT from 0.32 to 20 pkts/node/min. The average duty-cycle of the network has been measured and the results are depicted in Fig. 18(a). Results demonstrate that the average duty-cycle of the network increases for DuoMAC* and DuoMAC compared to LL-MAC. This is because the later handles one packet per cycle, and does not make any adaptation for RT traffic, where the other protocols balance energy optimization and delay optimization to accelerate RT packets delivery. On the other hand, DuoMAC* achieves better energy reduction, about 2 % compared to DuoMAC. This is due to the accurate built-in parameter adaptation of DuoMAC*, where $T_w$ and $T_{cp}$ are set optimally. Figure 18(b) shows the average duty-cycle of experimental results using the TestBed. The aim of this experiment is to measure the energy consumption of the network when the RT frequency gets very low. The generation rate of NRT traffic has been fixed to 10 pkts/node/min and the RT rate has been varied from 10 pkts/node/min (equal to NRT rate) down to 0.16 pkts/node/min. It has been observed that the power consumption of DuoMAC and DuoMAC* is higher than that of LL-MAC, and it increases with the rise of RT rate. This is because these protocols run most of time in HDC mode to forward RT traffic and thus consume more energy. However, it is noted that DuoMAC* considerably reduces the energy consumption compared to DuoMAC. Figure 19 shows the analytical, the simulation, and the experiments results of DuoMAC obtained for (a) the e2e delay of RT, (b) the e2e delay of NRT, and (c) the energy when varying the sampling rates $\in (0.16, 10)$ pkts/min. The plots show how the analytical model fits quite well the simulations and are near the experimental results, confirming the conclusions drawn from the protocol modeling.

Fig. 18

The average Duty-cycle obtained by DuoMAC*, DuoMAC, and LL-MAC when a increasing the sampling rate from 0.32 to 20 pkts/min using Avrora and b fixing NRT traffic rate to 10 pkts/min and decreasing RT Traffic from 10 to 0.16 pkts/min using TestBed

Fig. 19

The results obtained from DuoMAC Protocol analysis, simulation, and experimentation for a the e2e delay of RT traffic, b the e2e delay of NRT traffic, and c the energy consumption when varying the sampling rate from 0.16 to 10

7 Conclusion

DuoMAC has been presented in this paper, a new MAC protocol with runtime parameter adaptation that targets applications with heterogeneous traffic. The proposed protocol assures energy efficiency and delay constrained data delivery by balancing energy-minimization with delay-minimization, and adaptively switching between two states according to the dominating traffic in the network. Such protocol can be used in monitoring system applications where sensed data of the monitored area must be delivered to the control center by satisfying the application requirements in terms of e2e delay and network lifetime. A comprehensive analysis has been performed to compare DuoMAC protocol against some state-of-the-art energy-delay efficient duty-cycled MAC protocols, respectively DMAC, LL-MAC, and Diff-MAC. The results rise that LL-MAC is the best candidate for energy consumption in all cases while DuoMAC uses to provide the lowest latency to realtime traffic (RT). The results of this analysis have driven the parameter optimization approach that has been integrated to the proposed protocol, where an energy/delay constrained optimization problem has been formulated, and runtime resolution has been proposed to accordingly derive the optimal parameters that nodes must tune-up with in order to achieve optimized performance, and satisfy the application requirements. The proposed optimization has been evaluated through simulations and experimentations on MicaZ motes. Results show that optimized version of the proposed protocols (DuoMAC*) is tunable and meets delay requirements, and it shows clear reduction of the delay over LL-MAC and the ordinary DuoMAC (with static parameters). The improvement has been for both RT and NRT traffic types. Both versions clearly outperform LL-MAC with respect to e2e latency. However, this gain in delay minimization comes at the cost of a moderate additional energy consumption when compared to LL-MAC due to the increase of the channel polling period needed to satisfy delay constraints on RT traffic, which inevitably rises the duty-cycling. In addition to delay improvement, DuoMAC* reduces the energy cost compared to DuoMAC and exhibits a good distribution of the radio duty-cycle, which enables to improve the network lifetime.

Appendix: MAC energy-delay models

In this section, the per node energy and e2e delay models is provided for DMAC, LL-MAC, Diff-MAC and DuoMAC protocols following the operation modes of each protocol. The selected MAC protocols are chosen as representative of families of synchronous and asynchronous protocols as mentioned in the related work.Terms appearing in equations are described in Table 2.

1.1 DMAC protocol

The DMAC [20] per-node energy and e2e packet delay are given by:

(a) The Energy of node n:

$$E^n = E^n_{tx} + E^n_{rx} + E^n_{dp}$$

(28)

where $E^n_{tx} = (T_{cs} + T_{data}) F^n_{out}$, $E^n_{rx} = \frac{T_{up} + 4 \theta T_{sync}/2 + T_{cw} + T_{data}}{T_w} + \frac{T_{cs} + T_{hdr}}{T_{sync}}$, and $E^n_{dp} = (F^n_I + |I_d|\frac{1}{T_{sync}}) (T_{up} + 2\theta T_{sync} + T_{cw} + T_{data})$.

(b) The delay of node $n$ at level $d^n$:

$$L^n = \frac{T_w}{2} + \varvec{ \sum _{i=1}^{d^n}} \left( \frac{4\theta T_{sync}}{2} + T_{cw}/2 + T_{data} \right)$$

(29)

where $T_{data}= T_{hdr} + P/R + T_{ack}$.

1.2 LL-MAC protocol

The LL-MAC [34] per-node energy and e2e packet delay are given by,

(a) The Energy of node $n$:

$$E^n = E^n_{tx} + E^n_{rx}$$

(30)

where $E^n_{tx} = (T_{cs} + T_{data}) F^n_{out}$ and $E^n_{rx} = \frac{T_{up} + 4 \theta T_w/2 + T_{cw} + T_{data}}{T_w}$.

(b) The delay of node $n$ at level $d^n$:

$$L^n = \frac{T_w}{2} + \varvec{ \sum _{i=1}^{d^n}} \left( \frac{4\theta T_w}{2} + T_{cw}/2 + T_{data}, \right)$$

(31)

where $T_{data}= T_{hdr} + P/R + T_{ack}$.

1.3 Diff-MAC protocol

The Diff-MAC [33] per-node energy and RT/NRT e2e packet delay are given by,

(a) The Energy of node $n$:

$$E^n = \frac{T^{NRT}_{cw} + T_{hdr}}{T_w} + \frac{T_{active}}{T_w} + \frac{T_{sleep}}{T_{ 0}} + 2\theta - \left( T_{data} - T_{hdr} - T_{up}\right)$$

(32)

(b) The RT and NRT delays of node $n$ at level $d^n$:

$$\begin{aligned} L^n(RT)&= \frac{T_{sleep}}{2} + \theta T_w + \frac{T^{NRT}_{cw} + T_{hdr}}{2}\nonumber \\&+ \varvec{ \sum _{i=1}^{d^n}} \left( \left( \frac{T^{RT}_{cw}}{2} + T_{data}\right) \frac{T_w}{T_{active}} \right. \nonumber \\&\quad +\left. \frac{(\frac{T^{RT}_{cw}}{2} + T_{data})^2}{T_{active}} \right) \nonumber \\ L^n(NRT)&= \frac{T_{sleep}}{2} + \theta T_w + \frac{T^{RT}_{cw} + T_{hdr}}{2}\nonumber \\&+ \varvec{ \sum _{i=1}^{d^n}} \left( T_{msg}\frac{T_w}{T_{active}} +\frac{T_{msg}^2}{T_{active}} \right) \nonumber \\ T_{msg}&= \left( \frac{T^{RT}_{cw}}{2} + T_{data}\right) F^n_I + \left( \frac{T^{NRT}_{cw}}{2} + T_{data}\right) \end{aligned}$$

(33)

where $T_{data}= 4T_{hdr} + P/R$.

1.4 DuoMAC protocol

• (a) HDC mode (RT traffic):

  In HDC mode [illustrated in Fig. 2(b)], the energy is divided into the energy spent (1) for periodic channel polling, $E_{cp}$, (2) for sending RT packets $E_{tx}$, (3) receiving RT packets, $E_{rx}$, and (4) overhearing background node’s RT packet transmissions, $E_{ovr}$. Before start sending strobes, a node checks for channel activity for $T_{on}$. The maximum number of strobes is $\lceil \frac{T_{cp}}{T_{rts} + T_{cl}} \rceil$, and the strobes’ transmission time is $\lceil \frac{T_{cp}}{T_{rts} + T_{cl}} \rceil \frac{T_{rts} + T_{cl}}{2}$ on average. At reception, a node receives half of the packet strobe before the first strobe packet, and a node turns off its radio for $T_{cl}$ between the strobes, to save energy. For the overhearing, the average number of channel polling during one packet transmission is $\frac{T_{tx}}{T_{cp}}$. A node, $n$, spends energy overhearing one strobe and a half to decode the identifier for all background node’s transmissions, $F_B$. This yields,

  $$E^n_{HDC} = E^n_{cp} + E^n_{tx} + E^n_{rx} + E^n_{ovr}$$

  (34)

  where $E^n_{cp} = \frac{T_{on}}{T_{cp}}$, $T_{tx} = \lceil \frac{T_{cp}}{T_{rts} + T_{cl}} \rceil \frac{T_{rts} + T_{cl}}{2} + T_{cts} + T_{data}$, $E^n_{tx} = \left( T_{on} + T_{tx}\right) .F^{RT}_{out}$, $E^n_{rx} = \left( \frac{3}{2}T_{rts} + T_{cts} + T_{data}\right) F^{RT}_I$, $E^n_{ovr} = \left( \frac{T_{tx}}{T_{cp}} \frac{3}{2}T_{rts}\right) F^{RT}_B$ For the e2e delay, the RT packet is delayed on average by half the channel polling period, $T_{cp}$. When accounting for the contention and the transmission time, an RT packet in DuoMAC has a maximum e2e latency of,

  $$L^n(RT) = \varvec{ \sum _{i=1}^{d}} \left( \frac{T_{cp}}{2} + \frac{T^{RT}_{cw}}{2} + T_{data} \mathcal {P}_{lq} \right)$$

  (35)

• (b) LDC mode (NRT traffic):

  As illustrated in Fig. 2(a), a node spends energy in this mode receiving or sending beacons and NRT packets, respectively $E_{rx}$ and $E_{tx}$, during $T_{recv}$ and $T_{send}$, respectively. This includes on one hand, the reception and the transmission of $B_w$ and $B_{nw}$ beacons, the reception of NRT input traffic, $F_I$, and on the other hand the transmission of NRT output traffic, $F_{out}$. Note that to receive a packet, a node remains in the receiving state for a complete time-slot $T_{slot}$. Due to the absence of explicit synchronization in DuoMAC, nodes are required to guard for a minimal beacon exchange, which corresponds to the wake-up time, $T_w$. The duration of the time-slot must cover the potential clock drift, which is proportional to the time since the last beacon. Consequently, the energy of node, $n$, is expressed by,

$$\begin{aligned} E^n_{LDC}&= E^n_{rx} + E^n_{tx} \nonumber \\&= \frac{T^{B_w}_{rx} + T^{B_{nw}}_{rx}}{T_w} + T_{slot}F^{NRT}_I + \frac{T^{B_w}_{tx} + T^{B_{nw}}_{tx}}{T_w}\nonumber \\ &\,+ (T_{data})F^{NRT}_{out}. \end{aligned}$$

(36)

where $T_{slot} = T_{guard} + T_{data}$, $T_{guard} = 4\theta T_w$, and $T_{data} = T_{hdr} + P/R + T_{ack}$. For the e2e delay, the NRT packet, on average, is delayed by half the wake-up period $T_w$, added to the parent’s receive period that includes the time to receive and send beacons, respectively $B_w$ and $B_{nw}$, as well as the time to receive NRT packets from the children nodes. A NRT packet in DuoMAC, when accounting for the contention and the transmission time of each data packet, has a maximum e2e latency of,

$$L^n(NRT) = \frac{T_{w}}{2} + \varvec{ \sum _{i=1}^{d^n}} T^{i-1}_{recv}$$

(37)

where $T^i_{recv} = T^{B_w}_{rx} + T^{B_{nw}}_{tx} + \left( \frac{T^{NRT}_{cw}}{2} + T_{data} \mathcal {P}_{lq} \right) \frac{F^i_{I,NRT}}{F_{NRT}}$. The $E_{rx}$ term in Eq. (34) does not depend on $T_{cp}$. Using the property $\frac{T_{cp}}{T_{rts} + T_{cl}} \leqslant \lceil \frac{T_{cp}}{T_{rts} + T_{cl}} \rceil \leqslant \frac{T_{cp}}{T_{rts} + T_{cl}} + 1$, and by taking the upper bound, Eq. (34) can be rewritten as,

$$\begin{aligned} E^n_{HDC}&= \frac{T_{on}}{T_{cp}} + \left( T_{on} + \frac{T_{cp} + T_{rts} + T_{cl}}{2} + T_{cts} + T_{data} \right) F^{RT}_{out} \nonumber \\&+ E^n_{rx} + \left( \frac{T_{cp} + T_{rts} + T_{cl} }{2T_{cp}} + \frac{T_{cts} + T_{data}}{T_{cp}} \right) \frac{3}{2}T_{rts} F^{RT}_B \end{aligned}$$

(38)

Eq. (36) of LDC becomes,

$$\begin{aligned} E^n_{LDC}&= \frac{ T^{B_w}_{rx} + T^{B_{nw}}_{rx} + T^{B_w}_{tx} + T^{B_{nw}}_{tx}}{T_w} \nonumber \\&+ \left( 4\theta T_w + T^{NRT}_{cw} + T_{data}\right) F^{NRT}_I + \left( T_{cs}+T_{data} \right) F^{NRT}_{out} \end{aligned}$$

(39)