MultiMAC - An Adaptive MAC Framework for Dynamic Radio - CiteSeerX

MultiMAC - An Adaptive MAC Framework for Dynamic Radio Networking Christian Doerr, Michael Neufeld, Jeff Fifield, Troy Weingart, Douglas C. Sicker, and Dirk Grunwald Department of Computer Science University of Colorado at Boulder Boulder, CO 80309 {Christian.Doerr, Michael.Neufeld, Jeff.Fifield, Troy.Weingart, Douglas.Sicker, Dirk.Grunwald}@colorado.edu Abstract— Software-defined/cognitive radio has recently made the jump from a purely research driven endeavor to one that is now being driven commercially. Such radios offer the promise of spectrum agility and re-configurability through flexibility at the MAC and physical layers. In the wireless domain it has been shown that hybrid-MAC layer algorithms can lead to improved overall performance in varying network conditions. A hybrid MAC that uses CSMA in low-contention periods and switches to TDMA in high-contention periods can outperform CSMA or TDMA individually. However, such hybrid systems do not offer the flexibility and cognition required of dynamic spectrum networks. In this paper we describe M ULTI MAC, a framework and experimental platform for evaluating algorithms that dynamically reconfigure MAC and physical layer properties. M ULTI MAC, acts as a mediating MAC layer and dynamically reconfigures and/or selects from a collection of alternative MAC layers. As a result of monitoring current network metrics, M ULTI MAC chooses the MAC layer capable of achieving the best performance while ensuring that incoming frames are decoded using the correct MAC layer algorithm. M ULTI MAC incorporates decision processes to select the appropriate MAC component based on per-node and per-flow statistics. This engine will allow intelligent reconfiguration of the MAC and physical layers in response to changes in external conditions and/or requirements optimizing use of the available spectrum.

I. I NTRODUCTION Prior research has shown that network efficiency can be increased by using multiple MAC layers simultaneously [1], [2]; other work has shown that problems inherent in wireless networks can be solved by “overlaying” one MAC protocol on top of an existing protocol [3]. This paper describes a system and policies, M ULTI MAC, that extends upon this prior work to develop a practical, deployed system that automatically selects between multiple MAC protocols. Our system builds upon the work of Farago et. al. [1] by changing the performance metrics used to guide system learning and applying that learning to finer traffic distinctions with a fielded system. The M ULTI MAC system extends S OFT MAC, another software system developed at the University of Colorado built to provide a flexible environment for experimenting with MAC protocols. The ability to cheaply create, modify and conduct system level experimentation with hardware is often a goal of many research projects. However, many of these projects ultimately fail due to the cost, time, and effort involved in deploying a large scale experimental platform. The S OFT MAC platform fills this need. S OFT MAC uses 1-4244-0013-9/05/$20.00 ©2005 IEEE

a commodity 802.11b/g/a networking card with a chipset manufactured by the Atheros Corporation to build a software radio with predefined physical layers but a flexible MAC layer. Internally, the Atheros chipset provides considerable flexibility over the format of the transmitted packets, though this flexibility is not generally exposed by network drivers. By reverse-engineering many of those controls, S OFT MAC provides a driver that allows extensive control over the MAC layer while still allowing use of the waveforms defined by the underlying 802.11b/g/a physical layers. S OFT MAC also includes a software control system that allows its users to address many of the “systems level” issues facing researchers, such as those discussed in this paper. M ULTI MAC is intended to extend the basic S OFT MAC environment to tackle problems in the areas of dynamic spectrum allocation and softwaredefined/cognitive radio. M ULTI MAC builds upon the functionality in the S OFT MAC platform with some specific goals in mind. We first wanted a system that would allow us to have multiple MAC layers coexisting concurrently in the network stack with minimal switching impact. We also wanted a system that would allow us to dynamically reconfigure the MAC and physical layers on a per packet basis either from logic running as part of M ULTI MAC or from any user level process. Finally, by leveraging these capabilities we wanted to build a system that would allow intelligent reconfiguration of the MAC and physical layers; a cognitive MAC. A cognitive MAC layer couples the efficient reconfiguration offered by M ULTI MAC with the computational intelligence required to make smart decisions about which MAC layer should be used and also which physical layer properties should be set. As M ULTI MAC evolves into a cognitive MAC, we plan to extend our experience with the current computational engine to determine what other models (un-supervised learning, Bayesian reasoning, and/or fixed adaptation strategies) are better able to tailor network efficiency by varying aspects of the MAC and physical layers through techniques like dynamic channel selection, encoding, and spatial awareness. The basic mechanism provided by M ULTI MAC can also be used to implement specific fixed MAC protocols. For example, one platform used in our work couples commodity 802.11 network cards with an inexpensive phase array antenna. The directional phase array antenna can use dynamic beam-

