Research Article Proxy SDN Controller for Wireless...

Research ArticleProxy SDN Controller for Wireless Networks

Won-Suk Kim and Sang-Hwa Chung

Pusan National University, Busan 46241, Republic of Korea

Correspondence should be addressed to Sang-Hwa Chung; [email protected]

Received 4 March 2016; Revised 8 June 2016; Accepted 15 June 2016

Academic Editor: Claudio Agostino Ardagna

Copyright © 2016 W.-S. Kim and S.-H. Chung. This is an open access article distributed under the Creative Commons AttributionLicense, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properlycited.

Management of wireless networks as well as wired networks by using software-defined networking (SDN) has been highlightedcontinually. However, control features of a wireless network differ from those of a wired network in several aspects. In this study,we identify the various inefficient points when controlling and managing wireless networks by using SDN and propose SDN-basedcontrol architecture called Proxcon to resolve these problems. Proxcon introduces the concept of a proxy SDN controller (PSC) forthe wireless network control, and the PSC entrusted with the role of a main controller performs control operations and provides thelatest network state for a network administrator. To address the control inefficiency, Proxcon supports offloaded SDN operationsfor controlling wireless networks by utilizing the PSC, such as local control by each PSC, hybrid control utilizing the PSC and themain controller, and locally cooperative control utilizing the PSCs. The proposed architecture and the newly supported controloperations can enhance scalability and response time when the logically centralized control plane responds to the various wirelessnetwork events. Through actual experiments, we verified that the proposed architecture could address the various control issuessuch as scalability, response time, and control overhead.

1. Introduction

In recent years, software-defined networking (SDN) tech-nology has gained attention because it can support networkprogrammability [1]. SDN enables network devices, such asswitches, to perform only data plane processing by separatingthe control plane and data plane of the network. At the sametime, SDN controller performs only network control. Thecontroller also maintains a global network view by periodi-cally collecting the network state from the network devices.In addition, a network administrator can easily configurenetwork policies by implementing a network applicationthat utilizes the global network view through a northboundapplication programme interface (NBAPI) provided by thecontroller.

SDN has utilized the concept of the logically centralizedcontrol plane, and it naturally constitutes the control planewith physically distributed controllers to achieve a variety ofcontrol objectives.Whereasmultiple physical controllersmayaddress the control issues such as control bottlenecks anda single point of failure, management complexity becomes

quite high. Examples of increasing management complexityare synchronization between the controllers to share thenetwork view, the operations of the network applicationsuch as policy distribution, and load balancing amongthe controllers. Unfortunately, although there are quite alarge number of controller vendors, a standard of the east-bound/westbound protocol for multiple physical controllersdoes not yet exist.

Because cases of SDN application to actual networksare increasing, requests to control wireless networks andwired networks over a single logical control plane havebeen growing. Consequently, advanced SDNarchitectures forvarious wireless networks have been proposed continually[2–7]. In addition, such architectures can be utilized forcontrolling relatively complex control plane of a reliablewireless infrastructure, such as an advanced routing protocol,information centric networking (ICN), and amobile network[8–13]. If a control point of wired and wireless networksis unified, the controller can perform management of thevarious resources of the wireless networks as well as flowcontrol. Furthermore, it is possible to support a high level

Hindawi Publishing CorporationMobile Information SystemsVolume 2016, Article ID 7172187, 14 pageshttp://dx.doi.org/10.1155/2016/7172187

2 Mobile Information Systems

Software-defined wireless networks

SDN-enabledwirelessaccess points

SDN-enabledswitches

Main SDNcontrollers

Networkapplication

Networkapplication

Extended OpenFlow/ REST API protocolOpenFlow protocol

· · ·

Figure 1: A concept of software-defined wired and wireless net-works.

of control policies that reflect different types of networksat the same time. In other words, if the scope of SDN isexpanded to wireless networks, the SDN architecture will beable to support a variety of network applications forwired andwireless networks.

The SDN-based control method of wireless networks isdifferent from that of wired networks. Enterprise networksor campus networks that are aimed at users who often usemobile devices, such as smartphones, laptops, and handhelddevices, generally consist of many switches and even morewireless network devices such as a wireless access point(WAP) or a home node B (HNB). Such networks are config-ured as seen in Figure 1, which shows severalWAPs physicallyconnected to a single switch. If remote controllers manage alarge number ofWAPs in addition to the switches, the controloverhead at the controllers obviously becomes even greaterthan that when controlling only the wired networks.

In addition, most control for wireless network com-ponents such as WAPs is conducted by the event-drivenscheme. A station in a wireless network generally has largemobility, so wireless network events, such as station handoff,received signal strength indicator (RSSI) change, signal-to-noise ratio (SNR) change, channel state change, and WAPerror, occur more often than events in the wired networkssuch as link failure and switch error. In other words, networkstate updates by a topology change and variable link statesoccur more frequently.Therefore, if the control target of SDNis extended to wireless networks, the additional overheadin the controller will be inevitable by the additionally givenroles, such as network join/leave of station, authentication,security, handoff, andWAP load balancing. When the role ofthe controller increases, control issues such as scalability andreliabilitywill intensify, andnew issues such as timelinessmayarise.

When an existing SDN architecture controls the wirelessnetworks, expected challenges are as follows:

(i) Scalability and the control bottleneck due to a largenumber of WAPs.

(ii) Controller overload by event-driven control.(iii) Complexity of the controller operations due to vari-

ous event types of the wireless networks.(iv) Possibility of supporting events that require rapid

processing.

We have previously studied SDN architecture to solvethese issues [14]. The previous work was a concept study forlocal control and cooperation utilizing the proxy controller.The study however lacked the details of the event catego-rization and did not address the control type to respondto network events that require a global view. In this paper,we propose Proxcon, which is SDN architecture for wirelessnetwork control, to advance the proxy controller technology,and propose the operations and roles of the Proxcon agents,which are operated on each WAP, in detail. In particular,the agent is designed to support fine-grained control thatcan respond in a more adaptive way to the event types andnetwork state. Based on the features related to the agent, inaddition, we introduce a hybrid control type as well as thelocal control and cooperation based on the proxy controller.

Proxcon embeds a proxy SDN controller (PSC) and aProxcon agent in each WAP. The PSC takes part of therole of a main SDN controller (MSC, the existing centralcontroller). The PSC obtains the changed network policiesby synchronizing with the MSC. With these policies, thePSC can directly perform wireless network control thatrequires only a local network view. In addition, the Proxconagent maintains information on the controllers in chargeof various network events and utilizes the information toforward control messages. The Proxcon agent also deliversinformation on the various network events occurring in thewireless networks to the MSC or PSC.

The challenging issues mentioned above arise when theexisting SDN architecture controls wireless networks. Wecontribute to resolving these issues through Proxcon, asproposed in this paper. Proxcon supports three offloadedSDN control operations based on the PSC and the Proxconagent mentioned above. The offloaded control operations arethe local control by each PSC, the hybrid control utilizingboth the PSC and the MSC, and the locally cooperativecontrol utilizing the PSCs.These operations can be selectivelyused according to the event characteristic and address thechallenging issues by reducing the loads of the MSC andthe network efficiently. How these operations address thechallenges is summarized as follows:

