Scalable extensible middleware framework for context-aware mobile applications (SCAMMP)

Transcription

1 Sclble extensible middlewre frmework for context-wre mobile pplictions (SCAMMP) Hssn Sbeyti 1, Mohmd Mlli 1, Khlid Al-Tht 2, Ahmd Fdlllh 1, nd Mohmd Youssef 3 1 Fculty of Computer Studies, Arb Open University, Beirut, Lebnon {hsbeity, mmlli, fdlllh}@ou.edu.lb 2 Fculty of Computer Studies, Arb Open University, Ammn, Jordn k_tht@ou.edu.jo 3 Fculty of Sciences, Lebnese University, Beirut, Lebnon mohmd.h.yousef@gmil.com Abstrct The number of users of hndheld devices will exceed one billion in the coming five yers 1. These devices re incresingly being enhnced with new sensors, which enble the development of contextwre mobile pplictions. Moreover, mobile pplictions might shre the sme contextul informtion (decision logics) which in return shres dt from the sme sensors; this introduces high code redundncy. Sclble extensible middlewre frmework for context-wre mobile pplictions (SCAMMP) simplifies the ggregtion nd shring of rw dt from different sensors nd the dynmic injection of decision logics in order to generte high level contextul informtion. It llows mobile pplictions to shre these high level contextul informtion (decision logic) vi simple Appliction Progrmming Interfce (API). This pper presents fully-implemented SCAMMP (on Android pltform) with quntittive performnce nlysis. The nlysis shows tht SCAMMP s overhed due to power consumption is round 0%, processing power hve peks less thn 14% t certin moments but is zero most of the time, nd the memory usge did not exceed 5 MB. It lso shows tht SCAMMP mintins its sclbility fter injecting dditionl decision logics nd incorporting more sensors. Furthermore, SCAMMP llows pplictions to ccess high-level contextul informtion by dding only three lines of codes. Keywords: Context-Awreness, Middlewre, Mobile Applictions 1 Introduction The penetrtion of hndheld devices (especilly smrtphones) is predicted to be over one billion in the next five yers [1] [2]. Most of tody s hndheld devices re equipped with sensors tht provide motion, orienttion, nd other contextul conditions. Thy provide lso high precision rw dt. In fct, these sensors cn be clssified s hrdwre-bsed (e.g., ccelertion sensor) or softwre-bsed sensors (e.g., liner ccelertion sensor). One cn lso list third ctegory of sensors which is the logicl sensors (e.g., clendr events). Allowing ny mobile ppliction to lern nd dynmiclly djust its behvior to the current context (i.e the current stte of the user, the current computtionl environment, nd the current physicl environment) cn enhnce the efficiency of these pplictions towrds power sving nd user experience. All of these mke smrt phone pplictions smrter. Exmples re mny: Journl of Wireless Mobile Networks, Ubiquitous Computing, nd Dependble Applictions, 7:3 (September 2016), pp The uthors re grteful to Arb Open University- Jordn Brnch for supporting this reserch. Corresponding uthor: Arb Open Univeristy, Omr Byhoum Str. - Prk Sector, Beirut , Beirut, Lebnon, Tel: (ext: 509), Fx: Globl mobile devices nd connections in 2014 grew to 7.4 billions 77

2 When the user is trveling, pplictions tht need to sync with cloud (using expensive mobile dt network), cn schedule these tsks to be executed t home or t work in order to sve bttery power. Mking the phone silent when the user is sleeping enhnces the user experience. A Power-friendly Operting System process scheduler cn swp processes from memory to persistent storge tking into considertion the user s stte. A reminder ppliction cn notify the user s events dditionlly bsed on the user s loction nd ccording to wht he/she is doing. For instnce, n lrm cn be set bsed on dte, time nd current user stte; thus, the user cn set the lrm to ring when sleeping only, wke only or both. Embedding contextul informtion within ny mobile ppliction rises the following chllenges: 1. Collecting rw dt from different sensors tht re vilble in different formts. 2. Developing decision logics tht ggregte the different formtted rw dt nd ugment it into useful contextul informtion. 3. Moreover, different mobile pplictions might shre the sme contextul informtion (decision logics) which in return shres dt from the sme sensors; this introduces high code redundncy nd hence incresing the lod on the system resources. These re the min chllenges for integrting contextul informtion within ny mobile ppliction. To ddress ll these chllenges, we propose SCAMMP tht is n extension of the Stndrdised Sclble Reloctble Context-Awre Middlewre for Mobile Applictions reserch work [3][4]. The current work differs from the previous work by the following fetures: 1. the previous work presents only the rchitecture of the middle-wre, the necessry design digrms nd simulted cse study. 2. While in this work: the whole middle-wre pltform hs been implemented on n ndroid pltform. 3. Two cse studies were implemented nd integrted within SCAMMP 4. Mny design issues tht were presented in the previous work hs been revised nd enhnced for performnce reson, for instnce the communiction between the different lyers hs been rdiclly modified. 5. A quntittive performnce nlysis ws conducted to evlute the overhed of the SCAMMP on the OS in term of CPU lod, memory usge nd power consumption. SCAMMP is composed of two seprte lyers: The Dt Acquisition-ugmenttion Lyer (DAL) (pre-processing) tht cn hve ccess to ny sensor (whether hrdwre, softwre or logicl) using mediting gents (ech sensor will be encpsulted using single gent). This ddresses the first nd third chllenges. The Decision Lyer (DL) cn be used to inject decision logics within so-clled stte engines (ech engine encpsultes single decision logic tht mintins the sttes of specific context) nd to connect them to specific gents (sensors) of the DAL. Thus, stte engines produce high level contextul informtion using finite stte mchine. Hence, pplictions will be ble to shre this high level context-wre informtion through simple API. 78

