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, Ahmd Fdlllh 1, Khlid Al-Tht 2, 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 penetrtion of hndheld devices (especilly smrtphones) is predicted to be over one billion in the next five yers 1. These devices re incresingly being equipped with new sensors offering gret potentil for mking mobile pplictions context-wre. The diversity of the low-level (rw) sensor dt nd the need for decision logic re the min chllenges for integrting contextul informtion within 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. 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 [13] [7]. Most of tody s smrt devices hve built-in sensors tht mesure motion, orienttion, nd vrious environmentl conditions. These sensors re cpble of providing rw dt with high precision nd ccurcy. Every smrtphone nowdys is equipped with set of smll sensors. These sensors cn be hrdwre-bsed embedded in the smrtphone (e.g., ccelertion sensor) or softwre-bsed deriving their dt from one or more hrdwre-bsed sensors (e.g., liner ccelertion sensor). A third ctegory of sensors could be introduced 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, volume: 1, number: June, 2016, pp Corresponding uthor The uthors re grteful to Arb Open University- Jordn Brnch for supporting this reserch. 1 Globl mobile devices nd connections in 2014 grew to 7.4 billions 7

2 When the user is trveling, pplictions tht need synchroniztion with cloud services (dt uplod/downlod through mobile network), cn postpone these tsks until the user is t home or t work in order to sve bttery power even if the mobile network provides high bndwidth dt connection (e.g., LTE connection). Becuse once the bttery of the mobile is drined, rechrging the phone is difficult during trvel. Another exmple is mking the phone silent when the user is sleeping which 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 not only bsed on time nd dtes but lso 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; one cn choose ringing 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[2] tht 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. 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. 8

3 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 explores set of relted work nd compres them to this work. Finlly, Section 6 concludes the pper nd presents future work. 2 Architecture Figure 1 depicts the detiled rchitecture of SCAMMP[11]. 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, provides the ppliction lyer with n Appliction Progrmming Interfce (API) to ccess these high-level context-wre informtion. This informtion is stored 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 provides services to the lyer bove through well-defined set of commnds (protocols). The communiction between the different lyers is ccomplished s follows: the lower lyer sends notifiction (using push mechnism) to the upper lyer, ech time sensor notifiction is received, thus indicting the vilbility of vlid dt. If the upper lyer is interested, it issues request, using predefined protocol, sking for the new updte. At ny time the upper lyer cn issue commnd to the lower lyer sking for dt updtes. The seprtion of the system into different lyers offers gret flexibility for lyer hosting nd hence the possibility to move the DL to the cloud. 9

4 Figure 1: SCAMMP Detiled Architecture 2.1 DL The min tsk of the DL is to mintin finite stte mchine tht reflects 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 injected to host this new decision logic. Figure 2 depicts the different components tht build up this lyer. The API component represents the interfce of the ppliction lyer nd the controller component provides n interfce to the lower lyer, nmely the DAL. All remining components hve no direct ccess outside this lyer. The API provides direct ccess to the files 2.This lyer cn be hosted on the mobile device or on the cloud, nd it cn be relocted depending on the vilble Internet bndwidth. If this lyer is relocted to the cloud, then it cn be shred (with little modifiction) with ll ppliction lyers of ny mobile device. 2 Agin, in cse the lyer is relocted, other communiction wy could be implemented 10

5 Figure 2: Architecture of the DL 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 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. 11

6 () 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 sttes3 : 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 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. There re two types of requests tht cn be sent using the API component, one for list of the vilble contexts nd their ttributes (nmes nd descriptions) nd the other for the current sttes /(vlues) of the different contexts or the history for specific period of time Finite stte repository The Finite stte repository is storge system. It contins four types of dt, two of them re vilble to the ppliction lyer through the API component nd the other two re for internl use only. These four dt types re 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. 12

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 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. 13

8 () 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 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 s min role is to mintin the communiction with the lower lyer nd hence isolte the DL from the DAL. It receives notifictions from the sensor gents of the lower lyer nd forwrds them to the corresponding stte engines. It forwrds requests to the lower lyer received from the different finite stte engines nd forwrds the response to the corresponding finite stte engines. The other role is to mintin list of the ctive finite stte engines. Ech time new stte engine is injected, it hs to be registered t the controller. 14

