An Extensible Home Automation Architecture based ...

An Extensible Home Automation Architecture based on Cloud Offloading Yuichi Igarashi

Matti Hiltunen, Kaustubh Joshi, and Richard Schlichting

Hitachi, Ltd., Research & Development Group, Center for Technology Innovation – Systems Engineering Email: [email protected]

AT&T Labs – Research Email: {hiltunen,kaustubh,rick}@research.att.com

Abstract—Current home security and automation systems are typically structured as a collection of sensors and actuators connected to a local home controller. While new and more capable sensors are driving increasingly sophisticated applications such as video surveillance that require significant computing resources, home controllers are often resource-constrained devices that are not easy to upgrade or replace at scale. To address these limitations, we present a new Cloud-Enhanced Home Controller (CEHC) architecture where the resources of the local home controller are augmented with external cloud resources accessed over the network. While such cloud offloading has been studied in the context of other resource-constrained devices such as mobile phones, we posit that home control applications pose a new set of requirements unique to this domain. Here, we describe these requirements, propose an application ecosystem that enables the seamless use of both local and remote resources, and describe a decision engine that schedules applications under constraints imposed by the home controller, the network, and the costs associated with the cloud service provider. Keywords—Cloud; Offload; Home automation; Application ecosystem;

I.

I NTRODUCTION

While home automation and smart spaces have had a long history with enthusiasts and a presence in the academic literature since at least the late 90s [1]–[3], it is only recently that the area has seen commercial offerings at scale, mainly from telecom providers and cable operators, e.g., [4]. Such systems typically consist of a home controller that various sensors and actuators in the home connect to, and on which home automation applications run. Such a platform is a natural hub for much of the digital activity in the home, and it is easy to imagine it hosting a rich array of sensors and actuators, as well as compelling applications ranging from home security and energy management to assistance for aging in place. However, while a home controller can serve as a unifying device around which a flexible ecosystem could be built, we postulate that its potential is yet to be unleashed. A critical aspect is the flexibility of the home controller itself. Unlike consumer portable devices (e.g., mobile phones and tablets) that are intensely personal devices that users are incentivized to upgrade frequently, home controllers are associated with homes and, once installed, are difficult and expensive to upgrade at scale. Therefore, service providers are left with a difficult choice of how to balance the computing power of a controller (and thus its cost) with the wide array of current and future uses that may be vastly different for different homes.

At issue is the reality that the resource requirements for various home automation applications can vary widely. A simple passcode-based door lock application requires very few resources to manage, while a door lock application equipped with a front-door camera and face recognition system requires significantly more. (See Section IV for some measurements.) Provisioning all home controllers for the latter use case makes the service more expensive for everyone, while provisioning for the former locks out the more advanced users. The problem becomes worse when all combinations of applications that the controller might be called on to support concurrently are considered. It is little wonder that in today’s home automation marketplace, service providers have to make decisions on what services can or cannot be supported a priori. The result is less opportunity for everyone: service providers who have to pick winners and losers with little a priori information about which applications will be popular, users that are limited to service provider choices, and third party developers who are locked out altogether. We contend that this area is ripe for “cloudification”. We propose making the home controller a truly flexible platform device by allowing its application hosting capabilities to be extended by cloud resources. With this approach, applications run on the controller box when they can, and then partially or fully migrate to a cloud virtual machine as and when needed. This allows home controllers to be provisioned more conservatively, while providing a built-in ability to cope with new applications as they emerge. The first contribution of this paper is to propose exactly such a cloud-enhanced home controller architecture. This includes supporting platform services, and a novel application design paradigm where applications are designed to operate in three possible modes: completely at the home controller, mostly in the cloud, and in a degraded mode when the cloud or network is unavailable. The second contribution is a systemwide scheduler (SWiS) that determines the optimal placement for a given set of applications on the home controller and in the cloud. Finally, we validate the architecture using a number of realistic home control applications constructed for this platform. II.

R EQUIREMENTS AND CHALLENGES

Home automation applications such as home energy management and home monitoring are gaining increasing interest, both in terms of actual deployments and within standards

