Evaluating Performance of In-Situ Distributed Processing on IoT …sig-iss.work/percomworkshops2019/papers/p633-talusan.pdf · 2020. 5. 24. · While distributed computing through

Evaluating Performance of In-Situ DistributedProcessing on IoT Devices by Developing a

Workspace Context Recognition ServiceJose Paolo Talusan, Francis Tiausas, Sopicha Stirapongsasuti,

Yugo Nakamura, Teruhiro Mizumoto, Keiichi YasumotoNara Institute of Science and Technology, Japan

Email: {talusan.jose paolo.tg3, tiausas.francis jerome.ta5, stirapongsasuti.sopicha,nakamura.yugo.ns0, teruhiro-m, yasumoto}@is.naist.jp

Abstract—With the number of IoT devices expected to ex-ceed 50 billion in 2023, edge and fog computing paradigmsare beginning to attract attention as a way to process themassive amounts of raw data being generated. However, theseparadigms do not consider the processing capabilities of theexisting commodity IoT devices in the wild. In order to solve thischallenge, we are developing a new middleware platform calledIFoT, which processes various sensor data while consideringQuality of Service (QoS) by utilizing the computational resourcesof heterogeneous IoT devices within an area. This allows smartservices to be created and processed in parallel by various IoTdevices. In this paper, we show the effectiveness of the IFoT basedapproach of constructing services. We designed and implementeda workspace context recognition service, utilizing environmentalsensor data processed in a distributed manner according to theIFoT framework. We evaluate the QoS of IFoT middlewareand its feasibility when used on commodity devices such as theRaspberry Pi, through the service.

Index Terms—Edge Computing, Internet of Things, Middle-ware, Distributed processing, Activity recognition.

I. INTRODUCTION

Internet of things (IoT) devices continue to be created anddeployed at an increasing rate. The number of IoT devices inthe real world is expected to reach 50 billion by 2023 [1].With the increase in IoT devices, come the increase in rawdata, most of which is consumed and processed by companiessuch as Google, Apple and Facebook, then provided to users asservices that increase quality of life and social media. One ofthe key issues in a world that is saturated by the ever increasingdata is how to gather, process and aggregate it with low latencyand low cost.

Cloud computing is currently the main platform used fordeploying IoT services [2]. However, not all cloud-basedapproaches may be suitable for services targeted for smallercommunities without suitable access to the global IoT, or forprivate and secure services whose data cannot be given toglobal IoT systems.

Now edge and fog computing paradigms are attractingattention with their ability to process data much closer to thesource. In edge-based existing studies [3], [4], edge cloudsare deployed and used in a metropolitan based environment to

process tasks with low delay. However utilization of compu-tational resources and use of resource constrained devices arenot taken into consideration.

Therefore a new data processing framework called theInformation Flow of Things (IFoT) [5], [6] is proposed forprocessing information flow from various IoT devices in atimely and scalable manner based on distributed processingon in-situ devices. The IFoT framework flexibly utilizes com-putation resources of IoT devices existing near the data source,aiming to efficiently coordinate and maintain smart communityservices with low cost and low latency.

In order to realize the IFoT framework, we are developinga new middleware platform (IFoT middleware) [6]. In theIFoT middleware, heterogeneous IoT devices are groupedinto clusters and configured to work together to satisfy thecomputational demand of services. Services are user createdapplications that process and convert raw data into usable ones.User queries and requests of services, processed through theplatform, need to meet a predetermined service level agree-ment requirements (SLA). To be able to satisfy a service’sSLA, the IFoT middleware leverages the cluster’s distributedprocessing capabilities.

To demonstrate the effectiveness of the IFoT middleware,in this paper, we create a use case and deploy a servicethat utilizes the middleware. We design a workspace contextrecognition service that can be used by offices or buildingswith many rooms. This service use environmental sensors andcommodity IoT devices deployed in various rooms. The targetscenario is suitable on IFoT middleware because it is able todemonstrate how many heterogeneous IoT devices can be usedto provide services with minimal latency due to its distributedconfiguration.

