WING/WORLD: An Open Experimental Toolkit for the Design and Deployment of IEEE 802.11-Based Wireless Mesh Networks Testbeds

In designing a WMN, several issues, ranging from platform selection and node deployment to the selection of a suitable software framework for an efficient and useful testbed operation, must be carefully considered by the network engineer. It is worth noting that none of the aforementioned choices should be considered as the only driving factor in the testbed development. Instead, as we will see in the following sections, they all must be addressed as a coherent solution to a multitude of problems. The choices to be made during the platform selection phase heavily depend on research directions and reference application scenarios in terms of network type and size, expected users, and budget.

It is worth noting that processing power and storage space are hard constraints to both the services and the experiments that can be supported by the network. As a matter of fact, multiradio configurations can easily exceed the CPU capabilities of many embedded platforms especially if traffic forwarding is coupled with synthetic traffic generation. Moreover, a suitable storage space must be provided in order to collect measured data.

A wide range of OSes is available for the aforementioned hardware platform, ranging from open-source systems like all Linux variants and *BSD to commercial real-time solutions. Since no currently available software platform may be considered as the final solution for wireless mesh networking, an open-source OS, which makes available the source code under terms that allow modification and redistribution, is therefore the optimal choice to speed up research and prototyping. Linux-based OSes are available for the most important embedded platforms. However, it is worth noting that, albeit these OSes may be very similar to the Linux distributions available on common PCs, the available software packages and the userspace tools and utilities may differ significantly due to both CPU-specific requirements and system resources constraints.

There are three primary components that influence the routing framework: (i) the protocol architecture, (ii) the routing scheme, and (iii) the software implementation. Routing can be either provided at level three of the ISO/OSI networking stack as modification of the standard IP protocol or by adding an interposition layer between the Data Link Layer and the Network layer. In the latter solution (usually referred to as Layer 2.5 routing), the multihop backhaul is transparent to the upper networking stack, making the WMN appears just as another Ethernet link. On the other hand, such an approach introduces additional encapsulation and processing overhead as a result of, respectively, the header and checksum required by the interposition level. This implies a slight degradation in overall performance, in terms of both throughput and latency. Due to the large availability of routing protocols originating from the MANETs research, Layer 3 routing has been the most popular solution in the earlier WMN implementations. Solutions based on Layer 2.5 routing started mushrooming soon after in both academic and private research institutes (MIT Roofnet and Microsoft MCL are the two most notable precursors). Nowadays, we are observing an increasing trend from commercial vendors toward Layer 2 routing. Such an approach is however typically based on proprietary hardware/software solutions. The authors advocate for Layer 2.5 due to both its enhanced scalability and network stack transparentness.

WMNs share a number of features with ad hoc networks [10]. In particular, WMNs are characterized by self-organization and self-healing capabilities and exploit multihopping to build a wireless backhaul for delivering Internet connectivity to end-users. As a result, many routing protocols developed for Mobile Ad hoc Networks (MANETs) have been adapted to fit the mesh environments. However, as opposed to the MANETs paradigm, research efforts in the WMN community focused on network scalability rather than mobility. As a result, particular attention has been devoted by the academic community to the introduction of novel routing metrics capable of taking into account wireless channel characteristics [11] and to multiradio/multichannel architecture capable of increasing the overall network capacity [12].

Parallels activities aim at addressing the WMNs scalability issues by employing frequency agile/cognitive radios, dynamic spectrum access, and clustering algorithms. In [13] the authors propose the COMNET framework. COMNET exploits intelligent frequency-shifting self-managed mesh network in order to implement dynamic spectrum sensing and management techniques allowing radios to use frequencies other then those located in the ISM bands. Additionally, in [14] a novel cluster-based middle-ware is proposed. The proposed solution significantly reduces the bandwidth use within the wireless mesh backbone by introducing a clustering service and an adapter. The former builds and maintains clusters of nodes; the latter acts as interface with the applications. However, all these advanced wireless radio technologies and architectures require a revolutionary approach to the communication protocols' design in order to reduce congestion, eliminate potential bottlenecks links, and eventually facilitate the commercialization of WMNs.