organizations [5]. One driver is that the suite of controllable network devices for the home—temperature sensors, remote switches, door locks, lights, and cameras—is expanding rapidly. Home controllers typically communicate with these devices wirelessly through a USB interface, e.g., using a ZWave USB dongle or a ZigBee USB dongle. Advances have also been made in the area of operating systems specifically for home automation, such as the HomeOS [6]. HomeOS handles network devices as peripherals with abstract interfaces, simplifies the development of applications by providing higher-level abstractions, and gives users a management interface designed for the home environment. The aim of these technologies is to extend capabilities in the home easily by adding new devices and applications. With the increased range of possible home devices and applications that these devices enable (e.g., recognition of residents based on camera image and automatic unlocking of doors), the home automation system has to manage multiple applications at the same time. For example, energy management, monitoring inside and outside of the home (motion sensors, cameras), and automatic locking and unlocking of doors may all be running concurrently. As a result, a resourceconstrained home controller can quickly become a bottleneck to achieving this richer experience. For example, in [7] we showed that an application that uses a single web camera to monitor a home or its surroundings can consume 20 40% of the CPU resources of a typical home controller. Given this, when a monitoring application uses multiple cameras, the quality is poor and the application does not execute smoothly due to insufficient CPU resources. Resource limitiations become even more problematical when multiple home control applications of different types execute on the same home controller. Cloud computing offers an appealing solution when additional resources are required to augment a company’s or user’s computing resources. While various cloud computing techniques such as code-offloading and parallel processing have been proposed to address similar issues for mobile devices [8] [9] [10] [11], home automation has many unique characteristics that differ from the mobile computing scenario. Three in particular stand out [7]. First, home automation applications are in a sense easier to offload since they are not as interactive as the mobile applications typically used to motivate code offloading. Home applications normally gather information periodically from sensors, actuators, and cameras, and analyze and react to the data automatically, requiring less human interaction than, for example, gaming on mobile phone. Therefore, it is often possible to execute the bulk of the application in the cloud versus the home element. For the mobile computing use cases, in contrast, the control of the application remains on the mobile device and the cloud is simply used as an extra computational resource. Second, many home automation applications provide critical safety-related functionality, such as alarming for smoke, fire, or physical intrusions, and automatic door locking. As a result, they must continue to provide service—potentially in a degraded mode—even if network connectivity to the cloud server is lost accidentally or compromised intentionally through a physical cable cut or a DDoS attack against the cloud server. This means that it is often not feasible to move

!"#$! !"#$% &'$#$()!

*'"+,%!

-$)."/0!

*'"+,% &'$#$()! !"#$%*"()/"''$/!

!"#$%1$234$565$(5"/5%7(,%74)+7)"/58! Fig. 1.

Cloud-Enhanced Home Controller.

an entire application completely to the cloud. At the minimum, the application must have a degraded mode version that can run on the local home controller and the home controller must detect the network disconnection and execute the application’s local version. Finally, a home automation system often runs multiple applications for different home functions and multiple users at the same time. Hence, the runtime system has to determine which applications should run on the home controller and which on the cloud server. Mobile code offloading solutions are not designed for multiple applications potentially belonging to multiple users running continuously. III.

CEHC

A. Overview Most current home automation systems are Local Home Controller systems in which all applications run on the local controller at home. However, the local controller may become a resource bottleneck. Therefore, we propose a new approach called the Cloud-Enhanced Home Controller (CEHC) architecture. In this architecture (Figure 1), the home devices (sensors and actuators) connect with a home controller element (HE), while a cloud element (CE) is located remotely in an Internet data center and can be used to enhance the capabilities of the HE. The HE, CE, and the network connecting the HE and CE are all treated as system resources and considered holistically when doing placement and scheduling decisions. Applications can be run on either the HE or CE, or, more commonly, have their functionality split across the two. Each application will typically provide a choice of operating modes, at the minimum a cloud-enhanced one that takes advantage of the cloud resources and a home-only version to allow automation applications to execute even when the cloud or network are not available. The different operating modes utilize differently the resources of the CEHC including HE, CE, and the connecting network, see Figure 2. The figure shows alternative operating modes of an application ranging from two home-only modes (full features and degraded) and a choice of cloud-enhanced modes ranging from running the whole application in the cloud (input/output directly forwarded through the HE) to different distributed placement of application functions. The CEHC platform provides a number of services for the home automation applications, including failure detection (checking connectivity between the HE and the CE), data transfer, synchronization, and a scheduler that allocates home automation applications over the distributed platform consisting of the HE, CE and the network. For applications that

systems, the functions may be implemented by the same software component on both platforms. Home-only! modes

•

Shared inputs. Different home control applications may operate on the same sensor inputs. For example, the video stream from a camera can be used to detect motion (burglar alarm) and identify people (automatic door lock), as well as be recorded for remote viewing at later time. Given multiple uses of the input, it optimizes both resource use and potential cloud cost to transport it only once across the network and share it among the applications rather than transporting it multiple times.

•

