Ramon Dos

Reis Fontes

Mohamed Mahfoudi

Walid Dabbous

Thierry Turletti

Christian Rothenberg

How far can we go? Towards Realistic Software-Defined Wireless Networking Experiments

Keywords: Mininet-WiFi, Software-Defined Wireless Networks, OpenFlow, IEEE 802.11

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

I. INTRODUCTION

WiFi is ubiquitous and has become an indispensable part of our daily lives. IEEE 802.11x standards are present in almost any portable devices and allow rolling out wireless infrastructures based on access point devices at a relative low cost. While the IEEE 802.11x standards keep steadily evolving, there are still many structural barriers to openness that prevent the wireless infrastructure to adapt, be customized, allow for differentiation, and leverage all wireless capacity around us as consequence of being an infrastructure closed to innovation [START_REF] Yap | Blueprint for introducing innovation into wireless mobile networks[END_REF].

It is believed that the concept of Software-Defined Networking (SDN) [START_REF] Kreutz | Software-defined networking: A comprehensive survey[END_REF] applied to wireless networks, commonly referred to as Software-Defined Wireless Networking (SDWN) [START_REF] Jagadeesan | Software-defined networking paradigms in wireless networks: A survey[END_REF], [START_REF] Costanzo | Software Defined Wireless Networks: Unbridling SDNs. Software Defined Networking (EWSDN)[END_REF], can break down current structural barriers and contribute to a more innovative ecosystem. In spirit of (wired) SDN principles, SDWN decouples control and data planes, enabling the wireless network to become programmable by abstracting the underlying infrastructure from applications and network services that are offered with higherlevel APIs. As a consequence, wireless network infrastructures are presented with new deployment paths of research ideas around seamless communication over heterogeneous wireless networks [START_REF] Hossain | Vehicular telematics over heterogeneous wireless networks: A survey[END_REF], high transferring data over wireless medium [START_REF] Tarokh | Space-time codes for high data rate wireless communication: performance criterion and code construction[END_REF], energy optimization [START_REF] Khajuria | Energy optimization and lifetime enhancement techniques in wireless sensor networks: A survey[END_REF], among others [START_REF] Jagadeesan | Software-defined networking paradigms in wireless networks: A survey[END_REF], [START_REF] Costanzo | Software Defined Wireless Networks: Unbridling SDNs. Software Defined Networking (EWSDN)[END_REF].

The path towards actual roll-out is not without significant challenges, such as hardware availability, protocol implementations in software, resource constraints, realistic evaluation models, development and testing costs and efforts, and so on. Simulators, emulators and testbeds are common tools and approaches used in experimentally-driven research to evaluate the functionality and performance of networks. Aspects such as scalability, reproducibility and cost-benefit, among others, make the simulation and emulation the most preferred methods [START_REF] Imran | A survey of simulators, emulators and testbeds for wireless sensor networks[END_REF].

In the context of supporting SDWN research, a number of alternatives have been developed such as DCE/ns-3 [START_REF] Mancini | Demo abstract: Realistic Evaluation of Kernel protocols and Software Defined Wireless Networks with DCE/ns-3[END_REF] and OMNeT++ [START_REF] Varga | An overview of the omnet++ simulation environment[END_REF]. However, existing simulation tools face several limitations. For instance, OMNeT++ has its own switch/AP implementation and does not support third-party controllers. DCE/ns-3 uses API-specific glue code for its POSIX and kernel support, which does not cover system calls for all applications. Another common weakness of existing tools is the lack of 802.11 scan mechanisms which are critical for layer-2 handover mechanisms.

Addressing the gaps in SDWN experimentation tools from an emulation standpoint, we propose Mininet-WiFi [START_REF] Fontes | Mininet-wifi: Emulating software-defined wireless networks[END_REF] as an emulator for SDWN that: (i) allows the execution of real code with no modification in either kernel or applications, (ii) is able to support best of breed open source technologies (e.g., OpenvSwitch, any existing OpenFlow controller), (iii) supports the Linux mac80211 framework that allows testing most of the IEEE 802.11 functionality leveraging user space tools (e.g., hostapd and wpa supplicant), among others. Mininet-WiFi is a fork of the container-based Mininet network emulator [START_REF] Lantz | A network in a laptop: Rapid prototyping for software-defined networks[END_REF] extended to support WiFi by adding virtualized WiFi Stations (STAs) and Access Points (APs). Mininet-WiFi inherits all characteristics of Mininet, including the container-based emulation, a category of network emulation which allows the creation of small emulated networks on commodity hardware through the use of kernel level virtualization techniques [START_REF] Peach | An overview of linux container based network emulation[END_REF]. Like real testbeds, Mininet-WiFi runs real code (e.g., OS kernel, external SDN controllers applications) with real traffic (pcap traces or actual physical, 802.11-enabled devices). Like simulators, it supports arbitrary topologies and well-controlled yet dynamic, real-time environments at low cost.