Routing protocols are typically generally classified as proactive, reactive, and hybrid. Proactive protocols maintain a list of all destinations and routes while reactive protocols discover routes on-demand when a packet needs to be forwarded. Such a behavior makes proactive routing less suitable for WMNs or in general for networks characterized by low-churn rates (number of nodes that leave the network during a specified time period divided by the average total number of nodes over that same time period). It is the authors' standpoint that on-demand route discovery can result in much less traffic than the standard proactive approach, especially when innovative route caching schemes are employed.

Several proactive and reactive routing protocols are already available for deployment over a WMN. Their implementations differ by code maturity, license, and degree of modification to the standard networking stack. In such a context, moving the routing logic from kernel-space into user-space libraries offers considerable advantages in terms of both faster development cycle and easier debugging at the expense of performance reduction. Due to such considerations, many academic research prototypes exploit routing protocol implementations running in the user-space.

Mesh routers are built exploiting three different types of processor boards, namely, the PCEngines ALIX 2C2 (500 MHz x86 CPU, 256 MB of RAM) processor board, the PCEngines WRAP 1E (233 MHz x86 CPU, 128 MB of RAM) processor board, and the Gateworks Cambria GW2358-4 (667 MHz ARM CPU, 128 MB of RAM). Operating system and application are stored on a 1 GB Compact Flash card for the PCEngines platforms and on the 32 MB embedded flash memory for the Gateworks platform (in this case a 4 GB Compact Flash is used to provide additional storage). It is worth noting that the full WING/WORLD firmware including development and testing tools (traffic generator, loggers, etc.) requires about 16 MB of storage space. A stripped down version of the firmware without development and testing tools requires less than 4 MB of storage.

Connectivity is provided by 2 Ethernet channels, 2/4 miniPCI slots, (PCEngines/Gateworks) and one serial port. PCEngines ALIX/WRAP boards are equipped with two Mikrotik R52 WiFi IEEE 802.11a/b/g cards based on the Atheros AR2412 chipset. Gateworks boards are equipped with two Ubiquiti SR71-A WiFi IEEE 802.11a/b/g/n cards based on the Atheros AR9160 chipset. On the PCEngines platform, one interface builds and maintains the multihop wireless backhaul, while the other interface can be configured either in Client or in Master mode. The former configuration allows the node to share an already available WiFi connection with the entire WMN while the latter configuration is used to provide a standard IEEE 802.11 Access Point. Single interface setups are also supported; however, in this case the device acts as a pure relay node. Dual and single NIC nodes can coexist in the same network. On the Gateworks platform, both interfaces are used to build and maintain the multihop wireless backhaul implementing a true multiradio/multichannel WMN exploiting dynamic channel assignment. An additional WiFi interface can also be used to provide Internet connectivity to the network. Finally, platforms with USB support (PC Engines ALIX and Gateworks Cambria) can be equipped with a cellular modem allowing the entire WMN to exploit a UMTS/GPRS network as a gateway link to the Internet.

Being based on the x86 architecture, the PCEngines boards (similar systems are provided by Soekris Engineering) deliver high flexibility in terms of choice of components while at the same time providing us with platform suitable for real-world deployments in terms of both maintenance costs and expected performances. Moreover, no cross compilation is required and standard development tools and OSes can be used. On the other hand, the Gateworks boards deliver higher performances and support up to miniPCI wireless adapters enabling effective multiradio/multichannel deployments.

The selection of the Wireless NIC to be deployed in our testbed has been driven by the need to configure and control as many low-level (physical) parameters as possible. The selected Atheros-based Wireless NICs allow to control parameters such as transmission bit-rate, carrier sense thresholds from userspace and provide transmission feedback for unicast frames which are not successfully delivered. Moreover, raw 802.11 frames are exposed by the driver, allowing to control most of the node's functionality at the application level; for example, it is possible to get per-packet signal and noise readings and to send broadcast frames at arbitrary rates.

OpenWRT [16] has been selected as Operating system for our testbed. OpenWRT is a minimalist BusyBox/Linux distribution released under a GPL license [17]. It provides an automated system for downloading the source code for both the kernel and the userspace tools, and compiling it to work on any supported platform. Moreover, it is characterized by a small memory and disk footprint making it suitable for a wide rage of networking devices. Finally, it provides hardware configuration and maintenance abstraction through a custom system and package configuration facility called UCI (Universal Configuration Interface) and exploiting MIB-like structure in order to streamline device management using SNMP [18].