(i) The local control by each PSC can resolve scalabilityand the control bottleneck due to a large number ofWAPs. The control scalability is efficiently handledthrough the local control based on the synchroniza-tion between the MSC and PSCs.

Mobile Information Systems 3

(ii) The controller overload can also be resolved by thelocal control. By this operation, the MSC will offloadmost of the control load onto the PSCs.

(iii) The complexity of physically distributed controlleraffects the operation of network applications, such aspolicy distribution, and control load balancing amongthe controllers. These issues can be addressed appro-priately through synchronization between the singleMSC and PSCs in Proxcon. The network applicationinstances on the MSC may be configured to performthe same role in all or part of the PSCs. The controlload balancing need not be considered because thenumber of events that need to be processed in eachPSC is only a small portion compared with the entirenetwork.

(iv) Supporting the events that require rapid processingcan be achieved through the local control and coop-erative control.

Moreover, Proxcon can ensure control reliability by per-forming the local control regardless of the network state.The efficiency of Proxcon was evaluated through actualexperiments in the testbed.

The remainder of this paper is organized as follows.Section 2 presents related work, and Section 3 presentsProxcon details. In Section 4, the experimental results areanalyzed, and we conclude the paper in Section 5.

2. Related Work

Research on wireless network control based on WAP controlhas been actively conducted. In addition, some researchershave configured a WLAN control system using their ownprotocol without applying the concept of SDN.

Shrivastava et al. [15] proposed Centaur which is a WAP-controller collaboration system to address a hidden/exposedterminal problem, which is an old and well-known issue.Murty et al. [16, 17] proposed DenseAP which is a centralizedstructure for wireless network control and introduced Dysonwhich is a network control scheme based on Python. Dysoncan support various network applications for wireless net-work control with only the implementation of a simple codeusing Dyson APIs, but it incurs station-side modifications.These studies concentrated explicitly upon control functionsof a central controller, but they did not consider the issuesof scalability and reliability owing to the bottlenecks in thecontroller itself and the control overhead betweenWAPs andthe controller.

SDN was first studied as a control system for only wirednetworks, and thus communication protocols such as Open-Flow have been designed for this purpose. However, as wire-less networks have been rapidly diffused, SDN-based wirelessnetwork control technologies have also been steadily studied.Suresh et al. [18] and Schulz-Zander et al. [19] presentedOdinwhich is a structure that concentrates most of the controlfunctions for the WAPs on the central controller, and thissystem can support network-initiated handoff by configuringvirtual basic service sets (BSSs). Zhao et al. [20] designed the

extended OpenFlow protocol for the WAP control, and thesystem based on this protocol supports seamless handoff bysetting exclusive rules in the WAPs. However, these studiesfocused on SDN-based wireless network control only and didnot consider scalability issues caused by deploying a largenumber of WAPs.

In addition, the SDN technologies for various types ofwireless networks have constantly been studied [21]. Thestudies for software-defined wireless network (SDWN) havebeen designed to consider many features of wireless net-works, such as error-prone communicationmedium, channelinterference, user mobility, and unpredictable changes inlink quality and network topology. Yao et al. [22] proposeda control traffic load balancing scheme between multiplecontrollers. The study adopted the method of distributionand centralization management between multiple networkclusters and proposed a double threshold approach to evenlyallocate the control traffic load. Proxcon has been designedto support the proxy controller based offloaded control tohandle these challenges without high complexity caused bymultiple controllers.

Riggio et al. [23] proposed programming abstractions forSDWN. The authors state that the flow abstraction of Open-Flow for software-definedwired network did not consider thecharacteristics of the wireless network. Also, they argued thatthe programming abstractions should consider the natureof radio link, resource allocation granularity, and link/radioheterogeneity. The proposed abstractions addressed the fourcontrol aspects of wireless networks such as state manage-ment, resource allocation, network monitoring, and networkreconfiguration. This study increased the efficiency of net-work application implementation by providing the program-ming abstractions of SDWN but did not address the increaseof control overhead in SDWN. Proxcon proposes the controlsystem that eliminates some inefficiency control points, soProxcon architecture and the programming abstractions maybe compatible.

Research on the effective configuration of a physically dis-tributed control plane of SDN has been performed recently.Tootoonchian and Ganjali [24] and Yeganeh et al. [25]proposed HyperFlow which is an event-based distributedcontrol plane for OpenFlow. This architecture adopted thelogically centralized, physically distributed control plane. Itintroduced the utilization scheme of multiple controllersholding their own local network views. The system assumedthat the events explicitly affecting the global network view arevery few. However, in wireless networks, the events affectingthe network state occupy a significant percentage because ofthe greater mobility of stations.

Dixit et al. [26] proposed ElastiCon to reduce the con-trol load by expanding or shrinking the controller pool inresponse to a current control overhead. Riggio et al. [27]performed a taxonomical analysis to assess the admissibilityof a variety of wireless network management functionalitiesin the remote management plane. In addition, they alsospecified the control category for wireless networks by clas-sifying well-known FCAPS (fault, configuration, accounting,performance, and security) functionalities. These studiesfocused on the operation between the controller domains;


SDN-based backhaul network

SDNWAPs

Main SDN controllers

WAP firmware

Local control based onglobal network policy

Policy and statesynchronization

Local information sharing

Wired and wirelessnetwork control

PSC PSC

Proxy SDNcontroller (PSC)

Figure 2: Overall architecture and functionalities of Proxcon.

in contrast, a method that maximizes operation efficiencywithin a single controller domain is proposed in this paper.

The scalability issue occurs inevitably in SDN based onthe logically centralized control plane. Some studies haveutilized network devices such as a switch to address thisproblem. Curtis et al. [28] proposed DevoFlow to supportscalability through an operation in which the switches decidelocal routing by using a wildcard in a flow table while thecontroller directly controls elephant flows. Yu et al. [29]introduced DIFANE to take advantage of the concept of anauthority switch to support scalability. In this system, thecontroller generates authority rules based on network policiesand sends the authority rules to the authority switch. Theauthority switch sets the flow table by the authority rulesand forwards rules to neighboring switches. These studiesattempted to resolve the scalability problem by moving partof the control plane to the network devices. However, thesetechniques are unsuitable for response in a variety of networkevents that occur in wireless networks.

3. Proxcon Architecture

3.1. Proxcon Architecture Overview. In SDN-based controlsystem for wireless networks, if theMSC additionally handlesevent detection and periodic reports from a larger number ofWAPs compared to the number of switches, a significant loadwill be added onto the network as well as the controller itself.Because the overload causes degradation of the timelinessand availability of network control, the control reliability willbe eventually reduced.

Figure 2 presents an overview of the overall architectureof Proxcon and its functionalities. Proxcon maintains thewireless network control plane in a logically centralized andphysically distributed form. At first glance, it seems to be

a logically distributed control plane; but, actually, the MSCis solely in charge of controlling the wireless networks. ThePSC is merely a proxy controller that has been delegated tocontrol the WAP in which the PSC is operating.

Proxcon, which is proposed to improve the efficiencyof the SDN-based control for wireless networks, assigns thePSC within the WAP to handle part of roles instead ofthe MSC. Proxcon supports three offloaded SDN controloperations for control of the wireless networks by utilizingthe concept of the proxy controller. The offloaded controloperations are the local control by each PSC, the hybridcontrol utilizing both the PSC and the MSC, and the locallycooperative control utilizing the PSCs. By supporting thesecontrol operations, Proxcon provides an efficient controlmechanism for a network administrator.

