transitions for increased flexibility in fog computing: a case … · 2019-08-17 · transitions...

Manisha Luthra, Boris Koldehofe, Ralf Steinmetz. Transitions for Increased Flexibility in Fog Computing: A Case Study onComplex Event Processing. This is a post-peer-review, pre-copyedit version of an article published in the Informatik

Spektrum, Special Issue on Fog Computing Reality. The final authenticated version is available online at:http://dx.doi.org/10.1007/s00287-019-01191-0

The documents distributed by this server have been provided by the contributing authors as a means to ensure timely dissemination of scholarlyand technical work on a non-commercial basis. Copyright and all rights therein are maintained by the authors or by other copyright holders,not withstanding that they have offered their works here electronically. It is understood that all persons copying this information will adhere tothe terms and constraints invoked by each author’s copyright. These works may not be reposted without the explicit permission of the copyrightholder.

Transitions for Increased Flexibility in Fog

Computing: A Case Study on Complex Event

Processing

Manisha Luthra, Boris Koldehofe and Ralf SteinmetzTechnical University of Darmstadt,

Germany[firstname.lastname]@kom.tu-darmstadt.de

August 17, 2019

Abstract

Fog computing is envisioned to enable profound applications in theInternet of Things (IoT). A key characteristic of such applications is theneed to exchange vital information between distinct IoT devices in theform of event notifications, e.g., traffic conditions when performing trafficmonitoring. Complex Event Processing (CEP) is a powerful paradigmto overcome the information gap from observing primary sensor data byIoT devices to delivering event notifications to the IoT application users.However, to perform CEP in a highly dynamic IoT environment, e.g.,involving mobile and heterogeneous devices require an extremely flexibledesign of a CEP system to adaptively meet the changing requirementsand conditions in which the CEP system is executed.

In this article, we show on the use case of CEP how to increaseflexibility in a fog-cloud computing environment building on a methodologyknown as mechanism transitions. In particular, we state and analyze twoexemplary IoT use cases to show the potential of mechanism transitions.We identify and discuss possible promising mechanism transitions in thecontext of CEP. We perform an experimental study for operator placementand show how transitions help to adapt to conflicting performance objectives.

1 Introduction

Nowadays, there is a massive growth of Internet of Things (IoT) applications,e.g., in the context of smart cities, health, industry (Industry 4.0 in Germany),etc. [1] Such IoT applications interconnect a multitude of devices exchanginginformation about themselves and their surroundings. Complex Event Processing(CEP) and Data Stream Processing (DSP) are important communication paradigmsto support IoT applications in the exchange and real-time analysis of information.Although CEP and DSP share many similarities, a special functionality offeredby CEP is the support for the stepwise transformation from basic events (typicallycorresponding to sensor data) to complex events (events to which applicationsmay react, e.g., an accident on the road) by detecting patterns like causal andtemporal relations over the event stream.

1




Cloud

Fog

Things/

IoT devices

ω

ω⋈

ωV1 ωV2

Figure 1: Fog-Cloud infrastructure for deployment of IoT applications.

Typically, a CEP system consists of the event producer(s), the event consumer(s)and the event brokers. The event producer(s) generate low-level event streams,e.g., in the form of sensor data that are to be processed and correlated. Theevent consumer(s) or the IoT application end-users can specify the events ofinterest as a continuous query with the system. The query is transformed into anoperator graph, where operators represent the semantic units of the query, e.g.,joins, filter, windows, etc. The event broker(s) perform distributed in-networkquery or operator graph processing, to determine the events of interest. TheCEP system then notifies the event consumer(s) about the events of interest,better known as complex events.

Fulfilling demanding and often multiple performance objectives of IoT applications,e.g., stringent latency requirements, network bandwidth constraints and mobilityrequirements in the context of a Smart City environment is highly challenging.The CEP system allows processing of the operator graph on the network infrastructureto fulfill the performance objectives. Yet, executing a CEP system only inremote locations like the cloud is known to cause increased communicationlatency and bandwidth usage.

Fog computing is an emerging paradigm that promises increased flexibilityin the execution of distributed computations. It extends the cloud-computingparadigm to bring computation towards the edge near to the end-users orconsumers. Big cloud providers like Amazon and Google have recently launchedfog locations, Amazon CloudFront1 and Google Cloud CDN2, respectively, whichenable many innovative applications in gaming, e-commerce, social media, etc.

A fog-cloud network hierarchy is illustrated in Fig. 1, consisting of threelayers: (mobile) Things referring to IoT devices, a layer of fog nodes which offerslow-latency links to the IoT devices and a third layer comprising of resourcesfrom cloud data centers which offer high storage and computation. Such afederation of cloud and fog nodes allow a wide range of applications wherelatency-sensitive operators (e.g., ω./, join operator) can be placed at a fog node,while compute-intensive operators (e.g., ω→, sequence operator) at a cloud node.The diffused infrastructure is suitable to support large-scale distributed CEPsystems enabling deployment of IoT applications. For instance, to perform in-network query or operator graph processing over the fog-cloud infrastructure.

1https://aws.amazon.com/cloudfront/, last access: 9.8.2019.2https://cloud.google.com/cdn/docs/locations, last access: 9.8.2019.

2




The Smart City environments pose major challenges in the face of fog-cloudinfrastructure as explained in the following. (i) The presence of a diffusedheterogeneous infrastructure of fog, cloud and IoT devices as illustrated in Fig. 1that ranges from IoT devices to routers and switches at the fog layer to high-end servers at the cloud layer; each offering own mechanisms for processingand exchanging information. (ii) A dynamic streaming environment, e.g., a)event streams are produced at varying data rates, b) IoT devices can be mobileand c) fluctuating properties of the communication network, e.g., bandwidth.(iii) Variations in the performance objectives caused by the dynamic environment.For instance, distinct devices will use different communication mechanisms, e.g.,device-to-device or LTE, to exchange information. Dynamics like the mobilityof devices can increase communication latency and in turn violate stringentlatency constraints. In addition, latency constraint may depend on the movingspeed of the IoT device, e.g., to safely stop a vehicle.

Although, research on CEP systems has contributed to sophisticated adaptationand distribution principles including mobility [2] and elasticity [3, 4], existingCEP systems depend on static use of mechanisms and protocols targeted towardsspecific performance objectives. In the presence of highly heterogeneous devicesand performance objectives, it becomes important to benefit flexibly from multipleand hence dynamic use of mechanisms of a CEP system.

To this end, we discuss and propose in this article the application of anadaptation method named mechanism transitions [5] that facilitates a dynamicexchange of the mechanisms of a CEP system (e.g., operator placement [6–8]).We illustrate the potential of transitions to facilitate flexibility in CEP systemsto support a wide range of devices of the fog-cloud infrastructure and meet evendynamically changing performance objectives of IoT applications. This paperinvestigates the potential mechanisms in particular operator placement in a CEPsystem that can benefit from transitions.

The paper is structured as follows: in Section 2, we provide background onfog computing for CEP and related work analysis. In Section 3, we elaboratethe case study based on a Smart City environment. In Section 4, we enumerateimportant challenges identified based on the case study. In Section 5, weidentify key mechanism transitions for a CEP system and emphasize on the needfor transitions by experimentally analyzing operator placement mechanisms.Finally, in Section 6, we conclude and give next steps for the proposed fog-cloud assisted transition-capable CEP system.

2 Background and Related Work

In this section, we first state more precisely the definition of fog computing usedthroughout the article. Furthermore, we provide related work in (i) realizingadaptive applications on heterogeneous and distributed resources of fog specificallyfor our use case (cf. Section 3) and (ii) the existing communication systems thatprovide mechanism transitions.

There have been several attempts in the literature on defining fog computing.While Cisco coined this term as a synonym to edge computing, which correspondsto “analyzing data at the network edge near to the end-users” [9]; emerging fogstandards like the OpenFog consortium has defined it “as an architecture that

3




distributes resources and services like computing, storage, control and networkinganywhere along the continuum of Cloud to IoT devices at edge” [10].

In this article, we proceed with the former view on fog computing, definingit as a paradigm that facilitates computations at the network edge [9, 11, 12].Specifically, we use fog and cloud as an infrastructure model and facilitatemechanism transitions on this infrastructure for CEP systems.