It is worth noting that, being based on the x86 architecture, the PCEngines processor boards do not require, in principle, cross-compilation; however, we decided to use OpenWRT in order to abstract from the underlying hardware architecture making the WING/WORLD toolkit a platform-agnostic solution for wireless mesh networking. As a matter of fact, OpenWRT proved to be the most effective "glue" between heterogeneous hardware and software requirements.

The overall software architecture is sketched in Figure 2. As it can be seen from the picture, the node supports multiple backhauling technologies (Wired, WiFi, and UMTS). The software can seamlessly switch from one backhaul link the the other. However, due to the use of Network Address Translation (NAT) techniques at the mesh gateway, existing connections exploiting stateful protocols, such as TCP, are terminated when the backhaul link is switched. Likewise end-users applications that rely on NAT traversal techniques in order to implement client-to-client communications (e.g., peer-to-peer and VoIP) cannot survive the transition and are bounded to drop their active connections. It is worth underlying that, such a behavior derives from the joint use of NAT and network masquerading (or IP masquerading). This technique allows the network administrator to "hide" an entire address space (typically private network addresses) behind a single IP address (typically a public address). If on one hand such a technique allowed to tackle the exhaustion of IPv4 address space, on the other hand hosts behind NAT-enabled routers do not have end-to-end connectivity, which in time breaks the operations of stateless protocols such as UDP or hinder the services that require the initiation of TCP connections from the outside network.

The above mentioned issues are typically addressed using a variety of NAT traversal protocols. NAT traversal is a generic term used to identify techniques that establish and maintain TCP and/or UDP connections across NAT gateways. The general goal of a client implementing a NAT traversal protocol is to know its own external address (i.e., the address behind which the local address space has be hidden). The client can then start the communication by advertising its external NAT address to its peers, rather than the masqueraded (local) address that is not reachable for its peers on the public network. However, NAT traversal techniques are not designed to handle dynamic network egress points, as a matter of fact, a client has no way of notifying its peers that its external address has changed. Possible solutions involve modifying currently used NAT traversal protocols (e.g., Session Traversal Utilities for NAT [19]) in order to support dynamic network egress points or implementing a Mobile IP architecture in order to allow end-users' client to roam across different public networks. Both approaches are highly invasive and as such are out of the scope of this work.

Routing software is implemented using the Click modular router [20]. A Click router is built by assembling several packet processing modules, called elements, forming a directed graph. Each element is in charge of a specific function such as packet classification, queuing, and interfacing with networking devices. Click comes with an extensive library of elements supporting various types of packet manipulations. Such a library enables easy router configuration by simply choosing the elements used and the connections among them. Finally, a router configuration can be easily extended by writing new elements. The Click modular router is available as both Linux Kernel Module and user-space driver, allowing straightforward porting of a user-space implementation to kernel-space. Mesh routers uses the Click software router toolkit for route/gateway discovery, packet forwarding, and to implement a DiffServ-like traffic differentiation architecture. These features are sketched in Sections 3.3 and 3.4, respectively, while details about the modular gateway architecture (left hand block) and the multiradio mesh backhaul (right hand block) are given in Section 4.

The WING/WORLD toolkit is built on top of the Roofnet platform. Roofnet is an experimental WMN developed by the MIT. The Roofnet architecture is described in detail in [21]. Roofnet routes packets using a DSR-like routing protocol called SRCR exploiting the Estimated Transmission Time (ETT) as routing metric [22] and optimized for network scalability and throughput rather than for supporting mobility. The ETT metric aims at estimating the amount of time required to transmit a packet over a wireless link (including retransmission). The ETT metric is computed as follows:

where is an estimate of the highest effective throughput achievable in the forward direction, and is the delivery probability of the ACK signal in the reverse direction ( ). Since is the estimated throughput of broadcast packets in the forward direction at the transmission rate of Mb/s, the parameter can be computed as follows:

where is the link delivery probability in the forward direction. In order to compute the forward ( ) and reverse ( ) link delivery ratios, each node periodically broadcasts a sequence of five probes: one short probe aimed at modeling the ACK transmission and one long probe for each available transmission rate (broadcast frames are not acknowledged nor retransmitted by IEEE 802.11 devices). Each node keeps track of the number of probes received during an observation window . At any time, is then given by.