If the network application utilizes the features of Proxcon,control communication between theMSC and theWAPs willbe conducted to exchangemessages on the global control, thesynchronization, and the report. The global control messageis based on the global network view, the synchronizationmessage sets the global network policy of each PSC, andthe report message is required to maintain the recent globalnetwork view. In addition, when Proxcon is applied, thereliability of the wireless network control will be considerablyincreased because the PSC can be responsible for most of thewireless network control without the reference being affectedby the network state.

In Proxcon architecture, the purpose of the commu-nication between the MSC and the WAPs is to manageconnection, synchronization, events, and devices. In orderto achieve SDN, OpenFlow protocol has been used as defacto standard for southbound protocol between the MSCand switches. Although we have implemented Proxcon byutilizing vendor type messages of OpenFlow, there is no


(7) Forward the policies to thePSC

Networkapplication

Networkapplication

Controllercore

Proxconagent

Proxy SDNcontroller

WAPfirmware

MSC

WAP

(1) Connectionestablishment

(2) Notify thenew WAPconnection

(3) Configure network policies and APATentries for the new WAP

(4) Collect the policiesand entries for the newWAP from applications

(5) Issue the policies andentries

(6) Configure the APATby the APAT entries

(8) Update the localnetwork policy

(9) Local controlby the APATand the PSC

Figure 3: First control sequence for the WAP newly connected tothe MSC in Proxcon.

standard of the communication protocol between the MSCand the WAPs. The latest SDN controller, such as opennetwork operating system (ONOS) and OpenDayLight, cansupport several southbound protocols through the provider[30, 31]. Therefore, the communication protocol between theMSC and the WAPs does not need to be configured as theextended OpenFlow but may be a parallel signaling channelusing REST API.

3.2. Policy and State Synchronization. The MSC and thePSCs in each WAP conduct information synchronizationfrequently. There are two types of synchronization: synchro-nization for policy establishment and synchronization forreporting.The synchronization for policy establishment goesfrom the MSC to the PSC to set the network policy changedby a network application. The synchronization for reportinggoes from the PSC to the MSC to update the global networkview.When aWAP is connected to theMSC at the beginningor when the network policy is changed, the synchronizationfor policy establishment is conducted. In contrast, when thenetwork is operating normally, the network state informationcollected by the PSC is periodically reported to the MSCthrough the synchronization for reporting.

The modification of the controller in charge of a certainevent is performed by the network application, and theinformation is held in the access point action table (APAT) ofa Proxcon agentwithin eachWAP.The event is then processedby the MSC or the PSC in accordance with APAT entry.

Figure 3 shows the synchronization for policy establish-ment during the initial connection of aWAP. AfterOpenFlowconnection is established between the MSC and the Proxconagent within the WAP, a network application on the MSCdetermines whether there is a need to forward their policiesto the WAP. If there is an event that can be processed bylocal control, the network application forwards the MSC

Main SDNcontrollers

Proxcon agent(message forwarding, parsing,

WAP action table)

WAP firmware(WAP daemon,kernel driver)

SDNWAP

PSC

Other SDN WAPs

Extended OpenFlow/ REST API protocol(WAP control/sync messages)

Proxy SDNcontroller

Figure 4: Internal architecture of wireless access point and controlmessage flows of Proxcon.

the event type and the network policy related to the event.TheMSC collects the network policies and the event types fromthe network applications and then forwards the WAP thecollected data and the APAT entries. After the Proxcon agentreceives themessage, the agent updates its APAT according totheAPATentries, including the information of the controllersin charge of the specific event, and forwards the networkpolicies to the PSC. The PSC sets an event processing policywith the received message. When the network event occursafter this process is performed, theWAP firmware will notifythe Proxcon agent.The agent then converts the received eventinformation into an OpenFlow message and forwards thismessage to theMSC or the PSC according to the APAT entry.

A network application sets APAT entry for a PSC tocollect unimportant monitoring data, such as link qualityabove the threshold and the congestion level below a certainvalue. Therefore, the unimportant, ordinary monitoring datacollected by WAPs are stacked in the PSC within the WAP.In addition, when a certain link quality decreases excessivelyor the congestion level increases sharply, critical monitoringdata may be collected by the WAP. To update the globalnetwork view, the APAT may be configured to forward thecritical monitoring data to both the MSC and the PSC.

If the network application that requires ordinary mon-itoring data is utilized, the APAT may be configured toforward all monitoring data to both the MSC and the PSC.Unfortunately, this configuration incurs considerable controltraffic in the network.Therefore, to reduce the control traffic,the network application can modify the APAT for the PSC todirectly collect noncritical monitoring data and periodicallyreport processed data to the MSC.

3.3. Design of theWireless Access Point in Proxcon. TheWAPsin Proxcon consist of a PSC, a Proxcon agent, and WAPfirmware. Figure 4 shows the internal structure of the WAPand control message flows. The Proxcon agent, which is acore module of the WAP, is responsible for communicationwith the MSC and processes messages based on OpenFlow


Table 1: Example of the access point action table in the Proxconagent.

Event source Event type Condition Event targetWAP firmware Station join RSSI > 𝛼 PSC, MSC

WAP firmware Station join RSSI ≤ 𝛼,RSSI > 𝛽 MSC

WAP firmware Station join RSSI ≤ 𝛽 DROPWAP firmware Station leave PSC, MSC

WAP firmware Stationmonitoring ⋅ ⋅ ⋅ PSC

WAP firmware Networkmonitoring ⋅ ⋅ ⋅ PSC

WAP firmware WAP failure PSC, MSCMSC Policy issue PSC

MSC Global controlmessage WAP firmware

PSC Event report MSC

PSC Local controlmessage WAP firmware

or REST API, which is a southbound protocol. In addition,it maintains the information of the controllers in charge ofthe specific event by using the APAT. The PSC performslocal control for the WAP by utilizing an event responsepolicy, which is set by synchronization with the MSC, andsupports local cooperation with neighboring PSCs. Proxconis based on the extended OpenFlow protocol or REST APIthat includes synchronization messages and WAP controlmessages.

Table 1 shows the structure of the APAT in the Proxconagent. The APAT is composed of an event source, an eventtype, response conditions, and an event target. The eventsource and target include the WAP firmware, the MSC,and the PSC. The event type field contains the event typedefined in Proxcon. The response condition, which is anoptional field, divides the destination of a particular eventtype according to its own entry.

Asmentioned above, the Proxcon agent parses predefinedprotocol messages received from the MSC and forwards themessages to the PSC or the WAP firmware. The messageforwarded to the PSC is the synchronizationmessage, and themessage delivered to the WAP firmware is the direct controlmessage for the WAP. The PSC and the WAP firmware alsosend and receive messages through the Proxcon agent. ThePSC sends the local control message for the WAP and thereport message to the WAP firmware and the MSC throughthe Proxcon agent, respectively. TheWAP firmware forwardsmessages, such as a response to the WAP control message,an event in the wireless networks, or a periodic report aboutchannel or network state, to the Proxcon agent.Themessagesfrom theWAPfirmware are forwarded to theMSCor the PSCaccording to the APAT.

3.4. Proxcon Operation Details. Asmentioned previously, thechanges in network state and topology are frequent inwirelessnetworks compared to wired networks owing to the greater