Several approaches propose to realize adaptive fog applications [13]. Akey challenge they address is to support computation (e.g., CEP operators)offloading or placement to fog-cloud nodes under dynamics in Smart City environments [14].The key problems often neglected are (i) heterogeneity of fog-cloud nodes thatcan be used depending on the application and (ii) that the performance objectivescan change during runtime. Several authors utilize heterogeneous fog-cloudinfrastructure to realize applications for vehicular networks [15] and healthapplications [16], yet their solutions are specific to these applications. In contrast,we provide an extensible model using CEP for applications in Smart Cityenvironments, while dealing with the challenge of changing performance objectivesunder dynamic conditions.

The concept of mechanism transitions allow applications to exchange mechanismsat run-time without disrupting the execution of applications. Transitions havebeen applied in a wide range of applications [5, 17] and seem promising whenintegrating heterogeneous resources as it is commonly the case in the context offog computing. Our focus is on understanding how mechanism transitions canintroduce higher flexibility in fog computing to support CEP applications. Inparticular, we focus on how to realize highly dynamic and stateful mechanismtransitions comprising many dependent distributed entities as they are typicalfor fog computing. In the next sections, we will discuss a case study on aSmart City environment with concrete application scenarios, the potential andchallenges of realizing transitions.

3 Case Study: Smart City Environment

According to Cisco, the Smart City market is estimated to generate a revenueof a hundred billion dollars by 2025. Existing projects on smart cities likeEuropean Smart Cities3 highlight the increasing significance of key industryand service sectors in this domain including Smart Mobility, Smart Health,Smart Home, and other value-added services. While a few architectures [18]offer a complete end-to-end IoT solution, including connectivity management,device management, data management, security, etc., our focus in this work ison real-time data processing for IoT applications, in particular, using CEP.

Current IoT architectures rely on either of the two extremes for data processing– cloud, or edge [12] with only a few exceptions [19] sharing our view that neitherof the two extremes alone is capable for processing real-time data streams fromIoT applications. On the one hand, some IoT applications send all the datato the cloud for high capacity storage and computation, e.g., video processingapplications. On the other hand, time-critical applications like autonomouscars rely on local computation, particularly the IoT device layer in Fig. 1. IoTapplications pose multiple challenges that are hard to be solved by the twoextreme architectures. For instance, routing data to the cloud can take several

3http://www.eu-smartcities.eu, last access: 9.8.2019.

4




hundred milliseconds to react. This can lead to dangerous situations, e.g., forfuture autonomous car-to-car communication. Low latency in this applicationmeans minimizing the time to send a critical notification from one car to theother and triggering safety measures like putting hard brakes. Timely actionsare extremely important in such applications. If not taken, it could lead tolife-critical situations. For instance in a recent event, an Uber autonomous carkilled a pedestrian crossing the road4.

Some IoT devices might be resource-constrained; hence, processing datalocally might also be costly in terms of time and energy consumption. Forinstance, the widely used Raspberry Pi devices used for multiple purposescome with 1.2 GHz processor and 1 GiB RAM. Such devices may be usedfor pre-processing primitive events, however, to process high rates and volumeof complex events may be difficult. Another concern is that sending data overa communication network to a cloud server might consume much energy andbandwidth. This implies a complex trade-off, particularly if local nodes arebattery-powered.

In this research work, we address these limitations of current IoT architecturesby flexible and adaptive CEP enabling in-network query processing guidedby transitions (cf. Section 5) [6, 7]. Therefore, we focus on three importantquestions: (i) where, (ii) how to perform query processing and (iii) how processingoperators over fog-cloud infrastructure affect performance objectives of IoT end-users.

3.1 Traffic Control

According to INRIX 2017, Global Traffic Scorecard5, across 1,064 cities studiedtraffic conditions. Drivers spent an average of nine percent of their time incongestion. The traffic congestion continues to rise if it is left unchecked.A multitude of sensors in smart cities such as smart cameras, environmentalsensors like audio, radars, induction loops and GPS sensors on smart cars (orevent producers) can be used to derive insightful information about traffic.For instance, complex events can be delivered in the form of notifications tothe drivers (or event consumers) regarding the traffic flow, congested roads,unobstructed roads, or warning about road condition and accidents. As a result,drivers can switch to the uncongested roads that would eventually fasten freeingroads from congestion. CEP allows the correlation of the sensor data from eventproducers, e.g., traffic monitoring cameras and radar sensors to derive higher-level information such as a traffic congestion to timely notify the interestedusers. This is accomplished by processing the information in the network, e.g.,at multiple devices (or event brokers) as shown in Fig. 1. We look into threepossibilities of distributed CEP: (i) distributed local/fog CEP, (ii) distributedcloud CEP or (iii) distributed fog-cloud CEP.

Although, devices such as smartphones operate on high-speed processorswith clock frequencies up to 1 GHz, processing big video streams from trafficmonitoring cameras, locally on these low-powered sources may not be resource-efficient. A typical traffic monitoring camera captures at a resolution >=

4Uber autonomous car crash, https://www.technologyreview.com/the-download/

611094/in-a-fatal-crash-ubers-autonomous-car-detected-a-pedestrian-but-chose-to-not/,last access 9.8.2019.

5http://inrix.com/scorecard/, last access 9.8.2019.

5




320 × 240 pixels and frame rate 10fps, i.e., 768,000 pixels/data points persecond, approximately. Recently, researchers at MIT have developed a special-purpose chip that is claimed to reduce the power consumption and speed upthe computation, which can be placed in smartphones6. Yet, until date, thereis no benchmark that evaluates their compatibility and suitability on today’ssmartphones. Processing the video streams at a cloud server might also imposea significant cost in terms of communication latency and bandwidth usage. Onthe other hand, it is convenient to process lower level sensor data, e.g., GPSdata from vehicular sensors at local/fog nodes. A trade-off between executingCEP mechanisms locally or inside the cloud must be considered.

The detection of a complex event like traffic congestion is time- and location-dependent. It is not mindful of sending a notification for traffic congestionwhen it has been cleared (time) or for a road where the user is not traveling(location). Thus, for an accurate and efficient decision, the system must be timeand location-aware but also be aware of other environmental factors (context-aware) that are significant for controlling traffic congestion. For instance, thetraffic conditions are not the same the entire day as they are during rush hours.Therefore, it is evident that we reconfigure CEP mechanisms at runtime inaccord with the traffic conditions as later elaborated in Section 5.

3.2 Smart Health Monitoring

With the commence of the IoT, there is a growing number of devices thatallow for efficient health monitoring including Fitbit, body cardio scale, bloodpressure monitors, Kito+ and many more. CEP allows collaborative processingof information from this variety of sensors to gain meaningful insights on one’shealth and lifestyle, e.g., heart status, sport recommendation, etc. However, tomake full use of these vital sensors, information must be processed quickly andefficiently. The power of cloud can be used to process the information quickly,but transferring data to cloud for processing might be time-consuming and thedelay caused might lead to life-critical situations. Besides, cloud computing canalso be a source of data privacy concerns. The privacy can be protected if thedata is processed locally, either within the sensor, the body or the house orhospital where it was produced. Since users tend to be mobile, once the dataleaves the private sphere, sophisticated CEP mechanisms must be deployed toguarantee the protection of privacy [20]. On the other hand, data collectionand batch processing on the cloud can obtain prevalent insights, e.g., the heartstatus over a year.

Vital signs from various sensors can be used to predict an individual’s healthstatus, e.g., using tools like the Early Warning Score (EWS) system. It is amanual tool widely used in hospitals to track the condition of patients. Itinvolves measuring five physiological parameters namely heart rate, systolic BP,breath rate, SPO2 and body temperature and assigning them a score between 0and 3, with a lower score meaning a better condition [12]. IoT-enabled wearablesfor health monitoring can be used to empower systems like EWS, to continuouslytrack and predict an individual’s health in an automated way. However, thesystem alone faces open issues that must be addressed [12]. Environmental

6MIT neural networks chip, https://news.mit.edu/2018/

chip-neural-networks-battery-powered-devices-0214, last access 9.8.2019.

6




factors influence the vital signs like heart rate etc., which must be consideredto reach a more realistic solution. For instance, a heart rate of 120 beats perminute would be an alarming sign for a patient who is sleeping, while it can becompletely normal if one is exercising. If not considered, such characteristicscan drastically decrease the performance of the system in terms of accuracy andprecision. Corresponding CEP mechanisms are needed to adjust the scores toavoid false alarms [21] as well as to guarantee the protection of privacy in suchsystems [20]. To summarize, there is a strong need to consider adaptive use ofCEP mechanisms to cater the needs of different end-users of IoT applicationsin accord with the environmental context.