548

MulitMAC Basestation

High Traffic TDMA Low Traffic CSMA/CA

Fig. 1.

Dynamic MAC bridging using M ULTI MAC

forming to spatially create separate MAC zones (Fig. 1). In this instance, M ULTI MAC can act like a layer 2 bridge between the TDMA and CSMA zones; the CSMA MAC may be appropriate for local “access point” communication while the TDMA MAC may be more appropriate for “wireless backhaul” connections. CSMA frames are received by the CSMA M ULTI MAC component and are queued and rebroadcasted or “bridged” onto the TDMA zone by the TDMA MAC component. The framework allows us to instantly transition from a CSMA to a TDMA MAC. One could imagine other uses of M ULTI MAC, such as providing seamless roaming across networks supporting different MACs. Additionally M ULTI MAC offers the ability to dynamically invoke such capabilities as encryption or error correction in a dynamic manner while still supporting frames that are not encrypted or error corrected. In this paper, we begin by describing related work. This is followed by a discussion of S OFT MAC, the base system that was used to build M ULTI MAC. Then we discuss the development and implementation of the M ULTI MAC framework and our experience in using it to intelligently switch between a conventional MAC layer and one using reed-solomon forward error correction. The decision to switch between the different MAC layers is made by a user space process. This decision is based on the error rates observed in the received messages. Finally, we conclude by summarizing and outlining our future work. II. R ELATED W ORK At this point, we feel it important to distinguish the work presented in this paper from other work done in this area. M ULTI MAC on the surface bears some resemblance to the hybrid MAC approaches described in [2], [4], [5], [6], [7], [8], [9], [10], [11]. These approaches combine CSMA like bandwidth requests with scheduled allocation of bandwidth. That is, they incorporate the aspects of two separate types of MACs to form a composite MAC. Similar to these hybrid approaches there has also been some work done in creating an overlay MAC layer (OML), which attempts to overcome the fairness and allocation problems inherent in the 802.11 MAC.[3] These approaches are what we refer to as one-of-a-kind solutions. That is, a new “MAC” is created that embodies a set of requirements in order to attain a desired goal. Solutions of this nature must all interoperate at the MAC layer in order to function. M ULTI MAC’s approach is to allow the

concurrent operation of many MACs of totally different scope and design. M ULTI MAC allows frames from separate MACs to be transmitted, routed, and processed all within the same framework with little to no overhead. In addition to this type of flexibility, M ULTI MAC also allows the researcher to jump from an algorithmic approach that has been embedded within a specific MAC to one where the computational intelligence is directed at selecting the “best” MAC for a particular frame or data stream. In [1], [12], [13], Farago et al. describe MetaMAC, a method for automatically selecting an optimal MAC protocol among a set of existing protocols. Their approach is to create an adaptive layer that resides on top of a set of existing MAC protocols. Rather than relying on a centralized controller to coordinate the selection process, MetaMAC makes use of a local feedback mechanism in selecting which MAC to apply to a packet. Much of our M ULTI MAC work borrows and extends on this MetaMAC concept. An important initial difference between this work and ours is that we have an actual implementation of a MetaMAC. Our framework also provides flexibility in how and when the various MACs are selected. For example, a new MAC selection could be driven by changes observed at the MAC layer (e.g., frame errors) or it could be based on a user level process making requests to optimize reliable transmission. Other work in the area includes the application of machine learning or similar techniques to the problem of decision making within cognitive radio networks. For example, Rieser describes a biologically inspired cognitive radio engine that employs genetic algorithms to optimize the robustness of the network [14]. III. M ULTI MAC F OUNDATION : S OFT MAC The M ULTI MAC system is built on top of S OFT MAC, a flexible system for using commodity 802.11 network cards as (admittedly limited) software defined radios. We feel there is a compelling need for a software defined radio platform that is inexpensive, easy to use, and could provide at least partial control over the MAC and PHY layers. Although the National Science Foundation is funding research programs charged with developing software defined radios, these systems are still expensive (typically costing $10,000 for simple units and increasing to $100,000 for more complex systems) and relatively bulky when compared with the laptops and PDAs often used in wireless and mobile networking research. This greatly limits their utility when attempting to conduct large scale or mobile wireless systems level experiments. Furthermore, many interesting systems may still be constructed with a lesser degree of MAC and PHY flexibility than is afforded by these high-end platforms. The goal of the S OFT MAC system is to provide precise control over the content and timing of wireless transmission and reception. S OFT MAC was implemented by overriding the existing 802.11 MAC layer provided by a family of commercial networking cards. It is important to understand the design of the 802.11 MAC and PHY layers and how they