Note that is the number of probes received during the observation window , and is the number of probes that should have been received. Finally each probe sent by a node contains the number of probes packets received by the same node from all its neighbors during the last observation window. Such a design choice allows the receiver to compute the forward delivery ratio toward the node from which the probe was originated. Using two probes to estimate data and ACK delivery ratios separately allows the routing layer to properly model asymmetric links and to cope with the hidden node phenomena. In fact, probes lost at the receiver side due to interference are taken into account during the computation at the transmitting side by exploiting the information piggy-backed into each probe.

The default Roofnet implementation has been extended with additional modules responsible for QoS management. These enhancements are described in detail in [23‐25]. For readers' convenience, a brief overview of their main features is provided in the next section.

The WING/WORLD toolkit implements a traffic prioritization scheme based on the DiffServ [26] framework in order to allow classification and differentiated treatment. Network traffic entering a mesh router is classified by DSCP code and then fed to a suitable queue. Traffic differentiating is provided by means of a Deficit Weighted Round Robin (DWRR) scheduler which pulls packets from buffers, according to some input weights (see Table 1).

Each buffer maintains a pool of queues and a hash table that associates the MAC destination addresses with one of those queues. Incoming MAC frames are first classified according to their destination address and then fed to the corresponding queue. If such a queue does not yet exist, it is created dynamically by the scheduler. Unused queues are moved from the hash table to the pool. This is done in order to alleviate the need for repeated memory allocation as neighbors come and go. Within each buffer, two different link scheduling policies are supported by the system:

The presence of a backhaul technology represents one key differentiation points between WMN and the traditional MANET paradigm. The term backhaul is generally used [2] to identify a technology in charge of forwarding the traffic from the originator node to an external network (i.e., the Internet). The WING/WORLD nodes can automatically detect if they are relays or mesh gateways. A mesh node autoconfigures itself as gateway if an IP address can be obtained using DHCP over one of its backhaul links and if a list of well-known Internet addresses can be reached. At the present moment, three different backhaul technologies are supported.

In the current implementation, only one backhaul link can be active at a given time; however, different mesh gateways can exploit different backhauling technologies providing the testbed with an increased resiliency to network failures. It is worth noting that using more than one backhauling technology at the same time would not increase the network performances in that the typical bottleneck in a WMN lies at the last hop toward the mesh gateway whose capacity is at least an order of magnitude smaller than any of the available backhauling technology (with the sole exception of the UMTS backhaul which is to be considered anyway as a backup solution).

The wired interface takes precedence over both wireless technologies, while the WiFi backhaul takes precedence over the cellular link. A Finite State Machine (FSM) has been implemented in order to properly handle the backhaul's configuration without having either to reboot the node or to disrupt the normal network operations (Figure 3). Each backhaul technology is associated with a state. Additionally, the FSM defines the following states.

The specification of the FSM is provided in Table 2 as State Transition Table (STT). The vertical dimension indicates the current state; the horizontal dimension indicates possible events; the row/column intersections contains the next state if an event happens and the actions to be performed when the state transition occurs. Please note that PlugNode is an event that comes from the external world (i.e., powering up the mesh node). Here follows a description of all the possible events.

Two distinct actions can be linked to a state transition: Start Gateway and Start Relaying. The former action sets the backhaul link associated with the new state as the default route to the Internet; moreover, the node starts advertising itself as candidate gateway for the mesh network. The latter action disables the current backhaul link and use the multihop wireless backhaul as default route to the Internet.

The performances of the self-configuring and self-healing backhauling technology have been assessed through a series of experimental tests aimed at modeling different kinds of failures that can happen at a WMN's gateway. The reference network configuration is sketched in Figure 4. Internet connectivity is provided to the WMN by the New Delhi mesh gateway. The Rome desktop provides services such as DHCP, Radius, and PBX (Private Branch exchange). Finally, the Quito laptop acts as end-user's device exploiting the standard WiFi Hotspot provided by the Alix 6 mesh router. The network implements a three-tiers architecture [2] where traffic generated my end-users (first tier) is relayed to the destination by the mesh backbone (second tier). Internet-working with external networks (i.e., the Internet) is provided by dedicated nodes called mesh gateway that can exploit aforementioned backhauling technologies (third tier).