4 Challenges

In this section, we summarize the challenges faced by the IoT applicationsstudied in the examples above on traffic control and health monitoring.

Dynamic streaming environment. The streaming environment becomeshighly unpredictable due to the dynamic properties of the environment such asunderlying communication network and mobile devices elaborated as follows.(i) Event streams produced by IoT devices arrive at varying rates, volume andconstantly changing quality (or certainty). For instance, sensor data producedby some devices can be noisy and erroneous, while by other devices can bemore accurate. (ii) The streamed events have to be processed by user devicesthat might be resource- and memory-constrained (cf. Section 3.1). (iii) Due tomobility, some devices might become unavailable for processing. (iv) Lastly, thecommunication network connecting the infrastructure possesses highly fluctuatingproperties, e.g., time-varying latency, bandwidth, etc., that might influence theperformance.

Varying performance objectives. As pointed out earlier in our casestudy, the dynamic streaming environment causes changes in the performanceobjectives of the IoT application. For instance, latency requirements of anemergency service by an ambulance will be significantly more urgent than of anormal user. Similarly, in health monitoring applications, user context such aslocation and activity highly influences the performance perceived – privacy andaccuracy, respectively.

Heterogeneity of infrastructure. The diffused infrastructure of fog-cloud itself is a challenge because of the network and system heterogeneity.(i) Some nodes might have better computational capabilities (e.g., multi-coreGPU-supported CUDA platform at cloud), while some might not have (e.g.,resource-constrained Raspberry Pi at the edge). (ii) Some nodes might begeographically located far away (e.g., cloud nodes), while some might be near(e.g., fog and IoT nodes) that have an influence on the communication latency.The CEP system must prepare for proper coordination and planning of execution,i.e., where to process an operator – on cloud or fog nodes, split an operator tofog and/or cloud nodes or perform parallel processing at both of them. Thedecision varies based on the adaptive selection of CEP mechanisms.

7




5 Mechanism Transition in a CEP system

To meet varying performance objectives of a large number of consumers underdynamic streaming environment as identified in our case studies, we proposeto apply the concept of mechanism transitions in a CEP system. A mechanismtransition is defined as a dynamic exchange of mechanisms to fulfill the performanceobjectives of end-users influenced by dynamic the environment. [5] Towards this,in Section 5.1, we identify CEP mechanisms that can benefit from the conceptof transitions. In Section 5.2, we show the need for transitions particularlyfor one of the most prominent mechanisms of CEP – operator placement – byexperimental analysis.

5.1 Mechanism: Overlay and operator graph transitions

A CEP system detects events of interest by in-network processing of anoperator graph in a distributed manner. For this, a set of nodes, e.g., fog orcloud nodes are selected to deploy the operator graph. Once the operator graphis mapped to these physical nodes, the corresponding topology is often referredto as an operator network or simply an overlay. In this section, we have identifiedkey mechanism transitions in the execution of an operator graph and overlaythat are extremely important components of a CEP system.

5.1.1 Operator Placement in CEP System

The problem of selection of an appropriate node for the assignment of anoperator is well known as an operator placement problem. The operators areassigned to the nodes such that the performance objectives specified by thesystem are achieved. The performance objectives are such that they best satisfythe end user’s requirements. Once the operators are placed on the nodes, theoperator graph is processed in a CEP overlay. It has been proven in theliterature, that an optimal assignment of an operator to a node is an NP-complete problem [22]. Many heuristics and approximation algorithms existfor operator placement [23]. Although, each algorithm provides a solution tooptimally or sub-optimally place an operator on a node they make differentassumptions for the respective problem. The design characteristics of the placementare based on these assumptions and the performance objective(s) (e.g., lowlatency for emergency response in health monitoring application). The dynamicsin the environment as discussed before (cf. Section 4) influence the assumptions,performance objectives and hence the choice of the placement mechanism.

Centralized vs. Decentralized Algorithms

The placement algorithms are characterized based on: (i) how the placementdecisions are made and (ii) whether the decisions require centralized knowledgeabout the environment [23]. The centralized algorithms have central knowledgeabout the environment, e.g., about the network state, workload and resources,whereas the decentralized algorithms make decisions on placement based onthe local knowledge. Apparently, centralized algorithms suffer from scalabilityissues while decentralized algorithms do not. The event workload on the CEPsystem in the IoT applications vary significantly, as specified in our case study,

8




which would have an impact on the performance of the system based on theplacement algorithm in execution. Thus, transitions between centralized anddecentralized algorithms can be explored depending on the event workload.

Static vs. Dynamic Operator Network

Mobility is one of the major causes of dynamics in IoT applications. Decentralizedplacement algorithms can efficiently respond to such dynamic changes at runtimesince only local knowledge is used to make decisions. However, the mobilityconditions vary between different applications, as well as, within the sameapplication. For instance, in a traffic scenario (cf. Section 3.1), the conditionsare known to vary a lot from normal hours to rush hours. During normal hours,one can expect fast movement of cars and sparse traffic conditions. In contrast,during rush hours due to the slow movement, one can expect highly dense trafficconditions and low mobility. The CEP system has to reconfigure its mechanismsto deal with such conditions efficiently. For instance, during rush hours a highlydelay and load efficient mechanism can be deployed to deliver traffic congestioninformation promptly [24]. On the other hand, during normal hours, a highlystable placement that is resilient to short-term bursts of incoming events needsto be deployed to ensure a reliable delivery [25,26]. Efficient transitions betweenthese mechanisms become necessary to deal with the changing environment fromnormal to rush hours.

5.1.2 Elasticity and Fault tolerance in CEP System

It becomes extremely important to deal with challenges like mobility in a smartcity environment. One of the dire consequences of mobility is the sudden failureor unavailability of IoT devices (cf. Section 4). In this section, we have identifiedmechanisms for such scenarios to perform failure recovery and auto-scaling inCEP systems. Secondly, we identify transitions in these mechanisms as follows.

Auto-scaling Strategies

In a CEP system scalability can be provided in two ways: (i) vertical scalabilityor scale up (down) or (ii) horizontal scalability or scale in (out). Scaling up(down) means to add (remove) resources to (from) the nodes, while scalingin (out) means to add (remove) nodes in (from) the CEP overlay network.Techniques like parallel processing (scale up (down)) [4,27] or load partitioningand balancing (scale in (out)) [28, 29] can be used to adapt to decentralizedalgorithms and thereby satisfying the changing workload requirements. Recently,there is an increasing interest in providing such adaptations by using auto-scaling strategies [3]. This work could be a starting point to analyze the CEPoverlay transitions further.

Replication Strategies

High fault tolerance and elasticity can be achieved in a CEP system using twodifferent mechanisms: active replication or rollback recovery. Active replicationdeploys two or more backups of each operator of the operator graph on differenthosts [30]. Each host processes the input streams from the parent which are

9




filtered at the child for duplicates. This approach has a very low recovery time,on the other hand, uses the double amount of resources.

Rollback recovery [31] or upstream backup [32] is another approach thathandles failures in CEP systems by storing checkpoints to recover the stateof an operator at regular time intervals to persistent storage. This approachhas a relatively lower resource footprint, however, relatively higher recoverytime. There has been an interest in developing adaptive replication schemes [33]exploiting the former two approaches that show the significance of mechanismtransition for an elastic CEP system.

5.2 Need for Transitions in Operator Placement

In the view of the challenges discussed above in Section 4, there is a strongneed for transitions of the underlying CEP mechanisms. Current systems neglectthat the CEP mechanism performs well only under the given environmentalconditions, the respective assumptions and performance objectives. However,if dynamics are introduced into the environment, the performance objectivesmight not be met. For instance, higher workload renders the system unreliableand inefficient as observed in the case study presented in Section 3. Besides,the performance needs of a large number of users vary significantly, e.g., foremergency service in traffic control and exercising habits of different users inhealth monitoring. The CEP system must adapt from one placement mechanismto another at runtime to fulfill the performance objectives of a large number ofusers. In our existing work, we show that in this case, an operator placementmechanism transition is well suited [6–8]. We extend this work, to show ourhypothesis that transitions in CEP mechanisms, e.g., operator placement (cf.Section 5.1) over a fog-cloud infrastructure could aid us in fulfillment of performanceobjectives for a large number of users.

5.2.1 Transitions in Operator Placement over Fog-Cloud

