MAC–Engine: A New Architecture for Executing MAC Algorithms on Commodity WiFi Hardware Francesco Gringoli
Domenico Garlisi, Pierluigi Gallo, Fabrizio Giuliano, Stefano Mangione, Ilenia Tinnirello
Dept. Information Engineering University of Brescia, Italy
[email protected]
Dept. of Electronic and Electrical Engineering University of Palermo, Italy
[email protected] ABSTRACT
these simple interfaces allow to test various MAC protocols (including a TDMA-like access paradigm), they are affected by some intrinsic limitations. It is, in fact, the CPU of the PC that hosts the WiFi hardware to run these protocols by setting up the device registers through memory mapped I/O, and by sending and receiving packets through direct memory access transactions. Unfortunately due to the unpredictable jitter and latency affecting hardware interfaces like PCI busses, current solutions cannot guarantee: i) a precise scheduling of medium access times; ii) a programmable management of frame replies; iii) a fine-grained control of the radio tunings. In principle, a solution for avoiding the limitations of the OS timings is working directly on the card CPU at the firmware level. However, current monolithic firmwares are tight coupled to the underlying hardware, and can be programmed by vendors only. A first tentative to define a open firmware for the Broadcom chipset has been recently proposed in [8]. Unfortunately any modification or extension requires a deep knowledge of the Broadcom platform and the re-implementation of spread portions of the code. Goal of this demo is proving that MAC operations can be programmed by exploiting the card CPUs, without requiring advanced assembling capabilities and hardware architecture understanding. Such programmability is enabled by a new firmware architecture, according to which the protocol control is decoupled in terms of: i) a MAC engine able to run Finite State Machines, whose transitions are triggered by hardware events and require actions on the hardware; ii) a MAC program, specified in terms of a programmable Finite State Machine, which abstracts the hardware interactions.
In this demo, we prove that the flexibility supported by off–the–shelf IEEE 802.11 hardware can be significantly extended if we move the control of the MAC programming interface from the driver to the firmware, i.e. from the host CPU to the card CPU. To this purpose, we introduce the concept of MAC–Engine, that is an executor of Programmable Finite State Machines (PFSM) implemented at the firmware level: we show how the card itself can support different protocol logics thanks to PFSM bytecode representations that can be dynamically injected inside the card memory at run-time without incurring in down time issues or network disconnect events. We provide different PFSM examples in order to test the functional thoroughness of the programming interface provided by the MAC–Engine architecture. Finally, we introduce an experimental PFSM development framework, that can translate a graphical PFSM representation into an optimized bytecode. Categories and Subject Descriptors: C.2.5 Computercommunication networks: Local and Wide-Area Networks Access schemes General Terms: Design, Experimentation.
1.
INTRODUCTION
The significant research work on WLAN performance optimizations and the recent interest for cognitive radio networks has boosted the proliferation of research platforms devised to develop and test new and extensible MAC protocols. An increasing attention has been dedicated to SDR platforms [1] coupled to multi-core CPUs, DSPs or FPGAs, in order to provide full flexibility on the PHY layer control, while guaranteeing standard protocol timings [2, 3, 4]. Indeed, since MAC layer experimentation does not strictly require PHY layer programmability , an interesting alternative to these expensive platforms is using the powerful configuration interface of modern 802.11 chipsets for developing a MAC layer programming interface. For example, by accessing the chipset configuration registers and by hacking the drivers, in [5, 6, 7] software modules running on top of the driver implement a basic MAC programming interface able to: override the frame format, suppress automatic ACKs, eliminate RTS/CTS exchange, disable virtual carrier sense and transmission backoff. Although it has been shown that
2. 2.1
THE MAC–ENGINE Architecture
Wireless card architectures have tremendously evolved in the last years in order to transfer to the host processor the functionalities which do not require strict time constraints. While old devices were designed according to a full-MAC approach, where the control of all the MAC functionalities were entirely performed by the card, recent devices exploit an innovative soft-MAC approach, where important MAC primitives are supported by the driver on the host. Our architecture, proposed within the EU Project FLAVIA [9], extends the soft-MAC approach by decoupling the protocol control into an hard-coded part implemented in the card firmware and a programmable part exposed to the host (as
Copyright is held by the author/owner(s). WiNTECH’11, September 19, 2011, Las Vegas, Nevada, USA. ACM 978-1-4503-0867-0/11/09.
99
MAC mgmt service
HOST
MAC data service
load init state
MPDU generation
MLME
execute state event list executeprefetch action
state action
event polling
MAC program
WAIT_ACK
load init state execute card general yes purpose code
event list prefetch
event next event polling no
event change state change occurred state ?
CARD
MAC engine
event list no occurred?finished
event no
next event
event list finished
transmission
reception
transition action
yes
yes
END_TIMER OR RCV_OTHER update_cw()
yes
WAIT_DIFS_BK
CH_UP stop_timer()
END_TIMER [(backoff == 0) && (HOL == HP)]
END_TIMER [backoff != 0] resume_backoff()
BACKOFF
no
WAIT_MED
(a)
END_TIMER switch_TX() TX_start()
END_BK [queue == empty]
CH_UP freeze_bk()
IDLE QUEUE_OUT_UP [medium == busy]
Transition no condition verified?
TX
END_BK [queue != empty]
END_TIMER [(backoff == 0) && (HOL == LP)] set_backoff()
CH_DOWN set_timer(DIFS)
yes Transition condition execute verified?
REC_ACK
no
yes execute transition action
MED_DATA_CONF Switch_RX set_timer(ACK_TIMEOUT)
CH_UP stop_timer()
QUEUE_OUT_UP [medium != busy] set_timer(DIFS)
WAIT_DIFS_NO_B
(b)
Figure 1: MAC–Engine architecture: (a) host/card functionalities; (b) engine flow chart; (c) MAC programs. sentation in terms of a bytecode. We also developed a graphic PFSM editor on the Eclipse platform and a bytecode compiler able to change the PFSM graphical representation into a firmware understandable bytecode.
shown in fig. 1-a). In other words, we change the firmware role from implementing a given (unmodifiable) MAC protocol logic to implementing an executor of generic state machines, called MAC–Engine1 . Formally, a state machine is specified by a list of states and transitions. In a Mealy state machine the transition is given by a source state, a trigger event, an action, and a target state. On the basis of a predefined set of events and actions, representing the MAC programming interface, different state machines can be defined, loaded on the card shared memory and executed by the card firmware. The MAC programming interface has been defined starting from the analysis of different use cases (a TDMA-like, an hybrid reservation/contention, and a multi-channel access protocol) which, in our opinion, cover most of the MAC programmability requirements emerged so far. We identified the list of events and actions supported by the card that allow representing the considered use cases in terms of PFSMs.
2.2
3.
DEMONSTRATION DESCRIPTION
Our demonstration has two main goals: a functional goal, devised to prove that the envisioned application interface can easily support different protocols; a performance goal, devised to prove that our cheap platform can guarantee standard protocol timings and a dynamic reloading of new programs, without requiring any firmware re-compilation. We will present the MAC engine architecture and demonstrate the ease of defining a MAC program by exploiting our graphical editor and compiling tool-chain. We will also show some pre-defined MAC program examples, exploiting different programmability features exposed by the card. Our demonstrator will also provide a customized tool for monitoring the performance of MAC program executions. In particular, we will show the capability to guarantee a precise scheduling of the medium access times and standard interframe spaces by post-processing a channel observation trace in terms of busy/idle times. We also show some user-level appreciable performance figures, by playing a video/audio streaming, in presence of background traffic, under standard DCF and under an hybrid reservation/contention access scheme. We prove that it is possible to dynamically switch between different MAC programs without stopping the firmware execution.
Implementation
We implemented our new firmware architecture on a Broadcom AirForce54G chipset coupled to a b43 soft-MAC driver. The chipset has a general purpose processor, for which assembling tools are available. Moreover, since an open source firmware has been released for this chipset, information about registers, timers and transmission and reception commands are available. Specifically, the platform is equipped with: a 8 MHz CPU with 64 registers, arithmetic, binary, logic and flow control operations; 4KB of data memory with direct or indirect access; a template memory for composing packets; a 32KB code memory; hardware configuration (e.g. channel, power, etc.) and hardware notification (e.g. packet queued, plcp end, crc failure, etc) registers. Starting from the open firmware experience, a new firmware has been developed for implementing the MAC engine. The firmware works as summarized in fig. 1-b. For each state, it continuously monitors the event registers, until a transition event is detected. Such an event triggers the execution of the corresponding action and the transition to the destination state. The PFSM program (fig. 1-c) is usually represented by a table of transitions, in which the generic (i, j) element specifies the event and action labels connecting state i to state j. We coded the events and actions exposed as MAC API with 1 byte each, thus leading to a MAC program repre-
4.
REFERENCES
[1] USRP. The universal software radio peripheral. http://www. ettus.com/. [2] K. Tan, et al. ”Sora: High Performance Software Radio Using General Purpose Multi-core Processors,” in NSDI 2009. [3] http://warp.rice.edu/trac. [4] M.C. Ng, at al. ”Airblue: A System for Cross-Layer Wireless Protocol Development”, Proc. of ACM/IEEE ANCS 2010. [5] M.H. Lu, et al. ”Using commodity hardware platform to develop and evaluate CSMA protocols”, Proc. of ACM WiNTECH 2008, Sep. 2008, pp. 73-80. [6] M. Neufeld, et al. ”SoftMAC - Flexible Wireless Research Platform”, Proc. of HotNets, Nov. 2005. [7] C. Doerr, et al. ”MultiMAC - An adaptive MAC Framework for Dynamic Radio Networking” Proc. of IEEE DySPAN 2005, Nov. 2005, pp. 548-555 [8] Open firmware for WiFi cards. http://www.ing.unibs.it/openfwwf/. [9] European Union 7th Framework Programme ICT project FLAVIA, http://www.ict-flavia.eu/
1 We chose to abstract the MAC control in terms of generic state machine execution, since most MAC protocols are formally described in terms of state machines and many firmware implementations follow such a description.
100
