Exploiting programmable architectures for WiFi/ZigBee inter-technology cooperation

Recent years have witnessed an increasing adoption of heterogeneous technologies operating in unlicensed industrial, scientific, and medical (ISM) bands, thereby creating serious problems of coexistence and spectrum overcrowding. Although most wireless technologies (such as ZigBee, Bluetooth, and WiFi) have been designed to work in the presence of interference, it has been observed that performance may degrade significantly because of heterogeneous sensitivity to detect or react to the presence of other nodes and technologies.

While standardization groups are continuously defining standard amendments and extensions devised to cope with novel coexistence scenarios, the wireless research and academic community has pushed forward the vision of device programmability (started long time ago with cognitive [1] and active [2] networks) to cope with unpredictable and mutating interference situations, adapt to service demand variations and smartly exploit temporarily unused radio spectrum. In a fully programmable vision, the protocol stack defined in each standard should not be designed once for all possible deployments, but the most appropriate protocol fitting each specific context should be automatically employed when needed. In this vision, protocols would be simpler (for instance, why bother with hidden terminals in contexts where they are not present?), and backward or cross-technology compatibility would not be an issue any more.

In this paper, we specifically deal with ZigBee and WiFi technologies. Despite the fact that many mechanisms have been included in the relevant IEEE 802.15.4 and IEEE 802.11 standards to cope with interference (e.g., carrier sense, adaptive modulation and coding, signal spreading), both technologies can seriously suffer in the presence of each other [3]. Even when sufficient resources (spectrum and time) are available, coexistence problems arise because of lack of coordination due to heterogeneous carrier sense granularity [3] and operating conditions not explicitly considered by the standards.

To remedy this situation, we propose to exploit the programmable architectures recently introduced for both technologies, namely the Wireless MAC Processor (WMP) [4] for WiFi and SnapMAC [5] for ZigBee, which are powerful and versatile tools for dynamically changing the MAC characteristics of the devices. We introduce a cross-technology coordination mechanisms based on the detection of cross-technology interference and on-the-fly adaptations of the MAC protocol rules, in order to accommodate both technologies on the same interfering channels in a TDMA-like fashion. We will adapt the standard MAC behavior of IEEE 802.15.4 and IEEE 802.11 devices but will keep referring to them as ZigBee and WiFi devices for the remainder of this paper.

Several analytic and simulation models, as well as experimental studies, have been proposed for characterizing the cross-technology interference in ZigBee and WiFi networks [3, 6–8]. While most studies focus on the analysis of ZigBee performance degradation in the presence of WiFi interference, recently, it has been shown that significant throughput reductions can also be observed in WiFi networks [3, 9]. Surprisingly, WiFi vulnerabilities arise despite the fact that many mechanisms have been included at the medium access control (MAC) and physical (PHY) layer to guarantee robustness to interference. The phenomenon has been clarified by considering two different main reasons. (i) An intrinsic reason: vendor-dependent implementation choices in some cases make it difficult to detect non-WiFi modulated signals or introduce latency in the receiving chain [10]. (ii) An extrinsic reason: due to the longer sensing time required by ZigBee to detect channel activity, it can not always detect WiFi packets to prevent collisions [11, 12].

A first important requirement for proposing adaptation mechanisms in case of cross-technology interference is identifying the presence of two overlapping ZigBee and WiFi networks. The monitoring of heterogeneous radio frequency (RF) signals on ISM bands has been specifically addressed in [13]. This paper describes a monitoring infrastructure based on GNU Radio that is able to identify different technologies and demodulate received signals with the corresponding receiver modules. Although this approach is very effective, it requires additional dedicated hardware. The possibility to identify WiFi signals by using commodity ZigBee nodes has been explored in [14] and [15]. The approach proposed in [14] is based on the analysis of temporal samples of link quality indicators and received signal strength indication (RSSI) values, as well as on the identification of the portions of ZigBee corrupted packets by comparing those with typical WiFi transmission times. A similar temporal analysis is carried out in [15] with the aim to find periodic interference signatures caused by WiFi beacons and enabling the detection of WiFi networks by using a low-power monitoring interface. The possibility to detect ZigBee and other interference sources by means of WiFi commodity cards is explored in [16] by using an 802.11n PHY able to read RSSI values at different sub-carriers for characterizing spectral, energy, and pulse signals that are mapped into a technology classification scheme.

