Citation
Latency Optimization in Large-Scale Cloud-Sensor Systems

Material Information

Title:
Latency Optimization in Large-Scale Cloud-Sensor Systems
Creator:
Balasubramanian, Adhithya
Place of Publication:
[Gainesville, Fla.]
Florida
Publisher:
University of Florida
Publication Date:
Language:
english
Physical Description:
1 online resource (44 p.)

Thesis/Dissertation Information

Degree:
Master's ( M.S.)
Degree Grantor:
University of Florida
Degree Disciplines:
Computer Science
Computer and Information Science and Engineering
Committee Chair:
HELAL,ABDELSALAM ALI
Committee Co-Chair:
THAI,MY TRA
Committee Members:
XIA,YE

Subjects

Subjects / Keywords:
cloud -- energy -- latency -- optimization -- scalability -- sensor
Computer and Information Science and Engineering -- Dissertations, Academic -- UF
Genre:
bibliography ( marcgt )
theses ( marcgt )
government publication (state, provincial, terriorial, dependent) ( marcgt )
born-digital ( sobekcm )
Electronic Thesis or Dissertation
Computer Science thesis, M.S.

Notes

Abstract:
With the advent of the Internet of Things and smart city applications, massive cyber-physical interactions between the applications hosted in the cloud and a vast number of external sensors and devices is an inevitable situation. This raises two main challenges: cloud cost affordability as the smart city grows (referred to as economical cloud scalability) and the energy-efficient operation of sensor hardware. Cloud-Edge-Beneath (CEB) is a multi-tier architecture for large-scale IoT deployments, embodying distributed optimizations, designed to address these two challenges. In this article, we present another major challenge for cloud sensor-systems, which is latency. Latency can potentially arise in servicing requests from cloud applications, especially given our primary focus on optimizing energy and cloud scalability. It is a crucial factor to optimize for real-time and cyber-physical applications with limited tolerance to delays. Also, improving the responsiveness of IoT applications improves the user experience and hence the acceptability and adoption of smart city solutions by the city citizens. This work aims to give a formal definition and formulation for the latency optimization problem under CEB. We propose a Prioritized Application Fragment Caching Algorithm (PAFCA) to selectively cache application fragments from the cloud to lower layers of CEB, as a key measure to optimize latency. The algorithm itself is an extension of one of the existing optimization algorithms of CEB (AFCA-1). Through experiments, we measure and validate the effects of PAFCA on latency and cloud scalability. We also introduce and discuss the trade-off between latency and sensor energy in the given context. ( en )
General Note:
In the series University of Florida Digital Collections.
General Note:
Includes vita.
Bibliography:
Includes bibliographical references.
Source of Description:
Description based on online resource; title from PDF title page.
Source of Description:
This bibliographic record is available under the Creative Commons CC0 public domain dedication. The University of Florida Libraries, as creator of this bibliographic record, has waived all rights to it worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law.
Thesis:
Thesis (M.S.)--University of Florida, 2017.
Local:
Adviser: HELAL,ABDELSALAM ALI.
Local:
Co-adviser: THAI,MY TRA.
Statement of Responsibility:
by Adhithya Balasubramanian.

Record Information

Source Institution:
UFRGP
Rights Management:
Applicable rights reserved.
Classification:
LD1780 2017 ( lcc )

Downloads

This item has the following downloads:


Full Text

PAGE 1

1 LATENCY OPTIMIZATION IN LARGE SCALE CLOUD SENSOR SYSTEMS By ADHITHYA BALASUBRAMANIAN A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR TH E DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2017

PAGE 2

2 2017 Adhithya Balasubramanian

PAGE 3

3 To my Mom, Dad and Brother

PAGE 4

4 ACKNOWLEDGMENTS I would like to thank Dr. Sumi Helal whose constant motivation and guidance made this research work possible. I thank my parents and my brother for their constant support and care. I thank all the members of the Mobile and Pervasive Computing Laboratory for their valued suggestions. Last but not least, I would like to thank the faculty of the department of CISE for always inspiring me to do quality research.

PAGE 5

5 TABLE OF CONTENTS page ACKNOWLEDGMENTS ................................ ................................ ................................ .. 4 LIST OF FIGURES ................................ ................................ ................................ .......... 6 ABSTRACT ................................ ................................ ................................ ..................... 7 CHAPTER 1 INTRODUCTION ................................ ................................ ................................ ...... 9 2 OVERVIEW OF CEB ARCHITECTURE ................................ ................................ 12 Challenges Addressed ................................ ................................ ............................ 14 Bi Directional Waterfall Optimization Framework ................................ .................... 16 3 RELATED WORKS ................................ ................................ ................................ 19 4 LATENCY FO RMULATION AND OPTIMIZATION ................................ ................. 21 Formulation ................................ ................................ ................................ ............. 22 Analysis of Latency ................................ ................................ ................................ 23 Optimization Problems ................................ ................................ ............................ 24 5 EVENT PRIORITIZATION MODEL ................................ ................................ ......... 25 Application Fragments Redundancy Problem ................................ ......................... 26 Edge Caching Energy Benefit Evaluation Model ................................ .................... 27 Event Prioritization Model for AFCA 1 ................................ ................................ .... 28 6 EXPERIMENTAL EVALUATION ................................ ................................ ............ 31 Experiment 1 Comparison of Number of Critical Events Satisfied ....................... 33 Experiment 2 Comparison of Evaluation Times of Hot Events ............................. 35 Experiment 3 Comparison of Scalability Benefit ................................ .................. 36 CebX A CEB Experimental Station ................................ ................................ ...... 38 7 CONCLUSION AND FUTURE WORKS ................................ ................................ 41 LIST OF REFERENCES ................................ ................................ ............................... 42 BIOGRAPHICAL SKETCH ................................ ................................ ............................ 44

PAGE 6

