- Research Article
- Open Access
Implementation of a Cooperative MAC Protocol: Performance and Challenges in a Real Environment
© Thanasis Korakis et al. 2009
Received: 31 October 2008
Accepted: 31 March 2009
Published: 24 May 2009
Cooperative communication is an active area of research today. It enables nodes to achieve spatial diversity, thereby achieving tremendous improvement in system capacity and delay. Due to its immense potential, extensive investigations have been directed to closely examine its performance by means of both analysis and simulation. However, the study of this new technology in an implementation-based system is very limited. In this paper, we present two implementation approaches to demonstrate the viability of realizing cooperation at the MAC layer in a real environment. The paper describes the technical challenges encountered in each of the approaches, details the corresponding solution proposed, and compares the limitations and benefits of the two approaches. Experimental measurements are reported, which not only help develop a deeper understanding of the protocol behavior but also confirm that cooperative communication is a promising technology for boosting the performance of next-generation wireless networks.
Today, wireless devices are evolving into multipurpose systems with data extensive applications running on them. Such applications require high-speed connectivity and strong error protection. Those needs, along with the exploding growth of wireless networks and limited spectrum resources, have created a capacity crunch and high interference in today's wireless networks. This situation entails a move toward the development of new wireless techniques that can achieve a more efficient use of the avaliable spectrum. While emerging techniques such as multi-input multi-output systems (MIMO) increase the spectrum efficiency in terms of the number of bits per hertz of bandwidth, its usage is limited because of the size, cost, and power constraints posed by portable wireless devices. An alternative approach called cooperative communications [1–3] promises to deliver some of the benefits of MIMO within the given constraints.
Cooperative communication refers to the collaborative processing and retransmission of the overheard information at those stations surrounding the source. The notion of cooperation takes full advantage of the broadcast nature of the wireless channel and creates spatial diversity, in particular, transmission diversity, thereby achieving tremendous improvements in system robustness, capacity, delay, interference, and coverage range.
The fundamentals of cooperative communications lie in the physical layer. However, the notion of cooperation is available in various forms at different protocol layers. To facilitate access to the physical layer information and adaptation to mobility, it is natural to introduce the notion of cooperation in the layer directly above the PHY, namely, the medium access control (MAC) layer.
throughput performance under heavy load,
link performance (e.g., PER),
delay performance (e.g., average end-to-end delay, jitter, processing and transmission delay),
impact of cooperation on the helper station that helps the source transmit to the destination,
impact of the Hello Packet interval (the functionality of this packet will be defined later),
impact of buffer overflow on system performance,
impact of cooperative MAC on real-time (video) applications.
These results help in developing a deeper understanding of the protocol behavior and also confirm that the cooperative MAC protocol delivers superior performance as compared to a legacy (802.11) MAC protocol. Equally important, this paper also elaborates the technical challenges encountered in each of the approaches, details the corresponding solution proposed, compares the limitations posed by the approaches and their benefits, and shares the experience gained, thereby exemplifying how implementation of a cooperative protocol can be approached.
Note that given the nascent nature of cooperative communications, its performance evaluation by means of implementation and experimentation has been scarcely discussed or treated so far. Thus, to the best knowledge of the authors, the work presented in this paper represents one of the first attempts to develop and further advance the understanding of cooperative communication protocols in a real environment.
To familiarize the reader with the necessary background, Section 2 briefly introduces cooperative communications and discusses the recent experimentation efforts in related fields. The protocol that we selected for implementation, namely, CoopMAC, is summarized in Section 3. Then we discuss the driver testbed in Section 4 and the implementation efforts in Section 5. A rich set of measurement results from the driver testbed along with the insights revealed therein are reported in Section 6. Section 7 describes the limitations of the driver approach and introduces the SDR testbed. Section 8 details the implementation on the SDR platform. The results of the SDR implementation approach and the insights we derived are provided in Section 9. Section 10 completes the paper with final conclusions and possible future work.
2. Background and Related Work
The initial attempts for developing cooperative communications focused on physical (PHY) layer schemes [1–3]. These approaches refer to the collaborative processing and retransmission of the overheard information at those stations surrounding the source and the destination. By combining different versions of the same information transmitted by source and different relay stations, the destination can improve its ability to decode the original packet.
However, albeit highly promising, cooperation at the physical layer encounters several formidable obstacles when system realization is considered. First and foremost, joint decoding at the receiver is plausible only if an accurate synchronization can be maintained among all the stations involved in the communication, which is notoriously difficult to cope with in reality. Secondly, the cooperative coding scheme is significantly different from the conventional ones implemented in commercial wireless products (e.g., IEEE 802.11), so that it demands a total redesign of physical layer hardware, which is yet another daunting undertaking.
Numerous efforts [7–10] have also been reported on designing new MAC layer protocols that take advantage of spatial diversity and support cooperative schemes in the PHY layer. For instance, CoopMAC proposed in  allows a source station to choose a relay, based on the information collected passively by listening to the transmissions in the neighborhood. The rDCF protocol described in  follows a more active approach by advertising the ability of each relay to help by using "Hello packets." but for both CoopMAC and rDCF, the source station transmits the packet to the relay and the relay forwards the packet to the destination immediately after the reception. Meanwhile, the relay station in  forward the packet only if it does not receive an ACK from the destination that indicates that the destination has failed to decode the packet after the first hop transmission. Persistent RCSMA, described in , allows executing a distributed and cooperative automatic retransmission request (ARQ) scheme in wireless networks. These schemes exploit the broadcast nature of the wireless channel in the following manner; once a destination station receives a data packet containing errors, it can request a set of retransmissions from any of the relays which overheard the original transmission.
Thanks to the commoditization of IEEE 802.11 devices (e.g., network interface card (NIC) and access point) and the availability of various open source device drivers [11–13], software-defined radio testbeds [14, 15] and free wireless measurement/testing tools , prototyping and experimentation have become a feasible complement to theoretical research in the communication and networking community in recent years [17–22]. However, performance evaluation for all the cooperative MAC protocols [7, 9, 23] at this moment is solely based on simulation and analysis. Since implementation and field experimentation remain the ultimate test of the performance of a new protocol, we are motivated to pursue an implementation approach in this paper.
Among all these MAC protocols, we have chosen CoopMAC to implement, because it is one of the first MAC protocols that fully exploits cooperative diversity and has been widely discussed and referenced [4–7]. Moreover, CoopMAC maintains backward compatibility with the legacy IEEE 802.11 distributed coordination function (DCF)  and incurs a negligible additional signaling overhead, thereby requiring only minor modifications of the standard, and presenting an opportunity for incremental implementation of cooperation on commercial 802.11 platforms. Nevertheless, note that the experience reported in this study is equally applicable for the development of other cooperative MAC schemes that rely on a single relay for forwarding.
Implementation of CoopMAC can be built upon two possible platforms, namely, open-source driver [11–13] and software defined radio [14, 15] . Both platforms have their own benefits as well as drawbacks as far as CoopMAC implementation is concerned. In order to be able to conduct extensive studies on the cooperative MAC protocol in a real environment and realize its full potential, we decided to pursue both approaches.
3. Cooperation at MAC Layer
3.1. Multirate Capability and Motivation for Cooperation
Before delving into the protocol details of CoopMAC, the motivation for cooperation and the multi-rate capability of IEEE 802.11b deserve a brief discussion, as they are crucial to comprehending how cooperation at the MAC layer can be capitalized on.
Another key observation conveyed by Figure 1(a) is that a source station that is far away from the destination may persistently experience a poor wireless channel, resulting in a rate as low as for direct transmission over an extended period of time. If there exists some neighbor who in the meantime can sustain higher transmission rates (e.g., and in Figure 1(a)) between itself and both the source and the intended destination, the source station can enlist the neighbor to cooperate and forward the traffic on its behalf to the destination, yielding a much higher equivalent rate. With the simple participation of a neighboring station in the cooperative forwarding, the aggregate network performance would witness a dramatic improvement, which justifies and motivates the introduction of cooperation into the MAC layer.
3.2. A Cooperative MAC Protocol
The set of new features of cooperative MAC spans both the data plane and control plane of the protocol stack. For ease of explanation, the terms relay and helper will be used interchangeably in the following discussion. As shown in Figure 1(b), , , and represent the source, helper, and destination station, respectively. Moreover, , , and denote the sustainable rates between and , between and , and between and , respectively.
3.2.1. Data Plane
Before the transmission of a packet, station should access all the rate information in a cooperation table, and compare a rough estimation of the equivalent two-hop rate with the direct rate to determine whether the two-hop communication via the relay yields a better aggregate performance than a direct transmission. If cooperative forwarding is invoked, CoopMAC engages the selected relay station to receive the traffic from the source at rate and then forwards it to the corresponding destination at rate after an SIFS interval. In the end, destination indicates its successful reception of the packet by issuing an acknowledgment packet (ACK) directly back to . We would like to mention here that we also considered PHY and MAC overheads in our original paper  for a more accurate estimation to decide whether a direct or two-hop is used. Based on the results we concluded that for an average length packet, those parameters do not have a significant effect.
In order to distribute the identity of the station that has been selected as a helper, a minor modification has to be introduced to the addressing schemes defined in the legacy 802.11. More precisely, Address 4 field in the legacy 802.11 MAC header as shown in Figure 2(b) is left unused if the data packets are not sent between access points. For the data packet from to in CoopMAC, however, this field should hold the MAC address of the final destination , while Address 1 field contains the MAC address of the selected helper . When the packet is further forwarded by to , the helper will place the address of in field Address 1, and leave the Address 4 unused.
3.2.2. Control Plane
Each entry in the CoopTable, which corresponds to one candidate helper , is indexed by its MAC address. The values of and associated with are stored in the third and fourth field of the CoopTable, respectively. The main indication of the freshness of the learned information, namely, the time at which the most recent packet is overheard from , is held in the second field called Timestamp. The last field, Number of Failures, reflects the reliability of each helper, by recording the number of consecutive unsuccessful transmissions that use as a helper.
Whenever a packet is overheard from an , if that neighbor has no corresponding entry in the CoopTable, a new entry is created and inserted into the table; otherwise, all the fields associated with would undergo any necessary updates. It is worthwhile to note that for to acquire the value of and , a passive eavesdropping approach is followed, so that the overhead of additional control message exchange can be kept at minimum level. More specifically, the physical layer header (PLCP header) of any 802.11 data packet has rate information in its PLCP signaling field. Since PLCP header is always transmitted at the base rate, it can be decoded and understood by all other stations in the network, which includes . However, may not be able to correctly retrieve the MAC address of the transmitter and receiver directly from the corresponding data packet, since such information is contained in the MAC header and is in many instances transmitted at a rate higher than what can support. Fortunately, since each data packet sometimes are preceded by a successful handshake of RTS/CTS or succeeded by an acknowledgment, and all these control messages are exchanged at the base rate, eventually can find out the identity of and , with which the rate is associated. If there are direct transmissions between and , the rate estimation should proceed as prescribed by the rate adaptation algorithm that is used in the particular WLAN . Although the described mechanism takes advantage of the rate adaptation capability of the network, it is independent of the particular rate adaptation algorithm. When no communication between these two stations occurs during an extended period of time, is still able to derive the highest rate that it can sustain by estimating the quality of the link between and based upon the signal strength of the packet that overhears from .
Since protocol design is not the primary focus of this paper, it will not be covered at length hereafter. It is worthwhile to note that although CoopMAC seemingly bears some resemblance to the conventional ad hoc routing protocols, they are in essence fundamentally different. First and foremost, forwarding in CoopMAC per se is just one practical means to accomplish the goal of leveraging cooperative diversity, instead of the goal itself. Secondly, all the associated operations occur in the MAC layer, which enjoys a shorter response time and more convenient access to the physical layer information, as compared to traditional network layer routing. Interested readers are encouraged to refer to  for more detailed protocol specifications and technical discussions.
4. Driver Implementation Approach
5. Implementation of Cooperation Using Open Source Drivers
Figure 4(b) depicts the way CoopMAC has been implemented in the driver-chipset platform. Due to the constraints of space, certain implementation details cannot be covered. Nevertheless, the key challenges encountered in the driver implementation are summarized. Interested readers can access the official project website  for more technical information. The driver for cooperative MAC is also available at the website for free downloading.
When it comes to system design, all the features specified in the IEEE 802.11 MAC protocol are logically partitioned into two modules, according to the time-criticality of each task. The lower module, implemented as firmware on the wireless card, fulfills the time-critical mission such as the generation and exchange of RTS/CTS control messages, transmission of acknowledgment (ACK) packets, execution of random backoff, and so on. The other module, which normally assumes the form of system driver, is responsible for more delay-tolerant control plane functions such as the management of MAC layer queue(s), the formation of MAC layer header, fragmentation, association, and so on.
As the cooperative MAC protocol requires changes to both time-critical and delay-tolerant logics, the inaccessibility to firmware unfortunately causes additional complexity in implementation. Indeed, compromises have to be made and alternative approaches have to be pursued, due to this constraint. For illustrative purpose, three main circumventions that have been made are outlined as follows.
(i) Suspension of Three-Way Handshake
As mentioned in Section 3.2.1, a three-way handshake has been defined in the cooperative MAC protocol, which requires the selected helper to transmit a new control message called "Helper ready To Send" (HTS) between the RTS and CTS messages. Since the timing sequence of RTS and CTS packets has been hardwired in the firmware, an insertion of an HTS becomes impossible at the driver level. Consequently, three-way handshake of the protocol was suspended.
(ii) Unnecessary Channel Contention for Relayed Packet
Once the channel access has been allocated to the source station, the helper should relay the packet an time after its reception, without any additional channel contention. Since the time is set as in IEEE 802.11b, any function demanding such a short delay must be implemented in firmware. As a result, a compromise has been made in the implementation, in that the second hop transmission takes place after channel contention.
(iii) Duplicate ACK
Each successful data exchange in the original cooperative MAC protocol involves only one acknowledgment message, which is sent from the destination to the source directly. Since the acknowledgment mechanism is an integral function of firmware, it is impossible to suppress the unnecessary ACK message generated by the relay station for the packet it will forward on behalf of the source. Therefore, the unwanted ACK from the relay has to be tolerated, instead of being eliminated.
As a critical implication of the circumventions described earlier, a faithful implementation of cooperative MAC is anticipated to outperform the one demonstrated in this paper.
5.1. Maintenance of the CoopTable
As described in Section 3.2.2, the CoopTable plays a key role in facilitating the cooperative operation. The passive approach defined therein for rate learning, however, has not been realized due to the following reasons.
(i) Unwanted Packet Filtering
All the packets with a destination address different from the local MAC address are filtered out by the firmware, instead of being passed up to the driver. Hence, the driver is not aware of such packets, and therefore unable to retrieve any information from them.
(ii) Controllability of the Experimental Environment
Even if the driver has access to such packets (e.g., by periodically switching the wireless card to the promiscuous mode), the traffic load and pattern at each station may cause inconvenience during experiments.
Therefore, for the sake of controllability of the experimental environment, an active information distribution approach is followed instead. More specifically, a Hello packet is broadcast by each station periodically which notifies its neighbors about its existence as well as the sustainable transmission rate on the respective link. The frequency of the Hello packet broadcasts in all the scenarios, except for the one described in Section 6.2, is one packet per second. Upon the reception of the Hello packet, a station either inserts a new entry or updates an existing one in its CoopTable.
To further increase flexibility, the frequency at which the Hello packet is transmitted, as well as the rate information to be carried has been implemented as parameters in the driver, which can be configured on the fly by the iwpriv command.
5.2. New Shim Header
No flexible mechanism is available on the HostAP platform to pass three MAC addresses down to firmware to generate a proper MAC header, which implies that the addressing scheme described in Section 3.2.1 cannot be faithfully followed. As a tentative solution, a new shim header called CoopHeader, which contains the MAC addresses of source, helper, and destination, has instead been inserted between the MAC header and the MAC payload.
5.3. Summary of Implemented Functionality
Addressing scheme for different scenarios.
Source to destination
Source to helper
Helper to destination
Summary of implemented functionality.
(1) Helper selection, based upon CoopTable
(2) Creation and insertion of a CoopHeader in the packet to be transmitted
(1) Creation and insertion of a new CoopHeader in the packet to be relayed
(2) Cooperative packet relay
(1) Packet reception and payload extraction
5.4. Experimental Setup
Basic configuration of mobile stations.
Intel Pentium III processor 1 GHz
Redhat Linux 9
EnGenius 2511 CD PLUS, PCMCIA
Intersil Prism 2.5
5.5. Measurement Methodology
The majority of the statistics generated in the experiment, including throughput, packet loss, and jitter, are measured by using Iperf , which is a powerful tool for traffic generation and results measurement. A typical experiment setup could be to run an Iperf client at a handful of stations to generate UDP or TCP traffic streams, while an Iperf server residing on the dedicated destination receives the traffic and collects the statistics. To remove any random effect and short-term fluctuation, we run each experiment 5 times and each run lasts 10 minutes. Then, we get the average results.
The measurement of average delay is nontrivial, since no mean end-to-end delay statistics are provided by Iperf or other off-the-shelf traffic measurement tools. As further explained in , tight synchronization between the transmitter and receiver is needed, if the delay is to be measured directly.
To circumvent the synchronization requirement, which is difficult to meet, the end-to-end delay is therefore derived based upon a round-trip delay that can be measured more easily. More specifically, a new testing function has been implemented in the driver, which lets the transmitter periodically broadcast a packet. Once the receiver successfully decodes the packet, it immediately sends another broadcast packet back to the transmitter. Since the delays incurred in each direction can be considered identical, the one-way end-to-end delay experienced by a data packet is approximately equal to half of the round-trip delay observed at the transmitter. The delay statistics derived is the time from the instant that the wireless MAC driver pushes the packet into the MAC transmission queue, until the time the packet is passed from the physical layer to the MAC buffer at the receiver. A closer examination of this delay value reveals that it consists of several major components, namely, the delay incurred at the transmitter (e.g., kernel interrupt delay in the driver, random backoff time, DIFS), transmission time, and delay experienced at the receiver (e.g., delay associated with kernel interrupt that signals to the MAC layer the arrival of a new packet, etc.). Note that no time will be spent on transmitting an ACK packet because a broadcast transmission does not require any acknowledgment.
6. Performance Evaluation for the Driver Approach
Based upon the testbed described in Section 5.5, numerous experiments have been conducted, and the results obtained are reported and analyzed in this section.
6.1. Baseline Scenario
A baseline scenario, which only consists of 1 transmitter, 1 helper, and 1 receiver, is first used to develop a basic understanding of the implication of cooperation, and establish a benchmark for performance study of more sophisticated settings. Thanks to its simplicity, this scenario isolates such interfering factors such as collisions, and creates an ideal environment that gives rise to several crucial insights related to the behavior of CoopMAC.
6.1.1. Throughput Improvement at Source
For both types of traffic, CoopMAC enables to deliver substantially higher throughput, as readily demonstrated in Figure 6. In addition, Figures 6(a) and 6(b) also disclose that the throughput gain achieved by cooperation becomes more pronounced, as transmission rates and are increased.
6.1.2. Throughput Improvement at Helper
The impact of cooperation on helpers, however, is not that straightforward, and requires further exploration. In the second experiment, the Iperf client at is switched on, so that it not only relays traffic on behalf of , but also transmits its own packets to .
6.1.3. Interaction with Transport Protocol
In Figure 7, we can see the throughput comparison in a scenario of a source, an active helper, and a destination. Direct transmission between source station and destination always occurs at 1 Mbps, and helper station can sustain 11 Mbps for communication with both and . An important trend displayed in Figure 7(a) is that the bandwidth in the IEEE 802.11 network is equally shared by the two UDP sources at and , respectively, in spite of the fact that physical layer bit rate supported by is 11 times higher than that at . Indeed, this notion of fairness that 802.11 strives to maintain has been known as the major culprit for a serious network-wide throughput degradation . The CoopMAC protocol obviously preserves this fairness, as no significant disparity in the throughput of and can be seen in Figure 7(a), while significantly increasing network throughput.
With cooperation, this mismatch between the MAC and TCP protocols can be ameliorated, and the long-term fairness be restored, as readily demonstrated in Figure 7(b). Thanks to the assistance of the cooperative relay, packets from the slow source station will release the wireless channel much earlier. Consequently, the delay experienced at the fast relay falls to a value too low to incur any higher layer timeout under most circumstances.
6.2. Hello Packet Interval
6.3. End-to-End Delay
Another key dimension of performance for any MAC protocol is the delay, which in fact plays a more critical role than throughput in determining a network's capability of supporting delay QoS-sensitive applications.
6.4. Protocol Dynamics
However, the difference between the behavior of two protocols is more pronounced than the similarity, and the superiority of cooperative MAC is clear in this setting.
(1) Saturation Point
The 802.11 network passes the critical tipping point as early as , while CoopMAC does not experience saturation until a load of . Thus, the maximum throughput thereby achieved by CoopMAC is approximately times higher than that for 802.11.
(2) Postsaturation Regime
Once entering the respective saturation regions, all stations in 802.11 invariably start to witness significant packet drop and throughput deterioration. For helper stations in cooperative MAC, however, the decrease is stalled after an initial dip, and then is stabilized at a plateau of about . On the other hand, in spite of the fact that throughput of source stations in CoopMAC more or less follows the same trend of monotonic decline observed in 802.11, its absolute value is still notably higher.
A closer scrutiny further suggests that this performance disparity between the helper stations and source stations in a CoopMAC network is an artifact of our present implementation approach, and is expected to disappear once the access to firmware becomes available. More specifically, as explained in Section 5, the cooperative MAC protocol is currently realized at the driver level, which forces the helper stations to pass the received foreign packets into the driver space and queue them together with the native traffic in the same buffer. When the local load at the helpers grows high enough, the arrival rate of the indigenous packets at the buffer far surpasses that of the packets received from the source stations. Therefore, the rate at which the packets can be received at the helpers places a bottleneck on the end-to-end throughput of the forwarded traffic, which essentially gives local helper traffic preferential treatment.
6.5. Network Capacity and Jitter
Settings for study of network capacity and jitter.
Num. of source stations
Num. of helper stations
Num. of destination
As demonstrated in Figure 12, the CoopMAC protocol easily delivers a network capacity that is up to 2.5 times higher than the achievable by 802.11. In addition, this improvement is sustainable across a variety of network sizes.
Concerning the jitter, Iperf can provide a measurement for each traffic stream. Use and to denote the jitter observed at each source and helper station. To compare the worst case scenario, and have been extracted from the statistics and depicted in Figure 13 for source and helper station, respectively.
As compared to network capacity, both Figures 13(a) and 13(b) indicate that jitter is more sensitive to the network size. Moreover, although helper stations support a higher transmission rate than source stations, they experience a higher variance in end-to-end delay (jitter) in an 802.11 network. A similar trend has been previously identified and an explanation was offered in Section 6.1.3, where the interaction with TCP layer was first investigated.
Once cooperative MAC is adopted, the jitter performance for both source and helper stations can be improved. In addition, the fast helper stations now perceive lower jitter than the slow source stations, implying that the issue of unfairly high jitter for fast stations has been successfully resolved by CoopMAC.
6.6. Computational Overhead
A substantial proportion of mobile devices deployed in the field have limited computing power. To assess the feasibility of leveraging cooperative diversity from devices with such a constraint, the computational overhead incurred by cooperation should be evaluated.
Despite the increase of computational overhead at the helpers, neither the source nor the helper have been overwhelmed by the processing associated with cooperation. Moreover, since the laptops used in the testbed are not top of the line, the impact of additional computational overhead would be even less noticeable on state-of-the-art mobile devices.
6.7. A Demo of a Video Application
Although highly encouraging, all the aforementioned results are obtained in experiments that rely on artificial traffic patterns. The final judgment regarding the efficacy of cooperation cannot be made until the improvement is delivered to the application layer and becomes appreciable through user perception.
To this end, the transmission of a video clip is considered in the testbed described in Section 6.1. A Video LAN Client ( )  server is placed at the source station and constantly streams a commercial video clip, while the destination station runs a media player to play the video.
7. Software-Defined Radio Approach
As mentioned earlier, we were not able to implement CoopMAC in its full sense due to several limitations posed by the architecture of the wireless card hardware. In particular, CoopMAC defines some features that require modifications in the time-critical functionality of the wireless card. As a result, the final implementation of the scheme in HostAP was limited to an emulation of the original protocol. The open-source drivers implementation of CoopMAC missed several critical functional characteristics of the original protocol. The cooperative protocol, the way it was implemented on the open source drivers, is very similar to a layer 3 forwarding mechanism that takes into consideration the channel quality for the next hop forwarding. In particular, it introduces more overhead and it suffers from longer delays. Nevertheless, the experimental results showed significant benefits of using cooperation in the MAC layer. Therefore we decided to move forward and continue with the implementation of the protocol using a more flexible platform in order to achieve more accurate results.
The obvious choice was a software-defined radio, since in such an approach, both the PHY and the MAC layers are designed in software and therefore they can be changed. Moreover, an all-software radio platform gives us the ability to go lower in the PHY layer and design MAC and PHY cross-layer schemes that enable PHY layer cooperation at the receiver. Two strong candidate platforms were GNU radio  and WARP . GNU radio is a popular platform that has the MAC and PHY layer implementations in software that can run on a PC. The PC communicates though a USB cable with a simple transceiver that takes care of the transmission/reception of the signal. Due to the USB connectivity between the PC and the wireless board, GNU radio has a very limited capability of implementing sophisticated PHY and MAC protocols since this communication experiences long delay. This delay introduces synchronization problems in the MAC layer and performance limitations in the PHY layer. Therefore, although GNU radio allows us to build a version of our protocol, the above limitations do not allow for a realistic implementation.
WARP seemed a more promising solution since it consists of a Xilinx Virtex II Pro FPGA board with embedded Power PC processors. The processing and the transmission/reception of the frames are done on the board. Such a hardware platform allows for realistic MAC and PHY layer implementations with PHY layer rates similar to those in IEEE 802.11a,g.
Using the WARP radio platform, we were able to overcome all of the three limitations listed earlier. However, in this paper we focus on the description and the implications of the first two limitations. The RTS-CTS model is an optional supportive functionality that copes with the hidden terminal problem. Consequently, the RTS-HTS-CTS model is an extension of the RTS-CTS scheme that copes with the same problem. Since the focus of this work is the study of the benefits of cooperation between stations in the MAC layer, the study of the hidden terminal problem is out of the scope of this paper.
7.1. Software-Defined Radio Testbed Architecture
WARP consists of a Xilinx Virtex II Pro FPGA board with embedded Power PC processors and allows for realistic MAC and PHY layer implementations that could give PHY layer rates similar to those provided in IEEE 802.11a,g. It provides a complete embedded programing environment for the design of PHY and MAC layers. In addition, it has four daughter card slots in which radio cards or customized cards can be inserted to connect to the FPGA. The current physical layer design uses an Orthogonal Frequency Division Multiplexing (OFDM) implementation that is loosely based on the PHY layer of the 802.11a standard. The radio board uses 2.4 GHz/5 ISM/UNII bands for transmission.
In the MAC layer WARP provides a framework called WARPMAC and WARPHY which is used for the development of advanced MAC protocols. WARPMAC and WARPPHY are a set of functions that provide MAC-type functionalities and functionalities to access the PHY layer, respectively, and they work as the interface between the PHY and the user application layer. This MAC framework is implemented in the PowerPC and the code is written in the C language using Xilinx Platform Studio.
Rice University provides many software resources at the WARP web site  including an Aloha-like MAC and a CSMA-like MAC. For our implementation we based our development on the CSMA-like MAC.
8. Implementation of CoopMAC Using the All Software Radio Platform
In our implementation of CoopMAC on an all software radio platform, the OFDM reference design version 8 of the WARP platform has been used. The OFDM reference design version 8 implements the CSMA protocol for medium-access control, so it is a perfect candidate for legacy wireless protocols. We implemented CoopMAC using the CSMA model of the WARPMAC framework. Whenever we refer to a node in the following discussion, we refer to a WARP node.
In our implementation we define two operational modes for the transmission. Direct mode is the legacy direct mode under the CSMA protocol (no cooperation), and Cooperative mode is the mode that enables CoopMAC. In this mode the packet is forwarded to the destination through the helper using two fast hops. The decision about whether the transmission is in Direct mode or in Cooperative mode is taken by the source station after considering the information maintained in the CoopTable about candidate helpers in neighborhood and the rates they can sustain with both the source and the destination. In the rest of this section we describe the changes we introduced in several parts of the CSMA functionality of WARPMAC in order to implement the cooperative MAC protocol.
8.1. Addressing and Packet Structure
The addressing scheme that we used for CoopMAC is based on the one defined in WARPMAC. Each node has a unique nodeID which is determined by 4 dip switches. Therefore, a total of 16 unique nodeID's can be generated. Based on the nodeID, the MAC code generates a MAC address string and assigns it to the node. The nodes maintain a table that maps nodeID's to the corresponding MAC addresses.
Source address: the MAC address of the source station (in both direct and cooperative mode).
Destination address: the MAC address of the destination station. In direct mode this is the address of the final destination. In the cooperative mode this is the address of the immediate destination in that particular hop (i.e., the helper in the first hop, the final destination in the second hop).
CoopDestinationID: a new subfield we introduce in order to handle the forwarding process. It is used in the cooperative mode and it indicates the final destination for the packet. In the first hop, this field indicates the final destination while the Destination Address field (mentioned above) indicates the address of the helper. CoopDestinationID is used by the helper when it generates the header of the packet for the second hop in order to define the final destination of the packet.
- (4)PktType: used to indicate the nature of the packet.
DATAPACKET: a packet that is used in direct mode.
COOPPACKET: a packet that is used in CoopMAC for the first hop transmission (source to helper).
COOPFINAL: a packet that is used in CoopMAC for the second hop transmission.
ACK: a control packet that acknowledges successful reception and sent by the destination to the source.
Full Rate: used to indicate the rate at which the payload of a packet is transmitted.
Current Resend: used to indicate the number of retransmissions.
Length: used to indicate the length of the payload.
Checksum: a checksum value that is calculated and handled by the PHY layer.
DATAPACKET: if the received packet is DATAPACKET, then an ACK is transmitted back to the source node.
COOPPACKET: the packet type used between the source and the helper. On receiving a COOPPACKET, the receiver realizes that it should react as a helper. Therefore, it replaces the Destination Address field with that of the final destination address based on the CoopDestinationID field, and forwards the packet immediately, without contending for the channel.
COOPFINAL: the packet type used between the helper and the final destination. On receiving COOPFINAL packet, the destination sends back an ACK, directly to the source node.
ACK: on receiving an ACK, the source node stops the timeout process and proceeds with the next transmission.
A simplified flow graph of the reception process is shown in Figure 16(b). In this particular figure we do not show the ACK reception. In order to enable the ACK transmission directly from the destination to the source, the Source Address field of the packet header remains the same throughout the two hop transmission. In this way the final receiver is aware of the actual source.
8.4. Implementation of the CoopTable
In this table, a higher metric value implies a higher data rate. The CoopTable is updated passively after the reception of any packet that is transmitted by a node in the neighborhood. By checking the Full Rate subfield in the MAC header of the packet, the node is aware of the bit rate of the packet payload and therefore the channel condition between its source and the destination. In this way, a node gets information about the channel conditions between neighboring helpers and itself, as well as with potential destinations. We should mention that the MAC header of the packet is transmitted at the base rate (BPSK), and therefore any node in the proximity of the transmitter can receive it, decode it, and use the information contained within it to update its CoopTable. In addition to this passive approach, we implemented an active approach where periodic Hello packets are transmitted by each node in the network. A Hello packet contains information about the sustainable rates between the particular node and its neighbors (Rate Table). A node that receives a Hello packet updates its CoopTable based on this information.
8.5. Transmission Rates
WARP nodes supports dynamic modulation on a per packet basis. This information is included in the Full Rate subfield of the MAC header of the packet and is used for the demodulation of the packet at the receiver. The MAC header is transmitted at the base rate, which is BPSK for our implementation. This is done to increase the robustness of the decoding process of the header at the receiver. Similarly, an ACK is transmitted at the lowest rate using BPSK in order to minimize ACK loss.
9. Performance Evaluation on the Software Radio Approach
The CSMA approach that emulates the IEEE 802.11 MAC protocol. We will call this scheme direct transmission.
Approach 1 as described prevously based on the Driver platform. In order to differentiate between the two cooperative approaches we call this scheme CoopMAC with contention, while we call the accurate implementation (SDR approach) of the mechanism CoopMAC without contention.
As evaluation metrics we use the total number of successful packets (throughput) as well as the average delay per packet. We should mention that the QAM 64 modulation scheme of the current PHY layer implementation in the WARP platform is not very stable, and therefore we avoided using this rate in our experiments. We only used BPSK, QPSK, and QAM-16.
We currently have only three WARP nodes for conducting experiments. However, this small-scale testbed was enough for our purposes which was to show the fundamental benefits gained when using cooperative MAC schemes in a real environment.
All measurements were done indoors. For generating UDP traffic, we used Iperf . In all cases, the UDP packet length was 1470 bytes. Each scenario was run 10 times, for 50 seconds each time, and the results were averaged. For the experiments, three nodes were used: a source, a destination, and a helper. Therefore, the information in CoopTable was statically entered with metrics depending on the particular scenario. The metric selection is described in detail for each experiment.
9.1. Scenario 1
In the first experiment we study the performance of the cooperative MAC protocol in a typical scenario. We consider the case when the channel between the source and the destination is poor and that the helper is located in between the two nodes. Therefore, it has a good channel quality with both of them. We compare the CoopMAC implementation with CoopMAC with contention as well as to direct transmission. We emulated the bad channel in direct mode by forcing the data rate in the direct transmission to be (BPSK). The transmission via the helper for both hops was fixed at (QAM-16). Using Iperf we generated UDP traffic that was passed to the WARP nodes connected to PCs through an Ethernet cable.
In Figure 17(b), we depict the delay for each scheme under heavy load. It is clear that the cooperative protocols decrease the transmission time of the slow node thus reducing the delay. For CoopMAC without contention the delay is even smaller since it avoids the extra delay that is introduced in the second hop due to contention before the transmission of the packet.
9.2. Scenario 2
10. Conclusions and Future Work
The impact of a performance study in a real environment can never be overemphasized as it is able to identify the limitations of the predictions yielded by theoretical analysis and simulation, and valuable practical insights into protocol design and potential improvements are gained.
This paper represents one of the few attempts that rely on an experimental approach to develop an understanding of cooperation at MAC layer. The measurement results obtained confirm that the cooperative MAC protocol can substantially improve the performance (e.g., throughput, mean end-to-end delay, jitter, etc.) for not only the stations being helped but also the ones who offer the cooperation.
Furthermore, the paper sheds light on several critical issues particular to cooperation, such as the impact of MAC cooperation on the TCP protocol, and the dynamics of protocol behavior, which to the best knowledge of the authors have been presented for the first time. Note that early awareness, precise comprehension, and proper caution when addressing these issues can help in future implementation and experimentation.
The paper describes two different implementation approaches. An implementation that is based on open source drivers and an implementation that is based on an software-defined radio platform are presented. A detailed description of the motivations for the implementation of the protocol on each platform is given, as well as the benefits and limitations of the two approaches. The SDR approach seems to be highly promising, as it allows modification of the physical layer functions, and therefore makes it possible to realize MAC-PHY cross-layer mechanisms. On the other hand, an open-source wireless driver platform limits the capability of modifying physical layer functions. However, it enables the resultant prototype to be directly compared with 802.11 commercial products, something that is not feasible in the case of the SDR.
As for possible future work, we are planning to continue with the implementation of cooperative schemes in the PHY layer, and combine them with the existing cooperative MAC protocol. In this way, we will implement realistic cooperative cross layer mechanisms that will further improve wireless network performance by enabling cooperation at the PHY layer as well.
- Laneman JN, Tse DNC, Wornell GW: Cooperative diversity in wireless networks: efficient protocols and outage behavior. IEEE Transactions on Information Theory 2004, 50(12):3062-3080. 10.1109/TIT.2004.838089MathSciNetView ArticleMATHGoogle Scholar
- Sendonaris A, Erkip E, Aazhang B: User cooperation diversity—part I: system description. IEEE Transactions on Communications 2003, 51(11):1927-1938. 10.1109/TCOMM.2003.818096View ArticleGoogle Scholar
- Sendonaris A, Erkip E, Aazhang B: User cooperation diversity—part II: implementation aspects and performance analysis. IEEE Transactions on Communications 2003, 51(11):1939-1948. 10.1109/TCOMM.2003.819238View ArticleGoogle Scholar
- Tan K, Wan Z, Zhu H, Andrian J: CODE: cooperative medium access for multirate wireless ad hoc network. Proceedings of the 4th Annual IEEE Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks (SECON '07), June 2007, San Francisco, Calif, USA 1-10.Google Scholar
- Sayed S, Yang Y: A new cooperative MAC protocol for wireless LANs. Proceedings of the London Communications Symposium (LCS '07), September 2007, London, UKGoogle Scholar
- Feeney LM, Cetin B, Hollos D, Kubisch M, Mengesha S, Karl H: Multi-rate relaying for performance improvement in IEEE 802.11 WLANs. Proceedings of the 5th International Conference on Wired/Wireless Internet Communications (WWIC '07), May 2007, Coimbra, Portugal, Lecture Notes in Computer Science 4517: 201-212.View ArticleGoogle Scholar
- Agarwal N, Channegowda D, Kannan LN, Tacca M, Fumagalli A: IEEE 802.11b cooperative protocols: a performance study. Proceedings of the 6th International IFIP-TC6 Networking Conference on Ad Hoc and Sensor Networks, Wireless Networks, Next Generation Internet (NETWORKING '07), May 2007, Atlanta, Ga, USA, Lecture Notes in Computer Science 4479: 415-426.Google Scholar
- Liu P, Tao Z, Narayanan S, Korakis T, Panwar SS: A cooperative MAC protocol for wireless LANs. IEEE Journal on Selected Areas in Communications 2007, 25(2):1-40.Google Scholar
- Zhu H, Cao G: rDCF: a relay-enabled medium access control protocol for wireless ad hoc networks. Proceedings of the 24th IEEE Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM '05), March 2005, Miami, Fla, USA 1: 12-22.View ArticleGoogle Scholar
- Alonso-Zárate J, Kartsakli E, Verikoukis C, Alonso L: Persistent RCSMA: a MAC protocol for a distributed cooperative ARQ scheme in wireless networks. EURASIP Journal on Advances in Signal Processing 2008, 2008:-13.Google Scholar
- Host AP driver for Intersil Prism2/2.5/3 http://hostap.epitest.fi/
- MADWiFi: Multiband Atheros Driver for WiFi http://madwifi.org/
- Intel Wireless WiFi Link drivers for http://www.intellinuxwireless.org/
- GNU Radio—The GNU Software Radio http://gnuradio.org/trac
- WARP: Wireless Open-Access Research Platform http://warp.rice.edu/trac
- Iperf: The TCP/UDP Bandwidth Measurement Tool http://en.wikipedia.org/wiki/Iperf
- Miu A, Tan G, Balakrishnan H, Apostolopoulos J: Divert: fine-grained path selection for wireless LANs. Proceedings of the 2nd International Conference on Mobile Systems, Applications and Services (MobiSys '04), June 2004, Boston, Mass, USA 203-216.View ArticleGoogle Scholar
- Raniwala A, Chiueh T-C: Architecture and algorithms for an IEEE 802.11-based multi-channel wireless mesh network. Proceedings of the 24th IEEE Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM '05), March 2005, Miami, Fla, USA 3: 2223-2234.View ArticleGoogle Scholar
- Dangerfield I, Malone D, Leith D: Experimental Evaluation of 802.11e EDCA for Enhanced Voice over WLAN Performance. Proceedings of the 2nd International Workshop on Wireless Network Measurement (WiNMee '06), April 2006, Boston, Mass, USA 1-7.Google Scholar
- Zhang H, Arora A, Sinha P: Learn on the fly: data-driven link estimation and routing in sensor network backbones. Proceedings of the 25th IEEE Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM '06), April 2006, Barcelona, Spain 1-12.Google Scholar
- ORBIT Project: Open-Access Research Testbed for Next-Generation Wireless Networks http://www.orbit-lab.org/
- TAP Project: Transit Access Points Project http://taps.rice.edu/index.html
- Liu P, Tao Z, Lin Z, Erkip E, Panwar SS: Cooperative wireless communications: a cross-layer approach. IEEE Wireless Communications 2006, 13(4):84-92. 10.1109/MWC.2006.1678169View ArticleGoogle Scholar
- ANSI/IEEE Std 802.11 : Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. 1999 Edition, 1999Google Scholar
- Kamerman A, Monteban L: WaveLAN-II: a high-performance wireless LAN for the unlicensed band. Bell Labs Technical Journal 1997, 2(3):118-133.View ArticleGoogle Scholar
- Official Website of Cooperative MAC Implementation http://eeweb.poly.edu/coopmac/
- Heusse M, Rousseau F, Berger-Sabbatel G, Duda A: Performance anomaly of 802.11b. Proceedings of the 22nd IEEE Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM '03), March-April 2003, San Franciso, Calif, USA 2: 836-843.Google Scholar
- Xu S, Saadawi T: Revealing the problems with 802.11 medium access control protocol in multi-hop wireless ad hoc networks. Computer Networks 2002, 38(4):531-548. 10.1016/S1389-1286(01)00273-0View ArticleGoogle Scholar
- Berger-Sabbate G, Duda A, Gaudoin O, Heusse M, Rousseau F: Fairness and its impact on delay in 802.11 networks. Proceedings of the IEEE Global Telecommunications Conference (GLOBECOM '04), November-December 2004, Dallas, Tex, USA 5: 2967-2973.View ArticleGoogle Scholar
- VLC Media Player http://www.videolan.org/vlc/
- Korakis T, Tao Z, Makda S, Gitelman B, Panwar SS: It is better to give than to receive—implications of cooperation in a real environment. Proceedings of the 6th International IFIP-TC6 Networking Conference on Ad Hoc and Sensor Networks, Wireless Networks, Next Generation Internet (NETWORKING '07), May 2007, Atlanta, Ga, USA, Lecture Notes in Computer Science 4479: 427-438.Google Scholar
- Sharmat A, Gelaras V, Singh SR, Korakis T, Liu P, Panwar SS: Implementation of a cooperative MAC protocol using a software defined radio platform. Proceedings of the 16th IEEE Workshop on Local and Metropolitan Area Networks (LANMAN '08), September 2008, Chij-Napoca, Transylvania 96-101.Google Scholar
This article is published under license to BioMed Central Ltd. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.