3 SCAMMP rchitecture is designed to ddress the bove mentioned chllenges. It ims to: Allow decision logics to shre sensor s dt, nd further shring decision engine output with pplictions t the ppliction lyer. Allow pplictions on the sme device to shre in simple wy high level context-wre informtion nd further reduce code redundncy. Fcilitte the injection of new decision logics, the embedding of future sensors, nd the shring of SCAMMP source code All of this will speed up the testing of new decision logics nd will lso led to the extension nd shring of SCAMMP. Furthermore, we present n evlution of the overhed (i.e., power consumption, processing power, nd memory usge) produced by SCAMMP by injecting decision logics nd ggregting dt from different sensors. The rest of this rticle is orgnized s follows: section 2 presents the rchitecture of SCAMMP, the different blocks of the both lyers, the dt cquisition nd the DL. Section 3 presents fully implemented tow decision logic cse studies. Section 4 presents quntittive performnce nlysis of SCAMMP. Section 5 presents relted work nd drws comprison. Finlly, Section 6 concludes the pper nd presents future work. 2 Architecture Figure 1 depicts the detiled rchitecture of SCAMMP[3]. From the Appliction lyer on the top, ny ppliction cn shre the high-level context-wre informtion provided by SCAMMP. The DL which is locted t the top of SCAMMP, offers to the ppliction lyer n Appliction Progrmming Interfce (API) to ccess these high-level context-wre informtion. This informtion is sved in finite stte mchine nd represents, in rel time, the different context sttes (user, computtionl, physicl). Hence, ny ppliction cn esily integrte this informtion. The Acquisition lyer is t the bottom of SCAMMP; its min role is to provide gents tht encpsulte sensors. Figure 1 lso shows tht mobile pplictions cn shre the sme contextul informtion (decision logics) which in return shres dt from the sme sensors; this is shown by the different rrows pointing t different lyers. It ims t reducing code redundncy hence decresing the lod on the system resources. Moreover, modules (stte engines nd gents) cn be dded/removed dynmiclly, hence gurnteeing the extensibility of the pltform. Ech lyer offers services to the bove lyer vi set of commnds (protocols). The different lyers communicte s follows: the lower lyer sends notifiction (push mechnism) to the lyer bove, ech time sensor notifiction is received, thus indicting the presence of vlid dt. If the upper lyer needs this dt, it issues request using predefined protocol sking for the new updted dt. At ny time the upper lyer is ble to send commnd to the lower lyer requesting new dt. The splitting of the system into different lyers provides high flexibility for lyer hosting nd thus the possibility to move the DL to the cloud. 2.1 DL The min tsk of the DL is to provide finite stte mchine tht stores the different context (user, computtionl, physicl environment) sttes in rel time. It ddresses the chllenges of shring high level context-wre informtion with the ppliction lyer while hiding the detils of how they hve been ggregted nd ugmented from different sensors. The core components of this lyer re the stte engines. Every time new decision logic is needed (to mintin new context), new stte engine is 79

4 Figure 1: SCAMMP Detiled Architecture injected to host this new decision logic. Figure 2 shows the components tht constitute this lyer. The API component represents the interfce of the ppliction lyer nd the controller component mintins n interfce tht cn be used by DAL (lower lyer). All remining components re used exclusively within this lyer. The API provides direct ccess to the files 2.Moreover, the DAL cn be instlled on hndheld devices or on the cloud, it depends on the vilble bndwidth. If this lyer is relocted to the cloud, then it cn be shred (with little modifiction) with ll ppliction lyers found on ny mobile device Stte engine Every user context stte cn hve mny ttributes, for instnce, Home is user context stte nd sleeping is its ttribute. Every stte engine is built using specific decision logic to generte specific context stte long with its ttributes bsed on inputs from one or more sensor gents of the lower lyer. The different finite stte engine s outputs re stored in the finite stte repository. When injecting new finite stte engine, it should be introduced to the controller in order to be registered before being opertionl. During the registrtion of new stte engine, list of the connected sensor gents from the lower lyer need to be specified. Prcticlly there is n bstrct clss clled StteEngine; new engine hs to extend it nd implement some of its methods by injecting the decision logic. It needs to register itself t the controller nd specify the sensor gents it wnts to listen to. This is ll wht needs to be done before the engine strts updting its finite stte mchine nd producing high level contextul informtion. Ech time sensor gent of the cquisition lyer sends notifiction to nnounce the vilbility of new sensor dt, the corresponding finite stte engines will be notified vi the controller. It is up to the stte engines to decide whether to 2 Agin, in cse the lyer is relocted, other communiction wys could be implemented 80