Multiple Levels of QoS. The different operating modes consume different amounts of resources at the HE, CE, and network, and also provide different levels of QoS to the home residents. Optimizing the tradeoff between the QoS and resource consumption by different applications sharing the same CEHC platform is a difficult but important issue.

Cloud-enhanced modes Failure%Detec3on,%Scheduling%(SWiS),%% Data%Transfer,%State%Synchroniza3on

Fig. 2.

Application design choices and supporting platform services

require state synchronization between the parts at home and in the cloud, we provide a shared object abstraction implemented by running Zookeeper [12] both at the CE and HE. For data transfer, we provide a number of choices at the platform level and, in addition, applications may choose to use their own data transfer mechanism as illustrated with the example applications below. Specifically, the input and output from USB-based sensors and actuators can be transferred directly to the application running on the CE using USB/IP [13]. In our prior work, we demonstrated that USB/IP from the HE to the CE can be used for sensors and actuators with low I/O throughput but not for high throughput sensors such as video cameras [7]. Similarly, iptables can be used to direct IP based communication from the HE to the CE transparently, as we illustrate with our third example application below. B. Application design Home automation applications designed for CEHC have a number of special characteristics:

Our example applications in this paper have at most three operating modes based on which functions run on the HE and which on the CE. Specifically, the first mode (Home Mode) is when all the application functions run on the HE and the application provides full QoS for users. The second mode (Cloud Mode) is when some functions run on the HE and others on the CE, and together they provide full QoS similar to Home Mode. The final mode (Degraded Mode) is when there is a reduced-functionality version of the application that runs on the HE. Note that Degraded Mode could be used in the case the application is executing in Cloud Mode but the network or the CE becomes disconnected. Alternatively, Degraded Mode could be used for some applications when the HE is too overloaded to accommodate a full Home Mode of an application. C. Example applications

•

Multiple operating modes. An application that runs in the cloud must also have an operating mode (potentially degraded) that can be run on the HE in the event that the network is down or the cloud is down or otherwise unreachable. Additional operating modes provide different tradeoffs between quality of service and the resource consumption of the different CEHC resources.

•

Distributed. Given that the home control application gets its inputs from the sensors in the home and effects control through the actuators in the home, a CEHC application typically consists of parts that execute at the HE and parts that execute in the cloud. For example, it may not be possible to forward a full video stream from the home to the cloud, and thus the application may need to compress or preprocess the camera input at the HE before it is forwarded to the CE for further processing. As noted above, some applications can be run fully in the cloud using our transport mechanisms such as USB/IP and iptables configuration.

We use three example home automation applications in this paper. The first is a door lock application (Application 1). The application captures video using a front-door camera when visitors or residents come to the house, and then unlocks the door automatically depending on the results of face recognition. It must be possible to lock and unlock door even if the CE is unavailable or the HE is overloaded by other applications. Therefore, the application has a degraded mode where the door is unlocked manually. This application has three modes, as shown in Figure 3. Each box in the figure denotes one function (e.g., Capture video, Recognize faces) and the functions used in each mode of the application are denoted by the grouping of the functions using shading or solid and dotted lines. For example, the Cloud Mode of this application consists of Capture Video and Lock/unlock functions running on the HE, and Save Video/photo, Detect faces, and Recognize faces functions running on the CE. The Transfer Video/photo and Share result functions depicted on the line between the home and cloud elements denote data transfer.

•

Movable functions. The same application functions may be executed at the CE or the HE based on availability of resources. If the HE and CE run compatible

This application, as well as the other example applications, were implemented primarily using existing off-the-shelf components. For example, M-JPEG streamer [14] was used for

08/14/2014

Applica0on':'Remote'Monitorin Applica0on':'Lock/Unlock'doors' Cloud Element

Lock/unlock!

Encode/! decode!

Recognize! faces! Detect! faces!

Save! Video/photo!

Upload video! to local Server!

Encode/! decode!

Transfer ! Video/photo!

Cloud Mode!

Encode/! decode!

Capture! video!

Cloud Mode!

Applica0on':'Safe'Internet'fo USB Camera

Capture! video!

Fig. 4.

Application 2: Remote monitoring.

Cloud Element

USB Camera

Fig. 3.

Save! photos!

Transfer ! Video/photo!

Detect! faces! Save! Video/photo!

Upload video to! Web server!

Home Mode!

Home Mode!

Recognize! faces!

Upload video to Web server!

Lock/Unlock manually!

Share! result!

Home Element

Degraded Mode!

Home Element

Cloud Element

Home Element