In this article, we pose the question on how far can we go in performing realistic SDWN experiments acknowledging that there is no tool that fits all scenarios and that the research and deployment path is dominated by fundamental trade-offs intrinsic to each approach (i.e., testbed, simulation, emulation). More specifically, we try to answer the question on delivering realistic SDWN experiments based on the design choices and current capabilities of Mininet-WiFi, which include the support of (user-defined) mobility models, wireless channel propagation models, the ability to integrate with physical devices (e.g., smartphones) [START_REF] Fontes | Mininet-wifi: A platform for hybrid physical-virtual software-defined wireless networking research[END_REF], among other researcherfriendly features. To assess our claims of Mininet-WiFi delivering a sweet spot for realistic and reproducible SDWN experimentation, we reproduce related work experiments, we present a novel use case based on SSID-based forwarding, and we carry extensive evaluation work to validate the propagation models with traces and results from the R2lab testbed. 1 We also present the ability of replaying network conditions from the real world by taking into account observed variations in terms of bandwidth, latency, and packet loss. The remainder of this article is organized as follows. The next section provides a primer on SDWN by introducing relevant concepts to understand the applicability and relevance of experimental tools. Section 3 discusses simulators, emulators and testbeds as candidate platforms to support experimentation in wireless networks. Section 4 presents the Mininet-WiFi emulator and the main features allowing realistic SDWN experiments. Section 5 presents the experimental outcomes of a real testbed compared to the results obtained with Mininet-WiFi and the DCE/ns-3. Section 6 showcases an approach to replay captured traces supported by Mininet-WiFi. Finally, Section 7 concludes with some final remarks and avenues for future work.

II. PRIMER ON SOFTWARE-DEFINED WIRELESS NETWORKING

Software-Defined Wireless Networking (SDWN) [START_REF] Jagadeesan | Software-defined networking paradigms in wireless networks: A survey[END_REF], [START_REF] Costanzo | Software Defined Wireless Networks: Unbridling SDNs. Software Defined Networking (EWSDN)[END_REF] is based on providing programmatic centralized control of the network outside wireless-enabled devices (Access Points -APs) which enforce the data plane instructions (i.e.. policy decisions) received from the controllers. The principles of SDWN are similar to those of Software-Defined Networking (SDN) [START_REF] Kreutz | Software-defined networking: A comprehensive survey[END_REF], i.e., a networking approach based on a programmatic separation of the control plane (aka. Network OS) from the data plane (aka. forwarding-or data-plane). The software-defined approach allows administrators to specify the behavior of the network in a logically centralized manner and at a higher-level through APIs provided by the controller platform that implements southbound interfaces to the forwarding devices -the OpenFlow protocol [START_REF] Mckeown | Openflow: Enabling innovation in campus networks[END_REF] being the most popular southbound interface (as illustrated in Figure 1) but not the only one, CAPWAP [START_REF] Yang | Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)[END_REF], FORCES [START_REF] Doria | Forwarding and Control Element Separation (ForCES) Protocol Specification[END_REF], or NETCONF [START_REF] Enns | Network Configuration Protocol (NETCONF)[END_REF] are also candidate protocols in scope.

SDWN has become an emerging and significant research branch of SDN, mainly driven by the increased interest of mobile network operators [START_REF] Bernardos | An architecture for software defined wireless networking[END_REF], [START_REF] Sama | Software-defined control of the virtualized mobile packet core[END_REF] and the synergies with Network Function Virtualisation (NFV) [START_REF] Han | Network function virtualization: Challenges and opportunities for innovations[END_REF]. The separation between control and data planes has existed in the wireless domain prior to SDN and OpenFlow. Indeed, IETF standardized both LWAPP (Lightweight Access Point Protocol) RFC5412 [START_REF] Calhoun | Lightweight Access Point Protocol[END_REF] and CAPWAP (Control And Provisioning of Wireless Access Points) RFC4564 [START_REF] Yang | Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)[END_REF]. several years ago. Many enterprise WLAN management systems use protocols such as LWAPP and CAPWAP to manage their wireless network systems. LWAPP defines the control messaging for setup and path authentication and run-time operations whereas CAPWAP is based on LWAPP and enables a controller to manage a collection of wireless access points. Within the Open Networking Foundation (ONF), the Wireless & Mobile Working Group (WMWG) is defining a common ground architectural framework along the necessary OpenFlow protocol extensions or enhancements to realize the identified use cases while leveraging related work in other Standards Developing Organizations (SDOs) such as 3GPP, IEEE, NGMN, ITU, ETSI, IETF, etc. As per [START_REF] Foundation | Wireless & mobile[END_REF], over 15 use cases have been identified, ranging from flexible and scalable packet core to unified access networks, encompassing different elements of OpenFlow-based or OpenFlow-oriented wireless and mobile network domains.

SDWN research in academia has bloomed over the last years (refer to [START_REF] Jagadeesan | Software-defined networking paradigms in wireless networks: A survey[END_REF] for a comprehensive survey), including proposals such as OpenRoads [START_REF] Yap | Blueprint for introducing innovation into wireless mobile networks[END_REF], Odin [START_REF] Suresh | Towards programmable enterprise wlans with odin[END_REF], OpenRF [START_REF] Kumar | Bringing cross-layer mimo to today's wireless lans[END_REF], Ethanol [START_REF] Moura | Ethanol: Software defined networking for 802.11 wireless networks[END_REF], among others. Architectures such as Cloud-Mac [START_REF] Dely | CloudMAC -An OpenFlow based architecture for 802[END_REF] and Chandelle [START_REF] Monin | Chandelle: Smooth and Fast WiFi Roaming with SDNOpenFlow[END_REF] integration challenges with traditional switches and CAPWAP. One issue with CAPWAP is that it tries to solve both control and provisioning/management at once, opening the door for conflicts due to the split of roles, e.g., consider the management layer hazards of an AP receiving a CAPWAP firmware update command.

Wireless RAN Mobile terminals

