iGateLink: A Gateway Library for Linking IoT, Edge, Fog and Cloud Computing Environments

iGateLink: A Gatew a y Library for Linking IoT, Edge, F og and Cloud Computing En vironmen ts Riccardo Mancini 1 , 2 , Shresh th T uli 1 , 3 , T ommaso Cucinotta 2 , and Ra jkumar Buyy a 1 1 Cloud C omputing and Distributed Systems (CLOUDS) Lab, School of Computing and Information System, The Universit y of Melbourne, Australia 2 Scuola Sup eriore San t’Anna, Pisa, Italy 3 Departmen t of Computer Science and Engineering, Indian Institute of T echnology , Delhi, India Abstract. In recen t y ears, the Internet of Things (IoT) has been gro w- ing in p opularit y , along with the increasingly imp ortant role play ed b y IoT gatewa ys, mediating the interaction s among a plethora of heteroge- neous IoT devices and cloud services. In this paper, w e presen t iGateLink , an op en-source Android library easing the dev elopment of Android ap- plications acting as a gatewa y b etw een IoT devices and Edge/F og/Cloud Computing environmen ts. Thanks to its pluggable design, mo dules pro- viding connectivity with a num b er of devices acting as data sources or F og/Cloud framew orks can b e easily reused for differen t applications. Using iGateLink in tw o case-studies replicating previous w orks in the healthcare and image processing domains, the library pro ved to b e effec- tiv e in adapting to differen t scenarios and speeding up developmen t of gatew ay applications, as compared to the use of conv en tional metho ds. Keyw ords: Internet of Things, Gatewa y applications, Edge Computing, F og Computing, Cloud Computing 1 In tro duction Recen tly , the Internet of Things (IoT) has gained significant popularity among b oth industry and academia, constituting a foundational technology for creating no vel computing environmen ts like smart cities and smart healthcare applica- tions, which p ose higher and higher requirements on the capabilities of modern computating infrastructures [1, 2]. Cloud Computing allow ed for offloading com- plex and heavy-w eigh t computations, including big-data pro cessing pip e lines, to remote data centers [1]. Ho wev er, the exp onential gro wth of connected IoT de- vices and the forecast in the pro duced data v olumes for the upcoming y ears [3] pushed industry and academia to lo ok in to optimized solutions, where virtual mac hines are dropp ed in fav our of more light-w eight con tainers [4] and, more imp ortan tly , de c entr alize d solutions are employ ed, where computing happ ens at the e dge of the netw ork, giving rise to the F og computing paradigm. This leads to 2 Riccardo Mancini et al. reduced latency , deplo yment costs and improv ed robustness [5], so in recen t y ears man y fog/cloud frameworks ha ve b een prop osed lev eraging computing resources b oth at the edge of the netw ork and in cloud data cen ters [6, 7]. In now adays IoT and fog computing framew orks, a crucial comp onent is the gateway device which enables comm unications of users, sensors and actuators with edge devices and cloud resources [8]. Gatewa y devices could b e small em- b edded computers, smart routers or even smart-phones. In IoT the num b er of sensors and actuators ha ve increased tremendously in the last few years [9, 10], in- cluding adv anced gatewa y devices that emerged in recen t fog environmen ts [11]. Ev en though fog computing frameworks greatly simplify engineering gatewa y functionalit y , they do not fo cus on making generic gatewa y in terfaces for seam- less in tegration with diverse applications, user needs and computation mo dels. Fig. 1. Example scenario in which one or more IoT device communicate to the Cloud/F og through a gatewa y device. Contributions. This pap er proposes iGateLink , a modular fog-cloud gatew ay library easing the developmen t of applications running on Android-based IoT gatew ay devices. It provides common core functionalit y , so as to let develop- ers fo cus on the application-sp ecific co de, for example implementing commu- nications with sp ecific sensors or proto cols to exchange data with sp ecific fog or cloud systems. iGateLink is sp ecific to the men tioned IoT-F og use-case but generic enough in order to allo w simple extensions to be used in different IoT- F og integrated environmen ts as shown in Figure 1. It is also easy-to-use through a simple API and supp orts integration of differen t frameworks within the same application, including the p ossibility to run the required execution lo cally . iGateLink has b een applied to t wo use-cases, one dealing with a oximeter- based healthcare application for heart care patients, the other one for low re- sp onse time ob ject recognition in camera images. The presented framework pro ved to be effectiv e for reducing dev elopment complexit y and time, when com- paring with existing practises in co ding IoT gatewa y applications. 2 Related W ork Due to the v ast heterogeneity in the In ternet of Things, the imp ortance of the IoT gatew ay in enabling the IoT has b een ac knowledged by several works [12–14]. Some authors prop ose IoT gatewa ys to act only as routers, e.g. incapsulating ra w data coming from Blueto oth devices in IPv6 pac k ets to be sen t to the iGateLink 3 Cloud [15]. How ever, in order to enable more complex scenarios, offload compu- tations and/or sa ve netw ork bandwidth, IoT gatew ays need to b ecome “smart” b y pre-pro cessing incoming data from the sensors [16]. In this context, the use of smartphones as IoT gatew a ys has been proposed [17, 18], ho wev er those w orks do not take into consideration the most recen t F og and Edge Computing paradigms. Regarding efforts to in tegrate the IoT with F og and Edge Computing, A azam et al. [8] proposed a Smart Gatewa y base d communication that utilizes data trim- ming and pre-pro cessing, along with F og computing in order to help lessen the burden on the cloud. F urthermore, Gia et al. [19] developed a Smart IoT Gate- w ay for a Smart Healthcare use-case. Finally , T uli et al. [6] developed F o gBus an integration framework for IoT and F og/Cloud. How ever, their work do es not pro vide a generic application able to in tegrate IoT and F og/Cloud frameworks, building their application from the ground-up, tailored to their sp ecific use-case. Finally , it is worth while to note that none of the previously mentioned works fo cuses on the design and implementation of the softw are that is required to run in the IoT gatew ay , esp ecially in the case of an Android device, in order to mak e it generic and adaptable to man y different scenarios, as this pap er does. 3 System Mo del and Architecture The principles discussed in Section 1 hav e b een addressed by using a mo dular design, with a generic core up on which different mo dules can b e loaded. A v ariation of the publish/subscribe paradigm [20] has b een used, where the components collecting data from sensors and the ones sending it to the F og/Cloud are the publishers and are called Pr oviders , while the subscrib ers are the auxiliary components that manage the execution of the publishers or UI com- p onen ts that sho w incoming data to the user. The publish/subscribe paradigm is realized through an intermediate component that stores the incoming data from the Pr oviders , called Stor e , and notifies the subscrib ers, called T riggers , using the observer design pattern. A Stor e can also b e thought as the topic to whic h the Pr ovider publishes data, while the T riggers are its subscrib ers . In the considered scenario, a Pr ovider ma y b e started either as a result of a user interaction (e.g. a button click) or as a consequence of external ev ent (e.g. incoming Blueto oth data). It can also b e started with some input data or with no data at all. The prop osed mo del do es not assume any of the aforementioned cases, emplo ying a generic design, able to adapt to many different scenarios. While the input of a Pr ovider can v ary , the result is alw ays data that needs to b e stored in a Stor e . Whenev er a Pr ovider stores new data to a Stor e , all T riggers asso ciated with the Stor e are executed. The most common use of a T rigger is to start another Pr ovider but it could also b e used, for example, to up date the UI. These design choices enabled: 1) mo dularity since Pr oviders and T riggers can b e indep endently and easily plugged and unplugged; 2) flexibility since this mo del enables ev en more complicated use-cases than the one men tioned ab ov e; 3) ease of use thanks to co de reusability . 4 Riccardo Mancini et al. F urthermore, sev eral Pr oviders pro viding the same data (i.e. publishing to the same Stor e ) can be active sim ultaneously , for example Pr oviders for different F og/Cloud frameworks and/or lo cal execution. In this case, it is useful to define a new comp onent, the Cho oser , whose function is to selec t a sp ecific Pr ovider among a list of equiv alent ones in order to pro duce data. By doing so, it is p ossible to, for example, use another Pr ovider when one is busy or to fallback to another Pr ovider if one fails. 3.1 Implemen tation Details Core Android-specific modules Extension modules ( bluetooth, camera, aneka, fogbus , ...) User Application Fig. 2. High-level o verview of the library softw are comp onents. Store ExecutionManager Provider Trigger Chooser publishes to starts chooses 1..* 1 1 1 0..* 1 1..* 1..* runs 1 0..* calls Fig. 3. Simplified UML diagram of the core comp onen ts. Based on the mo del describ ed ab ov e, we hav e implemen ted the iGateLink library for Android devices. The library is op en-source and av ailable at: https:// gith ub.com/Cloudslab/iGateLink. F rom a high-lev el p oin t of view (Figure 2), the library is comp osed of a platform-indep endent core written in Jav a, an Android- sp ecific mo dule which extends the core to b e efficiently used in Android and sev eral extension mo dules that provide complimentary functionalities. Cor e. The core of the library is comp osed by the follo wing classes: Exe cution- Manager , Data , Stor e , Pr ovider , Cho oser and T rigger . Refer to Figure 3 for a conceptual ov erview of their interactions. The Exe cutionManager class co ordi- nates the other comp onents and provides an API for managing them. The Data class is not properly a component but is the base class that ev ery data inside this library must extend. It is characterized by an id and a request id : the former m ust b e unique b etw een data of the same Stor e ; the latter is useful for trac king data b elonging to the same request. The Stor e class stores Data elements and pro vides t w o operations: retrieve for retrieving previously stored Data and store for storing new data. Ev ery Stor e is uniquely identified by a key . There can be multiple Stor es for the same Data type. F urthermore, a Stor e can hav e one or more T riggers asso ciated to it that is called whenever new data is stored. F or example, a common use for a T rigger is starting a Pr ovider with the recen tly iGateLink 5 stored Data from another Pr ovider . The Pr ovider class tak es some Data in input and pro duces some other Data in output. Every Pr ovider is uniquely iden tified b y a key . There can b e m ultiple Pr oviders for the same Stor e but a Pr ovider can only use one Stor e at a time. A Pr ovider can b e started b y calling its execute metho d either through Exe cutionManager ’s runProvider or produceData . In the latter case, the user sp ecifies only whic h Data it w ants to be pro duced (b y means of a Stor e key) and a suitable Pr ovider will b e executed. In case there are t wo or more Pr oviders for the same Stor e , a Cho oser will b e used. A ndr oid-sp e cific mo dules. When developing such an application on Android, a common problem is the one to use worker thr e ads for time-consuming tasks that need to execute in the bac kground still letting the Android run time to kill the app as needed. This is addressed by pro viding the AsyncPr ovider class, whic h mak es use of the AsyncT ask class 4 . F urthermore, the Exe cutionManager is hosted within an Android Servic e , which, if configured correctly as a foreground service, prev ents the Android runtime from killing it. 4 Case studies In order to test the library and demonstrate its applicability to real applica- tions, t wo case studies ha ve b een dev eloped. They b oth reproduce existing w orks, namely F ogBus [6] and EdgeLens [7]. The first application connects to a blue- to oth oximeter to collect and analyze its data. The second application tak es a photo and sends it to the F og or Cloud for ob ject detection. In the original works b oth applications hav e b een developed using MIT App Inventor , which eases and speeds up the developmen t but provides only a v ery simple API that cannot be adapted to more complicated use cases. F urther- more, every application needs to b e built from the ground up even though many comp onen ts may b e in common, esp ecially when using the same input metho d or framework. By developing the applications using iGateLink , b oth mo dularit y and fast dev elopment can b e achiev ed. Oximeter b ase d he althc ar e applic ation The blueto othdemo application can be used to detect h yp opnea in a patien t by collecting data from an oximeter. The application consists of four screens: 1) the configuration screen (left picture in Figure 4); 2) the Blueto oth device pairing screen; 3) the Bluetooth device selec- tion screen through which the user chooses the device whose data to show; 4) the data and analysis result screen (righ t picture in Figure 4). Data is collected in real-time from the oximeter using Blueto oth LE . In order to do that, the blueto oth mo dule has b een developed whic h provides an imple- men tation of the Pr ovider which registers to the GA TT characteristics in order to receive push notifications from the Blueto oth device. Raw data receiv ed from the o ximeter is then conv erted to a Data ob ject and stored. 4 it pro vides a simple API for sc heduling a new task and executing a custom function on the main thread b efore and after the execution 6 Riccardo Mancini et al. Fig. 4. Configuration screen (left) and liv e data and analysis results screen (righ t) from the oximeter demo app. Fig. 5. Preview screen (left) and result screen (right) from the ob ject detection demo app. The user can then upload the data to F o gbus [6] b y tapping the “Analyze” button in order to get the analysis results. Data is sent using an HTTP request to the F o gbus master no de which forwards the request to a work er no de (or the cloud) and then returns the result to the application. This simplifies the dev elopment of the application, since only one HTTP request is required. Obje ct dete ction applic ation The c amer ademo application can b e used to take a photo and run an ob ject detection algorithm on it, namely Y olo [21]. The user in terface is very simple, with just a screen sho wing the camera preview and a button (Figure 5). When the button is clic ked, the photo is tak en and sen t to the F og/Cloud for ob ject detection. When the execution is terminated, the resulting image is do wnloaded and shown to the user. In order to in tegrate Android camera APIs with iGateLink , the c amer a mo d- ule has b een dev elop ed, whic h pro vides an implemen tation of a Pr ovider , Camer- aPr ovider , that takes a photo when its exe cute metho d is called. When the photo is stored, tw o pro viders are executed: BitmapPr ovider , that con verts the photo from an array of bytes to a Bitmap ob ject so that it can b e plug in a ImageView and shown to the user, and one of EdgeL ensPr ovider or AnekaPr ovider , that execute the ob ject detection on either EdgeL ens [7] or Anek a [22]. The result of the ob ject detection is, again, an array of bytes so it go es through another BitmapPr ovider b efore b eing shown to the user. The EdgeL ensPr ovider is resp onsible for uploading the image to the Edge- L ens framew ork and downloading the result once the execution is completed. EdgeL ens has a similar arc hitecture to F o gbus but, differen tly from it, commu- nication b etw een client and work er is direct, instead of b eing pro xied by the master. The usual EdgeL ens workflo w is: 1) query the master to get the desig- iGateLink 7 nated w ork er; 2) upload the image to the w ork er; 3) start execution; 4) do wnload the result when the execution is terminated. The AnekaPr ovider is resp onsible for exe cution in Aneka [22] through its REST APIs for task submission. The image is first uploaded to a FTP serv er (whic h could b e hosted by the master no de itself ), then the ob ject detection task is submitted to Aneka , whose master no de chooses a work er no de to submit the request to. The work er do wnloads the image from the FTP serv er, runs the ob ject detection on it and uploads the result image back to the FTP serv er. In the meanwhile, the client rep eatedly p olls the master no de in a lo op, waiting for the submitted task to complete. When it does, the clien t finally downloads the result whic h is display ed to the user. 5 Conclusions and F uture W ork In this pap er we presented a new Android library , iGateLink , whic h enables de- v elop ers to easily write new Android applications linking IoT, Edge, F og and Cloud Computing environmen ts, as it comes with a set of highly reusable mo d- ules for common IoT scenarios. W e demonstrated, by means of t w o use-cases, that the library can adapt to different applications. The library is easy to use, increasing the engineering simplicit y of application deplo yments, making such systems robust and easy to main tain. As part of future work, more mo dules could b e added to the library to co ver the most comm on use-cases in order to make the developmen t of a new ap- plication using the library easier. F or instance, the current version of the li- brary does not include any mo dule providing a Pr ovider for Bluetooth devices (curren tly only Blueto oth Low-Energy is supp orted), built-in sensors (for exam- ple accelerometer, gyroscop e, magnetometer, luminosity), touch even ts, audio recording. F urthermore, more F og/Cloud frameworks could be integrated within the library , making it lik e plug-and-play softw are for end users. References 1. Yi, S., Li, C., Li, Q.: A surv ey of fog computing: concepts, applications and issues. In: Proceedings of the 2015 w orkshop on mobile big data. pp. 37–42. ACM (2015) 2. Gill, S.S., T uli, S., Xu, M., Singh, I., Singh, K.V., Lindsa y , D., T uli, S., Smirnov a, D., Singh, M., Jain, U., et al.: T ransformative Effects of IoT, Blo ck chain and Arti- ficial Intelligence on Cloud Computing: Evolution, Vision, T rends and Open Chal- lenges. Internet of Things p. 100118 (2019) 3. Ericsson Mobility Report. https://www.ericsson.com/en/mobilit y- rep ort (2019) 4. Cucinotta, T., Ab eni, L., Marinoni, M., Balsini, A., Vitucci, C.: Reducing tem- p oral interference in priv ate clouds through real-time containers. In: 2019 IEEE In ternational Conference on Edge Computing (EDGE). pp. 124–131 (July 2019) 5. Bonomi, F., Milito, R., Zh u, J., Addepalli, S.: F og computing and its role in the in ternet of things. In: Pro ceedings of the first edition of the MCC workshop on Mobile cloud computing. pp. 13–16. A CM (2012) 8 Riccardo Mancini et al. 6. T uli, S., Mahm ud, R., T uli, S., Buyy a, R.: F ogBus: A Block chain-based Ligh tw eight F ramework for Edge and F og Computing. Journal of Systems and Softw are 154, 22 – 36 (2019) 7. T uli, S., Basumatary , N., Buyya, R.: EdgeLens: Deep Learning based Ob ject De- tection in Integrated IoT , F og and Cloud Computing En vironments. In: 4th IEEE In ternational Conference on Information Systems and Computer Netw orks (2019) 8. Aazam, M., Huh, E.N.: F og computing and smart gatewa y based communication for cloud of things. In: 2014 International Conference on F uture In ternet of Things and Cloud. pp. 464–470. IEEE (2014) 9. Singh, D., T ripathi, G., Jara, A.J.: A surv ey of internet-of-things: F uture vision, arc hitecture, challenges and services. In: 2014 IEEE world forum on In ternet of Things (WF-IoT). pp. 287–292. IEEE (2014) 10. Lee, I., Lee, K.: The internet of things (iot): Applications, inv estments, and chal- lenges for enterprises. Business Horizons 58(4), 431–440 (2015) 11. Whiteak er, J., Sc hneider, F., T eixeira, R., Diot, C., Soule, A., Picconi, F., May , M.: Expanding home services with adv anced gatewa ys. ACM SIGCOMM Computer Comm unication Review 42(5), 37–43 (2012) 12. Zh u, Q., W ang, R., Chen, Q., Liu, Y., Qin, W.: Iot gatew ay: Bridgingwireless sensor net works in to internet of things. In: 2010 IEEE/IFIP In ternational Conference on Em b edded and Ubiquitous Computing. pp. 347–352. Ieee (2010) 13. Datta, S.K., Bonnet, C., Nik aein, N.: An iot gatewa y centric arc hitecture to pro vide no vel m2m services. In: 2014 IEEE W orld F orum on Internet of Things (WF-IoT). pp. 514–519. IEEE (2014) 14. Chen, H., Jia, X., Li, H.: A brief in tro duction to iot gatew ay . In: IET In ternational Conference on Communication T ec hnology and Application. pp. 610–613 (2011) 15. Zac hariah, T., Klugman, N., Campbell, B., Adkins, J., Jackson, N., Dutta, P .: The in ternet of things has a gatew ay problem. In: Proceedings of the 16th international w orkshop on mobile computing systems and applications. pp. 27–32. A CM (2015) 16. Saxena, N., Ro y , A., Sahu, B.J., Kim, H.: Efficien t iot gatewa y o ver 5g wireless: A new design with prototype and implementation results. IEEE Communications Magazine 55(2), 97–105 (2017) 17. Golc hay , R., Moul, F.L., F rnot, S., Ponge, J.: T ow ards bridging iot and cloud services: Prop osing smartphones as mobile and autonomic service gatewa ys. In: Actes des 7meJournes F rancophones de la Mobilit et Ubiquit. pp. 45–48 (6 2011) 18. Aloi, G., Caliciuri, G., F ortino, G., Gravina, R., P ace, P ., Russo, W., Sav aglio, C.: A mobile multi-tec hnology gatew ay to enable iot interoperability . In: 2016 IEEE First International Conference on Internet-of-Things Design and Implemen tation (IoTDI). pp. 259–264. IEEE (2016) 19. Gia, T.N., Jiang, M., Rahmani, A.M., W esterlund, T., Liljeb erg, P ., T enhunen, H.: F og computing in healthcare internet of things: A case study on ecg feature extraction. In: International Conference on Computer and Information T ec hnology; Ubiquitous Computing and Communications; Dep endable, Autonomic and Secure Computing; Perv asive In telligence and Computing. pp. 356–363. IEEE (2015) 20. Eugster, P .T., F elb er, P .A., Guerraoui, R., Kermarrec, A.M.: The man y faces of publish/subscrib e. ACM computing surv eys (CSUR) 35(2), 114–131 (2003) 21. Redmon, J., Divv ala, S., Girshick, R., F arhadi, A.: Y ou only lo ok once: Unified, real-time ob ject detection. In: Pro ceedings of the IEEE conference on computer vision and pattern recognition. pp. 779–788 (2016) 22. V ecchiola, C., Chu, X., Buyya, R.: Anek a: a softw are platform for .net-based cloud computing. High Sp eed and Large Scale Scientific Computing 18, 267–295 (2009)