(Web services)

(Web services)

Web Proxy! (kidssafe & apache)!

Web Proxy! (kidssafe & apache)!

Application 1: Door lock application.

capturing video at home. It captures a video and automatically generates a web page from which the video can be viewed. We use wget to fetch the video from the HE to the CE and FFmpeg [15] to change formats of the captured video from jpeg to mp4 on the CE. Face detection from video is implemented using OpenCV. The face recognition and actual unlocking of the door has not been implemented. In our implementation, the Home Mode of the application captures movie on the HE and at the same time, does face detection. For the Cloud Mode, M-JPEG streamer captures the video, wget transfers the video to the CE, FFmpeg changes the formats, and face detection is done on the mp4 video. Therefore, the Cloud Mode of the application introduces higher latency than the Home Mode. The second application is remote monitoring (Application 2). This application capture a video or pictures using a camera in order to monitor pets or residents remotely. When the network is disconnected, this application has to be able to save information for later viewing. Hence, is also has three modes as shown in Figure 4. Similar to the first application, we use M-JPEG streamer for remote monitoring. The final application is a ”safe internet for kids” application (Application 3). This application provides a web proxy function that can be configured so that children using tablets can connect only to safe web pages. Some web proxies store all logs, which makes cloud off-loading an attractive option given the limited storage usually found on HEs. Note that there is no need for degraded mode since children will be unable to surf when the network is disconnected. Hence, the safe internet for kids applications has two modes as shown in Figure 5. We use Squid [16] as the web proxy in both the Home and Cloud modes of this application. For the Cloud Mode, we modify iptables to transfer all packets that are related to internet surfing from the HE to the CE.

Home Mode! Packet! Tunneling!

Cloud Mode!

Tablets

Fig. 5.

Application 3: Safe internet for kids.

IV.

S YSTEM - WIDE SCHEDULER (SW I S)

Scheduling a set of applications for a home means deciding the operating mode for each of the chosen set of applications. This scheduling choice determines the QoS each application will provide to the users, as well as the resource usage at HE, CE, and the network connecting them. The home user will want to maximize the quality of service of their home control applications while still being cognizant of network bandwidth usage since the network connection to the home is shared with other activities (e.g., streaming movies, web browsing). The home automation service provider will want to minimize its own costs (e.g., networking, cloud computing cost) while satisfying the quality of service requirements for customers. The SWiS scheduler decides the modes of all applications installed on the CEHC based on factors such as the CPU load of the HE, the memory consumption of the HE, the CPU load of the CE, the memory consumption of the CE, network bandwidth, and the cost of the CE. To determine the operating modes of each of the applications, the SWiS scheduler needs to know about the resource consumption of the different application modes. We assume that the compute

Input(1)

Input(2)

Application Config lists 1.  Local (Normal) 2.  Local (Minimum set) 3.  Remote

Input(3) Resources requirements

HE CPU

Cost estimation CE

MEM

NW

CPU

MEM

Step1.

Cloud

NW

Input(4)

Allpattern patternlist list All List of all patterns

Threshold of all requirements

Step2.

Input(5)

Executablepattern patternlist list Executable

Priority Rules

Step3. Output

Fig. 6.

Sorted pattern list

SWiS ranking algorithm Input(1) New Application Config list 1.  Local (Normal) 2.  Local (Minimum set) 3.  Remote

Input(2)

Input(3) Resources requirements

HE CPU

Cost estimation CE

MEM

NW

CPU

MEM

Cloud

NW

Input(4) Input(6)

Threshold of all requirements

Executable pattern list (Existed list)

Step1. Input(5) Executablepattern pattern Executable list(new) list(new)

Priority Rules

Step2. Output

Fig. 7.

Sorted pattern list

Adding a new application

resources and network bandwidth required by all modes of an application are known before installation. These metrics could be given, for example, by the home automation application provider, perhaps using an app store model like Apple or Google [17], [18]. The information is used by the SWiS to decide which mode is most suitable for a given scenario. To address these goals, we propose an approach for deciding the operating modes for each application using a ranking algorithm, as follows. Ranking algorithm The ranking algorithm used by SWiS creates a pattern list, as shown in Figure 6. The algorithm has five inputs: 1) 2) 3) 4) 5)

Configuration lists that capture the possible modes of each application, provided along with the application. Resources requirement for each mode of each application, provided along with the application. Cost estimates associated with increasing the resources of the HE and/or the CE, derived from information given by the service provider. Maximum allowable resource usages (e.g., 80% CPU load at the HE, 50% network utilization). Relative priority of requirements (CPU load of CE, memory consumption of CE, CPU load of HE, memory consumption of HE, network bandwidth or latency).