The target of the measurement campaign carried over the WING/WORLD testbed aimed at evaluating the time spent by mesh gateway to switch to another backhauling technology when the current one is experiencing service outages as well as to revert to the original configuration when connectivity has been restored. In order to do so, the following steps have been undertaken.

Switching time has been evaluated in two different scenarios. In the former one, end-users' Internet connectivity has been assessed by continuously pinging a remote host (http://​www.​google.​com/​) from Quito. Ping period has been set to 200 ms. In the second scenario, a synthetic traffic flow has been generated from Quito to Rome. The traffic flow has been modeled according to the parameters of the G.729.3 codec [29], a widely used VoIP codec. The G.729.3 VoIP codec generates 33 pkts/s; each packet contains 3 voice samples (10 bytes each) producing a final bit-rate of 8 kbits/s. All measurements are averaged over 10 runs.

The results of the first scenario are reported in Figure 5. The average Round-Trip-Times (RTTs), estimated using the ping command, are 50.2 ms, 51.7 ms, and 167.8 ms, respectively, for the Ethernet, WiFi, and UMTS backhauls. Confidence intervals are smaller than 2 ms over either backhaul links.

The results of the second scenario are reported in Figure 6 and summarized in Table 3. As it can be seen from the picture, a transition that is the result of a service disruption (Ethernet Wireless, Wireless UMTS, and Ethernet UMTS) requires a longer switching time than a transition that is reverting the backhaul, to its original configuration. The reason for this behavior lies in the fact that in the former case, about 6 seconds are spent by the mesh gateway to negotiate its IP address with the DHCP server. Moreover, in the transition to the UMTS backhaul a considerable amount of time is spent in the PPP negotiation phase with the UMTS carrier. On the other hand, in restoring a backhaul link, the mesh gateway can first complete the IP negotiation phase and then it can switch its default route to the new link.

The WING/WORLD toolkit can exploit multiple radios per mesh router, allowing simultaneous transmissions and reducing intrapath interference by tuning the mesh radios on non-overlapping channels. The Interference and Traffic Aware Channel Assignment (ITACA) algorithm has been developed in order to both assign the channels efficiently by taking into account the effects of traffic and interference patterns and to maintain topological connectivity. ITACA uses the Channel Assignment Server (CAS), which can be colocated with the mesh gateways, as a central node to collect information from the network and to assign channels to each radio interfaces. The objective of the CAS is to minimize the interference between mesh routers, and also to minimize the interference between the mesh network and other colocated wireless networks. It adopts a hybrid approach in assigning channels, combining pseudostatic default channel assignment, and dynamic channel assignment. It is worth noting that our approach ensures that channel assignment does not alter the network topology by mandating that one radio on each mesh router must operate on a default channel.

ITACA assigns channels considering both interference and traffic distribution. When traffic is homogeneously distributed among all nodes, ITACA assigns channels starting from the gateway, selecting links with the best metric. This approach is not optimal in case of traffic that is not homogeneously distributed among all nodes. In order to address such case, we consider the coefficient of variation of the aggregated traffic crossing each link. If this coefficient is greater than a threshold ( % in our implementation), we give higher priority to links transmitting more data while assigning channels. Otherwise, if the coefficient is smaller than the threshold, our scheme sorts links considering only interference information, thus giving higher priority to links emanating from the gateway and going toward the edges of the network. A multiradio conflict graph model [30] is used to estimate and model the interference within the network and also between the network and other colocated wireless transmitters. The Coefficient of Variation ( ) is defined as the ratio between the standard deviation ( ) and the mean value ( ):

where mean value ( ) and standard deviation ( ) are respectively defined as:

The ITACA algorithm is being currently evaluated over the WING testbed to assess performance and the effectiveness of the channel assignment strategy with respect to the operation of the mesh network. The ITACA algorithm has already been implemented and tested using the NS-2 simulator [31]. Figure 7 shows the observed performance improvement of ITACA with respect to a dynamic channel assignment algorithm, BSF-CA [32]. Results are averaged over runs. From the figure, it can be observed that ITACA outperforms BSF-CA scheme with respect to throughput and channel assignment delays. The simulations were carried out considering the presence of external network interference. The simulation details and the network models are presented in [30]. The multiradio extensions and the ITACA algorithm, implemented in NS-2, are available for public use at the WING community website [8].