6 LIST OF FIGURES Figure page 2 1 Overview of CEB Architecture. ................................ ................................ ........... 14 6 1 Comparison of number of critical events satisfied with Dell Latitude E6520 as Edge node. ................................ ................................ ................................ ......... 34 6 2 Comparison of number of critical events satisfied with Raspberry Pi as Edge node. ................................ ................................ ................................ .................. 34 6 3 Comparison of number of critical events satisfied with all events critical. ........... 35 6 4 Comparison of evaluation times of Hot events. ................................ .................. 36 6 5 Comparison of scalability benefit with Dell Latitude E6520 as edge node. ......... 37 6 6 Comparison of scalability benefit with Raspberry Pi as edge node. ................... 38 6 7 CebX Screenshots. ................................ ................................ ............................. 39

PAGE 7

7 Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for th e Degree of Master of Science LATENCY OPTIMIZATION IN LARGE SCALE CLOUD SENSOR SYSTEMS By Adhithya Balasubramanian December 2017 Chair: Sumi Helal Major: Computer Science With the advent of the Internet of Things and smart city applications, massive cyber physical interactions between the applications hosted in the cloud and a vast number of external sensors and devices is an inevitable situation. This raises two main challenges: cloud cost affordability as the smart city grows (referred to as economical cloud scalability) and the energy efficient operation of sensor hardware. Cloud Edge Beneath (CEB) is a multi tier architecture for large scale IoT deployments, embodyi ng distributed optimizations, designed to address these two challenges. In this article, we present another major challenge for cloud sensor system s, which is latency L atency can potenti ally arise in servicing requests from cloud applications, especially given our primary focus on optimizing energy and clou d scalability. It is a crucial factor to optimize for real time and cyber physical applications with limited tolerance to delays. Also improving the responsiveness of IoT application s improve s the user experience and hence the acceptability and adoption of smart city solutions by the ci ty citizens. This work aim s to give a formal definition and formulation for the latency optimization p roblem under CEB. We propose a Prioritized Application Fragment Caching Algorithm (PAFCA) to selectively cache application fragments from the cloud to lower layers of

PAGE 8

8 CEB, as a key measure to optimize latency. The algorithm itself is an extension of one of the existing optimizat ion algorithms of CEB (AFCA 1). Through experiments, we measure and validate the effect s of PAFCA on latency and cloud scalability. We also introduce and discuss the trade off between l atency and sensor energy in the given context.

PAGE 9

9 CHAPTER 1 INTRODUCTION As the smart city concept proliferates into a massive scale, smart city applications are bound to be pushed to the cloud where they can be hosted and ecause of the fact that numerous stakeholders will demand access to sensor data and the services (applications) which is difficult to achieve without a neutral and a common platform like the cloud. But connecting hundreds of millions of sensors and devices directly to the cloud is bound to result in massive traffic and unbounded use of cloud resources. Utilizing edge computing and connecting devices to the cloud through edge computers has been shown to be a promising approach to manage growth in the smart c ity and to achieve economical scalability of the cloud, by slowing down its elasticity rate as more devices and applications are deployed [22]. We have developed the cloud edge beneath (CEB) architecture to address the economical scalability challenge and to minimize the energy used by the sensors and devices. CEB embodied a distributed optimization framework deployed at all three layers of the architecture. Four optimization algorithms in CEB have been designed to minimize movements of application reques ts down to the sensors, and movements of data updates from the sensors up to the applications. Also, sensor sampling is minimized and a new guiding principle which we call sentience efficiency is applied. In a nutshell, sentience efficiency refers to the e xtent that data sampled from sensors and moved up or made available to applications is actually necessary to the proper execution of the application. In other words, a sentient efficient cloud sensor system is one that cleverly avoids any unnecessary sensi ng. To implement our optimization

PAGE 10

10 algorithms which we will briefly summarize in this article we introduced a bi directional waterfall optimization framework that coordinates the interplay between the four algorithms, and that correlates application charac teristic dynamics with data change dynamics, again to minimize all movements. While our prior work focused on energy savings in the beneath layer and the cloud economical scalability in the cloud layer, it left latency and real timeliness unaddressed. In this work we extend our CEB optimization approach to address latency, and to continue to optimize cloud scalability and sensor energy use under deadline constraints. We formally capture time and deadlines into the architecture and introduce a new, fifth a lgorithm that aims to bridge the gap between our prior optimization goals and its potential latency side effect. Motivation Latency is a crucial factor to consider in any real time and cyber physical system. Specifically, in cloud sensor systems where sen sors are dumb, and the application logic resides in the cloud, latency in evaluating events (application logic) could potentially be dangerous. For instan ce, consider a smart home with a sensor based simple fire extinguishing system installed. Suppose the system has a bunch of temperature sensors, smoke detecting sensors and water sprinklers An event of fire could be detected by analyzing the values sampled from the temperature sensors and smoke detecting sensors. A cloud application trying to detect an event of fire would have to fetch the individual values of the associated sensors and then must evaluate the event to detect fire Fetching s ensor values from the cloud involves two way communication and sampling, both taking time In an actual event of a fire, every millisecond of extra time taken to detect the fire causes more damage. But with an

PAGE 11

11 architecture like CEB, the distributed optimizations offered could be effectively used smartly to reduce the communication and the sampling time. Also, any us er of the cloud application would expect the application to be responsive. Optimizing latency in evaluating events is the key to improve the responsiveness of any IoT application. So, latency is a crucial factor to be optimized without which the IoT soluti ons would not be accepted and adopted by the end users and would hence not be successful.

PAGE 12

