Co-Simulation Based Platform for Wireless ... - Semantic Scholar

Co-Simulation Based Platform for Wireless Protocols Design Explorations Alain Fourmigue, Bruno Girodias, Gabriela Nicolescu, El Mostapha Aboulhamid Ecole Polytechnique de Montr´eal Abstract—Longer range, faster speed and stronger link are today’s wireless mandatory characteristics. Tremendous efforts are being deployed to create new and improved wireless protocols. However, these new protocols are being tested in harsh and uncontrolled environments. Simulation tools help to capture the expected behavior, but the proposed designs might not work in real life situations due to lack of accurate simulation models. Testbed platforms are able to test designs in real life settings, but the flexibility of the design is reduced and design exploration becomes a complex task. This paper presents a hybrid platform composed of a simulation tool and a testbed environment, which makes it possible easily design and accurately test new wireless protocols.

I. I NTRODUCTION Wireless is ubiquitous and new applications are multiplying every day. Remote medical assistance, just-in-time logistics systems, mobile live video streaming conferencing will all take advantage of wireless [1]. Slowly but surely, the 3G is becoming integrated into our daily lives. Meanwhile, the 4G prepares and promises to integrate various wireless technologies such as WiFi (LAN), WiMAX (MAN), GSM/WCDMA (WAN)[2]. Users demand more and wireless applications are getting more complex. The Physical (PHY) layer needs to be reconfigurable. The Media Access Control (MAC) layer needs to support QoS and security. The network layer needs more complex algorithms to support more sophisticated network topologies like mesh networks. In the wireless domain, there is still a gap between the modeled and the real-life designs. Tools like Matlab/Simulink[4] are frequently used for modeling PHY layers and IF/RF interface. However, these tools are forced to have a very high abstraction of the upper layers like the MAC layer and may compromise on important details. Also, the emergence of cross-layer designs necessitates a tightly coupled simulation/test of all the protocol layers. For a complete conception flow, model-based design simulation necessitates its seamless integration to a testbed platform. We make it possible by using co-simulation with modelbased tools like Matlab/Simulink and a real-life environment. This article presents a platform for designing wireless protocols. This platform uses Matlab/Simulink as a simulation tool and Linux as a testbed environment. Matlab/Simulink provides us with model-based design and Linux offers us a flexible environment with real-life applications and drivers which can host real final MAC implementation. The main contribution of this article is to provide a set of generic interfaces to embed a MAC layer in a Linux driver and communicate both with the PHY layer simulated in Matlab/Simulink and the Linux network stack. Therefore, it is

978-3-9810801-5-5/DATE09 © 2009 EDAA

possible to evaluate the MAC and PHY layers working together with the Linux TCP/IP stack, processing real data produced by any of the various network applications that run under Linux. The remainder of this paper is organized as follows : section 2 discusses related work, section 3 overviews the platform, section 4 describes the needed interface, section 5 gives an example of protocol in the proposed platform, and section 6 presents the concluding remarks. II. R ELATED WORK Wireless networking is a very active research domain, consequently there exist a very large number of network simulators and testbeds [5-13]. The two most popular network simulators are NS-2[14] and OPNET[7], which both support simulation of TCP/IP protocols and classic MAC protocols. Another simulator, the TrueTime simulator, is more recent in the networking domain and has the pecularity to use model based designs [10]. This platform consists of a Simulink block library which is used to simulate networked control systems. TrueTime introduces a kernel block to simulate a real-time environment. However, compared to NS-2 and OPNET, the TrueTime’s layers models are not as accurate [7]. Although network simulators provide a good degree of flexibility and reusability, they are often criticized for their lack of accuracy and precision [6, 8]. Therefore, network’s simulators may not be able to truthfully capture a real wireless environment, since they lack in accurate protocol implementations. To evaluate protocols with representative traffic and applications, many designers choose to evaluate their designs and concepts by using real environment platforms called testbeds [6, 8]. Most of the proposed testbeds [5, 6, 8, 5, 11] in the literature preferred the Linux platform. The possibility to integrate specific hardware like antennas or FPGAs (through device drivers) to a real networking implementation (i.e. the Linux TCP/IP stack), makes it a really attractive environment for researchers and designers. Any application built on TCP/IP can be used as an application for testing purposes. However, producing a testbed is time consuming and requires a lot of effort, whereas pure simulation has the advantage of being flexible and reusable. Therefore, a growing number of platforms for wireless protocol design try to merge simulation and testbed environments [6] to get the best of the two worlds. Hydra [15] seems to be currently the best effort towards these types of environments. It is a flexible Linux-based testbed that can be used to validate wireless protocols. Hydra uses software based MAC and PHY. To facilitate experimentations,

