Introduction
1.1 Motivation
Safety is paramount, and there is no place where safety is more important than in the home. According to a 2017 crime statistics study conducted by the Federal Bureau of Investigation (FBI), there is a home burglary every 22.6 seconds in the US; on top of that, the average burglary victim loses over $2000 in goods [9]. Research has shown that home security systems are e↵ective in deterring burglars, as “83% [of burglars] admitted that they specifically look to see if there’s an alarm” and “60% would change their mind if there was one installed” [2]. These security systems also allow residents to monitor their property at all times and to contact the police if necessary, even while they are away. Currently, many security systems are integrating smart devices that rely on an Internet connection to inform residents in near real-time. However, the reliability of the Internet connection depends on the provider, electrical company, and the wear and tear of cables. Without an Internet connection, many of these devices lose core functionality.
1.2 Solution
Since all of these smart devices require an Internet connection to be useful, we created a smart connection monitoring and recovery agent that can be added to the home network to monitor connectivity and, in the case of disconnection, connect the smart devices to a backup Internet source. The smart connection monitoring agent is designed and implemented using a Kingdel Powerful Mini Desktop Computer, which acts as a middle-man to facilitate reliable connections between smart devices and the network it connects to. It automates a majority of the connection process so the user does not have to be concerned with technical details.
The PC is configured as a router and provides wireless internet to all devices connected to it. The PC also relies on multiple Internet sources to broadcast this connection. The system provides an accompanying web application that allows users to manage preferences if they are more familiar with the technical details of the connection process. The application can also be used to give relevant statistical data, such as network speed and status of Internet connections. Furthermore, the solution we created provides a much more ideal fallback plan when Internet connection is lost compared to current existing solutions. Overall, our product ensures that smart home security systems are more reliable and more secure, thus o↵ering greater safety and protection of persons and property.
1.3 Existing Solutions
1.3.1 Hardware Load Balancer
A load balancer is a hardware device that can distribute network trac to a number of connected devices [10]. These load balancers are traditionally used in cloud computing and to distribute this network trac to servers in a data center. This device can be used in a smaller scale as well and would be able to take multiple internet sources and distribute this trac to the connected devices.
The downside of load balancers are that they are expensive and do not provide the ability to choose the amount of Internet sources connected to the device itself [13]. Load balancers have a specific amount of Ethernet ports connected to them and there is no way to add more ports if more connections are needed. They are also costly as they are traditionally used in large scale cloud computing networks and therefore built with high end hardware that is not cheap and not accessible to the average individual.
1.3.2 Cellular Data
Cellular data is another backup plan option for an Internet outage. There are some services that provide backup cellular data to your home in the event of a home Internet outage.
While cellular data does do a good job at providing a reliable backup plan, it has its drawbacks as well. For starters, this requires additional hardware to be installed and configured in one’s home [3]. Cellular data is also not free, as it usually requires users to pay a monthly or yearly subscription for the services, and this can add up quickly over time [3]. Lastly, cellular data traditionally provides a much slower internet connection than what is provided by ISPs for home networks.
Requirements
2.1 Functional
2.1.1 Provide Internet in Case of Outage
In the case of an Internet outage, all devices that are connected to the router must be able to regain Internet connection. This connection comes from a backup Internet source (di↵erent than the home network).
2.1.2 Open Source
The proposed solution must be open source so that anyone can easily replicate or improve upon the work done and build this solution for themselves.
2.1.3 User Configuration and Monitoring
Users of the system must have the ability to choose the Internet sources that are used for the router and have control over which network to use at any given time. The user also needs to be able to see network statistics, such as bandwidth, and the current configuration of the system.
2.2 Non-functional
2.2.1 Ease of Use
The system should be easy for users to navigate and configure. The web application should be straightforward and should require little, if any, technical knowledge to understand or navigate.
2.2.2 A↵ordability
The system should be a↵ordable to consumers, particularly in comparison to competing load balancers and cellular data plans, and especially as a potential one-time purchase.
2.3 Design Constraints
2.3.1 Internet Bandwidth
Our solution uses a Raspberry Pi 4 as the access point for the system. Although the Raspberry Pi provides great
functionality for the price, the functionality is limited at times. The network card that is in the Raspberry Pi can only provide a certain speed when providing Internet access to the devices connected to it [17]. This can lead to slower network speeds because of the hardware being used.
2.3.2 Network Interface Card Requirements
The proposed solution can be run on all hardware, but that hardware must have a Network Interface Card (NIC) that is capable of broadcasting a wireless signal.
2.3.3 Wireless Network Interface Source
Open Virtual Switch is not compatible with wireless network interfaces being connected to its bridges and because of this, a workaround is needed. Our solution requires a separate piece of hardware to connect to a wireless Internet source and then feed that signal to the OvS bridge. In our implementation, that piece of hardware is a Raspberry Pi 4 [23].
System Architecture
3.1 Description of System Implemented
A high-level overview of our solution is shown in Figure 3.1. The ACAS system is composed of several parts. The
main component is our Kingdel Powerful Mini Desktop Computer, which acts as our router. There are several network interface ports on the ACAS system that are connected to di↵erent internet sources.
The router has Open vSwitch installed, which allows us to build a network bridge and add ports and bonds to the bridge so that it is possible to switch between the di↵erent Internet sources that a user’s device might be using. Thebond connects the multiple Internet sources together to act as a single port for a user’s devices to use. Ports are added to the Open vSwitch bridge to connect a user’s devices to the internet source being used.
Users can connect to the ACAS system through either Ethernet or Wi-Fi. If Wi-Fi is the preferred choice of connection, an access point built with the Raspberry Pi 4 Model B board must be used to provide Wi-Fi capabilities [15].
The ACAS system currently has the NGINX web server and web application running on the system itself. A user’s
device can connect to the web application by communicating with the NGINX web server via HTTP/S trac [30].
The web application uses Django, which is a Python based web application framework [6]. The ACAS web application utilizes Python’s available modules [20] to provide network and system statistics as well as the ability to configure the system. The speedtest-cli module is used to obtain upload and download speeds of the Internet source the ACAS system is currently using [16]. The web application also utilizes Python’s ability to run shell commands on the system to obtain information and configure the Open vSwitch bridge’s bond.
Technologies Used
4.1 Hardware
The system created requires a few forms of hardware to function correctly. The access point, router, and Wi-Fi sources in the system are three separate pieces of hardware that all connect to one another. Figure 4.1 demonstrates how these components are wired together to reflect the system architecture in Figure 3.1. The following sections describe each piece of hardware in more detail.
4.1.1 Router: Kingdel Powerful Mini Desktop Computer
The Kingdel Powerful Mini Desktop Computer is used to build a router that runs the Open vSwitch software, OpenFlow Protocol, an NGINX web server, and a Django web application.
4.1.2 Access Point: Raspberry Pi 4 Model B
A Raspberry Pi 4 Model B is used as the access point for the router and therefore provides Internet connection to any device connected to it [15]. A second Raspberry Pi 4 Model B is used as a wireless Internet source for the router [23].
4.2 Software
The following sections describe the software components used in the system.
4.2.1 Open vSwitch
The Open vSwitch software is used to connect the user’s home devices to the di↵erent Internet sources. The two main aspects of OvS that are used are bridges and bonds. OvS bridges connect multiple physical network interfaces on the PC. OvS bonds allow two or more network interfaces to be treated as one port [25].
4.2.2 OpenFlow Protocol
The OpenFlow protocol controls network flow throughout the PC and more specifically across the OvS bridge [27]. This protocol ensures that the network trac flows from the Internet sources to the access point in our system.
4.2.3 NGINX Web Server
The NGINX web server is used to connect the user to our web application via HTTP/S [30].
4.2.4 Python
Python is a powerful programming language [21] that utilizes modules [20] that are used in the ACAS system to run shell commands to gather system and network statistics as well as configure the router’s Open vSwitch settings [16].
4.2.5 Django
Django is a Python-based web framework [6] that is used to build our web application to gather system and network statistics, as well as configure the ACAS system.
Design Rationale
5.1 Hardware Design
The hardware used for the system was chosen such that a reliable system could be created at a reasonable cost for a consumer.
5.1.1 Kingdel Powerful Mini Desktop Computer
The Kingdel mini PC is used to run OvS and OpenFlow and control packet flow throughout the system. While many hardware systems can handle this work load, the Kingdel PC is powerful enough to handle all of this without any issue and allows for a more scalable design over something with much less power. The Kingdel PC also has an x86 Intel CPU architecture that allows the PC to run Linux, more specifically Ubuntu, which was necessary for the system. OvS and OpenFlow both run on Linux based machines and the Kingdel PC was able to provide the correct operating system.
5.1.2 Raspberry Pi 4 Model B
A Raspberry Pi 4 Model B is used in two di↵erent ways in the system. One use case is as the access point [15]. The Raspberry Pi provides a wireless network signal to all devices connected to it. A Raspberry Pi 4 was chosen for this application because of the price to performance ratio. While a Raspberry Pi 4 is not the most powerful machine, it is able to provide a reliable Internet connection for a reasonable price. The second application of a Raspberry Pi 4 Model B is for a wireless network source for the router [23]. This Raspberry Pi connects to the Internet and in turn, provides a connection to the second Raspberry Pi that then outputs that network signal. In this case, a Raspberry Pi was also chosen because of its price to performance ratio, as it is able to provide the required performance for a reasonable cost [17]. Furthermore, Raspberry Pis have a Linux based operating system that allowed for the boards to be used for both applications within the system. See Appendix B on how to setup the Raspberry Pi 4s for the system.
5.2 Back-end Design
The back-end components of the ACAS system were chosen so that the system statistical information and configurations can be delivered to the user and system eciently and e↵ectively.
5.2.1 Open vSwitch
Open vSwitch is an open source virtual switch software that runs on Linux and provides control of packet switching within the operating system [5]. OvS was chosen to provide the packet switching over Linux switching features for a few main reasons. First of all, OvS is used in large scale productions and is therefore scalable and proven to handle large workflows. OvS also provides the ability to easily see network statistics and status on the switch itself. OvS also provides a bond feature that was instrumental in the completion of the system, but this was not the only OvS feature used. The two main features of OvS that were used are bridges and bonds [28]. See Appendix A on how to install Open vSwitch on any x86 machine.
Bond
An OvS bond allows two or more network interfaces to share network trac and act as a single port [25]. This allows our router to have multiple Internet sources connected to a bond at any given time. OvS bonding also has protocols attached to each bond that control the balancing of the bond [19]. The bond mode that was used in our system was the active backup protocol. This allows the bond to use one of many Internet sources at a time and switch over to another Internet source in the event of an outage. See Appendix A on how to work with OvS bonds.
5.2.2 OpenFlow Protocol
OpenFlow is a programmable network protocol that is designed to control network trac across a router and/or switch. OpenFlow runs on top of OvS and consists of three parts: flow tables, a controller, and an OpenFlow protocol [7]. The flow tables are setup on the switch itself and define what happens to packets when they enter/exit a switch. A controller is the software that talks to the switch, and the OpenFlow protocol is what enforces certain rules on network flow within a flow table [7].
All of these parts were used in ACAS in conjunction with OvS. While OvS connects network interfaces to ports
on the network bridge, OpenFlow controls the network trac flowing between these ports on the network bridge itself. OpenFlow ensures that the system forwards packets from the OvS bond (internet sources) to the OvS port (access point) and then back the same way for returning packets. Without using OpenFlow and a controller, there would be no way to ensure that packets are flowing correctly across the bridge and would result in an unstable system.
5.2.3 Web Application
NGINX Web Server
For users to communicate with our Django web application, our ACAS system needs to provide a web server. The web server allows users to connect to our web application through HTTP/S trac [30]. The exchange between HTTP requests and responses allows the user to get information about the ACAS system as well as configure the system’s settings. See Appendix B on how to install NGINX Web Server.
The web server we decided to utilize to allow users to connect to our web application is an NGINX web server.
We decided to utilize an NGINX web server over an Apache web server because it had similar or better performance statistics when delivering static and dynamic content to a user’s web browser. In terms of dynamic content, both NGINX and Apache web servers had similar performance statistics when delivering dynamic content. In terms of static content, an NGINX web server is able to deliver static content about 2 to 2.5 times faster than an Apache web server [14].
Django: Python
The ACAS web application was built using Django’s Python-based web application framework [6]. Python is a powerful language [21] that allows us to run shell commands on the ACAS system to gather system statistics on the Open vSwitch configuration, specifically the bond used to connect multiple internet sources and the port statuses for each of the internet sources connected to our system. Possible port statuses that are shown on the system are available and unavailable, which means that the internet source is ready or not ready to be used. Another port status that is shown is which port is the active slave. The active slave status is given to the port that the user’s home devices are currently.
using to get Internet access [12]. See Appendix D on the specifics of how Python was utilized.
Python also allows us to use developed modules that provide network statistics of our ACAS system. One module that we used is the speed test command line interface (speedtest-cli). The speed test module allows us to run speed tests to gather upload and download speeds [16].
With the various information Python is able to gather about the ACAS system, we can then use this information
to display it to the user on the web application.
5.3 Front-end Design
5.3.1 Web Application
Django: HTML and CSS
Since Django is used for the back-end of the web application, the front-end follows suit and utilizes Django’s builtin template language to create web pages in HTML and CSS. For the purposes of displaying network statistics and port statuses, as well as basic network configuring capabilities, we determined that it was not necessary to use more powerful frameworks like React.
User Experience and Visual Design
Although user experience and visual design were not considered priorities, several e↵orts were made to ensure the usability of the web application. Open Sans is the font used in the web application, as it is a highly legible and versatile font, particularly suited for prolonged reading on both mobile and web interfaces [11]. It is also suited for use in body text, titles, and other design elements [22]. Additionally, the font is visually simple, professional, and friendly—all characteristics we want associated with ACAS.
The web application also features a monochromatic color scheme with blue as the dominant color. 51% of the most valuable brands and logos use a monochromatic color scheme, and over 35% use the color blue [18]. Blue tends to facilitate a sense of trust, security, and dependability—again, all characteristics that would be beneficial for ACAS to be associated with [18]. Blue also tends to be a universally favored color, commonly liked across genders and age groups [18].
According to WCAG (Web Content Accessibility Guidelines) 2.0, there should be sucient contrast between text
color and background color. The minimum color contrast ratio is 4.5:1, with a preferred color contrast ratio of 7:1 [29]. From an accessibility standpoint, following WCAG guidelines helps people with low contrast sensitivity, which is common in older people, as well as people with color blindness [1]. There are several additional usability benefits as well; content tends to remain readable under di↵erent lighting conditions and becomes more legible for everyone, even for those without specific visual requirements [1]. ACAS’s web application adheres by these guidelines, achieving more than the preferred 7:1 color contrast ratio whenever text color and background color are concerned. These user experience and visual design considerations make ACAS highly suited for extension and elaboration in the future.
Testing
6.1 Plan
The most important aspect of the system is functioning as the backup plan if a user’s home Internet loses connection for any reason. Our system recognizes when a current connection goes down and then switches to a backup connection. This act of switching between networks does not happen instantly—there is a delay between when a network loses connection and when the backup network is used to give Internet to the access point. This Internet downtime delay was tested. Tests were conducted on the full system with one device connected to the access point of the router. There were two Internet sources connected to the router, one being a home network and the other a public Wi-Fi network. We had a laptop connected to the access point and opened a console and pinged the Internet. We then went to the router and simply unplugged the current active Internet source to simulate an Internet outage. During this time, the laptop continued to ping the Internet and stopped being able to ping when the Internet source was unplugged. After some time, the laptop would be able to ping the Internet once again. The delay when the laptop was unable to ping was timed and the results are shown in Figure 6.1.
6.2 Results
Figure 6.1 shows the results of our experiments. There were ten trials so that an average length of downtime when switching from one Internet source to the next could be calculated. As can be seen from the graph, our system takes somewhere between 15 and 20 seconds to recognize an outage and switch Internet sources, with an average of 17.16 seconds. This slight delay in response time is due to a handful of factors. Firstly, the OvS bond has to recognize that the active connection is down and most likely will not reconnect. The OvS bond also has to determine which of the backup sources (if there is more than one backup) to choose and make sure that this source does indeed have an active
Internet connection. Finally, OvS has to do the switching itself and forward all network trac through the new active source, rather than the original source. All of these factors play a role in the time delay that is seen in Figure 6.1.