mobility of stations and the link characteristic. Therefore,control of the wireless networks is based on the networkevents, such as station joining, channel resource control, andstation handoff. To provide a reliable network service forusers in such an environment, a control structure is requiredto respond appropriately to various network events thatoccur periodically.This section describes Proxcon operationsdivided into three categories with respective examples.

Figure 5 shows three offloaded SDNoperations supportedby Proxcon.The operations based on the concept of the proxycontroller are intended to respond to wireless network eventsefficiently.The first operation is the local control by each PSC,which enhances the response time and scalability.The secondoperation is the hybrid control utilizing both the PSC andthe MSC, which is used to respond to an event that maynot be handled by the PSC alone. The controller in chargeof the event is selected by the APAT according to the presetcondition.The last operation is the locally cooperative controlutilizing the PSCs. This operation reduces the control trafficin the network and enhances the scalability.

3.4.1. Proxcon Operation 1: Local Control by Each ProxySDN Controller. The network application of Proxcon can beconfigured to set the PSC for direct processing of particularevents that may not require the global network view.The typeof these events may include a station join/leave, monitoringdata collection, WAP resource control, traffic shaping, anddeep packet inspection (DPI). In Proxcon, the MSC shouldprovide the appropriate NBAPI to allow the network applica-tions to transfer part of their functions to the PSC.

For example, consider theWAP resource control. In IEEE802.11 wireless local area network (WLAN), one WAP canprovide multiple virtual basic service sets (VBSS) throughWAP virtualization or assign different resources for eachVBSS.There is a scheme that sets the channel share differentlyfor each VBSS by the uplink/downlink traffic control. In theexisting SDN architecture, the network application for VBSSmanagement is in charge of VBSS-specific resource allocation[32]. After eachWAP reports its current state to theMSC, theWAP is configured to apply the changed resource values, suchas queueing, enhanced distributed channel access (EDCA),and transmit opportunity (TXOP) values. In this case, thenetwork application must respond to rapidly changing trafficconditions by station mobility or traffic patterns. Thus, thisscheme must be implemented considering the load of theMSC, control traffic in the network, and a relatively slowresponse time. In addition, if the number ofWAPs or stationsis increased, this results in a scalability issue. On the otherhand, the control reliability can be ensured in Proxconbecause the PSC within each WAP can directly respond tothe traffic condition after the initial policy synchronization.

3.4.2. Proxcon Operation 2: Hybrid Control Utilizing Boththe PSC and the MSC. The APAT can be implemented tosupport a conditional operation. The condition may includethe event attributes, event frequency, response overhead, andcurrent load of the MSC or the WAP. It is possible to selectthe controller in charge in accordance with the conditions.


(1) Local control by each PSC

WAP(PSC)

MSC

WAP(PSC)

Networkevents

Networkevents

Direct controlbased on the globalnetwork policy

(2) Hybrid control utilizing boththe PSC and the MSC

WAP(PSC)

MSC

WAP(PSC)

Network events

Control by the MSCwhen certaincondition issatisfied

Direct controlby the PSC

(3) Locally cooperative controlutilizing the PSCs

WAP(PSC)

MSC

WAP(PSC)

Network events

Informationexchangebetweenthe PSCs

Direct controlby the PSC

Figure 5: Offloaded SDN operations supported in Proxcon.

Naturally, the policy to select the controller in charge is alsodetermined at the network application.

A station sends a probe request frame containing theservice set identifier (SSID) value to request a connectionto the IEEE 802.11 WAP. Because the probe request frame istransmitted as a broadcast, the request frame can be receivedby the adjacent WAPs operating on the same channel at thesame time. The WAP near the station may receive the framewith a higher RSSI value, whereas the WAP far from thestation will receive the frame with low signal strength. In thiscase, if the policy is set to perform a direct control by the PSC,it may lead to inefficient results because one PSC cannot beaware of the situation of several WAPs. For example, everyWAPmay respond to the request frame regardless of the RSSIvalue, and thus the link quality of the connectionmay indicatea poor quality. For these events, the network applicationin Proxcon can be implemented to support policies to takeadvantage of both the MSC and the PSC.

Consider the station join event in the APAT shown inTable 1 again. The APAT entries indicate that the controllersin charge of the station join event are configured differentlyaccording to the condition, which is set by the networkapplication. It is assumed that the network application has setthe conditions for the station join event at three according tothe RSSI value.

Table 2 illustrates the result of conditional action for thestation join event in Table 1. It is assumed that there are twoWAPs (WAP A andWAP B), and one station sends the proberequest frame.The two leftmost columns in the table show therange of theRSSI values of the probe request frame received ineachWAP as classes A, B, and C. Class A (RSSI > 𝛼) specifiesan even higher RSSI range that can be directly processed bythe PSC, class B (𝛽 < RSSI ≤ 𝛼) indicates the range to directlychoose the appropriate WAP by the network application onthe MSC, and class C (RSSI ≤ 𝛽) denotes the range of low

RSSI values that cannot communicate normally even if theconnection is established.

If both WAPs receive the probe request frame with RSSIbelonging to class A, the PSCs in both WAPs will directlyprocess the station join event separately.Therefore, the stationwill directly select one of two WAPs for the connection.If one WAP receives the frame in class A and the otherWAP receives class B frame, only the PSC in the WAP thatreceives the frame with class A will perform the response.Note that the Proxcon agent in the WAP that receives theframe belonging to class A forwards the frame to the MSC.This is a report for processing the requests with class B inthe network application.The network application collects therequest frames that belong to classes A and B, and then it doesnot respond to the station join event because it knows that thePSC in the WAP receiving class A frame already responded.In addition, the probe request frame that belongs to class C isdropped without any process.

If both WAPs receive the frame belonging to class B, theframes will be reported to the network application on theMSC, and then the network application will issue a commandto respondby selecting one of theWAPs. If bothWAPs receivethe frame belonging to class C, any process for the station joinevent will not proceed.

Through the methods described above, the networkapplication can be implemented to take advantage of both theMSC and the PSC for a particular event.

3.4.3. Proxcon Operation 3: Locally Cooperative ControlUtilizing the Proxy SDN Controllers. Another operation ofProxcon is locally cooperative control utilizing the PSCs.Thisoperation can be used for an event that cannot be handledby the PSC alone. A case in which the PSC cannot solelyrespond to the event may indicate that direct control of the


Table 2: Example of conditional operations for the station join event.

WAP A WAP B WAP A PSC WAP B PSC Network application onMSC Result

A A Response to thestation Response to the station Ignore The station selects the

WAP by itself

A B Response to thestation — Ignore WAP A by the PSC of

WAP A

A C Response to thestation — Ignore WAP A by the PSC of

WAP A

B B — —Select the WAP

reporting the higherRSSI value (A or B)

One of WAPs by theMSC

B C — —Select the WAP

reporting the higherRSSI value (A)

WAP A by the MSC

C C — — — The station cannotjoin the network

MSC is required to process the event. However, if the eventtarget is limited to a specific area, it may be processed byinformation sharing between the PSCs without interventionby the MSC. A representative example is a network-initiatedstation handoff. In the case of the handoff, a network globalview is not required to move the station to the other WAP,and only a small amount of information on the adjacentWAP is required. Proxcon supports the PSC cooperation forprocessing the event that has local characteristics.