549

can help and/or hinder this goal. The key attributes of the PHY and MAC layer formats to note are: • The PHY and MAC layers have checksums, and any failure in those checksums causes the message to be ignored • The MAC protocol is controlled by a series of precise timing intervals • Contention is handled by a combination of carrier sensing and collision avoidance using specified transmission durations contained in message headers • The PLCP headers constitute a fixed overhead on each packet. At high data rate, this is about 15% of the transmission time of a packet Commodity 802.11 hardware typically divides up the functionality of the 802.11 MAC between the hardware/firmware on the card and the driver running on the host system. This means that the flexibility of such systems varies greatly between manufacturers. The S OFT MAC system relies on features of the chipsets designed by the Atheros Corporation. In particular, we have used the Atheros AR5212 chipsets and the open-source Madwifi driver[15]. Atheros uses a “hardware abstraction layer” or HAL to provide a common hardware interface for operating systems. The HAL is written in the machine code of the computer hosting the the wireless card, and abstracts common functionality across different individual chipsets. Although the HAL is distributed in binary-only format and not extensively documented, there have been attempts to produce an “open-source” HAL. We have only used these open-source references while building S OFT MAC. A. Implementing S OFT MAC Overall, there were six primary tasks we needed to perform in order to implement S OFT MAC: 1) Override 802.11 MPDU frame format 2) Eliminate automatic ACK and retransmission 3) Eliminate RTS/CTS exchange 4) Eliminate virtual carrier sense (NAV) 5) Control PHY Clear Channel Assessment 6) Control transmission backoff Performing each of these tasks required modifying different portions of the Madwifi driver. We will now discuss the details of these modifications. Overriding the 802.11 MPDU frame format means that the card will both send and receive packets that do not necessarily conform to the 802.11 standard. Many 802.11 wireless network cards can operate in either “Managed”, “Master” or “Monitor” mode. Each mode determine the events conveyed to the O/S drive by the firmware on the card. A “Managed” card acts as a station, responding to all events needed to associate with other access points or operating in an “ad hoc” network. A card in “Master” mode receives and transmits messages needed by an access point, including beacons, association requests and other management frames. A card in “Monitor” mode receives all message types, including messages that contain checksum errors or that meet the 802.11 PHY format

but not any of the 802.11 MAC message types. This is distinctly different than “promiscuous mode”, which is common in networking hardware. A wireless card in “promiscuous mode” may hear messages intended for other nodes, but it would not receive underlying MAC layer events such as ACK, RTS and CTS messages. Cards configured for “Monitor” mode receive all messages that can be decoded by the physical layer, even those that contain checksum errors and would normally be discarded. Like several other 802.11 cards, the Atheros chipset allows you to transmit in monitor mode as well. The stock Madwifi driver may be easily modified to permit monitor mode transmissions to occur as well as eliminate the encapsulation of packets in 802.11 frames. A cursory examination might deem this practically sufficient to implement a S OFT MAC system; however, the Atheros hardware modifies packets based on values of what it assumes to be 802.11 header fields. First, it stamps each outgoing data packet with the MAC sequence number. Second, it calculates the MAC checksum for the packet and appends it to the packet. However, we discovered experimentally that setting the is retry flag in the second byte of the 802.11 MAC header would stop the hardware from setting the sequence number. This is reasonable behavior because retransmitted packets maintain their original sequence number. While this still means that the second byte of the packet may not be used arbitrarily, it is a vast improvement over having an essentially unknown two byte value stamped at an offset of 22 bytes into every packet. We opted to use the first byte of the packet to carry limited information about the type of the packet, meaning that the first two bytes of the S OFT MAC packet are fixed and may not be utilized for custom MAC layer experimentation. We did not eliminate the MAC checksum at the end of the packet. This does add four bytes of unusable overhead to the end of the packet, but this is relatively small and easy to ignore because it is at the tail end of the packet. We have developed extensions in the S OFT MAC driver that simplify the precise timing of packet transmissions; although packets require ≈ 90µs to transmit, the low variance on that latency allows us to precisely control transmission times. To simplify the software development effort, we have developed a modular interface that allows the MAC designer to focus on the state machine for the given MAC. Moreover, we have developed an interface to the Click Modular Router[16] that simplifies the process of designing MAC protocols. We determined experimentally that the Atheros hardware will automatically send an ACK when it receives a unicast packet directed to it with a valid MAC CRC, even when the hardware is configured in Monitor mode. This will only occur when the bytes corresponding to the destination address field in a received packet match the six byte MAC address of the network card. While this may occur accidentally, we only observed it occurring when we explicitly attempted to do so. Accidental occurrences of this could be explicitly avoided by sacrificing the first byte of the destination address field in the 802.11 MAC header; ensuring that the “multicast” bit of the