We developed and implemented a distributed machine learn-ing mechanism to utilize the cluster’s computational resource[7]. This mechanism is modified and improved in this paperusing a scheduling system which utilizes the in-memory datastructure. With this improvement we were able to generateresponses for multiple queries in 2.3 seconds which can thenbe decreased linearly the more nodes are added.

In the following Sections II and III, we discuss prior work

IQ2S'19 - 10th International Workshop on Information Quality and Quality of Service for Pervasive Computing

978-1-5386-9151-9/19/$31.00 ©2019 IEEE 633

and the IFoT platform, respectively. In Section IV, we describein more detail how we implement and deploy distributedprocessing of tasks for a workspace context recognition servicewithin the platform. In Section V, we show the actual setupand configuration and the results of the experiments. Finally,we conclude the paper in Section VI.

II. RELATED WORK

A. Edge and Fog computing

Fog Computing [8] and Edge Computing [9] are paradigmsthat mitigate server load by processing data on servers nearerto the data source. Edge computing may act as a bridgebetween IoT devices and the cloud. Edge and fog computingmake it possible to minimize the latency of tasks comparedwith the cloud. These platforms perform roles such as IoTdevice management, network management and data processingand transferring. While edge computing is able to minimizelatency as well as efficiently use available bandwidth, itstill faces challenges with regards to data partitioning andoffloading of tasks.

B. Docker Technology

Containerization [10] is technology that is now popularizedby Docker. Docker is a light-weight application that facilitatesthe creation of self-contained environments called containers[11]. These containers are isolated instances similar to thesolution provided by virtual machines (VM). However, unlikeVMs they achieve minimal overhead by sharing the kernelwith the host OS. Docker containers enable one to builddynamic services which can then be distributed within acluster of devices through an orchestrator. Docker has beenused in research that aims to deploy services on single-boardcomputers [12] [13], as well as in research on cost-efficientedge frameworks [14].

C. Middleware platforms

While distributed computing through IoT devices usingcontainers have been an attractive prospect, there is still thechallenge of heterogeneous IoT devices. Research is beingdone to address where current frameworks fall short in dealingwith the heterogeneity of distributed computing. Schafer et al.in Tasklets [15] and Bhave et al. [16] attempted to ease theburden of heterogeneity for distributed and edge computing byusing middleware and virtualization technologies to efficientlyhandle multiple heterogeneous devices and tried to pool theircomputation resources together.

While studies on containerization and middleware platformshave been found feasible and successfully done on commoditydevices such as Raspberry Pi [13], [17], [18], and have beenable to provide some form of distributed processing, thesesystems do not focus on providing service for users withinan area. Also, these prior systems and platforms while beingable to create a middleware on heterogeneous devices, werenot utilizing the computational resource of the pooled devicesfor more sophisticated data processing/analysis by means ofdistributed machine learning.

Fig. 1. Overview of IFoT Middleware Platform Architecture

III. IFOT MIDDLEWARE PLATFORM

The IFoT middleware platform (parts of its mechanisms arepresented in [6]) is a concrete realization of IFoT framework.It consists of three main layers: Resource Management Layer,Task Execution Layer and Service Coordination Layer. AllIoT devices in the platform are considered nodes and theymay serve different functions within the architecture shown inFig. 1.

A. Platform Architecture

1) Resource Management Layer: Manages IoT devices thatparticipate in the platform. It consists of the resource broker(R-Broker). It is manually set by community as (typically) themost powerful node in the network and has information on allavailable nodes. It also manages all the nodes in the platform.

The R-Broker handles resource registration by resourceowners through a web interface. The owners provide in-formation of IoT devices such as processing capabilities,available sensors and location details to the resource broker.The registered nodes are then configured into Docker nodes,to be configured into either Service Brokers or Service Work-ers depending on their computational capability, comprisingthe service coordination layer and the task execution layerexplained below.