The placement of CEP operators in a fog-cloud infrastructure exhibits differentperformance and cost trade-offs based on their computational complexity andnetwork utilization. The communication delays from a fog node to a cloudnode is high, approximately between 50–250 ms depending on the location ofthe consumer and the cloud data center [34]. In Fig. 2, we show an operatorplacement that exhibits varying performance objectives, i.e., high load and lowlatency, which can be dealt by performing a transition from system configurationshown by placement in the left figure to the system configuration and placementin the right figure; a transition arrow illustrates an exchange of mechanism. Inthe following, we give two examples where an operator placement transitionis evident in a traffic scenario using fog-cloud infrastructure. (i) If operatorplacement is performed at a cloud resource, the transmission of each videosegment capturing a car can be delayed by up to 250 ms in addition to theprocessing time. Similarly, the data rates average between 800–1200 Kbps makingthe transmission of video segment even slower [34]. Hence, it is not suitable toplace both latency- and bandwidth-sensitive operators on cloud nodes due tothe round trip time and the lower data rates between cloud and edge nodes.

10




ω

ω⋈

ωV1 ωV2

ω

ω⋈

ωV2ωV1

Cloud

Fog

Things/

IoT

devices

high load

operatorlow

latency

linkTransition

Figure 2: Operator Placement over the Fog-Cloud Infrastructure for conflictingperformance objectives high load and low latency.

At the same time, information exchanged between fog nodes or fog nodesand the cloud might get lost or has to be retransmitted multiple times due tothe mobility of some fog nodes. In such cases, a highly stable placement, e.g.,at the event producers would be suitable to avoid losing any data as well as toensure lower control overhead (messages exchanged to perform the placement).Depending on the performance objective of the user either low latency or highload, placement organized in the left figure or the right figure might be favored.

(ii) The second example where traffic environment is known to vary a lotis between rush hours (high density and slow movements) and normal hours(low density and fast movements). Consequently, a good placement mechanismwill favor the stability of the placement to cope with an environment of fastmovements of cars by placing operators on producers or IoT devices. Conversely,the placement should be highly delay-efficient to keep up with the high eventrates produced under environmental conditions with many vehicles by placingoperators on fog nodes. Here delay efficiency and stability are conflicting demandsthat are hard to be met by a single operator placement mechanism. Consequently,we propose to apply placement mechanism transitions [6]. A placement mechanismtransition allows a dynamic exchange of operator placement mechanisms in aseamless way depending on the environmental conditions at run time. Ourhypothesis is that CEP systems can benefit from the mechanism transitionconcept by exploiting a large number of existing mechanisms, e.g., operatorplacement mechanisms [23] by deployment in a fog-cloud infrastructure.

5.2.2 Experimental Analysis of Operator Placement Mechanisms

To challenge our hypothesis, we analyze the performance of two state-of-the-artplacement mechanisms Relaxation [24] and Mobile DCEP [25] under varyingenvironmental conditions: increasing workload of queries and input events.

Relaxation is based on a so-called cost space that considers latency andload as two dimensions. At the first step, the virtual operator placement isperformed using the cost space, and in the next step physical operator mappingis performed to the topology using KNN (K-nearest neighbors algorithm). Onthe other hand, the placement decision in Mobile DCEP is made locally, and nocost information is shared among the nodes resulting in lower communicationoverhead and achieving a stable operator placement near to the data sources.

We measure the performance of the two algorithms in terms of their definedperformance objectives for the operator placement, (i) end-to-end latency, i.e.,the total time until a complex event is received by the event consumer and

11




Experiment run-time 20 min, 2 min warm-upSampling interval 5 sec

Number of producers 2Number of brokers 10Number of consumers 4Input Event Rate 10, 100, 1000 events/secNumber of queries 50QoS Demands latency, message overheadDelay and Jitter min. 20±10 ms, max. 100±

50 ms (normal distribution)

Operator placementmechanisms

Relaxation [24], MobileDCEP [25]

Table 1: Configuration parameters for the experiment.

(ii) control message overhead, i.e., the communication overhead required toperform a stable operator placement, respectively. We use a traffic congestionquery on TCEP [6,8] a transition-capable CEP system, which is a platform thatenables an experimental evaluation of operator placement algorithms. TCEPis based on Akka7 and uses the actor programming model to develop a CEPsystem, where each component event consumer, event producer and event brokeris an actor, who communicates by passing messages. In addition, it providesan interface to the domain specific language AdaptiveCEP [35] to specifycomplex events as a query with a performance objective (e.g., latency) to theTCEP system. We use stream workloads of vehicle events based on an opendataset of a Madrid highway [36] containing vehicle speed and vehicle densitytuples for two road sections, consistent to our traffic scenario (cf. Section 3.1).

Each actor in the distributed TCEP application is encapsulated inside aDocker container on a VM with 32 GiB of memory and 8 cores on an Intel(R)Xeon(R) E5-2620 v2 server. To emulate the fog-cloud infrastructure, we usenetem, with the delay being minimum at the fog and maximum at the cloudnodes as stated in Table 1.

We evaluate the algorithms under changing environmental conditions in theform of (i) number of queries (by incrementally increasing the query load to upto 50 queries) and (ii) number of incoming events (increasing event rate to upto 1000 events per second). We repeat the execution 10 times to compute the95% confidence interval of the measurements. The different parameters usedfor the emulation are summarized in Table 1. The network delay and jitter areapplied as the minimum at the lower end (at fog and IoT devices) and as themaximum at the higher end (at the cloud) – consistently with the fog-cloudhierarchy in Fig. 2. The graphs show a bar plot where the point is the meanof the distribution and the error bar shows the upper and lower bound of theobserved values.

Fig. 3 shows the confidence interval measurements on (i) average end-to-endlatency (in ms) and its density distribution, and (ii) average control messageoverhead (in KB) observed for the placement algorithms over an increasingnumber of queries. In Fig. 3a on the left side, we show the confidence intervalsthat confirm that Relaxation achieves consistently very low average end-to-endlatency even for a higher workload of queries. On the right side, the densitydistribution of average latency for the two algorithms further clarifies that for

7http://akka.io/, last access 9.8.2019.

12




● ● ●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●

●●●●

●●●●●

●

●

●

●●

●

●●●●●

0

5000

10000

25 50 75 100

% of Queries

Avg

. Lat

ency

(ms)

010002000300040005000

0.00

0.25

0.50

0.75

1.00

distribution of Y

Avg

. Lat

ency

(ms)

Mobile DCEPRelaxation ●

(a) Relaxation achieves lower average latency thanMobile DCEP.

● ● ● ● ● ● ●● ●

% of Queries

Avg

. Ove

rhea

d (K

B)


25 50 75 100

2000

1500

1000

500

0

(b) Mobile DCEP achieveslower overhead thanRelaxation.

Figure 3: Impact of incrementally increasing the number of queries on theperformance of the placement mechanisms.

●●

●

10 100 1000

● Mobile DCEP

Input Event Rate (events/s)

Avg

. Lat

ency

(ms)

Relaxation

100

50

0

(a) Relaxation consistentlydelivers complex events at a lowerlatency than Mobile DCEP.

● ● ●0

300

600

900

1200

10 100 1000Input Event Rate (events/sec)

Avg

. Ove

rhea

d (K

B)


(b) Mobile DCEP consistentlydelivers complex events at a loweroverhead than Relaxation.

Figure 4: Impact of increasing the number of input events on the performanceof the placement mechanisms.

Relaxation the latencies lie below 100 ms for most number of queries. Fig. 3bshows that low latency comes at the cost of higher control message overheadthat increases linearly with the number of queries. Conversely, Mobile DCEPposes a very little increase in overhead but at the cost of very high latency(∼7.5s on average) for the 100% query workload.

Similarly, in Fig. 4, we evaluate the performance of the algorithms undervarying input event rate (cf. Table 1) for the two metrics: (i) latency and(ii) overhead. Consistent with the earlier results in Fig. 4a, for Mobile DCEP,we observe an increase in the average latency with the growing event rate.Inversely, in Fig. 4b, an increase in the overhead is observed for Relaxation.Interestingly, there is only a little or no increase in latency and overhead forRelaxation and Mobile DCEP, respectively, for a growing event rate.

In summary, we plot the results in Fig. 5 by collecting over ∼10,000 datapoints for each algorithm. The results show that (i) there is a strong trade-offbetween the two metrics latency and control message overhead. Hence, theseare indeed conflicting demands and (ii) there are only a few or no pareto optimalsolutions observed.

13