550

5000

10000

1 mb/s − 1058.1 + b * 8.16 2 mb/s − 552.5 + b * 4.05 5.5 mb/s − 335.5 + b * 1.51 11 mb/s − 289.1 + b * 0.75 24 mb/s − 170.1 + b * 0.36 54 mb/s − 161.5 + b * 0.16

0

Time, In Microseconds

15000

Time Per Packet For 802.11 MAC on Shuttle SS51

0

500

1000

1500

UDP Payload In Bytes

Fig. 2. A linear regression model relating the minimum packet transmission time (in milliseconds) vs. packet size for an 802.11b/g wireless network at different data rates.

15000

Time Per Packet For Softmac on Shuttle SS51

5000

10000

1 mb/s − 1048.0 + b * 8.11 2 mb/s − 680.5 + b * 4.07 5.5 mb/s − 449.9 + b * 1.49 11 mb/s − 386.4 + b * 0.75 24 mb/s − 154.0 + b * 0.34 54 mb/s − 133.0 + b * 0.16

0

Time, In Microseconds

destination address is set explicitly removes the address from the range of valid unicast addresses. This byte is the fifth in the overall packet format, meaning that only five contiguous bytes at the beginning of the packet would have to be reserved. It is also necessary to eliminate the delay caused by the sender waiting to receive the ACK, as well as the sender making attempts to retransmit the packet due to failure to receive an ACK. These tasks are both easily achieved by using welldocumented features of the HAL. Eliminating virtual carrier sense and the update of the NAV is essential for controlling the timing of packet transmission. If the medium is determined to be busy, the hardware may potentially enter backoff, seriously detracting from our ability to control the timing of sent packets. Fortunately, setting the card to “Monitor” mode suppresses NAV updates and virtual carrier sense. We were not able to determine a method of completely eliminating the PHY CCA. In lieu of achieving this goal we decided to attempt to set the noise floor to such a high level that even though the PHY CCA would occur it would always report the channel to be clear. This functionality is not directly exported by the Atheros HAL. However, by examining the open source version of the HAL used in the OpenBSD project we were able to discover likely avenues to explore. In particular, the driver instructs the hardware to periodically perform a noise floor calibration. The routine in the open source HAL that performs this queries the value of a specific hardware register during this operation. We disabled the periodic calibration and added the ability to force the driver to perform the calibration on demand. We then used a signal generator to subject the card to controlled amounts of noise and observed the ensuing value in the noise floor register. An RF synthesized signal generator (HP 8660C) tuned at channel 1 (2.412GHz) was directly connected to the antenna output port of the Atheros card. The transmit power of the signal generator was varied from -130dBm to 10dBm in steps of 10dBm and the corresponding noise floor calibrated by the Atheros chipset was noted. We observed that as the transmit power of the signal generator was increased, the noise floor calibrated by the Atheros HAL increased. At lower transmit power levels (< −50dBm) the Atheros HAL exhibited some variance of the calibrated noise floor. However above < −50dBm, the calibrated noise floor was stable and had no variance. Furthermore, we observed that setting a specific value in this register has the desired effect on the PHY CCA. By setting the noise floor to a low value we were able to cause the card to backoff and defer transmission of packets even when little noise was present; setting it to high values eliminated backoff. The transmission backoff duration is easily controlled through functionality exported by the Atheros HAL. The minimum and maximum values for the Contention Window (CWmin and CWmax ) may be specified. S OFT MAC sets CWmin and CWmax to one, minimizing the duration of the backoff and making it deterministic. We further limit the duration of the backoff by setting the slot time down to the

0

500

1000

1500

UDP Payload In Bytes

Fig. 3. Regression model for time per packet using the “Ethernet over Wireless” MAC protocol on a Shuttle SS51 system with a 2.4Ghz celeron processor. Confidence intervals for the regression are within the symbol width and thus omitted.

