Deploying WLAN Service with OpenFlow Technologies

Huai-Wen Hsu3, Kuei-Li Huang2, Yi-Chih Kao1, Shi-Chun Tsai3, and Yi-Bing Lin3

1Information Technology and Service Center, National Chiao Tung University, Hsinchu, Taiwan2 Information and Communication Lab, Industrial Technology Research Institute, Hsinchu, Taiwan

3 College of Computer Science, National Chiao Tung University, Hsinchu, Taiwan

SUMMARY

In this paper, we proposed a feasible SDN WLAN solution, which leverages OpenFlow technique and provides affordable centralized WLAN service without the proprietary restrictions of centralized thin AP WLAN architecture. Based on an SDN-enabled WLAN architecture with fat APs, we implement and deploy a wireless network test bed, where network administrators can exploit the extensibility and flexibility of OpenFlow-based SDN switches and controller. Service providers can develop customized application modules and required features. We build our system with open sources and commercial off-the-shelf (COTS) hardware, and develop a mechanism to control wireless bandwidth. Field experimental results show that our SDN wireless bandwidth control application can effectively manage bandwidth in a dynamic and flexible way via the SDN WLAN.

Index Terms—1. Network Management/1.2 Wireless & mobile networks, 5. Management Approach/ 5.1 Centralized Management (Software Defined Network), 7. Methods/ 7.8 Experimental Approach

1. INTRODUCTIONWireless local area networks (WLANs) have been widely deployed in enterprises, campuses, offices, and

home environments using unlicensed radio bands, thereby users can carry mobile devices to connect to the network through access points (APs). After attaching to an IEEE 802.11 AP, a mobile device can send and receive packets via the wired infrastructure through WLAN. There are two types of APs: fat APs and thin APs. Fat APs are popular in homes and small offices to provide wireless connection to user devices and offer network services such as dynamic host configuration protocols (DHCP) and network address translation (NAT). Thin APs are usually installed with licensed firmware and deployed in large enterprises. They connect to a mobility controller [1] and provide radio connectivity to users. The mobility controller allows centralized authentication and management, and provides network functions to user devices.

Each FAT AP operates as an independent device [2]. But the independent AP architecture suffers from scalability and management problem. It is difficult to configure and manage a large scale wireless network. Each thin AP operates as a controller-based device, and is usually part of a centrally managed enterprise WLAN network. While FAT APs are popular and much cheaper in price compared with thin AP. Existing unified access management platforms are costly and closed systems, and they typically include LAN switching, WLAN controllers and access points as the entire solution supplied by a single vendor.

At the time when we prepared this work, there were a couple of commercially available SDN WLAN solutions announced. For example, in March 2015, HP acquired Aruba Networks [3] to provide SDN BYOD solution [4]. In July 2015 Fortinet acquired Meru Networks [5] and bring SDN to the WLAN solutions [6]. However, solutions by vendors are proprietary. It is difficult to add new features. The most notable difference of our solution is that we also develop SDN AP operations, administration, and management (OAM) application running on the OpenSource SDN controller. This application enables network administrator to manage SDN APs through SDN switch.

Here, we propose an affordable wireless system with OpenFlow-based software-defined networking (SDN) WLAN architecture, which provides services through SDN switches managed by one or more SDN controllers. Each switch connects to the proposed SDN WLAN controller over an OpenFlow channel with

1

the optional transport layer security (TLS) protocol [7]. Our system adopts fat APs as SDN switches, by installing the fat APs with firmware that supports OpenFlow-based switching functions and OpenWrt [8] firmware. With the refurbished fat APs and SDN controller, we have developed a wireless network service with the flavor of centralized thin AP approach. In addition, this architecture provides a flexible way to manage a WiFi wireless network in several aspects, such as bandwidth, antenna power, etc., based on the advantage that the SDN controller can manage APs dynamically and interactively.

In this work we have identified important issues for related services and successfully deployed and operated it as part of our system for campus visitors’ WLAN services. Overall, the SDN paradigm provides flexibility and leads to a significant CAPEX saving. While for OPEX, the cost is slightly higher, since it needs more efforts for system developing and maintenance. Therefore, to support such type of service, we find that it will be a norm that a network administrator could also be a skillful programmer. The rest of the paper is organized as follows. Section 2 describes the OpenFlow and SDN architecture. Section 3 presents an SDN WLAN design. Section 4 demonstrates the setup of experiments and the results. Section 5 concludes with some remarks.