● ●●●●●●●●●●●●●●● ●●●●●●●●●●●●●●●●●●●●● ●●●●●●● ●● ●●●●●●●●●●●●●●●●●● ●●●●● ●●● ●●●●●

●●●●●●●●●● ●●●●●●● ●●●●● ●●● ●●●●●●●●●● ●●●●●●●●●● ●●● ●●●●● ●●● ●●●● ●●●●●● ●● ●●●●● ●●●●●●●●●●●●●● ●●●●●●●● ●●●●●●● ●●●●●●●●●●●●●●●● ●●● ●● ●● ● ●●●●● ●● ●●●●●●●● ●● ●●● ●●● ● ●●●

●●● ●●●●●●●● ●●●●●●●●●●●●●●●● ●●●● ●●●●●● ●●●●●●●● ● ●●● ●●● ●●●● ●●● ●●●●●●● ●●●●● ● ●●●●●●●●●●●●●●●●●●●●●●●●●●● ●●● ●●●●●●●●●●●● ●●● ●●●● ●●●● ●●● ●● ● ●● ●●●●●●●●●●●●●●● ●●●●●●● ●●●●●●● ●● ●●●●● ●●●●●● ●● ●● ●●●● ●●●●● ●●●●● ●● ●● ● ●●● ● ●● ●● ●● ●●●●●●●● ●●● ●●●●● ●●●●

●● ●●● ●●● ●●●●●●●● ●●●●●● ●● ●●●●●●●●●●●● ●●●● ●●● ●●●●●●●●●●●●●● ●●●● ●● ●● ●●●●● ●● ●● ●●

●● ● ●●●● ●● ●●●●●● ●●●●●●●● ●● ●●● ●● ●●●●●●●●●●●● ● ●●●● ●●●●●●●● ●● ●●● ●●● ●●● ●●● ●●● ●●●●● ●●●●●● ●● ●●●● ●●●●●● ●●● ●●●●●● ●●●●●● ●●●●● ●●● ●●●●●●●●● ●● ●●● ●●●● ●●●● ● ●●●●●●● ●● ●●

●●●● ●●●●● ●●●●● ●●●●●●●●●●●●●● ●●● ●●● ●●●● ●●●●●● ●●●●●● ●●● ●●● ●●●● ●●● ●● ●● ●●●● ● ●●● ●

●● ●●●●●● ●●●●●● ●●● ●● ●●●●●●●●●● ●● ●●●●● ●●●● ●●●● ●●● ●● ●●● ●● ●●● ●●●●● ●●● ●● ●●●● ●● ●●● ●● ● ●●●●● ●●●●●●●●● ●●● ●●●●●●●● ●●●● ●●●●● ●●●● ●●● ●●● ●●●● ●●●● ●● ●●●●●●●●●● ● ●●● ●●●●● ●●

● ●● ●●●●●●●●●●●● ●●●● ●●●●●● ●●●●● ●●● ●●● ●● ●● ●●●●●● ●● ●●●● ● ●●●●●● ●●●●● ● ●● ●●●●● ●●●● ●●● ● ●●●●● ●● ●● ● ●●●●●● ●●●●●●●● ●●● ●●●●●● ●●●●●● ●●●● ● ●● ●●● ●● ●●●●●● ●●●● ●●● ●●● ●●● ●●●

●● ●●●●●● ●●●●● ●●● ●●● ●●●● ●●●●●● ●●● ●● ●● ●●●●● ●●●●● ●●● ●●● ●● ●●● ●●●●● ●●●●● ●● ●●● ●●●●●

●● ●● ●● ●●●● ●●●●●● ●●● ●●●●●●● ●●● ●●●● ●● ●●●● ●● ●●● ●● ●●● ● ●●●●● ●● ●●● ●●●● ● ●● ● ●●●●● ● ●●●

● ●●● ●● ●●●● ● ●●●●●●●●●●●●●●● ●●● ●● ●● ●●● ●●●●●●● ●●● ●●● ●●●● ●● ●● ●● ●● ●●● ●● ●●●●● ●●● ●●

● ●●●●●●● ●● ●●●●● ●●● ●● ●●●●●● ● ●●●●● ● ●● ●●●●●● ● ●● ●●●●●●● ●●●●●●●● ●●●● ●●●● ●● ●●● ● ●●●

●●●●●●●● ●● ●●●●● ●●●●●● ●●● ●●●●●●● ●●● ● ●● ●● ●● ●● ●●●●●●●●●● ●● ●● ● ●●● ●●● ●●●●●● ●●● ● ●●●● ●● ●●●●●● ● ●●●●●●●●● ● ●●● ●●●●● ●●●●● ●● ●● ●●●●●●●● ● ●●●●● ●● ●●● ●●● ●●●●● ●●● ●● ●● ●● ●●●

●●●●●●● ●●● ●●●●●● ●●● ●●● ●●●●●●●●●● ● ●●● ●●● ●● ●● ●●● ●●●●●●●● ●● ●●●● ●●● ●●●● ● ● ●● ●●● ●●

●● ●●●● ●●●●●● ●●● ●●● ●●●● ●● ●● ● ●●● ● ●●●● ●● ●● ● ●● ●● ●●●● ● ●●●● ●● ●● ●●●●● ●●● ●● ● ●●●● ●●●●

●●● ●●●● ●● ●●●● ●●●● ●●●●● ●● ●●● ●● ●● ●●●● ●●●● ● ●● ●● ●●● ●●●●●● ●● ●● ● ●● ●●● ●●● ● ● ●● ●● ●●●

●● ●● ●●● ● ●●●●●●● ●●●●●● ● ●● ●● ●● ●●● ●● ● ● ●●● ●●●● ● ● ●●● ●●● ●●● ●● ●●● ●● ●●●● ●● ●● ● ●● ●●●●● ●●●● ● ●●● ●●●●●●●● ●●●● ●●● ●● ●● ● ●●●●● ●● ●● ● ●●●● ●●● ● ●● ●●● ●● ● ●● ●●●●●● ●● ● ● ●● ●● ● ●●

●●● ●● ●●● ●●●● ●●●●●●● ●●● ● ● ●●● ●●●● ●●● ● ●● ●● ● ●●●● ●● ●●●●●●● ●● ●● ● ●●●● ●●●● ● ● ●●●● ●●●● ● ●●●● ●●●● ●● ●●● ●●●●●●●●●●● ● ●● ● ●●●●● ●●● ●● ●● ● ● ●●● ●● ●●●●●● ● ● ●● ●●● ●● ● ●●● ● ●●●● ●●

● ●● ●●● ● ●●●●●●●●●● ●●●●● ●● ●●● ●●● ● ●●●● ●●● ●● ●●●● ●● ●● ●●● ●● ●●● ● ●● ●●● ●● ● ●●● ● ●● ● ●●●

● ●●●● ●● ●● ●●● ●●●●● ●● ●●●●● ●● ● ●● ●●●●● ●●●● ●● ●● ●●● ●● ● ●●● ● ●●● ● ● ●●● ● ● ●●● ●●● ● ●● ●●●●●

● ●●● ●● ● ●● ●●● ●●● ●● ●● ● ●●● ●●●● ●● ●● ●●● ●●●● ●●●●●●● ●● ●● ●●● ●●●●●●●● ●●● ●● ●●●●●● ●●●●●

● ●●●●● ●● ● ●●●●●● ●● ●●●●● ● ●●● ● ●●●●●● ●●● ●●●●●● ●●●● ●● ●● ● ●●●●● ●● ●●● ●● ●● ● ●●●●● ●●●●●● ●● ●●● ●● ● ●●● ●●● ● ● ●●● ●● ●●● ● ●●●●● ●●● ●●● ● ●●●●●●● ●●● ●●● ●●● ●● ●● ●●● ●●●● ●●●● ●● ●●●●●

● ● ●● ●● ●● ● ●●● ●●● ●● ●●●●● ● ●●●● ●●●●● ●● ●● ●● ●● ●●●●● ●● ●●●● ●●● ●●●● ● ●●●● ●● ●●● ●●●●●● ●●

●● ●● ●●●●● ●●● ●●● ●● ●●● ●● ● ●●● ● ●●●●● ●● ●● ●● ●●●● ●●● ●●●● ●●● ● ●●● ●●●●● ●● ● ● ●●●●●● ●●●●●●● ●●● ●●●● ●●● ●● ● ●● ●●● ●●● ● ●●●●●● ●●●● ●●●● ●● ●●●●●●● ● ●●● ●● ●●●● ●● ● ●●● ●●●● ●● ●● ●●●●●