minimum allowed. For the current Atheros HAL this value is 9µseconds. B. Performance and Experience With SoftMAC S OFT MAC performs well, and we have implemented several different MAC protocols using the software. Figure 2 shows measurements we made of a standard 802.11b network running at an 11mb/s rate. These measurements were made between a wireless station and another system behind an 802.11 access point; we explicitly controlled the transmission rate from the 802.11 access point. Measurements were made by time-stamping each packet and using that to estimate a linear regression model for the time to transmit a packet. The model estimates a UDP packet at 11mb/s as t802.11,11 (b) = 551

289 + b × 0.75µ seconds. Figure 3 shows the performance for a MAC implemented using S OFT MAC. This MAC is effectively “ethernet over wireless” - there are no ACK’s, no RTS/CTS and no NAV mechanism, as in the standard 802.11 MAC. The regression model for that data set estimates tS OFT MAC,11 (b) = 386 + b × 0.75µ seconds; the time taken per packet is slightly longer than for the 802.11 MAC for most of the modulation types. We believe this happens because S OFT MAC queues a single packet to the hardware in order to provide precise ordering of packet transmissions. By utilizing the high resolution timer built in to the Atheros hardware we determined that it is possible to send messages every 91±1µseconds at the 95% confidence level – this is may account for the additional delay when using S OFT MAC. Although S OFT MAC has been very useful, the software design only allows a single MAC to be used at a time. This leads to unwieldy code organizations and considerable complexity. For example, we are using S OFT MAC to build MAC’s for networks using directional phase-array antennas; in this system, we want to use a time-division duplexing MAC for the inter-node links that use the directional antennas. When relaying packets to local stations, we want to use a CSMA/CA MAC similar to the 802.11 MAC. The system alternates between phases of distributing local packets and directing packets to other remote systems using the phase-array antenna. This need to use multiple MAC protocols concurrently was our motivation in pursuing M ULTI MAC. IV. M ULTI MAC F RAMEWORK As with many structures in operating and network systems, its useful to decompose M ULTI MAC into mechanisms and policies. The mechanisms define the actual interfaces and constructs used to implement a specific system; the policies define how and when those mechanisms are used. A. Mechanisms for MAC adaptations M ULTI MAC acts as a mediating MAC layer between the physical device and the network stack in the Linux kernel. While M ULTI MAC appears to the system as the sole MAC layer in a standard network protocol stack, it allows the creation of other, more specialized kernel modules, such as implementations of TDMA, Aloha or 802.11. Our interfaces emphasize three aspects of MAC protocols - reception decoding, transmission encoding, and transmission timing. Individual MAC variants can be used by M ULTI MAC for decoding their respective incoming frames as well as encoding outgoing frames with a MAC best suited for particular network conditions. This process is both completely transparent to the user and system as well as being highly adaptive in operation. MAC layers can be changed on the fly without interrupting radio service or dropping frames during the transition. When a decoded frame arrives, the appropriate MAC layer must “claim” and decode the frame. Claiming a frame can be done by a number of methods, such as making use of existing frame identifiers or by adding a byte to the header of the frame for identification. Such additional mappings are

defined by a global MAC identifier (GMI) comparable to the service/protocol identifiers in other networking protocols. This avoids conflicts between competing MAC layers and also ensures that nodes using different configurations (and therefore MACs) for transmitting packets are still able to interpret and decode incoming packets from other nodes encoded with a different MAC; however, using a GMI precludes backward compatbility with existing MAC frame formats. Thus, rather than legislate a particular solution, each component MAC must provide a claim function that examines the frame indicating whether or not that MAC layer claims the frame. Individual MAC layers are probed in order until a frame is claimed; unclaimed frames are discarded. In an earlier version of M ULTI MAC, each received packet was delivered to each registered MAC. Thus allowing each MAC to either accept the packet and decode it, or drop the packet. The MAC layers in M ULTI MAC share the same physical layer implementation. That is, each MAC receives all the packets and will count the packets of different MAC implementations as “failures” or “errors”. Bandwidth or spectrum measurement policies that use feedback on packet reception failure rates will react to an artifically large number of corrupted packets. To prevent statistical errors of this type the current “claim” function returns three values indicating if A ) the packet appears to belong this MAC implementation and can be properly decoded; B ) the packet appears to belong to this MAC implementation but can not be properly decoded or C ) this packet does not appear to belong to this MAC implementation. This redesign was also necessary to reduce the impact of non M ULTI MAC traffic on our experimental platform. Because the typical experimental wireless network exists in a non-shielded environment it was necessary to filter other access point traffic to preserve the validity of our measured results (such as the count of incoming, claimed or broken packets). Currently, if none of the MACs claim a packet, M ULTI MAC discards it without letting the packet impact the statistics, thus providing a virtual, software-shielded experimental space. Kernel Network stack