12 CHAPTER 2 OVERVIEW OF CEB ARCHITECTURE In this chapter, we briefly describe our prior work on Cloud Edge Beneath (CEB) architecture whose understanding is required for our proposed work in this article to be clearly explained. CEB is a three tier architecture and a framework for deploying and m anaging cloud sensor systems whose applications are programmed, hosted and run on the cloud [22]. Figure 2 1 shows an abstracted high level view of the architecture. The architecture is intended to enable an ecosystem for developing and deploying smart cit y applications in the cloud. The beneath layer refers to the sensors/devices and their sensor platforms which are low power computing and communication platforms, connecting related sensors (e.g., belonging to same geographical area, organization or an aut hority) to a corresponding edge. Edge layer groups related sensors and connects them to the cloud. Deploying and powering up devices under CEB makes the devices automatically externalized and represented in the cloud as software services. This architectures such as the ARM mbed [1] in which device cloud services can be generated as RESTful services. Automatic externalization immediately enables developers to program and deploy smar t city applications in a practical fashion that decouples physical device deployment from application development. CEB is built on top of Atlas [7] which is an implementation of the Service Oriented Device Architecture (SODA) model [5]. For every beneath d evice connected to an Atlas node, a corresponding basic service is automatically created on the edge. And for every basic edge service, there exists a corresponding replica basic service created also automatically on the cloud, and

PAGE 13

13 managed by an instance o f the Atlas Cloud Middleware (ACM) at the cloud layer. ACM acts as a cloud gateway to the edge. It hosts all cloud sensor service bundles passed from the edge and provision them (and make them accessible) to developers with permissions as services ready to be subscribed to, by other cloud services and applications. Sensor based services and applications are developed, deployed and run in a container called Cloud Application Runtime (CAR) at the cloud layer. Both the edge and the cloud layers use the Open S ervices Gateway Initiative OSGi [13] as their basis to provide service registration, discovery, activation and configuration. The current implementation of CEB is based on an event driven application model called E SODA [22], where the applications do no t only utilize raw sensor data, but are also able to tune to specific events ranging from simple to complex events. We descri be E SODA briefly in this chapter Clo ud, Edge and Beneath (CEB) is a three tier architecture and framework for deploying and manag ing cloud sensor systems whose applications are programmed, hosted and run on the cloud [1]. The beneath layer refers to the sensors and their sensor platforms which are low power computing and communication platforms, connecting the sensors to the edge. E dge layer groups geographicall y related sensors and connects them to the cloud. CEB is built on top of Atlas [2] which is an implementation of Service Oriented Device Architecture [3]. For every node in the edge layer there exists a corresponding Atlas Cloud Middleware (ACM) at the cloud layer. ACM acts as a cloud gateway to the edge. It hosts the cloud sensor service bundles passed from the edge and provision them as services ready to be subscribed to, by

PAGE 14

14 other cloud services and applications, when the sensors are activated. Sensor based services and applications are dev eloped, deployed and run in a container called Cloud Application Runtime (CAR) at the cloud layer. Both the edge and the cloud layers use OSGi [ 4] as their basis to provide service discovery and configuration. The current implementation of CEB is based on an event driven application model called E SODA [1 ], where sensor data are abstracted into events. Figure 2 1. Overview of CEB Architecture Chall enges Addressed The two key challenges that have been addressed by CEB are the cloud scalability challenge and the sensor energy challenge. We first discuss cloud scalability. Extensive interactions between sensors and cloud services could pose a challenge on the scalability of the cloud. In a smart city scenario, with millions of sensors requiring which requires tremendous processing power, memory and huge incoming/ou tgoing

PAGE 15

15 cloud traffic, leading to a heavy draw on the costly cloud elasticity. Given the existing use based price models, the cloud would become too expensive as the economies of scale per sensor will not stand. This will be a major show stopper given that main motivation is bridging supply and demand in face of increased urbanization and decline of resources and budget to spend per capita. So it would not make any sense to spend unbounded amount of money on cloud services monthly while trying to meet ends and bridge gaps! CEB has been architected to slow down cloud elasticity in face of growing demands of applications or expanding instrumentation of the smart city. CEB utilize optimizing algorithms to lean back on and exploit power unconstraine d edge servers and even beneath nodes to tackle some of the work, which effectively contains elasticity and enhances cloud economic scalability. The second key challenge is maintaining the energy constraints of the sensor devices. Most of the sensors are g enerally battery powered which make them vulnerable to power drainage. In a smart city scenario, a sensor may be queried by hundreds of applications, each requiring continuous evaluation of events based on sensor readings. This could lead to continuous sam pling of the sensors. Without optimizations, the energy of the sensors might deplete rapidly, rendering them unreliable and unavailable. We have addressed this challenge by several optimization algorithms coordinated via a bi directional waterfall optimiza tion framework [20], which essentially renders a distributed optimization occurring at each layer of CEB. The same framework is used as the context in which our proposed latency optimization algorithm is coordinated, and hence, we briefly explain this fram ework first in the next section.

PAGE 16

16 Bi Directional Waterfall Optimization Framework In CEB, cloud applications request data from the physical layer which reaches the cloud through the edge layer. In our Bi directional waterfall optimization framework [20], in addition to data being cached up from beneath to the edge and ultimately to the even beneath, opening up a number of optimization opportunities. Application caching require s that the application model is inherently divisible (that is, an app can be divided into communicating parts easily). Pub/Sub, Event driven and functional programming based application models are inherently divisible. CEB utilizes an event driven model kn own as E SODA which enables the concept of application fragment caching. Under E SODA, a complex event (cloud application) could be diced into a number of smaller complex events each represented by an Event Representation Tree (ERT), which can be cached a t the lower layers. Caching an application fragment means caching a subtree of events from an ERT. A cached event is evaluated at the layer it is cached to and its event value is pushed back to its upper layers only when the value changes from its previous event at the upper layers. This shadow event receives the selective push messages from the layer below it. The edge is of strategic importance here, because it has a view of both the data and the application domains and could potentially analyze how the data and applications interplay. This enables powerful optimizations which take the sensor data and the cloud applicat ions as inputs to the optimization equation, thereby addressing the two key challenges mentioned above. The four optimization algorithms

PAGE 17