2) Service Coordination Layer: Handles the communica-tion between end-user and the task execution layer. It consistsof the service brokers (S-Brokers). The S-Brokers manageservices. Each S-Broker is the gateway by which users querythe service through a web interface. S-Broker is assignedmanually by a service creator to (typically) the most pow-erful node available after the R-Broker. S-Broker managesmultiple S-Workers within its service area and adds moreS-Workers/worker nodes to its manageable resource pool toprovide needed QoS level for the current computation demand(i.e., the number of queries per unit of time) [6].

3) Task Execution Layer: Handles the execution of servicesor task graphs that the platform offers the users. It consistsof service workers (S-Workers). This layer is configured tofunction as a cluster and is designed to execute tasks in adistributed manner.

Once nodes are registered into the platform, they are setupas clusters for a specific location. Clusters are the task

IQ2S'19 - 10th International Workshop on Information Quality and Quality of Service for Pervasive Computing

634

execution block of the platform which are composed of thefollowing:

a) Service Worker (S-Worker): S-Worker is the virtualrepresentation of the task execution cluster. It is formed by aDocker Swarm cluster which consists of a master node andmultiple worker nodes. They are in charge with communi-cating with the S-Brokers regarding the user queries for taskexecution. Upon receiving requests, they are the ones thatmanage the task distribution to multiple worker nodes.

b) Master Nodes: handle the task distribution to themultiple worker nodes. Databases such as the environmentalsensor databases, are placed on master nodes as well. In ourimplementation these are deployed on Raspberry Pi.

c) Worker Nodes: are the basic execution nodes of theplatform. They are tasked with executing tasks allocated bythe master node. Each worker node is a single IoT devicewith limited or constrained computational resources. In ourimplementation worker nodes are Raspberry Pi.

d) Environmental sensor database (envDB): are timeseries database that collects and aggregates data from thesensors connected to the platform. Services such as activityrecognition will gather data from envDBs. These are assignedto the master nodes of S-Workers.

IV. WORKSPACE CONTEXT RECOGNITION SERVICE

A. Service Scenario

In this section, we present a workspace context recognitionservice scenario as a typical use case of IFoT middlewareplatform.

We assume that future smart offices will have many freeaddress workspaces where many environmental sensors areinstalled as well as having their own network infrastructure.Employees can freely use these rooms for meetings, work, andrecreation at anytime. However, if the office space is too large,it is difficult for employees to figure out which workspaceis currently available and suitable for their needs. This isour motivation to develop the workspace context recognitionservice.

Workspace Context Recognition Service: Using this service,office employees can get useful information regarding theroom context such as the comfort level, noisiness, and the pos-sible over use or under use of certain rooms. This informationis generated through the data processing (Statistical process-ing and machine learning inference using pre-trained modelswithin the platform) of data from environmental sensors whichare located in the rooms. This service can be accessed bythe employees through the S-Broker on the local intranet. Allinformation remains private since data is only stored locallywithin the nodes.

The number of rooms that need to be monitored as wellas people monitoring these rooms, affect the performance ofthe platform. Performance can be increased by adding moreIoT nodes into the system, increasing the local computationresource, thus avoiding the need for a more powerful centralterminal. Clusters of commodity single-board computers suchas Raspberry Pis are more than enough for this application.

Fig. 2. Task graph for workspace context recognition service

Furthermore, having more nodes within the platform allowsthe creation of more services that may be needed by employeesin the office space. Addition of a service is simply a case ofadding the required sensors and a task graph that details thecollecting, processing and aggregating tasks.

Other use cases: This framework can be generalized to sim-ilar use cases which feature characteristics such as: geo-spatialsensor data, machine-learning, heatmap, etc. Modifications tothe task graph allow the framework to handle such use cases,without the need for large changes of the entire framework.

B. Details of the Task graph