First, consider the existing method in SDN for thenetwork-initiated handoff. In the central control scheme forthe handoff, the MSC should maintain the signal strengthvalues or other handoff metrics of all stations in the networkthat are received from all WAPs. For example, if there aretwenty WAPs and twenty stations in the network, the MSCalways maintains up to four hundred RSSI values in realtime. If the network scale increases, this approach may causelarge overhead of the MSC and quite high control trafficin the network. Another scheme for the handoff controlis a completely distributed one. It performs the handoffby exchanging information with the adjacent WAP whenit is necessary for each WAP. However, this approach canmake it difficult to change the handoff policy. On the otherhand, Proxcon supports locally cooperative control utilizingthe PSCs for the station handoff, and the handoff policycan be easily changed through synchronization for policyestablishment between the MSC and the PSCs.

The information exchange process between neighboringWAPs designed in this study is as follows. The WAP obtainsthe information on the neighboring WAPs by scanningafter boot and reports it to the MSC after the OpenFlowconnection is established. The MSC then informs the WAPof the detailed information on the neighboring WAPs forconnection establishment, such as an IP address and aport number. This process is performed periodically duringnetwork operation.

Figure 6 shows the control flow betweenWAPs during thestation handoff. It is assumed that the network application hasspecified the handoff policy to each PSC before the handoff

WAPfirmware

WAPfirmware

Periodically collectstation context

Is handoffneeded?

No

Yes Establish connectionbetween PSCs ofneighboring WAPs

REQ station context Exchangemonitoredstation contextStart periodic report

station context

Handoffdecision

Close connectionbetween other N-PSCsGet

station contextSend station context

Handoffcommand/reportcompletionNotify

handoff completionRemovestation context

PSC PSC

Figure 6: Handoff process by locally cooperative control utilizingthe PSCs.

process, such as the station RSSI collection cycle, the start ofsignal overhearing at adjacent stations, the RSSI level to startthe information exchange with the PSCs in the neighboringWAPs (N-PSCs), and the RSSI level to perform the handoff.The PSC periodically receives the RSSI value of the stationsfrom the WAP firmware. When the exchange of the RSSIvalue of a certain station with the N-PSCs is required becausethe RSSI value of the station is lower than the thresholdpreset by the network application, the PSC will establisha connection with the N-PSCs. After the connection with


the N-PSCs is established, the PSC periodically exchangesthe RSSI values and compares them. If it is determined thatthe station handoff is required, the PSC will terminate theconnectionwith all otherN-PSCs except for theN-PSC that isin the handoff targetWAP.The PSC then performs the stationhandoff by exchanging the information on the station withthe target N-PSC. Each PSC reports the handoff result to theMSC after the handoff is completed. By this process, Proxconcan significantly reduce the control overhead of theMSC andthe control traffic in the network.

3.4.4. Time Cost Analysis of Each Proxcon Operation. Inthis section, we analyze the offloaded control operationsmentioned above in terms of the time cost. For the analysisof the time cost, we use the following notations:

(i) 𝑇WAP: processing time of the WAP that includesintermodule communication.

(ii) 𝑇MSC: processing time of the MSC.(iii) 𝑇M-W: transmission delay between the MSC and the

WAP.(iv) 𝑇W-W: transmission delay between the WAP and a

neighboring WAP.(v) 𝑇collect: collection time at the MSC.(vi) 𝑁WAP

𝑛

: the number of WAPs near the WAP in whichan event occurs.

(vii) 𝑇𝐸𝑂𝑋

: consumed time for performing the𝑋-type oper-ation in the existing SDN architecture.

(viii) 𝑇𝑃𝑂𝑋

: consumed time for performing the𝑋-type oper-ation in Proxcon architecture.

This analysis does not consider unpredictable latencybetween the WAP and the station, because it intends toevaluate the network control efficiency.

When the event that can be handled through local controloccurs, the consumed time can be expressed as follows:

𝑇𝐸

𝑂𝐿

= 2𝑇M-W + 𝑇MSC,

𝑇𝑃

𝑂𝐿

= 𝑇WAP,

𝑇𝐸

𝑂𝐿−1

= 𝑇M-W + 𝑇MSC,

𝑇𝑃

𝑂𝐿−1

= 𝑇WAP,

(1)

where 𝑇𝑂𝐿−1

means the time cost of the control operation forhandling the event that does not require the response, such asthe monitoring information collection.

The time cost of the hybrid control is as follows:

𝑇𝐸

𝑂𝐻

= 2𝑇M-W + 𝑇collect + 𝑇MSC,

𝑇𝑃

𝑂𝐻

= (𝛽 − 1) (𝑇WAP) + 𝛽 (2𝑇M-W + 𝑇collect + 𝑇MSC) ,(2)

where 𝛽 means the probability of occurrence of the eventrequiring the support of the MSC. The hybrid control opera-tion of Proxcon is directly processed in theWAP or is carriedout with the assistance of the MSC.

The time cost of the cooperative control is as follows:

𝑇𝐸

𝑂𝐶

= 𝑇M-W + 𝑁WAP𝑛

(𝑇M-W + 𝑇MSC) + 2𝑇M-W

+ 𝑇WAP + 2𝑇M-W + 𝑇WAP + 𝑇M-W,

𝑇𝑃

𝑂𝐶

= 𝑇WAP + 𝑁WAP𝑛

(𝑇W-W + 𝑇WAP) + 2𝑇W-W

+ 𝑇WAP.

(3)

Note that the transmission delay is generally greater thanthe processing time, so 𝑇WAP and 𝑇MSC are negligible. Inaddition, we can assume that𝑁WAP

𝑛

is 1, and then the aboveequations can be simplified as follows:

𝑇𝐸

𝑂𝐿

= 2𝑇M-W,

𝑇𝑃

𝑂𝐿

= 0,

𝑇𝐸

𝑂𝐿−1

= 𝑇M-W,

𝑇𝑃

𝑂𝐿−1

= 0,

𝑇𝐸

𝑂𝐻

= 2𝑇M-W + 𝑇collect,

𝑇𝑃

𝑂𝐻

= 𝛽 (2𝑇M-W + 𝑇collect) ,

𝑇𝐸

𝑂𝐶

= 7𝑇M-W,

𝑇𝑃

𝑂𝐶

= 3𝑇W-W.

(4)

Note that 𝑇M-W > 𝑇W-W and 𝛽 < 1 are always valid, so𝑇𝐸

𝑂𝐿,𝐻,𝐶

> 𝑇𝑃

𝑂𝐿,𝐻,𝐶

will be satisfied in all cases.

4. Experimental Results

In this study, we evaluated the performance and efficiency ofProxcon in various aspects. Experiments were carried out onthe wireless network testbed based on the proof-of-concept(PoC) implementation of Proxcon.Theproposed architecturewas evaluated compared to the existing SDN architecture,which consists of one central controller. In the experiment,the scalability, control efficiency, and control overhead wereevaluated, including the response time according to theincrease in the number of WAPs, the communication over-head of the central controller, and the control overheadwhen the actual network application is operated on eacharchitecture.