●● ●●●● ● ●● ●●● ●●●●● ●● ● ●●● ●●●●●●●●● ●● ●● ●● ● ● ●●●● ●●●● ●● ●●●● ●●●●● ● ●●●● ●●●●●●● ●●● ●●

●●●●● ●●●●●●● ●●●● ●●●●● ●● ● ●●● ● ●●● ●●● ●●●●● ●● ●●●●●●●●●●●●●● ●●●●●●● ●●●●●●●●● ●●●●●●●● ●●●●●●●● ●●●●●●● ●●● ●●● ●●●● ●● ●●● ●●●●● ●● ●●●● ●●●●● ●●●●● ●●●●●●●●●●● ●●●●● ●●●● ●●●

● ●●●●●● ●●●●● ● ●● ●●●● ●●● ●●●●●● ●●●●●●●● ●●● ●●●●●●●●●●●●●●● ●●●●●● ●● ●●●●● ●● ●●●●● ●●

● ●●● ●●● ●●●● ●●●●● ●● ●●●● ●●●● ●● ●●●● ●● ●●●●● ●●●●●●●●●● ● ●●●●● ●●●●● ●● ●●● ●●●●● ●●●● ●●

● ●●●●●● ●●●●● ●●●●● ● ●●● ●●●●● ●●●●●● ●●●● ●●● ●●●● ●● ●●●●●●●● ● ●●● ● ●●●●● ●●●●●●●● ●●●●●

● ●●●● ●●● ●● ● ●●● ●● ●●●●● ●●●●●●● ●●●●●●●●●●● ●● ●●●● ●●●●●●●●●● ●●●●●● ●●●●●● ●●●● ●●●● ●

●●●●●●● ●● ●●● ●●●● ●●● ●● ●●●● ●●●●●●●● ●●● ● ●●●● ●● ●● ●●●●●●●●●● ●● ● ●●●●●●● ●●● ●●●●●●●●

● ● ●●●●●●●● ●● ●●● ●● ●●●●● ●●● ● ●●●●● ●●● ●●●● ● ●●●● ●● ●●●● ●●●●●●● ●●●●●●●●● ●●● ●●●●●● ● ●

● ●● ●●●●●●●●●● ●●● ●● ●● ●● ●●●●●● ●● ●●●●●● ●●● ●●●● ●● ●●●●● ●● ●●●●●● ●●● ●●●●●●●●● ●●●●● ●

●●●●●●●●●●● ● ●●●●●●●●●●● ●●●●● ●●●● ●●●● ●●●●● ●● ●● ●●● ●● ● ●●● ●● ● ●● ●●●● ●●●●●●●●

● ●●●●●●● ●●●●●● ●●●●●●● ●●●●● ● ●●● ●●●● ●● ●●●● ● ●●● ●●●● ●●●●● ●●●● ●● ●●●●●● ●●●● ●●●●●●●

●● ●●●●●● ●●● ● ●● ●●●● ●●● ●●●● ●● ●●● ●●●●●● ●●●●●● ●●●● ●●●●●●●● ● ●●●●● ●●●●● ● ● ●● ●●● ●●●●● ●●●●●●● ●●●●● ●●● ●●●●●● ●●●● ●●●● ●●● ●● ●●●●● ●●●●● ●●● ●●●● ● ●●● ●●● ●●● ● ●●● ●● ● ●●●●●●●● ●●●●●●● ●●●●●● ●● ●●● ● ● ●●●●●● ●●●● ●●● ●● ●●●●● ●●●● ●●●●● ●●●●● ●● ●● ●●●●●● ●●●●●●●●●●●

●● ●●●●● ●●●●●● ●●●●● ●●● ●●● ●●●●●●● ●●●● ●●● ●●●●●●● ●●●●●●●●● ●●●●● ●●●●● ● ● ●●● ●●●●● ●

●● ●●●●●●●● ●●●●●●● ●●● ●●●●●●●●●● ●●●● ●●●●● ●●●● ●●●● ●●● ●●●●● ● ●● ●● ●●●●●●●●● ●●

●● ●●●●●● ●●●● ● ●●●●● ●●●●●● ●●●●●● ● ● ●●●●●●●●● ●● ●● ●●●● ●●● ●● ● ●● ●●● ●●●●● ●

●●●●●●●● ●●●●●●●● ●●● ●● ●●●●●●●●● ●●●●●● ●●●● ●● ●●●●● ●●●●●● ●●● ●●●●● ●●●●●●● ●● ●

●●●● ●●●●●●● ●● ●●●●●● ●●●●● ● ●●●● ●●●●● ●●●●●● ●●●●●●● ●●●● ●●●●●● ● ●●● ●●●●● ●● ●●●● ●

Avg

. Ove

rhea

d (K

B)

Avg. Latency (ms)Relaxation ●Mobile DCEP

No one-sizefits all solution

0 ... 30000...0

1500

(a) Impact of increasing the number ofqueries on latency and message controloverhead.

● ●●● ●● ●●●●●● ●●●●● ●●● ●●●●● ●●●●●●●●●●● ●●●● ●●●● ●● ●●● ●●●● ●●●● ●● ●●●●● ●●●●●●●● ●●●●

●● ●●●●●●● ●●● ●● ●●● ●●● ●●●● ●●●● ●●● ●● ●● ●● ●●● ●● ●●●●● ●●●●● ●●● ●●●●● ●●● ●●●●● ●●●●●● ●●●

●●●● ● ●●●●● ●●●● ●●●●● ●●● ●● ●●● ●●● ●●● ●●●●● ●●●● ●●●● ●● ●●●● ●● ●●●●●● ●●●●●●●●● ●● ●●●●●●

●● ●● ●●●●●●● ●●●● ●● ●●●●● ●● ●●●●●● ●●●●●●● ●●●● ●●●● ●● ●● ●●● ●●●●●●● ●●●● ●● ●●●● ●●●● ●● ●●

●●● ●●● ●●● ●●● ●●●● ●●● ●●● ●●● ●●●●●●● ●● ●● ●●●●● ●● ●●● ●●● ●●●● ●●●●●●● ●●● ●●●●● ●● ●●● ●●● ●

●●●● ●●●●● ●●●● ●● ●●●● ●● ●●●● ●● ●●●●● ●●●●●●●● ●●●●● ●●●● ●●● ●●●●● ●● ●● ●●●●●●● ●●●●●●●●

●● ●●●●● ●● ●●● ●●●● ●●●●●●●●●●●●●●●●● ●●● ●●●●●● ●●●●●● ●●●●● ●●●●●● ●● ●●● ●●●●● ●●●●● ●●●

●●●●●● ●●●●●● ●●●●● ●●●● ●●●●●●●● ●● ●●●● ●●●●●● ●●● ●● ●●●●●●● ●● ●●● ●● ●●● ●●●●● ●● ●●● ●●●

●●●●●● ●●● ●●●●●● ●●● ●●● ●●●●●●●● ●●●●● ●●● ●●● ●●●●●●●● ●●●●● ●●●● ●●●●●●●● ●●● ●●●●● ●●●●

●● ●● ●●●●● ●●●●● ●●●● ●●●●●●●●● ●● ●●●● ●●● ●●●●● ●●●●● ●●●●● ●● ●● ●●●●●● ●●●● ●●●● ●● ●●● ●●●

●● ●●● ●●●●● ●●●● ●●●● ●● ●●●●●●●●●● ●● ●●● ●●●●●●●●● ●●● ●●● ●●●● ●●●● ●●●●●●● ●● ●●● ●● ●●●● ●

●● ●●●●● ●● ●●●●● ●●● ●●● ●●●●●●●●● ●●●●● ●● ●●●●●●● ●●●●● ●●●● ●●● ●●●●● ●●● ● ●●●●●● ●● ●●●●

●●●● ●●●● ●● ●●●●●●●●●●●● ●● ●●●● ●● ●●● ●●●●● ●● ●●●●●●● ●●● ●●●●● ●● ● ●● ●●● ●● ● ●●● ●●●● ●●●

● ●●● ●●●●● ●●●● ●●● ●●● ●●● ●●●● ●●● ●●● ● ●● ●●●●● ●● ●●●●● ●●● ●●●●● ●● ●● ●●●● ●●●● ●● ●●●●● ●●

●● ●● ●●● ●●●●●● ●●● ●● ●●●●● ●● ●● ●● ●●● ●●●● ●● ●●● ●● ●●●●●●● ●●●●● ●●● ●●●●●●●●●●● ●●● ●● ●●

