Colombo SDK - simulating the innards of a wireless MAC
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Colombo SDK – simulating the innards of a wireless MAC Dinan Gunawardena, Božidar Radunović Microsoft Research, Cambridge, UK Abstract Colombo is a software development kit (SDK) that speeds up prototyping of a MAC design for software defined radios (SDR). An SDR MAC is typically developed and tested on a single SDR, and it is optimized to meet strict timing requirements and constraints on interaction with other layers (e.g. MAC running in kernel code). Once a MAC is deployed in a distributed environment, new types of bugs may surge due to complex interactions among devices, and with the wireless environment. These bugs can reflect on correctness or performance of the MAC and they are typically very hard to find. Limited debugging capabilities in a test-bed in the wild, and constantly changing environment further aggravate the problem. Colombo is designed to help a developer correct the bugs arising from these interactions. It takes an arbitrary SDR MAC code and runs it in Colombo simulation environment, where execution is reproducible and bugs are easy to find. The existing network simulators (such as ns-2 and Qualnet) are based on discrete-event simulation architecture and require a specific programming model for MAC code. SDR MAC code requires substantial modification to run on these simulators, which obfuscate the original problem. The key advantage of Colombo is that it virtualizes the SDR environment and it runs the existing SDR MAC code with minimal changes. All the bugs are discovered directly in the original code. By deploying Colombo in two of our research projects we have shorten the design cycle of each project by an order of magnitude. Colombo can also be used to test performance of the proposed MAC in a larger network. The core of Colombo is a continuous event simulator. The simulator is interfaced to a particular SDR architecture through a shim layer tailored for a specific SDR architecture. We have released a shim layer for SORA, and we have also built an internal shim layer for the Lyrtech SFF SDR. However, the architecture is easily extendible to other SDR radios. Introduction Cross-layer wireless design has been traditionally evaluated using network simulators, such as (1), (2), (3). However, the PHY models used in these simulators are simplified for performance reasons and they are not able to capture the complexity of the wireless medium. More complex wireless models take a long time to simulate and are unable to capture MAC and network layer effect that happen on larger time-scales. Furthermore, wireless hardware was almost impossible to modify and real-world verification of the simulated results was very difficult and expensive. These have been fundamental obstacles to a further advance in joint PHY and MAC design in an academic environment.
Recently developed, powerful and affordable software-defined radio (SDR) platforms (4), (5), (6), (7), (8) promise to overcome these issues. PHY and MAC prototyping in these environments is much faster and cheaper than building an entire system, including the analogue part, from scratch. The new methodology has spurred a renewed interest in this research area. However, developing for SDR still incurs complexity. Wireless radios need an extreme efficiency and basic MAC operations (such as ACK) are typically executed within microseconds. SDR architectures and programming models need to respect the tight delay guarantees. One possibility is to develop the entire radio design (PHY & MAC) in an FPGA (8). This approach gives very fast execution but the programming model is less intuitive. Another possibility is to implement the MAC layer in a procedural language (e.g. C) (4), (5), (6). This MAC code needs to be highly optimized for performance and often run as a kernel driver. It also needs to respect technical requirements of a potentially complex interaction with the underlying PHY layer, with its own timing guarantees. In either case, the programming model is very involving, and several research papers are focused entirely on how to build a PHY/MAC to satisfy different SDR architectural constraints (4), (8). Additional complexity is introduced in MAC design requirements. A typical MAC standard (e.g. 802.11, LTE) consists of hundreds of pages of protocol description and its correctness has to be verified using formal methods (and an academic researcher typically does not have such resources available). Moreover, developing a novel MAC/PHY protocol may introduce a priori unknown correctness and performance issues that are artefacts of the protocol design. These issues are a usual part of any research process, and a repeated design, prototyping and testing process is a standard way to address them. To address the abovementioned complexities, researchers usually follow a process that contains two phases. Firstly, they implement a protocol in a network simulator to test the intended behaviour and performance. Then they implement it in an SDR to test the real-world issues. These two parts are completely separated. The network simulators (1), (2), (3) are event-driven simulators and have their own programming model, which includes call-backs that react to different events in the system. In principle, any simulator code could be ported to a SDR platform. In practice, this is unlikely to meet performance requirement. The code thus needs to be ported manually, and this process is prone to introduction of new bugs. A wireless network in the wild is a complex, unpredictable distributed system with very limited debugging support and most of the bugs are difficult to spot and correct. Colombo is a novel design paradigm for cross-layer protocol design which bridges the gap between prototyping for a network simulator and an SDR. Its goal is to enable a developer to evaluate a code written for an SDR platform directly in a simulator with minimal changes to the code. The main idea of Colombo is to simulate the existing code against a virtual PHY layer. The key component of Colombo is a continuous event simulator that runs each MAC at each node in separate thread(s) and “virtualizes” the environment for each thread. All calls to a virtual PHY layers are captured by the simulator and executed in a wireless simulation environment. A user can design the virtual PHY layer and the wireless simulation environment as suited his/her needs.
Colombo is flexible and can be adapted to most of the existing SDR platforms. It can be used with its
own simple wireless simulator platform. Also, it can potentially be linked to existing network
simulators (1), (2), (3) (although we have not implemented it). So far we have integrated and
successfully used Colombo with Sora and Lyrtech platform (we release only the Sora port). Colombo
was instrumental for fast prototyping of the MAC/PHY design presented in (9), (10), (11) and sped up
the design cycle by an order of magnitude.
In the following sections we describe the basic architecture of Colombo in more detail and we give
some example.
Colombo Architecture
Colombo’s architecture is illustrated in Figure 1. An existing MAC code, written for an SDR
environment, is linked with a Colombo simulator through the Colombo environment shim. The shim
overloads PHY and upper layer function calls and maps them to appropriate Colombo virtual PHY or
environment code (either by linking or through pre-processor directives). The Colombo simulator
executes each of the PHY or environment calls and returns the value to the MAC through the
environment shim. The MAC layer has no knowledge whether it runs in a simulator or in a real world
environment.
MAC (Node 1) MAC (Node 2)
simulation simulation real world
Colombo environ. shim Colombo environ. shim SDR PHY
Colombo simulator Wireless environment
Colombo wireless Network simulator
Figure 1: Architecture of Colombo SDK
The goal of the simulator is to simulate an entire network. A configuration file is used to configure
the network parameters (such as the positions of the nodes, which MACs to use, similar to classical
network simulators). Each node is assigned a separate instance of a MAC with a context block and
runs in a separate thread. If an SDR MAC implementation consists of several threads (such as the
SORA multi-threaded code), then each MAC thread will be run separately, and they will share the
parent node’s context block. A MAC instance interacts with a simulator through a Colombo
environment shim layer. The simulator uses a wireless channel simulator to calculate the outcomes
of different wireless interactions. The wireless channel simulator could potentially be replaced with
a standard network simulator (this has not been implemented so far).Node 1
Main TX loop:
ObtainNetworkPacket;
Wait until not SenseCarrier();
TransmitPacket;
time = GetTime();
while (GetTime() < time + SIFS)
if (SenseCarrier())
Colombo simulator
ReceivePacket();
if (PktCorrect() and PktAck())
For i = 1:N
pktTX = true;
Init MAC(i);
else
Suspend MAC(i);
pktTX = false;
end
end
Main loop: loop;
Resume all threads; end
Wait for sync point from all threads; end
Process new PHY events; pktTX = false;
Call traffic generators and sinks; end
Increase simulator time by ε;
Resume all threads; Node 2
end
Main RX loop:
Kill Threads; Wait until SenseCarrier();
ReceivePacket;
if PacketCorrect()
send ACK;
DeliverNetworkPacket;
end
Figure 2: An example of a simple CSMA-type of MAC
Colombo is a continuous event simulator. We illustrate its main ideas through a simple example in
Figure 2. The simulator starts by initializing and suspending all the threads, and then runs the main
loop. At the beginning of each loop all MAC threads are suspended. The simulator resumes all
threads and waits until all threads are suspended again.
Each thread runs its own MAC code. Whenever the code calls an external method (a PHY call, a call
to a traffic generator or a sink), a corresponding shim method is called. The shim method performs
all the required interaction with the virtual environment (e.g. transmitting a packet requires
transferring an array of bytes to the virtual PHY in the Colombo wireless simulator), and then
suspends the thread. Shim methods are written in bold in Figure 2, and these are the function calls
that suspend threads.
Once all threads are suspended, the simulator the wireless channel simulator to evaluate the
outcome of the wireless and other events (if any), increases the virtual (simulation) time by a small
constant number ε, and resumes the threads.
The main intuition behind the design is as follows (we do not prove correctness in this document).
Firstly, only calls to external environment can be affected by simulation time. Hence, it does not
matter how much code we execute between two external calls. Secondly, if a code executes
correctly for some ε, it will also execute correctly for any ε’ < ε. The only issue is if ε is too large, then
a complex operation that requires several external calls might execute in more time than required.
As a rule of a thumb, we choose ε an order of magnitude smaller than the smallest MAC timing
requirement. Thirdly, we assume only a single external call is an atomic operation and the sequences
of external calls at different nodes executed in parallel are arbitrary. This is exactly what happens in
reality – a node can only rely on external readings to estimate what other nodes’ states are and aMAC design has to deal with it anyway. Similarly, if a MAC implementation is multi-threaded, any synchronization among multiple threads of the same MAC has to be explicitly implemented in the MAC code. Colombo simulator interprets these synchronization primitives in the same way they are executed on a CPU. Figure 2 gives a simple example of a network with two nodes. Node 1 is only transmitting packets, and only when the medium is idle. Node 2 is only receiving packets. Calls in bold are external calls that suspend nodes’ threads. After transmitting a packet, node 1 spin-waits for SIFS amount of time or until it receives an ACK. In a discrete event simulation this loop needs to be unrolled, several event call-backs have to be added (receive ACK, ACK timeout) and processed separately. This is clearly not an efficient code implementation able to guarantee 9us SIFS time. Instead, we virtualize the environment in Colombo and execute the virtually unchanged MAC code. Discussion One interesting question is what the limitations of the Colombo SDK are. So far, we have found one class of examples of MAC code that does not work in Colombo. In this class, a MAC codes makes an implicit assumption on the speed of execution. For example, instead of checking the actual time in the spin-wait example in Figure 2, once can execute a loop a certain number of times, assuming that corresponds to the SIFS time-out. However, this is easy to fix by adding an explicit thread sleep request to the loop, or rewriting the loop to rely on external reading of the time. Further, one might argue that this class of MAC code is highly brittle to changes in the performance of the underlying CPU/clock-speed. Another interesting question is if a continuous simulator is efficient enough for large-scale simulations. In our experience it is efficient, and we managed to simulate networks with tens of nodes for tens of seconds of virtual time in a very reasonable time. However, it is possible to further optimize the Colombo scheduler. One could augment an existing MAC code to allow for predicting duration of time between different external call. This prediction could be used to adaptively set ε for each loop. However, our goal was to minimize the changes to the MAC code, and we have not further experimented with these ideas. Finally, Colombo simulation environment has only basic functionality. Channel and PHY models are simple, and the upper layers are only basic (currently we only support CBR traffic). Thus, the simulation results are of limited use. To circumvent this problem, it may be interesting to integrate Colombo with some of the well-known and more detailed network simulator, such as ns-2 or Qualnet. A simple way to do it would be to write a shim towards a discrete event simulator that would forward the events from the discrete to the continuous time simulators and vice versa. We have not experimented with this feature so far.
SORA port example
We have implemented and tested Colombo on Lyrtech (6) and Sora (4) SDR platforms. For various
licencing reasons we only release the Sora port of Colombo. We tested the Sora port of Colombo on
the example Sora MAC that comes with the standard Sora distribution. We have changed very few
lines of code in the MAC implementation. We have modified the include files to call the shim
components instead of the hardware calls. The diagram in Figure 3 shows the new shim components
that are added (pink) to interface the SORA code (blue) with the Colombo platform (green). For
example, we have implemented 10 methods in the PHY layer shim to include all the functionality
required by the Sora MAC. For more details, see the additional documents on the Sora port.
Figure 3: Architecture of Sora port of Colombo
In general, porting Sora code to Colombo one has to keep in mind 3 rules, which require no or
minimal changes to the existing code:
Clean decoupled Transport/MAC/PHY implementation: Ensure that all cross MAC/PHY
Transport/MAC calls can be virtualised using the Colombo calls. One example of an incompatible
design in the sample code is in the LatencyCheck() function, which directly accesses PHY
parameters (such as Freq.QuadPart and RateMap[Rate]) instead of using methods that could be
virtualized.
Define a context block for your MAC: Each instance of a MAC is executed in a separate thread, so
local variables for each instance have to be defined separately. Define a context block for your MAC,
encapsulate any local variables related to an instance of the MAC and add a pointer to the Colombo
MAC context block and vice versa (so that the simulator can access the Colombo block in virtualised
calls). Note that this modification does not change the MAC code, only the way one references the
variables.
Do not spin wait in the MAC: Do not assume a spin wait will take a deterministic length of time in
the simulation. Always wait for a fixed duration of time or for an external event.Bibliography 1. The ns-3 network simulator. [Online] http://www.nsnam.org/. 2. Scalable Network Technologies. Qualnet. [Online] http://qualnet.com/. 3. Glomosim. [Online] http://pcl.cs.ucla.edu/projects/glomosim/. 4. Microsoft Research. SORA. [Online] http://research.microsoft.com/sora/. 5. Rice University. WARP. [Online] http://warp.rice.edu/. 6. Lyrtech. SFF SDR. [Online] http://www.lyrtech.com/products/sff_sdr_development_platforms.php. 7. Ettus Research. USRP. [Online] http://www.ettus.com/. 8. Airblue: A System for Cross-Layer Wireless Protocol Development. Man Cheuk (Alfred) Ng, Kermin Elliott Fleming, Mythili Vutukuru, Samuel Gross, Arvind , Hari Balakrishnan. 2010. ACM/IEEE Symposium on Architectures for Networking and Communications Systems (ANCS). 9. Efficient and Fair MAC for Wireless Networks with Self-interference Cancellation. Nikhil Singh, Dinan Gunawardena, Alexandre Proutiere, Bozidar Radunovic, Horia Vlad Balan, Peter Key. 2011. WiOpt. 10. Bozidar Radunovic, Alexandre Proutiere, Dinan Gunawardena, Peter Key. Exploiting Channel Diversity in White Spaces. s.l. : MSR-TR-2011-53, 2011. 11. Bozidar Radunovic, Ranveer Chandra, and Dinan Gunawardena. Adaptive Preambles for Coexistence. s.l. : MSR-TR-2011-15, 2011.
You can also read