Once interference is detected, it is often required to make non-overlapping ZigBee and WiFi transmissions. However, solutions that simply choose a better channel upon the detection of interference are becoming nonviable because of the increasing number of technologies and applications in the market. Advanced solutions rely on complex and expensive radio transceivers to communicate with multiple protocols and different technologies [17], or increase the complexity of the transmission by using error correction codes or multiple antennas [18]. In addition, different approaches have considered the possibility to introduce some indirect forms of coordination between the two technologies. A time-based coordination is proposed in [10], where the authors first characterize the WiFi idle intervals in a given network scenario (called white spaces) and then adapt the ZigBee frame lengths and transmission intervals in order to maximize the probability to transmit during these white spaces. Channel reservations have been achieved in [11] by using two ZigBee channels overlapping with the WiFi one: the first channel is adapted to transmit a busy tone able to activate the WiFi carrier sense, while the second channel is used by the other ZigBee nodes to transmit their data in parallel to the busy tone transmission (i.e., while WiFi stations are prevented from accessing the channel). Other schemes introduce some simple forms of adaptive redundancy (e.g., by repeating the header in the ZigBee packet [12], whose transmission time is comparable with a WiFi packet transmission time) for improving the ZigBee resilience to WiFi transmissions that typically overlap at the beginning of the ZigBee frame because of the limits in the ZigBee carrier sense granularity.

These coordination solutions require a customized tuning of the MAC parameters used in the multi-technology interfering networks or even modifications of the medium access operations. However, making these modifications context-dependent and dynamic is not viable on off-the-shelf nodes: on one side, in WiFi nodes, low-level MAC operations are hard-coded into the network cards for efficiency reasons and only support a parametric control model (e.g., tuning of the contention windows); on the other side, even when the MAC is implemented in software as in the case of ZigBee nodes, dynamic modifications cannot be supported at run-time, without recompiling and reloading the relevant software modules.

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:

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.

For the evaluation of the above solutions, the Orbit Management Framework (OMF) and Measurement Library (OML) were used. This framework has been designed for the configuration, execution, and centralized control of network experiments and is now deployed in several testbeds worldwide (from the USA to Australia), including the European CREW testbeds [24]. It is based on a client-server architecture: resource control (RC) processes running on the testbed nodes interact with a central experiment controller (EC) and database. Based on an experiment description file this EC instructs the RC processes to launch applications, generate traffic flows, collect performance information, monitor the node’s status, re-configure the nodes when network events occur, etc.

Although the framework has been designed for experiment control, following the approach proposed in [25], we exploited the OMF primitives to define a cross-technology MAC adaptation strategy that, in principle, could work in independent and autonomously evolving wireless networks. To this purpose, we integrated some WiFi and ZigBee nodes in the CREW testbed based on the WMP and SnapMAC architecture. Moreover, we developed an OMF wrapper for both the WMP and SnapMAC control interfaces to allow the EC to invoke the control commands (e.g. for dynamically loading or activating a new MAC state machine or command chain).

5.1 Supporting a MAC cognitive cycle

We consider a MAC cognitive cycle in which: i) the sensing phase is implemented by collecting throughput and error statistics by means of dedicated monitoring applications deployed on the nodes; ii) the analysis and reasoning phases are performed at the EC by aggregating data and defining customized events to be fired when cross-technology coexistence problems arise, iii) the adaptation phase is finally achieved by loading and/or activating cross-technology TDMA programs on the controlled nodes when needed. The cycle is depicted in Figure 8. ZigBee and WiFi receivers report the achieved throughput to a central database using the OML framework; WiFi nodes also report their error occurrence statistics. This data is continuously queried by the experiment controller (EC): when throughput reduction is observed for both technologies or when the WiFi error statistics correspond with an interfering ZigBee network, the EC triggers the run-time MAC reprogramming and the cross-technology TDMA programs (defined in terms of an XFSM for WiFi nodes and a command chain for ZigBee nodes) are activated on the controlled nodes.