●●●●● ● ●●●●● ●● ●●● ●●●● ●●● ●●● ●●● ● ●●●●●●● ●●●●● ●●●●● ●● ●●●● ●● ●●● ●● ●●● ●●●● ●●● ●●●●● ●

●●● ●●● ●●● ●●●●● ●●●● ●●●●● ●●●●● ●●●●●● ●●● ●● ●●●● ●●●●●●●●●●● ●● ●●●● ●●●●● ●●● ●● ●●●●● ●

●●● ●●●●●●●●● ●●●● ●●●● ●●●● ●●● ●●● ●●●●●● ● ●● ● ●●●● ●●●●● ●●●●●● ●●● ●● ●●● ●●●●● ●●●● ●● ●●

●● ●● ●● ●● ●● ●● ●●●● ●●● ●●● ●● ● ●●● ●● ●●●●●●●●●● ●●●●●●● ●●● ●● ●●●● ●● ● ●●● ●● ●●● ●● ●● ●●●● ●

● ●● ●●●●● ●●●●●● ●●● ●●● ●●●● ●●● ●●●● ●● ●● ●●●● ●●● ●●●● ● ●●●● ●●●●●●●● ●● ●●●● ●●●● ●●●●●●●

●● ●●● ●● ●●●●●●● ●●●● ●●●●● ●●● ●● ● ●● ●● ●●●●● ●●● ● ●● ●● ●● ● ●● ●● ●● ●●● ●●● ●●● ● ●●●● ● ●● ●●● ●●

● ●●●● ● ●●●● ●●● ●● ●● ●● ●●● ● ●● ●●●●●● ● ●● ●● ● ●●● ● ●● ● ●● ● ● ●●● ●● ●● ●● ●●●● ●● ●● ●● ● ●●●●● ● ● ●

● ●● ● ●●●● ●●● ●●●●● ● ● ●●●● ● ●● ●● ●● ● ●●●● ●●● ●● ●●● ●● ● ● ●●● ●●● ●● ●●● ●● ●● ● ●●● ●● ●● ●● ●● ●●●

●● ●● ●●●● ●● ● ●●●●● ●●●●● ●●● ●●● ●● ●●●●● ● ● ●●● ● ●●●●● ●● ●●● ●●● ●● ●●● ●●● ● ●●●● ● ●● ●●●●● ● ●

●●● ● ●●● ●●● ● ●● ●●●● ●● ●● ● ●● ●●● ● ●●●●● ●●● ●●●●● ● ●● ●● ●● ●●● ● ●● ●● ●●● ●● ●● ● ●● ●● ● ●●●● ● ●●

● ● ●● ●● ●● ●●● ● ● ●●● ●● ● ●●● ●●● ●●●●●●● ● ●● ● ●●● ● ●●● ●● ●●●●●●●● ● ●●● ●● ●●● ●●●●● ● ● ●● ●● ● ●●

●● ●●● ●●● ● ●●●● ●●● ●●● ●●●● ●● ● ●●● ● ●●● ●●● ● ●●●● ● ●●●● ●● ●

●●●● ●●●●●●● ●●●●● ● ●●● ●●●●● ●● ●●●●● ●● ● ●●●●● ● ● ● ●●● ● ●●●●● ●●● ●●● ●●●●●●● ● ●● ●●● ●● ●●●

●● ●●● ●● ●● ●●● ●● ●● ●●●●●●● ●●● ● ●● ●●●● ●● ●● ●●●● ● ●● ● ●●●● ●●● ●● ● ●● ●●● ●● ●●●●●●●●● ●● ●● ●

●● ●● ● ●●●● ●● ●●● ●●●● ●● ●● ●●●● ● ●● ● ●●●●●● ●● ●●● ●● ●●●●● ●● ●●●● ●● ●● ●●● ●● ● ●●●● ●●● ●● ●●●

●●● ●●●● ●●● ●●● ●● ●●● ●●●●●●● ●● ●● ● ●●●●● ●●●●● ●●●●● ●● ● ●●● ●●● ●●● ● ●●●● ●● ●●●●●●● ●●●●●●

●●● ●●● ●●●●●●●● ●● ●●●● ●●●●●● ●● ●● ●●● ●●●●● ●●●●●● ●● ●●● ●●● ● ●●● ●● ●●● ●●● ● ●● ●●● ●●●●●●●

● ●●●● ●●● ●● ●●● ●●●● ●●● ●●●● ●●●● ●● ● ●● ●●● ●●●● ●●●● ●● ● ● ●●●● ●●●●●● ●●● ●●●● ●●● ●● ●●●●●●●

● ●●●●●●●●●●●● ● ●● ●● ●●● ●● ●●● ●● ●● ●● ●●●● ●●● ●●●●●● ●●●●●●●● ●● ●● ●●●● ●● ● ●● ●● ●●● ●● ●● ●●

● ●● ●●●●● ●● ●●●● ●●● ● ●●●● ●●● ●● ●● ●●●● ● ●● ●● ●●● ●●● ● ●● ●●●● ●●● ●●● ●● ●● ●● ●● ●●● ●●● ●● ●● ●

● ●● ●●● ●● ●● ●●● ●● ●●●●● ●●● ●●●● ●● ●●● ●●●●● ●●● ●●●●● ●●●● ●●● ●● ●●●● ●●● ●● ● ●●●●●● ●● ●●●●●

●●●●● ●●● ●●● ●●● ●●●● ●●● ●● ● ●●● ●●● ●● ●● ●●● ●●●● ●●●●● ●●● ●●● ●●●●● ●●● ●●● ●● ●●●● ●●● ● ●●●

● ● ●●● ●●● ● ●●●●●●●●● ●● ●●●●● ●●● ●●● ●●● ●●●●● ●●● ●● ●●●●● ●●●● ● ●● ●●●●●● ●●● ●● ●●●●●● ●● ●

●●●●● ●●●● ●●● ●●●●● ●●● ●● ●●●●●●●● ●●● ●●● ●●●● ●●● ●● ●● ●●●● ●●● ● ●●●● ●● ●●●● ●● ●●●●● ●●●●

●●●●●● ● ●●●●● ●● ●●● ●● ●● ●●●● ●●●● ●●● ●●● ●●● ●●● ●● ●●●● ●●●● ● ●●●● ●● ●●● ●● ●●● ●●●● ● ●●●●●

Avg

. Ove

rhea

d (K

B)

Avg. Latency (ms)

No one-sizefits all solution

Relaxation ●Mobile DCEP

0 430... ...1

1500

(b) Impact of increasing the number ofinput events on latency and messagecontrol overhead.

Figure 5: There are no or very few pareto-optimal or best in both objectivessolutions observed for the two placement algorithms.

6 Conclusion and Future Work

In this paper, we motivated in the context of a CEP system, the benefits ofmechanism transitions to increase flexibility in fog computing. We presented acase study on the Smart City environment for two different applications, trafficcongestion control, and smart health monitoring. Several use cases are identifiedwhere transitions in CEP mechanisms can be beneficial with the assistanceof a fog-cloud infrastructure. We identified important CEP mechanisms fortransitions corresponding to the use cases in our case study. Finally, we presentedan experimental analysis of the state-of-the-art operator placement mechanismsto identify the conflicting performance objectives that cannot be satisfied byone operator placement and hence proving the need for transitions. Intuitively,transitions are costly, and therefore in the near future, we will look into the costand benefits of transitions concerning the scenarios defined above.

Acknowledgment

This work has been co-funded by the German Research Foundation (DFG) aspart of the project C2 within the Collaborative Research Center (CRC) 1053 –MAKI.

References

[1] P. Samulat, Die Digitalisierung der Welt: Wie das Industrielle Internet derDinge aus Produkten Services macht. Wiesbaden: Springer FachmedienWiesbaden, 2017, pp. 103–124.

[2] B. Ottenwalder, B. Koldehofe, K. Rothermel, K. Hong, D. Lillethun, andU. Ramachandran, “MCEP: A Mobility-Aware Complex Event ProcessingSystem,” ACM Transactions on Internet Technology (TOIT), vol. 14, no. 1,pp. 1–24, 2014.

[3] T. Heinze, Z. Jerzak, G. Hackenbroich, and C. Fetzer, “Latency-aware elastic scaling for distributed data stream processing systems,” inProceedings of the 8th ACM International Conference on Distributed Event-Based Systems, 2014, pp. 13–22.

14