17 implemented at the three layers of CEB are briefly described below and their interplay explained. Cloud to Edge Applica tion Fragment Caching Algorithm (AFCA 1) [21] cloud scalability: AFCA 1 selects application fragments (ERTs) from the cloud to cache at the edge layer to address the cloud scalability challenge and at the same time, staying within the limitations of the resources in edge servers (memory and processing power). Edge servers are not elastic as cloud. Shortcut Evaluation and Branch Permutation Algorithm (BPA) [19] saving sensor energy: In processing the application fragments cached at the edge layer, shortc ut evaluation can be utilized when a subset of sensor data is sufficient to derive the occurrence of an event, saving the sensor power due to the skipped sensor samplings. For example, consider an event A represented as an ERT, which is evaluated as A = B AND C, where B and C are two other ERTs (children or subtrees of A ) and the value of A is calculated by performing a Boolean AND operation on its children B and C. If the value of B is known to be 0, then there is no necessity to evaluate and calculate s value to determine the value of A. Branch permutation algorithm does exactly this and prunes ERTs if the occurrence of those events could be figured out without looking at the events that are not yet explored. Had the same equation been A = C AND B and B is more likely to be 0, it would be better if we evaluated B first which might shortcut C are evaluated is the key to enable more shortcuts and hence improve sensor energy savings. BPA permutes the branches of the ERT affecting the order of sensor sampling and sub event evaluation to enhance the chances of shortcuts happening.

PAGE 18

18 Application Aware Adaptive Sampling Algorithm (AAAS) [19] saving sensor energy: Atomic events are the events which are directly as sociated with the sensors and immediately evaluated from the sensor readings (the most primitive application fragment). These events are at the leaves of any ERT. Atomic events could be cached at the beneath layer to save more sensor energy. For every atom ic event cached at the beneath, AAAS algorithm uses ARMA (Auto Regressive Moving Average) model [18] to predict sensor data and skip subsequent samplings, if the predicted value is close to the sampled value. However, there should be a limit on the number of samplings skipped and AAAS uses a modified version of the algorithm proposed in [4], bringing in some characteristics from the cloud applications to fix the maximum skip limit and better optimize sensor energy. Edge to Beneath Application Fragment Cachi ng Algorithm (AFCA 2) [19] saving sensor energy: AFCA 2 selects the atomic events to cache at the beneath layer to achieve more optimized energy efficiency of the sensor nodes. Atomic events when cached at the beneath layer, would miss out on the energy savings happening because of shortcuts during the evaluation of ERTs at the edge. AFCA 2 calculates the overall benefit that could be obtained by caching an atomic event to the beneath but potentially missing out on savings because of shortcuts. If the cal culated benefit is greater than a certain threshold, AFCA 2 caches the atomic event at the beneath and does not cache it otherwise.

PAGE 19

19 CHAPTER 3 RELATED WORKS Several research projects focused on minimizing network latency in cloud based systems. One of the most significant work is the cloudlet approach by Satyanarayanan et al. [16] in which the cloud is brought closer to the applications/mobile devices (one ho p away) by introducing a new architectural element called cloudlet in the three tier hierarchy: mobile device cloudlet cloud. In contrast to the cloudlet approach, in our cloud sensor systems approach, the applications are on the cloud and the edge is used to bring the physical world (sensors and devices) closer to the cloud. In CEB, edge is used to either bring the physical world closer to the cloud or cache application fragments down closer to the physical world. A power and latency aware optimum clo udlet selection strategy was proposed by Mukherjee et al. [12] for multi cloudlet environment. A computation model c ombining the characteristics of fog computing [3] [17] and in cooperating Complex Event Processing (CEP) [14] at the edge of the network, to achieve low latency and real time responses that cloud applications demand, was proposed by Madumal et al. [9]. A mathematical model of fog computing which assesses the applicability of fog computing in Internet of Things to meet the demands of latency se nsitive applications running at network edge, was proposed by Sarkar et al. [15]. It also showed that as the number of latency sensitive applications increase, fog computing outperforms cloud computing. A service oriented network architecture named Applica tion Assist Network (AAN), with an adaptive network cache algorithm achieving lower response times than the traditional caching algorithms was proposed by Matoba et al. [10]. To effectively manage data

PAGE 20

20 latency, [8] provided a framework for a responsive dat a architecture (RDA), based on patterns seen in real IoT projects that leverage the public cloud. AirBox a performant and scalable edge service platform that can execute functionality onloaded on behalf of remote, cloud based services, in order to addr ess the bandwidth use and latency requirements of device cloud interactions was proposed by Bhardwaj et al. [2]. Unlike AirBox, where edge can directly handle application requests, in CEB all the application requests are addressed by the cloud. Zhang et al [23] introduced Mobile Edge Computing (MEC) into 5G architecture and evaluated the network end to end latency. Low latency services with a requirement not smaller than 17ms are supported by MEC. Drolia et al. [6] discussed about leveraging spatio tempora l context at the edge to dynamically create caches in edge servers and across mobile devices to decrease latency for vision based applications. In this article, we model latency inherent in evaluating events in an event driven application model and propose a greedy optimization algorithm within CEB to minimize latency.

PAGE 21

21 CHAPTER 4 LATENCY FORMULATION AND OPTIMIZATION The time elapsed from the moment an application places an event evaluation request to the cloud application runtime (CAR) until the moment it gets back a response from the CAR, is defined as the latency involved with the request. As we mentioned before, the current implementation of CEB with bi directional waterfall optimization framework has not considered latency optimization (minimization) as one of its key challenges. This section formulates and analyzes the latency under CEB as defined above and explains the potential reasons for high latency in the existing implementation of CEB. The section also introduces the two ways to think about laten cy optimization, and the type of latency optimization problem that this work aims to address. Since selective push is employed when an event is cached at the edge, the value. This means that any point in time, the cloud layer has the most updated value of the cached event. Thus, when an application requests the value of a cached event, it can directly be given the value from the shadow event service in the ACM. No reque st needs to be passed to the edge layer or the beneath and no sampling needs to be done to service the request. When an atomic event is not cached by AFCA 1 at the edge, it is not cached at the beneath as well. This is because, AFCA 2 chooses atomic events to cache at the beneath, only from the set of events that are already present in the edge. Every event evaluation request of a non cached atomic event at the cloud layer, results in a sampling of the sensor corresponding to that atomic event.