2. BACKGROUNDS AND RELATED WORKS

The SDN technology was initiated at the University of California at Berkeley and Stanford University in 2008 [9]. SDN technology is used to manage backbone network services at internet-based companies such as Google and Internet2. In an SDN architecture, network logic is centrally managed by a programmable SDN controller. The OpenFlow protocol enables communications between the controller and SDN switches. SDN is developed under open standards, thus the underlying infrastructure can be easily expanded to accommodate new applications and network services [10].

2.1 SDN architecture

The foundation for building SDN solutions is the OpenFlow protocol standard published by the Open Networking Foundation (ONF) [11]. Later, ONF in September 2013 published OpenFlow-enabled mobile and wireless solution briefs, but still it has not specifically targeted at WLAN [12]. Figure 1 shows that ONF partitions the SDN architecture into three logical layers: the Application Layer, the Control Layer, and the Infrastructure Layer [13].

2

Figure 1 ONF/Software-Defined Network (SDN) architecture

As shown in Figure 1 (a), business applications developed in the SDN controller include information technology security, integration of cloud-based databases, etc. Users can purchase these features at quantities suitable for their needs. The SDN controller provides northbound application programming interfaces (APIs: see Figure 1 (b)) to enable various network application functions. Popular open source controllers adopted in the Control Layer (Figure 1 (c)) include POX [14], Ryu [15], Floodlight [16], OpenDaylight [17], etc. Through southbound APIs (Figure 1 (d)), the SDN controller is used to manage the data plane, i.e., the SDN Switch in the Infrastructure Layer (Figure 1 (e)).

2.2 SDN based WLANs

For SDN-enabled WLAN, Suresh et al. [18] proposed an SDN framework (named as Odin) to introduce programmability in enterprise wireless local area networks (WLANs). Odin is built on a light virtual AP abstraction that greatly simplifies client management. Odin does not require any client side modifications and its design supports WPA2 Enterprise. Monin et.al [19] present Chandelle system that allows to faster roaming procedure by integrating CAPWAP [20] wireless controller with SDN/OpenFlow controller. Lee et.al [21] propose a novel SDN based high availability (HA) solution for wireless WLAN utilizing the open network operating system (ONOS) controller [22], and make a performance evaluation under a test environment. Lalith [23] uses the Odin software defined networking framework to demonstrate that, by using a set of abstractions, it is possible to express common enterprise WLAN services as network

3

applications. Lei et.al [24] construct software access point and deploy an SDN based campus WLAN framework (called SWAN) to provide more flexibility and expandability. An SWAN protocol is used by SWAN controller to invoke commands on the agents and collect statistics from them. Thus network operators can design programs to manage and configure the network.

3. DESIGN OF OUR PROPOSED SYSTEM

In this section, we first briefly describe the advantages and limitations of the traditional thin AP WLANs and then elaborate on our SDN WLAN architecture based on fat AP to address the issues of thin AP.

3.1 Limitations of thin AP WLAN architectureFigure 2 illustrates a typical thin AP WLAN architecture. The APs (Figure 2 (a)) are deployed in

several service areas. A service area consists of one or more layer 2 switches (Figure 2 (b)) that connect to core switch (Figure 2 (c)) through a fiber network, and provide the network connection for thin APs. The core switch provides inter-vlan routing. The WAN Gateway (Figure 2 (d)) performs the "traffic directing" functions and works as an entry/exit point to the Internet.

A typical wireless service is governed by a core mobility controller (Figure 2 (e)) that manages APs and provides thin AP authentication services, by which all security policies are centrally managed, enforced, and configured. Also, it can dynamically allocate AP’s radio channels to avoid conflict and to enhance performance.

When a user connects to the thin AP WLAN, the DHCP server (Figure 2 (f)) automatically leases a private IP to user’s mobile device. One can enter the user name and password to access the login portal (Figure 2 (g)), and the authentication is done by the Radius Server (Figure 2 (h)). The Intrusion Detection System/Firewall (IDS/FW) (Figure 2 (i)) provides network security service, and the network traffic is filtered by the IDS/FW before the mobile device can utilize the IP and Port translation service on the NAT Server (Figure 2 (j)) for Internet connection.