Hydra uses the Click framework [16] for its MAC implementation. Click allows users to write modular packet processing modules[8]. However, for the users who already have a MAC implementation (i.e. a driver for instance), it can be a waste of time to implement it again with Click. To remedy this problem, we provided a generic Linux network driver which can host an exiting or newly developed wireless MAC implementation and makes it communicate both with the upper layers (i.e. the Linux network stack) and the lower layer (i.e. the PHY layer simulated in Matlab). Alongside to our driver, we provided a PHY I/O and a co-simulation interface which makes it possible for the embedded MAC protocol to interact seamlessly with the PHY Simulink model. At the same time, the structure of the driver integrates naturally the MAC layer to the standard Linux TCP/IP stack. III. P LATFORM OVERVIEW The platform presented in this paper is based on the Linux environment. By integrating seamlessly simulation tools like Matlab/Simulink with the Linux TCP/IP stack, it offers a comprehensive development suite for implementing and exploring MAC protocols as well as PHY layers.

Fig. 1. Platform overview

Figure 1 presents an overview of the platform. It shows the different layers and their respective running address space in Linux. Like most modern operating systems, Linux uses different address spaces. Users’ applications execute in userspace where they run in an unprivileged mode. They cannot interact directly with the hardware, whereas the kernel uses a protective memory space called kernel space and has complete access to the hardware. A. Application Layer Deploying Voice over IP (VoIP) and Internet Protocol for Television (IPTV) over wireless medium has raised unprecedented quality and performance issues. To face theses challenges, tomorrow’s protocols have to be validated with real-life

applications. Skype and Asterisk are two popular applications using VoIP. As they are also available under Linux, the platform presented in this paper allows the designer to use any of them to evaluate his design. More traditional applications like http or ftp clients, are available as well. B. Transport and Network Layer Nowadays, the TCP/IP protocol suite is at the core of almost every application written for networking. From the early years of Linux, TCP/IP has been present in the kernel. The platform presented in this paper proposes to use different IP policy routings’ rules and settings to simulate a network composed of several nodes. Therefore, a single machine is enough to simulate the flows of packets that would normally take place between the different nodes of a wireless network. C. MAC Layer In our design, the MAC layer is implemented as part of a Linux driver, which is the classical approach to implement MAC layers under Linux. In Linux, a driver can be compiled as a kernel module that can be loaded on demand. Therefore, the MAC implementation is a piece of code that can be added to the kernel at runtime. Thus, it is possible to get short and predictable responses and changes take place immediately without rebooting the machine. We provided a generic Linux driver that can embed the designer’s MAC implementation thanks to a well defined interface. The MAC implementation can even be written in an object oriented style even if it is not the approach retained by ordinary drivers. In brief, designers can litteraly plug their own MAC implementation into the platform provided they respect the basic rules of our interface. Usually, drivers are written to access the hardware, but in our case, there is no hardware since it is simulated by Matlab. The main role of our driver is to forward the packets to the user space so that they can be processed by Matlab. At the same time, our driver declares a network interface which is the entry point to the kernel network stack. Thus, the embedded MAC layer can communicate with the kernel stack. In Linux, any network transaction is made through a network interface. Eventually, the driver’s privileged role allows us to choose exactly how the PHY simulation appears to the kernel stack (i.e. as a real device). D. PHY Layer In our approach, the PHY Layer is composed of two elements : (1) PHY I/O and (2) PHY SIM. These two components are interfaced together using the co-simulation technique. More details will be presented in section 4.3. 1) PHY I/O: The PHY I/O component runs as a user process. It is in charge of collecting the frames produced by the driver and making them accessible to the co-simulation interface. Once the transport on the medium has been simulated by the PHY SIM component, the PHY I/O returns the data to the driver.