5 API Controller Finite Stte Repository Stte Engine 1 Stte Engine 2 Figure 2: Architecture of the DL request the dt or not. The kernel of the stte engine is bsed on finite stte mchine tht updtes the current context stte. The stte mchine components (sttes nd trnsitions) depend on the vilble stte nd its ttributes; the stte mchine is updted nd logicl trnsitions re pplied between sttes. () Stte Mchine Digrm (b) Loction Finite Stte Mchine Figure 3: Finite Stte Mchine Figure 3 is templte stte mchine tht is integrted within the stte engine.in fct, ll sttes re stored in the finite stte repository of the DL (Figure 1) in XML formt. For instnce, we consider the loction stte mchine with sptil user context sttes 3 : Home, University/School, Work, Visiting, nd Shopping. The stte mchine of such sttes is lmost common between people so tht ll sttes will return to Home stte nd most of them originte from Home Stte. The outcome of this engine is the current user stte represented in n XML file tht dpts the User Stte Schem nd is stored in the stte repository. The output becomes vilble to the ppliction lyer through the API component. 81

6 2.1.2 Appliction Progrmming Interfce The pplictions cn ccess the high level context-wre informtion only through the API. The min role of the API is to provide the current vlues nd the history of the different context sttes to the ppliction lyer. The API is implemented s librry (JAVA pckge) tht hs to be imported in ny mobile ppliction project tht wnts to ccess high level context-wre informtion provided by SCAMMP. Two different requests re provided by the API component, one request to list the vilble contexts nd their ttributes nd the other one to request the current sttes /(vlues) of the different contexts or the history for specific period of time Finite stte repository The Finite stte repository is implemented s storge system. It holds four different kinds of dt, two of them re mde vilble to the ppliction lyer vi the API component nd the other two re for internl use only. These four dt types re implemented s XML entry lists tht respectively: 1. contin n entry of every registered stte engine. 2. store the current vlues nd history of the different user sttes. 3. contin the output of every stte engine. 4. declre for ech gent (of the cquisition lyer) the stte engines tht re ttched to it. As lredy mentioned, the lst two dt types re for internl use nd re mde vilble for the stte engines. Since the history of the user stte could become huge fter while, it cn be rchived nd uploded to the cloud (or ny other remote storge), nd still being vilble to the ppliction lyer. The following subsection (2.1.4) describes the XML schems for the different dt types XML Schems The XML files re sved in the repository nd must follow specific schem depending on the type of dt stored s described bove. Figure 4 illustrtes the stte engine registrtion schem. Ech stte engine must hve, in ddition to its unique ID, unique URI. The URI is used to rech the stte engine dt in cse the DL is hosted in the cloud. The file lso clerly declres the set of gents ttched to the engine nd its desired output. The XML schem tht represents the user stte stores the current stte or previous sttes so tht the ltest file is the current one nd ll others re user stte history. The schem cn be extended to include ny kind of context informtion depending on the vilble stte engines. Figure 5 presents the unified schem used by stte engines to formt their output. 82

7 ssssssssssss sssssssssss ss sss s s sss sss s ss sss s s ss sss sss ss sss ss s sss ss ss sss sss s ss sss ss ssss s ss sss sss ssss ss s s sss ss ssss s ss sss Figure 4: Stte Engine Registrtion XML Schem () Stte Engine Dt XML Schem (b) Smple output (Loction Engine) Figure 5: Stte Engine Dt The schem for Agent-Engine declres for ech gent (of the cquisition lyer) the stte engines tht re ttched to it. This informtion is needed by the controller when receiving notifictions from the lower lyer to be forwrded to the engines concerned of the gent dt updte Nming Spce The repository stores its documents in hierrchy of collections or folders. It contins three min directories to hold the four types of dt (presented in section 2.1.3). DecisionDt Folder: contins two files: The user stte file nd the vilble sttes file. The user stte 83

8 file stores the current stte nd the history of the user stte following the Decision Dt Schem. The vilble stte s files store ll the vlues tht the middlewre cn detect. EngineDt Folder: holds ll the dt produced by stte engines. Ech engine hs specific folder identified by its ID. The folder contins n XML file tht follows the Stte Engine Dt Schem. Additionl files required by the stte engine might be dded to this folder. Registrtion Folder: This folder sves ll vilble stte engines in the registrtion.xml file tht dpts the Stte Engine Registrtion Schem. It lso contins the Agent-Engine ttchment files, where ech Agent hs its own file tht contins the stte engines ttched to it. These files follow the Agent-Engine Attchment Schem. Since the DL cn be hosted in the cloud when needed, the repository files must hve unique URI so they cn be reched remotely. Therefore, we suggest ttching URI to ech folder link in the repository: For instnce, dt produced by Loction engine cn be found on the URI: Controller The controller mintins the communiction with the lower lyer nd thus isoltes both lyers (DAL nd DL) from ech other. It receives notifictions from the sensor gents lyer (DAL) nd forwrds them to the corresponding stte engines lyer (DL). It forwrds requests to DAL received from the vilble finite stte engines(dl) nd sends the nswer bck. The controller updtes list of ctive finite stte engines nd registers new injected stte engines. 2.2 DAL The min im of DAL (Figure 6) is to provide the dt collected from different sensors in unified formt. When injecting new sensor whether physicl or virtul, it will be encpsulted using single dedicted gent. Once sensor produces new dt, the corresponding gent will decide, bsed to specific threshold whether to forwrd notifiction to the lyer bove or not; if yes, the gent will red the dt nd sve it in the dt repository in unified XML schem (Figure 7). This dt becomes vilble to the corresponding finite stte engines of the upper lyer through the controller. 84