Task graphs (or service recipes) detail how a service handlesqueries by users. Each service has a corresponding task graph.The task graph for the workspace context recognition serviceis shown in Fig. 2. Sensor data is stored inside an envDBlocated inside the monitored room. Upon receiving a query,the S-Broker, executes a task graph that is executed by the S-Worker(s). The task graph makes use of Redis [19], an opensource in-memory data structure that functions as the mainqueueing system of the IFoT middleware. Tasks are queuedonto Redis and then worker nodes monitor these queues andprocess them when they are free.

1) Collecting Task: For the current experiment, the queryincludes time information for the test room. This time infor-mation is then sent to a worker node which in turn collects thedata from the envDB inside the room. This task is executed inparallel for each received query. The worker obtains the datain the form of a JSON string which is passed onto the queuefor processing.

2) Processing Task: Processing tasks will be done in par-allel, depending on the number of available worker nodes thatmonitor the queue. Upon receiving the JSON string from thequeue, it converts these to a Pandas dataframe. It also loads thepre-trained classification model that is stored in each workernode for use. It will then use the loaded model to classifythe status of the room based on the sensor data. The workernode then sends the classified labels back to the queue for theaggregator.

3) Aggregation Task: This task is usually done on oneworker node. It will wait either for all nodes to finish orset a timeout. Upon gathering all the coordinate and labelinformation, it will generate a heatmap that specifies the usageof a particular area. This is then saved as an SVG image andthen sent back to the S-Broker for displaying back to the user.

IQ2S'19 - 10th International Workshop on Information Quality and Quality of Service for Pervasive Computing

635

Fig. 3. Current experiment architecture

V. IMPLEMENTATION AND EVALUATION

A. Implementation

The smart room context recognition service with the IFoTmiddleware platform is built using Raspberry Pi 3 ModelB (Pi) and Omron 2JCIE-BL01 Environmental Sensor. ThePi is equipped with 1.4GHz ARMv8 processor, 1GB DDR2SDRAM, Wifi and Bluetooth low energy (BLE) connectivity.It uses Raspbian operating system, a version of Linux Debian,optimized for ARM. The sensor is a wireless sensor that isequipped with 7 different sensors: temperature, humidity, light,UVI, absolute pressure, noise and acceleration. The Omronsensor measures data at 300 second intervals (this period canbe set between 1 second and 1 hour), at this rate lifetime ofthe battery is 3 months. Each period, the sensor obtains theroom’s current temperature, relative humidity, ambient light,UV index, pressure and sound noise. All these informationare sent to the Pi node, which listens to the sensor beaconsvia Bluetooth Low Energy. It receives the sensor informationas well as timestamp, RSSI, sensor MAC address, gatewayaddress, estimated distance via the RSSI, heat stroke factor,discomfort index and battery level, which is stored as a rowwith 18 columns in the envDB.

Five environmental sensors were placed in a large multi-function room used for seminars, meetings, recreational ac-tivities, and discussions. Due to the room’s size, it wasfurther broken down into several areas as shown in Fig. 4.The locations of these sensors were chosen to maximize theamount of data being collected on the varying use of the roomthroughout the day. Data is broadcast by the sensors every5 minutes and were received by a sensor node (RaspberryPi) located in the same room. This sensor node is equippedwith an envDB for storing the timeseries data generated by allthe sensors. Transmission of data is through Bluetooth LowEnergy and thus RSSI information was also recorded. TwoRaspberry Pi Camera Module v2 cameras were setup in twocorners of the room, as shown in Fig. 4, to capture ground truth

Fig. 4. Placement of Environmental sensors in the implementation

data during the experiment. We then manually label each 10minute interval based on the number of people present. We use4 classification levels No Use, Low Use, Medium Use, HighUse. We set these based on the number of people present inthe room. 0: [No Use], 1-3: [Low Use], 4-9: [Medium Use]and 10+: [High Use]. This was in an effort to keep trainingand classification simple since the experiment location wasa single multi-functional room. Subsequent experiments withmultiple rooms may increase the classification to take intoaccount more classes.