9 2.2 DAL The min role of the Dt Acquisition-ugmenttion lyer (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, ccording to certin threshold whether to forwrd notifiction to the upper lyer or not; if yes, the gent will collect the dt nd store 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. Controller Agent1 Agent2 Agent3 Sensor Dt Repository Sensor 1 Sensor 2 Sensor 3 Figure 6: Architecture of the Acquisition lyer Agents Most populr mobile OS provide sensor frmework s n API. For instnce Abdllh2014-powered mobile devices provide rw sensor dt by using the Android sensor frmework, which is prt of the ndroid hrdwre pckge nd includes mny clsses nd interfces (SensorMnger, Sensor, SensorEvent, SensorEventListener, etc.). The SCAMMP gents encpsulte the OS frmework to provide homogenous sensor dt representtion. A unified XML schem is used by ll gents to represent the cptured sensor dt (Figure 7)). Smples of rel cptured dt re illustrted s three ctegories of sensors (physicl, virtul nd logicl) in figures 8 (Accelerometer sensor), 8b (Bttery sensor) nd 8c (Clendr sensor). For every sensor (whether physicl, virtul or logicl), there will be dedicted gent. The internl implementtion of the gent 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 15

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 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 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. 16

11 () Accelerometer sensor (b) Bttery sensor (c) Clendr sensor Figure 8: Agent cptured dt 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 [10] (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 17

12 3.1.2 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)". 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 We define three gents required to determine the user s loction. They lso 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 per the schem defined in figure 7. Loction Agent: Both Android nd IOS operting systems offer loction frmework tht determines the loction of the device. It is softwre-bsed sensor tht uses the GPS, cell tower informtion, nd connected Wi-Fi network to detect the user s loction. It returns the loction using the ttributes: longitude, ltitude, ltitude, ccurcy in meters, nd time. Figure 9 is smple dt produced by the Loction Agent. Figure 9: Loction Agent Dt Network Connection Agent: This gent determines the type of network the user is currently connected to (e.g., Wi-Fi, Mobile Dt network). This informtion is obtined from the "Connectivity Mnger" in the mobile operting system. The gent s role is to send notifiction whenever the user switches from one connection to nother. The returned dt includes: connection type, connection SSID for Wi-Fi networks, nd the set of cell towers the device is connected to. Figure 10 represents rel smple dt for Wi-Fi network connection with SSID Alf ( mobile opertor in Lebnon). 18

13 Figure 10: Network Connection Agent Dt 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 [14]. 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 19

14 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 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 logics 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. 20

15 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: 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) 21

16 4.1.1 Tools nd Methodology The bsh shell commnd "top" [1] 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 [4] 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: 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 [3] 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. 22

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 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 23

18 RAM Used (kb) Time (sec) Loction MUSEP Loction & MUSEP Figure 16: RAM-DAL Usge during the running phse 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 24

19 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"[4] 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 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 The multiplicity nd diversity of sensors embedded within mobile devices mkes context-wre pplictions difficult to develop, so middlewre solutions re proposed to provide n bstrction lyer between the operting system nd pplictions. In this section we review some of the proposed middlewre solutions of the context-wre systems. Blduf et l.[5], in their survey of context-wre systems, concluded tht there is common lyered conceptul frmework for most systems: Strting from the low level (Sensors Lyer) pssing through the Rw Dt Retrievl Lyer nd Preprocessing Lyer tht rises the level of bstrction of context dt. Then the Storge nd Mngement Lyer tht provide n interfce for the Appliction Lyer to obtin wht is needed from the collected dt. Although most systems hve common rchitecture but they differ in the kind of trget pplictions they serve. Some of the rchitectures gther informtion for generl context-wre pplictions such s smrt homes, intelligent vehicles, nd context wre hospitls. Other systems including SCAMMP re specilized for mobile devices. Henricksen et l. [12] proposed the PACE middlewre tht supports heterogeneity, mobility, trcebility nd control, nd deployment nd configurtion of new components which re some of the requirements for context-wre middlewre. On the other hnd it does not chieve the sclbility requirement. This middlewre is developed for context-wre systems in generl rther thn mobile devices. The middlewre is divided into 3 lyers: Context Repositories Lyer, Decision Support Tools Lyer, nd Appliction Components Lyer. Dey et l. [9] presents frmework tht supports the rpid development of generl context-wre pplictions. Using the Context Widget, Interpreters, Aggregtors, nd Services, it seprtes the context cquisition from the use of context in the ppliction. The Context Toolkit ws implemented to instntite the frmework, but it is limited in sclbility nd ese of deployment nd configurtion. Another generic context-wre frmework is CMF [16]. It is sclble context-wre frmework tht enbles processing nd exchnge of heterogeneous context informtion. The Context Source uses resoning techniques to integrte dt collected from different sensors nd offers them to the Context Provider. The frmework tkes benefits from user profiles stored in the User Mngement component. The sentient object model is proposed by the CORTEX [6] project for the development of context-wre pplictions in mobile d hoc environments. A sentient object is mobile intelligent softwre component tht senses the surrounding environment vi sensors nd other sentient objects. It consists of three prts: Sensory Cpture, Context Hierrchy, nd the Inference Engine. The model ws improved more in [15] by dding the reflection cpbility nd the Service Discovery component. It ws lso tested by building n intelligent vehicle ppliction. 25