9 Controller Agent 1 Agent 2 Agent 3 Sensor Dt Repository Sensor 1 Sensor 2 Sensor 3 Figure 6: Architecture of the Acquisition lyer Agents Most populr mobile operting systems provide sensor frmework s n API. For instnce powered mobile devices offers rw sensor dt by using the Android sensor frmework. This is prt of the ndroid hrdwre pckge nd includes mny clsses nd interfces (SensorMnger, Sensor, SensorEvent, SensorEventListener, etc.). The SCAMMP gents hide the OS API to offer unified sensor dt representtion. A unified XML schem is mde vilble to ll gents to store the cptured sensor dt (Figure 7)). Smples of rel cptured dt re illustrted s three kinds of sensors (physicl, virtul nd logicl) in figures 8 (Accelerometer sensor), 8b (Bttery sensor) nd 8c (Clendr sensor). Every sensor (whether physicl, virtul or logicl) is mnged by single gent. The gent implementtion is sensor-dependent. Ech time new gent is injected, it hs to be introduced to the controller Sensor Dt Repository The Sensor Dt Repository is n internl storge system tht holds ll informtion needed in the DAL. In order to orgnize the storge nd for the retrievl of XML files, the sensor dt repository is equipped with repository mnger to be used by the different gents. The repository contins three types of dt: the gent registrtion file tht contins ll registered gents, the dt produced by gents, nd the configurtion files (one for ech gent) XML Schems The XML files sved in the repository must follow specific schem. Figure 7 presents the unified schem tht is followed by gents to formt sensor dt. Figure 7b is the schem for gents registrtion file where sensortype cn hve one of the vlues {physicl, virtul, logicl} nd sensorloction cn be one of {locl, remote, cloud}. Finlly, figure 7c is the schem for the gents configurtion file. 85

10 ssssss sssss ss sss ss sss ss ss ss ssss sss sssss sssss ssssss sssss () Agent Dt (b) Agent Directory gggggg gd tttggt ttstet tttnggnesg teeeegge tddetdgnd eggt ettegtggg tttttdggg tttttdggg gdeeeeggy ettegtggg tttttdggg eggt tttttdggg (c) Agent Configurtion Figure 7: Agent XML Schems () Accelerometer sensor (b) Bttery sensor (c) Clendr sensor Figure 8: Agent cptured dt 86

11 2.2.4 Inter-process Communiction Communiction between different components t the sme lyer s well s inter-process communiction between the controllers t both lyers is done through intent brodcsts nd receivers. This requires the definition of severl filters. All filter nmes re composed of three prts: The first prt is fixed prefix "SCAMMP". The second prt is n bbrevition of the nme of the sending lyer (DL for Decision Lyer nd DAL for Dt Acquisition-ugmention lyer). The third prt specifies the sending component of specific lyer. Minly components cn send notifictions, but the sender cn be the DL controller becuse it might send messges to the stte engines nd to the controller t the lower lyer (DAL). In this cse, the third component prefix will be Controller_EngineX, where X identifies the stte engine concerned with the messge. In cse the DL is relocted (e.g., hosted on the cloud), new version of communiction would be dded using the sme messge formt. 3 Cse studies The min gol of SCAMMP is to provide middlewre frmework tht offers high level context-wre informtion through simple API to the ppliction lyer. But to chieve this gol, SCAMMP needs to be extended by injecting new decision logics nd encpsulting new sensors. In this work, we present two cse studies: the user loction nd the Mobile User Signture Extrction bsed on user behviorl Pttern [5] (MUSEP). In this section, we present how in generl, SCAMMP cn be extended, nd then we present how ech cse study cn be integrted within SCAMMP. 3.1 Extending SCAMMP SCAMMP cn be extended by injecting new decision logics nd encpsulting new sensors. The rest of this section explins how to chieve this Encpsulting new sensors within the DAL We need to encpsulte ech sensor using one gent: this cn be done by extending the bstrct super clss Agent: "public bstrct clss Agent extends Service " Depending on the sensor type, there re two cses: Periodic Dt Cpture, which requires implementing the bstrct method redsensordt() Event Bsed Cpture, which requires the implementtion specific brodcst receiver Injection of new stte engines within the DL The following steps need to be done in order to inject new stte engine: Extending the bstrct super clss StteEngine:"public bstrct clss StteEngine extends Service". Overriding the service methods of the clss StteEngine to include the needed decision logic. Implementing brodcst receiver tht listens for SCAMMP DL Controller Engine. Registering the new stte engine in the controller using the method:" RegisteredStteEngine registerengine(string nme, Output[] outputs, int[] input, String description)". 87

12 3.2 User Loction cse study The im of this cse study is to determine the current loction stte (high level user context informtion) of the user, whether the user is t home, work or elsewhere. This cn be done by injecting new stte gent t the DL clled "Loction Stte engine" nd dding three gents Adding Agents Three gents re needed to get the user s loction. These three gents encpsulte the following sensors: Loction (hrdwre/softwre sensor), network connection (softwre sensor) nd clendr (logicl sensor) sensors. These gents convert rw dt generted by the encpsulted sensors into unified XML dt s depicted in figure 7. Loction Agent: Most operting systems provide loction frmework tht clcultes the loction of the device. A softwre-bsed sensor found in most hndheld devices tht use the GPS, cell tower informtion, nd the connected Wi-Fi network is responsible for clculting the user s loction. It provides the following loction dt: longitude, ltitude, ltitude, ccurcy in meters, nd time. Figure 9 is n exmple of dt generted by the Loction Agent. Figure 9: Loction Agent Dt Network Connection Agent: This gent extrcts the current user connected network type (e.g., Wi-Fi, Mobile Dt network). It obtins this informtion from the "Connectivity Mnger" integrted in the mobile OS. The min role of this gent is to send notifiction whenever the user chnges the network connection type. It returns the following dt: connection type, connection SSID for Wi-Fi networks, nd the connected cell towers. Figure 10 represents rel smple dt for Wi-Fi network connection with SSID Alf ( mobile opertor in Lebnon). Figure 10: Network Connection Agent Dt 88

