AeroFlux: A Near-Sighted Controller Architecture for Software-Defined Wireless Networks

Applying the concept of SDN to WiFi networks is challenging, since wireless networks feature many peculiarities and knobs that often do not exist in wired networks: obviously, WiFi communicates over a shared medium, with all its implications, e.g., higher packet loss and hidden or exposed terminals. Moreover, wireless links can be operated in a number of different regimes, e.g., transmission rate and power settings can be adjusted, RTS/CTS mechanisms can be used. Indeed, due to the non-stationary characteristic of the wireless channel, permanently adjusting settings such as transmission rate and power is crucial for the performance of WiFi networks and brings significant benefits in the service quality, e.g., through reducing the packet loss probability. Today’s rate and power control is mainly done on the WiFi device itself. But it is rarely optimized to the application-layer demands and their diverse traffic requirements, e.g., their individual sensitivity to packet loss or jitter. Therefore, if SDN for wireless can provide mechanisms to control the WiFi-specific transmission settings on a per-slice, per-client, and per-flow level, traffic and application-aware optimizations are feasible. This however requires that controllers frequently collect link characteristics and, accordingly, adjust transmission settings in a timely manner. As a reference, the standard rate control mechanism in the Linux kernel adjusts the transmission rate on a wireless link based on transmission success probability statistics every 100 ms. Leaving rate control (and power control accordingly) to a centralized controller comes with a risk of overloading the control plane, or of adding too much latency, while there is limited benefit in maintaining these statistics globally. For instance, the coherence time (also a function of the client mobility) can easily exceed the expected time of the successful transmission of multiple data frames [2], rendering optimized control difficult. In this paper, we suggest a 2-tiered approach for the design of a wireless SDN control plane. Our design, called AeroFlux, handles frequent, localized events close to where they originate, i.e., close to the data plane, by relying on NearSighted Controllers (NSC) [3, 4, 7]. Global events, which require a broader picture of the network’s state, are handled by the Global Controller (GC). More specifically, GC takes care of network functions that require global visibility, such as mobility management and load balancing, whereas NSCs control per-client or per-flow transmission settings such as rate and power based on transmission status feedback information exported by the Access Points (AP), which include the rates for best throughput and best transmission probability. Put differently, we enable the global controller to offload latency-critical or high-load tasks from the tier-1 control plane to the NSCs. This reduces the load on the GC and lowers the latency of critical control plane operations. As a result, with AeroFlux, we realize a scalable wireless SDN architecture which can support large enterprise and carrier WiFi deployments with low-latency programmatic control of fine-grained WiFi-specific transmission settings. The AeroFlux design introduces a set of new trade-offs and optimization opportunities which allow for advancements in the use of the shared wireless medium, and, as a result, in the user’s quality of experience. For instance, our prototype’s perflow control allows application-aware service differentiation by prioritizing multimedia streams (§2). Another key feature of AeroFlux is that it does not require modifications to today’s hardware and works on top of commodity WiFi equipment. 1 The AeroFlux Architecture AeroFlux uses a 2-tiered control plane: the Global Control plane GC and the Near-Sighted Control plane NSC. Figure 1 depicts the high level interactions of the architecture’s building blocks. The GC is logically centralized, e.g., a set of redundant controllers deployed in data centers, whereas the NSCs are located closer to where they are needed, e.g., close to the wireless APs. On the APs runs a Radio Agent (RA), which hosts the Light Virtual Access Points (LVAPs) [6] that abstract the specifics of the 802.11 protocol, such as association and authentication state. Furthermore, LVAPs store per-client OpenFlow and WiFi Datapath Transmission (WDTX) rules. In the following, we describe the different elements in more detail. Global Controller (GC): The global controller handles events which are not time-critical [7] or events belonging to inherently global tasks [4]. Examples include: authentication, wide-area mobility management, global policy verification (including loop-free forwarding sets), client load balancing, and applications for intrusion detection or network monitoring. In addition, the global controller is best suited to man-