WMNs are known to be susceptible to the "IEEE 802.11 performance anomaly" [33] which refers to sudden performance drops that occurs when nodes transmitting at low bit-rates due to poor channel conditions capture the wireless medium for longer periods of time at the expense of nodes transmitting at higher bit-rates. Intracell airtime fairness is provided in the WING toolkit by the Airtime Deficit Round Robin (ADRR) link scheduling discipline. ADRR enhances the Deficit Round Robin (DRR) discipline by taking into account the channel quality which in time prevents a node affected by high-packet loss from monopolizing the wireless channels thus lowering the performance of the whole system. It is worth underlining that ADRR does not require modification to the standard IEEE 802.11 MAC and can be readily implemented using off-the-shelf components. Figure 8 depicts the main building block of the ADRR scheduler.

The scheduler maintains a linked list of currently backlogged queues. Each queue is associated with a counter, called Deficit Counter, that indicates the amount of resources the link can use in a round. At each round, the deficit counter of the currently visited queue is increased by a fixed quantity called Quantum. The ADRR scheduler only serves packets whose expected transmission time is smaller than the deficit counter. The expected transmission airtime for a packet bytes long is given by.

where is the the link metric and is the size of the probe used to compute it. Basically the transmission airtime is the link's metric linearly scaled in order to take into account the size of the packet being transmitted. As a matter of fact, given a certain bit error rate and assuming the errors are i.i.d. (after decoding), a longer frame has a higher probability of getting corrupted and thus will require a longer transmission time. After a packet is sent, the deficit counter is decreased by the expected transmission time of the transmitted packet. A frame whose transmission time exceed the deficit counter is held back until the next visit of the scheduler. Empty queues are removed from list of currently backlogged queues and their deficit counter is set to zero.

Measurements carried out over the WING/WORLD testbed proved the capability of the ADRR scheduler to provide performance isolation in IEEE 802.11-based WMNs. Network topology is sketched in Figure 9(a). In particular, nodes number 2, 3, and 4 are fed with a CBR connection generated at node number . We have modeled each CBR connection as a single UDP stream with constant inter-departure time (2 ms) and packet size (1460 bytes) producing a final bit-rate of  Mb/s.

Measurements have been carried out exploiting three deployments scenarios differentiated by the channel condition experienced by nodes number . Notice that in each deployment all nodes are in radio range. However, while node number and are kept close to the gateway, node number is positioned in such a way to experience channel condition raging from Good to Poor with an intermediate Medium quality.

Tables 4 through 6 summarize the outcomes of our measurements campaign. Results show that the proposed scheduler is capable of addressing the "IEEE 802.11 performance anomaly" maintaining a high throughput over reliable links (Node number 3 and 4) as opposed to both the FCFS and the DRR policies that fail to achieve performance isolation when node number 2 starts to experience poor channel conditions.

As is shown in Table 4, when channel condition for node number 2 is still good, the available resources are evenly shared among all the nodes. However, it is worth noting that the average throughput achieved by each node using the ADRR is slightly higher than the throughput achieved using both the FCFS and the DRR scheduling disciplines.

We postulate that the ADRR scheduler is capable of exploiting channel fluctuation by opportunistically allocating more airtime to links that experience better channel condition. We recall that the feedback mechanism embedded in the routing metric gives the transmitting station (Node 1 in our case) the capability to schedule for transmission links experiencing better channel conditions. Such considerations are supported by the theoretical finding in [34] where channel fluctuations are exploited by transmitting information opportunistically when and where the channel is strong.

As node number 2 moves away from the gateway (Tables 5 and 6), the ADRR is capable of allocating more resource to the nodes experiencing better channel conditions, while the other scheduling policies degrade the aggregated throughput. In the extreme case where node number experience poor channel condition, ADRR outperforms both FCFS and DRR by delivering a higher aggregated throughput (1.1 Mb/s w.r.t. the baseline scenario) and by allocating to nodes number 3 and 4 a percentage of the bandwidth which is only slightly lower than the optimal case.