13 Clendr Agent: This gent encpsultes the logicl sensor clendr. The informtion collected by this gent cn be used (t the DL) to rise the certinty of the loction obtined from other gents. Figure 11 is smple dt presenting clendr event nmed Meet Mnger. Figure 11: Clendr Agent Dt Ech of the bove gents is implemented by clss tht extends the bstrct clss Agent; for instnce the network gent is implemented s follows: "public clss LoctionAgent extends Agent " nd overriding the method "public void oncrete() " Injection of Decision Logics At the DL, new stte engine (clled loction stte engine) needs to be injected, which hosts the decision logic. The gents presented bove (loction, network connection, Clendr) re ttched to this stte engine. The kernel (decision logic) of the loction stte engine cn determine user s loction (Home, Work, or elsewhere) using density-bsed clustering [6]. In fct, it goes through two phses: the lerning phse nd the ctive phse. During the lerning phse, the engine remins for period of time collecting the loctions tht the user frequently visits. In this phse, the "Loction Stte Engine" uses dt form the Loction Agent only. After period of two weeks of collecting dt, the loction history is clustered using density-bsed clustering into home, work, nd elsewhere ("Elsewhere points" re the points recognized s noise by the clustering lgorithm). Therefore, the clustering step is executed s prt of the lerning phse. Thus, ny loction point cn be clssified in certin loction. After the clustering step is done, the network gent strts signling the beginning of the ctive phse. Whenever new connection is detected, this is mpped to one of the three high level loctions (Home, Work, or Elsewhere) in n XML file following the Loction-Connection Mpping Schem (Figure 12). nnnnnnnnnnnnnnnnnnn nnnnnnnn nnnnn n nn n nnnn nnn n nn nn n nn Figure 12: Loction-Connection Mpping Schem 89

14 3.3 MUSEP The MUSEP system ims t building n intrusion detection system bsed on user behviorl pttern. It is composed of three softwre components s depicted in figure 13. The three components re the lerning component, the mthemticl model nd the intrusion detection component. The MUSEP is executed in two min phses: the lerning phse nd the intrusion detection phse. The rest of this section explins how MUSEP is implemented using SCAMMP Addition of Agents Only one gent is needed. This gent encpsultes softwre sensor nmely, the User behviorl sensor. It is defined s kind of user interction with his/her phone. It hs been decided to use the "WhtsApp" ppliction s proof of concept becuse of the frequent use of such ppliction. Hence, ech time the user uses the "WhtsApp" ppliction, the gent records the strt time nd the durtion in seconds Injection of Decision Logic The intrusion detection logic is composed of two min components; the mthemticl component nd the intrusion detection component. In the mthemticl component, dt stored in the first phse will serve s comprison tool for the decision phse. The input of this model is the strt time of the ctivity (considered s bsciss x) collected t run time which is provided to the cubic spline function; the mthemticl prt of the overll lgorithm. Next, decision mking tool will use both the dt stored in the device, nd the result of the cubic spline function in order to come up with the proper decision. The mthemticl model component (the cubic spline function) is used in collbortion with the intrusion detection component to form the intrusion detection phse. In the lter component, the lgorithm will compre the ordinte "y" from the stored dt with the result of the cubic spline. The stored dt will lso serve to determine threshold by which the decision of the owner or dversry will be tken depending on the difference between the results. Figure 13: MUSEP Architecture 3.4 API Therefore, ny ppliction tht wnts to integrte high level context-wre informtion bout the current user loction or the user uthentiction cn do this by dding only three lines of codes. First the pckge (UserStte) needs to be imported, nd then cll to the following three sttic methods of the clss API cn be plced nywhere within the ppliction: 90

