1 Introduction

Wi-Fi network performance is known to degrade dramatically when node density is high, and when flows are sustained over multiple hops. These conditions arise when multiple networks coexist [10, 21] and when large access infrastructure is deployed [3, 17]. The degradation results from the starvation and unfairness associated with carrier sense multiple access (CSMA) based protocols. This is attributed to a mismatch in the local views of the wireless medium among the nodes, and due to high levels of contention when the network is congested [12].

To mitigate such problems several approaches have been proposed. These include adopting rate limiters on nodes [4, 7], using multi-hop reservations [16], using different access priorities for data and control traffic [8], and exploiting admission control [22].

Airtime measures the channel time in which a link is sensed busy because of frame transmissions. Airtime measurements are position-dependent, because channel attenuation differs for each transmitter-receiver pair. Airtime has been applied in routing in mesh networks [7, 9], and in admission control [18].

This paper makes two contributions. First, we use a measurement driven approach to control the airtime allocated to each node in a wireless network computed by the REACT protocol [19]. REACT negotiates airtime allocations among the nodes on the basis of traffic requirements and local views of the network. In order to achieve its allocated airtime we develop SALT, a mechanism for dynamically tuning the contention window of each node.

There has been much work on contention window tuning but with different objectives. Among the first may be MACAW [1], replacing the binary exponential backoff with a multiplicative increase and linear decrease (MILD) of the contention window (CW) size to improve fairness. Other work tunes the CW to achieve a theoretical throughput limit [6]. Our goal here is different: Our aim is to tune the contention window at each node to realize a specific airtime allocation.

REACT and SALT are both compatible with the 802.11 standard [15] and have been implemented on legacy devices. Extensive experimentation in the w.i-Lab.t wireless network testbed [5] shows that the tuning approach is able to align allocations to those negotiated.

The second contribution is an extension of REACT to reserve an allocation along the path of a multi-hop TCP flow. This requires that neighbours of the nodes along the forwarding path take the reservation into account as part of their own allocations so that they do not interfere with the multi-hop flow. Multi-hop wireless mesh networks present many challenges for TCP. In addition to the unreliable wireless transmission at each hop, contention from hidden and exposed nodes in a wireless network constrain the TCP throughput achievable over a multi-hop path [11]. To the best of our knowledge, Gupta et al. [14] is one of the few works conducting experimentation with TCP in a physical wireless network. However, their emphasis is on how TCP throughput is affected by routing, user mobility, and the number of hops in the network rather than on the impact of the MAC protocol. While no performance advantages for TCP were found in their results [14], we have achieved higher TCP throughput in running the flow over REACT combined with SALT, than over 802.11.

The rest of this paper is organized as follows. In Sect. 2, we describe the REACT protocol for negotiating channel airtime. Section 3 presents SALT, a new tuning algorithm, its implementation in legacy commercial Wi-Fi cards, and an evaluation of how well it achieves the airtime allocation. Section 4 provides an algorithm to reserve airtime for a multi-hop flow over the REACT/SALT framework and evaluates the algorithm using a multi-hop TCP flow. Finally, we summarize and propose future work in Sect. 5.

2 Realizing a REACT Allocation

REACT is a distributed resource allocation protocol that uses the metaphor of an auction [19]. When used in the context of mesh wireless networks, the resource being allocated (or put up for “auction”) is airtime, the percentage of time a node controls the medium over a given period. Each node runs an auctioneer and a bidder algorithm concurrently; auctioneers offer capacity while bidders claim capacity at adjacent auctions to satisfy their own airtime demand. Auctioneers update their offers to satisfy all nodes bidding at their auction while also ensuring that all nodes receive a fair allocation of the resource. Bidders update their claims to ensure that they are not consuming any more airtime than can be offered at any adjacent auction. Nodes participating in REACT converge to a lexicographic max-min airtime allocation [19]. A change in the local network view or traffic load triggers REACT to run and adapt the allocation.

Lutz et al. [19] realize the REACT allocation in a schedule-based MAC protocol, in which a number of transmission slots at each node are selected at random to correspond to its allocation. A node can recompute its schedule immediately upon receiving a new allocation from REACT, rather than waiting for the end of a frame, making it competitive with contention-based protocols. Their initial evaluation was conducted in simulation where synchronization is not a challenge.

Hence, Garlisi et al. [13] instead realize the REACT allocation in a contention-based MAC protocol. Because the channel access probability depends on the average contention window (CW) size [2], a node’s REACT allocation is realized by tuning the CW size. A legacy Wi-Fi node i can estimate its current allocation \(s_i\) as a function of the total number \(n_i\) of channel accesses it makes, the total time \(F_i\) that its backoff is frozen, and the total airtime \(A_i\) in an observation interval C:

$$\begin{aligned} s_i= & {} \frac{A_i}{C} = \frac{A_i}{A _i+ F_i + W_i/2 \cdot \sigma \cdot n_i} \end{aligned}$$
(1)

where \(W_i/2 \cdot \sigma \cdot n_i\) is an approximation of the total time required for the backoff countdown. This suggests how the contention window can be tuned.

3 REACT Implementation with SALT Tuning

Different from [13], rather than modify 802.11 packet headers, we send control messages to implement REACT periodically. The time period must be longer than the amount of time it takes to update bids and offers. With this method the overhead for control traffic does not increase when the data rate increases.

Our implementation of REACT is paired with a new contention window tuning approach, described next.

3.1 Smoothed Airtime Linear Tuning (SALT)

Smoothed Airtime Linear Tuning (SALT) is a new contention window tuning technique. As in [13], the contention window size is fixed unless and until a new airtime is allocated to node i by REACT. The intuition is that a node’s channel access behaviour should depend on its allocation, not on the packet outcome.

SALT measures airtime \(a_i^t\) at node i over observation interval t and uses it to set \(W_i^{t+1}\), the contention window size for the next interval \(t+1\). However \(a_i^t\) is not passed directly to the tuning component of SALT. Its value is first smoothed, using an exponentially weighted moving average in Eq. (2) with parameter \(0 \le \beta \le 1\), to produce \(S_i^t\) which is then used for tuning. Smoothing is done to reduce the effect of random background noise.