PAGE 22

22 Formulation Let denote the time taken to evaluate an event already cached in the edge, whose cloud event service is denoted as (4 1) Here, from the shadow event service corresponding to the cloud event service to (communication time). The time taken to eval uate an atomic event not cached at the edge, denoted by is given by the following equation. (4 2) Here, denotes the time taken to sample t he sensor corresponding to the atomic event The time taken to evaluate any non atomic event is given by the maximum time taken to evaluate each of the children of that event, assuming parallel evaluations of child events. Let denote the set of all child events of event The time taken to evaluate an event in general, denoted by is given by the following recurrence. (4 3) The overall latency for any event evaluation request is formulated as follows. (4 4)

PAGE 23

23 H ere, is the time taken for the evaluation request to reach CAR from a cloud application and is the time taken to send back the response from CAR to the cloud application after event evaluation which takes time. Analysis of Latency In orde r to minimize latency, has to be minimized. Observed latency is least when is cached at the edge. In this case, the most recently updated value of the event from the cloud shadow event service is directly given to the application. Also, it is the maximum when no atomic event in the ERT of is cached at the edge by AFCA 1, and the evaluation of each of them results in a sampling of the corresponding sensors. It could be seen that the latency directly depends on whether AFCA 1 caches an event in t he edge or not. Hence, it must be made sure that AFCA 1 caches events that are of great interest to the application at the moment. Caching an event in the edge also gives the event a chance to be a part of all the optimizations at the edge and the beneath which might also improve the energy savings of the sensors corresponding to the cached event. Potential reason for high latency AFCA 1 right now cares only about the cloud dimension with a constraint on the edge resources and does not take into account t he interest of cloud applications on a particular event and the expectations of the applications on how fast event evaluations need to be done. When events are considered for caching at the edge by AFCA 1 without any prioritization (based on time, not getting cached at the edge, as the edge resources might already be exhausted

PAGE 24

24 with oth er cached application fragments, each of which might not be of use to any application at that moment. Similar to how the order in which the branches are evaluated in an ERT is important in shortcut evaluation, the order in which events are considered by AF CA 1 for caching at the edge is important, so that the lower layers are totally application aware. Also, without prioritization among events in AFCA 1, AAAS is only partially application aware because it is based on the range of values of a particular sens point in time. Hence, AFCA 1 needs to include a prioritization model for events, and try to cache events to the edge in the order given by the model. Optimization Problems Latency optimization can be looked in two ways. First, there could be a single constraint on the system saying any event evaluation request made by any cloud application should not suffer a latency more than a certain threshold, say time units. The opti mization problem would be to minimize the threshold Second, every event could be associated with a real time constraint on the latency, which implies the optimization problem would be to satisfy the maximum possible number of such constraints. This work aims to address the second type of latency optimization problem.

PAGE 25

25 CHAPTER 5 EVENT PRIORITIZATION MODEL As suggested in the previous section, an event prioritization mod el needs to be included in AFCA 1 to optimize lat ency in the system. This chapter discusses in detail one such model we propose. The three key parameters involved in the model are 1. Event Evaluation Request Rate, denoted by 2. Latency Threshold, deno ted by 3. Event Value Change Rate, denoted by implies how fast evaluation requests for an event comes from the cloud applications. This is a direct measure of how excited the applications are about is assigned by the applications to each event. This parameter is a measure of the expectation of applications on how fast the evaluation of needs to be completed. measures how fast the value of an event changes and how often selective pushes to the cloud could happen if is cached at the edge. Based on the set of all events can be split into two broad categories namely critical and non critical e vents. If as defined by equation ( 4 4) of an event is greater than at any point in time, the latency constraint on the event can be satisfied only by caching or some or all of the sub events of to the edge, thereby reduci ng the latency. Such events are called critical events. Events for which is greater than already satisfy the latency constraint. Such events are called non critical events. Also, based on events could be broadly categoriz is greater or lesser than a constant respectively. is a common constant across any event belonging to any

PAGE 26

26 cloud application. Based on the combination of both these factors, events are classified into the following four categories. 1. Critical and Hot 2. Critical and Cold 3. Hot and Non c ritical 4. Cold and Non c ritical Caching category 1 and 2 events to edge would result in achieving the latency optimization goal and cac hing category 3 events would result in better user experience. Application Fragments Redundancy Problem multiple applications work on some common subset of events. However, eac h application has its own copy of every event it works on and this leads to redundant events in the CAR. This can be visualized as two ERTs from two different cloud applications, each having its own copy of a common subtree. In the current CEB implementati on, this problem is not addressed and there is a possibility that two exactly same events from different ERTs of different applications redundantly getting cached at the edge, which is not an efficient way of utilizing edge resources. Hence, there needs to be a single unique view of every event in the cloud which is what AFCA 1 should be looking at. Redundant application fragment/event is also problematic because the notion of criticality/latency threshold of the same redundant event might differ for diffe rent applications. Thus, for the same event one application might assign a latency threshold of say 10ms and another application might assign a latency threshold of 1s. Once there is a single unique view of every event, it becomes easy to define latenc y constraints on the events. For instance, the minimum of all the latency thresholds

PAGE 27

27 assigned for an event by all the cloud applications accessing it, would be the latency threshold of that event. Similarly, the event evaluation request rate of any event w ould be the sum of all the event evaluation request rates on that event by all the applications accessing it. Edge Caching Energy Benefit Evaluation Model Caching an event to the edge reduces the latency involved in its evaluation. This could also potentially save sensor energy because of the lower layer optimizations edge might deplete sensor energy faster than the scenario when the event is not cached at the edge. If is much higher than and if is cached at the edge, the rate at which sampling of sensors associated with is done and the rate at w hich selective pushes happen to the cloud from the edge might be much higher than However, had not been cached at the edge, the rate of sampling of sensors associated with would be equal to which might be much lesser than the rate of sampling (and hence sensor energy depletion) in the former scenario. More formally, let as given by (5 1 ) denote the overall energy spent per unit time in evaluating when is cached at the edge by AFCA 1. In (5 1 ) is the energy spent in communication (selective push) from edge to cloud, is the probability of shortcut not happening at event is the actual energy spent in the sampling, done for evaluating atomic event and is the ene rgy spent in communication of sampled value from beneath to the edge. (5 1)

PAGE 28

28 If is not cached at the edge by AFCA 1, the cost is given by (5 2) Here, is the energy spent in communication from edge to beneath and is the energy spent in communication from cloud to edge. The benefit of caching to edge is given by (5 3) If is greater than 0, then caching to the edge saves sensor energy and if is less than 0, not caching to the edge would result in better sensor energy saving. Thus, we could see that sensor energy could be saved by not caching certain events to the edge. However, not caching to edge increases the latency involved in the evaluation of Thus, there ex ists a clear trade off between energy savings and latency. This trade off should also be taken into account when caching events from the cloud to edge. Event Prioritization Model for AFCA 1 The key factors to consider while prioritizing events are their cr iticality (critical or non caching them to the edge, given by [21], and the energy benefit obtained by caching them to the edge, given by The st eps involved in the prioritization are as follows. 1. Start with an empty event list 2. Add all the critical events (category 1 and 2) sorted in decreasing order of to

PAGE 29

29 3. Add all the Hot and Non critical events (category 3) with sorted in decreasing order of to 4. Add all the remaining events (category 4) with sorted in decreasing order of to 5. Consider events for caching to the edge in the order given by C ategory 2 events are given more priority than category 3 events by this model to maximize the number of events whose latency constraints are satisfied, which is the goal of our optimization. The improved AFCA 1 which is called PAFCA to better optimize latency is gi ven below. Prioritized Application Fragment Caching Algorithm 1. Initialize , 2. for every event in CAR 3. if 4. add to 5. end for 6. sort events of in decreasing order of 7. add events of to in the sorted order 8. for every event not in 9. if and 10. add to 11. end for 12. sort events of in decreasing order of 13. add events of to in the sorted order 14. for every event not in 15. if 16. add to 17. end for 18. sort events of in decreasing order of 19. add events of to in the sorted ord er 20. for every event in construct its ERT 21. Partition into areas (based on edges) 22. for each area in 23. 24. send to edge, wait for the response; 25. receive the events approved to cache from edge; 26. end for 27. end for The method at line 23 of the algorithm is an extension of [21] method of AFCA 1. selects events to obtain maximal

PAGE 30

30 total scalability [21] of selected events and also makes sure that at most one event from each branch of the ERT is chosen. filters out some of the events from those selected by For a critical event only those events in need to be cached in order to satisfy the latency constraint of On the other han d, for a non critical event any event in should not be cached as that would result in greater sensor energy loss. The algorithm implementing the above mentioned steps is given below. EventSelectV2(Area Event ) A gorithm 1. 2. if is critical 3. for every event in 4. if 5. add to 6. end for 7. else 8. for every event in 9. if 10. add to 11. end for 12. return

PAGE 31

31 CHAPTER 6 EXPERIMENTAL EVALUATION The goals of our experiments were t o validate how PAFCA proves to be an efficient solution to the stated latency optimization problem, and to show how reactive and dynamic the algorithm is, when events are accessed at varying rates by the cloud applications. Real timeliness of responses is very important for critical and real time tasks, and the responsiveness of any IoT application is the key for improving user experience and possibly user satisfaction. Extending the algorithm to optimize latency, on the scalability benefit obtained with AFCA 1 on place, at least for a practical proportion of critical events in the event set. The trade off between improving cloud scalability (major goal of AFCA 1) and latency optimization (major goal of PAFCA) is al so presented in this section. Our experiments were based on a simulated set of about 99,400 events and 100 edges, with their properties set to match the real world events and edge computers well, respectively. AFCA 1 and PAFCA were simultaneously executed on the simulated event set and several metrics like the number of critical events cached, latency in evaluating extracted and compared, after every execution cycle of both t he algorithms, to validate the effectiveness of PAFCA. The simulated event set consisted of atomic events (no child) and events with 1 to 4 children, with their ERTs having up to 15 levels. Experiments were done on multiple such sets, each having a differe nt number of atomic events, and different number of composite events at multiple levels. For any event cached at the edge, the time taken to retrieve its value from its corresponding shadow service at ACM was modeled with a

PAGE 32

32 discrete probability function The probability of the memory region being unavailable memory region being available during retrieval and the probability of that was set as 0.95. The evaluation time f or atomic events, as given by ( 4 2) was modeled as a normal distribution around a mean (300ms) with a standard deviation of 20ms. The time taken to evaluate composite events was calculated using the recursive formulation given by ( 4 3). The expected evaluation times of events that are fixed by the cloud applications were modeled as a uniform distribution within a fixed range of time values. The number of CPU cycles required to evaluate an atomic event was also modeled using a normal distribution. Also, the number of CPU cycles required to evaluate a composite event was calculated as the sum of the number of CPU cycles required to evaluate all of th at evaluation of child events happen in parallel. In order to model the event value change rate we used the PLCouple1 dataset collected from PlaceLab [11] to learn how frequently the sensor values change and used that information to model for all the atomic events. For every composite event was calculated as the maximum event value change rate of all the children of With the events simulated and their properties modeled as mentioned above, we ran an instance of AFCA 1, an instance of PAFCA and an instance of an event evaluation request simulator on three different threads. The request simulator was designed to pick events at random and simulate event evaluation requests from cloud applications, thereby changing f or every picked event. As becomes high

PAGE 33

33 for certain events, we could see that PAFCA detects this and tries caching those events to the edge to improve the responsiveness of the application. Experiment 1 Comparison of Number of Critical Events Sat isfied The goal of this expe riment was to compare the number of critical events whose latency constraints as set by the cloud applications, were satisfied. for every event was modeled as a uniform distribution with a lower limit close t o the minimum evaluation time of all atomic events. The upper limit of the distribution was assigned a much higher value than the maximum evaluation time of all events, and was decreased at regular intervals, until it became equal to the lower limit. For e ach { lower limit, upper limit} pair, was generated for all the events and AFCA 1 and PAFCA were simultaneously executed. As the upper limit of the distribution decreased, the number of critical events increased and PAFCA prioritized the cri tical events while caching events to edge. This resulted in a decrease in the evaluation times of the edge cached events such that their latency constraints were satisfied. The result of performing this experiment with edge computers being Dell Lati tude E 6520, is shown in Figure 6 1 We could see that the amount of satisfied critical events with PAFCA is always greater than that with AFCA 1. When the number of critical events was 10% of the total events, PAFCA satisfied about 4.5% more critical events than AFCA 1 and when the amount was 20%, PAFCA satisfied about 9% more criti cal events than AFCA 1. Figure 6 2 shows the results of the same experiment but done with a different edge computer (Raspberry Pi). The memory capacity of the edge was set to be 256MB and the processor speed was 700MHz. As the edge resources are very limited, the number of satisfied critical events is significantly lower.

PAGE 34

34 Figure 6 1. Comparison of number of critical events satisfied with Dell Latitude E6520 as Edge node Figure 6 2. Comparison of number of critical events satisfied with Raspberry Pi as Edge node Figure 6 3 shows the results of the experiment done with the upper limit of the distribution mentioned above, set to a value lower than the minimum of of all t he

PAGE 35

35 atomic events. The lower limit was set to 0. All the events in the event set were critical with this setting. As we could see, when all the events were set with no latency constraint could be satisfied by both AFCA 1 and PAFCA as it is impossible to achieve a response time of 0ms even with caching. As the upper limit on increases, PAFCA could satisfy up to 97.37% of critical events while AFCA 1 satisfied up to 52.03% of critical events. Figure 6 3. Comparison of number of critical events satisfied with all events critical Experiment 2 Comparison of Evaluation Times of Hot Events under AFCA 1 and PAFCA and understand how PAFCA dynamically caches events that are of most interest to cloud applications at the moment, in an attempt to improve the responsiveness of the cloud applications. The event evaluation request simulator was implemented in such a way to figure out events that are not cache d by both AFCA 1 and PAFCA and simulate application requests on those events, which would increase of those events. When we could see that PAFCA would cache it

PAGE 36

36 while AFCA 1 wo uld be unaware of that. Figure 6 4 shows the r esults of the experiment. The lowest possible latency in our experiment was 7ms, which is the time needed to the cloud application. Figure 6 4. Comparison of evaluation times of Hot events Experiment 3 Comparison of Scalability Benefit The goal of this experiment was to compare the scalability benefit obtained by AFCA 1 and PAFCA in caching events to edge. The setup for this experiment was the same as the on e for the Experiment 1. The results of the experiment are shown in Figure 6 5 It could be seen that regardless of the number of critical events, the sum of scalability benefit of all events cached at edge servers is the same for AFCA 1 and is the optimum. However, because PAFCA follows a greedy strategy with event prioritization, critical events that have negative scalability benefit also gets cached at the edge decreasing the overall sum.

PAGE 37

37 Figure 6 5. Comparison of scalability benefit with Dell Latitude E6520 as edge node We could see that if the percentage of critical events is up to 5% of the total events (about 5000 events in our case), the scalability benefit obtained by PAFCA is up to 3.5% less than that obtained by AFCA 1. If the percentage of critical events is 10%, scalability benefit given by PAFCA is about 8% less than that obtained with AFCA 1. When the number of critical events increases to 20%, the scalability be nefit decreases by 16%. The reason for this drop is the greedy strategy of PAFCA which tries to satisfy critical events first even if that would decrease the overall scalability benefit. However, from a practical standpoint, assuming that the number of cri tical events would be less than 20% of the total events looks fair. Figure 6 6 shows the results of the same experiment with the edge computer being Raspberry Pi with the memory capacity of 256MB and processing speed of 700MHz. It could be seen that as the edge computers become saturated and has no more space or processing power to allow further caching,

PAGE 38

38 of scalability benefit given by PAFCA becomes as good as AFCA 1 when the number of critical events is more than 50% of the total number of events. Figure 6 6 Comparison of scalability benefit with Raspberry Pi as edge node CebX A CEB Experimental Station CebX is a tool developed to simulate AFCA 1 and PAFCA algo rithms of the Cloud Edge Beneath architecture. The tool is intended to compare and validate the effectiveness of both these algorithms. Users are required to provide parameters to configure edge computers and event services and are asked to select the algo rithms they wish to test/compare.

PAGE 39

39 A B C Figure 6 7. CebX Screenshots A) Event configuration tab B) Edge configuration tab C) Home screen of CebX with other configuration tab active.