Identified benefits of integrating WLAN and OpenFlow [START_REF] Foundation | Wireless & mobile[END_REF] are commonly related to centralized management and monitoring, unified policies, increased programmability and finegrained control of WLAN functions. Taking into account these benefits and the limitations associated to CAPWAP -arguably the most advanced (closed) solution today for centralizing wireless networks management prior to SDN-some questions are inevitable: "Is CAPWAP in scope of SDWN?", "How to improve the OpenFlow specification to support centralized management of wireless networks?", "Are radical new designs required?" or "How much can be leveraged from currently deployed infrastructures?". Although these questions are still majorly open, some noteworthy initials steps are undergoing. There is IETF work [START_REF] Cao | Alternate Tunnel Encapsulation for Data Frames in CAPWAP[END_REF] on extending the CAPWAP protocol to support separate termination points for management, control and data plane tunnels, and the definition of the role of an AP and its controller(s) in RFC7494 [START_REF] Shao | IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP)[END_REF]. In spirit of the longerterm mission and deliverables of the ONF WMWG, the Open-Flow protocol specification version 1.5 (section B.6.3 [START_REF] Foundation | Openflow switch specification -version 1[END_REF]) includes a revised behaviour when sending packets out to incoming ports, which was a longstanding issue when mapping wireless interfaces to switch ports.

In addition to CAPWAP-based products, there are multiple proprietary solutions (e.g., Aerohive, Aruba, Cisco HDX, Meraki, Ruckus) based on external controllers to manage a collection of APs. These commercial solutions introduce a number of extensions to standardized protocols or define their own APIs between the controller and APs, presenting differences in the refactoring of control and data plane functions in addition to a series of proprietary radio resource enhancements. While arguably all these solutions have proven to work well at scale, their cost is often prohibitive for many deployments and raise concerns due to their closely integrated nature, the consequent vendor lock-in, and the inability for in-house or third-party innovations.

As today, the most realistic way to experiment with WiFi and OpenFlow together is using open source firmware and OS solutions like OpenWRT that allows turning commodity wireless routers into OpenFlow-enabled switches. However, like any real testbed, such approach is subject to challenges related to the costs and scale of the experiments, in addition to reproducibility constraints as well as high setup times. Wireless SDN simulators and emulators, on the other hand, are interesting alternatives allowing to work with multiple devices (e.g. APs and STAs) at reasonable scale in experimenterdefined environments. Before detailing our proposed research path based on the Mininet-WiFi emulator, we next briefly survey the main available SDWN research platforms.

III. WIRELESS SIMULATORS, EMULATORS AND TESTBEDS

This section provides an overview of notable simulators, emulators and testbeds identifying their main characteristics towards a better understanding of the trade-offs when aiming at supporting realistic SDWN experimentation.

As is well-known but commonly underestimated or misjudged when choosing an experimental platform to support research efforts, each environment excels in some aspects but is subject to certain limitations and/or constraints, as depicted in Figure 3. While the exact quantification of each characteristic and the degree of realism ultimately depend on the accuracy of the model implemented in each specific tool among other platform aspects that may affect each feature, Table I (adapted from [START_REF] Zimmermann | Architecture of the hybrid mcg-mesh testbed[END_REF]) aims at illustrating the main strengths and shortcomings typically common to each type of experimentation approach as a first guide to choose the best type tool for a given set of research goals and constraints.

Turning now the attention to specific wireless simulators and emulators, Table II compares a number of features including Type (e.g., Simulator/Emulator, Open/Close source), Programming Language (which language the solution is written) and finally Supported Protocols (relevant protocols available by default), Last Activity (i.e., recent updates). Similarly, Table III attempts to categorize and compare relevant wireless testbeds considering different criteria.

As we can see, there are a couple of alternatives for OpenFlow-based SDWN experimentation such as DCE/ns-3, OpenNet, OMNeT++, and the Estinet and Nitos testbeds. Under the emulation/simulation space, OpenNet [START_REF] Chan | Opennet: A simulator for software-defined wireless local area network[END_REF] highlights as recent work (arguably closest to Mininet-WiFi) on combining DCE/ns-3 and the Mininet SDN emulator [START_REF] Lantz | A network in a laptop: Rapid prototyping for software-defined networks[END_REF] to provide rich SDWN experimentation features by allowing the execution of external controllers and real applications at the cost of a strongly coupled solution. In addition, OpenNet does not provide high-level abstraction APIs for wireless links nor emulation of wireless nodes (e.g., access points and stations are not equipped with wireless network interfaces), and neither mechanisms to select new access points before disconnection of current link to further shorten handover latency.

As today, there is few information regarding Estinet, which according to the developers can be used for many different scenarios, including SDN. Being a proprietary solution and due to its testbed nature, the availability to the wider research community is limited. Nitos, in turn, supports four OpenFlow switches and allows users the possibility to conduct experiments in indoor and outdoor environments.

Table IV compares Mininet-WiFi and DCE/ns-3. 2 In general, in contrast to Mininet-WiFi, DCE/ns-3 does not incorporate real-world network stacks yet and might not support execution of unmodified applications and/or without kernel modification. Another important weakness of DCE/ns-3 is about the development and/or improvements for IEEE 802.11. DCE/ns-3 depends on the development of new models while Mininet-WiFi relies on the mac80211 wireless stack of the Linux kernel. On the other hand, DCE/ns-3 supports greater variety of mobility and propagation models and also Long-Term Evolution (LTE) and because of this, DCE/ns-3 has been [START_REF] Zimmermann | Architecture of the hybrid mcg-mesh testbed[END_REF]) very useful during the development of Mininet-WiFi, serving as a basis for reference implementation.