The output is a list of configuration patterns that gives modes for each application ordered by the relative priorities, such that total resources used by all applications do not exceed the maximum on the HE or the network. The ranking algorithm is essentially a simple exhaustive search across the feasible combination of modes for all applications using the following steps. Step(1): SWiS makes a list of all combinations of patterns for all modes of all installed applications, and calculates the resources required to execute each pattern. At this point, the list has at most 3n patterns, where n is the number of installed applications. Step(2): SWiS checks each pattern to determine whether all applications are executable or not. If any of the required resources for the application modes exceed the thresholds, that pattern is infeasible and deleted from the list. The pattern is never used again even if new applications are installed. Step(3): SWiS sorts all patterns in the list according to priority rules, and selects the pattern of application modes with the highest priority. If priority rules change, e.g., the highest priority is changed from the HE’s CPU load to the CE’s CPU load, the decision may change. When new applications are installed, SWiS calculates the list again according to a simplified algorithm described in Figure 7. Step(1): SWiS makes patterns for the new applications and adds these to the current list made in Step(2) of Figure 6. Then, infeasible patterns are again deleted from the updated list as in Step(2) of Figure 6. Step(2): SWiS sorts the pattern list according to priority rules using the same procedure as in Step(3) of Figure 6. As before, the pattern of application modes with the highest priority is selected. If an application is deleted, SWiS updates the list again according to the algorithm in Figure 6. Other applications can continue to be executed at the same level of service, of course, so the list does not need to be updated immediately. Dynamic updating SWiS monitors resources such as CPU load, memory consumption, and network bandwidth, and can change the selected pattern as conditions evolve. In some situations, this is necessary to avoid overload, while in others it would just help align resource utilization more closely with conditions. A complete network disconnection would also be handled using this mechanism. In this case, all patterns that use the CE would be declared infeasible, leading automatically to the best solution using only local resources on the HE. In particular, applications would be switched to Home Mode that provides full functionality locally at the HE or to Degraded Mode that provides reduced functionality. The priority rules would dictate the choices.

08/14/2014

Fig.8(a)

06/23/2015

Fig.8(b)