PAGE 40

40 Users can play around with the simulations, change different parameters used to simulate different components of the system and visually see how changes to different parameters affect the effectiveness of the optimizations. The tool allows users to export the results of experiments (gra phs) as JPEG images. Users can also save experiments to files persistent on disk, which could be loaded into the tool at a later point in time to perform the same experiments again. Some of the screenshots of CebX are given in Figure 6 7

PAGE 41

41 CHAPTER 7 CONCLUSION AND FUTURE WORKS Latency is a major challenge for any cloud sensor system or Internet of Things application. Our work gave a formal definition and formulation of latency inherent in event evaluation, for any event driven application model and pr oposed an extension of the AFCA 1 optimization algorithm of our CEB architecture to include latency in its optimization goals and equations The proposed work introduced a prioritization model that needs to be followed when caching events to the edge and a lso introduced a new energy benefit model that the caching algorithm needs to take into account. The results of the simulation experiments prove the effectiveness of PAFCA in handling Critical and Hot events (as defined in this article ). Although the scala bility benefit obtained with 1 when the number of critical events is large, the benefits of real timeliness and better responsiveness is believed to outweigh the loss in scalability. Our ongoing and future wor k is focused on improving the scalability benefit obtained with PAFCA, even with a high number of critical events. We are also designing mobile sensor and device support and optimization in CEB, in which a device may change the edge it belongs to dynamica lly. The CEB experimental tool, CebX could be improved and support to dynamically generate graphs based on user given major and minor axes could be added. The tool itself could be extended as a full fledged CEB testing tool to test/verify all the optimizat ion algorithms present in the architecture.