The classification model is trained using a Support VectorClassification (SVC) algorithm via Scikit-Learn package. Thefeatures that are used from each sensor are humidity, light,noise, RSSI, and temperature. The other three features, accel-eration, UVI and pressure showed little to no changes for theduration of the experiment and were not used.

Since all 5 sensors were placed in a single room at differentlocations, we used each sensor’s 5 different sensor data ascolumns. Raw sensor readings were used without furthermodification for the data set. This results in a 26 columndataset (including the timestamp which is used as a feature)with almost 2000 rows for 4 days of data gathering. This wastrained offline using the SVC algorithm. The resulting machinelearning model which has an accuracy of 62% as shown in Fig.5, is then saved into a file for distribution to the S-Workers.

In our implementation, the model is sent first to the S-Broker and is then automatically distributed to the S-Workervia Python script. S-Worker, located outside the room simplyfor debugging purposes, is connected to the university’s net-work via wired connection. The sensor node, which containsthe envDB, is connected to the same network via WiFi. Thesensor node can also be a worker node of the S-Worker,however for simplicity, it was configured separate from theS-Worker. In future experiments, this will be made part ofthe S-Worker. S-Workers and S-Brokers connect to eachother through the same network above, via wired connec-

IQ2S'19 - 10th International Workshop on Information Quality and Quality of Service for Pervasive Computing

636

Fig. 5. Confusion matrix for SVC model

Fig. 6. Demonstration of possible output of the Smart Room contextrecognition service, where blank(no use), blue(low use), green(medium use)and red(high use)

tion. The user can access the S-Broker through any method(wired/wireless, smart phone or PC) as long as they areconnected to the local area network of the university. In thiscase, each worker node receives a copy of the same model.Upon receiving a user query, the S-Broker, executes a taskgraph as shown in Fig. 2. The classification process is thenexecuted in the following manner: (1) Upon receiving servicerequests, the S-Broker divides it into singular room queries.(2) It obtains and forwards the time information of each roomquery into the queue. (3) The S-Worker monitors this queueand assigns the tasks to a free worker node under it. (4) Theworker node performs the collecting task and then using thepreviously received pre-trained model, the processing task. (5)Upon classification, it then sends the labeled data as well asother room information data back into a queue. (6) Again, theS-Worker, monitoring the queue, assigns this to a free workernode to perform the aggregation task as detailed in Sec. IV-BThe next section discusses the evaluation of this task executionand the effects of the S-Worker on the QoS.

B. Evaluation: Centralized vs. Distributed Task Execution

Given the setup above, a use case was imagined for the ser-vice: employees want to know information on the workspacesin the building. They query the S-Broker for information based

on the sensors deployed in each space. The number of roomsor number of other entities (e.g., other building staff, local firedepartment monitors, etc.) regularly performing such a queryat the same time may vary, leading to scenarios that requirea serviceable quality of service (QoS) from the platform. Theoutput of a user query is a corresponding label for the roomthey are querying, in the future this output can be displayed inthe form of a heatmap as shown in Fig. 6, where room usageis shown in various colors.

Since we only have sensors placed in a single room, wesimulate how the system would behave when multiple roomsare being queried at once. To be able to do that, we randomlyselect 100 data points (i.e., 100 samples) from the datasetand set it as the target of query. Since the sensors would bethe same regardless of the room which it is placed in, wethen suppose that each row (a data point) in the data set is adifferent room. Based on the study of Egger et al. [20], thereis a direct relationship between delay and dissatisfaction, withthis we aim that the workspace context recognition serviceshould be able to return a response within around 2 seconds.

We perform the following experiment to investigate the QoSthe platform is capable of delivering. We test the system’sability to handle 100 rooms being queried at once. We firstconfigured the platform such that the S-Worker would onlyrun 1 worker node and then increase the number of nodes viathe scale-out method detailed in [6].