15 API.getCurrentStte(): to get the user s lst stte API.getBetween(GregorinClendr from, GregorinClendr to): to get user sttes between given dtes API.getAvilbleSttes(): to get ll vilble user sttes using the UserStte formt 4 Quntittive Performnce Anlysis Hndheld devices nd despite the dvnces in bttery technology, still hve very limited energy resource nd require frequent rechrging. In ddition, the processing power nd the memory storge re considered s scrce resources. Hence, the instlltion of ny middlewre needs to be nlyzed regrding the requirements put on of these three resources. This section presents quntittive performnce nlysis of the resources (in terms of processing power, memory usge nd power consumption) consumed by SCAMMP. SCAMMP is implemented s two seprted pplictions one for ech lyer. Ech ppliction is implemented s bckground multi-threded service. We run the performnce nlysis by executing ech cse study prt nd then running both of them together to test SCAMMP s sclbility. We executed the running phse only, becuse it includes the lerning phse. 4.1 Experimentl Setup One device ws used. Below re the device specifictions. Device 1: Smsung Ace Plus GT-S7500T, 1 GHZ processor ndroid 2.3.6, 512MB RAM with SIM crd (WiFi nd 3G re used) Tools nd Methodology The bsh shell commnd "top" [7] is used to get CPU lod (percentge) nd the bsh shell commnd "dumpsys meminfo" [8] is used to get the PSS (Proportionl Shre Size) vlue for SCAMMP which tkes into considertion pges shred between processes, n ndroid ppliction hs been developed to execute these commnds periodiclly (every 3 seconds for CPU nd 10 seconds for RAM). We used the Trepn Profiler [9] mobile ppliction to gther the power consumption. The execution of these tests were done s follows: Run the loction cse study lone. Run MUSEP cse study lone. Run both cse studies together. 4.2 Running Phse The running phse requires running both lyers, the decision nd the DAL. The DAL is responsible for the lerning phse. Therefore we only evluted the running phse becuse it covers both, the lerning nd the running phse. During this phse, the user chnged his loction nd ws connected to different networks tht were new networks or recent ones to ensure executing ll code pths of SCAMMP. The user lso uses "WhtsApp" ppliction during this phse in order to ctivte the user s behviorl gent. There re two ctive gents, the network nd the user behviorl gent. We executed the dt cquisition nd DL for the following three different situtions: 91

16 Running the loction cse study, where the stte engine "Loction" nd the network gent re ctive Running the MUSEP cse study, where the stte engine "MUSEP" nd the gent user s behviorl gent re ctive Running both cse studies, Loction nd MUSEP together, where both stte engines nd gents re ctive CPU Lod We recorded the CPU lod for both lyers seprtely becuse they re implemented s two seprted pplictions tht reside in two distinct memory spces. Figure 14 depicts the percentge of CPU usge of the DAL for ll three situtions (Loction, MUSEP nd both). It is cler tht the CPU percentge usge is lmost zero for long periods nd t most (given by one record cpture) it exceeds 14%. This is becuse the middlewre (DAL only in this cse) listens to events coming from sensor gents, so either the user is now ttched to new network or is using the "WhtsApp" ppliction. The ndroid API documents [10] sttes tht the listeners re only considered ctive (in execution) when n event is received. Figures 15 depicts the percentge of CPU usge of the DL for ll three situtions. It shows similr result s the DAL with mximum pek of 12% (less thn the mximum of the DAL) this is due to the fct tht the DL is not interested ll the time in the dt gthered by the DAL. In fct, if they do not exceed certin threshold, they will be ignored. Both figures 14 nd 15 show tht the injection of new sttes engines (by running both, the Loction nd MUSEP cse studies) does not significntly increse the CPU lod Memory Usge Grphs in figures 16 nd 17, show tht RAM usge recorded mximum of 4912 KB for both cse studies for ll three situtions ( Loction, MUSEP nd both). The fluctution of the memory usge is cused by the networks frequent connections nd disconnections for the loction cse study nd the use nd relese of the "WhtsApp" ppliction. Ech time the gents cpture new dt, JAVA objects re creted (using the new opertor) nd lter relesed by the grbge collector. This leds to frequent incresing nd decresing of llocted memory t the ppliction hep. The sme hppens t the DL, whenever new dt is received from the DAL, new objects re creted nd grbged lter. Figures 16 nd 17 depict tht when running two gents nd two sttes engines, the memory usge will not remrkbly increse. In fct, most of the climed memory is due to the SCAMMP frmework source code itself Power Consumption The bttery cpcity is one of the most importnt components of ny hndheld device, but the bttery life time depends on the ppliction running. It is well known tht I/O opertions consume more power thn CPU processing. In ddition, hndheld devices ccess mobile dt network, hot spots nd GPS. All of these consume remrkble mount of bttery energy. Mny pplictions shre the ccess to this device, tht is why it s very difficult to ttribute the mount of power consumed by specific ppliction. We used the mobile pp "Trepen Profile"[9] to find out the mount of current (in ma) consumed by SCAMMP. Figure 18 depicts the current (in ma) consumed by SCAMMP while running both lyers. The figure shows tht the current consumed did not rech 0.1 ma, which mens it is in the rnge of Micro-Ampere µa. In fct SCAMMP doesn t ccess GPS, Wi-Fi or mobile network dt. It hs 92

17 CPU Lod (%) Loction MUSEP Loction & MUSEP Time (sec) Figure 14: CPU-DAL Usge during the running phse CPU Lod (%) Time (sec) Loction MUSEP Loction & MUSEP Figure 15: CPU-DL Usge during the running phse RAM Used (kb) Time (sec) Loction MUSEP Loction & MUSEP Figure 16: RAM-DAL Usge during the running phse 93

18 Figure 17: RAM-DL Usge during the running phse Current (ma) Time(S) Lction & MUSEP Figure 18: Current consumption in ma of SCAMMP (DAL+DL) during the running phse listener tht is ctivted whenever one of these devices sends brodcst. This results in executing method, which requires some CPU processing nd memory ccess, thus it doesn t put high lod on the bttery. Hence, we cn conclude tht SCAMMP does not put high dditionl overlod on the CPU lod, memory usge or bttery life time. Even fter injecting new stte engines nd the ddition of new sensors, the dditionl overlod remins cceptble. 5 Relted Work Developing mobile pplictions tht re context-wre is difficult tsk, this is due to the multiplicity nd diversity of sensors found within mobile devices. Hence, mny reserch works hve proposed middlewres s solutions to offer n bstrction lyer between the operting system nd the pplictions. In this chpter we present middlewre solutions tht provide context-wre informtion. Blduf et l.[11] presented survey of context-wre systems nd concluded tht common lyered conceptul frmework exists for most systems: Strting from the bottom (Sensors Lyer) going through the Rw Dt Retrievl Lyer nd Preprocessing Lyer tht increses the level of bstrction of contextul dt. Furthermore, the Storge nd Mngement Lyer provide n interfce to the Appliction Lyer in order to obtin the needed dt. While most systems re hving common rchitecture, they differ in 94

