SDN Research @ FG INET

Software-Defined Wireless Networking

OpenSDWN: A software-defined wireless networking architecture which combines the benefits of SDN, NFV and wireless.
Papers: ONS Research Track 14, HotSDN 14, SOSR 14

Odin: A software-defined wireless networking framework for Enterprise WLANs, that builds upon some novel WiFi-specific programming abstractions.
Papers: HotSDN 12, SIGCOMM (Demo) 12, Usenix ATC 13


OpenSDWN, a novel WiFi architecture which combines the benefits of WiFi, SDN and NFV. OpenSDWN exploits datapath programmability to enable service differentiation and fine-grained transmission control, facilitating the prioritization of critical applications. OpenSDWN implements per-client virtual access points and per-client virtual middleboxes, to render network functions more flexible and support mobility and seamless migration. OpenSDWN can also be used to out-source the control over the home network to a participatory interface or to an Internet Service Provider.

Unified Programmability and Abstractions

VNF Migration

The logically centralized control plane unifies SDN and NFV through programmatic abstractions. That is, OPENSDWN virtualizes both access points and virtualized middleboxes, which facilitates an easy handling and migration of per-client state, also beyond CPE boundaries. The OpenSDWN abstractions can be seen as an extension of Odin to NFV: Odin’s LVAP concept abstracts the complexities of the IEEE 802.11 protocol stack (client associations, authentication, and handovers), and enables the unified slicing of both the wired and wireless portions of the network. The former is achieved by encapsulating the client’s Openflow state. OpenSDWN additionally introduces per-client virtual middleboxes, short vMBs, which can be transferred seamlessly across the network. Specifically, a vMB encapsulates the client’s MB state as a virtual MB object. Thus, OpenSDWN achieves control logic isolation as SDN/NFV applications running on top the controller can only operate on their respective LVAPs and vMBs.

Programmable Datapath

WDTX Installation

The programmable datapath gives the possibility to set per-flow specific transmission settings. The settings include transmission power, transmission rate as well as tailored retry chains. It is even possible to differentiate between different packets of the same flow (5-tuple): for instance, key frames of a live stream may be given higher priority. This is achieved by using an Intrusion Detection System (IDS, in our case: Bro) for packet classification and tagging: transmission settings are chosen depending on the tag.

Participatory Interface

Participatory Interface

OpenSDWN’s participatory interface allows us to define flow priorities as well as priorities over customers. The chosen priorities are translated by the controller into meaningful network policies. Priorities can be adjusted anytime.


Odin is an SDN-based solution which presents a programming abstraction which can provide the features enterprise and provider networks need. It bridges the gap between the range of features required by network operators and the lack of programmability in today’s WiFi networks based on cheap off-the-shelf WLAN hardware.


Network applications written on top of Odin can function both reactively and/or proactively. Proactive applications are timer-driven whereas reactive applications use triggers and callbacks to handle events. The latter mode of operation is important particularly within WiFi networks due to the dynamic nature of the channel, and the system needs to react based on inputs from different measurement sources. To this end, in our current implementation, an application can utilize multiple measurement sources.


The controller is implemented as an extension to Floodlight OpenFlow controller. This allows us to use OpenFlow for Odin specific functionality such as tracking client IP addresses to be attached to their respective LVAPs by tapping into DHCP messages. The initial assignment of agents to slices, the initial set of SSIDs per slice, and the network applications to run on each slice are defined via a configuration file. The controller uses a TCP-based control channel to invoke the Odin protocol commands on the agents. The controller organizes state on a per-slice basis, allowing it to present applications only a view of their respective slice in terms of associated clients, their LVAPs, and physical APs. Applications are expressed as Java code and run on top of the controller as threads. The programming API includes hooks for applications to view and control mappings of clients to APs, add/remove SSIDs to slices, and to register/unregister subscriptions for the pub-sub mechanism. As a result of using Floodlight, the controller is not distributed and runs on a single machine.


Odin agents run on physical APs, and are implemented in the Click Modular Router. The agents implement the WiFi split-MAC together with the controller, host LVAPs, and collect statistics on a per-frame and host basis. They notify the controller whenever a frame is received that matches a per-frame event subscription registered by a particular application. Alongside the agents, we run Open vSwitch on the APs to host OpenFlow rules carried by LVAPs as well as those expressed explicitly by network applications and the controller (for instance, to handle DHCP acknowledgments). Excluding the OpenFlow rules, the state associated with each LVAP hosted by an agent is approximately 48 bytes in size, and up to 32 bytes per- SSID in the slice (slices can announce multiple SSIDs).

Subset of APIs provided by the framework

North-bound API (Controller to Application)
Method Description
getClients() Get slice-specific-view of associated clients
getAgents() Get a view of agents in the application's slice
handoffClientToAp() Perform an LVAP migration of a client to an AP
getRxStatsFromAgent() Query agent for per-station rx-statistics
{register/unregister}Subscription() Subscribe to a per-frame event of interest at the agents
{add/remove}Network() Add or remove an SSID to the application's slice
South-bound API: (Controller to agent)
Method Description
{add/remove/set}-lvap Add/remove/update an LVAP on an agent
read-lvap-table Obtain the list of LVAPs on an agent
read-rx-stats Query per-station rx-stats at the agent
{read/set}-subscriptions Query/set the list of subscriptions at the agent
{read/set}-channel Query/set the channel the agent listens and transmits on
{read/set}-beacon-interval Query/set the beacon interval on the agent
South-bound API: (Agent to Controller)
Method Description
HELLO Keep-alive sent from agents to the controller
PROBE Notify controller about a client's probe request
PUBLISH Notify controller about a subscription being triggered



, ,


The projects are led by Julius Schulz-Zander.
Contact information is listed on my group's website