lock/unlock(a(door(

lock/unlock(a(door(

Home Mode: CPU load of HE!

100

Cloud Mode: CPU load of HE!

40

20

80

60

40

53:30 5

53:35 10

53:40 15

53:45 20

53:50 25

53:55 30

54:00 35

54:05 40

54:10 45

54:15 50

54:20 55

Execution Time [sec]!

Fig. 8.

60

40

20

20

0 53:25  0

0 06:05  0

06:10 5

06:15 10

06:20 15

06:25 20

06:30 25

06:35 30

06:40 35

06:45 40

06:50 45

06:55 50

07:00 55

07:05

0 09:00  0

Execution Time [sec]!

5

09:10 10

15

09:20 20

25

09:30 30

35

09:40 40

45

09:50 50

55

10:00 60

65

10:10

Execution Time [sec]!

Results of door lock application (Application 1) in Home Mode and Cloud Mode TABLE I.

Appl

mode

1

home cloud degraded home cloud degraded home cloud

2 3

TABLE II.

A PPLICATION RESOURCE CONSUMPTION Resources ( Average ) HE[%] CE[%] NW CPU MEM CPU MEM [bps] 94 25 35 26 26 35 16 8

V.

9 1 25 15 24 25 10 3

– 53 – – 5 – – 4

– 1 – – 1 – – 1

– 345 – 344 345 – 800 800

Cost [$/mo] – 0 – – 0 – – 0

E VALUATION

We have performed a number of experiments to demonstrate the feasibility and need for the cloud-enhanced home controller. The experiments were performed on the following hardware. As the HE, we used a Raspberry Pi with a 700MHz ARM core and 512MB of RAM running 3.6.11+ kernel Raspbian OS. Our CE is a PC with a 3.10GHz Intel dual core system and 4GB of RAM, running Ubuntu 12.04. A. Experiments We first evaluated the modes of all three applications. For Home Mode of the door locking application (Application 1), the CPU load of the HE reached about 94%, as shown in the leftmost graph of Figure 8. This is as expected since all of the functionality, including face detection, executes on the HE. In the Cloud Mode, face detection is moved to the CE and as a result, the CPU utilization of the HE is reduced as shown by the middle graph in Figure 8. In this sample execution, the CE receives the video from 10[sec] until 52[sec], and then executes the face detection algorithm resulting in a spike of CPU usage at the CE as shown by the rightmost graph in Figure 8. Largely due to face detection, the dock locking application has the most demanding compute requirements among all the applications. The CPU load is consistently more than 70% for the HE and more than 50% at points for the CE. Note, however, that the CPU load of the HE in the Cloud Mode is around 25%, much less than in Home Mode. Consequently, other applications are able to execute on HE, demonstrating one of the values of our architecture. I.

total! user sys user! sys!

CPU load of CE [%]!

CPU load of HE [%]!

CPU load of HE [%]!

80

60

total

total

user total! sys user! sys!

sys! 80

Cloud Mode: CPU load of CE!

100

100

total total! user sys user!

06/23/2015

Fig.8(c)

A summary of all the evaluation results are shown in Table

Primary criterion HE CPU load CE CPU load

S ELECTED PATTERNS Application mode Appl 1 Appl 2 Appl 3 cloud cloud home cloud home home

B. Evaluating SWiS We first evaluated the ranking algorithm used in SWiS under different priority rules. When we select the CPU load of the HE as a primary criterion, SWiS selects the Cloud Mode for Application 1, Cloud Mode for Application 2, and Home Mode for Application 3. However, if we select the CPU load of the CE as the primary criterion, SWiS selects Cloud Mode for Application 1, Home Mode for Application 2, and Home Mode for Application 3. These are summarized in Table II, SWiS actually uses multiple criteria when making decisions, not just the primary one. To see the importance of this, consider what would happen if SWiS takes into consideration only a single criteria such as the CPU load on the HE. In this case, the Cloud Mode would always be chosen for all applications since this maximizes the offload and minimizes the load on the HE. In these evaluations, network bandwidth usage is the secondary criteria, which is what leads SWiS to select Home Mode for Application 3. Note that relative importance of these criteria may in fact be different depending on, for example, whether application model is driven by the service provider, the application developer, or the end user. The goal of SWiS is to provide a general framework that allows the differing priorities to be expressed in these cases. For our evaluation, we have three applications that have 3, 3, and 2 modes, respectively. This gives a total of 18(= 3 ⇥ 3 ⇥ 2) possible patterns. However, after eliminating infeasible patters, the sorted list at Step(3) of Figure 6 has only 8 patterns. While our focus here is not on the efficiency of the ranking algorithm itself, our expectation is that a simple approach such as the one used will be sufficient even in more realistic scenarios. The initial calculation of the best pattern can be done pre-deployment at the time of system installation in the home, and the calculations for subsequent new application can be done incrementally as noted above. Moreover, the system requires time to download and install the application in this case, giving some lead time for re-calculating the newest pattern. For application removal, efficiency is also not a big concern since the selected pattern need not be updated immediately, as discussed above in IV.

Fig.8

09/18/2014

Evalua2on(dynamic%decision)%on%HE%

09/18/2014

AP(1): Home Mode! AP(1): Cloud Mode!

100

100

total user system

total user system

90

80

80

60

CPU load of HE [%]!

CPU load of HE [%]!

70

AP(2): Cloud Mode!

50

60

AP(1): Cloud Mode!

40

AP(2): Cloud Mode!

40 30

20

20 10

AP(3): Cloud Mode!

AP(3): Cloud Mode!

0

07:30  0

0 11:40  0

07:40 10

15

07:50 20

25

08:00 30

35

08:10 40

45

08:20 50

55

08:30 60

65

08:40 70

75

08:50 80

Execution Time [sec]!

11:50 5

12:00 10

12:10 15

12:20 20

12:30 25

12:40 30

12:50 35

13:00 40

13:10 45

13:20 50

13:30 55

Execution Time [sec]!

Fig. 11.

CPU load of the HE where AP(1) and AP(2) share a video feed. CPU load of the CE where AP(1) and AP(2) share a video feed.

Fig.11

Fig. 9. CPU load of the HE when an application mode is dynamically Fig.9changed by SWiS. At 15 sec, Application 1 in the Home Mode starts to capture a movie. Then SWiS detects that CPU load of HE is over a threshold and changes the mode from Home Mode to Cloud Mode to decrease CPU load of HE according to system-wide decision at 23 sec.

09/18/2014

100

100

total user system

80

total user system

AP(1): Cloud Mode 80

CPU load of CE [%]

Evalua2on(dynamic%decision)%on%CE%

CPU load of CE [%]!

5

60

40

AP(1): Cloud Mode!

60

20

40

0 07:20 07:30        0

5

07:40 10

15

07:50 20

25

08:00 30

35

08:10 40

45

08:20 50

55 08:30 60

65 08:40 70

Execution Time [sec]

Fig. 12.

20

0 11:40  0

11:50 5

12:00 10

12:10 15

12:20 20

12:30 25

12:40 30

12:50 35

13:00 40

13:10 45

13:20 50

13:30 55

Execution Time [sec]!

Fig. 10. CPU load of the CE when an application mode is dynamically changed by SWiS. SWiW switches Application 1 to the Cloud Mode at 23 sec.

We also tested SWiS’ ability to react to changes in the execution environment. Specifically, we checked how well SWiS monitors resources, detects emergencies, and changes configuration patterns. To do so, we first executed the remote monitoring application (Application 2) in the Cloud Mode and the safe internet application (Application 3) in the Home Mode simultaneously. We then started the door lock application (Application 1) in the Home Mode to stress the load on the HE, despite the fact that the Cloud Mode is the configuration proposed by SWiS. As shown in Figure 9, between 15[sec] and 25[sec], the CPU load of the HE reached almost 100%. SWiS detected this overload condition at the HE, changed the mode of Application 1 from Home Mode to Cloud Mode automatically, and started the functions needed for the Cloud Mode such as face detections on the CE. Figure 10 shows the corresponding CPU utilization at the CE. These results show that all three applications were able to execute simultaneously without overloading the HE.

CPU load of the CE where AP(1) and AP(2) share a video feed.

Finally, we evaluated an operational scenario in which multiple applications operate on the same event stream, as described in III. For example, in our evaluation, Applications 1 and 2 can share the same video when Application 2 is monitoring the outside of the home. In this case, the usage level of HE’s resources in the Cloud Mode for Application 1—e.g. capturing and transferring video to the CE in Figure 3 and Figure 4—are going to be negligible as shown in Figure 11. The corresponding CPU usage at the CE is shown in Figure 12. Consequently, the HE will have more resources available for both current and future applications. VI.

R ELATED W ORK

Mobile applications that require a significant amount of computing power such as gaming, video, navigation, and speech recognition are becoming increasingly popular and are a common target for work related to cloud offloading. In this context, offloading is used as a way to enhance the capabilities of computationally modest and battery-constrained devices. Two efforts in this space are MAUI [8] and CloneCloud [9]. MAUI provides dynamic energy-aware offloading of mobile code by choosing methods that can be executed remotely in the cloud. The main goal is to optimize the energy consumption of a mobile device based on estimates of the energy cost of local processing and remote execution. CloneCloud offloads

portions of the Android Dalvik code running on a mobile device to the cloud automatically and dynamically based on static analysis. CloneCloud uses a cloned VM image as a powerful virtual device. Moreover, CloneCloud proposes the encapsulation of the mobile application’s stack into the VM in the cloud; this feature ensures that application can be processed locally or remotely at the byte level. The main purpose of CloneCloud is to speed-up execution time and decrease energy consumption on the mobile device. As discussed in Section II, the requirements of home automation are different of those of mobile offloading, and therefore our solution is fundamentally different than mobile offloading research. Another category of related work is system and network support for remote devices such as temperature sensors, remote switches, door locks, lights, and cameras. In such scenarios, a home controller communicates with the devices through a USB Interface, for example, using a Z-wave USB dongle, a ZigBee USB dongle, or directly to a USB camera. USB/IP [13] provides a virtual peripheral bus extension over IP to enable such functionality. Using this, a home controller can share devices over networks without any modification to either the OS or applications and applications when sufficiently large network bandwidth is available. This work is complementary to that presented here in the sense that it provides underlying support for our proposed cloud-enhanced architecture. As mentioned in Section II, HomeOS [6] is a platform that provides an abstraction for network device technologies in the home. HomeOS handles network devices as peripherals with abstract interfaces, simplifies the development of applications by abstraction, and gives users a management interface designed for the home environment. The goal of these technologies is to extend the home automation system easily by adding new devices and applications. However, HomeOS does not address the resource constraints of the home controller. VII.

techniques can be applied to address these issues. For example, authentication techniques can be used to verifying the identity of the CE and HE, and a virtual private network (VPN) can be used to create an encrypted connection between the CE and HE. In future work, we intend to address the remaining challenges in realizing our vision, including implementing a more comprehensive set of applications and security. ACKNOWLEDGMENT The authors would like to thank Gueyoung Jung for his helpful suggestions and feedback for ranking algorithm of SWiS. R EFERENCES [1]

[2] [3]

[4] [5] [6]

[7]

[8]

C ONCLUSIONS

In this paper, we make the case that cloud offloading can be instrumental in enabling a new flexible ecosystem of rich applications in the rapidly growing home automation space. We presented our Cloud-Enhanced Home Controller (CEHC) architecture, including a novel application design paradigm that allows each application to execute in multiple possible modes, each with different resource consumption patterns for the home, cloud, and network resources, as well as potentially different levels of functionality. We also described key platform services, in particular, the System-wide Scheduler (SWiS). SWiS decides which applications should be offloaded to the cloud based on multiple constraints and criteria such as the hardware capabilities of the home controller and the cloud, network bandwidth, and the cost of the network and the cloud. Furthermore, SWiS monitor resources and detects when the applications should switch operating modes, for example, from a Cloud Mode to a Degraded Mode when connectivity is lost, or from a Cloud Mode to a Home Mode when more resources become available. This makes it possible to provide stable quality of services to residents and to decrease the cost of using the network and cloud. We evaluated the architecture using three example applications. In this paper, we do not address any security issues (e.g., privacy of users/data, authorization, authentication, etc.). However, standard security

[9] [10] [11]

[12] [13]

[14] [15] [16] [17] [18]

M. Chan, C. Hariton, P. Ringeard, and E. Campo, “Smart house automation system for the elderly and the disabled,” in Systems, Man and Cybernetics, 1995. Intelligent Systems for the 21st Century., IEEE International Conference on, vol. 2, Oct 1995, pp. 1586–1589 vol.2. J. Gerhart, Home Automation and Wiring. McGraw-Hill Professional, 1999. A. Ranganathan and R. H. Campbell, “Supporting tasks in a programmable smart home,” In ICOST 2005 : 3rd International Conference On Smart Homes and Health Telematic – From Smart Homes to Smart Care, 2005. At&t digital life. [Online]. Available: https://mydigitallife.att.com/learn/ [Accessed 23 June 2015] oneM2M, oneM2M Use Cases Collection, http://www.onem2m.org/library/index.cfm, 2013. C. Dixon, R. Mahajan, S.Agarwal, J. A.Brush, B.Lee, S.Saroiu, and P.Bahl, “An operating system for the home,” In Proceedings of the 9th USENIX conference on Networked Systems Design and Implementation, 2012. Y. Igarashi, K. Joshi, M. Hiltunen, and R. Schlichting, Eds., Vision: Towards an Extensible App Ecosystem for Home Automation through Cloud-Offload. The Fifth ACM Workshop on Mobile Cloud Computing and Services (MCS), 2014. E. Cuervo, A. Balasubramanian, A. Wolman, S. Saroiu, R. Chandra, and P. Bahl, “MAUI: making smartphones last longer with code offload,” In Proceedings of the 8th international conference on Mobile Systems, applications, and services, pp. 49–62, 2010. B.-G. Chun, S. Ihm, P. Maniatis, M. Naik, and A. Patti, “CloneCloud: Elastic execution between mobile device and cloud,” EuroSys, 2011. S. Kosta, A. Aucinas, P. Hui, R. Mortier, and X. Zhang, Eds., ThinkAir: Dynamic resource allocation and parallel execution in the cloud for mobile code offloading. In Prod. of IEEE INFOCOM 2012, 2012. M.-R. Ra, A. Sheth, L. Mummert, P. Pillai, D. Wetherall, and R. Govindan, Eds., Odessa: Enabling Interactive Perception Applications on Mobile Devices. In Prod. of the 9th international conference on Mobile systems, applications, and services, 2011. P. Hunt, M. Konar, F. P. Junqueira, and B. Reed, “Zookeeper: Wait-free coordination for internet-scale systems,” in Proceedings of the 2010 USENIX Conference on USENIX Annual Technical Conference, 2010. T. Hirofuchi, E. Kawai, K. Fujikawa, and H. Sunahara, “USB/IP – a peripheral bus extension for device sharing over ip network,” Proceedings of USENIX Annual Technical Conference, vol. FREENIX Track, pp. 47–60, 2005. Mjpeg-streamer. [Online]. Available: https://code.google.com/p/mjpgstreamer/ [Accessed 18 April 2015] Ffmpeg. [Online]. Available: https://www.ffmpeg.org [Accessed 18 April 2015] Squid. [Online]. Available: http://www.squid-cache.org [Accessed 18 April 2015] App store. [Online]. Available: https://itunes.apple.com/ [Accessed 23 June 2015] Google play. [Online]. Available: https://play.google.com/store [Accessed 23 June 2015]