19 the wy they ddress the pplictions. Mny proposed middle-wre rchitectures collect informtion for wide rnge of context-wre pplictions such s smrt homes, intelligent vehicles, nd context wre hospitls. Other systems such s SCAMMP re trgeting excessively hndheld devices. Henricksen et l. [12] presented the PACE middlewre tht offers heterogeneity, mobility, trcebility nd control, nd deployment nd configurtion of new components. This middlewre ddresses mny of the context-wre middlewre requirements, except the sclbility requirement which is not stisfied. This middlewre is not trgeting mobile devices exclusively, in fct, it offers context-wre informtion for generl purpose systems. It is composed of three (3) lyers: Context Repositories Lyer, Decision Support Tools Lyer, nd Appliction Components Lyer. Dey et l. [13] introduced frmework tht offers fst development of generl context-wre pplictions. Using the Context Widget, Interpreters, Aggregtors, nd Services, it splits the context cquisition from the use of context within the ppliction. The Context Toolkit ims t instntiting the frmework, but its sclbility, ese of deployment nd configurtion fetures re rther limited. On the other hnd, the generic context-wre frmework CMF [14] is sclble context-wre frmework tht llows processing nd exchnging of heterogeneous context informtion. The Context Source pplies resoning techniques to ggregte dt from different sensors nd provides them to the Context Provider. This frmework is bsed on user profiles informtion tht is sved in the User Mngement component. The CORTEX [15] project introduced the sentient object model tht llows the development of contextwre pplictions in mobile d hoc environments. A sentient object is defined s mobile intelligent softwre component. It senses the surrounding environment through sensors nd other sentient objects. It is composed of three prts: Sensory Cpture, Context Hierrchy, nd the Inference Engine. Therefter, the proposed project ws enhnced in [16] by injecting the reflection cpbility nd the Service Discovery component. This hs been tested by building n intelligent vehicle ppliction. SCAMMP somehow shres some similrities with the presented work bove. It is similr in the wy it collects dt from vrious sensors, rises its bstrction level, nd provides context informtion for the pplictions lyer, but SCAMMP offers the following importnt dditionl fetures: Any ppliction t the ppliction lyer hs ccess to the different contexts provided by SCAMMP nd this cn be done using only three lines of code. SCAMMP cn be esily extended nd this gin is considered t the design stge, by llowing the injection of new decision logics nd the encpsultion of future sensors. The DL cn be moved to the cloud nd this is considered t the design stge. This llows the shring of decision logics mong different devices nd not only mong pplictions of the sme device. A performnce test hs been conducted using two cse studies tht showed the impct of SCAMMP on power, memory nd CPU lod remins cceptble when injecting new stte engines nd dding new gents. 6 Conclusion nd future work This pper presents fully implemented middle-wre frmework (on ndroid pltform). It includes the detiled rchitecture nd design specifictions s well s the communiction protocol. In ddition, in implementtion of two cse studies is give to show how simple it is to extend SCAMMP nd to evlute the overhed in terms of power consumption, memory usge, nd CPU lod produced by SCAMMP. 95