Characteristic Simulators Emulators Testbeds Total Cost ••• ••• ••• Overall Fidelity ••• ••• ••• Replay Real Traces ••• ••• ••• Real Applications ••• ••• ••• Traffic Realism ••• ••• ••• Timing Realism ••• ••• ••• Scalability ••• ••• ••• Maintainability ••• ••• ••• Flexibility ••• ••• ••• Replication ••• ••• ••• Isolation ••• ••• •••
IV. MININET-WIFI Mininet-WiFi is a fork of Mininet [START_REF] Lantz | A network in a laptop: Rapid prototyping for software-defined networks[END_REF] extended with the required classes to add wireless channel emulation, node mobility, and support of 802.11 through SoftMac, a MAC layer that provides a flexible environment for experimenting with MAC protocols. The main components of the Mininet-WiFi architecture are illustrated in Figure 2. In the kernel-space, the module mac80211 hwsim is responsible for creating virtual Wi-Fi interfaces, enabling the creation of stations and access points. Still in the kernel-space, MLME (Media Access Control Sublayer Management Entity)3 is realized by stations, while hostapd is responsible for the counterpart task at the user-space side in APs.

Mininet-WiFi relies on a couple of standard Linux utilities such as iw, iwconfig, and wpa supplicant. The first two tools are used for interface configuration and for getting information from wireless interfaces while the latter is used with Hostapd in order to support WPA (Wi-Fi Protected Access), among other tasks. Both infrastructure and ad-hoc networks are supported. Another fundamental utility to realize the emulation of the wireless channel is TC (Traffic Control), 4 a user-space utility program used to configure the Linux kernel packet scheduler to control packet rate, delay, latency, and loss. TC applies these attributes in virtual interfaces of stations and APs, allowing Mininet-WiFi to replicate with high fidelity the actual packet behavior as observed in the real world. The mobility and propagation models do not require any kernel modification or changes in the applications. More details about both mobility and propagation models are discussed below.

••• ••• propagation models ••• ••• supported technologies WiFi LTE/WiFi

A. Mobility

Current mobility models supported by Mininet-WiFi include: Random-Walk, Truncated-Levy Walk, Random- Direction, Random-Waypoint, Gauss-Markov, Reference-Point and Time-Variant Community. In addition to these readily available model, the user is able to determine all positions that a node have to pass through and also its speed. This is important, because the user may have total control over the motion of the nodes. Basically, the mobility is defined by the Equation 1: First, we determine the interval time (intervalT) that the node will move to and them we calculate the motion (that includes the speed of the node) based on both initial (initPos) and final position (finalPos) previously defined by the user for getting what we call by motion factor (fac). Finally, we take both initial position and motion factor in order to calculate the next position of the node (defined and updated by pos) until the final position.

B. Propagation Models

In the current version, Mininet-WiFi supports Free-Space, Log-Distance, Two-Ray Ground, and International Telecommunication Union (ITU) propagation models. Other propagation models can be easily implemented by extending a single class for propagation models. Propagation models calculate the power of the signal received by station (RSSI) and translate them into "equivalent" network attributes in practice, like the maximum supported rate or the expected packet loss. Equation 2 shows how the RSSI is calculated.

First, the user must set the propagation model (defined by PropagationModelFormula) to be used (free-space is defined by default if no propagation model is set) in order to calculate the path loss (PathLoss). Diverse parameters are considered in the propagation models' formula, such as distance between transmitter and receiver, frequency, system loss, etc. Then, the RSSI (signalStrength) is calculated taking into account the transmission power (pT), antenna gains of transmitter (gT) and receiver (gR) and the Path Loss.

The RSSI is used to calculate the maximum supported rate during a communication between two nodes. We first rely on the technical specification of the physical devices (e.g., commercial wireless NIC) to define the custombw thresholds. The link bandwidth depends on the actual signal strength (RSSI) and the maximum supported rate for a specific RSSI. Finally, taking into account the distance between the transmitter and receiver, the rate is calculated through Equation 3.

rate = custombw * (1.1 -dist ) (3)
A similar approach is used to calculate packet loss. However, as there is no specification for actual packet loss, we only take into account the distance between transmitter and receiver as depicted in Equation 4.

loss = (dist * 0.2)/100 (4)
Equations 3 and 4 are based on generic approaches that by default try to mimic the behavior presented by R2lab. In the future, we plan to further improve the models by supporting minstrel,5 a mac80211 rate control algorithm, and wmediumd, 6 related work that provides enhancements on the wireless medium for mac80211 hwsim.

C. Scenario Diversity

As previously discussed, Mininet-WiFi supports both infrastructure and ad-hoc networks modes, i.e., it supports APs where stations may connect to and stations are also able to directly connect to each other. Both infrastructure and ad-hoc modes can coexist in the same topology/experiment, extending the variety of possible experimentation scenarios. As an example of ad-hoc networks, Mininet-WiFi supports VANET (Vehicular Ad Hoc Networks) scenarios through an integration with SUMO (Simulation of Urban MObility) providing the node mobility patterns. Further features in scope of diverse SDWN scenarios include support of Wi-Fi Direct (or Wi-Fi P2P), a technology developed by the Wi-Fi Alliance to replace the Wi-Fi ad-hoc mode, user-defined control on node mobility to allow limiting the region of motion (even when default mobility models are used), replaying network conditions (see Sec. VI-C); and allowing hybrid environments blending real physical nodes (e.g. smartphones) with the emulated environment as publicly demonstrated [START_REF] Fontes | Mininet-wifi: A platform for hybrid physical-virtual software-defined wireless networking research[END_REF] and further discussed in the use case experiments (see Sec. V-C). Further diverse scenarios enabled by the experimenter-friendly features are being driven by the user community. 7

D. Limitations

Mininet-WiFi is under continuous development driven by SDWN experiments that define the feature roadmap. As of today, a number of limitations worth to note include: (i) lack of mechanisms for channel contention (e.g. CSMA-CA), as well as for MAC layer retransmission and interference; (ii) WDS -Wireless Distribution System support;8 (iii) although beacons can be captured using any packet sniffer, changes on the RSSI by the propagation models in place are not included in the packet header yet; and (iv) any inherited limitations from Mininet, mainly concerning performance fidelity under high workloads and overall scalability in terms of total amount of nodes interfaces before performance fidelity degrades which ultimately depends on the system platform (e.g., number of cores, memory, etc.).