20 All the referenced pproches re similr to SCAMMP in the wy they collect dt from different sensors, rise its bstrction level, nd offer context informtion for pplictions. But SCAMMP hs the following 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, design specifictions nd the communiction protocol. In ddition, it includes n implementtion of two cse studies 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. 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 this, simplifies the test of new decision logic ides. This 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] Top commnd mnul pge. [Lst ccessed on 25/2/2016]. [2] Scmmp project website. July [Lst ccessed on 25/2/2016]. [3] Android developers [Lst ccessed on 25/2/2016]. [4] Trepn profiler. trepn-profile, [Lst ccessed on 25/2/2016]. [5] Mtthis Blduf, Schhrm Dustdr, nd Florin Rosenberg. A survey on context-wre systems. Interntionl Journl of Ad Hoc nd Ubiquitous Computing, 2(4): ,

21 [6] Gregory Biegel nd Vinny Chill. A frmework for developing mobile, context-wre pplictions. In Pervsive Computing nd Communictions, PerCom Proceedings of the Second IEEE Annul Conference on, pges IEEE, [7] Cisco. Cisco visul networking index: Globl mobile dt trffic forecst updte, Technicl report, Cisco, Februry [8] Android Developpers. Dumpsys system dignostics [9] Anind K Dey, Gregory D Abowd, nd Dniel Slber. A conceptul frmework nd toolkit for supporting the rpid prototyping of context-wre pplictions. Humn-computer interction, 16(2):97 166, [10] Betrice El-Hge. Mobile user signture extrction bsed on user behviourl pttern. Mster s thesis, Arb Open University - Fculty of Computer Studies - Lebnon, [11] Hssn Sbeity Ftim Abdllh nd Ahmd Fdlllh. Stndrdised sclble reloctble context-wre middlewre for mobile pplictions (scmmp). In The Eighth Interntionl Conference on Mobile Ubiquitous Computing, Systems, Services nd Technologies (UBICOMM 2014), [12] Kren Henricksen, Jdwig Indulsk, Ted McFdden, nd Ssithrn Blsubrmnim. Middlewre for distributed context-wre systems. In On the Move to Meningful Internet Systems 2005: CoopIS, DOA, nd ODBASE, pges Springer, [13] GSMA Intelligence. Gsm mobile economy 2015 report. Technicl report, GSMA, [14] Hns-Peter Kriegel, Peer Kroger, Jorg Snder, nd Arthur Zimek. Density-bsed clustering. Wiley Interdisciplinry Reviews: Dt Mining nd Knowledge Discovery, 1(3): , [15] Crl-Fredrik Sørensen, Momo Wu, Thirunvukkrsu Sivhrn, Gordon S Blir, Pul Oknd, Adrin Fridy, nd Hector Durn-Limon. A context-wre middlewre for pplictions in mobile d hoc environments. In Proceedings of the 2nd workshop on Middlewre for pervsive nd d-hoc computing, pges ACM, [16] Herm Vn Krnenburg, M Brgh, Sorin Icob, nd Arjn Peddemors. A context mngement frmework for supporting context-wre distributed pplictions. Communictions Mgzine, IEEE, 44(8):67 74, 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. 27

22 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 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. 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. 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. 28