TDMA

Cheesy

Aloha

MultiMAC

802.11

Corresponding MAC layer of incoming packets resolved with MultiMAC header byte

ath

Fig. 4. M ULTI MAC assigns received frames to the MAC layer that can decode them.

552

Once a packet is handed over to its corresponding MAC

layer implementation, decoding happens the same way as in an unmodified network stack (Figure 4). A mirrored, but significantly more complex, procedure takes place on the encoding side; the process is more complex because transmitting a packet involves sending a properly encoded frame that also matches the timing constraints of the MAC protocol. When M ULTI MAC gets a packet from the Linux kernel for transmission, it must decide which MAC is best suited to transmit this particular packet (Figure 5). When a MAC is selected, that it must then encode the packet and specify the transmission timing constraints. The MAC will encode and prepare the data packet for transmission the same way as it would when it was the sole MAC, with the option of adding a GMI byte if allowed by the underlying MAC layer. Additional complexity is added when allowing an underlying MAC protocol to express the timing of packet transmissions; without a close coupling between the M ULTI MAC layer and the underlying MAC protocols, whatever decision that is made is likely to be wrong or suboptimal. For example, consider the previous example of a M ULTI MAC configuation for wireless backhaul using a directional antenna; this situation is illustrated in Figure 5. A TDMA MAC used for the longdistance backhaul can increase link reliability and quality by directing the phase array antenna of different stations to point to each other; this only has value if both antennas are pointing at each other simultaneously. In our current implementation, we are experimenting with specifications similar to those used in the real-time operating systems community – individual packets specify constraints such as absolute, relative or periodic deadlines. These deadlines can be combined with statistical or model based estimates of channel occupancy for specific MAC protocols to determine if a particular “MAC schedule” is feasible. This component of the system is the least understood and under-specified in our system, but it is also one of the components that distinguishes M ULTI MAC from prior work such as Meta-MAC [1] where a specific MAC was chosen on a packet-by-packet basis with no interactions between successive transmissions. Kernel Network stack

MultiMAC chooses MAC layer of outgoing packets depending on the current traffic situation

MultiMAC

TDMA

Cheesy

get phy info

Aloha

802.11

MultiMAC

ath

Fig. 5. On the sending side, M ULTI MAC uses network status information to determine the best MAC layer to use for a certain packet.

B. Policies for MAC adaptations M ULTI MAC exports an interface to the user level where the rules for deciding which MAC to use for transmitting a certain packet are viewable and editable. Unlike other approaches [12], [3], neither the number and selection of MACs nor the rules to choose between them are hard wired into the system. This allows us to start with a policy set providing rules for the best selection of a MAC layer depending on a context and also adapt and modify these rules using, for example, machine-learning algorithms, thus turning the M ULTI MAC into a cognitive MAC. The individual policies used to select an out-going MAC protocol rely on feedback from the physical and network layers. M ULTI MAC maintains a connection to the status and diagnosis API of the Atheros chipset in the wireless card. By pulling out network status information such as the time to transmit frames, queue lengths, and bit-errored frames, M ULTI MAC policies can determine the appropriate MAC for the specified goal. In addition to the physical layer attributes, the policy interface requires that properly decoded packets specify the yield of a specific packet. Prior work, such as MetaMAC, attempted to optimize the ability of a specific MAC protocol to simply access the media, without considering the success or failure of the media access. This limits the range of possible MAC behaviors. For example, a MAC protocol that provides forward error correction with CSMA may be less successful at acquiring the media than a protocol with no error correction that uses oblivious access. However, in a noisy environment, the protocol with error correction would actually accomplish more work. The complication in this example is that stations can only estimate the “useful work” or “yield” of packets they receive; unless the channel conditions are symmetric, some additional protocol may be needed to communicate this endto-end information.1 Our initial policy set provides M ULTI MAC with a base of rules for different traffic situations where certain MAC layers outperform others. Random access or virtual carrier sense MACs like CSMA, Slotted Aloha and 802.11 provide the best performance in low traffic situations where little or no congestion and jamming is likely to occur [17]. In difficult transmission environments where a lot of bit errors are induced into the packets, M ULTI MAC may switch to MAC layers emphasizing error correction such as Reed Solomon encoding [18]. If more and more traffic has to be carried by the network (diagnosed at the node level by a dramatical increase of congestion, high queues and broken frames through interference), MultiMAC can start switching to a TDMA protocol where each node is guaranteed a certain bandwidth for transmission. Other policies can also address providing MAC layer quality of service. If the delivery of a packet isn’t critical (as in multi-media streaming, for example), less sophisticated MAC 1 While the possability of creating a “meta-M ULTI MAC” seems necessary, we are trying to avoid complexities in our current implementation.