4.1. Experimental Scenario and Testbed. TheMSC was basedon ONOS as the SDN controller and was operated on adesktop based on Ubuntu 14.04.2 LTS [30]. The WAP wasbased on an APU1D4 embedded board by Netgate, anda WLE200NX by Compex Systems based on the AtherosAR9280 chipset was used as the WLAN module [33, 34].The WAP firmware was implemented by modifying theLinux kernel driver and Hostapd. The stations used in theexperiment were based on Raspberry Pi 1 Model B+, and aUSB wireless adapter and a separate battery were added [35].


SDNWAPs

Hub

Main SDNcontroller

Hosts

Mobile stations

SDNswitches

Figure 7: Testbed topology for experiments.

To evaluate Proxcon, as shown in Figure 7, we haveimplemented the SDN-based wireless network testbed com-posed of a single MSC, seven mobile stations, and fourWAPs consisting of the PSC and the Proxcon agent. Inall experiments, approximately 100 to 200 wireless networkevents occur per second from eachWAP.Most of these eventsare to report the RSSI values of the stations; in other words,eachWAP reports the RSSI values of the neighboring stationsevery 20ms. The generated events also include the event thatrequires a response, such as packet-IN and network join/leaveof the client, and the event initiated by the control plane, suchas the WAP configuration change and client handoff.

The frequency of the synchronization between the MSCand the PSCs may be variably set depending on the purposeof the network application, but it was set to 1 s in the experi-ments. All experiments were compared to the control archi-tecture using a single MSC. Most of the SDN-based wirelessnetwork researches have focused on the client handoff, WAPconfiguration, and the abstraction scheme, and researcheson the control plane architecture have concentrated ondeployment of theMSC.Therefore, the experiment comparedto the single MSC-based control architecture will show quitesimilar results with direct comparison with existing SDN-based wireless network researches.

4.2. Scalability and Control Latency Issue. Figure 8 depicts acumulative distribution function (CDF) graph showing theaverage response time of all transactions in accordance withthe architecture type and the number of WAPs. The resultwas quite intuitive, and the response time in Proxcon wassignificantly faster for most of the event processing than thatin the existing SDN architecture regardless of the numberof WAPs. In particular, the response time in the existingarchitecture is even longer because the transaction time of

5 10 15 20 25 30 35 400Response time (ms)

Single MSC (1 WAP)Single MSC (3 WAPs)Proxcon (1 WAP)Proxcon (3 WAPs)

Single MSC (2 WAPs)Single MSC (4 WAPs)Proxcon (2 WAPs)Proxcon (4 WAPs)

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

CDF

Figure 8: Experimental results related to scalability issues accordingto the control architecture and the number of WAPs.

an event such as station join, which should be processed in away determined after collection at theMSC, includes a reportcollection time as well as a network delay. On the other hand,the response time in Proxcon is considerably fast because thePSC solely determines the station connection in most casesby using metrics such as RSSI.

Naturally, the distribution of the response time in Prox-con depends on the proportion of the certain operation typesuch as the hybrid operation utilizing both the MSC and thePSC and the local cooperation between the PSCs. However,compared to the existing SDN architecture in which theremote MSC is in charge of responses to all events, thedistribution in Proxcon will remain low.

Figure 9 shows the response time distributions in aboxplot graph. As described above, the response time in theexisting architecture is higher than that in Proxcon owingto the network delay and the data collection latency at theMSC for the particular events. The outliers of the Proxcongraph express the response time of the MSC when thesynchronization or hybrid operation is performed.

As shown in both Figures 8 and 9, the response time ofthe existing architecture is increased according to the numberof WAPs, whereas the response time of Proxcon does notincrease. As mentioned above, one WAP was set to generatemany events owing to the limitations of the testbed. In the realenvironment, because a large number of WAPs will generatea number of events, the average response time in the realenvironment will be similar to the foregoing results.

Figure 10 shows the results of a single WAP controlresponse time measured on the existing SDN architecturewith background traffic. The background traffic was setto 0, 20, 50, 100, 200, 300, 500, 750, and 1000Mbps on


0.34 0.47 0.42 0.45 5.05

7.74

12.77

20.53

in Proxcon in single MSC

0

5

10

15

20

25

30

35

40

45Re

spon

se ti

me (

ms)

2 3 41The number of WAPs

2 3 41The number of WAPs

Figure 9: Responsiveness comparison between the existing archi-tecture and Proxcon.

a wired link whose physical bandwidth was 1 Gbps. Thehigh background traffic caused the irregular, high controlresponse time. In particular, more than 70 percent of theevent response time exceeded 50ms when the wired link wassaturated.These results show that the SDN architecture usinga single controller is quite vulnerable to network congestion.In addition, the control reliability may decline significantly ina network with significant background traffic.

4.3. Effects on Actual Network Application. Themain purposeof Proxcon introducing the concept of the PSC within aWAPis to resolve the issues of scalability and slow response time.To resolve these issues is to respond to the events rapidly andaccurately. In this section, we evaluate the control efficiencyof the Proxcon operations, such as the PSC-based control,the hybrid control, and the locally cooperative control, whenProxcon actually supports the wireless network applications.Two experiments were conducted: one handles the stationjoin event to evaluate the efficiency of the hybrid control,and the other controls the station handoff to assess the PSCcooperation.

Figure 11 indicates the averageRSSI values and the averageresponse time of the station join and station handoff. Thestations used in the experiment are stationary or mobilewithin the wireless network coverage, and the station handoffoccurs based on the RSSI value during movement. In bothexperiments, the average RSSI value is the arithmetic meanof the RSSI values measured in all WAPs every 100ms. Theaverage latency is a measured value from the moment whenthe significant value is inputted to theWAP until themomentwhen the proper handling for the event is performed. Asseen in the graph, the average RSSI values of the existingarchitecture and Proxcon in both experiments remained ata similar level. However, a significant difference is seen in thetime required to respond to the event.

0.4

0.5

0.6

0.7

0.8

0.9

1

CDF

5 10 15 20 25 30 35 40 45 500Response time (ms)

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

CDF

20 40 60 80 100 120 140 160 180 2000Response time (ms)

500 Mbps100 Mbps0Mbps

750Mbps200 Mbps20 Mbps

1000 Mbps300 Mbps50Mbps

Figure 10: Response time in the network congestion state.

Avg.

RSS

I for

stat

ion

join

Avg.

RSS

I for

stat

ion

hand

off

Stat

ion

join

late

ncy

Stat

ion

hand

offla

tenc

y

Single MSCProxcon

0

−10

−20

−30

−40

−50

−60

−70

Avg.

RSS

I (dB

)

0

5

10

15

20

25

30

35

Late

ncy

(ms)

Figure 11: Experiments on the actual applications. The yellow barsrefer to “singleMSC” and the yellow striped bars refer to “Proxcon.”


The latency for a single MSC-based station join processis the value consisting of the time to transmit the eventinformation to the MSC from the WAP, the waiting timefor data collection at the MSC, and the time to send theresponse to a certain WAP. On the other hand, in the case ofProxcon, if the probe request framewithRSSI value exceedingthe threshold is received, the PSC immediately processes theevent, so only the interprocess communication (IPC) delay isincurred. In a low probability, if a probe request frame with alower RSSI value than the threshold is received by all WAPs,the hybrid control is required to handle the event, the delayof which would be similar to the single MSC-based control.