We consider the total execution time as the time measuredfrom when the user sent the query until the response of theheatmap is received by the same user. Fig. 7 shows the QoSof the platform against the number of worker nodes present inan S-Worker. Given large sets of data bound in a single query,a single node on average, total execution time goes beyondthe set limit of 2 seconds and fails to achieve acceptable QoS.Increasing the number of nodes to 5, allows the platform torespond with an average of 2 seconds for large data set queries.This total execution time only goes lower the more nodes areadded.

Next we simulate the effect of in-situ resource provisioningwith scale-out [6], an additional implementation for the IFoTplatform. We overload a single node using the same 100rows used in the previous experiment, but we divide the100 rows into individual queries and then send simultaneousqueries to S-Broker. As seen in Fig. 8, using a single node,it has an average total execution time of 25 seconds. With aninitial 4 nodes, we can decrease this total execution time to 5seconds, quicker than a single node but still unable to meetthe QoS. Finally, implementing in-situ resource provisioningto the nearest 3 neighbor nodes, we can decrease the totalexecution time to 1.2 seconds.

VI. CONCLUSION

In this paper we designed and developed a use case forthe IFoT middleware platform. The use case of smart roomcontext recognition system is implemented into the platformas a service. Users query the service in order to identify theusage of workspaces in an office environment. The main goal

IQ2S'19 - 10th International Workshop on Information Quality and Quality of Service for Pervasive Computing

637

Fig. 7. Execution times for large sets of data in single queries with varyingnumber of workers

Fig. 8. Execution times for small sets of data in multiple parallel querieswith varying number of workers

for the service is to be able to provide a certain QoS suchthat the service is able to respond to multiple queries within2 seconds. We achieve this by using the IFoT middlewareplatform that uses pre-trained machine learning algorithms andcomputational resources right at the data source to classifiyand recognize room usage using environmental sensors. Inaddition, we implement distributed processing on the platform,this improves the QoS of the system from a total executiontime of 4.2 seconds to less than 2 seconds. Furthermore, withthe implementation of adaptive in-situ resource allocation, weshow that we can further improve the total execution time for100 simultaneous requests from 4 seconds to 1.2 seconds.

The platform was implemented on a single room in theessence of saving time, but we show that this system is feasibleand is able to deliver acceptable QoS regardless of the numberof rooms being monitored.

ACKNOWLEDGEMENT

This work was in part supported by JSPS KAKENHIGrant Number 16H01721 & 17J10021 & 26220001 andR&D for Trustworthy Networking for Smart and ConnectedCommunities, Commissioned Research of National Instituteof Information and Communications Technology (NICT).

REFERENCES

[1] Iot: number of connected devices worldwide 2012-2025 —statista. [Online]. Available: https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/

[2] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, “Internet of things(iot): A vision, architectural elements, and future directions,” Futuregeneration computer systems, vol. 29, no. 7, pp. 1645–1660, 2013.

[3] L. Tong, Y. Li, and W. Gao, “A hierarchical edge cloud architecturefor mobile computing,” in INFOCOM 2016-The 35th Annual IEEEInternational Conference on Computer Communications, IEEE. IEEE,2016, pp. 1–9.

[4] L. Wang, L. Jiao, J. Li, J. Gedeon, and M. Muhlhauser, “Moera:Mobility-agnostic online resource allocation for edge computing,” IEEETransactions on Mobile Computing, 2018.

[5] K. Yasumoto, H. Yamaguchi, and H. Shigeno, “Survey of Real-timeProcessing Technologies of IoT Data Streams,” Journal of InformationProcessing, vol. 24, no. 2, pp. 195–202, 2016.

[6] Y. Nakamura, T. Mizumoto, H. Suwa, Y. Arakawa, H. Yamaguchi,and K. Yasumoto, “In-situ resource provisioning with adaptive scale-out for regional iot services,” in Proceedings of the Third ACM/IEEESymposium on Edge Computing (SEC 2018), 2018, pp. 203–213.