2) PHY SIM: The PHY SIM allows the designer to simulate the functionality of PHY. Our approach favors design-based models as the main driver of the complete layers simulation. In a design-based model, the model of the system is at the centre of the design process, from specifications capture to the final design and from the implementation to carry out final tests. Our approach allows the designer to completely abstract the PHY layer and to encapsulate MAC PDUs with traditional Ethernet PHY. This allows the designer to concentrate on the MAC layers and quickly test MAC layers concepts without a precise PHY model. IV. I NTER AND INTRA LAYERS INTERFACES The following section will present the different interfaces needed to make all the different layers work together, thus creating a platform for protocol design. A. Interface between TCP/IP and MAC The proposed platform can simulate a Point to Multi Point network composed of several nodes on the same computer. This generates some routing problems. In a multiple computer simulation, each machine has its own Linux TCP/IP stack and its own routing table. Therefore, no routing conflict is generated from sent and received packets between nodes. In a single computer simulation, only one Linux stack is used and the same local routing table is shared.

To circumvent this issue, the proposed platform uses a kind of Network Address Translation (NAT) mechanism to correct this default Linux kernel internal behavior. NAT is an effective way to change the IP address information in IP packets so packets can be controlled and routed properly for adequate wireless network design topology. B. Interface between MAC and PHY I/O Traditionally, the MAC layer would interact directly with a hardware device via a data exchange mechanism (most often a DMA mapping). In the proposed platform, the hardware device is simulated by tools like Matlab/Simulink which runs in user space while the MAC layer, embedded in a driver, executes in the kernel space. The need to transfer data between the kernel address space and the user address space in an efficient manner is a source of concern. The proposed platform uses the PF PACKET protocol family, a standard Linux feature which allows a user application to inject and retrieve packets directly at the level of the network interfaces. The PHY I/O opens a RAW socket specifying the PF PACKET protocol family. From then, any packet sent through the socket is directly passed to the driver and any packet received by the driver is by directly passed to the PHY I/O process.

Fig. 3. MAC and PHY interfaces Fig. 2. Routing issue

Figure 2 presents the routing conflict. Linux represents every node simulated with a different network interface (wlan0, wlan1, wlan2). This example illustrates an infrastructure network. When station A sends a packet to station C, the packet will be transmitted through station B. The packet should be routed to the interface wlan2 to simulate the transmission to station C (as shown by the dashed line). However, as these IP addresses are locally hosted addresses, Linux will send the packet to the loopback interface. This behavior is not suitable for adequate wireless network topology simulation and real-life testing.

Figure 3 presents the MAC and PHY interactions. A TX and RX ring buffers are allocated by the PHY I/O to handle the packets. The PHY I/O calls the standard routines sendto and recvfrom to exchange packets directly with the driver. C. Interface between PHY I/O and PHY SIM We provide an intra-layer interface for the exchange of packets between the PHY I/O and the PHY SIM is required. This interface enables communication and synchronization between Simulink and a user application running under Linux. In our previous work, we proposed a generic co-simulation interface able to communicate and synchronize data and events from/to Simulink to/from Linux’s user process. The behavior

of this interface was formally defined and verified in [17] and implemented in [18]. This approach was applied for the definition of the PHY I/O PHY SIM Interface. This interface is implemented as a Simulink S-function block programmed in C++. The communication and synchronization is ensured using the triggered subsystem component from Simulink library and the Inter-Process Communication mechanisms (eg. shared memories, semaphores) available in Linux. More details on this implementation are presented in [18]. V. W IRELESS PROTOCOL IMPLEMENTATION To demonstrate the platform presented earlier in this article, we have chosen to implement the IEEE 802.16-2004 protocol [19] to simulate a WiMAX network. It is a very complex protocol; hence, we focused only on mandatory features. We present a Simulink PHY model and a MAC implementation that can be integrated with the interfaces presented in the previous section. A. PHY layer (Model-based design) Nowadays, one can find different models available through Mathworks [20]. These models can be used and modified for a quick start in one’s wireless protocol design. The proposed PHY model (Figure 4) was designed from the 802.11a demo available through Simulink and was modified appropriately to respect the IEEE 802.16-2004 standard [19]. The model supports all the basic blocks: randomization, Reed-Solomon codec, convolutional codec and interleaving. The model includes mandatory modulation: BPSK, QPSK, 16QAM and 64- QAM. The model simulates OFDM (orthogonal frequency division multiplexing) transmission with 200 subcarriers, 8 pilots and 256-point FFTs. Presently, the proposed PHY does not model time windowing of OFDM symbols and short training sequences. For channel simulation, the PHY model uses Simulink’s dispersive multipath fading channel block, however, one can choose from different channel blocks available like the Rayleigh and Rician fading channel models. B. MAC layer (Linux drivers) The 802.16 specifications define several entities and concepts such as QoS scheduling which raise some issues while writing the driver. This section describes the solutions we propose to respect the constraints imposed by the Linux drivers’ design. To avoid expensive copying of the payload, Linux uses the same buffer structure to manage a packet while going through the network stack layers. To get better performance, we keep using the structures allocated by the network stack, even if we have to allocate some more bytes to insert the 802.16 MAC headers. The 802.16 MAC performs some tasks like scheduling the queued MPDUs, which are quite complex and can’t be executed by few instructions. We have to be carefull when we implement these time-consuming tasks because much code in the driver executes from interrupt context. We use the tasklets mechanism