Note that, for our WMP and SnapMAC architectures, reprogramming a MAC protocol does not require the loading of a new software module and/or rebooting the nodes, because it is achieved by changing a parameter in the transition table (for the WMP) or command chain (for SnapMAC). Therefore, MAC reprogramming is transparent to applications and can be performed at run-time with negligible latency (corresponding to the time required to load the new parameters).

5.2 Alternative control mechanisms

The use of OMF allowed us to rapidly prototype and evaluate the performance of our cross-technology TDMA scheme, including the use of the existing control network to report node statistics to the central controller. This implementation simulates ZigBee and WiFi gateways connected to a wired backbone, but even if no existing control channel is available, several solutions are possible and are discussed in the following section.

5.2.1 Multi-technology nodes

Nodes equipped with both WiFi and ZigBee radios can act as centralized controllers or relay control traffic between the two different technologies as shown in Figure 9. This way, no additional hardware or physical channel is required. The control packets will have an impact on the application throughput, especially for low data-rate ZigBee communication, but this will be compensated by more efficient channel usage.

5.2.2 Inter-technology communication system

While both technologies are unable to decode each others packets, both are able to detect the presence of another technology. This fact is used by our TDMA implementation to synchronize the transmission intervals, but could also be used for more complex communication. For example, this technique is exploited in [26] to implement a novel inter-technology communication system, called BusyBee, that defines a modulation scheme and a message-oriented protocol that allows to exchange low-rate control information between WiFi and ZigBee nodes. A possible architecture using this method is shown in Figure 10.

5.2.3 Fully decentralized

In a fully decentralized architecture, each node can independently adapt its own operation by observing interference patterns, and no information is shared with a central controller, negating the need for a dedicated control channel. As the decision making is based on a more limited information set, this requires more intelligent adaptation strategies and can lead to sub-optimal results. As with the previous solutions, there is a trade-off between the reduced number of control messages and the throughput gain of the adaptations. While more complex, the use of flexible MAC architectures allowing runtime reconfiguration will simplify the implementation of these solutions.

Although these alternative solutions are feasible in terms of conceptual communication, OMF provides a simple way to collect measurements and detect interference patterns and was therefore used to implement our cognitive cycle.

We have tested the cross-technology TDMA scheme in the CREW w-ilab.t testbed [27], composed of over 60 nodes spread in a semi-shielded environment of 22×66 m ². We selected one pair of WiFi nodes, Alix 3C3 embedded PCs equipped with a bcm4318 wireless interface running our custom-made WMP firmware [4], and one pair of interfering ZigBee nodes, RM090 [28] motes running TinyOS and using the SnapMAC driver. During the experiments, the WiFi nodes executed the legacy state machine and reported throughput and error statistics to the central database. When triggered by the experiment controller, they switched to the TDMA state machine. The ZigBee nodes were programmed with two SnapMAC chains: on the receiving node, a simple chain was responsible for receiving and reporting all ZigBee packets. On the transmitting node, a TDMA chain was running that could switch between regular CSMA operation and TDMA operation as instructed by the experiment controller.

The WiFi nodes used WiFi channel 11 (centered at 2462 MHz) for communication while the ZigBee nodes used ZigBee channel 23 (centered at 2465 MHz). Together with a transmit power of 15 dBm for WiFi and -5 dBm for ZigBee, this realistic setup guarantees that both technologies will interfere when they transmit at the same time. Without interference, the WiFi link is capable of reaching speeds of up to 4.5 Mb/s (using a data-rate of 6 Mb/s), and the ZigBee link can reach 195 Kb/s (using the fixed data-rate of 250 Kb/s). It should be noted that the speeds reported in the following experiments are averaged over a period of 1 s. As we use a TDMA period of 100 ms, the TDMA cycles themselves are not visible in these figures.