[7] J. P. Talusan, Y. Nakamura, T. Mizumoto, and K. Yasumoto, “Nearcloud: Low-cost low-power cloud implementation for rural area con-nectivity and data processing,” in 2018 IEEE 42nd Annual ComputerSoftware and Applications Conference (COMPSAC), vol. 02, July 2018,pp. 622–627.

[8] F. Bonomi, R. Milito, J. Zhu, and S. Addepalli, “Fog computing andits role in the internet of things,” in Proceedings of the First Edition ofthe MCC Workshop on Mobile Cloud Computing, ser. MCC ’12. NewYork, NY, USA: ACM, 2012, pp. 13–16.

[9] P. Garcia Lopez, A. Montresor, D. Epema, A. Datta, T. Higashino,A. Iamnitchi, M. Barcellos, P. Felber, and E. Riviere, “Edge-centriccomputing: Vision and challenges,” ACM SIGCOMM Computer Com-munication Review, vol. 45, no. 5, pp. 37–42, 2015.

[10] . Kovcs, “Comparison of different linux containers,” in 2017 40thInternational Conference on Telecommunications and Signal Processing(TSP), July 2017, pp. 47–51.

[11] C. Boettiger, “An introduction to docker for reproducible research, withexamples from the R environment,” CoRR, vol. abs/1410.0846, 2014.[Online]. Available: http://arxiv.org/abs/1410.0846

[12] A. van Kempen, T. Crivat, B. Trubert, D. Roy, and G. Pierre, “Mec-conpaas: An experimental single-board based mobile edge cloud,” in2017 5th IEEE International Conference on Mobile Cloud Computing,Services, and Engineering (MobileCloud), April 2017, pp. 17–24.

[13] C. Pahl, S. Helmer, L. Miori, J. Sanin, and B. Lee, “A container-basededge cloud paas architecture based on raspberry pi clusters,” in 2016IEEE 4th International Conference on Future Internet of Things andCloud Workshops (FiCloudW), Aug 2016, pp. 117–124.

[14] M. Al-Rakhami, M. Alsahli, M. M. Hassan, A. Alamri, A. Guerrieri,and G. Fortino, “Cost efficient edge intelligence framework using dockercontainers,” in 2018 IEEE 16th Intl Conf on Dependable, Autonomic andSecure Computing (DASC), Aug 2018, pp. 800–807.

[15] D. Schafer, J. Edinger, J. M. Paluska, S. VanSyckel, and C. Becker,“Tasklets:” better than best-effort” computing,” in Computer Communi-cation and Networks (ICCCN), 2016 25th International Conference on.IEEE, 2016, pp. 1–11.

[16] S. Bhave, M. Tolentino, H. Zhu, and J. Sheng, “Embedded middlewarefor distributed raspberry pi device to enable big data applications,” in2017 IEEE International Conference on Computational Science andEngineering (CSE), vol. 2, July 2017, pp. 103–108.

[17] Y. Elkhatib, B. Porter, H. B. Ribeiro, M. F. Zhani, J. Qadir, and E. Rivire,“On using micro-clouds to deliver the fog,” IEEE Internet Computing,vol. 21, no. 2, pp. 8–15, Mar 2017.

[18] X. Wang, S. Jiang, X. Xu, Z. Wu, and Y. Tao, “A raspberry pi andlxc based distributed computing testbed,” in 2016 6th InternationalConference on Digital Home (ICDH), Dec 2016, pp. 170–174.

[19] Redis. [Online]. Available: https://redis.io/[20] S. Egger, T. Hossfeld, R. Schatz, and M. Fiedler, “Waiting times

in quality of experience for web based services,” in 2012 FourthInternational Workshop on Quality of Multimedia Experience, July 2012,pp. 86–96.

IQ2S'19 - 10th International Workshop on Information Quality and Quality of Service for Pervasive Computing

638