Figure 2 an example of thin AP WLAN

4

However, in a thin AP WLAN, network administrators cannot easily develop new features. Since the thin AP WLAN is proprietary, both of APs and mobility controller are usually provided by the same network equipment vendor. This issue motivates us to implement the SDN mechanism proposed next.

3.2 Proposed SDN WLAN ArchitectureSince fat APs are widely available, they are much cheaper than thin APs. We propose an SDN WLAN

architecture by replacing the firmware of fat APs with OpenWrt firmware to make them function as SDN APs so that they can connect to an SDN controller and can be managed by the SDN controller. Therefore, the fat APs are responsible solely for sending and receiving signals. By developing OAM modules on the SDN controller, network administrators can overcome the limitations of ill-coordinated fat APs. On the other hand, the SDN controller provides an open platform architecture that allows deployment of new management features that cannot be conveniently achieved by a traditional thin AP WLAN.

Figure 3 illustrates our SDN WLAN architecture. Firmware of each SDN switch (Figure 3 (b)) is upgraded with Linux-based OpenWrt BARRIER BREAKER (release 14.07) and installed with OpenVSwitch. The core switch (Figure 3 (l)) connects to the SDN controller (Figure 3 (c)) to manage each switch via a channel with the optional TLS protocol. The DHCP/NAT Server (Figure 3 (m)), connects to the core switch to provide DHCP/NAT functions and Internet access. Each service area hosts one or more SDN switches, which connect to the SDN core switch via VXLAN tunnels and multiple APs (Figure 3 (a)), which are installed with Linux-based OpenWrt BARRIER BREAKER (release 14.07) and OpenVSwitch. The SDN controller (Figure 3 (c)) contains application modules from which network applications can be expanded. For the current version it includes Access Controller (AC) module (Figure 3 (d)) with redirect function, and User Flow Management (UFM) module (Figure 3 (e)). The Wireless AP(WAP) controller (Figure 3 (f)) contains OAM module (Figure 3 (g)) and REST services (Figure 3 (h)). The Radius Server (Figure 3(i)) connects to the Login Portal (Figure 3 (j)), which links to SDN core switch. All of the information data will be stored in a central database (DB) (Figure 3 (k)) and managed with a Web UI (Figure 3 (n)) over the two Controllers. In Figure 3, the SDN controller reliability can be improved by clustering two SDN controllers in active/hot standby modes. These features are typically found in the mobility controller of the thin AP architecture.

5

Figure 3 Proposed SDN WLAN Architecture

Within the SDN WLAN architecture, we upgrade the non-SDN switches with firmware that supports OpenFlow-based SDN switching functions, and install OpenWrt-supported fat APs with OpenWrt firmware. This SDN WLAN enables authentication via our modules. For details we refer to the article [8], which shows how to modify the fat APs, reconfigure according to network environment and verify the desired functions through OAM functions. We thus can compile the OpenWrt firmware, upload the firmware and then modify the AP configuration.

3.3 Network OperationWhen a user connects to the SDN AP (Figure 3 (a)), the DHCP server (Figure 3 (i)) will provide a

private IP. As the first packet is received by the switch (Figure 3 (b)), the switch will match the packet MAC address with a flow table. This attempt will fail, and the switch will direct the packet to the SDN controller (Figure 3 (c)) via the OpenFlow protocol with packet header encapsulation. The SDN controller receives the packet header and checks the database (Figure 3 (k)) to determine whether the user’s device has been previously authenticated. Since it has not, no authentication record is found. Therefore, the redirect function in Access Controller module (Figure 3 (d)) changes the destination IP address in the packet header to the IP address of the Login Portal (Figure 3 (j)) and returns it to the SDN controller. After a TCP/IP three-way handshake, the end user will see the Login Portal web page. If the user accepts the “End User Agreement”, he/she is authenticated via the Login server (Figure 3 (j)). The authentication information and the MAC address of the device will be stored in the DB (Figure 3 (k)) for future authentications. A flow entry, including a match field record containing the MAC address of the user device, is created in the flow table. Before this flow entry is removed, a user can access the Internet without login through the NAT for IP & Port translation (Figure 3 (m)). To ensure that this new network architecture does provide stable services, a primitive OAM module (Figure 3 (g)) is developed such that the network administrators can easily monitor AP status.