6.1 Functional analysis

In order to verify the effectiveness of the envisioned cross-technology coordination strategy, we used a USRP node to record RSSI samples with a very high temporal resolution (at a μ s scale). This RSSI trace visualizes the channel access operations performed by both ZigBee and WiFi transmitter.Figure 11 shows an example of such a trace, using legacy access protocols (top) and cross-technology TDMA coordination (bottom). The figure clearly shows the transmission intervals where the RSSI values are higher than the background noise. Because of the different transmission powers, the RSSI values corresponding to the WiFi transmissions are about 20 dB higher than ZigBee transmissions: the power level sensed for WiFi frames and WiFi acknowledgments are, respectively, -70 and -62 dBm, while the power level of ZigBee frames is about -87 dBm.In the case of legacy access, some ZigBee and WiFi transmissions collide, resulting in a missing acknowledgment and the overlapping of transmission intervals (e.g., the trace pattern shown at 40 ms in Figure 11). In the case of cross-technology TDMA, the figure clearly shows that the two technologies operate orthogonally by alternating channel access periods. This figure also shows an idle time at the end of each period to make sure the last transmission of one period will not interfere with the first transmission in the next period. For a given period duration, this idle time can be up to about 4 ms at the end of the ZigBee period or about 1 ms at the end of the WiFi period and is equal to the time to transmit a single frame at their respective data rates. The length of this idle time could be reduced by transmitting variable length ZigBee packets, but all our experiments were performed using fixed length 120 byte ZigBee packets. Even with this modification a small guard interval would still be required to deal with synchronization offsets.

6.2 Performance analysis

The complete cognitive MAC cycle was tested by monitoring the throughput of the WiFi and ZigBee links while running the cognitive loop as described in Section 5.1. Instead of plotting the absolute throughput values, they are divided by their respective data rates to obtain normalized throughput values that can be displayed on the same scale.

The first experiment, shown in Figure 12, consists of a ZigBee link transmitting at a maximal throughput at the start of the experiment. This only corresponds to a normalized throughput of approximately 80%: the transmission of a ZigBee frame takes 4.2 ms, after which the radio requires at least 550 μ s before it is able to start the transmission of the next frame. After 58 s, the WiFi link is activated with a data rate of 6 Mb/s, and the ZigBee throughput drops from 80% to about 20%. The decreased ZigBee performance in the presence of increased WiFi throughput is identified as cross-technology interference. After a few seconds, the TDMA scheme is activated, and both technologies are assigned equally sized slots. The ZigBee throughput returns to 35% while the WiFi interferer reaches a normalized throughput of 45%. This difference is caused by the longer idle time at the end of the ZigBee slot as shown in Figure 11. While this is less than the theoretical maximum of a 50% to 50% split, this is a significant improvement over the legacy situation where interference would also cause wasted channel time. By tuning the TDMA parameters, these throughput results can be equalized or tuned to specific traffic requirements as is demonstrated in the last experiment.A second experiment was devised to monitor the packet error rate (PER) of the ZigBee link. For the entire time of the experiment, the ZigBee node transmits packets at a constant rate of 50 packets per second using the TDMA protocol. During the first part of the experiment, no interference is generated. During the second part, a WiFi interferer using legacy channel access is activated, and finally, this interferer is switched to the TDMA protocol using the same parameters as the ZigBee transmission. The results of this experiment can be seen in Figure 13, without interference the PER is close to 0%, but when the legacy interferer is activated, almost 30% of the packets are lost. After activating the TDMA scheme in the final part of the experiment, the PER for the ZigBee link again drops to 0%, and the WiFi throughput increases slightly. This indicates that a legacy interferer will cause almost 15% wasted channel time due to interference (about 30% of the ZigBee time slot). By using the TDMA protocol, this lost time is recovered, and the channel is used much more efficiently without negatively effecting the WiFi throughput.A final experiment demonstrates the capability of the cognitive solution to change and distribute the TDMA parameters at run-time. Shown in Figure 14, the experiment starts with a ZigBee and WiFi transmitter without cooperation. After 20 s, the TDMA protocol is activated and at 35 and 50 s, the allocated TDMA slots are reconfigured dynamically. During the non-optimized operation, both technologies experience collisions resulting in throughput degradation and fluctuations. During the TDMA operation, throughput results are stable and depend on the allocated slot interval. For example, ZigBee slots are equal to 30% (28 ms for ZigBee, 64 ms for WiFi), 50% (50 ms for ZigBee and 44 ms for WiFi), and 80% (79 ms for ZigBee and 14 ms for WiFi) of the TDMA period, respectively, resulting in a normalized throughput of about 23%, 35%, and 63%.