The latency for the single MSC-based handoff control isthe value comprising the time to transmit the RSSI data fromtheWAP to theMSC, the time to collect all RSSI reports at theMSC, the time to request the station information on the oldWAP and to receive it, the time to forward the informationto the new WAP and receive the completion report, and thetime to issue the command for removing the station context.On the other hand, the latency in Proxcon consists of the timeto transmit the RSSI value of the station to the N-PSCs, theresponse time from the N-PSCs that overheard the stationcommunication with a higher RSSI value, the transmissiontime of the station information, and the response time of thehandoff completion. Because the communication with theneighboring WAPs is carried out at a relatively low latency,it was confirmed that the handoff control in Proxcon isperformed with lower latency compared to communicationwith the MSC in the existing SDN architecture.

As seen in the experiments above, although Proxcondistributes part of roles of the central controller to eachWAP,the wireless network controls based on Proxcon, such asthe station join processing and the station handoff control,were performed with almost the same efficiency as theexisting architecture. However, the average control time forevent processing is decreased significantly. In addition, thedifference in the response time will increase with increasingnetwork size or number ofWAPs. In other words, when targetnetworks become larger, the control result is expected to besignificantly different depending on the control architecturebecause a high control delay of the existing SDN architecturewill significantly reduce the control reliability.

In particular, in terms of the mobile network, it isexpected that this control overhead reduction schemebecomes even more important. Looking briefly, the networkobviously needs control, and collecting information at thecontroller is especially required for decision-making in SDN.The mobile network is pushing forward the progress to5G, and one of the main features of 5G is small cell thatcollaborates withWi-Fi. In other words, the range of the basestation of 5G mobile network may be extended to the Wi-FiWAPs, and it means that the density of the base station is alsoincreased.

4.4. Effects on Main SDN Controller in terms of Traffic. If theconcept of a proxy controller is introduced to control thewireless networks, the control load of the central controllerwill be naturally reduced. Figure 12 indicates the traffic load

Single MSCProxcon

50 100 150 200 250 300 3500Times (s)

0

2

4

6

8

10

12

14

16

18

MSC

load

(kilo

byte

s/s)

Figure 12: Average traffic load of the main SDN controller.

of the MSC according to the architecture type. As mentionedearlier, the synchronization cycle was set to 1 s.

The average control traffic at the MSC was 13.93 kB/sin the existing SDN architecture and 0.87 kB/s in Proxcon.Understandably, Proxcon can reduce the control traffic atthe MSC because most of the event responses are performedby the communication of the internal WAP or betweenthe WAPs. This means that an increase in the number ofWAPs under Proxcon does not significantly affect the controloverhead of the MSC, so the MSC can concentrate on thecontrol of the wired networks as in the existing SDN archi-tecture. In addition, Proxcon can reduce the control traffic onthe network and thus perform the network operation moreefficiently.

As seen in the experiments above, Proxcon distributespart of roles of the central controller pertaining to networkcontrol to each WAP, and thus the control traffic on thenetwork and the response time are reduced. In addition,the network control is not significantly affected by networkcongestion. This means that it is possible to increase thereliability of the network control and support the scalability.In addition, although the role of the central controller isdistributed to each WAP, the control operations for actualnetwork applications, such as station join and station handoff,demonstrated approximately the same efficiency as the exist-ing architecture, whereas it was confirmed that the responsetime is significantly reduced.

5. Conclusion

In this paper, we proposed Proxcon, a control architecturebased on SDN for the control of wireless networks. Becausecontrol of wireless networks mostly comprises event-basedmanagement, Proxcon provides scalability regardless of


the MSC performance and distance on the MSC by sup-porting three offloaded control operations based on the PSCand the Proxcon agent in every WAP. It also ensures reliable,immediate control based on this scheme.

The proposed architecture was evaluated through exper-iments on the testbed based on the PoC implementation.According to the experimental results, compared to theexisting SDN architecture, Proxcon efficiently resolves thescalability issue that results from the number of WAPs in thenetwork, and it was confirmed that the control performanceis not significantly affected by backhaul network conditionssuch as congestion. From the experiments on handling actualnetwork applications, although the proposed architecturedoes not manage all network information in the central con-troller, the response delay was reduced, whereas the controlperformance demonstrates the same efficiency as the MSC-based control. In addition, Proxcon reduced the operationload of the MSC by reducing the traffic to the MSC, whichprevented degradation of the MSC control performance dueto the impact of additional functions such as wireless networkcontrol.

In the future work, we will focus further on the SDNcontrol architecture to expand the concept of the proxycontrol plane to the wired networks. More specifically, astudy will be performed to address the issues of efficiencyand consistency of the synchronization between the centralcontrollers and the proxy controllers. In particular, we willseek to combine the concept of SDN and fog computing thatmoves some controller instances to WAPs or switches.

Competing Interests

The authors declare that they have no competing interests.

Acknowledgments

Thisworkwas supported by Institute for Information&Com-munications Technology Promotion (IITP) grant funded bytheKorea government (MSIP) (no. B0126-16-1051, A Study onHyper Connected Self-Organizing Network InfrastructureTechnologies for IoT Service).

References

[1] N. McKeown, T. Anderson, H. Balakrishnan et al., “OpenFlow:enabling innovation in campus networks,” ACM SIGCOMMComputer Communication Review, vol. 38, no. 2, pp. 69–74,2008.

[2] X. F. Xiao and X. Kui, “The characterizes of communica-tion contacts between vehicles and intersections for software-defined vehicular networks,”Mobile Networks and Applications,vol. 20, no. 1, pp. 98–104, 2015.

[3] C.-F. Lai, R.-H. Hwang, H.-C. Chao, M. M. Hassan, and A.Alamri, “A buffer-aware HTTP live streaming approach forSDN-enabled 5G wireless networks,” IEEE Network, vol. 29, no.1, pp. 49–55, 2015.

[4] M. Abolhasan, J. Lipman, W. Ni, and B. Hagelstein, “Software-defined wireless networking: centralized, distributed, orhybrid?” IEEE Network, vol. 29, no. 4, pp. 32–38, 2015.

[5] S. Vissicchio, L. Vanbever, and O. Bonaventure, “Opportunitiesand research challenges of hybrid software defined networks,”ACMSIGCOMMComputer CommunicationReview, vol. 44, no.2, pp. 70–75, 2014.

[6] S. Sezer, S. Scott-Hayward, P. Chouhan et al., “Are we readyfor SDN? Implementation challenges for software-defined net-works,” IEEE Communications Magazine, vol. 51, no. 7, pp. 36–43, 2013.

[7] S. Gringeri, N. Bitar, and T. Xia, “Extending software definednetwork principles to include optical transport,” IEEE Commu-nications Magazine, vol. 51, no. 3, pp. 32–40, 2013.

[8] W.-S. Kim and S.-H. Chung, “Interface assignment-basedAODV routing protocol to improve reliability inmulti-interfacemultichannel wireless mesh networks,” Mobile InformationSystems, vol. 2015, Article ID 768596, 16 pages, 2015.

[9] S. Salsano, N. Blefari-Melazzi, A. Detti, G.Morabito, and L. Vel-tri, “Information centric networking over SDN and OpenFlow:architectural aspects and experiments on the OFELIA testbed,”Computer Networks, vol. 57, no. 16, pp. 3207–3221, 2013.