6

3.4 OAM functions To meet the network management requirements for an SDN WLAN, we develop a client agent software

and install it via SSH on every AP to capture system information of the AP, such as user statistics, and network usage statistics. When this agent receives a query command from the WAP controller to look up information about the AP, the agent issues the “iwinfo wlan0 info” command, which is built in the OpenWrt running on the AP. The information received by the WAP controller from APs are parsed and displayed through a web based interface as in Figure 4.

Through the Web UI, we can monitor the AP status as in Figure 4 (a), the Client status as in Figure 4 (b) and Configurations of AP and Controller as in Figure 4 (c). Figure 4(d) shows flow statistics of users.

(a) Access point status

The information received include: MAC Address (AP MAC: C8:D3:A3:5C:XX:XX), AP channel management (Channel: 1), AP transmission power (Txpower: 20 dBm), SSID management (SSID: "NCTU-Free"), user connection statistics for APs, user bandwidth slicing and data transfer statistics.

(b) Client status

7

(c) Configuration

(d) Flow statistics of users Figure 4 Illustration of OAM functionalities

3.5 Wireless Bandwidth Control ApplicationA wireless bandwidth control application is an OAM application module on top of an SDN controller,

which provides network administrators a function to configure bandwidth control policies on APs. The bandwidth control function on the AP can be enabled by installing the traffic control module into the OpenWrt on the APs. This module can be utilized to configure queues maintained in the kernel space of

8

OpenWrt. Basically, bandwidth control on AP is port-based. That is, each port associates with a number of queues and each defines its own queueing policies such as guarantee bit rate and maximum bit rate. To realize flexible bandwidth control on an AP, we adopt client agent software [25] and install it via SSH on the AP to configure queueing policies. The client agent maintains and manages queues through the traffic control module and provides the queue information to the wireless bandwidth control application through the OpenFlow interface so as to install special flow entries into the SDN flow table for bandwidth control.

As shown in Table 1, packets matching the first flow entry are sent to port 2 and queued in queue 1 of port 2, while the second flow entry guides packets heading for the host with IP address 192.168.1.2 to port 2 yet queued in queue 2 of port 2. As shown in Table 2, a packet flow which matches the first flow entry in Table 1 is allowed 2 megabit per second guaranteed bit rate and limited to 3 megabit per second maximum bit rate; a packet flow matching the second flow entry is with 1 megabit per second guaranteed bit rate and 4 megabit per second maximum bit rate. Therefore, the wireless bandwidth control application co-working with the client agent can provide network administrator a configuration interface to enforce and dynamically adjust the wireless bandwidth policies on APs.

Table 1 Flow Entries with Enqueue Actions

Table 2 Queue Configuration

4. EXPERIMENTAL RESULTS

This section conducts measurements on the performance and cost of the proposed SDN WLAN. In our system, we adopt OpenFlow protocol version 1.0, because of the popularity and support of hardware vendors.

4.1 Bulk Transfer PerformanceWe compare transfer rates of the SDN WLANs and the thin AP WLANs (equipped with Aruba 6000

mobility controller and AP-93 access point). According to [26], most wireless users access network applications such as web service, emails and social media through WLAN. Thus, transfer rates can be measured by uploading and downloading files of different sizes (1, 5, 10, 20, 40, 50 MB) using the FTP client running on the same notebook model at the same location and within the same timeframe through the two WLANs to the same FTP server (Pure-ftpd). We repeated one hundred tests on uploading and downloading files. The average transfer times are summarized in Figure 5 (a). The average upload time of 50 MB file in the SDN WLAN is 12.7156 seconds, while thin AP WLAN is 11.4567 seconds. In contrast, the average download time of 50 MB file in the SDN WLAN is 11.2613 seconds, while thin AP WLAN is 11.9141 seconds. That is, the SDN WLAN almost has the same performance as the thin AP in downloading files, yet with uploading performance around 11 % slower than that in the thin AP WLAN. The reason is