We currently do not implement the inverse adaptation cycle (from the execution of cross-technology TDMA scheme to the execution of legacy MAC operations). However, all components to support this kind of adaptation are already present and would only require extending the context detection of the coordinator and adding additional actions. Additionally, future work will also focus on further exploiting the capabilities of the re-configurable WiFi and ZigBee MAC architectures by designing cognitive solutions that can support multiple MAC protocols at the same time.

In order to test the feasibility of our cross-technology TDMA, we used a static distribution of the TDMA intervals, activated based on simple throughput measurements. As our flexible radio architectures are capable of reporting a wide range of cross-layer metrics, further research should evaluate the feasibility and impact of more advanced control algorithms that adapt the TDMA operation and interval based on this extended information base.

For the solution presented in this paper, we used the available OMF/OML infrastructure to enable the fast prototyping and verification of our cognitive solution. In a real deployment, this wired backbone would not be available but could easily be replaced by a wireless control channel to exchange configuration parameters and measurement information. Solutions such as multi-technology nodes acting as a controller, cross-technology signaling, or even completely decentralized operation can be easily implemented in the future by using flexible MAC architectures.

In this work, we have presented a dynamic coordination mechanism to improve the coexistence of ZigBee and WiFi networks in the emerging scenario of overcrowded ISM bands. In dense wireless environments, it is impossible for WiFi and ZigBee to operate in non overlapping channels and our experiments have shown that in such a situation both technologies undergo a severe throughput degradation.

The solution, explored in this paper, does not require dedicated hardware or modifications to the transmitter hardware for cross-technology interference detection, but only uses off-the-shelf ZigBee and WiFi hardware. The solution is based on the adoption of programmable MAC architectures to support run-time MAC protocol adaptations managed by a global network controller. In particular, we have proposed and experimentally verified a cross-technology TDMA protocol that can be used to efficiently share the spectrum between ZigBee and WiFi transmitters in overlapping frequency channels.

We have shown that experiment control infrastructure cannot only be used for experiment descriptions and experiment control, but also for cognitive network control. Using standard tools for experiment control, being the OMF for node management and the OML for data collection, a fully cognitive solution was created that is able to trigger protocol modifications upon the detection of cross-technology interference. The protocol itself was implemented using the flexible WMP and SnapMAC architectures, allowing fast switching between MAC protocols without downtime.

Initial experiments with a simple cognitive loop have shown a significant performance improvement for both ZigBee and WiFi by eliminating collisions between the two technologies through the activation of the cross-technology TDMA protocol: for a 50% to 50% time division, the 15% of wasted channel time in a legacy configuration can be completely recovered by using the TDMA scheme. Furthermore, we demonstrated the run-time adaptation of the TDMA parameters, showing the capability to dynamically tune the spectrum allocation according to the throughput needs of wireless applications.

The use of OMF/OML experiment control tools as a cognitive network control framework in combination with programmable MAC architectures offers a powerful framework for rapid prototyping and experimental verification of dynamic cognitive control solutions in realistic coexistence scenarios.