20 The evlution shows tht SCAMMP s overhed due to power consumption is round 0%, processing power hve peks less thn 14% t certin moments but is zero most of the time, nd the memory usge did not exceed 5 MB. Moreover, SCAMMP offers high level context-wre informtion to the ppliction lyer through well-defined API tht is esily ccessible by ny ppliction t the ppliction lyer through the ddition of three lines of code. SCAMMP is by design constructed to llow the injection of new decision logics (tht generte dditionl context-wre informtion) nd the encpsultion of future sensors. All of them simplify the test of new decision logic ides. Tht lso llows the shring of decision logics mong reserchers nd engineers. In ddition, it is reloctble llowing the DL to be hosted on the cloud. Finlly, it uses stndrd protocol for inter-lyer communiction nd URI for nme spcing. All of the spects of SCAMMP mentioned bove distinguish it from the currently proposed middlewre. In the future, we re intending to crete softwre community round SCAMMP tht works on extending (injecting new decision logics nd encpsulting new sensors) nd shring it. We re looking further into implementing it on n IOS pltform. References [1] GSMA Intelligence, Gsm mobile economy 2015 report, GSMA, Tech. Rep., [2] Cisco, Cisco visul networking index: Globl mobile dt trffic forecst updte, , Cisco White Pper, Februry 2015, ip-ngn-ip-next-genertion-network/white_pper_c pdf [Online; Accessed on September 10, 2016]. [3] H. S. Ftim Abdllh nd A. Fdlllh, Stndrdised sclble reloctble context-wre middlewre for mobile pplictions (scmmp), in Proc. of the 8th Interntionl Conference on Mobile Ubiquitous Computing, Systems, Services nd Technologies (UBICOMM 14), Rome, Itly, August 2014, pp [4] Scmmp project website, July 2015, [Lst ccessed on 25/2/2016]. [5] B. El-Hge, Mobile user signture extrction bsed on user behviourl pttern, Mster s thesis, Arb Open University - Fculty of Computer Studies - Lebnon, [6] H.-P. Kriegel, P. Kroger, J. Snder, nd A. Zimek, Density-bsed clustering, Wiley Interdisciplinry Reviews: Dt Mining nd Knowledge Discovery, vol. 1, no. 3, pp , [Online]. Avilble: [7] Top commnd mnul pge, Linux User s Mnul, [Online; Accessed on September 10, 2016]. [8] Android developers, Dumpsys system dignostics, 2016, dumpsys.html [Online; Accessed on September 10, 2016]. [9] Trepn profiler, [Online; Accessed on September 10, 2016]. [10] Android developers, 2016, [Online; Accessed on September 10, 2016]. [11] M. Blduf, S. Dustdr, nd F. Rosenberg, A survey on context-wre systems, Interntionl Journl of Ad Hoc nd Ubiquitous Computing, vol. 2, no. 4, pp , [12] K. Henricksen, J. Indulsk, T. McFdden, nd S. Blsubrmnim, Middlewre for distributed contextwre systems, in Proc. of the OTM Confederted Interntionl Conferences on the Move to Meningful Internet Systems 2005: CoopIS, DOA, nd ODBASE, Prt I, Agi Np, Cyprus, ser. Lecture Notes in Computer Science. Springer Berlin Heidelberg, October-November 2005, vol. 3760, pp [13] A. K. Dey, G. D. Abowd, nd D. Slber, A conceptul frmework nd toolkit for supporting the rpid prototyping of context-wre pplictions, Humn-computer interction, vol. 16, no. 2, pp , [14] H. Vn Krnenburg, M. Brgh, S. Icob, nd A. Peddemors, A context mngement frmework for supporting context-wre distributed pplictions, IEEE Communictions Mgzine, vol. 44, no. 8, pp ,

21 [15] G. Biegel nd V. Chill, A frmework for developing mobile, context-wre pplictions, in Proc. of the 2nd IEEE Annul Conference on Pervsive Computing nd Communictions (PerCom 04), Orlendo, Florid, USA. IEEE, Mrch 2004, pp [16] C.-F. Sørensen, M. Wu, T. Sivhrn, G. S. Blir, P. Oknd, A. Fridy, nd H. Durn-Limon, A contextwre middlewre for pplictions in mobile d hoc environments, in Proc. of the 2nd workshop on Middlewre for Pervsive nd Ad-hoc Computing (MPAC 04), Toronto, Ontrio, Cnd. ACM, October 2004, pp Author Biogrphy Hssn M. Sbeity received the Dipl.-Ing degree in Electricl Engineering nd Informtion Science form the Ruhr Universitt Bochum (Germny) in He worked mny yers in the development of PC I/O devices nd their drivers t EBS in Germny. In 2001, he received the DEA (Msters) in Informtics, Modeling nd Intensive Clcultion from AUF nd the Lebnese University in Beirut. In 2005, He received PhD in Informtics t Vlenciennes et du Hinut Cmbresis, LAMIH ROI (Frnce) with collbortion of the University of Ghent (ELIS), Belgium. He is currently Assistnt professor t the Arb Open University Lebnon brnch (since 2003). His min reserch interests include open lerning, computer rchitecture, ppliction prlleliztion, Mobile computing, Multimedi pplictions, nd memory optimiztion of embedded systems. Mohmmd G. Mlli obtined the Engineering Diplom in Electricl nd Electronics from the Lebnese University (Lebnon) in After tht, he received the Mster nd PhD Degrees in Networking nd Distributed Systems from the University of Nice Sophi Antipolis in 2003 nd 2006 respectively. He is currently the coordintor of the ITC progrm in the Arb Open University Lebnon brnch. His reserch interests lie in the res of Open Lerning, Mobile Computing, Computer Networking, nd Socil Networking Khlid S. Al-Tht holds B.Sc. in computer science from Yrmouk University in Jordn, n MSc. in AI from Mlysin University for Science nd Technology nd PhD in Softwre Engineering from the Ntionl University of Mlysi. Currently, he is the coordintor of the informtion technology progrm t the Arb Open University- Jordn Brnch. He worked t eductionl institutes in UK, Mlysi nd Jordn. His reserch interest lies in the fields of modern softwre engineering, mobile computing, AI nd teching computing. He is n uthor of bout 20 ppers published in interntionl journls, conference proceedings nd invited book chpters. Ahmd Fdlllh received the Engineering Diplom in Electricl Engineering nd Electronics from the Lebnese University (Lebnon) in In 2003, he received the DEA (Msters) in Telecommuniction Networks from AUF nd the Lebnese University in Beirut. In 2008, he received PhD in Computer science nd Networking from Telecom PrisTech-Frnce. He is currently Assistnt-Professor t the Deprtment of Informtion Technology nd Computing t the Arb Open University Lebnon brnch (since 2008). His reserch interests lie in the res of open lerning, Mobile computing, mobile networks, multimedi services nd computer & network security. 97

22 Mohmd H. Youssef received his BSc. in computer science from the Lebnese university, fculty of computer science in He obtined his MSc. studies in the informtion nd decision support systems (IDSS) t the Lebnese university in He is currently in the process of strting his PhD. 98