V. USE CASE EXPERIMENTS

This section showcases how Mininet-WiFi facilitates fast prototyping and experimentation of SDWN use cases along its ability to reproduce experiments from the literature. All code and instructions to reproduce the four selected use cases (and further ones) are publicly available in the source code repository 9 and documented in a comprehensive user manual.

A. Wireless n-Casting

This use case aims at replicating OpenFlow wireless work [START_REF] Kiong Yap | Lossless handover with n-casting between wifi-wimax on openroads[END_REF] on bicasting over multiple wireless links. The original experiment consisted of a video streaming application running in a mobile station, equipped with two WiFi and one WiMax interface, and receiving the packet flow over multiple radios simultaneously (n-casting). The mobile station was attached to the multiple APs using the same SSID and OpenFlow rules were used to duplicate packets in the wired network and re-write the L2/L3 headers at the radio access points. As a result, the quality of experience is improved by compensating packet loss over one wireless link by the duplicated stream received over the alternative links(s).

In the strawman scenario shown in Figure 4(a), we use Iperf to measure the bandwidth between STA3 and H4 during 60s. STA3 has two wireless interfaces and both interfaces are connected to different APs (AP1 and AP2), which are connected to an OpenFlow controller as well as the switch S1. OpenFlow rules ensure that packets are copied and sent through the different paths to the stations. During the first 20s the measured bandwidth is about 40Mbps, which seems coherent with the 54Mbps limit of each interface in mode g. When the time reaches 20s one wireless interface is disconnected (from AP2) causing a traffic decrease. The bandwidth at the station increases again when the wireless interface is connected back to AP2 at 40s (Figure 4(b)).

B. Multipath TCP

We now showcase the use of MPTCP (MultiPath TCP), 10 a TCP extension that allows end-hosts to use multiple paths to maximize network utilization and increase redundancy.

Previous work [START_REF] Nam | Towards Dynamic MPTCP Path Control Using SDN[END_REF] presented the integration of Mininet and physical wireless devices in order to evaluate the gains of MPTCP in conjunction with SDN path control. We show The topology setup (Figure 5a) consists of 1 station (sta1) acting as a client and 2 access points (ap2 and ap3), with the distance between sta1 and ap2 being 8.06 meters and 1.41 meters between sta1 and ap3; 1 host (h10) acting as a server; and 1 OpenFlow controller responsible for the flow control based on a network-wide view. In order to obtain the results presented in Figure 5b, we measure the bandwidth between sta1 and h10 using ifstat to report network interfaces bandwith for each packet transmission. As expected, the results show that the data is transmitted by the two Wi-Fi interfaces of sta1 (sta1-wlan0 and sta1-wlan1) and the amount of data received by the sta1-wlan0 interface is less than sta1-wlan1 (around 1.97Mbps and 5Mbps, respectively), due to the different modes of operation (IEEE 802.11g and IEEE 802.11n) used in each interface. Following the configuration provided by the AP TP-Link TLWR740N 11 chosen for this experiment, theoretically, up to 54Mbps over 802.11g and up 11 to 130Mbps over 802.11n can be provided when the signal is up to -68 dBm. Considering the signal strength measured at the station -34.3 dBm over IEEE 802.11g and -19.1 dBm over IEEE 802.11n, the maximum data rate capacity is consumed. 12 The maximum data rate is calculated by taking into account the rate supported by TP-Link TLWR740N and Equation 3.

C. Hybrid Physical-Virtual Environment

This use case experiment was first presented in [START_REF] Fontes | Mininet-wifi: A platform for hybrid physical-virtual software-defined wireless networking research[END_REF] and features a hybrid physical-virtual environment where real users connect their 802.11-enabled smartphones to interact with the virtualized infrastructure, including nodes forming a mesh subnetwork, and access the global Internet after having its traffic processed through a multi-hop OpenFlow network. Figure 6 illustrates the scenario, where virtual and physical mobile devices are able to interact with each other with the switch behaviour being defined by an OpenFlow Controller.

The OpenFlow controller initially discovers the topology and installs the required L2 flow entries to allow connectivity between the APs. Next, the user connects to AP1's SSID and tries to access any Internet Web page via HTTP. The Open-Flow controller installs one rule to re-write the IP destination address and to re-direct all user's HTTP traffic to a captive portal where the user is expected to authenticate in order to get Internet access and unlock the initial bandwidth limits enforced through OpenFlow 1.3 metering actions. The user can also communicate (e.g. PING) with mobile nodes forming a mesh network.

D. SSID-based Flow Abstraction

This use case illustrates the ability of fostering SDWN research and experimentation by prototyping and trying out ideas around SSID-based packet forwarding as illustrated in Figure 7. This scenario is similar to the one described in [START_REF] Cook | Simultaneous multi-mode wifi differentiated by ssid[END_REF] but is novel in the OpenFlow implementation choice. We mimic the case presented by the authors by assigning unique Service Set-Identifier (SSID) for each user (or group of users) and managing all flows through an OpenFlow controller that defines different bandwidth limit on an SSID basis. It is very common for an organization to have multiple SSIDs in their wireless network for various purposes, including: (i) to provide different security mechanisms such as WPA2-Enterprise for your employees and an "open" network with a captive portal for guests; (ii) to split bandwidth among different types of service; or (iii) to reduce costs by reducing the amount of physical access points.