to implement the fastidious tasks. Tasklets allow a task to be differed until it is safe to be executed. This MAC layer implementation, integrated in a functional driver, made us realize that it would be possible to build generic libraries, which could then be reused for future MAC layer implementations. VI. C ONCLUSIONS AND FUTURE WORK This paper presented a platform for building wireless protocols. Inspired by existing projects, we proposed a novel approach in design which consists in co-simulating a modelbased design environment with the Linux environment. This allows us to be the closest to final implementation and use the Linux environment as a testbed platform. The platform supports implementation of realistic modern protocols. PHY layers can be accurately modeled by tools like Matlab/Simulink and MAC layers final implementation can be validated in the Linux environment. From the illustrative example, we were able to define the problematic of building wireless protocols and able to demonstrate the concepts put forward in this article. Future works will focus on refining the interface between layers to ease the exploration of cross layer designs. Work will also be done to make the platform integrated into Eclipse and to start defining generic libraries specific to MAC layers. R EFERENCES [1] B. Karlson and al., Wireless Foresight: Scenarios of the Mobile World in 2015, England: John Wiley & Sons, Ltd, 2003. [2] J. Qaddour and al., Evolution to 4G wireless: problems, solutions, and challenges, ACS/IEEE International Conference on Computer Systems and Applications. p. 78. [3] P. Yanik, Migration from Simulation to Verification, EDA Tech Forum, 2004]. [4] MathWorks, http://www.mathworks.com, 2008. [5] I. Haratcherev et al., PowerBench: A Scalable Testbed Infrastructure for Benchmarking Power Consumption, Int. Workshop on Sensor Network Engineering (IWSNE), 2008. [6] A. Jansang et al. Framework Architecture for WLAN Testbed, (AMOC 2004), 2004. [7] G. F. Lucio et al., OPNET modeler and Ns-2 - Comparing the accuracy of network simulators for packet-level analysis using a network testbed, WSEAS Transactions, 2003. [8] K. Mandke et al., Early Results on Hydra: A Flexible MAC/PHY Multihop Testbed. pp. 1896-1900. [9] H. Mitsuhashi et al., A Testbed with a Practical Smart Antenna for Directional MAC Protocols in Ad hoc Networks. 2007 [10] A. Cervin et al., Simulation of networked control system using TrueTime, Proc. 3rd International Workshop on Networked Control Systems: Tolerant to Faults, 2007. [11] D. A. Armstrong et al., A Rapid Prototyping Platform for Wireless Medium Access Control Protocols. 2007. [12] OMNet, 2008; www.omnetpp.org. [13] M. Hnnikinen et al., TUTWLAN QoS Supporting Wireless Network, Telecommunication Systems, 2003. [14] NS-2, 2008; http://www.isi.edu/nsnam/ns/. [15] Hydra Project, 2008; http://hydra.ece.utexas.edu/. [16] Click, 2008; http://read.cs.ucla.edu/click/. [17] L. Gheorghe, F. Bouchhima, G. Nicolescu et al., Semantics for ModelBased Validation of Continuous/Discrete Systems. pp. 498-503. [18] F. Bouchhima, G. Nicolescu, E. M. Aboulhamid et al., Generic discrete -continuous simulation model for accurate validation in heterogeneous systems design, Elsevier Science, Microelectronics journal vol. 38, no. 6-7, pp. 805-815, 2007. [19] IEEE 802.16-2004, 2007; http://standards.ieee.org/. [20] MathWorks - File-Exchange, 2008; http://www.mathworks.com/matlabcentral/.