As stated before, support for flexibility and (re)programmability of wireless devices is crucial to cope with emerging scenarios of technology proliferation and unpredictable interference conditions. Wireless communication performance should be matched to the demands of the application being used, and should be able to intelligently exploit opportunistically available spectrum and resources in dense environments. While pursuing such an idealized, adaptive vision, the research community has mainly worked on programmable radio platforms, such as GNUradio [19], WARP [20], Airblue [21], etc. However, very recently, a different paradigm has been proposed for trading-off flexibility and ease of programmability by identifying suitable abstractions and relevant programming languages devised to formally describe wireless protocols. Such a paradigm has lead to the definition of novel programmable architectures for technologies such as WiFi and ZigBee, in which elementary commands are composed in a protocol logic defined in terms of state machines or command chains, on the basis of the following decoupling compromise:
-
wireless cards support a hard-coded (not modifiable by the MAC protocol programmer) instruction set, namely an application programming interface (API) comprising of elementary commands and signals;
-
third-party MAC programmers describe how commands are coordinated and triggered in a formal (executable) model, such as a state machine or a command chain.
These architectures enable dynamic network optimization that can be executed by a network controller by loading the most suitable protocol on the fly on the basis of a context estimate.
3.1 Wireless MAC processor
While each protocol (or protocol release) supports different features and each vendor implements a specific hardware/software card architecture, there is an interesting common set of capabilities and functions that can be exploited for defining hardware agnostic programs to be loaded on the wireless cards and change their behavior. The Wireless MAC Processor [4], whose architecture is shown in Figure 1, is based on this observation. The core of the architecture is an execution engine capable of running programs defined as extended finite state machines (XFSMs). These state machines are composed of the following: a set of signals provided by the hardware subsystems by means of an interruption block, a set of elementary functions implemented into an operation block, and a set of registers to save system state and configuration parameters. A memory block is dedicated to the storage of MAC programs (XFSMs), while a control interface is available for loading programs and tuning configuration parameters.
According to this architecture, the card does not implement a standard-specific predefined protocol, but it acts as a generic executor of state machines reacting to internal events of the system (e.g., the arrival of a new packet from the host) or external events of the channel (e.g., the reception of a new packet from the air interface). The reactions to the same signals may vary according to the system state, which includes the state of the hardware and the logical state of the programmed protocol.
3.1.1 The WMP application programming interface
A breakdown analysis of MAC protocols reveals that they are well-described in terms of three types of elementary building blocks: actions, events, and conditions.
Actions are commands acting on card hardware. In addition to ordinary arithmetic and memory related (set/get) operations, which work on system registers and queues, dedicated actions implement atomic MAC functions such as transmit a frame, set a timer, write a header field, switch to a different frequency channel, etc. Actions are not meant to be programmable. As the instruction set of an ordinary central processing unit (CPU), they are provided by the hardware vendor. The set of actions may be extended at will by the device vendor and can also include advanced operations on the PHY, such as the configuration of the physical channel and the selection of the desired encoding scheme.
Events include hardware interrupts such as channel up signals, indication of reception of a valid preamble or end of a valid frame, expiration of timers, and signals conveyed from the higher layers such as the enqueuing of a new packet. As in the case of actions, the list of supported events is a-priori provided by the hardware design.
Conditions are boolean expressions evaluated on internal configuration and statistic registers. These registers are either explicitly updated by actions or implicitly updated by events. Some registers are dedicated to store general hardware parameters whose tuning automatically affects the hardware configuration (such as the operating channel, power level, transmission format, selected packet queue), while some others store programmable data related to enqueued frames (source or destination address, frame size, etc) or MAC protocol variables (contention window, back-off counter, etc.) Registers are used to provide an interface to the PHY layer and to achieve a more compact protocol description.
Actions, events, and registers on which conditions may be set, form the application programming interface exposed to third party programmers. This API is implemented (in principle) once-for-all, meaning that programs may use such building blocks to compose a desired operation, but have no means to modify them.Figure 2 shows a simple example of state machine defined on the basis of elementary events, actions, and conditions (using self-explanatory names). The program can be coded into a table listing all possible state transition relations, an initial state, and an initial set of hardware configuration parameters.
3.1.2 MAC engine: the CPU
The ability to timely react to events is a crucial property of lower-MAC protocols (e.g., for triggering a transmission right at the end of a timer expiration). In the Wireless MAC Processor architecture, this is accomplished by implementing an XFSM execution engine, called MAC engine, directly on the radio hardware. The MAC program, namely the tables containing all the possible state transitions, is loaded in a memory space deployed on the hardware. Starting from the initial state and parameters of the selected memory slot, the MAC engine fetches the table entry corresponding to the state, reads the list of all the possible events triggering a transition from that state, and loops until one of these events occurs. It then evaluates the associated conditions on the system parameters, and if this is the case, it triggers the associated action and parameters’ updates (if any), executes the state transition, and fetches the new table entry for such destination state.
3.2 SnapMAC
One of the major issues with the radio drivers for sensor nodes is the lack of strict timing control (since the same CPU controls the radio and the user code) and the lack of flexibility. The first is a major problem when developing time sensitive protocols (such as TDMA, fast software acknowledgements,...) while the second prohibits swapping or modifying protocols at run-time. The SnapMAC architecture [5] was designed to allow easy implementation and modification of novel MAC protocols on sensor nodes without compromising the performance.
In contrast to traditional systems, where protocol logic is hard-coded, SnapMAC uses the concept of dynamic “chains” to define protocol logic. These chains are composed of small commands that each execute a single task. All information on these commands resides in the command pool, where commands are further grouped into modules, depending on the type of functionality they provide. Radio commands operate directly on the radio (turn on the radio, transmit a packet), memory commands perform memory operations (move buffer, clear memory), arithmetic commands can be used to manipulate variables (increment, decrement), etc. Finally, the flow commands can be used to control execution flow through the chain. By combining these commands, it is possible to create complex chains that execute the logic of any MAC protocol.An overview of the SnapMAC architecture can be seen in Figure 3. Two interfaces are offered to the user code: a data interface and a control interface. The data interface is used to exchange buffers that can contain data to transmit, received packets, or even spectrum-sensing information. The control interface is used to compose or modify chains and control their execution.
When activating a chain, it is possible to specify a time at which a specific command has to be executed. The scheduler will then calculate the execution time of all earlier commands to ensure that the requested timing is met. Thanks to this functionality, it is possible for MAC designers to define time critical protocols without the need to know hardware specific timing information. The scheduler will instruct the command dispatcher when to execute each command.A simple SnapMAC chain is shown in Figure 4. This chain will transmit a single packet on a specific channel and then return to the original channel. Upon activating this chain, the time at which the packets must be transmitted can be specified. When the chain is finished, the stop command can periodically reschedule this chain at a later time. This way, a simple TDMA scheme can be implemented without having to know the time it takes to change the channel or load the packet into the radio.