PAGE 42

42 LIST OF REFERENCES [1] https://docs.mbed.com/docs/arm ipv66lowpan stack/en/latest/02_N_arch/ accessed: 16th November 2016. [2] K. Bhardwaj, M. W. Shih, P. Agarwal, A. Gavrilovska, T. Kim and K. Schwan, "Fast, Scalable and Secure Onloading of Edge Functions Using AirBox," 2016 IEEE/ ACM Symposium on Edge Computing (SEC) Washington, DC, 2016, pp. 14 27. [3] F. Bonomi, R. Milito, J. Zhu, S. Addepalli, "Fog Computing and Its Role in the Internet of Things", Proc. first Ed. MCC Work. Mob. cloud Comput. pp. 13 16, 2012. [4] S. Chatterjea and P. frequency control scheme for energy efficient data acquisition in wireless sensor Santorini, Greece, Jun. 2008, pp. 60 78. [5] S. de Deugd, R. Carroll, K. Kelly, B. Millett and J. Ricker, "SODA: Service Oriented Device Architecture," in IEEE Pervasive Computing vol. 5, no. 3, pp. 94 96, July Sept. 2006. [6] U. Drolia, K. Guo, R. Gandhi and P. Narasimhan, "Poster Abstract: Edge Caches for Vision Applications," 2016 IEEE/ACM Symposiu m on Edge Computing (SEC) Washington, DC, 2016, pp. 91 92. [7] J. King, R. Bose, H. i. Yang, S. Pickles and A. Helal, "Atlas: A Service Oriented Sensor Platform: Hardware and Middleware to Enable Programmable Pervasive Spaces," Proceedings. 2006 31st IEEE Con ference on Local Computer Networks Tampa, FL, 2006, pp. 630 638. [8] D. Linthicum, "Responsive Data Architecture for the Internet of Things," in Computer vol. 49, no. 10, pp. 72 75, Oct. 2016. [9] M. B. A. P. Madumal, D. A. S. Atukorale and T. M. H. A. Usoof, Adaptive event tree based hybrid CEP computational model for Fog computing architecture," 2016 Sixteenth International Conference on Advances in ICT for Emerging Regions (ICTer) Negombo, 2016, pp. 5 12. [10] K. Matoba, K. i. Abiru and T. Ishihara, "Service ori ented network architecture for scalable M2M and sensor network services," 2011 15th International Conference on Intelligence in Next Generation Networks Berlin, 2011, pp. 35 40. [11] http://web.mit.edu/cron/group/house_n/data/PlaceLab/PlaceLab.htm accessed: 23 December 2016.