In order to increase the performances of the WING testbed, we implemented a packet aggregation technique capable of reducing the overhead due to both protocol headers and the channel contention by concatenating several MAC Service Data Units (MSDUs) to form the data payload of a large MAC Protocol Data Unit (MPDU). Such packet aggregation scheme leverages the channel probing functionalities of mesh routers in order to compute the optimal saturation burst length. The building blocks of the Aggregation Buffer and their relationships are sketched in Figure 10.

Incoming MAC frames are first classified according to their destination address and then fed to a different queue. For each queue, an A-MSDU is generated when either an aggregation timer is expired or a burst of optimal length can be generated. The ETT metric is exploited as a cross-layer technique in order to match link layer parameters with our adaptive traffic aggregation policy.

Aggregation and deaggregation are performed at each hop. Albeit such an approach could lead to increasing delays as the number of hops increases, we postulate that, at intermediate nodes, medium access delay is sufficient to collect enough packets so that burst generation is triggered by the optimal frame length without incurring in any aggregation delay. In our measurement settings, each mesh node sustains the same traffic, consisting in an increasing number of VoIP sessions plus an additional background traffic modeled according to a TCP socket working in saturation regime. Streams configuration is sketched in Figure 9(b) where VoIP bundles and TCP flows are represented respectively by dashed and solid lines. Each VoIP call has been emulated as single UDP stream modeled according to the parameters of the G.729.3 codec [29]. A typical VoIP source tends to transmit a large number of packets with a small payload, and such a combination is known to lead to large transmission overheads [35] in that a considerable amount of time is wasted in the contention phase and in sending headers and acknowledgments.

The outcomes of the measurements campaign are reported in Figure 11. As it can be seen from the figure, our adaptive aggregation policy provides almost a factor performance increase, since the number of sustained sessions reaches , whereas the plain IEEE 802.11 protocol allows for just 8-9 VoIP sessions.

End-users access to the WING/WORLD testbed is performed through a captive portal. Captive portals leverage a common web-browser as a secure authentication device, which in time delivers service providers with a standard mean to extend their hotspot coverage using WMN technology while maintaining well-established Authentication, Authorization, and Accounting (AAA) practices.

A captive portal forces an HTTP client on a generic network to see an authentication page before using the Internet normally. In order to achieve such a goal, a captive portal must intercept all packets, regardless of address or port, until the user opens a browser and tries to access the Internet. At that time the browser is redirected to an authentication page. The captive portal authenticates the end-user using against a centralized users directory using a suitable protocol. In our case, the RADIUS [36] protocol has been chosen to provide centralized AAA management for end-users. The main building blocks that compose a captive-portal-based end-users access management system are shown in Figure 12.

As the result of a successful authentication the captive portal will update the users directory with the details about the newly authenticated user (MAC/IP address, login time, etc.) and will grant its IP address with the right to access the Internet. Additionally, the captive portal can also set QoS routing rules so that they get provisioned a certain amount of bandwidth or cap to the amount of data transfered.

CoovaChilli [37] has been chosen as wireless LAN access point controller. It supports web-based login (through a captive portal), which is today's standard for public HotSpots, WISP "smart-client" authentication, and it supports Wi-Fi Protected Access (WPA and WPA2). FreeRADIUS [38] is a high-performance and highly configurable RADIUS server. It supports many database back-ends ranging from flat-text files, up to RDBMS and LDAP servers. It also supports many authentication protocols such as PAP, CHAP, and so forth.

It must be underlined at this point that the opportunity to provide access to a general audience people to the WMN infrastructure is a critical point for a testbed, since it enables to offer a realistic load to the network and to capture feedback on the users' perceived quality of the considered architecture (this last version currently under implementation).

As the result of a successful authentication, the captive portal will update the users directory with the details about the newly authenticated user (MAC/IP address, login time, etc.) and will grant its IP address with the right to access the Internet. Additionally, the captive portal can also set QoS routing rules so that they get provisioned a certain amount of bandwidth or cap to the amount of data transferred.