$$\begin{aligned} S_i^t= & {} \left\{ \begin{array}{ll} a_i^1 &{} \text { if } t = 1 \\ \beta a_i^t + (1 - \beta ) S_i^{t-1} &{} \text { if } t > 1 \end{array} \right. \end{aligned}$$
(2)

SALT’s tuning component is given in Eq. (3); \(s_i^t\) is the airtime allocation for node i from REACT, k is a constant scaling factor, and the maximum CW size is 1024. The difference between \(S_i^t\) and \(s_i^t\) is scaled by k to convert the difference of unit-less airtime ratios into a contention window size value.

$$\begin{aligned} W_i^t= & {} \left\{ \begin{array}{ll} 0 &{} \text { if } t = 0 \\ \lfloor S_i^t - s_i^t \rfloor k + W_i^{t-1} &{} \text { if } t> 0 \text { and } 0 \le \lfloor S_i^t - s_i^t \rfloor k + W_i^{t-1}< 1024 \\ 1023 &{} \text { if } t> 0 \text { and } \lfloor S_i^t - s_i^t \rfloor k + W_i^{t-1} \ge 1024 \\ 0 &{} \text { if } t > 0 \text { and } \lfloor S_i^t - s_i^t \rfloor k + W_i^{t-1} < 0 \end{array} \right. \end{aligned}$$
(3)

3.2 SALT Implementation

SALT is implemented as a Python program running at user level on each Linux testbed node in an experiment. It is part of the same program that is running REACT, and the airtime allocation is passed from the thread running REACT to the thread running SALT. The airtime measurement interval used is one second. SALT is invoked after each of these one second intervals and uses data collected by the networking subsystem to determine the airtime during the last interval.

The Linux kernel is modified to expose the minimum \(W_{min}\) and maximum \(W_{max}\) contention window size to user level programs. The interface allows a user level program to set these parameters; we set \(W_{min} = W_{max} = W_i^t\). The wireless subsystem is also patched to accept CW sizes that are not powers of two.

3.3 SALT Evaluation

To evaluate SALT, we use the IMEC advanced w-iLab.t testbed, located in Zwijnaarde, Belgium [5]. It is pseudo-shielded from external interference and is equipped with various wireless technologies, including IEEE 802.11, IEEE 802.15.4, Bluetooth dongles, Software Defined Radios (SDRs), LTE femto cells, among others. The w-iLab.t testbed uses the cOntrol Management Framework (OMF) for resource allocation, hardware and software configuration, and the orchestration of experiments. Measurement data are collected and stored in a central database over a wired control network for further processing.

Configuring wireless topologies in such an indoor controlled environment is important for benchmarking and for the reproducibility of the results. However, it is a non-trivial task, because the distance at which nodes are able to interfere can be much farther than the transmission range. In order to limit the physical visibility of the nodes, we use the 802.11a PHY, at the central frequency of 5180 MHz with a transmission power of 1 dBm.

Tests are conducted to identify “zotac” nodes among the more than 90 available to match the logical topologies in Fig. 1. Each node is programmed to send broadcast pings in a dedicated time interval when all the other nodes are silent. Nodes that can decode the ping (ICMP Echo Request and Response) are neighbours connected by a bidirectional link. At the end of these tests, we build the network topologies in Fig. 1; see [20] for more topologies. The physical location of the nodes in w-iLab.t is shown in Fig. 2.

Fig. 1.
figure 1

Logical testbed topologies used to evaluate SALT. Black lines correspond to bidirectional links while blue arrows denote single-hop flows. (Color figure online)

Full size image
Fig. 2.
figure 2

Logical topologies from Fig. 1 mapped onto physical nodes in w-iLab.t.

Full size image

In each topology, each experiment conducted uses greedy UDP flows. These flows are set up with a target 1 Gbps UDP bandwidth, far beyond the capabilities of the wireless link (i.e., the channel is saturated).

Experiments to Select the Values of \(\beta \) and k. In order to determine values for \(\beta \) and k in Eqs. 2 and 3, we conduct an experiment where we varied their values over their range; we vary \(\beta \) from 0.1 to 1.0 in steps of 0.1 and k from 250 to 5000 in steps of 250, making for 120 trials on each of the topologies. Each trial lasts 15 s and we measure airtime for each node in the trial over that time. The heat maps in Fig. 3 show the convergence results for each topology and each combination of \(\beta \) and k. The darker the square in the heat map the faster the trial converged. We average the convergence time for each trial on each topology for the same \(\beta \) and k and select the lowest average. This results in a \(\beta =0.6\) and \(k=500\), for the best average convergence time of 7.44 s; these values of \(\beta \) and k are used in all subsequent experiments.

Fig. 3.
figure 3

\(\beta \) versus k “heat maps” by topology. The darker the square in the heat map the faster the trial converged.

Full size image

3.4 Experiment to Compare Tuning Algorithms

We conduct an experiment to compare SALT and the original tuning algorithm [13], running along with REACT; 802.11 DCF is included as a control. The flows in this experiment are greedy UDP flows set up as described in Sect. 3.3.

We present the results for the star topology in Figs. 4 and 5 because they are representative; see [20] for more detail. Figure 4 plots airtime as a function of time. As expected, the airtime of nodes running 802.11 is unequal and highly variable for each node. In this topology, the allocation computed by REACT for each node is 20%. The original tuning algorithm converges more quickly than SALT but not as tightly. Moreover, each node running SALT oscillates around the allocated airtime whereas in the original tuning algorithm some nodes are unable to reach their allocated airtime of 20%.

Figure 5 plots per-node throughput, jitter, drop rate, and aggregate throughput for the star topology. The high variability in airtime for 802.11 is reflected in the per-node results: The throughput, jitter, and drop rates from node to node are also highly variable. The tighter convergence of SALT leads to the higher throughput and lower jitter than the original tuning algorithm. Both tuning algorithms have a near zero drop rate while 802.11’s drop rate is extremely high, well above 90% for three of the four nodes. Despite the high drop rate for 802.11, it still leads in aggregate throughput of 67.96 MiB; one node (zotacF4), which obtains around 60% of the airtime, is almost solely responsible for the higher aggregate throughput achieved. SALT has throughput of 55.57 MiB with the original tuning algorithm achieving 49.72 MiB.

Fig. 4.
figure 4

Airtime versus time for the star topology for 802.11, the original tuning algorithm, and SALT.

Full size image
Fig. 5.
figure 5

Per-node throughput, jitter, and drop rate for each of 802.11 (in blue), the original tuning algorithm (in green), and SALT (in red), in addition to aggregate throughput, for the star topology. (Color figure online)

Full size image

We now examine a more challenging multi-hop scenario.

4 Multi-hop REACT and Multi-hop Reservations

Until now, nodes running REACT have only taken into account their own traffic needs. In the auction a node’s bid secures airtime for itself, but if there are multi-hop flows in a network this is insufficient because it does not take into account the fact that a node might need to forward traffic ultimately destined to other nodes. We present a multi-hop airtime reservation protocol that addresses this issue.

Without a reservation algorithm a node could try to predict how much airtime to reserve for multi-hop flows passing through it. Nodes store each of their neighbour’s claims and could speculate how their demand should reflect the possibility of multi-hop flows. Unfortunately claims provide no information on the directionality of flows, multi-hop or not. A claim is sent to every node within broadcast range and only informs the receiver that the sender is currently expecting to utilize the amount of airtime claimed. Claims also do not tell a node anything about the demands of nodes beyond their one-hop neighbourhood, where the multi-hop flow could be originating. Multi-hop reservations allow the originators of multi-hop flows to inform nodes of the additional traffic they are expected to forward. Nodes along the reservation path can also inform the originator of resource saturation. The REACT auction itself is a convenient mechanism that can be used for the purpose of making these reservations.

Each auction in the REACT protocol allocates the channel capacity. In our multi-hop reservation algorithm, a reservation is made by reducing this capacity by the reservation amount at nodes along the path and at their neighbours. Once the reservation is placed nodes along the reservation path they each increase their allocation by the reservation amount. This secures airtime for the flows that will be passing through the node while still maintaining the standard REACT auction for allocating airtime in the neighbourhood. Section 4.1 provides a more precise description of this process and Sect. 4.2 presents our evaluation of it.

4.1 Multi-hop Reservation Algorithm

The Reserve algorithm is recursive, with parameters s, r and d, where s and d are the source and destination of the multi-hop flow, requiring a reservation of r. First, the source reserves r for the multi-hop flow. If it is unable, the reservation fails. If it is successful, then it requests each of its one-hop neighbours, except the next-hop along the multi-hop path, to reserve r for the multi-hop flow. If any neighbour cannot reserve r it returns failure, causing the reservation to fail and recursively release the reserved resources. However, if all neighbours succeed in making a reservation, then Reserve is called recursively with the source equal to the next-hop node along the multi-hop path. If the next hop is the destination, then the reservation has succeeded at each node along the path, and the success propagates back to the source of the multi-hop flow. The pseudocode for the Reserve algorithm is provided in Algorithm 1.

figure a

4.2 Multi-hop Reservation Evaluation

To evaluate the reservation process, experiments were conducted on the line topology with a multi-hop TCP flow. Figure 6 shows the line topology used with the multi-hop flow indicated in green. In the trials that used REACT, the TCP flow is started only after successful reservation along the path. In our experiments, we auction 80% of the channel, not 100%, leaving 20% for the control traffic; this is the same data/control traffic split used in [13]. The interior nodes of the line (e.g., zotacF4), must split 80% of the channel among three nodes (itself, and its previous and its next hop along the line). The reservation is placed for \(\frac{80}{3} \approx 26.6\%\) airtime, which is close to the maximum amount of airtime that can be reserved in this scenario, assuming no other traffic flows. The TCP flow lasts for 120 s in both the REACT and 802.11 trials. Multi-hop routing is static with each node having neighbour information before the flow starts.

Fig. 6.
figure 6

A three-hop line topology used in the multi-hop reservation experiment. (Color figure online)

Full size image

Figure 7 plots the airtime graphs for both REACT and 802.11 in the multi-hop scenario. The reservation of 26.6% airtime was placed after 0.9063 s and REACT converged after 9.041 s. Line topologies suffer both hidden and exposed node problems, with the airtime of 802.11 being highly unstable; in a multi-hop flow, the relatively high airtime of zotacF3 cannot help the throughput of the multi-hop flow. The more consistent airtime and lower jitter for REACT leads to higher TCP throughput over REACT than over standard 802.11. Specifically, 802.11 achieved throughput of 0.86 Mbps, while multi-hop REACT achieved 0.91 Mbps.

Fig. 7.
figure 7

Multi-hop TCP results: The airtime of 802.11 and of REACT with reservation over the life of the multi-hop flow, and the multi-hop TCP throughput.

Full size image

5 Summary and Future Work

A new tuning algorithm, SALT, converges more tightly to REACT’s airtime allocations, and tighter convergence leads to reductions in unfairness and jitter compared to 802.11 DCF. A new multi-hop reservation algorithm that leverages the airtime allocation and realization capabilities of this combination was proposed. With a reservation in place we have shown that REACT and SALT achieve higher throughput in a multi-hop TCP flow than in one that runs over 802.11 DCF.

There are several avenues of future work. To date, no real-world implementation of REACT handles nodes leaving an auction. This could occur if a node goes offline unexpectedly, or moves out of the range of the auctioneer. In simulation, Lutz et al. [19] used neighbour timeouts to determine when to evict nodes from the auction.

At present, SALT converges slowly. Perhaps combining SALT with the original tuning algorithm to leverage the lower jitter and faster convergence of each could be explored.

The reservation algorithm must be adapted to work with a dynamic routing protocol. This would likely require communication between REACT and the routing software.

All of these directions would contribute to the promising results of REACT with SALT to enabling fair, scalable mesh networks.