PAGE 43

43 [12] A. Mukherjee, D. De and D. Guha Roy, "A Power and Latency Aware Cloudlet Selection Strategy for Multi Cloudlet Environment," in IEEE Transactions on Cloud Computing vol. PP, no. 99, pp.1 1, July. 2016. [13] http://www.osgi.org/Download/Release4V42 accessed: 15 September 2016. [14] D. Robins, "Complex Event Processing", 2010 Second International Workshop on Education Technology and Computer Science pp. 10, 2010. [15] S. Sarkar, S. Chatterjee and S. Misra, "Assessment of the Suitability of Fog Computing in the Context o f Internet of Things," in IEEE Transactions on Cloud Computing vol. PP, no. 99, pp. 1 1, October 2015. [16] M. Satyanarayanan, P. Bahl, R. Caceres and N. Davies, "The Case for VM Based Cloudlets in Mobile Computing," in IEEE Pervasive Computing vol. 8, no. 4, pp. 14 23, Oct. Dec. 2009. [17] I. Stojmenovic, "Fog computing: A cloud to the ground support for smart things and machine to machine networks," 2014 Australasian Telecommunication Networks and Applications Conference (ATNAC) Southbank, VIC, 2014, pp. 117 122 [18] Autoregressive moving average model https://en.wikipedia.org/wiki/Autoregressive%E2%80%93moving average_model accessed: 12th October 2016. [19] Y. Xu Dissertation, University of Florida, 2014. [20] Y. Xu and S. Helal, "An Optimization Framework for Cloud Sensor Systems," 2014 IEEE 6th International Conference on Cloud Computing Technology and Sc ience Singapore, 2014, pp. 38 45. [21] Proc. ACM Montreal, Canada, 2014, pp. 303 306. [22] Y. Xu and A. Helal, "Scalable Cloud Sensor Architecture for the Internet of Things," in IEEE Internet of Things Journal vol. 3, no. 3, pp. 285 298, June 2016. [23] J. Zhang, W. Xie, F. Yang and Q. Bi, "Mobile edge computing and field trial results for 5G low latency scenario," in China Communications vol. 13, no. Supplement2, pp. 174 182, 2016.

PAGE 44

44 BIOGRAPHICAL SKETCH Adhithya Balasubramanian is a Master Studen t in the D epartment of Computer Science at University of Florida, Gainesville, FL, USA, where he works as a Research Assistant at the Mobile and Pervasive Computing Lab oratory His rese arch interests span cloud sensor systems, internet of things, mobile computing, distributed systems and energy aware computing.