[10] T.-W. Um, G. M. Lee, and J. Kim, “SDN-based active contentnetworking,” International Journal of Distributed Sensor Net-works, vol. 2016, Article ID 1603239, 6 pages, 2016.

[11] W.-S. Kim, S.-H. Chung, and J.-W. Moon, “Improved con-tent management for information-centric networking in SDN-based wireless mesh network,” Computer Networks, vol. 92, pp.316–329, 2015.

[12] C. J. Bernardos,A.DeLaOliva, P. Serrano et al., “An architecturefor software defined wireless networking,” IEEE Wireless Com-munications, vol. 21, no. 3, pp. 52–61, 2014.

[13] N. Chen, S. Sun, M. Kadoch, and B. Rong, “SDN controlledmmwave massive MIMO hybrid precoding for 5G heteroge-neous mobile systems,” Mobile Information Systems, vol. 2016,Article ID 9767065, 10 pages, 2016.

[14] W. Kim, S. Chung, and J. Shi, “WiPCon: a proxied controlplane for wireless access points in software defined networks,”inProceedings of the IEEE International Conference onComputa-tional Science and Engineering (CSE ’14), pp. 923–929, Chengdu,China, December 2014.

[15] V. Shrivastava, N. Ahmed, S. Rayanchu et al., “CENTAUR:realizing the full potential of centralized WLANs through ahybrid data path,” in Proceedings of the 15th Annual ACMInternational Conference on Mobile Computing and Networking(MobiCom ’09), pp. 297–308, ACM, Beijing, China, September2009.

[16] R. Murty, J. Padhye, R. Chandra, A. Wolman, and B. Zill,“Designing high performance enterprise Wi-Fi networks,” inProceedings of the USENIX Symposium on Networked SystemsDesign and Implementation (NSDI ’08), pp. 73–88, San Fran-cisco, Calif, USA, April 2008.

[17] R. Murty, J. Padhye, A. Wolman, and M. Welsh, “Dyson: anarchitecture for extensible wireless LANs,” in Proceedings ofthe USENIX Annual Technical Conference (ATC ’10), pp. 1–14,Boston, Mass, USA, June 2010.

[18] L. Suresh, J. Schulz-Zander, R. Merz, and A. Feldmann, “Demo:programming enterprise WLANs with odin,” ACM SIGCOMMComputer Communication Review, vol. 42, no. 4, pp. 279–280,2012.

[19] J. Schulz-Zander, L. Suresh, N. Sarrar, A. Feldmann, T. Huhn,and R.Merz, “Programmatic ochestration ofWiFi networks,” inProceedings of the USENIX Annual Technical Conference (ATC’14), pp. 347–358, Philadelphia, Pa, USA, June 2014.


[20] D. Zhao, M. Zhu, andM. Xu, “Supporting ‘One Big AP’ illusionin enterprise WLAN: an SDN-based solution,” in Proceedingsof the 6th International Conference onWireless Communicationsand Signal Processing (WCSP ’14), pp. 1–6,Hefei, China, October2014.

[21] I. T. Haque and N. Abu-Ghazaleh, “Wireless software definednetworking: a survey and taxonomy,” IEEE CommunicationsSurveys & Tutorials, 2016.

[22] H. Yao, C. Qiu, C. Zhao, and L. Shi, “A multicontroller loadbalancing approach in software-defined wireless networks,”International Journal of Distributed Sensor Networks, vol. 2015,Article ID 454159, 8 pages, 2015.

[23] R. Riggio, M. K. Marina, J. Schulz-Zander, S. Kuklinski, andT. Rasheed, “Programming abstractions for software-definedwireless networks,” IEEE Transactions on Network and ServiceManagement, vol. 12, no. 2, pp. 146–162, 2015.

[24] A. Tootoonchian andY. Ganjali, “HyperFlow: a distributed con-trol plane for OpenFlow,” in Proceedings of the Internet NetworkManagement Workshop/Workshop on Research on EnterpriseNetworking (INM/WREN ’10), pp. 1–6, San Jose, Calif, USA,April 2010.

[25] S. H. Yeganeh, A. Tootoonchian, and Y. Ganjali, “On scalabilityof software-defined networking,” IEEE Communications Maga-zine, vol. 51, no. 2, pp. 136–141, 2013.

[26] A. Dixit, F. Hao, S. Mukherjee, T. V. Lakshman, and R. Kom-pella, “Towards an elastic distributed SDN controller,” ACMSIGCOMMComputer Communication Review, vol. 43, no. 4, pp.7–12, 2013.

[27] R. Riggio, S. Kuklinski, T. Rasheed, D. Andreatta, D. Tacconi,and F. Antonelli, “Up in the clouds: a taxonomical analysisof network management functionalities from a network as aservice perspective,” inProceedings of the 18th EuropeanWirelessConference (EW ’12), pp. 1–8, Poznan, Poland, April 2012.

[28] A. R. Curtis, J. C. Mogul, J. Tourrilhes, P. Yalagandula, P.Sharma, and S. Banerjee, “DevoFlow: scaling flowmanagementfor high-performance networks,” ACM SIGCOMM ComputerCommunication Review, vol. 41, no. 4, pp. 254–265, 2011.

[29] M. Yu, J. Rexford, M. J. Freedman, and J. Wang, “Scalable flow-based networking with DIFANE,” ACM SIGCOMM ComputerCommunication Review, vol. 40, no. 4, pp. 351–362, 2010.

[30] Open Network Operating System, http://onosproject.org/.[31] OpenDaylight, https://www.opendaylight.org/.[32] K. Guo, S. Sanadhya, and T. Woo, “ViFi: virtualizing WLAN

using commodity hardware,” ACM SIGMOBILE Mobile Com-puting and Communications Review, vol. 18, no. 3, pp. 41–48,2014.

[33] PC Engines APU1D4 System Board, http://www.pcengines.ch/apu1d4.htm.

[34] PC Engines wle200nx 802.11a/b/g/n miniPCI express radio,http://www.pcengines.ch/wle200nx.htm.

[35] Raspberry Pi 1 Model B+, https://www.raspberrypi.org/.

Submit your manuscripts athttp://www.hindawi.com

Computer Games Technology

International Journal of

Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014


Distributed Sensor Networks


Advances in

FuzzySystems

Hindawi Publishing Corporationhttp://www.hindawi.com

Volume 2014


ReconfigurableComputing

Hindawi Publishing Corporation http://www.hindawi.com Volume 2014


Applied Computational Intelligence and Soft Computing

Advances in

Artificial Intelligence


Advances inSoftware EngineeringHindawi Publishing Corporationhttp://www.hindawi.com Volume 2014


Electrical and Computer Engineering

Journal of

Journal of

Computer Networks and Communications


Hindawi Publishing Corporation

http://www.hindawi.com Volume 2014

Advances in

Multimedia


Biomedical Imaging


ArtificialNeural Systems

Advances in


RoboticsJournal of



Computational Intelligence and Neuroscience

Industrial EngineeringJournal of


Modelling & Simulation in EngineeringHindawi Publishing Corporation http://www.hindawi.com Volume 2014

The Scientific World JournalHindawi Publishing Corporation http://www.hindawi.com Volume 2014


Human-ComputerInteraction

Advances in

Computer EngineeringAdvances in


Research Article Proxy SDN Controller for Wireless...

Documents

Transcript of Research Article Proxy SDN Controller for Wireless...