553

protocols such as Aloha [19] can be used to provide a besteffort delivery, while another component of M ULTI MAC can provide a different application with a guaranteed amount of bandwidth.

to the frame prior to adding the MAC header. Simply put, we have two MACs implemented on each machine, one MAC incorporating forward error correction and one not. We expect the MAC incorporating Reed-Solomon forward error correction to outperform the non-error corrected MAC in low to mid-noise conditions and be less beneficial in a high-noise environments due to the introduction of additional errors. We first explore this phenomenon experimentally and then incorporate this knowledge into M ULTI MAC.

Fig. 6. Various MAC layers can be used between different types of nodes in the network.

Additionally, one can implement policies that address locality issues. Figure 6 shows a setup with three different wireless domains. Nodes within each domain are using a competing medium access algorithm sharing the available bandwidth between them while the black-circled nodes (with directional antennas) are using a different MAC algorithms for their communication, such as TDMA, providing a guaranteed bandwidth between the domains and therefore forming a interdomain backhaul. V. E XPERIMENTATION In order to show the adaptive behavior of M ULTI MAC we conducted an experiment illustrating how M ULTI MAC is able to react to changing background conditions, like noise, in order to ensure successful reception. In our experimental setup, two unobstructed M ULTI MAC base stations were placed 10 meters apart. A signal generator, equipped with an omnidirectional antenna, was placed between the two stations and was used to generate noise. The M ULTI MAC stations were setup with two functional MAC layers. The first MAC layer, called fromagemac2 , simply takes the outgoing frame and appends a CRC checksum to it. In order to identify an incoming frame as a fromagemac frame, the MAC layer also places a small identifier at the beginning of the packet. This identifier allows the fromagemac on the other machine to claim this packet and decode it. The second MAC layer, called rsmac, is identical to the first, with the exception of applying Reed-Solomon forward error correction 2 The name “fromagemac” is a take-off from one of the first MAC layers implemented using S OFT MAC. That MAC, which was essentially an Ethernetover-wireless MAC was called “cheesymac” because it was a haphazard implementation. The “fromagemac” extends cheesymac with checksums and other slight extensions; it is, in essence, a fancier “cheesymac”.

Fig. 7. Measured frame loss for fromagemac and rsmac depending on introduced noise

Figure 7 shows the experimentally determined decision points using measurements with the 802.11b PHY layer at the 2Mb/s transmission rate. For a low noise level the FEC schema is able to recover about 50% of the total errors compared to the un-errorcorrected MAC layer. It follows that a FEC MAC layer be used in mid-to-low noise conditions. As the noise level is increased, the beneficial effect of ReedSolomon is less pronounced. At this transmission rate, the the non-error corrected MAC layer clearly outperforms the MAC layer applying FEC at high error levels because the packets are physically smaller. The 25% loss rate appears to be a good choice for a transition point in the switch between the FEC and non-FEC MACs. A user level process was created to automate the response of the system to changes in noise level. This user level process monitors status information provided by M ULTI MAC via entries in the Linux /proc filesystem and commands M ULTI MAC to transition to and from the FEC and non-FEC MACs. The status information is retrieved by the user level process every 3 seconds preventing haphazard reconfigurations. The following diagram illustrates how M ULTI MAC’s responds as noise is introduced into the environment. This particular set of measurements and the rule extrapolated from those measurements was for the 2Mb/s transmission rate; this transmission rate is very resistent to errors of the sort introduced by the signal generator we used in this experiment. Other transmission rates, such as the 11Mb/s encoding, are more susceptible to transient errors, and the benefit of the

554

rsmac

rsmac fromage

Fig. 8.

Switching between MAC layers as the noise changes over time

Reed-Solomon FEC are more pronounced. We are using M ULTI MAC to develop a learning algorithm to determine the optimal encoding point for each transmission rate. VI. C ONCLUSION In this paper, we have described M ULTI MAC, a framework and experimental platform for evaluating algorithms that dynamically reconfigure MAC and physical layer properties. M ULTI MAC provides a mechanism for studying the actual behavior of MACs. It also provides an easily scalable and usable toolkit for exploring new MAC protocols. M ULTI MAC, acts as a mediating MAC layer and dynamically reconfigures and/or selects from a collection of alternative MAC layers. As a result of monitoring current network metrics, M ULTI MAC chooses the MAC layer capable of achieving the best performance while ensuring that incoming frames are decoded using the correct MAC layer algorithm. M ULTI MAC incorporates decision processes to select the individual MAC component based on per-node and per-flow statistics. This engine will allow intelligent reconfiguration of the MAC and physical layers in response to external conditions or changes in requirements in order to optimize use of the available spectrum. This work was funded by NSF award #0435452 and #0435297 under the NeTS-ProWIN program. Michael Neufeld developed the S OFT MAC system of which M ULTI MAC is the extension; he currently works at BBN. Eric Anderson contributed some experimental data to an earlier version of this paper.