The Mesh Connectivity Layer (MCL) is an experimental Microsoft Windows driver developed by Microsoft Research and released under a Shared Source License. MCL implements an interposition layer between layer 2 (the link layer) and layer 3 (the network layer) of the standard ISO/OSI model. It is sometimes referred to as layer 2.5. To the higher layers, MCL appears to be just another Ethernet link, albeit a virtual one. To the lower layers, MCL appears to be just another protocol running over the physical link. MCL routes using a modified version of DSR [39] called MultiRadio Link Quality Source Routing (MR-LQSR) [22]. LQSR assigns a weight to each link. This weight is the expected amount of time it would take to successfully transmit a packet of some fixed size on that link. In addition, the channel, the bandwidth, and the loss rate are determined for every possible link. This information is sent to all the nodes. Based on this information, LQSR uses a routing metric called Weighted Cumulative Expected Transmission Time (WCETT) to define the best path for the transmission of data from a given source to a given destination. Channel assignment is static and must be performed manually by the network designer.

An extension to MCL, featuring distributed channel assignment (DCA-MCL in the comparison table), is proposed in [40]. The distributed channel assignment scheme proposed by the authors selects channels that are least used by each node's neighbours. No common channel is used in order to keep the network connected. The algorithm does not need a common signaling channel to keep the network connection. The protocol has been implemented and tested over a 14-nodes testbed. Routes are selected using the MR-LQSR routing protocol using the WCETT metric, a routing metric designed to select channel diverse path in multiradio environments.

Hyacinth is a multichannel WMN developed by the Experimental Computer System Lab at the Stony Brook University (New York) and built using off-the-shelf components. Each Hyacinth node is equipped with multiple IEEE 802.11 radios operating in ad hoc mode. Internetworking with mobile stations is made possible by a traffic aggregation device embedded in each mesh node. Each WMN nodes interacts with individual mobile stations through the traffic aggregation device and is responsible of assigning mesh-wide unique IP addresses to the mobile stations. A joint centralized channel assignment and routing algorithm has been implemented in order to build and maintain a network spanning tree rooted at each gateway in the network. The protocol does not rely on a common signaling channel to keep the network connected. Hyacinth has been implemented and tested over a small-scale indoor testbed consisting of nodes.

Mcube [41] is a modular, multiradio, WMN designed and developed by the Mobility Management and Networking Laboratory (MOMENT Lab) at UC Santa Barbara. Mcube shows a modular wireless mesh router architecture called split wireless router. A split wireless router is composed of multiple distinct processing nodes, each equipped with a single radio. Such a design allows for easily extensible wireless mesh routers and alleviates the detrimental self-interference problems that can occur between commodity radios. Channel assignment is performed in a centralized manner; more specifically information about network topology are first collected then the topology and interference aware channel assignment algorithm (TIC) is executed in a central server, and finally the channel assignments are disseminated to the mesh routers. The proposed architecture has been validated using a 20-nodes WMN consisting of 46 IEEE 802.11a/g radios. Results show that an 802.11a dual-radio split router is able to forward aggregate TCP traffic over  Mbps. In contrast, a single-unit multiradio router is able to operate at only  Mbps because of inter-radio interference. Compared to dual channel assignment schemes (e.g., Microsoft's MCL), TIC's channel selection technique delivers TCP performance improvement in 30%–100% range.

DMesh [12] is an extension to MAP (Mesh@Purdue) [42], a WMN testbed developed and deployed by Purdue University. DMesh exploits both directional antennas for spatial separation and multiple orthogonal channels for frequency separation to provide significantly increased throughput. The Directional OLSR (DOLSR) routing protocol has been developed along with a channel assignment algorithm in order to take advantage of directional antennas setup. DOLSR extends the OLSR protocol assisting the physical formation of high throughput routing trees rooted at the gateways using practical directional antennas, sets up and maintain corresponding routing state, and performs distributed channel assignment. The proposed architecture has been evaluated using both simulation and experiments ran over a mesh network testbed. Results show that, compared with the omnidirectional/multichannel configuration, the proposed architecture improves packet delivery ratio and throughput and drastically lowers average per-packet delay.

ROMA is a joint distributed channel assignment and routing scheme developed by Networking and Wide-Area Systems Group (NEWS) at the New York University. Channel assignment is performed by the network's gateway that broadcast a channel sequence to the other nodes. Channel allocation sequences are computed in such a way that intrapath interference is eliminated. Moreover, ROMA included a measurement driven routing metric inspired by mETX [43] and taking into account link delivery ratio, fluctuations, and external interference. The protocol has been tested on a 24-node dual-radio testbed. Results show that ROMA can achieve high end-to-end throughput and adapts well to changing network conditions.