Using multiple SSIDs requires the AP to map each station to a different network connection. Traditionally, this fixed mapping is accomplished through VLAN tagging. In our case, we use the OpenFlow protocol to apply rules based on input/output ports as instances of the SSIDs abstractions. Multiple SSIDs are created in APs and each SSID is linked to separated sub/virtual interfaces. OpenFlow rules defined how traffic is being handled and allowed through different SSIDs. By acting on ports, no changes were required to the OpenFlow protocol in order to support this use case. One drawback in our current implementation is the WiFi NIC limit of 8 sub/virtual interfaces per virtual interface constraining each AP to handle up to 8 different SSIDs whereas commercial WLAN solutions are known to be able to create up to 64 SSIDs per AP.

To the best of our knowledge, this is the first time that traffic based on a specific WLAN attribute (SSID) is defined through OpenFlow rules. The technique is an example that may lay the groundwork for the implementation and evaluation of more sophisticated scenarios using Mininet-WiFi, for instance: (a) Wi-Fi Hotspots for Public Wireless Access [START_REF] Wang | Tr-321 -public wi-fi access in multi-service broadband networks[END_REF]; (b) Community Wi-Fi [START_REF] Wang | Tr-321 -public wi-fi access in multi-service broadband networks[END_REF]; and (c) virtual Service Providers (vSPs) [START_REF] Saucez | A virtual Service Provider for SOHO networks[END_REF].

VI. EXPERIMENTAL VALIDATION

This section delves into experiments to assess the realism of the wireless channel emulation and overall end-to-end system provided by Mininet-WiFi. To this end, we conduct a series of experiments in R2lab, 13 an anechoic wireless testbed that 13 http://r2lab.inria.fr/overview.md R2lab consists in a set of thirty-seven nodes on the ceiling of a room of approximately 90m 2 distributed in mesh layout to offer an advanced simulation Wi-Fi site (see Figure 8). Being an RF anechoic chamber built into a screened room, it provides a suitable environment for high-fidelity, reproducible Wi-Fi experimentation.

A. Propagation Model

In order to evaluate the propagation models implemented in Mininet-WiFi, this case experiment uses R2lab nodes to obtain the signal received by the stations with varying distances.

1) Approach

We first choose some nodes [START_REF] Jagadeesan | Software-defined networking paradigms in wireless networks: A survey[END_REF][START_REF] Imran | A survey of simulators, emulators and testbeds for wireless sensor networks[END_REF][START_REF] Peach | An overview of linux container based network emulation[END_REF][START_REF] Doria | Forwarding and Control Element Separation (ForCES) Protocol Specification[END_REF][START_REF] Han | Network function virtualization: Challenges and opportunities for innovations[END_REF], 24 and 28) as reference nodes, where node 3 acts as the transmitting station and the other nodes as receivers (APs) located at different distances. 14 All the nodes were configured with specific rate mask limited to 11Mbps, running in mode b, channel 6 and transmission power equal to 15dBm. Then, we used readily available instrumentation (wireshark) to record the RSSI between the communicating nodes and compared them with the RSSI values provided by the three supported indoor propagation models in Mininet-WiFi. Parameters for each propagation model include:

• Free-Space: system loss = 2 • Log-Distance: exponent = 3; system loss = 2 • ITU: power loss coefficient = 32; floor penetration loss factor = 0; number of floors = 0 Note that variations in these parameters directly influence the outcome of each propagation model. System loss is a factor which is not related to propagation; exponent represents the path loss exponent whose value is normally in the range of 2 to 4 depending of the type of environment; power loss coefficient represents the quantity that expresses the loss of signal power with distance; floor penetration loss factor is an empirical constant dependent on the number of floors the waves need to penetrate; and number of floors represents the number of floors. Being user-defined parameters in the propagation class of Mininet-WiFi, the parameters can be tuned according to observed in particular scenarios with "snowflake" characteristics (e.g., room geometry, obstacles, etc.), a fact that can be exploited when aiming to reproduce physical experiments using Mininet-WiFi.

2) Results

Figure 9 illustrates the results obtained for the same experiment setup in R2lab and Mininet-WiFi. We can observe the relationship between RSSI and distance, i.e., the signal decrease as the distance between the transmitter and receiver increases. Based on these results, we conclude that the ITU propagation model is more appropriate. Furthermore, based on the measured RSSI values, the model can be calibrated to reflect with more accuracy the conditions of the target environment, R2lab in our case for the follow-up experiments. All logs from R2lab experiments can 14 Node 33 was not chosen due to observed misbehavior at the time of the experiments.

be found at https://github.com/ramonfontes/miscellaneous/tree /master/r2lab.

B. Simple File Transfer

We now aim at assessing the end-to-end user/application experience in a real setup, ns-3 and in Mininet-WiFi. The experiment consists of transferring a single file between two nodes in the R2lab testbed (Figure 10) and measure the transferring time, throughput, latency and packet loss. Then, we replicate the same scenario (e.g., node distance, WiFi modes, etc.) in Mininet-WiFi and ns-3 in order to compare the similarity of the obtained results and hence assess the realism that the different tools provide compared to a testbed experiment.

1) Approach

We select node 13 as the AP and nodes 3 and 24 as the server and client, respectively (see Figure 10). We then transfer a 62.6MB file between server and client by using wget over TCP and repeat this process for 10 times and measure the total transfer time, throughput, delay, and packet loss. Relevant setup details of this experiment towards reproducibility include: a) nodes working on channel 1, transmission power equals to 15dBm and IEEE 802.11b enabled; b) distance between nodes 3 and 13, and 13 and 24 equals to 2.72m and 4.08m, respectively.