[2] B. A. Sharp, E. A. Grindrond, and D. Camm, “Hybrid tdma/csma protocol for self managing packet radio networks,” in Proc. IEEE ICUPC, pp. 929–933, 1995. [3] A. Rao and I. Stoica, “An overlay mac layer for 802.11 networks,” in MobiSys ’05: Proceedings of the 3rd international conference on Mobile systems, applications, and services, (New York, NY, USA), pp. 135–148, ACM Press, 2005. [4] D. J. Goodman, R. A. Valenzuela, K. T. Gayliard, and B. Ramamurthi, “Packet reservation multiple access for local wireless communications,” IEEE Trans. Commun., vol. 37, pp. 885–890, 1989. [5] W. Wong and D. Goodman, “Integrated data and speech transmission using packet reservation multiple access,” in IEE ICC, pp. 172–176, May 1993. [6] Narasimhan and R. Yates, “A new protocol for the integration of voice and data over prma,” IEEE JSAC, vol. 14, pp. 623–631, October 1995. [7] G. Bianchi, F. Borgonovo, L. Fratta, L. Musumeci, and M. Zorzi, “Cprma: a centralized packet reservation multiple access for local wireless communications,” IEEE Transactions on Vehicular Technology, vol. 46, pp. 442–446, 1997. [8] R. Bolla, F. Davoli, and C. Nobile, “The rra-isa multiple access protocol with and without simple priority schemes for real-time and data traffic in wireless cellular systems.,” MONET, vol. 2, no. 1, pp. 45–53, 1997. [9] M. J. Karol, K. Y. Eng, and Z. Liu, “An efficient demand-assignment multiple access protocol for wireless packet (atm) networks,” Wirel. Netw., vol. 1, no. 3, pp. 269–279, 1995. [10] J. Mikkonen, J. Aldis, G. Awater, A. Lunn, and D. Hutchison, “The magic wand - functional overview,” IEEE Journal on Selected Areas in Communications, vol. 16, pp. 953–972, August 1998. [11] D. Petras, “Performance evaluation of medium access control protocols for mobile broadband systems,” tech. rep., Technical Report RACE project, January 1996. [12] A. Farag´o, A. Myers, V. Syrotiuk, and G. Z´aruba, “A new approach to mac protocol optimization,” in Proc. IEEE GLOBECOM’01, 2001. [13] A. D. Myers, G. V. Z´aruba, and V. R. Syrotiuk, “An adaptive generalized transmission protocol for ad hoc networks,” Mob. Netw. Appl., vol. 7, no. 6, pp. 493–502, 2002. [14] C. Rieser, Biologically Inspired Cognitive Radio Engine Model Utilizing Distributed Genetic Algorithms for Secure and Robust Wireless Communications and Networking. PhD thesis, Virginia Polytechnic Institute and State University, August 2004. [15] “Madwifi.” http://sourceforge.net/ projects/madwifi. [16] E. Kohler, R. Morris, B. Chen, J. Jannotti, and M. F. Kaashoek, “The click modular router,” ACM Transactions on Computer Systems, vol. 18, pp. 263–297, August 2000. [17] A. Tanenbaum, Computer Networks. Prentice Hall Professional Technical Reference, 2002. [18] I. S. Reed and G. Solomon, “Polynomial codes over certain finite fields,” j-J-SIAM, vol. 8, pp. 300–304, June 1960. [19] R. Binder, N. Abramson, F. Kuo, A. Okinaka, and D. Wax, “Aloha packet broadcasting-a retrospect,” in AFIPS Conference Proceedings, pp. 203– 216, May 1975.

“The views expressed in this article are those of the authors and do not necessarily reflect the official policy or position of the Air Force, The Department of Defense or the U.S. Government” R EFERENCES [1] A. Farag´o, A. Myers, V. Syrotiuk, and G. Z´aruba, “Meta-mac protocols: Automatic combination of mac protocols to optimize performance for unknown conditions,” EEE JSAC, special issue on: Analysis and Synthesis of MAC Protocols, vol. 18, pp. 1670–1682, 2000.

555