[4] V. Gulisano, R. Jimenez-Peris, M. Patino-Martınez, C. Soriente, andP. Valduriez, “Streamcloud: An elastic and scalable data streamingsystem,” IEEE Transactions on Parallel and Distributed Systems, vol. 23,no. 12, pp. 2351–2365, 2012.

[5] B. Alt, M. Weckesser, C. Becker, M. Hollick, S. Kar, A. Klein, R. Klose,R. Kluge, H. Koeppl, B. Koldehofe, W. R. KhudaBukhsh, M. Luthra,M. Mousavi, M. Muehlhaeuser, M. Pfannemueller, A. Rizk, A. Schuerr,and R. Steinmetz, “Transitions: A protocol- independent view of the futureinternet,” Proceedings of the IEEE, pp. 1–12, 2019.

[6] M. Luthra, B. Koldehofe, P. Weisenburger, G. Salvaneschi, and R. Arif,“Tcep: Adapting to dynamic user environments by enabling transitionsbetween operator placement mechanisms,” in Proceedings of the 12th ACMInternational Conference on Distributed and Event-based Systems, 2018,pp. 136–147.

[7] M. Luthra, “Adapting to dynamic user environments in complex eventprocessing system using transitions,” in Proceedings of the 12th ACMInternational Conference on Distributed and Event-based Systems, 2018,pp. 274–277.

[8] M. Luthra, S. Hennig, and B. Koldehofe, “Understanding the behavior ofoperator placement mechanisms on large scale networks,” in Proceedingsof the 19th ACM/IFIP/USENIX International Middleware Conference:Posters and Demos, 2018.

[9] “Cisco: Fog Computing and the Internet of Things: Extend the Cloud toWhere the Things Are,” https://www.cisco.com/c/dam/en us/solutions/trends/iot/docs/computing-overview.pdf, accessed 22.11.2018.

[10] C. C. Byers, “Architectural imperatives for fog computing: Use cases,requirements, and architectural techniques for fog-enabled iot networks,”IEEE Communications Magazine, vol. 55, no. 8, pp. 14–20, Aug 2017.

[11] F. Bonomi, R. Milito, J. Zhu, and S. Addepalli, “Fog computing and itsrole in the internet of things,” in Proceedings of the First Edition of theMCC Workshop on Mobile Cloud Computing, 2012, pp. 13–16.

[12] M. A. Rahmani, L.-S. P. Preden, and A. Jantsch, Fog Computing in theInternet of Things. Springer International Publishing, 2018.

[13] P. Hu, S. Dhelim, H. Ning, and T. Qiu, “Survey on fog computing:architecture, key technologies, applications and open issues,” Journal ofNetwork and Computer Applications, vol. 98, pp. 27–42, 2017.

[14] X. Chen, “Decentralized computation offloading game for mobile cloudcomputing,” IEEE Transactions on Parallel and Distributed Systems,vol. 26, no. 4, pp. 974–983, 2015.

[15] X. Hou, Y. Li, M. Chen, D. Wu, D. Jin, and S. Chen, “Vehicularfog computing: A viewpoint of vehicles as the infrastructures,” IEEETransactions on Vehicular Technology, vol. 65, no. 6, pp. 3860–3873, 2016.

15




[16] M. Ahmad, M. B. Amin, S. Hussain, B. H. Kang, T. Cheong, and S. Lee,“Health fog: a novel framework for health and wellness applications,” TheJournal of Supercomputing, vol. 72, no. 10, pp. 3677–3695, 2016.

[17] B. Richerzhagen, B. Koldehofe, and R. Steinmetz, “Immense Dynamism,”German Research, vol. 37, pp. 24–27, 2015.

[18] A. Mathur, T. Newe, W. Elgenaidi, M. Rao, G. Dooly, and D. Toal, “Asecure end-to-end iot solution,” Sensors and Actuators A: Physical, vol.263, pp. 291–299, 2017.

[19] A. Munir, P. Kansakar, and S. U. Khan, “Ifciot: Integrated fog cloud iot:A novel architectural paradigm for the future internet of things.” IEEEConsumer Electronics Magazine, vol. 6, no. 3, pp. 74–82, 2017.

[20] S. M. Palanisamy, F. Durr, M. A. Tariq, and K. Rothermel, “Preservingprivacy and quality of service in complex event processing through eventreordering,” in Proceedings of the 12th ACM International Conference onDistributed and Event-based Systems, 2018, pp. 40–51.

[21] G. Cugola, A. Margara, M. Matteucci, and G. Tamburrelli, “Introducinguncertainty in complex event processing: Model, implementation, andvalidation,” Computing, vol. 97, no. 2, pp. 103–144, 2015.

[22] F. Starks, V. Goebel, S. Kristiansen, and T. Plagemann, “MobileDistributed Complex Event Processing - Ubi Sumus ? Quo Vadimus ?”Mobile Big Data- A Roadmap from Models to Technologies, Springer, no. 1,pp. 1–34, 2017.

[23] G. T. Lakshmanan, Y. Li, and R. Strom, “Placement strategies for internet-scale data stream systems,” IEEE Internet Computing, vol. 12, no. 6, pp.50–60, 2008.

[24] P. Pietzuch, J. Ledlie, J. Shneidman, M. Roussopoulos, M. Welsh, andM. Seltzer, “Network-aware operator placement for stream-processingsystems,” in Proceedings of the 22nd International Conference on DataEngineering, 2006, pp. 49–49.

[25] F. Starks and T. P. Plagemann, “Operator placement for efficientdistributed complex event processing in manets,” in 2015 IEEE 11thInternational Conference on Wireless and Mobile Computing, Networkingand Communications, 2015, pp. 83–90.

[26] Y. Xing, J.-H. Hwang, U. Cetintemel, and S. Zdonik, “Providing resiliencyto load variations in distributed stream processing,” in Proceedings ofthe 32nd International Conference on Very Large Data Bases. VLDBEndowment, 2006, pp. 775–786.

[27] R. Mayer, B. Koldehofe, and K. Rothermel, “Predictable low-latency eventdetection with parallel complex event processing,” IEEE Internet of ThingsJournal, vol. 2, no. 4, pp. 274–286, 2015.

16




[28] X. Liu, A. Harwood, S. Karunasekera, B. Rubinstein, and R. Buyya,“E-storm: Replication-based state management in distributed streamprocessing systems,” in 46th International Conference on ParallelProcessing, 2017, pp. 571–580.

[29] B. Satzger, W. Hummer, P. Leitner, and S. Dustdar, “Esc: Towardsan elastic stream computing platform for the cloud,” in 2011 IEEE 4thInternational Conference on Cloud Computing, 2011, pp. 348–355.

[30] M. Balazinska, H. Balakrishnan, S. R. Madden, and M. Stonebraker,“Fault-tolerance in the borealis distributed stream processing system,”ACM Transactions on Database Systems, vol. 33, no. 1, pp. 1–44, 2008.

[31] B. Koldehofe, R. Mayer, U. Ramachandran, K. Rothermel, and M. Volz,“Rollback-recovery without checkpoints in distributed event processingsystems,” in Proceedings of the 7th ACM International Conference onDistributed Event-based Systems, 2013, pp. 27–38.

[32] R. Castro Fernandez, M. Migliavacca, E. Kalyvianaki, and P. Pietzuch,“Integrating scale out and fault tolerance in stream processing usingoperator state management,” in Proceedings of the 2013 ACM SIGMODInternational Conference on Management of Data, 2013, pp. 725–736.

[33] T. Heinze, M. Zia, R. Krahn, Z. Jerzak, and C. Fetzer, “An adaptivereplication scheme for elastic data stream processing systems,” inProceedings of the 9th ACM International Conference on Distributed Event-Based Systems, 2015, pp. 150–161.

[34] Y. Simmhan, Big Data and Fog Computing. Cham: Springer InternationalPublishing, 2018, pp. 1–10.

[35] P. Weisenburger, M. Luthra, B. Koldehofe, and G. Salvaneschi, “Quality-aware runtime adaptation in complex event processing,” in Proceedings ofthe 12th International Symposium on Software Engineering for Adaptiveand Self-Managing Systems, 2017, pp. 140–151.

[36] M. Gramaglia, O. Trullols-Cruces, D. Naboulsi, M. Fiore, and M. Calderon,“Mobility and connectivity in highway vehicular networks: A case study inMadrid,” Computer Communications, vol. 78, pp. 28 – 44, 2016.

17

transitions for increased flexibility in fog computing: a case … · 2019-08-17 · transitions...

Documents