2

) Results

As we can observe from the results presented in Table V, the experiment run in Mininet-WiFi yields results very close to those obtained in the R2lab testbed. The observed difference of the average transfer time of 10 runs (stdev) is only 5 seconds of a total of about 180 seconds. The measured bandwidth and end-to-end latency are also quite similar. When compared to the results obtained in ns-3 for the same configuration 15 we observe higher throughput over the wireless channel but less goodput. Inspecting the pcap capture we observe a high amount of TCP retransmissions and also out-of-order and duplicated packets corresponding to approximately 16% of the total packets transferred to complete the file transfer. The observed retransmissions explain why ns-3 provides higher throughput, but finalizing the file transferring in almost 4 minutes. We do not have a clear explanation for the deviations obtained in the ns-3 results, once we tried to our best to configure the simulation parameters to match the same experiment setup run in R2lab and ns-3. 15 Information about the file configuration can be found at the Mininet-WiFi's manual Fig. 10. Sample Topology

C. Replaying Network Conditions

The wireless medium is known for the frequent variations in networking conditions change due to multiple reasons, such as cross traffic and many sources that contribute to fluctuations of the physical medium. We now focus on the ability of Mininet-WiFi to dynamically change the parameters of the network links (e.g. bandwidth, packet loss, latency and delay) based on the distance between the communicating nodes and eventually augmented with observations from an actual experiment in the real world.

Being able to replay real networking conditions based on traffic observations in real environments is useful to predict network performance under certain conditions, reason about the observed network behavior, and perform fair comparisons between alternative algorithms' implementations subject to the mirrors of the physical network. Previous works have explored this approach [START_REF] Eckhardt | A trace-based evaluation of adaptive error correction for a wireless local area network[END_REF], [START_REF] Noble | Trace-based mobile network emulation[END_REF], some of the including wireless scenarios, e.g., TraceR [START_REF] Acun | Preliminary evaluation of a parallel trace replay tool for hpc network simulations[END_REF], OMNeT++ [START_REF] Varga | An overview of the omnet++ simulation environment[END_REF], SimGrid [START_REF] Casanova | Versatile, Scalable, and Accurate Simulation of Distributed Applications and Platforms[END_REF], and others. To the best of our knowledge, Mininet-WiFi pioneers the use of this technique in SDWN.

1) Approach

In this scenario, we transfer a 62.6MB file between two nodes in R2lab and collect real traffic using wireshark. By filtering by TCP protocol, we record information about bandwidth and latency. We then replay these information (traces) in Mininet-WiFi by dynamically redefining link bandwidth and latency using Linux TC and measure the results using both 802.11b and 802.11g.

2) Results

The results are presented in Figure 11. As expected, the total transfer time was less for 802.11g than 802.11b due to the higher transmission speed. Mininet-WiFi outputs a similar behaviour but with slightly higher throughput, and, consequently, finalizes the file transfer file process before R2lab. We believe that the difference is due to the amount of ACK frames generated during the communication by both receiver and transmitter, where in Mininet-WiFi those frames are sent out to a specific interface called hwsim0 by default. This behaviour differs from the real world where wireless network interfaces are responsible for processing any packet including ACK frames. If more accurate results are desired, the parameters of the wireless channel emulation can be tuned, for instance to reduce the bandwidth (axis X) as needed. In the case of IEEE 802.11g, the average consumed bandwidth in Mininet-WiFi and R2lab during the file transferring was 1.66Mbps and 1.56Mbps, respectively. Thus, reducing the bandwidth provided by Mininet-WiFi in 0.1Mbps (i.e., about 1%) should be enough for getting further closer results when aiming at reproducing experiments for this specific use case scenario.

Regarding latency and packet loss both R2lab and Mininet-WiFi provide very similar results. Altogether, we believe that the results are accurate within an order of magnitude, which seems to be a "good enough" result for the wireless channel emulation sufficient to support SDWN research commonly focused on the higher-layer control and management features. Nevertheless, we plan to keep improving our approach to emulate the wireless medium with increased fidelity and reproducibility (aka "replay") features in order to provide more realistic experimentation options and deliver accurate results comparable to those from a real testbed.

VII. CONCLUSIONS AND FUTURE WORK

This article revolves around the question of carrying realistic SDWN experiments, and in particular, the advances reached by our Mininet-WiFi emulation platform.

Extending the success story of Mininet for wired SDN into wireless, Mininet-WiFi introduces itself as a powerful tool for SDWN research and WiFi experiments by supporting arbitrary Linux-based applications, OpenFlow programmability, external SDN controllers, mobility and propagation models among other experimenter-friendly features.

We believe that a lightweight virtualization together with good enough wireless channel emulation capabilities, mobility models and overall experimental scenario reproducibility are steps forwards towards cost-effective and realistic SDWN experimentation. Can we go further? Certainly.

With Mininet-WiFi we have achieved significant steps as validated through the prototype use cases presented and the proof-of-concept experiments to validate our claims of realistic SDWN emulation. To this end we conducted experiments in a real testbed and compared the results with those from the Mininet-WiFi propagation models. Furthermore, we showed the ability to replay network conditions from the real testbed to reproduce in the emulated environment the expected behavior from a real world experiment.

Altogether, the obtained results suggest that Mininet-WiFi is able to mimic the real world with enough fidelity to support meaningful SDWN experiments. All necessary code and instructions to reproduce each of the experiments presented in this article and additional ones are available in the project website. 16 In order to reach further, some of our ongoing efforts include (i) further validation (including scalability limits) via experiments of more complex scenarios, (ii) improve the replaying features of captured traces in order to provide more accurate results and facilitate reproducibility (e.g., configure statistics/results collection), and (iii) keep adding features and support of scenarios as requested by the increasing user community via the mailing list and the public code repository. 17