9

that in order to manage packets, an SDN AP processes each packet in user space, while a thin AP decapsulates and encapsulates packets in the kernel space. The processing delays of packets in user space can be reduced if we implement either “Openflow” or “OpenvSwitch” as kernel modules to improve the performance of an SDN AP, which will be our future work.

4.2 Round-Trip DelayWireshark is a network protocol analyzer. It lets users capture and interactively browse the traffic

running on a computer network. It has a rich and powerful feature set and is the most popular tool of its kind. It is freely available as open source [27]. We use Wireshark (Ver. 1.8.7) to simultaneously measure delay times through the SDN WLAN and the thin AP WLAN with 10 laptop computers. By repeating the experiment for 1000 times, we measured the delay time (t1) between end users and wireless login portal (Figure 3 (j)), and the delay time (t2) between wireless login portal and campus main page (http://www.nctu.edu.tw) via SDN Core Switch (Figure 3 (l)). All nodes are configured to query an NTP server to synchronize the clock on the machine or to provide time service to other computers in the network. Averages of the measured delays are plotted in Figure 5 (b).

SDN WLAN has a longer delay t1 than that of the thin AP WLAN. Since SDN controller has to acquire forwarding rules and create flow entry before traffic reaches Login portal. SDN WLAN has a shorter delay t2 than that of the thin AP WLAN. Since the packet is not routed through the controller again, it will be faster. At 95% confidence interval SDN WLAN experiences 255.39 ± 24.18 ms t1 delay and 29.59 ± 4.24 ms t2 delay. On the other hand, thin AP WLAN has 30.92 ± 0.81 ms t1 delay and 493.41 ± 8.31 ms t2 delay. For the net delay t1 + t2, our experimental results show that the SDN WLAN is 239 ms, which is faster than that of the thin AP WLAN.

(a) The upload / download times

10

(b) The delaysFigure 5 Performance Comparison of SDN and thin AP WLANs.

4.3 Flexibility of the New SDN WLAN ArchitectureThe proposed SDN WLAN architecture actually mimics a thin-AP architecture yet entails more

flexibility on network management. We demonstrate the flexibility of the new SDN WLAN architecture with respect to bandwidth control by conducting field trials on campus near an eatery. As shown in Figure 6, users are in an area furnished with tables and chairs, where an OpenFlow-enabled AP is deployed nearby and connected to an SDN switch in the information technology and service center (ITSC). The center also has a number of APs deployed. A new user is first redirected to the portal for authentication before being authorized to access the network. The wireless bandwidth control application, described in subsection 3.5, is used in the field trials to show the flexibility of the new architecture with respect to bandwidth control.

11

Figure 6 SDN WLAN Deployments in the Field Experiment

In the first experiment, we arrange three users each of which connects to the OpenFlow-enabled AP in Figure 6. We create three queues for the three users, respectively. Two queue configurations are shown in Table 3. The two queue configurations are enforced in different time slots where Queue Configuration 1 begins at the 70th second until the 174th second; Configuration 2 is then enforced by the controller during the time from the 174th second to 279th second. During the experiment, there is no direct background traffic in the SDN network. However, APs deployed in the ITSC and those nearby interfere the communication between the users and the AP. The experimental result is shown in Figure 7. Initially, i.e., from the 0 th

second to the 70th second, the throughput of user 1 and user 3 is slightly better than that of user 2 due to their own network interface card behaviors. During the time from the 70th second to the 174th second, by applying Queue Configuration 1, the throughput of user 3 is limited to under the maximum bit rate, 2500 Kbps, and consequently both the throughputs of user 1 and user 2 increase to around 4500 Kbps. When Queue Configuration 2 is applied from the 174th second to 279th second, which means the guaranteed bit rate of user 3 is increased to 3500 Kbps, both the throughputs of user 1 and user 2 still retain a similar trend. The summary of the throughputs also approximately corresponds to the summary of maximum bit rates in each queue configuration. The above experimental results show that the OpenFlow-enabled AP can dynamically control the throughputs of users. Although the dynamics of air channel conditions and network interface card behaviors could cause throughput change, the control enforced by the OpenFlow-enabled AP affects the performance from a long-term perspective.

12

Table 3 Queue Configuration in the First Experiment

01234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451461471481491501511521531541551561571581591601611621631641651661671681691701711721731741751761771781791801811821831841851861871881891901911921931941951961971981992002012022032042052062072082092102112122132142152162172182192202212222232242252262272282292302312322332342352362372382392402412422432442452462472482492502512522532542552562572582592602612622632642652662672682692702712722732742752762772782792802812822832842852862872882892902912922932942952962972982993002000

4000

6000

8000

10000

12000

14000

UE1UE2

Time (Second)

Thro

ughp

ut (K

bps)

Figure 7 Bandwidth Control with Two Different Queue Configurations enforced in Different Time Slots

In the second experiment, we conduct a file transfer experiment with the queue configuration as shown in Table 4. The file size is 10 megabyte. Figure 8 shows that the file transfer speeds experienced by the three users are different. User 4 experiences a faster transmission rate, while User 6 observes a slow file transfer process. Although the users connect to the same AP, they perceive different throughput. This implies our SDN WLAN architecture is able to manage bandwidth with a sophisticated granularity, i.e., per user or even per session.

13

Table 4 Queue Configuration in the Second Experiment

Figure 8 File Transfer Experiment with Different Queue Configurations

The field trial results imply that an SDN wireless bandwidth control application can provide a flexible way to manage bandwidth dynamically and interactively in the SDN WLAN architecture.

4.4 Cost Estimation of the New SDN WLAN ArchitectureTotal cost of ownership (TCO) is frequently applied to quantify the bottom-line costs associated with

any equipment acquisition over the life cycle of installation and usage [28]. We can formulate a basic model for the TCO as follows:

TCO = CAPEX + OPEX,

where capital expenditure (CAPEX) is the cost of required equipment, and operational expenditure (OPEX) is the cost of equipment installation and cost of equipment maintenance.

14

Here, CAPEX includes the cost of APs, POE adapters, hybrid-mode switches, mobility controller, and AP management license. OPEX includes the cost of hardware installation and maintenance. We compare the potential cost efficiency of the proposed SDN WLAN with that of the thin AP networks based on a scale of 100 APs, 3 set of hybrid-mode switches, and 1 set of mobility controller, as shown in Figure 9. According to the cost analysis based on the Manufacturer's Suggested Retail Price (MSRP) during 2014 Q4. The estimated TCO of SDN WLAN is $78,830 US dollars including CAPEX for $25,480 US dollars and OPEX for $53,350 US dollars, while thin AP network’s TCO is $99,830 US dollars including CAPEX for $66,980 US dollars and OPEX for $32,850 US dollars. The proposed SDN WLAN reduces 21% TCO at the scale of 100 APs during four-year service period.

Figure 9 Estimated TCO of SDN WLAN and Thin AP networks

5. CONCLUSIONSThis paper describes an OpenFlow-based SDN WLAN architecture with fat APs. Network

administrators could exploit the flexibility of a programmable open platform in which multiple OpenFlow-based SDN switches can be managed by a single OpenFlow-based SDN controller. A service provider can develop customized application modules for required features. Experimental results confirm that the SDN WLAN architecture can be an alternative to network service design as compared with traditional WLAN architectures in terms of flexibility. The wireless bandwidth control application is an OAM application example that shows the flexibility on bandwidth management. We are still developing additional OAM features to meet the network management requirements by network administrators for more complicated applications. As compared with the architecture of campus SDN WLAN proposed by Stanford University in 2008, this study adopts off-the-shelf devices and proposes an easy-to-deploy and flexible solution with QoS, while their approach needed to design some required components from scratch. As compared with

15

other SDN WLAN solutions, this study utilizes an OpenFlow protocol and tools from open sources. We also implement and evaluate our proposed SDN WLAN solution on campus. In this work, we identify several important issues for deploying SDN enabled WLAN. We leave the SDN WLAN roaming security as our future work.

ACKNOWLEDGMENTSThe authors would like to thank Prof. Chien-Chao Tseng, Prof. Yung-Chia Chang, Chun-Hung Hsu, Wen-Shuo Chao, and Fang-Yu Lin for their helps and comments on this work. The authors also would like to thank Industrial Technology Research Institute for their support to this work.

REFERENCES[1] G. Rajagopalan, “802.11n client throughput performance,” Aruba Networks, 2008. [2] A. Dalvi, P. Swamy, and B. B. Meshram, “Centralized Management Approach for WLAN,” Computer

Networks and Information Technologies (pp. 578-580). Springer Berlin Heidelberg, 2011.[3] HP next, http://www8.hp.com/hpnext/posts/hp-announcement-march-2015#.VStxe28fq_I[4] HP SDN case study,

http://www8.hp.com/h20195/V2/GetPDF.aspx%2F4AA4-7496ENW.pdf [5] Meru Networks, http://www.fortinet.com/meru/ [6] SDN for WiFi,

http://www.merunetworks.com/collateral/white-papers/sdn-for-wifi-wp.pdf[7] T. Dierks, “The Transport Layer Security (TLS) Protocol Version 1.2,” 2008.[8] OpenWrt, http://wiki.openwrt.org/toh/tp-link/tl-wr1043nd[9] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J.

Turner, “OpenFlow: Enabling Innovation in Campus Networks,” ACM SIGCOMM Computer Communication Review, 38(2), 69-74.

[10] Software-Defined Networking (SDN) Definition, https://www.opennetworking.org/sdn-resources/sdn-definition

[11] Open Networking Foundation Overview, https://www.opennetworking.org/about/onf-overview[12] OpenFlow™-Enabled Mobile and Wireless Networks,

https://www.opennetworking.org/images/stories/downloads/sdn-resources/solution-briefs/sb-wireless-mobile.pdf

[13] SDN architecture, https://www.opennetworking.org/en/sdn-resources/sdn-definition[14] POX, http://www.noxrepo.org/pox/about-pox/ [15] Ryu SDN Framework Community, http://osrg.github.io/ryu/[16] FloodLight, http://www.projectfloodlight.org/floodlight/[17] OpenDaylight, http://www.opendaylight.org/ [18] L. Suresh, J. Schulz-Zander, R. Merz, A. Feldmann, and T. Vazao, “Towards programmable enterprise

WLANs with Odin,” ACM SIGCOMM Workshop on Hot Topics in Software Defined Networks (HotSDN), 2012, pp. 49–54.

[19] S. Monin, A. Shalimov, R. Smeliansky "Chandelle: Smooth and Fast WiFi Roaming with SDN/OpenFlow", Proceedings of the 2014 Open Networking Summit Research Track, USENIX, March 3-5, 2014 Santa Clara, USA

[20] IETF CAPWAP Architecture,http://tools.ietf.org/html/draft-ietf-capwap-arch

16

[21] H.-Y. Lee, Y.- M. Kwon, J.-W. Shin, W.-J. Lee, and M.-Y. Chung, "High Availability WLANs Based on Software-Defined Networking," AICT 2016: The Twelfth Advanced International Conference on Telecommunications.

[22] ON.LAB White paper, Introducing ONOS - a SDN network operating system for Service Providers, 2014.

[23] Lalith Suresh Puthalath, "Programming the Enterprise WLAN: An SDN Approach," 2012. [24] T. Lei, Z. Lu, X. Wen, X. Zhao and L. Wang, "SWAN: An SDN based campus WLAN framework,"

2014 4th International Conference on Wireless Communications, Vehicular Technology, Information Theory and Aerospace & Electronic Systems (VITAE), Aalborg, 2014, pp. 1-5.

[25] K.-L. Huang, C.-L. Liu, C.-H. Gan, M.-L. Wang, and C.-T. Huang, SDN-based Wireless Bandwidth Slicing. 2014 International Conference on Software Intelligence Technologies and Applications, 1-5.

[26] 2013 User Behavior Survey of Wireless Network, http://www.twnic.net.tw/download/200307/20140109c.pdf

[27] Wireshark, https:// www.wireshark.org/faq.html#q1.1[28] Farpoint Group, WLAN Total Cost of Ownership: Comparing Centralized and Distributed

Architectures, Farpoint Group White Paper, Jan. 2004.

17

Table 1. Flow Entries with Enqueue Actions

Table 2. Queue Configuration

Table 3. Queue Configuration in the First Experiment

Table 4. Queue Configuration in the Second Experiment

18