'handover Management And Data Routing In Mobile Networks Using Sdn

Transcript

VICTORIA UNIVERSITY OF WELLINGTON ¯ Te Whare W¯ananga o te Upoko o te Ika a M¯aui School of Engineering and Computer Science ¯ ¯ Te Kura M¯atai Pukaha, Purorohiko PO Box 600 Wellington New Zealand Tel: +64 4 463 5341 Fax: +64 4 463 5045 Internet: [email protected] Handover Management and Data Routing in Mobile Networks using SDN Alexander Deng Supervisors: Prof. Winston Seah and Dr. Bryan Ng Submitted in partial fulfilment of the requirements for Bachelor of Engineering. Abstract We live in a world where we are becoming ever more connected through ’smart’ devices. Cisco predicts 69 percent of the world’s population to be mobile users by 2019 and a tenfold increase of mobile traffic between 2014 and 2019. This means that the number and density of points of access for mobile devices (access point for IEEE 802.11/WiFi and base stations for cellular) will increase significantly to meet mobile traffic demands. Densification of points of access increases likelihood of switching between them and a handover is required to ensure service continuity when moving between points of access. Existing approaches to handover are complex and require major changes on every piece of hardware to facilitate seamless handover. These approaches suffer from at least one of two drawbacks: a large delay when moving between two points of access or a high packet loss rate leading to Quality of Service and Quality of Experience problems to the users. With the advent of software defined networking (SDN), a new handover management solution produced shows how the programmability and centralized attributes of SDN can improve handover performance. Using this system, there was a noticeable performance increase in objective and subjective tests. Acknowledgments Special mention to my friends Callum Dickinson and Emmanuel Godinez for helping, supporting me and listening to my problems throughout the year. Even though it may not have made any sense to you guys, having you guys there to listen to my nonsense really helped. I would also like to thank Gloria Qu for taking the time to share her experience and knowledge in this field to guide me through this process. Most importantly, I would like to thank my supervisors Prof. Winston Seah and Dr. Bryan Ng for their support over this long and stressful year. Your advice and encouragement motivated me to stay strong and on top of the work throughout the year. The knowledge and experience gained will be invaluable for my future endeavors. i ii Contents 1 Introduction 1.1 The Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Report Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 3 3 2 Background 2.1 Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Delay in Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Handover Decision Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Software Defined Network (SDN) . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 OpenFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Ethane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 SDN for Wireless Networks . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 A software-defined networking approach for handover management with real-time video in WLANs . . . . . . . . . . . . . . . . . . . . . . 2.4.3 Handover Management in SDN-based Mobile Networks . . . . . . . . 2.4.4 Supporting One Big AP illusion in Enterprise WLAN: an SDN-based Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5 7 7 7 8 8 9 9 3 4 Design 3.1 Requirements . . . . . . . . 3.2 Design Considerations . . . 3.3 Architecture . . . . . . . . . 3.3.1 Physical Setup . . . . 3.3.2 Logical Architecture 3.4 Algorithm Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementation 4.1 OpenWrt and OpenFlow . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 OpenFlow Packages . . . . . . . . . . . . . . . . . . . . . 4.1.3 Monitor Mode Kernel Panic . . . . . . . . . . . . . . . . . 4.2 Disconnecting Clients . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Python Implementation . . . . . . . . . . . . . . . . . . . 4.2.2 C Implementation . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Tying into OpenFlow . . . . . . . . . . . . . . . . . . . . . 4.3 Sending IEEE 802.11 Management Information to the Controller 4.3.1 OpenFlow Switch Implementation . . . . . . . . . . . . . 4.3.2 RYU Controller Implementation . . . . . . . . . . . . . . iii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11 11 . . . . . . 13 13 14 15 15 16 18 . . . . . . . . . . . 25 25 25 25 26 27 27 28 28 30 30 31 4.4 5 6 4.3.3 Storing Information on the Controller . . . . . . . . . . . . . . . . . . . Modular Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evaluation 5.1 Experiments to Determine Algorithm Thresholds 5.1.1 Experiment Environment . . . . . . . . . . 5.1.2 Experiment Equipment and Setup . . . . . 5.1.3 How RSSI Changes with Distance . . . . . 5.1.4 Throughput Changes with Distance . . . . 5.1.5 Handover Experiments . . . . . . . . . . . 5.1.6 RSSI Handover Thresholds . . . . . . . . . 5.2 Evaluation Tests . . . . . . . . . . . . . . . . . . . . 5.2.1 Evaluation Metrics . . . . . . . . . . . . . . 5.2.2 Evaluation Methods . . . . . . . . . . . . . 5.2.3 Test Environment . . . . . . . . . . . . . . . 5.2.4 Measurement . . . . . . . . . . . . . . . . . 5.2.5 Dataset Processing . . . . . . . . . . . . . . 5.2.6 Objective Evaluation Results . . . . . . . . 5.2.7 Subjective Evaluation Results . . . . . . . . 32 33 . . . . . . . . . . . . . . . 35 35 35 37 37 38 39 39 40 40 40 40 41 43 43 44 Conclusions 6.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 47 A Appendices A.1 OpenWrt Compilation . . . . . . . . . . . . . A.1.1 TP-Link Archer C7 . . . . . . . . . . . A.1.2 Linksys WRT1900AC . . . . . . . . . . A.2 OpenWrt Configuration . . . . . . . . . . . . A.2.1 Port Trunking . . . . . . . . . . . . . . A.2.2 Network Configuration . . . . . . . . A.2.3 Wireless Configuration . . . . . . . . . A.2.4 OpenFlow Configuration . . . . . . . A.3 Running OpenFlow . . . . . . . . . . . . . . . A.3.1 OpenFlow Functions . . . . . . . . . . A.3.2 Starting OpenFlow . . . . . . . . . . . A.4 Experiment Code . . . . . . . . . . . . . . . . A.4.1 RSSI Client Logger Code . . . . . . . . A.4.2 RSSI Network Code . . . . . . . . . . A.4.3 Throughput vs Distance Code . . . . A.4.4 Changeover Experiment Logger Code iv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 53 53 54 54 54 54 60 61 61 61 61 61 61 67 67 67 Figures 1.1 Total Handover Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1 Handover Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 Physical Hardware Design . . . . . . . . . . Logical Design . . . . . . . . . . . . . . . . . In memory data store of client information Algorithm Design Sequence Diagram . . . Database Update Flow . . . . . . . . . . . . Decision Algorithm Flow . . . . . . . . . . Client State Machine . . . . . . . . . . . . . Controller State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 17 18 20 21 21 22 23 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 Indoor office scenario in Level 2 of Cotton . . . . . . . . . . Indoor open space scenario with many people in the Hub . Indoor line of sight scenario in the Laby to Cotton corridor Outdoor scenario in Lower Hutt . . . . . . . . . . . . . . . RSSI vs. Distance . . . . . . . . . . . . . . . . . . . . . . . . Throughput vs. Distance . . . . . . . . . . . . . . . . . . . . Hardware Test Setup . . . . . . . . . . . . . . . . . . . . . . Evaluation Environment and Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 36 36 36 38 39 41 42 A.1 Logical Network Port Configuration . . . . . . . . . . . . . . . . . . . . . . . . 70 v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi Chapter 1 Introduction A handover is needed when a mobile device moves out of range of one access point (AP) and into the range of another. These handovers can occur over from a mobile base station to another base station (cellular to cellular), from a mobile base station to WiFi, or from WiFi to WiFi. Cisco predicts that over 69% of the world’s population to be mobile users by 2019 and a predicted tenfold increase in mobile traffic [1]. To cope with this increase in users and traffic, the points of access (base stations and APs) will have to increase too. A handover is also required to ensure the connections that a user has established do not break (such as a YouTube video or a Skype call) when moving out of range of one point of access, and into another. Current handover schemes generally have one of two limitations (or both): they are slow, causing a noticeable delay to the user, or they have a large packet loss rate. Definitions of a handover can vary, but the origin of the term was from the work of Richard H. Frenkiel and Philip Thomas Porter in the late 1960’s. In 1970, Edward Joel Amos Jr, a Bell Labs engineer patented the idea of a handover to allow for ”continuity of communication paths to mobile stations passing from the coverage of one radio transmitter into the coverage of another radio transmitter” [2]. Studies into handover management schemes for Internet Protocol (IP) date back to the early days of Mobile IP (mobility support for IPv4). Mobility itself was not built into IP, rather it was an extension to IP. Handovers are not part of Mobile IP nor the IEEE 802.11 WiFi standard. 1.1 The Problem The handover problem addressed in this project is framed in the context of a campus based WiFi network which is based on the IEEE 802.11 standard. The IEEE 802.11 standard allows for mobile devices to switch access points (APs) which mobile devices are associated to, but does not maintain any connections and flows that might be currently active on a device. Handovers that maintain connections and flows were not part of the original IEEE 802.11 standard for WiFi. This leads to poor Quality of Service (QoS) and Quality of Experience (QoE) in the form of delay, packet loss and user dissatisfaction [3–5]. Besides maintaining connectivity during a handover, meeting delay constraints is another important problem in WiFi handovers. Delay constraints arise because the network carries real-time services such as voice calls, video streaming and remote monitoring. The handover delay in an IEEE 802.11 WiFi network is defined as the time taken for the Probe, Re-association and Authentication processes [6] and this delay is shown in Figure 1.1. To remedy the two problems stated above, research into supporting handovers to support seamless mobility with WiFi can be divided into three main approaches namely: (i) 1 Figure 1.1: The Probe, Re-association and Authentication processes that make up the total delay in an IEEE 802.11 handover. This diagram shows the potential delays that can be targeted to improve handover times. Reproduced from [6]. client-side, (ii) network-side and (iii) client & network side. The majority of proposed handover solutions in the literature is focused on client-side solutions [3, 5, 7, 8]. This means the handover decision is the responsibility of the client devices. There are also many proposals in the literature which require changes to both the clientside and network-side devices. These approaches require the client to coordinate closely with the network to determine when a handover should occur. Often the network will request information from the clients for the handover process. Among the three approaches, joint network and client approach perform the best, with the lowest loss rates and delays but they are the most difficult to roll out. This is due to the sheer number of devices out there as they will all have to be modified to support the handover schemes. Network-side schemes are easiest to implement and roll out because modifications are introduced to the network devices only. This is convenient as it makes administration easy for the initial roll out and future updates as well as for client device compatibility due to a fewer number of network devices that have to be modified. Any solution that requires implementation changes to the client devices will be difficult to roll out as every client device will need to be modified. 2 1.2 Proposed Solution Network-side handovers are advantageous as they often have an entity with a global view of the network that aggregates information from the AP’s involved in a handover before the process occurs [9, 10]. Due to this, a software defined network (SDN) based solution, implemented on the network side is proposed. SDN separates the control and data planes that are traditionally within a router and endows the a logically centralized controller with a global view of the network [11]. The controller is the main entity that determines packet movement in a network and it maintains up-to-date information on the network. Given this, the controller can retrieve information about the mobile devices that are associated with the APs in the domain that it controls (i.e. The Victoria University network will have one logical controller). Traditional networks with a propriety solutions do not provide abstractions and open interfaces for managing, monitoring and programming the network to facilitate the handover process. In contrast, SDN provides open and simple abstractions that enable handover functions to be added easily. From researching solutions and products that already exist and potential technologies that might be adaptable to solving the problem outlined in subsection 1.1, the following specifications were formed for this ENGR489 project: • The handover solution must be implemented on the network-side. The clients will need to be oblivious to the handover implementation. • The solution produced needs to work on consumer grade networking equipment. • An SDN-based solution is to be produced. Existing network-side solutions utilized Mobile IP to enable roaming and bicasting/multicasting to anticipate a handover [4, 5, 7]. This means the packet stream is sent to two or more APs that the network is anticipating a client to move to. This relied on hardware that supported multicasting and a mobility agent to handle sending the packets to several destinations where the clients could have roamed to. An SDN-based solution addresses these shortcomings by removing the need for Mobile IP. SDN allows flow rules to be dynamically installed and removed as a user’s mobility increases or decreases. This has the same effect as bicasting/multicasting in the event of a handover. Such a solution builds the foundation for future extensions to a better handover management system. An SDN-based solution has the potential to have significant impact on the way handover management is performed because programmability attribute of SDN allows features to be implemented in ways never seen previously with propriety hardware. The International Telecommunication Union (ITU) have defined a set of methods to evaluate the performance of an audio/video stream [12–15]. Such methods can be used evaluate the performance of handover management schemes using the metrics defined. Existing work in the literature have used mean opinion scores (with real test subjects’ opinions), packet loss and video playback delay tests to evaluate the performance [4, 8, 16, 17]. The SDN-based handover solution for this project was evaluated using the same methods. The methods set by the ITU were too stringent for ENGR489, so simplified versions of these tests were used to evaluate the performance of the handover solution produced. 1.3 Report Structure The remainder of the report will be structured as follows. The background information on handovers as well as some related work proposed by researchers is described in Chapter 2 3 followed by Chapter 3 which details the design of a SDN based handover. Chapter 4 outlines the implementation of the components that make up the SDN based handover scheme. Chapter 5 describes the experiments that were done to determine the thresholds for when to initiate a handover. Chapter 5 also evaluates the scheme against various applications and compares the result to a system with a standard IEEE 802.11 implementation. Chapter 6 concludes the work and gives insights on future work. The appendices give various details on setup and issues faced with implementation and hardware. 4 Chapter 2 Background This Chapter provides background on handovers and SDN. It also provides recent work in the literature into combining an SDN-architecture into improving handover performance. Research into handover management schemes has been a hot topic for many years since the early days of Mobile IPv4. Most of the schemes were ad hoc with no standardization until the IEEE created the 802.21 media-independent handover services (MIH) to support vertical and horizontal handovers [18]. Despite this standard being created, the number of manufacturers that have implemented this are few to none due to the work involved with implementation and roll out as it is a network and client based solution. 2.1 Handover The definition of a handover (or handoff) varies between sources [2, 5, 19]. Most definitions seem to agree that a handover is when a client device or mobile device (called a mobile terminal (MT) in cellular networks and a mobile node (MN) in IEEE 802.11 WiFi networks) changes its point of access (PoA). The IEEE definition of a handover is ”the process by which a mobile node obtains facilities and preserves traffic flows upon occurrence of a link switch event” [19]. Though not directly named a handover, some of the earliest work on handover management was patented by Amos Jr [2] of Bell Corp. in 1970 during the infancy stages of cellular communications. The patent description was to ”establish and maintain continuity of communication paths to mobile stations passing from the coverage of one radio transmitter into the coverage of another radio transmitter”. Today, there are two types of handovers: horizontal and vertical[5]. A horizontal handover occurs when mobile device switches its PoA to another of the same infrastructure type. This means a mobile device connected to a base station (BS) will switch to another BS or a device connected to an access point (AP) switching to another AP (cellular to cellular or WiFi to WiFi). A vertical handover happens when a mobile device switches its PoA from one type of infrastructure to another. This means a device switching from a BS to an AP or vice versa. To allow for such a handover, a mobile device with support for both cellular technologies (such as 3G or 4G which could be LTE or WiMAX) and IEEE 802.11 WiFi is needed. These two types of handovers can be further classified into either a hard handover or a soft handover. A soft handover also known as a ”make-before-break” handover, is when a mobile device connects to a new PoA before it disconnects from its current one. These types of handovers were part of UMTS (3G) mobile networks but were removed from LTE (4G) networks. A hard handover is where a mobile device breaks its current connection with its current PoA before it connects to its new target PoA. In WiFi, it is often not practical to be 5 associated (connected) to more than one AP due to power consumption considerations in modern mobile devices have multiple WiFi interfaces (multiple associations to multiple APs are possible). Each interface allows for one association at a time which means a soft handover is not possible in WiFi unless extra wireless interface cards are used (which increases power consumption) or complex schemes like MultiNet are used [20]. Figure 2.1: Handover Types Most handover management schemes attempt to address the issue of calls or connections being dropped when a mobile device switches its point of access. Cellular technologies like 3G and 4G have handover management schemes that explicitly allows a call to not be dropped when a mobile terminal (MT) (which is the mobile device) switches BSs as they use an out-of-band control signalling such as Signalling System Number 7 (SS7). The IEEE 802.11 WiFi standard does not have a scheme in place to prevent reconnections when a MN changes APs [21]. Any signalling (often by proprietary solutions) is performed in-band. For stored streaming based multimedia applications like YouTube and Spotify, application layer techniques such as buffering are used so playback is not affected even during a handover when throughput is stalled. Real-time multimedia applications like VoIP (Skype calls) and live streaming will be affected more by a handover. As these applications are real-time, application techniques to pre-buffer buffer packets are not available so when throughput is stalled during a handover, there will be a pause in the stream when the mobile device switches APs. A handover can occur on multiple layers of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol stack. Despite this, the actual handover where a mobile device switches its point of access or association to another is performed at the Medium Access Control (MAC) or Link layer (layer 2 of the TCP/IP stack). This is often referred to as a layer 2 handover. A layer 3 handover is a handover on the network layer for a MN to change its IP address and generally inform its home agent of its new care-of-address (CoA) to established connections in currently running applications can continue without having to be reestablished. This capability is provided by Mobile IP (mobility support for IPv4). 6 2.1.1 Delay in Handovers Mishra et al. [6] analyzed the process of the IEEE 802.11 MAC Layer handover. They concluded that scanning all WiFi channels and actively probing to find a new candidate AP to connect to makes up more than 90% of the delay in a handover. IEEE 802.11 WiFi handovers are conventionally client initiated and keeping established connections such as TCP flows after the handover is not part of the standard [21]. The authors found that the total delay (combination of the Probe, Re-association and Authentication delays) was between 58ms and 397ms in their experiments depending on the hardware used [6]. 2.2 Handover Decision Triggers A handover is often triggered by one of several criteria. A decision algorithm determines whether a handover should occur or not. These algorithms decide based on one or a combination of the following [8, 22–24]: • Received Signal Strength (RSS) - Most handover algorithms use RSS as the criterion for the decision algorithm to determine when a handover should occur. Measured in dB or dBm, RSS enables mobile device to determine the signal of its PoA. RSS is easy to compute and allows for easy comparison with multiple PoA’s. RSS often fluctuates due to different types of interference (shadowing, absorption, etc.) so different techniques need to be used to ensure accuracy. • Network Latency/Bandwidth - These algorithms trigger a handover when certain network related requirements are not met. This could be when throughput (measures in Bytes per second) decreases below a certain point or similarly when the delay increases above a certain point (measured in ms). When delay increases and bandwidth decreases to a certain point that affects user experience, a handover can be triggered to prevent the performance from degrading to a point where it is noticeable to the user. Many smartphones running a newer version of Android has a feature called Smart Network Switch that determines when a device should switch traffic from a WiFi connection over to a mobile (3G/4G) one based on signal strength and throughput. • Power Consumption - Different access technologies require different amounts of power from a mobile device. When a mobile device is running low on power, and is currently connected to an access technology that has high power consumption, a handover algorithm may switch the phone from an access technology to one with lower power consumption. • Monetary Cost - Some handover schemes take monetary cost into account when deciding when a handover should occur. An example of this would be preference of using WiFi over cellular technologies which usually have a lower monetary cost. • User Preference - Such algorithms are usually associated with historical networks that the user has selected. A user may prefer one out of several networks that they have access to at the same time. 2.3 Software Defined Network (SDN) SDN is a recent networking concept that separates the control and data functions of network appliances which enables a network to be logically centralized and have a programmatic 7 approach to building, operating and managing a network [11]. In old mainframe systems, the API was closed requiring specialized hardware, operating system and applications to be purchased from the same manufacturer. The move to personal computers (PC) opened up the hardware to multiple operating systems (OSs) not specific to the hardware manufacturer and applications that run on top of the OS. The same transition is starting to take place in networking devices. SDN improves programmability by opening up interface to hardware in these devices so they are able to run network OSs other than what is created by device manufacturers. Traditional IP networks are complex in that the device vendors hide implementation details from network operators. Implementation of useful features not defined by a request for comments (RFC) document often differ between vendors leading to interoperability and incompatibility problems. These useful features are often paired together with features not used by many operators resulting in devices that are bloated and full of unnecessary software. Together, these drawbacks lead to traditional networks being difficult to manage without being locked into a single hardware vendor. One idea behind SDN is to address this issue by allowing vendor neutral hardware to be used and only implement the features that are needed. By removing the device vendor from the software, features can be implemented based on the network operator’s requirements. 2.3.1 OpenFlow Often confused for being SDN itself, OpenFlow is the most popular application layer protocol that allows a network to be operated using characteristics of SDN [25]. The concepts of SDN are realized with both hardware and software in OpenFlow, which was originally designed for researchers to run new experimental protocols on vendor agnostic hardware. Testing on traditional ”name-brand” [25] hardware was almost impossible as the manufacturers did not have an open interface/platform for new protocols to be installed and run for competitive and copyright reasons. For these reasons, the authors decided that they needed a new system that could allow them to meet four requirements [25]: • Able to work with existing high-performance and low-cost implementations. • Capable of supporting a broad range of research. • Able to isolate experimental traffic from production traffic. • Respect a device vendor’s need for closed platforms. From these four requirements, an OpenFlow switch requires any form of forwarding to be defined by a remote controller. The controller installs flow entries into these switches’ flow tables. The flow entries consist of the header match conditions, statistics information and a simple action of drop, forward to a specific port, or encapsulate and send to the controller. 2.3.2 Ethane Ethane was the immediate predecessor OpenFlow that defined a new network architecture for enterprise networks [26]. It used to idea of separating the control and data planes of a routing device to make management and security enforcement easy with a single policy that is applied on every switch of a network. The control planes in each of the network devices was moved into a single centralized controller. The centralized controller was in used to control policy and routing based on packets that it received from the ’Ethane switches’. The 8 ’Ethane switches’ were also called dumb switches as they could not perform any forwarding until they were instructed to by the controller. Upon receipt of a control message, they would perform the actions specified by a controller. Unlike OpenFlow, Ethane was targeted towards a particular use case. Rather than focus directly on the programmability aspect of SDN, Ethane was built for the control of an enterprise network. Even though OpenFlow was initially created for researchers, it has evolved into a protocol that is used in large data centres [27]. While this is not an entirely new idea, Ethane used the idea of having a centralized control plane for all of the network devices which has since evolved into OpenFlow [11]. Unlike solutions of the past, the forwarding devices or Ethane switches did not require major changes to allow them to be operated using a controller. One of the ideas behind Ethane to have a centralized controller determine the actions upon the receipt of the first packet in a flow has evolved into what OpenFlow is today. 2.4 Related Work The following literature were reviewed in depth as they were the closest to this project. The papers were obtained from links on Google Scholar, IEEEXplore and ACM Digital Library using the keywords ”SDN Handover”. A filter was applied to order the results by the date of publication from newest to oldest. Search results between 2010-2015 were studied more thoroughly to identify recent trends in handover management. Papers that required changes to client-side implementation were discarded. The paper “OpenSDWN: Programmatic Control over Home and Enterprise WiFi” [28], published late into this project was the closest in terms of architecture and design. 2.4.1 SDN for Wireless Networks The majority of work on SDN has been focused on the wired networks that make up the backbone of production networks [11]. There has been research into the use of SDN in wireless networks but the focus has been on heterogeneous networks which are networks controller by operators with a combination of WiFi APs and BSs. The use of SDN allows a tiered controller approach to support vertical handovers between the different access technologies. The existing work into WiFi specific SDNs has followed the same approaches that have been applied to heterogeneous networks that use WiFi APs and cellular base stations. The authors of [29] and [28] proposed OpenSDWN which used a two-tied controller design. The radio agents within an AP report to a radio driver controller that is contained within the centralized SDN controller. The radio agents are in charge of getting all of the link layer information to the radio driver. The hardware that the authors used were all-in-one (AP + router + switch) devices running OpenWrt. The novel aspect of this project is that it combines SDN, NFV and WiFi all into a single solution. The solution was implemented on the network-side only. Major changes were made to the all-in-one devices as well as a controller application that worked in tandem to send the appropriate commands. To support mobility between the APs in the SDN, the WiFi interface regularly sends link-layer information as it is received to the controller. The controller monitors when the received signal strength indicator (RSSI) drops below -70 dBm which it then acts on by determining whether a handover is required. When a handover is required, a clients Light Virtual Access Point (LVAP) abstraction which is defined as its association state (basic service set identifier (BSSID), service set ID (SSID), client IP address, and OpenFlow flow rules) is transferred to a target AP. The authors claims that migrating a clients LVAP can control the 9 AP that the client is attached to without requiring any re-association. This is true for even a standard IEEE 802.11 implementation provided the APs are operating on the same SSID. Moving a client device between APs regardless of whether the controller has initialized the handover requires a connection to be momentarily broken as the client has to re-authenticate with the target AP [21]. The authors experimented with a promising platform, though it appeared that they tried to focus on too many things in their implementation. Not only did their system focus on mobility, it attempted to integrate an IDS implemented in NFV and connected a enterprise grade and home network into one. 2.4.2 A software-defined networking approach for handover management with real-time video in WLANs Dely et al. proposed a new SDN based approach to handover management for real-time video in IEEE 802.11 [30]. They used OpenFlow and involved modifications to both the client and network ends. The client initiates the handover in their scheme. Two key areas of the IEEE 802.11 handover process have been identified for improvement: one was the authentication and association process, while the other was the scanning process as described in Section 2.1.1. Their solution involved the use of pre-authentication and pre-association prior to the mobile station changing access points (AP). The authors stated that their solution would do this via the use of ”out-of-band signaling”, to preauthenticate and pre-associate with all AP’s of a certain geographic area that are not currently in its current coverage area. To address the scanning process which by far contributes the most delay in the IEEE 802.11 handover process, the authors introduce a dedicated scanning card to determine whether having a separate piece of hardware is able to reduce this delay (as a mobile station cannot simultaneously transmit data and scan with only one WiFi card). As a mobile station with one WiFi card can only be associated with one AP at a time, by pre-authenticating and pre-associating with potential BSs before the handover process, the network can reduce the delay on its end. The authors’ solution uses embedded devices each with two wireless cards as APs which connect to a virtual machine host via Ethernet and a Generic Routing Encapsulation (GRE) tunnel. This virtual machine host contains the OpenFlow switch, the streaming server and the control server. The solution was implemented on a testbed, and shown to perform with impressive results. A handover using a standard Linux distribution resulted in an average freeze time (in video streaming) of 2.75 s and a total number of freeze events of 79. The maximum freeze time observed for standard Linux was 32.06 s. With their solution, the mean freeze time was only 0.46 s with a total of 15 freeze events. The maximum observed freeze time was 2.24 s (which was less than the standard Linux average). The authors found that the use of a dedicated scanning card provided very little benefit to their solution. While the dedicated scanning card decreased the total number of freeze events, it actually increased the average and maximum freeze time compared to not using it. The extra hardware cost and power consumption greatly outweighed the benefits. One noticeable aspect of this solution is that it utilizes MultiNet [20]. MultiNet allows one wireless card (on the host device) to be associated with multiple access points. This is done by introducing another layer between the Link and Network layers to abstract the multiple connections from the Network layer and above. The use of MultiNet allows the host devices or the Mobile Stations (MS) to simultaneously connect to multiple APs. This allows for a soft handover as the MS is able to make a new connection before it breaks an old one, achieving a smoother handover with better performance. However, it needs to be 10 implemented on every host device as well as on the network which is not really practical. 2.4.3 Handover Management in SDN-based Mobile Networks Kuklinski et al. [31] discussed the different handover solutions that are part of current UMTS (3G) and LTE networks. They discuss and compare the handover schemes of UMTS and LTE against each other and introduce an SDN based solution for future 5th Generation (5G) mobile networks. LTE removed the Radio Network Controller (RNC) that was responsible for controlling the BSs in UMTS and thus responsible for coordinating the handover between two BSs. LTE required the BSs that the mobile device was switching from and to respectively to coordinate the handover amongst themselves. For 5G networks, the authors proposed the use of an SDN based solution using OpenFlow with a logically centralized controller that is also responsible for handovers as well as its normal duties determining the operation of the network. With a centralized solution, a handover can be initiated with minimal signaling messages. The authors recognized a potential scalability problem of having only one logically centralized controller so they introduced two other solutions. A semi-centralized solution which involved multiple logical controllers that are each responsible for a portion of a domain (such as in an ISP). Another is a hierarchical-based solution with several controllers for a given domain, but these controllers are controlled by a master controller. Although the authors presented some valid cases for the use of SDN for future 5G mobile networks, their ideas are not without limitations. The semi-centralized solution leaves the task of determining forwarding to the lower-tied controllers rather than have the master controller perform the task. This can lead to consistency issues unless an appropriate signalling protocol. The authors claimed that all this could be realized using OpenFlow without considering the original intended use cases for OpenFlow, namely, wired-backbone networks. The idea of using SDN to provide either a centralized, semi-centralized or hierarchical solution are similar to previous technologies (GSM, UMTS) but removed in LTE. This approach [31] therefore suggests that reintroducing control (by removing responsibility from the BS) is going to improve performance, without doing any actual implementation to support the claim. 2.4.4 Supporting One Big AP illusion in Enterprise WLAN: an SDN-based Solution Zhao et al. [32] proposed ”One Big AP” to improve the poor performance of existing enterprise WLAN (WiFi) implementations. They found that existing solutions were ”clientcontrolled” which lead to poor client-AP associations. Client devices would all connect to an AP with the highest signal strength often leading to load issues. The authors have identified that the handover procedure is very time consuming due to the signaling needed between the client, old AP and the new AP. They state existing solutions to improve handover times still required hundreds of milliseconds. To improve on the handover time further, they proposed a solution that would make every AP in a network appear as one AP with a large coverage area to the client. Their implementation would be purely network based and thus no changes to client devices were needed. OpenFlow was the protocol used on the network to change flows as the result of a handover. This solution involves operating every AP in the network on the same channel with the same SSID to abstract the fact that there are multiple APs from the client. They arrange the APs in a way that there is overlap so that multiple APs can receive the broadcast transmis11 sions from a client device. When a handover is required, the client’s flows are changed to the new AP. The old AP and new APs will be sent MAC ACK messages from the SDN controller to instruct the old AP not to respond to the client’s messages, and the new AP to respond instead. To prevent the MAC layer addressing from breaking (incorrect MAC addresses in the header), they implemented a global table to store the client devices. When a client device first connects to an AP in the network, it is assigned a unique BSSID which is mapped to the client’s MAC address. The BSSID is spoofed onto the AP. Subsequently, when the client is served by a different AP (the network has initiated the handover), the new AP will check this table, and will use this BSSID for its communications with the client. To test their solution, the authors used the throughputs of TCP and UDP as their benchmark. They found that the throughput of both TCP and UDP dropped to close to 0 megabits per second (Mbps) when a traditional IEEE 802.11 WiFi network is used (where the client initiates the handover). With their solution, they found that TCP maintained a constant throughput of about 1.8 Mbps and UDP of about 1.6 Mbps. As little information was provided on how the validation was conducted, the efficacy of their solution remains to be seen. 12 Chapter 3 Design This chapter details the design of the SDN architecture for our proposed handover solution. The design process solves the problem outlined in Section 1.1 taking into account existing techniques and research detailed in the literature that was discussed in Chapter 2. Section 3.3 and 3.4 plan out the solution that is implemented in Chapter 4 which is then tested and evaluated in Chapter 5. 3.1 Requirements On top of the project specifications set in Section 1.2 the following requirements are key to the design of the handover algorithm described in this report. • There will be periodic beacon messages sent from the APs to the clients • There will be periodic probe messages sent from the clients to the APs • Wireless links are on a shared broadcast channel • RSSI information can be obtained from client probe messages. The first requirement of periodic beacon and probe messages is fulfilled by Request For Comment (RFC) 5113 [33]. RFC 5113 confirms that the beacon and probe messages are part of the MAC layer specification of the IEEE 802.11 standard. Beacon messages are considered the passive discovery method for a mobile device to scan for APs that they are within range of. The beacon messages are broadcast from an AP to all reachable mobile devices within range. The purpose of these beacon messages is to announce the presence of an AP and for mobile devices to discover this AP. Within these beacon messages, there is information about the AP that send the beacon frame, which includes its SSID, capacity information, supported rates and more. Probe messages are the active discovery method for a mobile device to scan for APs by broadcasting a Probe request MAC frame to all APs within range. The APs that receive this message respond with a Probe response which indicate that an AP is within range [21]. The APs with a monitor mode interface enabled can calculate RSSI and signal information of these clients from driver code. Wireless links use a shared channel and operate in half-duplex mode [34]. The MAC protocol for IEEE 802.11 utilizes carrier sense multiple access with collision avoidance (CSMA/CA) in which a mobile host will not transmit if it senses there is already a transmission in progress in the shared medium. This means that with the same wireless link, either amobile host is sending, or the AP is sending (ignoring other hosts) via the same channel. 13 3.2 Design Considerations On top of the requirements defined in section 3.1, the following considerations were also taken into account in the design. • Where to store mobile host information? Should this be stored on the APs or the controller? For a global view of the network, this information should be stored on the controller. If this information is stored on the AP, then there is less emphasis on SDN concept with the switches just being forwarding devices. A problem with storing all this data on the controller is that this system could end up not being scalable. This problem can be solved by using a sufficiently powerful controller with ample RAM. Another solution can be to limit the amount of data that is stored about each client as data does go stale over time. • Should the information about client devices be stored in a database in secondary storage or in memory for fast access? Storing this information in secondary storage will ensure that there will sufficient storage for all the information that will be stored about the client devices. Doing this may pose a risk to network performance though due to the comparatively slow read speeds associated with mechanical hard drives used in databases. Storing this information in RAM of the controller is the better solution as the read and write speeds of RAM is a lot faster than a mechanical hard drive. Provided there is sufficient amount of RAM in the controller, storage should not be a problem. • How much information should be stored? How many probe requests should we store? Should averages be taken? Should the handover occur with just one piece of information (one RSSI reading) or should some historical information be stored to make a better decision. • Will the RSSI of the mobile devices reflect real world conditions (i.e. walls, objects, etc.) How will interference be taken into account? RSSI readings fluctuate given the slightest amount of interference. Taking multiple readings can potentially alleviate these fluctuations. • Nomadic Mobility and Speed. In contrast to mobile users which are assumed to be constantly moving, a nomadic user is one that is stationary for long periods of time such as someone sitting in an office using their laptop which is a mobile device. The network needs to realize this and not initiate a handover for these devices. • What should be done in the event of a client not disconnecting from its current AP despite there being a better AP with stronger signal strength in range? Client devices tend to stay associated to an AP as long as they can. These are called sticky clients. These client devices will go further and further away from the AP but not disassociate from their current APs and associate to new APs. The network will have to disconnect these clients before this happens so that user experience and network connectivity are not affected. • Pre-buffering packets. Packets that arrive on the old AP for the mobile device in the process of a handover need to be buffered on the new AP in anticipation of it switching over. • How do we control the rate when a client is handed over to a new access point? Network layer changes will have to be made or is there something in OpenFlow that can help with this? 14 3.3 Architecture The main focus of the project was to create a solution that utilized the advantages that an SDN architecture provides. When a new flow comes into a switch that is not in its flow table, it is forwarded to the controller where they defined and installed on the switches. Once a flow is installed, the switches will be able to forward packets on their own without going back to the controller until the flows expire. OpenFlow is the protocol of choice for its popularity in production SDN networks, its ongoing development and the documentation for existing projects. It is not vendor specific allowing it to be used in generic hardware. The APs in the network would be operating on the same subnet to avoid a layer 3 handover, where the mobile devices would have to change their IP addresses on top of the association change. Having the APs all in the same subnet would mean that only one Dynamic Host Configuration Protocol (DHCP) server is needed. Doing this would also mean that a routing device (a standard router that contains both the control and data plane in one) is not needed for inter-AP communications. The single subnet scenario has been chosen to facilitate the testing and validation in a campus environment. 3.3.1 Physical Setup As the project focuses on WiFi handovers, hardware that allows the AP to also be controlled by the controller was appropriate. Production networks like the one in Victoria University of Wellington (VUW) often have separate devices for APs each containing a wireless controller. These separate APs are often made by companies like Cisco which do not make the application program interface (API) to the hardware openly available so was not suitable for this project. This is due to not being able to control physical layer parameters including transmission power, transmission rates from the controller. For these reasons, devices that have open source drivers for the hardware was chosen. Two all-in-one (switch + router + AP) devices, namely, TP-Link Archer C7 and Linksys WRT1900AC, were used for the project though any device that supports the OpenWrt Linux based firmware will work. The TP-Link Archer C7 was chosen for its compatibility with all the features that OpenWrt offers while being stable . It has 128 MB of RAM which is sufficient for the flow entries but only 16 MB of flash memory which can limit the installation of additional packages. The Linksys WRT1900AC on the other hand does not have these problems. It has 256 MB or 512 MB RAM for flow table entries and 128 MB of flash memory for all the packages that can be used on top of a dual core CPU. The reason both routers were used was because of the reported stability problems with the Linksys. The firmware was still in early stages of development at the start of this project. The controller can be run on any computer that has a physical Ethernet port to allow for the physical connections from the OpenFlow switches. The controller was run on a mid-2015 Apple MacBook Pro Retina which contained a quad core Intel Core i7 4870HQ and 16GB of RAM. The physical connections from the OpenFlow switches to the controller were through Ethernet to Thunderbolt via an adapter. The actual limits of the controller hardware was not tested due to not having the large amount of traffic associated with a production network. The maximum throughput of the network interface card (the Thunderbolt to Ethernet adapter limited throughput to 1 Gbps) is likely to be the limiting factor over the internal hardware. Such a powerful machine used as a controller removes any potential processing bottleneck and any concerns about the amount of RAM available. A diagram of the physical set up of the system can be seen in Figure 3.1. Though the diagram shows only two APs, the number of APs can be increased so long as there is a physical 15 layer 2 connection to the controller. For inter-AP data plane communications for the mobile devices, there needs to be a connection between the APs. This can either be through Ethernet or through a wireless link. Ethernet was chosen so the characteristics associated with a wireless network would not have to be taken into consideration when doing performance evaluations of the solution. Each of the APs chosen have five ports for use. Only one needed to be used for a connection to the controller and the rest could be used for data plane connections. Scalability could become a concern with any system that features only one controller (one logically centralized controller does not mean that there is only one controller). As the number of APs increase, the controller may become the bottleneck in the system though this is outside the scope of this project. Controller Ethernet Ethernet Ethernet OF Switch 1 OF Switch 2 WiFi Client Figure 3.1: Physical Hardware Design 3.3.2 Logical Architecture This subsection describes the software used and how the different components of the system relate and communicate to each other. The local architecture of the solution produced is shown in Figure 3.2. The Ryu SDN Controller is the center of the solution. It was chosen for its simplicity, ample documentation and user base, as well as for its familiarity amongst the SDN researchers and staff of Victoria University’s ECS faculty. The Ryu framework contains many applications for different scenarios. Additional applications can be developed using the Python programming language. It supports up to OpenFlow 1.4 though 1.3 will be used as it is considered the most stable release. As the target for the project is a layer 2 handover, the APs are operating within the same subnet. The DHCP is part of the OpenWrt image that was flashed into the all-in-one APs. To ensure that there are no address reservation conflicts, only one DHCP server is used. 16 To do this, one of two different methods was considered. Either the DHCP server would be a completely separate entity on the network, or only one of the DHCP server instances located on the APs were to be used. The second option was chosen for its easy of use and configuration. The DHCP settings on one AP was left as default. Every additional AP in the network would have its DHCP server process disabled and made to point to an external DHCP server which was the IP address of the first AP. RYU Legend Ethernet Controller WiFi Control Control DHCP OpenFlow OpenFlow OpenWRT OpenWRT Data Switch Switch AP OF Switch 1 AP OF Switch 2 Data Client Figure 3.2: Logical Design The schema for flow and RSSI information about the mobile devices is to be stored on the controller is shown in Figure 3.3. The data is to be stored in RAM on the controller. As this information does not need to be persistent across reboots, storing such data in RAM will not adversely affect the network performance as compared to a mechanical hard drive normally associated with databases. A choice needs to be made regarding what kind of in-memory data store is to be used. An in-memory database can be used to take advantage of a well defined data definition language (DDL) associated with database management system like PostgreSQL. An analysis of whether the extra processor usage associated with such a system needed to be weighed up to see whether any advantages provided by a DDL outweighs the costs. The alternative is to use a map implementation. A key linking to an in-memory object can be quickly hashed with minimum processing power to insert and obtain an object (which is information about a mobile device in this system). A disadvantage of this is the potential for hash collisions where a mobile device can be hashed to the same object messing up each others information stored on the controller and in turn preventing a handover from occurring at the correct time to the correct AP. 17 CLIENT_MAC_TO_AP_ASSOCIATION AP_ASSOCIATED_LIST (PK) client_mac_address (FK) associated_ap_bssid (PK)(FK) ap_bssid list CLIENT_MAC_TO_PROBE AP_BSSID_TO_PROBE (PK) client_mac_address (FK) ap_bssid (PK) ap_bssid list Figure 3.3: In-memory database schema used to store association and RSSI information. 3.4 Algorithm Design The proposed handover algorithm comprises several key components. Figure 3.4 (page 20) shows the sequence of communications between the involved entities of a handover. Most of the messages that occur are part of the IEEE 802.11 standard and since the client side implementation is not going to be changed, these messages will occur regardless. Mishra et al. [6] found that the handover process in a standard IEEE 802.11 network is made up of three parts: discovery, re-authentication and re-association phases. The discovery phase is made up a series of probe request frames on each channel, sent from the client devices to all reachable APs. The APs will then respond to these with a probe response frame. The interval at which these probe request frames differs from implementation but the timestamps of the frames have a different of about 5 seconds when captured using tcpdump1 . The client will then decide to associate to the AP with the highest signal strength. It will send a re-authentication frame to the new AP (and additionally a re-association frame if it is moving to an AP of a different SSID). Once a response is received, the client device is associated and can communicate via the AP. Optionally, de-authenticate and disassociate request frames (which cannot be denied) can be sent to the previous AP. These frames are not often used in practice though as the old AP will remove the mobile devices from their associated list after a period during which it senses that there is no longer any packets from the device. The key part of the solution to be produced for the project lies in the global view of the controller. The probe request frames sent to the APs are forwarded to the controller (as in Figure 3.4 but has been sent as an OFPT SEND PROBE OpenFlow message). The controller will store RSSI from the probe request frames sent from the client devices to the APs as shown in Figure 3.5 on Page 21. The controller will then obtain this information from an in-memory database and determine whether a handover is necessary. If the RSSI values of a mobile device are approaching a set of thresholds, the controller will install that device’s flows that were installed on its original AP onto its new target AP. This happens preemptively before the handover in case that device switches AP on its own without the controller disconnecting it. If a handover is required (beyond aforementioned thresholds), the controller performs an extra action in anticipation of the client device re-authenticating 1 tcpdump is a common packet analyzer that runs under the command line and allows the user to display TCP/IP and other packets being transmitted or received over a network to which the computer is attached. 18 and re-associating to the new AP. The controller will disconnect the client device from its current AP by sending a disassociation frame. The client device that receives this message will try and reconnect again. The SSIDs of the APs are the same so when it performs the discovery phase again, it will find the AP with the highest signal strength which will be the target AP. To ensure that the mobile device does not reconnect to its old AP immediately, the handover will only occur at a point where the client device is far away enough from its previous AP and the RSSI will definitely be lower than the target AP. The actions described in this paragraph are denoted by the NEW tag in the sequence diagram in Figure 3.4 on Page 20. The decision algorithm of the handover scheme is shown in Figure 3.6. Historical information about the mobile devices are to be stored on the controller so a smarter decision regarding whether the handover should occur in the first place is made. If the RSSI of the probe request frames on the currently associated AP is below a threshold and the RSSI of another AP is above a threshold, then the controller will facilitate a handover. The state machine diagrams of the client devices and the controller can be seen in Figure 3.7 and Figure 3.8 respectively. These state machines take into account the states of the IEEE 802.11 standard as well as the states that it results in due to the NEW actions denoted in Figure 3.4. 19 Probe Request (EXISTING) Discovery (NEW) Forward to controller AP2 AP1 Client Controller OFPT_SEND_PROBE Probe Response Probe Request OFPT_SEND_PROBE Probe Response Update DB (1) * Handover Decision (2) † (NEW) Preinstall Flow Rules IF Client probes on AP2 approaches threshold Flow Install Response IF Client probes on AP1 below threshold and Client probes on AP2 above threshold (NEW) Disconnect sticky clients Install MN Flows OFPT_DISCONNECT_CLIENT Deauthentication Request Deauthentication Response IF Client no longer connected (EXISTING) Reassociation (NEW) Forward to controller Re-authentication Request OFPT_SEND_ASSOC Re-authentication Response Figure 3.4: Sequence Diagram of Algorithm Design New indicates recently covered details. Existing indicates the messages defined by the IEEE 802.11 standard. * Linked to Figure 3.5. † Linked to Figure 3.6 20 (2) (1) Query DB for Client Information Request from AP RSSI on Current AP (AP1) below threshold No Yes No Update DB on Controller RSSI on AP2 above threshold Yes Perform Handover from AP1 to AP2 Figure 3.5: Flow diagram of the in-memory database being updated as new information arrives from AP. Figure 3.6: Flow diagram for handover decision. 21 Discover new APs Associated Discovery Current AP is Best Found better AP Deauthenticated Associate to another AP in range Authenticating Figure 3.7: State machine of the client devices in the OpenFlow network. The state machine takes into account the behaviour of the clients as defined by the IEEE 802.11 standard and the result of the actions specified by the controller in the scheme produced. 22 Controller Terminated Perform Handover Handover Required Handover Algorithm Run Algorithm Handle Probe Controller started Listening Handle Packet_in Handle Association Handle Disassociation Figure 3.8: State machine of the SDN controller in the OpenFlow network. The state that the controller can be in depends on the information that it receives from the APs. 23 24 Chapter 4 Implementation This chapter documents the process of implementing the network-side SDN solution to a handover algorithm. The implementation consists of three main functions: (i) Install and compile OpenFlow on a WiFi router, (ii) Disconnect clients with OpenFlow messages and (iii) Controller and WiFi router handover information exchange using OpenFlow messages. The challenges and individual components that make up the system are detailed. 4.1 OpenWrt and OpenFlow OpenWrt is an open source Linux based operating system (OS) that is installed and run on embedded devices such as typical consumer routers [35]. OpenWrt is known for its customizability due to its ease of installing packages to add new features. As the solution was to be SDN-based, open source software is a must as OpenFlow needs to be able to talk to the kernel to gain access to the hardware. 4.1.1 DHCP Server As described in Chapter 3, there can only be DHCP server on the network to prevent address conflicts and remove the need for a full network layer handover. The majority of enterprise and campus wide networks have a single DHCP server that is in charge of allocating an IP address for all the host devices across their wireless backbone. The same system was implemented within the test network. To reduce hardware costs and complexity involved with a physically separate DHCP server, one of the OpenWrt routers was setup as the DHCP server. All of the OpenWrt routers have a DHCP server enabled by default. Disabling the DHCP server on all but one of the routers results in the request being forwarded to the only DHCP server in the network. The has the same effect as having a single physically separate DHCP server. In order to disable the DHCP servers on the OpenWrt routers, option ignore ’1’ needs to be added into the lan network of the /etc/network/dhcp configuration file. This can be seen below. config dhcp ’lan’ ... option ignore ’1’ 4.1.2 OpenFlow Packages The OpenFlow protocol has been implemented by several organizations to run on top of OpenWrt. These implementations turn a generic wireless router that is capable of running 25 OpenWrt into an OpenFlow switch. Pantou is a project created by Stanford (where OpenFlow was created) that turns an OpenWrt router into an OpenFlow enabled switch. CPqD is a Brazilian company that specializes in networking solutions. They too took part in a project to turn an OpenWrt router into a OpenFlow enabled switch. The difference between these two projects is that Pantou is based on the OpenFlow 1.0 specification compared to CPqD which is based on 1.3. OpenFlow 1.3 was intended by the ONF to be the current ”stable” release of OpenFlow. For the flexible match and traffic metering features introduced between OpenFlow versions 1.0 and 1.3 (inclusive), the CPqD implementation was chosen as it is based on the 1.3 standard. 4.1.3 Monitor Mode Kernel Panic The OpenWrt build for the Linksys WRT1900ac contained a bug which caused the router to crash and reboot after being started up for a few minutes when a monitor mode interface was enabled on one of its wireless radios. Having a monitor mode interface on the radios are a vital part of the handover algorithm it is required for obtaining IEEE 802.11 management frames, and to send deauthentication frames that have been crafted by the disconnection code described in section 4.2. The router would reboot in a matter of minutes. The reason for the reboot was not initially clear. Tests with the monitor mode disabled did not result in the router rebooting. When a monitor mode was enabled, it would reboot after 3-5 minutes of the router being turned on. No error messages would be printed out onto the console when the router crashed and rebooted so tracing the error was not easy. Research into this problem did not lead to an answer as to why this occurred. To figure out what was causing this to occur, a transistor-transistor logic (TTL) to universal serial bus (USB) board (also known as a dev board) was soldered onto the main-board of the router to create a serial link to observe debug information. Once the dev board was soldered on, the router was booted on to determine the location of the kernel panic. As initially expected, the router would reboot after it had been turned on after a few minutes with a monitor mode interface enabled. The reason for the reboot is due to a kernel panic. A null pointer was being dereferenced. The call stack of the kernel panic traced the crash back to the mwlwifi driver that was used for the wireless radio devices in the router. Enabling the debug symbols traced the kernel panic back to the tx.c file of the WiFi driver. The exact location of kernel panic was traced back to the mwl tx done function. One of the data queues of the radio interface would be freed after a transmission once its length was greater than SYSADPT DELAY FREE Q LIMIT: a pre-processor macro that was defined as 256. This error can be seen in the code snippet below. There was no obvious reason for the queue to be kept at a constant length of 256, and only dequeued once it reached a length of 257. Removing the if check fixed the kernel panic. Once the packet was transmitted, freeing the memory that stored the data is intuitively the correct way to go (as with the original drivers released by Marvell), but the WiFi drivers did not have a comment explaining why it was kept at the aforementioned size, nor did the developer respond to questions regarding the matter. if (skb queue len(&priv−>delay q) > SYSADPT DELAY FREE Q LIMIT) dev kfree skb any( skb dequeue(&priv−>delay q)); Subsequent releases of the mwlwifi driver for the wireless chipset continue to have this error as the developer has not made the above change into the code. If a newer version 26 OpenWrt is compiled in the future, the above change needs to be made once again to the driver to prevent a kernel panic as the code is re-downloaded from the github repository each time a new compilation is made. Further changes to an existing OpenWrt does not require the change to the driver each time an image is compiled as code is only pulled from github when a fresh compile is made. 4.2 Disconnecting Clients Different WiFi standards have different throughputs due to different data rates (i.e. IEEE 802.11b and IEEE 802.11g have different data rates). The throughput of a wireless channel depends on many factors but as the user moves further and further away, the delay and throughput starts to decrease due to a degradation in the quality of the wireless link. Client devices tend to stay connected to an AP for as long as it can as the user moves away despite link conditions gradually degrading. This is known as a ”sticky client” [36]. As the implementation of a client devices’ behavior differ between manufacturers, the network needs to be able to handle such cases. These sticky client devices need to be disconnected from currently associated APs when there is a more suitable AP available (i.e. closer than current AP). As the solution is OpenFlow based, the controller is able to determine when these cases are, as packets not matching a rule in the flow table are sent to it. Probe packets will not have a flow installed to ensure that they are sent to the controller. The controller gets this information and determines whether a handover is needed. The scheme to disconnect the client devices is based off an attack normally used on WiFi networks. As part of the IEEE 802.11 standard, a management frame called ”deauthentication frame” can be used to deauthenticate from an associated AP or an associated client. Upon receipt of this frame sent from the AP, a client device is disconnected from its associated AP. Such frames are normally sent from an attacker spoofing an APs MAC address to cause a denial of service (DoS) attack so client devices can no longer connect to an AP. The handover scheme needs client devices to switch APs when the controller sends a request so such a method is needed. When the decision algorithm has determined that a handover is needed, the controller will send a ”Disconnect Client Request” OpenFlow message to the AP. Upon receipt of this message, the AP needs to send deauthentication frames to the client specified in the message. 4.2.1 Python Implementation The initial method of disconnecting client devices was to use Python and a library called Scapy. Scapy is a packet crafting tool normally used to create packets so they can be sent over a network. So long as a monitor mode interface could be created Scapy could be used to send a packet (which is supported in OpenWrt). The Python implementation of the disconnection code was able to be implemented in around 20 lines of code. The scapy library wraps the functions available to the packet capture (pcap) and radiptap (standard for IEEE 802.11 packed injection) into functions that can be called. The program is run by passing it 4 arguments, a monitor mode interface to send the frames out of, the BSSID (MAC address) of the AP, MAC address of the client to disconnect (or FF:FF:FF:FF:FF:FF to disconnect all associated clients), and the number of frames to send (as 1 might not react the host). There were issues with the Python implementation. The first is the storage required for the Python language itself. The TP-Link Archer C7 only has 16MB of flash memory, meaning it does not have sufficient space for both the OpenWrt OS and the Python language package. 27 This was not a problem for the Linksys WRT1900AC though. The other was the performance of Python. Python is an interpreted so it must interpret the code into machine code as it runs. An analysis by Prechelt [37] found that depending on the application, a Python implementation of the same piece of code was often 10 times slower than the C equivalent. When the disconnection implementation was run, a spike in CPU and RAM usage can be observed. CPU increases to 50% utilization and RAM usage increases by 20MB. 4.2.2 C Implementation The C implementation uses a packet injection library called osdep that was included as a package in Backtrack Linux and a tool called Aircrack-ng. The C implementation of the disconnection code performs the same functionality as the Python implementation but in 100 lines of code instead of 20. The C implementation takes an extra argument, the channel the wireless card is operating on as the osdep library does not default to the channel of the wireless card. C code needs to be compiled into a binary executable before it can be run. A complex nested makefile was written to ensure that the osdep library could be compiled for multiple platforms so it could be tested before being loaded onto the routers. The code was compiled and successfully run on a laptop running Ubuntu 14.04. The code allows a frame to have the BSSID of an AP spoofed into the source MAC address field so the code was confirmed to work as clients could be successfully disconnected. Compiling the code for OpenWrt was not as simple as running a makefile. Extra C flags are used to ensure both the code and the osdep library was compiled correctly for the platform of each router (different CPU architectures require different compiler toolchains). The routers used are embedded devices and the code needed to be cross compiled. The path of the toolchain that was used to compile the OpenWrt needed to be passed to the makefile. Upon compiling the code, a binary executable of the disconnection program is made along with a library for osdep. These need to be copied into the /usr/bin/ and /usr/lib/ directories within the OpenWrt file system respectively in order for the binary to be executed so clients can be disconnected. Issues were had with certain builds of OpenWrt. OpenWrt seemed to alternate between the uClibC and musl C standard library toolchains to compile the firmware. When the uClibC library was used, the disconnection code was able to be compiled and run in OpenWrt. When the musl toolchain was used, the code could be compiled, but not run in OpenWrt because the path of the toolchain could not be passed to the makefile. 4.2.3 Tying into OpenFlow In order to disconnect a client using the C implementation, a new OpenFlow message had to be created to instruct the AP to do so. The task at hand is unconventional in that the OpenFlow switches are meant to be ’dumb’ and only perform forwarding based on the actions specified by a controller. The all-in-one routers running OpenWrt are not completely ’dumb’ and have a wireless AP built in. Several lines of code were written to enable this function on both the AP and the controller. OpenFlow Switch/AP Disconnect Message Implementation As the APs needed to disconnect the client devices when the controller has determined that a handover is needed, a change to the OpenFlow implementation for the switches was needed. The CPqD implementation conforms to the OpenFlow 1.3 specification. This means that there are 29 types of OpenFlow messages [38]. In order to trigger the AP to disconnect the client devices, a new OpenFlow message needed to be created. 28 All OpenFlow messages begin with an ofp header which determines the version of the protocol in used (0x04 for 1.3), the message type (a new type needs to be created to disconnect the client), the length of the OpenFlow message (including header and payload), and the translation id. New OpenFlow messages have since been added in the OpenFlow 1.4 and 1.5 specification to add additional functionality [39]. To ensure compatibility with future versions of OpenFlow, the OpenFlow message created was on a large number that is not in use, and will not be in use within the near future. A a result, the new OpenFlow message for disconnecting a client was OFPT DISCONNECT CLIENT = 168. struct ofp header { uint8 t version; uint8 t type; uint16 t length; uint32 t xid; /∗ OFP VERSION. ∗/ /∗ One of the OFPT constants. ∗/ /∗ Length including this ofp header . ∗/ /∗ Transaction id associated with this packet . Replies use the same id as was in the request total len facilitate pairing . ∗/ }; The below code snippet shows the format of the new OpenFlow message created. Along with the required header, the controller needs to specify the BSSID of the AP that needs to disconnect the client, the MAC address of the client to be disconnected, the channel the AP is operating on, the interface of the wireless device and the number of frames to send. struct ofp msg disconnect client { struct ofp header header; /∗ OFPT DISCONNECT CLIENT, ∗/ char ap bssid[18]; /∗ BSSID of AP ∗/ char client mac [18]; /∗ MAC address of client to disconnect ∗/ /∗ Channel specific interface operating on ∗/ uint16 t channel; char interface [20]; /∗ Interface that client is associated to ∗/ uint16 t num send; /∗ Number of deauth frames to send ∗/ }; OpenFlow Controller Disconnect Message Implementation Along with a new message being created on the AP, the same message needs to be implemented on the controller. The controller is running RYU and requires the code to be written in Python. Unlike C, Python does not have structs so the message sent to the controller with the fields needed to disconnect a client is needs to be packed into a message that that can be cast back into what the AP expects. The format string equivalent to the C struct of the disconnect message can be seen below. The OpenFlow header is added on by RYU and is not part of the format string. OFPT DISCONNECT CLIENT PACK STR = ’!18s18sH20sH’ OFP DISCONNECT CLIENT SIZE = 60 assert ( calcsize (OFPT DISCONNECT CLIENT PACK STR) == OFP DISCONNECT CLIENT SIZE) When the controller needs to instruct the AP to disconnect a client, it needs to construct an instance of the OFPDisconnectClient class. Once this is constructed, the object is passed to the datapath to pack into a byte stream and send to the OpenFlow switch. Upon receipt of this message, the OpenFlow switch will unpack the message as described in sub-subsection 29 4.2.3 back into the C struct and compose a string that matches the disconnect program created as described in subsection 4.2.2. 4.3 Sending IEEE 802.11 Management Information to the Controller On top of being able to disconnect a sticky client from the controller, the controller also needs IEEE 802.11 management information from the AP that is built into the OpenFlow switch. RSSI and association information is retrieved from IEEE 802.11 management frames for tracking a client. This tracking information is sent to the controller as it is captured on the monitor mode interface There were two proposed solutions to addresses this. The first was to implement a poll system on the controller so it periodically requests this information from the AP. Upon further analysis, this proved to be a poor solution as it means the controller will not immediately receive new information at the same time as the APs. This means that the Probe Request and Authentication frames will not received by the controller immediately until it polls the AP. This information needs to be sent to the controller as the AP receives it. The solution to address the shortcomings of the first proposed solution was to monitor when the AP received this data and send to the controller immediately once received. This solution involved implementation on both the APs and the controller. Like the code to disconnect sticky client devices, new OpenFlow message types were created on both the APs and controller. • OFPT SEND PROBE = 169 • OFPT SEND ASSOC = 170 • OFPT SEND DISASSOC = 171 Additionally, a C struct was implemented on the AP in order for the messages to be packed and sent to the controller. The controller also have the definitions of these new messages implemented and the corresponding unpack functions to obtain a Python version of the C struct. Each message type corresponds to an IEEE 802.11 management frame that is required on the controller. An event handler matching. The event handler function definition for the Probe Request frames can be seen below. The ofp event.py file of the Ryu controller contains code that allows an event handler to be created for any OpenFlow message type as long as a definition was created prior in the ofproto v1 3 parser.py and ofproto v1 3.py files. @set ev cls(ofp event.EventOFPSendProbe, MAIN DISPATCHER) def send probe handler(self, ev): ...... 4.3.1 OpenFlow Switch Implementation Tcpdump was used too monitor IEEE 802.11 management frames as the were received at the AP. A single command with a filter that monitored the required information was written and run from within the control plane part of the OpenFlow protocol. This command with the filter can be seen below. 30 tcpdump -l -i wlan1 -e type mgt subtype probe-req or type mgt subtype auth or type mgt subtype disassoc By default, tcpdump will capture all traffic on the given interface unless specified by a filter. Once certain types of IEEE 802.11 management frames needed to be sent to the controller. This tcpdump command and filter above collects the following information and nothing else. • Probe Request frames: Sent from client devices to actively discover reachable APs once they response to these frames [21]. The client devices will send these frames to APs within the OpenFlow network; the APs will then construct a message and send to the controller immediately. • Authentication frames: Sent when the client initially associates to an AP or when it is moving from one AP to another. When the client devices initially associate to an AP, it will send an Association Request to the AP, which the AP will then respond to with an Association Response if it can handle the client [21]. The problem with monitoring Association frames is due to these only being sent when a client initially associates. When it moves to another AP of the same SSID within its vicinity, it will not send an Association Request, rather it will only send an Authentication frame. As a result, the tcpcump filter monitors Authentication frames and sends these to the controller when they are received. • Disassociation frames: Sent by the client device to its associated AP when it wants to leave the network due to the WiFi interface being shut down or when the user manually switches to another SSID [21]. When these frames are received, the controller is informed in order for it to stop tracking a client because it will no longer be roaming between the APs in its network. When OpenFlow is started up, tcpdump is started using the popen function which forks the parent process into a child. The child process then progresses into an infinite while loop where it waits for output from tcpdump. When output is received, it will construct an OpenFlow message corresponding to the received frame type to send to the controller. As with disconnecting a client, a struct representing the OpenFlow message is filled in and then packed into a byte stream before being sent to the controller. 4.3.2 RYU Controller Implementation For each of the three IEE 802.11 management frames that are being monitored, a Python class matching each of the C structs was created. The information from the management frames that were extracted from tcpdump are then packed into an OpenFlow message to send to the controller. Within the controller application, an event handler was written to handle the messages when one of the three managements frames were received from the AP. An event handler will call a function associated with a particular OpenFlow message upon the receipt of one of the three messages corresponding to the IEEE 802.11 management frames captured. The core part of the handover algorithm is being able to monitor Probe Request information from the controller. This enables the controller to monitor when client devices are moving between APs. As with the algorithm design, if the client devices are ’sticky’ and are hanging on to their current associated AP, while the Probe Requests are getting stronger on another AP, the controller will disconnect these clients. Once disconnected, the client 31 devices will under normal circumstances authenticate to another AP of the same SSID in the OpenFlow network. This is normally the case on both Android and iOS devices though some will have new ’Smart Network’ features enabled that will decide to disconnect from WiFi networks completely and only use their mobile connections (3G/4G). The event handler corresponding to the OpenFlow messages sent by the APs when they receive Probe Request messages is the core part of the solution. The main algorithm is implemented within this function. When Probe Request information from an OFPT SEND PROBE OpenFlow message is received, the controller will check the numbers against the client devices currently associated AP (assuming the Probe is for another AP) and determine whether a handover is needed. If the RSSI of the AP that the Probe Request was received on is within 10 dBm of the threshold, the existing flows of the particular client device that sent the frame will be pre-installed into this AP. If the RSSI of a client device in the Probe Request on the current AP is below the threshold along with being below the threshold on its currently associated AP, the controller will instruct the AP to disconnect the client in order for it to connect the the target AP. New association and dissociations of client devices to an AP within an OpenFlow network are monitored from the controller. As described in subsection 4.3.1, association frames are only sent from a client device to an AP if the AP is the first one of that SSID that the client is connecting to. If the client device is moving from another AP of the same SSID, it will only send an authentication frame to the AP. As a result, the AP will forward association frame information to the controller. The controller maintains a mapping of client devices to their respectively associated APs as well as a list of clients that are currently associated to each AP that is within its network. 4.3.3 Storing Information on the Controller To meet the design of storing some state information about the AP and clients, a Python dictionary was used. Using a database stored in secondary storage would slow down the reads and writes when information was received from an AP. Using primary memory (RAM) to store this information would allow for fast write and read access when data came in or when data needed to be read in order to make the handover decision. When Probe Request information is received from an OpenFlow switch, the controller creates an entry in its attributes which act as the in memory storage. The self.probe client to apbssid = attribute is used to maintain Probe Request data. Probe Request data is only recorded on the controller if the MAC address of a client device is already associated to an AP in the network. The dictionary contains an entry for each client device that has sent Probe Request frames to any AP in the network. For each client mac entry in this dictionary, there is an inner dictionary for each BSSID (each AP) in the network that associates a timestamp with the RSSI information received. As most client devices observed in practice sends out anywhere from three to five Probe Request frames each time it enters the discovery phase to determine what APs are in range, the controller makes use of this by storing four of these frames. Doing this allows for a more accurate reading of the RSSI to be calculated, smoothing any potential error in the readings if one of the Probe Request frames is incorrect. In practice, all of the client devices sent out between three to five frames, the manufacturers of these devices have no set guidelines on how many they send as this is not specified by the standard. On top of the Probe Request information, the controller also maintains a list of clients associated to each AP and which AP a client is associated to. The self.assoc apbssid to client attribute is a Python dictionary that that controller maintains to ensure it has an up to date view of what clients that are associated to an AP. The self.assoc client to apbssid = attribute 32 in comparison is used to quickly determine which AP a client is associate to. It maintains a 1:1 mapping of a client MAC address to the BSSID of an AP in the network. 4.4 Modular Design The CPqD implementation was not documented on the Github page of their OpenFlow implementation nor was it on their company website. Tracing where the part of the protocol to connect to the controller was a difficult task as the original authors used an unconventional naming scheme to define the entry point of their program. Once found, the initialization point was used to enable the packet capture of IEEE 802.11 management frames, and additional OpenFlow messages were created to send to the controller. The initial method of using a monitor mode to pass IEEE 802.11 management information to the controller failed as the packets came out malformed when captured using tcpdump. Code was added to allow new OpenFlow messages (structs and message packers/unpackers) to be created with minimal changes. As each additional functionality was complex, implementation would require many new lines of code. Writing the code in a modular fashion allows future functionality to be added with minimal changes to the code. Any extra information that needs to be obtained from the controller can be obtained with a common new OpenFlow message and a corresponding message structure to send to the controller. This provides the foundation for any future features that could be explored to determine if a further improvement to the handover management scheme could be obtained. 33 34 Chapter 5 Evaluation This chapter details the experiments performed to determine the thresholds used in the algorithm and to evaluate the performance of the solution produced. The tests involved setting up hardware in various locations. 5.1 Experiments to Determine Algorithm Thresholds As part of the algorithm design in Chapter 3, a threshold needed to be met (for both a mobile device’s currently associated AP and a target AP to handover to) before the handover should occur. To determine the optimal threshold to initiate the handover, experiments were performed to observe the signal strength and throughput of a WiFi connection. On top of this, the experiments done would calibrate the ideal transmission power to set the AP to. If the transmission power is set to a value that is too high, a large distance would be needed to collect data to evaluate the proposed solution. The following objectives were set for the experiments • Determine RSSI changes with straight line distance in a real world environment. • Determine throughput changes of a wireless link with straight line distance in a real world environment. • Determine the RSSI at which client devices switches APs with an AP running a standard implementation of the IEEE 802.11 standard. • Obtain a set of thresholds to determine when to initiate a handover. 5.1.1 Experiment Environment There were different experiments performed to determine an optimal handover threshold. Two different sets of experiments were performed. The first was to determine how figures such as RSSI and throughput changes as a mobile device is moved away from an AP. The second was to determine the RSSI at which a mobile device would switch from its currently associated AP to a target AP when a standard IEEE 802.11 implementation is used. The experiments to determine how RSSI and throughput changes with distance were performed indoors along the Laby to Cotton corridor. Doing these experiments allows real world numbers to be compared to theoretically predicted values under ideal situations without interference. 35 The experiments determining handover thresholds were performed in three indoors and one outdoor scenario. The indoor scenarios were three different locations within the Kelburn Campus of Victoria University. This indoor environment reflects the typical noise and interference associated with human movement patterns and other APs within range that are potentially operating on the same or overlapping channels. The first of the indoor scenarios was in the Laby to Cotton corridor which reflects a typical path that a student might take as they move from one class to another. The second indoor scenario was in level two of Cotton which may represent the path a student takes to reach a lecturers office. The third scenario was in the Hub which reflects where a student may go to meet up with friends for lunch. This environment usually contain the highest concentration of people at certain times of the day reflecting the highest interference from movement and other WiFi signals. The fourth scenario is an outdoor setting in Lower Hutt, Wellington, New Zealand, with minimal interference due to few people and minimal WLAN pollution in the vicinity to act as a baseline reference. Figure 5.2: Indoor open space scenario with many people in the Hub Figure 5.1: Indoor office scenario in Level 2 of Cotton Figure 5.3: Indoor line of sight scenario in the Laby to Cotton corridor Figure 5.4: Outdoor scenario in Lower Hutt 36 5.1.2 Experiment Equipment and Setup The test bed equipment was comprised of both network and host devices. There was a difference in requirements for the kind of data and control needed from the perspective of the network, and from a host. All of the network equipment (APs) used in the experiment (Linksys WRT1900ac) were identical and running the same version of OpenWrt (15.05 Chaos Calmer) in order to achieve homogeneity and reduce systematic bias that could result due to differences in handover handling in both the hardware and drivers running within OpenWrt. The APs were configured to run in Channel 1 on the 2.4 GHz band using IEEE 802.11b speeds with a maximum data rate of 11 Mbps (at the physical layer). Each AP used in the experiment records data from it’s own perspective (runs the shell script individual from another AP) and logs the result into a Comma Separated Values (CSV) file on the AP’s internal flash memory to be parsed later. Each mobile host was tracked using their MAC addresses which each AP would maintain a list of had they associated with the AP (and not disassociated from). An assumption was made tat each mobile host has a unique MAC address. The host devices on the other hand did not need to be identical like the network equipment. A variety of Android smartphones and an Apple iPhone was used in the experiments. Tracking each of these different types of smartphones allowed the various hardware and manufacturer implementations of the IEEE 802.11 standard to be reflected in the data gathered. Rather than create a model for a single device, the use of multiple devices allows the model to be smoothed and applicable a scenario where a handover is required for many differing host devices in a single network which is normally the case. Before setting up the equipment to run the experiments, a site survey at each of the four chosen locations were conducted. This was done to determine a common transmit power that would be appropriate for the space available at the locations as well as for determining ideal AP placement. Based on the site survey, a device is likely to switch between APs when the transmit power was configured to 15 dBm. 5.1.3 How RSSI Changes with Distance Thee equation for determining the RSSI of a given device can be calculated using Eqn. 5.1 given by Rappaport [40]. The path loss exponent n in Eqn. 5.1 is altered to represent the losses associated to the material or environment that a radio wave has to propagate through. This exponent typically ranges from 2 in an indoor environment, and goes up to 4 in a dense indoor environment as determined from empirical experimentation. PL(dB) dBm = PL(d0 ) dBm + 10nlog10 ( d ) d0 (5.1) Where • PL(dB) is the path loss in dBm • PL(d0 ) is the reference reading (typically 1m from the transmitting AP) in dBm • n is the path loss exponent that indicates the loss rate increase with distance • d0 is the reference distance (the distance the reference reading was taken from) in m • d is the actual distance a device is from the AP in m The indoor environment of Victoria University is made up of various materials and density of students which results in incorrect distance calculations from the path loss formulas when a fixed path loss exponent is used. The first experiment to determine how RSSI 37 RSSI vs. Distance 25 0 n=2 RSSI (dBm) −25 −50 n=4 −75 −100 0 30 60 90 Distance (m) Figure 5.5: A comparison of how RSSI changes with distance from the perspective of both the AP and a client device. The red series is the RSSI of the AP from the perspective of the client and the blue series vice versa. The lines n=2 and n=4 shows the theoretical RSSI values when those path loss exponents are used in Rappaports model [40] in Eqn. 5.1 changes with distance was performed in the corridor from Laby to Cotton. The experiments were performed during both peak and off peak times to determine if there was an observed difference in readings. Figure 5.5 shows the results of the experiment. The red series represents the observed RSSI of the Nexus 5 from the perspective of the AP and the blue series is the observed RSSI of the AP (from its beacon frames) from the perspective of the smartphone. A path loss exponent of 2 represents a free space model where as a exponent of 4 represents a two-ray model. These can be compared to the experimental results in Fig. 5.5. The average exponent in the experiment was slightly over 5. This was a surprising number as there was always a clear line of sight from the client device to the AP. The path loss exponent in a multi-story building across varies between 2-6 but the experiments were done on the same floor which should be between 1.6-3.5 according to empirical measurements [40]. 5.1.4 Throughput Changes with Distance One of the experiments to determine the thresholds for a handover was a throughput test. These were performed in the Laby to Cotton corridor. iPerf3 throughput tests were run at various distances ranging from 1m - 110m. Each run of the iPerf throughput test was setup to run for 100 seconds, giving 100 samples of the bandwidth. iPerf defaults to using TCP, and as a result the maximum throughput in an IEEE 802.11b network that can be achieved in practice under ideal conditions as around 6-7 Mbps. This can be seen in Fig. 5.6 when a Nexus 5 is placed 1m from the AP which is considered an ideal condition but is not reflective of the distances users are from an AP in real world scenarios. Throughout decreases as the smartphone is moved further away from the AP. At two points (30m and 70m), throughput actually increases, which is likely due to increased reflections from the surrounding walls and objects at these points. When Fig. 5.6 is placed alongside Fig. 5.5, it is observed that while RSSI is still high at 60m, throughput has significantly decreased to 2 Mbps, which is less than a third of that it was when the client device was placed 1m from the AP. 38 Throughput vs. Distance Throughput (Mbps) 6 4 2 0 0 30 60 90 Distance (m) Figure 5.6: A graph showing how throughput changes with distance. 5.1.5 Handover Experiments There are several factors that need to be taken into account for the design of the handover algorithm. The main one being the RSSI thresholds when to perform a handover. The RSSI values of the probe request frames from mobile devices on both their currently associated AP and target APs need to be analyzed to determine the ideal values. To determine the RSSI thresholds for when a client should be disconnected, a set of experiments were conducted to collect data from APs the moment a mobile host switches from one AP to another. A user with a mobile device (Nexus 5, iPhone 4 and Samsung Galaxy S4) walked along a path from one AP to another to create the distance required for a handover to be initiated. The travel path that were taken to perform the handover experiments can be seen in Figures 5.1, 5.2, 5.3 and 5.4. A shell script was written to automate measurement and data collection. Each AP used in the experiment records data from it’s own perspective (runs the shell script individually from another AP) and logs the result into a Comma Separated Values (CSV) file on the AP’s internal flash memory to be parsed later. Each mobile host was tracked using their MAC addresses which each AP would maintain a list of had they associated with the AP (and not disassociated from). An assumption was made that each mobile host has a unique MAC address. The host devices on the other hand did not need to be identical like the network equipment. A variety of Android smartphones and an Apple iPhone was used in the experiments. Tracking each of these different types of smartphones allowed the various hardware and manufacturer implementations of the IEEE 802.11 standard to be reflected in the data gathered (non-device specific). Tracking several different devices allows a threshold to be determined that reflects the ideal RSSI for the controller to initiate the handover at, not specific to a particular device. 5.1.6 RSSI Handover Thresholds From the RSSI and throughput experiments, a good point to initialise a handover is when throughput decreases to a third of the maximum achievable throughput. Any less than this rate leads to increased times needed to transfer data and possible reduction of user experience in real time applications such as video streaming. This means these experiments 39 show that an ideal RSSI figure to perform that handover at is around -70 to -80 dBm provided the client device has not already switched over to another AP during the discovery phase. This matches the numbers used by Schulz-Zander et al. [28]. There are cases where a client device will not require to be disconnected by the controller and will actually move to an AP with a stronger signal by itself. In these cases, the code to disconnect the client will not be needed. This does completely depend on the specific device manufacturer though. 5.2 Evaluation Tests To determine the performance of the solution produced, several tests were conducted. These tests involved streaming video and audio to determine whether the limitations of a handover (delay and loss) have improved. The same tests were repeated using a fresh firmware flash of OpenWrt without any of the SDN implementations installed. This allows concrete comparisons to be made. 5.2.1 Evaluation Metrics The main metrics that need to be tested to determine the performance of the handover solution produced are: • Playback Delay • Packet Loss • User perceived improvement compared to a standard IEEE 802.11 implementation 5.2.2 Evaluation Methods Two different types of evaluation methods were used for the determine the performance of the handover algorithm. These are objective and subjective tests. The objective evaluation tests are the ones that are able to evaluate the performance of the handover algorithm against a standard IEEE 802.11 implementation using concrete data from packet captures and actual recordings of the playback recordings. Performing an analysis on the data allows the Delay and Loss metrics to be tested. The subjective evaluation tests required actual human subjects to take part in order to gain their opinion on any perceived improvement in the handover algorithms. The tests used were a simplified version of a mean opinion score. The ITU have defined methods for assessing a solution based on mean opinion score (subjective tests) in the P.800 [13], P.910 [14] and P.913 [15] methods, though they are too stringent for ENGR489. In order to do both an objective and subjective evaluation of the handover algorithm created, streaming tests was executed using the same network hardware as well as the client devices. Streaming both video and audio allows for data to be collected during the stream, as well as being played back to an audience of test subjects. 5.2.3 Test Environment The hardware for the OpenFlow was setup as in Fig. 5.7 for the evaluation. The hardware for a standard IEEE 802.11 network was setup in the same way with the only difference being that the controller was not used (nor was it needed). The hardware used was a mid2015 MacBook Pro for the SDN controller using official Thunderbolt to Ethernet adaptors to act as the control plane to the APs. The APs used were the Linksys WRT1900ac. They 40 Controller 192.168.2.168 Streaming Server 192.168.1.117 192.168.2.1 eth1 eth0.5 eth0.5 192.168.2.2 eth1 Router 2 Router 1 Client Figure 5.7: Hardware Test Setup were operating on the 2.4 GHz, using the IEEE 802.11b standard with the maximum data rate set to 11 Mbps (at physical layer). The radio was set to transmit to 15 dBm. The default rate adaptation for the AP was used (the mwlwifi driver for the Marvell 88W8864 Chipset). The APs were connected together using an Ethernet cable on each connected to a standard Gigabit Layer 2 Linksys switch that acted as the data plane. Also attached to the switch was the streaming server which was an Intel NUC 5i7RYH that contained a dual-core CPU and 16GB of RAM to transcode and stream the video to the client devices. The client devices were Google Nexus 5’s updated to the latest version of Android, 5.1.1 Lollipop. The same hardware was used across all experiments identical to achieve homogeneity and reduce systematic bias that could be due to differences how a handover is handled. The experiments for the SDN based handover algorithm involved all of the solutions described in Chapter 4 to be implemented and configured prior to starting. The experiments for a standard IEEE 802.11 network required all of the solutions and software implemented for the SDN-based network to be removed. This removes any potential for software inferring with each other, affecting the results. 5.2.4 Measurement The evaluation experiments were executed with both audio and video sources. A set of videos from YouTube were downloaded to use for the video experiments. Each video downloaded was encoded with a resolution of 1280x720 (720p) using H.264 coding. This was the best quality achievable on an IEEE 802.11b link without constant stuttering due to insufficient throughput. The audio file used was an MP3 file with the data compressed at 320 kbps. Each of the video and audio files were copied onto the streaming server where they were transcoded into an Moving Picture Experts Group-transport stream (MPEG-TS) to be sent 41 Up 0 13.6m 2m 6.06m 7.86m 5.54m Up Up 3.28m Floor 1 Floor 2 Figure 5.8: The environment the packet capture and audio/video took place in. to the client device. VLC was used as the streaming server. In order for the server to send the video and audio files out to a client device as a live stream, it had to transcode the video into an MPEG-TS. The MPEG-TS is then encapsulated into Real Time Protocol (RTP) packet before it is sent as a UDP packet to a particular client device. Once the audio/video streams were started, the client devices with MX Video Player installed would start listening to a network stream on the IP address of the streaming server. The audio and video files were each streamed onto the client device a total of 30 times. At the same time they were being streamed, a user with the phone would walk along the same path from one AP to the other as seen in Fig. 5.8. Once the user got to the other AP, they would wait until the handover has occurred before traversing the same path back to the first AP. They would know when the handover has occurred when the video or audio source stutters due to the make-before-break characteristic of a handover with WiFi. Also, the 2.4 wireless device activity LED on the AP would be flashing to indicate that there was traffic flowing from the AP to the client after the handover as the client device was the only associated client. At the same time the video and audio files were being streamed to the client device, a background tcpdump command was being run to capture all of the packets arriving on the wireless interface of the Nexus 5. The packet capture allows an analysis to be done afterwards to determine the number of packets that have been lost along with the delay incurred as a result of the handover. The video and audio streams were also being captured while they were being streamed to the client device. These video captures were to be used as part of a subjective test to determine if there was any perceived improvement in the handover algorithm (either in improved loss or delay rates) to a number of test subjects. 42 5.2.5 Dataset Processing The packets captured using the tcpdump command are saved into a pcap file that is not easily parsed without a dedicated library. Wireshark allows the packets to be decoded into RTP packets manually before being converted into a comma separated values (CSV) file which can be easily parsed. Once a CSV file, a small Python program was written to parse the file. The Python program parsed through the RTP packets that sorted in the order that they arrived on the wireless interface on the Nexus 5. The program compares the sequence numbers of the RTP headers to determine when a handover has occurred. When more than 50 packets had occurred, a handover was deemed to have occurred and the timestamp difference (in the packet, not in the RTP timestamp field) was calculated. The packet loss rate appeared to always be over 100 when a handover had occurred. As the packets being captured were live and corresponded to the audio/video being streamed on the client device, the data did not have to be cleaned except for when the stream completely cut out due to a significantly higher loss or delay rate. IEEE 802.11 requires a break-before-make handover which results in the lost and delay rates varying between the experiments. Occasionally, when a handover has occurred, the video files being streamed would completely cut out rather than stutter for the moment the handover occurred. While this will not always occur, MX Video Player may be the application that does this due to the way it is programmed. During runs where this phenomenon occurs, the pcap files were flagged to indicate that this had occurred in order for this to be logged later on. This phenomenon appeared to happen more for the IEEE 802.11 network more than the OpenFlow network. 5.2.6 Objective Evaluation Results Parsing the packet captures of the audio and streaming tests reveals the true performance of the SDN-based handover algorithm. The full results can be seen in Table 5.2. The delay and loss columns are calculated with the two packets captured just before and just after the handover. The delay results are calculated by subtracting the timestamps of the two aforementioned packets. The loss results are calculated with the sequence number fields of the RTP header in the same packets. The loss rate of a handover is expressed as a percentage of the total number of packets in the entire stream. Analysis • There was a still a noticeable delay when switching APs in the OpenFlow network. This is expected due to the break-before-make nature of WiFi though the performance was still better than a network with APs running a standard OpenWrt implementation. • The number of packets lost during a handover has decreased though the rate is still high enough to cause a noticeable delay during video playback. • The dropout rate across the 30 runs of each streaming tests was on average 6% lower in the OpenFlow network compared to a standard IEEE 802.11 implementation. While this is an improvement, the dropout rate is still to high as the users will have to reestablish the video streams if the loss/delay rate is too high. • There was an overall 26.7% improvement in delay and 43.8% improvement in packet loss when the SDN handover algorithm was used. This can be attributed to the flows being pre-installed early removing the need for a packet in during the first handover. 43 Source Audio 1 Video 1 Video 2 Video 3 Video 4 Average Min Max Average Min Max Average Min Max Average Min Max Average Min Max Average Min Max Average Table 5.1: My caption Delay (seconds) Packet Loss (%) 802.11 OpenFlow 802.11 OpenFlow 2.01 0.02 1.93 0.25 4.06 3.23 5.06 4.23 3.05 2.34 3.25 1.86 1.09 1.13 1.29 0.62 5.38 3.65 6.58 3.22 1.96 1.64 3.93 1.52 1.79 0.18 1.52 0.58 5.40 4.99 3.86 4.14 3.60 2.40 2.73 2.43 1.93 0.05 3.14 0.19 9.89 5.06 5.07 4.45 2.76 2.15 3.97 1.78 0.02 0.02 0.10 0.14 12.64 5.03 7.96 4.12 3.04 2.04 1.54 1.05 1.37 0.28 1.60 0.35 7.47 4.39 5.71 4.03 2.88 2.11 3.08 1.73 Dropout 802.11 OpenFlow 0% 0% 33.3% 23.3% 26.7% 20% 23.3% 16.7% 36.7% 30% 24% 18% Table 5.2: The packet capture of the audio and video streams compares the performance of a standard IEEE 802.11 network vs an OpenFlow enabled one. 5.2.7 Subjective Evaluation Results The screen captures of the video and audio files were played back to the NWEN302 class of 17 students. The ITU subjective assessment states that a minimum of 15 test subjects are needed for subjective quality evaluation, meaning the 17 students of NWEN302 were sufficient for the test [12]. The screen captures on an IEEE 802.11 and OpenFlow network were randomized to prevent the students from knowing which video belonged to which network. Under normal circumstances, the audio stream playback would be more indicative of the performance of the handover algorithm as the human ear is more sensitive to loss than the eye. In the case of all of the videos being played back, there was noticeable stuttering during the handover for both an IEEE 802.11 and OpenFlow network due to the breakbefore-make nature of WiFi. Hence the audio test was less indicative of the performance than the video stream playback files though the test subjects did find the audio stream better on the OpenFlow network. Two versions of the same audio/video stream were played to the students one after another. Once playback had ended, the students were asked for their preference for one of the two streams or whether there was no perceptible difference. Table 5.3 shows the results from the subjective tests based on the opinions of NWEN302. Analysis Across the one audio and four video tests, there was a clear preference for the streams that were being sent from an OpenFlow Network. In Video 1, the entire NWEN302 class preferred the stream played back on an OpenFlow network. The combination of disconnecting 44 Source Audio 1 Video 1 Video 2 Video 3 Video 4 802.11 21.4% 0% 5.9% 0% 21.1% OpenFlow 57.2% 100% 70.6% 94.4% 26.3% No Perceived Difference 21.4% 0% 23.5% 5.6% 52.6% Table 5.3: The packet capture of the audio and video streams compares the performance of a standard network vs an OpenFlow enabled one. the client and pre-installing flows for that run produced the best results out of all the tests. There was a notable difference which was also evident in the packet capture. Video 4 was the worse performing stream across all of the tests with a noticeable pause across both videos leading to over 50% of the students not seeing a difference between the two. Despite the noticeable pause, of the students that felt there was a difference, the preference was still favored to the OpenFlow network. What is notable from this test is that there is definitely a perceived difference in the perceived QoS to a collection of test subjects. Despite complex buffering and bi-casting techniques not being used in the network, there was still a perceived performance increase across all of the audio and video streams tested. 45 46 Chapter 6 Conclusions The IEEE 802.11 standard for WiFi did not explicitly support handovers as its original intended use was not for real-time delay sensitive applications leading to high delay and packet loss rates when a client device switches APs. The idea behind this project has been developed from the basis that the global view and programmability attributes offered by an SDN architecture could improve the performance of handovers in WiFi. Existing research focused on developing a handover scheme that needed to be deployed on both client and network devices. The aim of this project focused on creating a network-only solution that do not require any changes to the client devices. The results showed that the handover algorithm utilizing OpenFlow and disconnecting sticky clients to force them to a new AP resulted in an improvement in delay and packet loss rates in video and audio streaming. The improvement can as seen in objective tests via packet captures shows an average reduction of 26.7% in delay and 43.8% in packet loss. The design and implementation of the handover scheme used in the validation has created a platform for the system to be improved on in the future. The handover algorithm implemented performs its decision process based on RSSI but studies have found that there are other handover metrics that could also be effective in determining the ideal situation for a handover. The design also allows any extra information that is normally specific to the AP to be sent to the controller. This includes physical and link-layer information such as noise, and rate adaptation rates. The platform allows for the realization of capabilities on an SDN that has not been done before. 6.1 Future Work This project demonstrated the effectiveness and benefits that an SDN can offer in terms of handover performance, but it can be extended further in a number of ways: Buffering Techniques Despite the improvement in delay and packet loss during a handover, there were often times where the video streams would still cutout during a handover as shown in Chapter 5. This is due to the packet loss rate still being too high. The use of buffering techniques typically found in application-level protocols and tools can be developed for an SDN to further improve handover performance. Due to the break-before-make nature of WiFi handovers, packet loss is generally unavoidable. By buffering the packets sent to an AP during a handover, and sending them to the client afterwards, this loss can be mitigated. 47 Extending the solution to work on Production-Grade Hardware The project only involved the use of consumer-grade hardware that were capable of running OpenWrt. Being able to port the solution over to production grade hardware can allow the solution to be realized on hardware that the university uses, creating a feasible business case for the university to consider a SDN in the future. 48 Bibliography [1] Cisco, “Cisco visual networking index: Global mobile data traffic forecast update, 2014 - 2019,” Cisco Public., 2015. [2] E. J. A. Jr, “Mobile communication system,” US3663762 A, Bell Telephone Labor Inc, http://www.google.com/patents/US3663762. May 16, Available 1972, patent online via [3] H. Velayos and G. Karlsson, “Techniques to reduce the IEEE 802.11b handoff time,” in IEEE International Conference on Communications (ICC), vol. 7, June 2004, pp. 3844–3848 Vol.7. [4] M.-L. Tham, C.-O. Chow, Y.-h. Xu, K. Choong, and C. Lee, “Seamless handover between unicast and multicast multimedia streams,” Journal of Zhejiang University SCIENCE C, vol. 15, no. 10, pp. 929–942, 2014. [Online]. Available: http: //dx.doi.org/10.1631/jzus.C1400052 [5] L. Taylor, R. Titmuss, and C. Lebre, “The challenges of seamless handover in future mobile multimedia networks,” IEEE Personal Communications, vol. 6, no. 2, pp. 32–37, Apr 1999. [6] A. Mishra, M. Shin, and W. Arbaugh, “An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process,” SIGCOMM Computer Communication Review, vol. 33, no. 2, pp. 93–102, Apr 2003. [7] J.-I. Kim, S.-J. Koh, N.-S. Ko, and S.-B. Hong, “PMIPv6 with Bicasting for IP Handover,” in Third International Conference on Convergence and Hybrid Information Technology, 2008 (ICCIT), vol. 1, Nov 2008, pp. 793–796. [8] X. Xu, Y. Cui, J. Liu, W. Wang, Y. Tan, G. Liu, and C. Zhu, “Seamless handover scheme for real-time multimedia services in PMIPv6,” in 8th International ICST Conference on Communications and Networking in China (CHINACOM), Aug 2013, pp. 834–839. [9] K. Nakauchi and Y. Shoji, “WiFi Network Virtualization to Control the Connectivity of a Target Service,” IEEE Transactions on Network and Service Management, vol. 12, no. 2, pp. 308–319, June 2015. [10] B. Sarikaya and X. Zheng, “CAPWAP Handover Protocol,” in IEEE International Conference on Communications (ICC), vol. 4, June 2006, pp. 1933–1938. [11] D. Kreutz, F. Ramos, P. Esteves Verissimo, C. Esteve Rothenberg, S. Azodolmolky, and S. Uhlig, “Software-Defined Networking: A Comprehensive Survey,” Proceedings of the IEEE, vol. 103, no. 1, pp. 14–76, Jan 2015. [12] ITU, “BT.500 : Methodology for the subjective assessment of the quality of television pictures,” January 2012. 49 [13] ITU, “P.800 : Methods for subjective determination of transmission quality,” August 1996. [14] ITU, “P.910 : Subjective video quality assessment methods for multimedia applications,” April 2008. [15] ITU, “P.913 : Methods for the subjective assessment of video quality, audio quality and audiovisual quality of Internet video and distribution quality television in any environment,” January 2014. [16] A. Chan, K. Zeng, P. Mohapatra, S.-J. Lee, and S. Banerjee, “Metrics for Evaluating Video Streaming Quality in Lossy IEEE 802.11 Wireless Networks,” in Proceedings of IEEE INFOCOM, March 2010, pp. 1–9. [17] G. Cunningham, P. Perry, J. Murphy, and L. Murphy, “Seamless Handover of IPTV Streams in a Wireless LAN Network,” IEEE Transactions on Broadcasting, vol. 55, no. 4, pp. 796–801, Dec 2009. [18] A. De La Oliva, A. Banchs, I. Soto, T. Melia, and A. Vidal, “An overview of IEEE 802.21: media-independent handover services,” IEEE Wireless Communications, vol. 15, no. 4, pp. 96–103, Aug 2008. [19] “IEEE Standard for Local and metropolitan area networks - Media Independent Handover Services,” IEEE Std 802.21-2008, pp. 1–0, Jan 2009. [20] R. Chandra, P. Bahl, and P. Bahl, “MultiNet: connecting to multiple IEEE 802.11 networks using a single wireless card,” in INFOCOM 2004. Twenty-third AnnualJoint Conference of the IEEE Computer and Communications Societies, vol. 2, March 2004, pp. 882–893 vol.2. [21] “IEEE Standard for Information Technology - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications,” IEEE Std 802.11-2007 (Revision of IEEE Std 802.11-1999), pp. 1– 1076, June 2007. ˘ [22] X. Yan, Y. Ahmet S¸ekercioglu, and S. Narayanan, “A Survey of Vertical Handover Decision Algorithms in Fourth Generation Heterogeneous Wireless Networks,” Computer Networks: The International Journal of Computer and Telecommunications Networking, vol. 54, no. 11, pp. 1848–1863, Aug. 2010. [Online]. Available: http://dx.doi.org/10.1016/j.comnet.2010.02.006 [23] M. Kassar, B. Kervella, and G. Pujolle, “An overview of vertical handover decision strategies in heterogeneous wireless networks,” Computer Communications, vol. 31, no. 10, pp. 2607–2620, Jun. 2008. [Online]. Available: http://dx.doi.org/10.1016/j. comcom.2008.01.044 [24] S. Kuklinski, Y. Li, and K. T. Dinh, “Handover management in SDN-based mobile networks,” in Globecom Workshops (GC Wkshps), 2014, Dec 2014, pp. 194–200. [25] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, “OpenFlow: Enabling Innovation in Campus Networks,” SIGCOMM Compututer Commununications Review, vol. 38, no. 2, pp. 69–74, Mar. 2008. [Online]. Available: http://doi.acm.org/10.1145/1355734.1355746 50 [26] M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown, and S. Shenker, “Ethane: Taking Control of the Enterprise,” in Proceedings of the 2007 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications (SIGCOMM), ser. SIGCOMM ’07. New York, NY, USA: ACM, 2007, pp. 1–12. [Online]. Available: http://doi.acm.org/10.1145/1282380.1282382 [27] Going with the flow: Googles secret switch to the next wave of networking. [Online]. Available: http://www.wired.com/2012/04/going-with-the-flow-google/ [28] J. Schulz-Zander, C. Mayer, B. Ciobotaru, S. Schmid, and A. Feldmann, “OpenSDWN: Programmatic Control over Home and Enterprise WiFi,” in Proceedings of the 1st ACM SIGCOMM Symposium on Software Defined Networking Research, ser. SOSR ’15. New York, NY, USA: ACM, 2015, pp. 16:1–16:12. [Online]. Available: http://doi.acm.org/10.1145/2774993.2775002 [29] J. Schulz-Zander, N. Sarrar, and S. Schmid, “Towards a Scalable and Near-sighted Control Plane Architecture for WiFi SDNs,” in Proceedings of the Third Workshop on Hot Topics in Software Defined Networking, ser. HotSDN ’14. New York, NY, USA: ACM, 2014, pp. 217–218. [Online]. Available: http://doi.acm.org/10.1145/2620728.2620772 [30] P. Dely, A. Kassler, L. Chow, N. Bambos, N. Bayer, H. Einsiedler, C. Peylo, D. Mellado, and M. Sanchez, “A software-defined networking approach for handover management with real-time video in WLANs,” Journal of Modern Transportation, vol. 21, no. 1, pp. 58–65, 2013. [Online]. Available: http://dx.doi.org/10.1007/s40534-013-0007-x [31] S. Kuklinski, Y. Li, and K. T. Dinh, “Handover management in SDN-based mobile networks,” in Globecom Workshops, Dec 2014, pp. 194–200. [32] D. Zhao, M. Zhu, and M. Xu, “Supporting ”One Big AP” illusion in enterprise WLAN: An SDN-based solution,” in 2014 Sixth International Conference on Wireless Communications and Signal Processing (WCSP), Oct 2014, pp. 1–6. [33] J. K. J. Arkko, B. Aboba and F. B. Ed., “RFC 5113: Network Discovery and Selection Problem,” RFC 5113, 2008. [34] M. Jain, J. I. Choi, T. Kim, D. Bharadia, S. Seth, K. Srinivasan, P. Levis, S. Katti, and P. Sinha, “Practical, Real-time, Full Duplex Wireless,” in Proceedings of the 17th Annual International Conference on Mobile Computing and Networking, ser. MobiCom ’11. New York, NY, USA: ACM, 2011, pp. 301–312. [Online]. Available: http://doi.acm.org/10.1145/2030613.2030647 [35] About openwrt. [Online]. Available: http://wiki.openwrt.org/about/start [36] Cisco, “Cisco high density experience,” Cisco Public., May 2015. [37] L. Prechelt, “An Empirical Comparison of Seven Programming Languages,” IEEE Computer, vol. 33, no. 10, pp. 23–29, Oct. 2000. [Online]. Available: http://dx.doi.org/10.1109/2.876288 [38] O. N. F. (ONF), “OpenFlow Switch Specification Version 1.3.0 (Wire Protocol 0x04),” June 25, 2012. [39] O. N. F. (ONF), “OpenFlow Switch Specification Version 1.5.0 (Wire Protocol 0x06),” December 19, 2014. [40] T. Rappaport, Wireless Communications: Principles and Practice, 2nd ed. River, NJ, USA: Prentice Hall PTR, 2001. 51 Upper Saddle 52 Appendix A Appendices A.1 OpenWrt Compilation A.1.1 TP-Link Archer C7 1. Install OpenWRT dependencies: $ apt−get install build−essential binutils flex bison autoconf gettext \ $ texinfo sharutils subversion libncurses5−dev ncurses−term zlib1g−dev gawk git− core 2. Download OpenWRT source $ git clone http://git . openwrt.org/14.07/openwrt.git 3. Configure the feeds of openwrt to install packages and add luci GUI $ cd openwrt $ mv feeds.conf.default feeds.conf $ ./ scripts /feeds update −a $ ./ scripts /feeds install −a $ ./ scripts /feeds install −a luci 4. Download CPqD Openflow source code and link packages into OpenWRT so it can be compiled $ git clone https://github.com/CPqD/openflow−openwrt.git $ cd package/ $ ln −s ../openflow−openwrt/openflow−1.3/ $ cd .. $ ln −s openflow−openwrt/openflow−1.3/files/ 5. Build OpenWRT with LuCI and OpenFlow $ make menuconfig $ # Select these options . To compile the image with the LuCI GUI and build it specifically for the Archer C7 $ [Target System: Atheros AR7xxx/AR9xxx] $ [Target Profile : TP−LINK Archer C5/C7] $ [LuCI −> Collections −> luci] # Press s to select it . Esc twice to back out to main screen $ [Network −> openflow...Open Flow 1.3 Switch Userspace Package] 53 $ # When exiting, make sure to save the new configuration ( press Y when the confirm dialog comes up) $ make A.1.2 Linksys WRT1900AC $ git clone https://github.com/openwrt−mirror/openwrt.git $ git clone https://github.com/openwrt−mirror/openwrt.git $ mv feeds.conf.default feeds.conf $ ./ scripts /feeds update −a $./ scripts /feeds install −a $./ scripts /feeds install −a luci $ $ $ $ $ git clone https://github.com/CPqD/openflow−openwrt.git cd package/ ln −s ../openflow−openwrt/openflow−1.3/ cd .. ln −s openflow−openwrt/openflow−1.3/files/ $ make menuconfig $ # Select these options . To compile the image with the LuCI GUI and build it specifically for the Archer C7 $ [Target System: Marvell Armada 37x/38x/XP] $ [Target Profile : Linksys WRT1900AC (Mamba)] $ [LuCI −> Collections −> luci] # Press s to select it . Esc twice to back out to main screen $ [Network −> openflow...Open Flow 1.3 Switch Userspace Package] $ # When exiting, make sure to save the new configuration ( press Y when the confirm dialog comes up) $ make A.2 OpenWrt Configuration A.2.1 Port Trunking Configuring the network settings as in A.2.2 for the OpenFlow creates the logical structure as in the Figure below. A.2.2 Network Configuration The configuration file is located at /etc/config/network Two different configurations were used. One for the standard IEEE 802.11 network and one for an OpenFlow network. OpenFlow: Router 1 54 config interface ’loopback’ option ifname ’lo ’ option proto ’ static ’ option ipaddr ’127.0.0.1’ option netmask ’255.0.0.0’ config interface option ifname ’wlan1−1’ option proto ’ static ’ option ipv6 ’0’ config interface ’lan’ option ifname ’eth0’ option force link ’1’ option type ’bridge’ option proto ’ static ’ option netmask ’255.255.255.0’ option ip6assign ’60’ option ipaddr ’192.168.1.1’ config interface ’wan’ option ifname ’eth1’ option orig ifname ’eth1’ option orig bridge ’ false ’ option proto ’ static ’ option netmask ’255.255.255.0’ option ipaddr ’192.168.2.1’ config interface ’wan6’ option ifname ’eth1’ option proto ’dhcpv6’ config switch option name ’switch0’ option reset ’1’ option enable vlan ’1’ config switch vlan option device ’switch0’ option vlan ’1’ option ports ’3 5’ option vid ’1’ config switch vlan option device ’switch0’ option vlan ’2’ option ports ’4 6’ option vid ’2’ config switch vlan 55 option device ’switch0’ option vlan ’3’ option ports ’0 5t ’ option vid ’3’ config switch vlan option device ’switch0’ option vlan ’4’ option ports ’1 5t ’ option vid ’4’ config switch vlan option device ’switch0’ option vlan ’5’ option ports ’2 5t ’ option vid ’5’ config interface option ifname ’eth0 .3’ option proto ’ static ’ option ipv6 ’0’ config interface option ifname ’eth0 .4’ option proto ’ static ’ option ipv6 ’0’ config interface option ifname ’eth0 .5’ option proto ’ static ’ option ipv6 ’0’ config route option interface ’wan’ option target ’192.168.2.1’ option netmask ’255.255.255.0’ Router 2 config interface ’loopback’ option ifname ’lo ’ option proto ’ static ’ option ipaddr ’127.0.0.1’ option netmask ’255.0.0.0’ config interface option ifname ’wlan1−1’ option proto ’ static ’ option ipv6 ’0’ 56 config interface ’lan’ option ifname ’eth0’ option force link ’1’ option type ’bridge’ option proto ’ static ’ option netmask ’255.255.255.0’ option ip6assign ’60’ option ipaddr ’192.168.1.2’ config interface ’wan’ option ifname ’eth1’ option orig ifname ’eth1’ option orig bridge ’ false ’ option proto ’ static ’ option netmask ’255.255.255.0’ option ipaddr ’192.168.2.2’ config interface ’wan6’ option ifname ’eth1’ option proto ’dhcpv6’ config switch option name ’switch0’ option reset ’1’ option enable vlan ’1’ config switch vlan option device ’switch0’ option vlan ’1’ option ports ’3 5’ option vid ’1’ config switch vlan option device ’switch0’ option vlan ’2’ option ports ’4 6’ option vid ’2’ config switch vlan option device ’switch0’ option vlan ’3’ option ports ’0 5t ’ option vid ’3’ config switch vlan option device ’switch0’ option vlan ’4’ option ports ’1 5t ’ option vid ’4’ 57 config switch vlan option device ’switch0’ option vlan ’5’ option ports ’2 5t ’ option vid ’5’ config interface option ifname ’eth0 .3’ option proto ’ static ’ option ipv6 ’0’ config interface option ifname ’eth0 .4’ option proto ’ static ’ option ipv6 ’0’ config interface option ifname ’eth0 .5’ option proto ’ static ’ option ipv6 ’0’ config route option interface ’wan’ option target ’192.168.2.1’ option netmask ’255.255.255.0’ Standard IEEE 802.11: Router 1 config interface ’loopback’ option ifname ’lo ’ option proto ’ static ’ option ipaddr ’127.0.0.1’ option netmask ’255.0.0.0’ config globals ’globals’ option ula prefix ’fd39:77aa:cf32 ::/48’ config interface ’lan’ option ifname ’eth1’ option force link ’1’ option type ’bridge’ option proto ’ static ’ option ipaddr ’192.168.1.1’ option netmask ’255.255.255.0’ option ip6assign ’60’ config interface ’wan’ option ifname ’eth0’ 58 option orig ifname ’eth0’ option orig bridge ’ false ’ option proto ’ static ’ option netmask ’255.255.255.0’ option ipaddr ’192.168.2.1’ config interface ’wan6’ option ifname ’eth0’ option proto ’dhcpv6’ config switch0 ’eth0’ option enable ’0’ option enable vlan ’0’ option reset ’1’ Router 2 config interface ’loopback’ option ifname ’lo ’ option proto ’ static ’ option ipaddr ’127.0.0.1’ option netmask ’255.0.0.0’ config globals ’globals’ option ula prefix ’fd39:77aa:cf32 ::/48’ config interface ’lan’ option ifname ’eth1’ option force link ’1’ option type ’bridge’ option proto ’ static ’ option ipaddr ’192.168.1.2’ option netmask ’255.255.255.0’ option ip6assign ’60’ config interface ’wan’ option ifname ’eth0’ option orig ifname ’eth0’ option orig bridge ’ false ’ option proto ’ static ’ option netmask ’255.255.255.0’ option ipaddr ’192.168.2.2’ config interface ’wan6’ option ifname ’eth0’ option proto ’dhcpv6’ config switch0 ’eth0’ option enable ’0’ option enable vlan ’0’ 59 option reset ’1’ config ’ofswitch’ option ’dp’ ’dp0’ option ’dpid’ ’000000000001’ option ’ofports’ ’eth0.3 eth0.4 eth0.5 wlan1−1’ option ’ ofctl ’ ’tcp :192.168.2.168:6633’ option ’mode’ ’outofband’ A.2.3 Wireless Configuration The configuration file is located at /etc/config/wireless config wifi −device ’radio0’ option type ’mac80211’ option channel ’36’ option hwmode ’11a’ option path ’soc/soc:pcie−controller/pci0000:00/0000:00:01.0/0000:01:00.0’ option htmode ’VHT80’ option country ’AU’ config wifi −iface ’wlan5’ option device ’radio0’ option network ’lan’ option mode ’ap’ option ssid ’OpenWrt’ option encryption ’none’ option disabled ’1’ config wifi −device ’radio1’ option type ’mac80211’ option hwmode ’11g’ option path ’soc/soc:pcie−controller/pci0000:00/0000:00:02.0/0000:02:00.0’ option country ’AU’ option txpower ’7’ option channel ’1’ config wifi −iface option device ’radio1’ option network ’lan’ option mode ’ap’ option ssid ’ Test LS’ option encryption ’psk2’ option key ’abc123456’ config wifi −iface option device ’radio1’ option ssid ’ Test LS’ 60 A.2.4 OpenFlow Configuration The configuration file is located at /etc/config/openflow config ’ofswitch’ option ’dp’ ’dp0’ option ’dpid’ ’000000000001’ option ’ofports’ ’eth0.3 eth0.4 eth0.5 wlan1−1’ option ’ ofctl ’ ’tcp :192.168.2.168:6633’ option ’mode’ ’outofband’ A.3 Running OpenFlow A.3.1 OpenFlow Functions OpenFlow will not run until functions.sh is linked into the /etc/ directory. The below commands needs to be be run to link the functions.sh file. $ cd /etc/ $ ln −s /lib/functions.sh A.3.2 Starting OpenFlow If a controller is not on and listing to connections when the AP is started up, OpenFlow needs to be restarted in order for a secure connection to the controller to be established. The below commands should be used to start OpenFlow. A controller needs to be already running for a connection to be established. $ /etc/init . d/openflow stop # To kill all current OpenFlow processes $ /etc/init . d/openflow start A.4 Experiment Code A.4.1 RSSI Client Logger Code package com.example.experimentlogger; import java.io . BufferedWriter; import java.io . File ; import java.io . FileNotFoundException; import java.io . FileWriter ; import java.io . IOException; import java. util . ArrayList; import java. util . Collections ; import java. util . Comparator; import java. util . List ; import android.support.v7.app.ActionBarActivity; import android.annotation.SuppressLint; import android.content.BroadcastReceiver; 61 import android.content.Context; import android.content.Intent; import android.content.IntentFilter ; import android.net.wifi.ScanResult; import android.net.wifi.WifiManager; import android.os.Bundle; import android.view.Menu; import android.view.MenuItem; import android.view.View; import android.widget.EditText; import android.widget.ProgressBar; import android.widget.TextView; import android.media.MediaPlayer; public class Scan extends ActionBarActivity { private WifiManager wifiManager; private WifiScanReceiver wifiReceiver; private WifiManager wifiLogManager; private WifiLogReceiver wifiLogReceiver; private private private private int distance; int numTimesToScan; int numScansDone; String ssid ; private MediaPlayer mp; private ArrayList scanResults; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity scan); // register wifiscanreceiver wifiReceiver = new WifiScanReceiver(); wifiLogReceiver = new WifiLogReceiver(); // initiate the progress par to zero makeProgressBar(); mp = MediaPlayer.create(this, R.raw.ding); } @Override public boolean onCreateOptionsMenu(Menu menu) { // Inflate the menu; this adds items to the action bar if it is present . getMenuInflater(). inflate (R.menu.scan, menu); return true; } 62 @Override public boolean onOptionsItemSelected(MenuItem item) { // Handle action bar item clicks here . The action bar will // automatically handle clicks on the Home/Up button, so long // as you specify a parent activity in AndroidManifest.xml. int id = item.getItemId(); if (id == R.id. action settings ) { return true; } return super.onOptionsItemSelected(item); } public void scanWifi(View view) { registerReceiver(wifiReceiver, new IntentFilter(WifiManager. SCAN RESULTS AVAILABLE ACTION)); wifiManager = (WifiManager) getSystemService(Context.WIFI SERVICE); wifiManager.startScan(); } public void logWifi(View view) { EditText distanceInput = (EditText) findViewById(R.id.distance); EditText samplesInput = (EditText) findViewById(R.id.samples); EditText ssidInput = (EditText) findViewById(R.id.ssid); EditText delayInput =(EditText) findViewById(R.id.delay); if (distanceInput.getText() . toString () . equals(””) || samplesInput.getText ().toString () . equals(””) || ssidInput.getText() . toString () . equals(””)) { TextView tv = (TextView)findViewById(R.id.textView2); tv . setText(”Please Fill in all above int fields !! ”) ; return; } // clear textview in case of error message above TextView tv = (TextView)findViewById(R.id.textView2); tv . setText(””) ; // obtain edittext information distance = Integer.parseInt(distanceInput.getText() . toString () ) ; numTimesToScan = Integer.parseInt(samplesInput.getText().toString()); numScansDone = 0; ssid = ssidInput.getText() . toString () ; scanResults = new ArrayList(); // check if delay needed. if textedit is empty, delay not needed. if (! delayInput.getText(). toString () . equals(””)){ try { Thread.sleep(Integer.parseInt(delayInput.getText(). toString () ) ∗ 1000); // 1000 milliseconds is one second . 63 } catch(InterruptedException ex) { Thread.currentThread().interrupt(); } } // register and start scan registerReceiver(wifiLogReceiver, new IntentFilter(WifiManager. SCAN RESULTS AVAILABLE ACTION)); wifiLogManager = (WifiManager) getSystemService(Context. WIFI SERVICE); wifiLogManager.startScan(); // reinitialise the progress bar to zero makeProgressBar(); } public void makeProgressBar(){ final ProgressBar pbar = (ProgressBar) findViewById(R.id.progressBar); pbar. setVisibility (View.VISIBLE); pbar.setMax(numTimesToScan); pbar.setProgress(0) ; } public void updateProgressBar(){ final ProgressBar pbar = (ProgressBar) findViewById(R.id.progressBar); runOnUiThread(new Runnable(){ public void run(){ pbar.setProgress(numScansDone); } }) ; } private void writeToFile(){ // no access points matching ssid found if (scanResults.size () == 0) return; try { boolean directory = new File(”/sdcard/Log/”).mkdir(); System.out.println(”Here ” + directory) ; File file = new File(”/sdcard/Log/” + distance + ” ” + numTimesToScan + ” ” + ssid + ”.csv”); BufferedWriter bw = new BufferedWriter(new FileWriter(file, false)); bw.write(”ssid,bssid,frequency,rssi\n”); // bw.write( txt ) ; String txt = ””; for(ScanResult s : scanResults){ 64 txt = s . SSID + ”,” + s . BSSID + ”,” + s . frequency + ”,” + s . level + ”\n”; TextView tv = (TextView)findViewById(R.id.textView2); bw.write(txt) ; } bw.flush(); bw.close() ; } catch (FileNotFoundException e) { // TODO Auto−generated catch block e.printStackTrace() ; } catch (IOException e) { // TODO Auto−generated catch block e.printStackTrace() ; } } class WifiScanReceiver extends BroadcastReceiver { @SuppressLint(”UseValueOf”) @Override public void onReceive(Context context, Intent intent ) { TextView tv = (TextView)findViewById(R.id.textView2); List wifiList = wifiManager.getScanResults(); String result = ””; wifiList = wifiManager.getScanResults(); Collections . sort ( wifiList , new Comparator(){ @Override public int compare(ScanResult lhs, ScanResult rhs) { // TODO Auto−generated method stub if (lhs . level > rhs.level ) return −1; else if (lhs . level < rhs.level ) return 1; return 0; } }) ; for(ScanResult s : wifiList ){ result += ”SSID: ” + s . SSID + ”\n” + ”BSSID: ” + s . BSSID + ”\n” + ”Capabilities : ” + s . capabilities + ”\ n” + ”Freq: ” + s . frequency + ”\n” + ”Level/RSSI: ” + s. level + ”\n\n”; } tv . setText( result ) ; 65 unregisterReceiver(wifiReceiver); } } class WifiLogReceiver extends BroadcastReceiver { @SuppressLint(”UseValueOf”) @Override public void onReceive(Context context, Intent intent ) { TextView tv = (TextView)findViewById(R.id.textView2); List wifiList = wifiLogManager.getScanResults(); // String result = tv . getText () . toString () + ”Scan Number: ” + numScansDone + ”\n”; String result = ””; wifiList = wifiLogManager.getScanResults(); ArrayList sr = new ArrayList(); for(ScanResult s : wifiList ){ if (s . SSID.equals(ssid)){ sr . add(s); } } Collections . sort (sr , new Comparator(){ @Override public int compare(ScanResult lhs, ScanResult rhs) { // TODO Auto−generated method stub if (lhs . level > rhs.level ) return −1; else if (lhs . level < rhs.level ) return 1; return 0; } }) ; for(ScanResult s : sr){ scanResults.add(s); } tv . setText( result ) ; numScansDone++; updateProgressBar(); System.out.println(”Calls ” + numScansDone); if (numScansDone < numTimesToScan){ wifiLogManager.startScan(); } 66 else if (numScansDone == numTimesToScan){ unregisterReceiver(wifiLogReceiver); writeToFile() ; mp.start() ; } } } } A.4.2 RSSI Network Code # !/ bin /sh distance=$1 samples=$2 rm −f ${distance} ${samples}.csv touch ${distance} ${samples}.csv for i in ‘seq $samples‘ do result =$(iwinfo wlan1 assoclist | grep ”64:89:9A:50:20:67” | sed ”s :[ dBm|ms|ago |/|(|)|SNR]::g”) echo $result | while read address dbm1 dbm2 snr rest do echo ”$address,$dbm1,$dbm2,$snr” >> ${distance} ${samples}.csv done sleep 1 done A.4.3 Throughput vs Distance Code distance=$1 filename=${distance}.txt if [ −e $filename ] then filename=filename=${distance} 1.txt fi iperf3 −s −J > $filename A.4.4 Changeover Experiment Logger Code 67 # !/ bin /bash separateAssocList(){ echo $assoclist | sed ’s :\( Pkts\.\) \([ˆ TX]\):Pkts.\n\2:g’ } folder=’./log/’ interface =$1 mac=$2 location=$3 filenamedate=$(date +%F %T ) prevrxpkts=−1 mkdir −p $folder echo ”timestamp,rssi,noise,snr,tx rate , rx rate , tx packets since , tx bytes since , rx packets since , rx bytes since , numclients,delay ms” > ${folder}${mac} ${location }.csv #${folder}${filenamedate} ${interface}.csv ipmap=$(cat /proc/net/arp | grep −i $mac) echo $ipmap ipaddr=${ipmap%% ∗} echo $ipaddr iperf3 −s −J > ${mac} iperf ${location}.txt & tcpdump −i $interface ether src $mac −w /log/${mac} ${location}.pcap & while true do pinged=$(ping −c 1 $ipaddr) &> /dev/null delay=$(echo $pinged | sed −e ’s/ˆ.∗time=//’ −e ’s/ ms.∗$//’) assoclist =$(iwinfo $interface assoclist ) numClients=$(separateAssocList | wc −l) matchMac=$(separateAssocList | grep −i $(echo $mac | sed ’s/\:/\\:/g’)) if [ ”$matchMac” ] then result =$(echo $matchMac | sed ”s:[dBm|ms|ago|/|(|)|SNR]::g”) tx=$(echo $matchMac | sed −e ’s/ˆ.∗RX\: //’ −e ’s/ MBit\/s.∗$//’) rx=$(echo $matchMac | sed −e ’s/ˆ.∗TX\: //’ −e ’s/ MBit\/s.∗$//’) echo $result | while read address dbm1 dbm2 snr rest do timestamp=$(date +%s) prevrates=$(luci−bwc −i $interface | grep −i $(expr $timestamp − 1) | sed −e ’s/\[//g’ −e ’s/\]//g’ −e ’s/\,//g’ −e ’s/ˆ ∗//’ −e ’s/ ∗$//’) 68 currrates=$(luci −bwc −i $interface | grep −i $timestamp | sed −e ’s/\[//g’ −e ’s/\]//g’ −e ’s/\,//g’ −e ’s/ˆ ∗//’ −e ’s/ ∗$ //’) echo $currrates | while read ts rxb rxp txb txp do echo $prevrates | while read tsp rxbp rxpp txbp txpp do if [ ! −z ”$currrates” ] && [ ! −z ” $prevrates” ] then txps=$(expr $txp − $txpp) txbs=$(expr $txb − $txbp) rxps=$(expr $rxp − $rxpp) rxbs=$(expr $rxb − $rxbp) if [ $rxbs −ne 0 ] then echo ”Monitoring Client MAC: $address RSSI: $dbm1 Noise: $dbm2 SNR: $snr TX: $tx RX: $rx TX Packets Since: $txps TX Bytes Since: $txbs RX Packets Since: $rxps RX Bytes Since: $rxbs No. Clients: $numClients Delay: $delay” echo ”$timestamp,$dbm1,$dbm2, $snr,$tx,$rx,$txps,$txbs,$rxps ,$rxbs,$numClients,$delay” >> ${folder}${mac} ${ location}.csv fi fi done done done fi sleep 1 done 69 Internal wlan1 VLAN 5 Port 3 VLAN 1 Port 4 VLAN 2 wlan0 VLAN 4 Port 2 Internet (wan) Switch VLAN 3 Port 1 1 truncked Port 0 2 To controller 3 Admin Port 4 OpenFlow Ports Physical (back of router) Port 5 Port 6 br-lan (eth0) br-wan (eth1) wlan0 wlan1 eth0.3 eth0.4 eth0.5 Controller OpenFlow (out of band) 70 Figure A.1: Logical Network Port Configuration