Fig. 1 .

 1 Fig. 1. Generalized and Simplified Software-Defined Wireless Networking Architecture.

Fig. 2 .

 2 Fig. 2. Main components of Mininet-WiFi.

Fig. 3 .

 3 Fig. 3. Overview of related work and trade-offs of different wireless experimental platforms.

  intervalT = endT ime -startT ime posx, posy, posz = initP osx, initP osy, initP osz f acx = (f inalP osx -initP osx)/intervalT f acy = (f inalP osy -initP osy)/intervalT f acz = (f inalP osz -initP osz)/intervalT posx, posy, posz = posx + f acx, posy + f acy, posz + f acz (1)

P

  athLoss = P ropagationM odelF ormula signalStrength = pT + gT + gR -P athLoss

Fig. 4 .

 4 Fig. 4. Bicasting over WiFi

Fig. 5 .Fig. 6 .

 56 Fig. 5. MultiPath TCP

Fig. 7 .Fig. 8 .Fig. 9 .

 789 Fig. 7. Forwarding by SSID

Wireless SDN Controllers Northbound interface Southbound interface

	use CAPWAP in their proposals.
	CloudMac describes current WLAN management protocols
	such as CAPWAP, as a protocol hard to extend with new
	functionalities since CAPWAP AP controllers are mostly
	proprietary systems. Chandelle, instead, proposes a smooth
	and fast Wi-Fi roaming with SDN/OpenFlow but suffers from
	Applications
	(Service Providers, Operators)
	Control/Management of Wireless
	and Mobile functions
	(e.g. mobility, authorization, QoS)
	(e.g. OpenFlow, Capwap)

TABLE I RANKING

 I OF SIMULATORS, EMULATORS AND TESTBEDS (ADAPTED FROM

TABLE III COMPARATIVE

 III TABLE BETWEEN MININET-WIFI AND TESTBEDS

	Software	Availability Mobility Support	Supported Protocols	Last activity
				Any (L3 -L7)
	Mininet-WiFi [11]	Public	Yes	IEEE 802.11, 802.3,	2016
				OpenFlow
	Nitos[37]	Public	No	IEEE 802.11, WiMAX, LTE, OpenFlow	2016
	R2lab[38]	Public	No	IEEE 802.11, LTE	2016
	EMULAB [39]	Public	No	IEEE 802.11	2016
	Orbit[40]	Public	No	IEEE 802.11, WiMAX, LTE Bluetooth, ZigBee	2016
	Mininet-WiFi	DCE/ns-3
		(v1.9)	(v1.8)
	sysctl, ifconfig, route
	IPv6 address config.
	full POSIX
	poll implementation
	Quagga routing stack
	extensive test
	real time scheduler
	mobility models

TABLE IV COMPARISON

 IV BETWEEN MININET-WIFI AND DCE/NS-3

  4 http://tldp.org/HOWTO/Traffic-Control-HOWTO/intro.html cost = f(CAPEX, time-to-experiment, complexity, resources, etc.)

			Increased Realism/Complexity
				Nitos
				R2lab
				EMULAB
				Orbit
			Mininet-WiFi
			DCE/ns-3
			Core	Less real experimental
				conditions
		OpenNet
		OMNeT++ ns-2	Less scalability, flexibility, reproducibility, repeatibility, etc.
	Models Formal Math.	Simulators	Emulators Experimental Options	Testbeds	Networks Live	Realism

  in KB/s out KB/s in KB/s out 246.04 5047.28 632.20 25951.69 245.37 5045.90 624.49 25949.27 246.96 5045.91 625.94 25950.82 245.09 5047.38 624.06 25949.16 245.19 5047.35 624.34 25950.53 247.08 5045.96 625.22 25949.61 245.21 5047.43 625.50 25950.95 246.84 5046.30 624.95 25948.97 244.79 5047.37 625.49 25950.64 246.59 5045.86 624.63 25950.56

	Client	Server
	mininet-wifi> sta1 ifstat sta1-wlan0 sta1-wlan1 KB/s mininet-wifi> h10 ifstat h10-eth0 KB/s in KB/s out
		30592.15 886.37
		30592.50 872.26
		30594.53 870.65
		30590.97 870.02
		30594.11 870.48
		30592.60 869.30
		30593.90 868.02
		30591.12 869.98
		30594.98 871.94
		30590.90 867.48
	(b) Results

Mininet-WiFi supports technical specifications of several devices AP2 (a) Topology setup

TABLE V MEAN

 V VALUES OF MEASURES OBTAINED FROM TESTS

http://r2lab.inria.fr

Information about DCE/ns-3 relesase 1.8 were obtained from the online manual: https://www.nsnam.org/docs/dce/manual/ns-3-dce-manual.pdf

Some of the functions performed by MLME are authentication, association, sending and receiving beacons, etc.

https://wireless.wiki.kernel.org/en/developers/ documentation/mac80211/ratecontrol/minstrel

https://github.com/bcopeland/wmediumd

https://groups.google.com/forum/#!forum/mininet-wifi-discuss

Required improvements of mac80211 hwsim are underway; https://www.youtube.com/watch?v=FgrESRbG61Y

https://github.com/intrig-unicamp/mininet-wifi/tree/master/demos

http://www.multipath-tcp.org/

http://www.tp-link.com.br/products/details/cat-9 TL-WR740N.html#specificationsf

ACKNOWLEDGEMENTS

This research was partially supported by FAPESP grant # 14/18482-4. The R2lab wireless testbed at Inria has been funded by the ANR Equipex FIT 6165.