1 Seamless Resources Sharing in Wearable Networks by Application Function Virtualization
Harini Kolamunna, Kanchana Thilakarathna, Diego Perino, Dwight Makaroff and Aruna Seneviratne
Abstract—The prevalence of smart wearable devices is increasing exponentially and we are witnessing a wide variety of fascinating new services that leverage the capabilities of these wearables. Wearables are truly changing the way mobile computing is deployed and mobile applications are being developed. It is possible to leverage the capabilities such as connectivity, processing, and sensing of wearable devices in an adaptive manner for efficient resource usage and information accuracy within the personal area network. We show that application developers are not yet taking advantage of these cross-device capabilities, however, instead using wearables as passive sensors or simple end displays to provide notifications to the user. We thus design AFV (Application Function Virtualization), an architecture enabling automated dynamic function virtualization and scheduling across devices in a personal area network, simplifying the development of the apps that are adaptive to context changes. AFV provides a simple set of APIs hiding complex architectural tasks from app developers whilst continuously monitoring the user, device and network context, to enable the adaptive invocation of functions across devices. We show the feasibility of our design by implementing AFV on Android, and the benefits for the user in terms of resource efficiency, especially in saving energy consumption, and quality of experience with multiple use cases.
Index Terms—smart wearable devices; wearable computing; energy utilization; context monitoring; function virtualization. !
1 INTRODUCTION
MART wearable devices such as smartphones, tablets, utilize the distributed device resources, managing the cost S smartwatches and fitness bands enable mobile users to of running these functions in each device and communi- form Personal Area Networks (PANs). Some of the devices cation costs explicitly. This requires developers to have a in the PAN are capable of providing the same functionality. wider understanding of distributed systems and increases For instance, a fitness band, a smartwatch and a smartphone the complexity of mobile app development. Therefore, an are each likely to have an accelerometer, a gyroscope, and architecture that takes user and device context into account, a heart rate monitor. Similarly, a number of devices on enabling app developers to utilize all PAN resources easily the PAN may have direct Internet connectivity, providing is needed. multiple network interfaces. Furthermore, some wearable In this paper, we present such an architecture that ex- devices will have sufficient computing resources to perform tends the concept of network function virtualization [2] functions such as data encoding, compression and encryp- to device functions. We show the proposed architecture’s tion, while others may not. advantages to users and application developers and make Previous analysis of several popular wearable health and the following contributions: fitness tracking applications [1] shows that app developers • Provide an architecture (AFV) that enables wear- tend not to leverage available resources on other devices. able/mobile application function virtualization for For examples, the smartwatch pedometer will still use its the development of adaptive wearable/mobile ap- own accelerometer when the battery level is low, despite plications. an accelerometer being available on a fully-charged smart- • Design AFV’s inter-device and intra-device commu- arXiv:1711.08495v1 [cs.OS] 14 Nov 2017 phone. The primary reason for relying on local resources nication protocols to minimize the overhead added only is the app developers reliance on the APIs provided by by the architecture and maximizes the advantages. the target device.1 • Propose and evaluate a greedy heuristic algorithm To harness the collective capabilities of PAN devices, for adaptive function allocation across devices con- developers have to implement each app individually to sidering the available resources and dynamic context of devices in the PAN. • H. Kolamunna, K. Thilakarathna, and A. Seneviratne are with the • Demonstrate AFV’s ability to adapt to context School of EE&T, University of New South Wales and Data61- CSIRO, Eveleigh, NSW 2015, Australia. E-mail: {harini.kolamunna, changes dynamically and demonstrate user and per- kanchana.thilakarathna, aruna.seneviratne}@data61.csiro.au formance benefits of using AFV using a number of applications, and their usage. • D. Perino is with Telefonica Research. Email: [email protected] The rest of this paper is organized as follows. We first • D. Makaroff is with University of Saskatchewan. E-mail: present the AFV architecture, describing each module of [email protected] AFV followed by the context-aware adaptive function allo- 1. These APIs abstract a large spectrum of functions (e.g., sensing, cation algorithm. Next, we show the realization of AFV with communication) that are actually implemented by the operating sys- tems (OS) or third party libraries and executed in the device where the implementation in Android and the experimental calibra- application is running. tions. Performance evaluation with simulation and experi- 2 ments are presented in details with the experimented use Apps app 1 app 2 app 3 cases of AFV. Finally, we overview related work and com- AFV Apps Architecture Developer plementary systems, and provide conclusions with future OS AFV APIs Func on API Preference API work. Tier 1 - Device 3 Apps Decision Func on AFV Engine Manager User Architecture 2 AFV: APPLICATION FUNCTION VIRTUALIZATION OS AFV Architecture AFV Tier 1 - Device 2 Context Func on Communica on Manager Monitoring Execu on
OS APIs OS
Tier 2 - Devices Tier 1 - Device 1
Fig. 2. Overview of the AFV and logical connectivity among devices.
state, which we refer to as AFV. In so doing, it is possible to accomplish the goals of a) minimizing the development effort for application developers; b) minimizing the config- uration burden of the users; and c) maximizing the user quality of experience.
Fig. 1. An overview of an personal wearable network. 2.1 AFV Architecture AFV is a collaborative platform, which runs on the Tier 1 Current PAN devices can be divided into two broad devices and interacts with the Tier 2 devices in a PAN as categories, which we refer to as Tier 1 and Tier 2, depicted shown in Figure 1, makes available all potential resources in Figure 1. Tier 1 devices, (e.g. smartglasses, smartwatches, to application developers and/or users seamlessly through smartphones), are relatively more resourceful than Tier 2 APIs. devices. Tier 2 devices, (e.g. smartshirts and bio-patches) Figure 2 provides a schematic view of the AFV archi- simply carry out sensing functions. In contrast to Tier 2 tecture. To use AFV, applications register requests for the devices, Tier 1 devices have the following additional fea- required functions via the AFV APIs explained in Section tures: a) availability of heterogeneous long-range network 2.2. Within AFV, application function registration requests connectivity (WiFi, cellular), and b) ability to process sensed are handled by the Function Manager module as described and received information. in Section 2.3. The Context Monitoring module periodically Therefore, Tier 1 devices may be equipped with a rich- monitors device and user context as detailed in Section 2.4. set of sensors, multiple connectivity interfaces, storage and One of the Tier 1 devices on a PAN is elected as the Master computing power to perform wide set of functions such Device. This can either be done by the user or automatically as compression, encoding, rendering, intrusion detection, based on a set of criteria such as the lowest ratio between firewall filtering and encryption. Some of these resources current state of charge and energy usage (i.e., the Tier 1 are context dependent, e.g. WiFi connectivity will only be device that would be least affected by the master tasks). available in limited locations, GPS location will not be The automated Master Device selection is done in the available indoors and devices may be disconnected if the Decision Engine (described in Section 2.5) as a collective battery is depleted. process of all the Tier 1 devices. The Decision Engine of the Since, Tier 2 devices provide complementary and specific selected Master Device then determines the optimal mapping functionality that may be duplicated on available Tier 1 of each application function request to a function provided devices, an application does not usually need sensors on all by a device on the PAN. All the other Tier 1 devices transfer devices to be active simultaneously. It is also the case that context changes to the Master Device to be used by the Deci- different sensors have differing output quality and resource sion Engine. The Communication Manager maintains efficient requirements that make the selection of functionality for Inter-device and Intra-device communication as detailed in optimal user benefit at run-time a challenge. Thus if all the Section 2.6. Finally, the Function Execution module performs resources available on a PAN can be effectively utilized in an function invocation on devices as described in Section 2.7. automated fashion, depending on the user/device context, Figure 3 shows the diagrammatic representation of the flow it should be possible to significantly improve both the di- of events in AFV when a request is made, which is explained mensions of user utility: functional requirements (precision, throughout this section. accuracy), and performance (energy consumption, latency). As mentioned, application developers do not effectively 2.2 AFV APIs utilize all the available resources in a PAN, when developing AFV provides two main types of APIs: Function APIs that applications. We believe to facilitate the use of PAN wide are executed during run time and Preference APIs that are resources, that it is necessary to provide methods for design- executed at application start-up. ers to seamlessly access the resources, taking in to account the context of use. We further believe this is achievable by 2.2.1 Function APIs virtualizing the commonly used functions distributed across For each supported function, AFV provides a specific API to multiple devices on a PAN, and orchestrating the use of the developer. As such, the AFV APIs augments the existing the functions depending the context of use, and the system APIs provided by the operating system. 3
App Context (Sensor) Func on Context y Master Device Execu on Monitoring Modules y AFV APIs Context (Sensor) Data I/O Vd Func on Preference Context Context (Request) Client Device API API Modules Monitoring k h f a b Decision Communica on e Engine c d Manager x Func on Master Manager Context (Request) FAP g Algorithm Selection B Algorithm Func on A Requests Manager Aggregation Individual Reports
Requests Communica on V àD R àD R àD RdàD i d d Aggregation d Manager k
Data I/O R à D AdàD AdàD j d DeviceCapabilities h Func on
AlltheDevices’ Execu on AdàD l DeviceCapabilities Data I/O via OS APIs Vd
Fig. 3. Diagrammatic representation of AFV.
As an example, Figure 4 describes how the setUserPrefs()) by configuring the application to syn- AFV API for the sensing function, enhances the API chronize data only when WiFi connectivity is available. For provided by Android. The onSensorChanged and this example, the preference input in setAppPrefs() unregisterListener Android APIs are not changed, is
2.2.2 Preference APIs 2.3 Function manager There may be different preferred configurations for The Function Manager is responsible for (i) keeping track the user, application and the device itself when ex- of device capabilities in terms of supported functions and ecuting an application. These configurations are man- their associated costs, and (ii) managing the function regis- aged in AFV via the Preference APIs. AFV pro- tration requests and preferences received from AFV-enabled vides three types of Preference APIs, namely application applications. The Function Manager in the Master Device (setAppPrefs()), user (setUserPrefs()) and device additionally stores the supported functions and associated (setDevicePrefs()), which have the same structure. An costs for all Tier 1 devices and their paired (passive) Tier 2 example of setAppPrefs() is illustrated in Figure 5. The devices in the PAN. These stored information is transferred configurations (application, user and device) could be con- to the Decision Engine (cf. x in Figure 3). flicting. This is mitigated by certain possible configurations A pre-defined list of supported functions of each device being mandated, or eliminated. In the current implementa- is provided with AFV architecture. The associated cost of tion the following order of priority is used: Device, User, each function is composed of two main components; the Application. cost of executing the function and the cost of exchanging Consider a scenario where the developer (via inputs/outputs between the requested application and the setAppPrefs()) may specify a fitness tracking applica- function running device. Costs would be energy, monetary, tion to synchronize data with an Internet server, when- latency or any other form. The associated costs are either ever data connectivity is available. However, the user may wish to override the application’s settings (via 2. https://support.apple.com/en-au/HT201678 4
Android function (Ad 7→ D). Finally, the Function Manager transfers abstract void onSensorChanged(SensorEvent event) the A 7→ D mapping to the Communication Manger in boolean registerListener(SensorEventListener d listener, Sensor sensor, int sampling order to perform the data transfer from/to the AFV-enabled PeriodUs, int maxReportLatencyUs) applications (cf. j in Figure 3).
void unregisterListener(SensorEventListener TABLE 1 listener, Sensor sensor) Example set of context information and mapped system objectives.
AFV System objective Context abstract void AFVonSensorChanged(AFVSensorEvent (i) Maximizing the Functional Quality event) Precision of fitness tracking Moving status (i.e. walking or not) boolean AFVregisterListener Network throughput Average link speed of the network (AFVSensorEventListener listener, (ii) Energy Utilization AFVSensor sensor, int samplingPeriodUs, Extend the battery uptime Battery level, Default energy usage int maxReportLatencyUs, List
of context. First, the decision engine performs the preferred (i) During the system bootstrap or after any device mappings and filters out infeasible function executions by joins/leaves the PAN. All the devices broadcast their own considering the preferences of device, user and application. capabilities (e.g., via DataAPI in Android). Initialization The preference information is transferred at the context Message is used in this phase. The main purpose of this changes. Then, each remaining function registration request message is to announce the device to the PAN along with is mapped to one of the feasible implementations as de- its supported functions. scribed in Section 3. (ii) Changes in the context. In this phase, a Context Then, the Master Device creates individual messages for (Sensor) Message or Context (Request) Message is transmitted each device which has (i) the mapping between function from client devices to master device when there is a change registration requests r ∈ Rd and the device d ∈ D selected in any of the context information. to execute the function (Rd 7→ D), (ii) the mapping between (iii) Once the Decision Engine module on the Master function executions v ∈ Vd in the device and each requesting Device executes the function allocation algorithm. The device d ∈ D (Vd 7→ D). These messages are then trans- Communication Manager of the Master Device notifies the ferred to the Communication Manager of the Master Device in other devices with the assignments using Assignment Mes- order to communicate to all the devices in the PAN (cf. g sage, which contains the Rd 7→ D, and Vd 7→ D mappings. in Figure 3). (iv) Data transfer from/to other devices in the PAN. When the requested function is selected to run in a different 2.5.1 Objective functions device than the requesting device, the required data is trans- Although the overall objective of AFV is to maximize the ferred using a Data Message. The Communication Manager user quality of experience, there can be specific objectives is designed to aggregate data for different requests to a for individual users. We have categorized the potential user particular device in order to remove the additional tail specific objectives into three groups: i) Quality, ii) Energy, energy after each message transmission. and iii) Monetary cost. An example set of context information that is required by the Decision Engine to achieve a specific 2.6.2 Intra-device communication objective is summarized in Table 1. We have given the user Intra-device communication involves in data exchanges be- and/or application developer the ability to configure the tween the AFV and AFV-enabled applications. Data Message optimization preference (via the UI or Preference APIs); by format is used for these transfers. There are four methods default AFV is configured to optimize Energy. In the case available for intra-device communication: broadcasting, sock- of Quality, we assume the user prefers quality of service ets streams, content provider (specifically in Android), and improvements, e.g., maximize the precision of sensing infor- service callbacks. In broadcasting, all the apps registered with a mation or network throughput, over energy consumption of given broadcast listener receive the broadcasted data, while devices and monetary cost. Then, in the case of Energy, we apps that are not registered with the listener will discard presume the user prefers to keep all devices in the PAN the message. The socket streams, content provider and service active for the longest possible time compromising Quality callbacks methods provide one-to-one data transmission in- and Monetary cost. Finally, if the user opts for Monetary cost, stead, where data is directly exchanged between AFV and the Decision Engine makes external communication decisions the targeted app. based on cost per byte information provided by the user (via Intuitively, the most suitable mechanism for intra-device the UI provided by AFV). However, achieving one objective communication depends on the requested function. For does not gurentee the achievement of another objective. In example, in the case of sensing functions where multiple order to support different objectives and function categories different applications are requesting the same function, the the Decision Engine runs an instance of the function alloca- use of broadcasting would be efficient. On the other hand, in tion problem (FAP) per objective-function category pair (cf. case of data transfer towards the Internet where applications Section 3). have different data to transfer, it should be more efficient if data is transferred directly to the application. We experi- 2.6 Communication manager mentally evaluate the energy efficiency of all these methods This module manages all AFV communications. There are in Section 5. two types of communication modes in AFV: i) Inter-device communication and ii) Intra-device communication. 2.7 Function execution 2.6.1 Inter-device Communication This module is responsible for the invocation of functions Communication among devices in the PAN is performed on the devices selected by the Decision Engine. The Commu- via Bluetooth or other similar low-powered wireless tech- nication Manager forwards the required function invocations nologies. We define AFV specific message formats rather (cf. h in Figure 3) Then, the Function Execution mod- than using existing data structures (e.g., Java-defined, csv) ule leverages operating system APIs to execute functions. in order to minimize the amount of data transferred. The Essentially, Function Execution maps the function requests defined message formats and descriptions are shown in made by AFV APIs to operating system APIs and then Appendix A. In addition, the Communication Manager ag- invokes the operating system APIs accordingly. The data gregates messages and batches data transfers to further limit exchanges in between the AFV-enabled applications and communication costs. Inter-device communication in AFV is AFV is performed via via the Communication Manager (cf. performed in following situations. k in Figure 3). 6
3 CONTEXT-AWARE FUNCTION ALLOCATION The sets of xr,d ∈ X and yd ∈ Y would be the solution FAP x = 1 We define ra,v,d ∈ R to be the registration for virtual of the . r,d if the function registration request function v ∈ V , at device d ∈ D, for application a ∈ A, r ∈ Rv is assigned to the device d ∈ Dv and yd = 1 if where A is the set of applications installed in the PAN. the device d is required to be activated to satisfy certain Rv ⊂ R and Dv ⊂ D represents the set of registrations and requests. Only mappable implementations will be assigned the list of devices providing implementations respectively and each function registration request will be mapped to an for a given virtual function v. Thus, the objective of the implementation. context-aware function allocation is to map each function regis- tration request to its chosen implementation, i.e. Rv 7→ Dv, 3.3 Solution to function allocation to optimize the total cost of executing the all requested When mr,d is given ∀r ∈ Rv, ∀d ∈ Dv, it is trivial to show functions. that FAP is equivalent to UNCAPACITATED FACILITY LOCA- TION (UFL) problem where every function implementation 3.1 Function costs Dv is a facility with fv,d facility opening cost and every The function costs are related to the usability objective of function registration request Rv corresponds to a customer the system, i.e. monetary, quality and/or energy, which can associated with cr,d service cost. It immediately follows that be defined either by the app developer or the user. For FAP is also an NP-Hard problem. However, there are number each objective, there are two types of costs associated with of approximation algorithms for the well-studied UFL prob- each function request and its implementations; 1) commu- lem. We build on the approximation algorithm proposed by nication costs and 2) implementation costs. If the objective Williamson and Shmoys [6] to take into account the use of is to optimize the monetary costs, internal communication valid mappings (mr,d) after context aware constraints. The (e.g., Bluetooth), can be considered as zero. On the other iterative greedy solution to FAP is described in Algorithm 1. hand, if the objective is to optimize the energy consumption of the devices, communication is not negligible. Usually, Algorithm 1 FAP(Rv,Dv, m, f, c) local mapping incurs zero cost. For the same function, the 1. S ← Rv implementation cost can be different for multiple devices, 2. X ← ∅ for example, the energy cost of activating the WiFi network 3. while S 6= ∅ do 4. Select v ∈ Dv and P ⊆ S s.t. ∀p ∈ P : mr,d = 1 interface compared to the total battery capacity on the P fv,d+ p∈P cr,d smartphone is lower than on the smartwatch. that minimize |P | The implementation function cost v in device d is rep- 5. S ← S − P ; fv,d = 0 6. (Rv 7→ Dv) ← (Rv 7→ Dv) + (P 7→ v) resented as fv,d ∈ Fv. Similarly, the communication costs 7. return assignment σ : Rv 7→ Dv between a given function registration request ra,v,d and an implementation on device d are denoted as cr,d ∈ Cr. The algorithm iteratively selects a function implemen- tation and the valid registrations associated to it. Assigned 3.2 Problem formulation registrations are then removed from the problem and the im- We first define a binary variable mr,d where mr,d = 1, if plementation cost set to 0. At each iteration, an implemen- function registration request ra,v,d ∈ Rv can be mapped to tation is selected as to minimize the total cost of function implementation on device d ∈ Dv, and mr,d = 0 otherwise, registrations that will be associated to the implementation. depending on the current context of the user and the device. The algorithm can be efficiently realized by maintaining the For instance, even if the GPS sensor is implemented on the list of registrations not yet satisfied for each implementation device d1 ∈ Dv, it may not be able to map d1 with any in increasing cost order. FAP is performed for each type of request if the current remaining battery capacity on d1 is be- function separately, and aggregate the solutions to get the low the threshold. If no function implementation is available final solution. This further increases the efficiency of FAP. for a particular function registration request, we remove that function from the problem formulation. That makes for all P 4 REALIZATION OF AFVFRAMEWORK considered functions ∀d∈D mr,d = 1; ∀r ∈ Rv. Given the v 4.1 Implementation set function registrations Rv and function implementations Dv and the associated costs fv,d as input, the optimal Our prototype realizes AFV as a library that can be com- FUNCTIONALLOCATIONPROBLEM (FAP) can be formulated piled into an application and as a stand-alone user-level as follows: application. For simplicity and without loss of generality, ! it is assumed that all Tier 1 devices in the PAN run the same X X X Minimize yd · fv,d + xr,d · cr,d (1) OS (e.g., Android). The library, AFV lib, provides access to
d∈Dv r∈Rv d∈Dv the AFV APIs for the developer once imported to applica- Subject to: tion. To support AFV services to multiple applications in parallel at the user-level, the other components of AFV are X 1. xr,d = 1; ∀r ∈ Rv implemented in a standalone application, AFV app. At the
d∈Dv time of installation of an AFV enabled application, it checks 2. mr,d ≥ xr,d; ∀r ∈ Rv, ∀d ∈ Dv whether the AFV app is already installed. If not, it initiates the installation of the AFV app. 3. yd ≥ xr,d; ∀r ∈ Rv, ∀d ∈ Dv The communication between AFV-enabled devices is 4. yd, xr,d ∈ {0, 1}; ∀r ∈ Rv, ∀d ∈ Dv implemented using MessageAPI and DataAPI as Android 7
Services. Context monitoring is also implemented as an 4.2 Experimental Calibrations Android Service.A Master Device is selected among the 4.2.1 Energy costs of functions devices in the network and it runs FAP algorithm described For the FAP algorithm to allocate functions optimally, the in Section 3 to check for optimal function placement. Function Manager should contain a list of supported func- Device arrival/departure is monitored using the tions and their associated costs. We measured energy con- onCapabilityChanged method. When an AFV-enabled sumption of several application functions for sensing, com- device joins/leaves the PAN, all AFV-enabled devices send munication,3 and processing. We use a smartphone running Initialization Messages via DataAPI to all the connected Android 6.0 and LG Watch Urbane running Android 5.1.1 devices. In addition, Context Monitoring runs in the back- with 2300 mAh and 410 mAh battery capacities respectively ground and collects information such as battery level, charg- for all experiments. The functions are reported in Table 2. ing status, moving status, connected network, and link speed. When a context of a device changes, it reports the TABLE 2 change to the Master Device by sending a Context (Sensor) Energy cost associated to each function Message via MessageAPI. This context change will trigger Energy cost the Decision Engine of the Master Device to make new deci- Function Smartphone Smartwatch sions. Sensing (Speed (NORMAL - UI - GAME - FASTEST ) [mJ/s]) Also, as shown in Figure 6, once an application Accelerometer 5.01 - 13.28 - 34.46 - 77.71 9.52 - 24.74 - 57.61 - 168.40 Gyroscope 11.71 - 20.33 - 36.44 - 80.15 16.23 - 33.34 - 60.44 - 181.90 registers a function (e.g., AFVregisterListener(this, Magnetometer 8.12 - 15.45 - 28.46 - 28.28 17.04 - 30.21 - 57.82 - 79.73 Sensor.TYPE _ACCELEROMETER), AFVHTTPGet), Connectivity (Per Byte [mJ/B] - High Power Idle [mJ] - Low Power Idle [mJ]) AFV lib sends a broadcast with an Intent about the func- Bluetooth 0.0095 - 305 - 300 0.0024 - 126.07 - 64.23 WiFi 0.00054 - 66 - N/A 0.00039 - 50 - N/A tion registration to AFV app. The BroadcastReceiver in Processing (Per Byte [mJ/B]) the AFV app transfers the request to the Function Manager. Compression 0.01 0.0004 Then, it is identified as a context change and reports to the Encoding 0.00026 0.00025 Master Device by sending a Context (Request) Message via MessageAPI. Then Master Device’s Decision Engine checks The energy consumption for each function is obtained 4 for the optimal placement of the function. with a Monsoon power monitor directly connected to each device via USB. Energy usage is obtained by integrating the instantaneous power values calculated using current and voltage measurements from the USB interface sampled AFV app AFV Enabled App Function Requesting Devices at 0.2 ms time intervals. The experiment energy usage is AFV lib Function Manager computed by deducting the fixed energy of the background processes from the total energy consumed. Sensing energy is Context Monitoring Intent Object Intent Object Function Registration Function Data OS APIs APIs OS Runs in the
Background Background measured for multiple sampling frequencies that are offered
Sensor context Sensor Broadcast Receiver/ 5 Sender by Android by default. These energy cost values are used Communication Manager Message API in the experimental validation of AFV architecture and to Data Message show user benefits. AFV app Master Device AFV app Decision Engine 4.2.2 Intra-device communication modes Message API Function Executing Devices Context Message Context Monitoring Communication Manager As mentioned in Section 2.6, there are four potential modes for intra-device communication. We experimentally eval- Communication Manager Function Execution uate the energy efficiency of four methods (broadcasting, Message API Assignment Message OS APIs socket streams, content provider, service call-backs) in the case of
Intra-Device Communica on AFV message exchanges. Figure 7(a) shows the results for Inter-Device Communica on Communica on Between Modules different intra-device communication methods in transfer- ring 2.5 KB of data from AFV to an app. The measurements are done in an Android smartphone. As expected, intra- Fig. 6. Message flow in the implementation. device communication has much lower energy usage than inter-device communication (cf. Table 2). In this particu- The Decision Engine implements the FAP algorithm by us- lar case, smartphone inter-device communication consumes TreeMultimaps ing efficient ordered data structures (i.e., ∼23 mJ without tail energy (∼650 mJ with tail energy) and ArrayLists and ). Function Execution registers the function intra-device communication consumes ∼1 mJ-6 mJ. using Android APIs and returns data in a self-defined data Moreover, we observe that broadcasting requires the min- format to the Communication Manager (Data Message). The imum energy for transactions even in case of a single Communication Manager aggregates all the Data Messages application. Therefore, we further experiment with the case MessageAPI per device and sends it via . Once the Data where up to eight external apps requesting the same data Message is received by a device, the Communication Manager broadcasts the data stream. Each app that has a registered 3. Only WiFi receive measured, transmit is between 20% and 30% listener for the function will receive the data stream. higher [7]. 4. https://www.msoon.com/LabEquipment/PowerMonitor/ In Section 5, we use AFV lib and AFV app to evaluate the 5. http://developer.android.com/reference/android/hardware/ practical feasibility of AFV and user benefits with use cases. SensorManager.html 8
8 • OPTIMAL Broadcast Content Provider 15 : Function allocation, using the optimiza- 7 Socket Service Callbacks 4 tion problem solver Gurobi.6 6 3 5 10 We assume that costs of executing a function on devices is 4 2 normally distributed, with a standard deviation σ = 0.1 × µ
3 Time (mS) Energy (mJ)
5 Energy (mJ) 2 where µ is the average value. We change µ to obtain multi- 1 1 ple cost values to evaluate the performance of FAP. 0 Energy Time 1APP 2APPs 4APPs 8APPs 5.1.2 Efficiency and robustness of the FAP algorithm (a) With one external app. (b) Broadcasting to multiple apps Figure 8(a) shows the cost reduction obtained when using requesting same data. the FAP algorithm with respect to MANUAL, ALL and OPTI- Fig. 7. Impact of intra-device communication modes. MAL as a function of the ratio of function implementation cost (Fv) to communication cost (Cr). Communication costs 100 FAP saving compared to OPTIMAL are incurred for any transmission of an individual sensor FAP saving compared to RANDOM stream to the device executing the application. 80 FAP saving compared to ALL We consider 5 active wearable devices in a PAN. Intu- 60 itively, if the communication cost is too high, it is more 40 efficient to execute the function on each device, resulting
20 in parallel apps with no coordination. This is reflected in the region where Fv/Cr < 1. Under these conditions ALL
Cost saving of FAP [%] 0 performs as well as OPTIMAL and FAP. However, FAP sig- 0.1 1 10 nificantly reduces the cost compared to MANUAL selection. Cost ratio (Fv/Cr) As Fv/Cr increases the significance of the communication
(a) The impact of cost ratio Fv/Cr. cost decreases. Thus, executing a function in all devices becomes inefficient as there is potentially a device with a 20 very low relative function execution cost. Since there is a 1/5 chance of selecting the right device, MANUAL performs 15 comparatively well with a high standard deviation. FAP
10 performs equally well (error is less than 1%) compared to OPTIMAL irrespective of the Fv/Cr value. FAP saving compared to OPTIMAL 5 FAP saving compared to RANDOM Figure 8(b) shows that FAP increases its cost savings FAP saving compared to ALL compared to both MANUAL and ALL along with the number 0 of functions when Fv/Cr = 1. Furthermore, FAP accuracy Cost savings of FAP [%] 0 5 10 15 20 25 30 35 40 45 50 does not vary significantly compared to OPTIMAL (error is Number of Functions/Devices about 2-3%). Overall, Figure 8 shows that the FAP algorithm
(b) The impact of no. of functions, Fv/Cr = 1. is often able to map the function registration requests to the optimal device for executing the function providing Fig. 8. Efficiency, accuracy and robustness of FAP algorithm. significant cost savings. from AFV architecture. Figure 7(b) illustrates that energy consumption of broadcasting to eight apps is still lower than 5.2 Evaluation of prolong system uptime any other method of intra-app communication for a single We analyze AFV effectiveness by considering system uptime one app as shown in Figure 7(a). We thus select broadcasting (i.e. time until at least one device drains out its battery) as an as the intra-device communication mode in AFV. example of the quality metric. First, we evaluate the system uptime varying the power status of devices with simula- tions. Then, we augment simulation results by conducting 5 PERFORMANCE EVALAUTION experiments with real-devices. We consider a smartphone and a smartwatch for both simulations and experiments. We first evaluate the performance of the FAP algorithm with data driven simulations. 5.2.1 Evaluation with simulations Uptime of a device depends on its remaining battery per- 5.1 Evaluation of the FAP Algorithm centage (i.e. State of Charge (SoC)) and current energy 5.1.1 Evaluation methodology usage. To simulate typical user behaviour, we assume the smartphone battery would completely drain in two days We developed a custom simulator to analyze the effective- linearly and the smartwatch would last only one day. We Decision Engine FAP ness of the , inparticular, algorithm. We consider the “sensing accelerometer in FASTEST speed” compared AFV function allocation against three strategies: function and 60 second data synchronization frequency: • MANUAL: User assignment of functions in a static the Decision engine takes decisions to maximize system up- manner, e.g., MyFitnessCompanion [1]. time.We use measurements in Table 2 to derive energy con- • ALL: Running functions on all available devices in sumption for the functions. As an example, for sense only parallel, which is one of the common strategies in today’s wearable applications, e.g., UP [1]. 6. https://www.gurobi.com 9
2000 100 Initialization Phone Only 1800 Context-Request update Watch Only Phone in Data Exchange 80 AFV - Phone 1600 Watch in Data Exchange Context Change AFV - Watch 1400 60 1200 1000
40 800 Energy (mJ) 600 Threshold at 20% 20 400
Remaining battery [%] 200
0 0 Master Client Master Client Client Functioning Requesting 8 10 12 14 16 18 20 changing not changing Device Device context context Time [hours] (a) Energy consumption of different message passing phases. (a) Battery drain profiles
100 40 80 35 An app on each device is requesting 30 Accelerometer data 60 An app on each device 25 is requesting Accelerometer and Gyroscope data 20 40 15 AFV compared to Phone only 10 AFV compared to Watch only 20 Smartphone with Android AFV compared to ALL Smartwatch with Android An app on each device with AVF [%] is requesting 5 Smartphone with AFV+Android Accelerometer, Gyroscope Smartwatch with AFV+Android and Magnetometer data Battery State of Charge(SoC) (%) 0 0 0 500 1000 1500 2000 2500 3000 System uptime increase -5 Time (min) 0 10 20 30 40 50 60 70 80 90 100 Remaining battery of the phone at the beginning [%] (b) Energy consumption with and without AFV when each device is requesting for different functionalities. (b) Percentage increase in system uptime. Fig. 10. Energy consumption of the system. Fig. 9. The impact of AFV on system uptime. on smartphone (Accelerometer FASTEST speed) and data and 55%. synchronization frequency of one minute (70KB of data), we 5.2.2 Evaluation with experiments can get the energy consumption per minute from Table 2 as f + c=(77.71*60)+((0.0095*70000)+305+300)=5932mJ. Next, we quantify the energy consumption of the devices Figure 9(a) illustrates the battery drain profile for MAN- with and without AFV experimentally. We installed AFV on UAL selection, i.e. sense only on the smartphone or on the an Android smartphone and a smartwatch. Without AFV, smartwatch, and when AFV is running. Due to a lower rela- we use counterpart applications that are installed on both tive impact on the smartphone, AFV selects the smartphone devices. We consider the “sensing accelerometer in NOR- as the sensing device if the smartphone has sufficient SoC. MAL speed” function and 60 second data synchronization However, if the smartphone’s SoC drops below 20% (context frequency. Most current apps select both devices to perform change), the Context Monitor triggers the Decision Engine and a certain functionality and then exchange data [1]. There- sensing switches to the smartwatch if the smartwatch has fore, we selected ALL function allocation strategy. sufficient SoC (Figure 9(a)). To show this context change, Figure 10(a) shows the measured energy consumption we consider the following initial conditions: smartphone - for each type of message passing in AFV (cf. Section 2.6). 45% SoC, smartwatch 100% SoC. The smartwatch uptime The energy requirement for group formation (Initialization) increases by approximately 2 hours compared to sensing is (0.6 ∗ (n − 1) + 1.8)J that is much lower compared to on the smartwatch. The gain for the smartphone is ap- the group formation energy in [8]. Figure 10(b) shows the proximately 1/2 hour compared to only sensing on the reduction of battery SoC in smartphone and smartwatch. smartphone. Using AFV achieves lower energy usage by approximately 3 times for one function request, despite the additional energy Since uptime gain is dependent on the initial SoC of consumption of AFV (e.g., Initialization, Context Monitor- devices, in Figure 9(b) we change the initial smartphone ing). Moreover, the battery SoC decreases much faster as SoC. If the smartphone remaining SoC is greater than 60% the number of functions increases, especially without AFV. at the beginning, AFV increases the system uptime between Thus more energy is saved with AFVwhen the number of 35-40% compared to sensing on the smartwatch and on function requests increases. both devices. Due to sufficient battery capacity on the smartphone, AFV selects the smartphone most of the time. As a result, AFV does not increase the uptime compared 5.3 Experimental validation of AFV-enabled PAN to sensing only on the smartphone. AFV may marginally We now present experimental results to show quantitative reduce the system uptime when the SoC of one or more benefits of AFV. As shown in Figure 11, we consider a devices drops below the threshold. To minimize the applica- PAN consisting of 4 devices (3 Tier 1 devices and a Tier tion energy consumption, while respecting user preferences, 2 device). The Tier 1 devices (smartphone, smartwatch and the Decision Engine selects the only available device or the smartglasses7) are connected with each other via Bluetooth most energy efficient when both are under the threshold, and each have Internet connectivity. The Tier 2 device although this solution may reduce system uptime. This can be observed when initial Phone SoC is approximately 35% 7. https://developers.google.com/glass/ 10
is received by the AFV-enabled application installed in the smartphone. In order to avoid unnecessary functionality movements between devices for this context, AFV triggers a function placement change only if the new activity con- tinues for a goven period of time, in this experiment 10 seconds. During this time, the previously selected device continues to feed data to the AFV-enabled app. (b) Requesting heart rate data: Next, the AFV-enabled app requests for heart rate (HR) data. Assume that at first, the user has the smartphone and the smartwatch. When the user dons the smartshirt, it is paired with the smartphone. Al- though the AFV architecture is not installed in the smartshirt Fig. 11. Experimental Setup. (as being a Tier 2 device), it is considered as a remote sensor. The smartphone is responsible for pulling data from its 8 (smartshirt ) consists with three different sensor types and remote sensors and feeding it to the AFV. paired with the smartphone. We developed an AFV enabled Assume that the best heart rate measurements are given fitness tracking application requiring accelerometer and by the smartshirt as it is dedicatedly designed for sensing. heart rate information to be uploaded to Internet servers, In the absence of the smartshirt, the data is provided by the that is similar to the applications previously identified smartwatch. Therefore, the Decision Engine will select the [1],that is the current popular health and fitness applica- smartshirt when ever it is available. The context change of tions. The app was installed in the smartphone, smartwatch the availability of the smartshirt via the smartphone triggers and smartglasses. the AFV architecture and the Decision Engine selects the We investigated five scenarios, to investigate the benefit smatrshirt via the smartphone to feed the AFV-enabled app. of using AFV. These experiments evaluated three main ob- Figure 12(b) shows the heart rate data received by the jectives described in Table 1. For the first objective of achiev- AFV-enabled smartphone app every 10 seconds. It illus- ing the maximum functional quality, we conducted two trates that the smartshirt is feeding stable and accurate HR experiments, one to achieve the best information quality, data when the user is doing the same activity. In this par- and the other to achieve the maximum network throughput. ticular case, the smartshirt’s data is available for third party For the objective of energy utilization, we examined how application development via the cloud. Therefore, the phone the usage of AFV extends the device uptime. Finally, we is connected to the cloud and retrieves the smartshirt’s real- examined the case of minimizing the monetary cost of data time data and feeds it to AFV. However, managing resources usage. in Tier 2 devices depends on the accessibility provided by the device manufacturers. 5.3.1 Maximizing the Functional Quality (2) Maximizing the network throughput. In this use case, (1) Maximizing the precision of fitness/health tracking. the AFV virtualizes the Internet connectivity function in or- (a) Requesting accelerometer data: The AFV-enabled app der to maximize the network throughput in a heterogeneous requires accelerometer data for fitness tracking. The user environment. is wearing the smartglass and the smartwatch, and has Assume that an AFV-enabled app on the smartphone the smartphone nearby while standing and exercising. At requires to upload sensor data from the smartphone to an first, the user is doing head stretching exerecises and then external server periodically (i.e. per second). We created moves to body stretching exercises. After a while, the user two WiFi networks with different throughputs to emulate starts walking, carrying the smartphone in the pocket. We the heterogenous network. At first, the smartwatch has consider that the smartphone provides the best quality Internet connectivity but not the smartphone. After a while, information when user is walking, smartwatch provides the we enable another higher speed network, to which the best quality information when user is doing body stretch- smartphone is connected. The device’s connectivity to a ing activities, and the smartglass provides the best quality new network triggers a context change which invokes the information when doing head stretching exercises. This rule Decision Engine to select the higher throughput network to is used in the Decision Engine in order to feed the app with upload the file. best quality of data. At first, when the smartphone does not have direct Inter- At first, while the user is doing head stretching exercises, net connectivity, the data from the smartphone is uplaoded as there is no walking detected by the smartphone on the to the Internet servers by relaying through the smartwatch. table, and no activities are detected by the smartwatch, the After a while, when direct Internet connectivity for the smartglass performs the accelerator function and feeds to smartphone becomes available, the AFV-enabled app on the the AFV-enabled app. When the user starts doing body smartphone automatically suspends the data transfer via the stretching exercises, the accelerometer sensing function is smartwatch and starts transferring directly to the Internet. moved to the smartwatch and feeds data to the AFV-enabled The achieved throughput is measured at the access points by app. When the smartphone detects that the user is walking, using a network analyzer (Wireshark9). Figure 12(c) depicts the sensing function moves from the smartwatch to the the throughput at the access points for data uploads before smartphone. Figure 12(a) shows the accelerometer data that and after context change.
8. https://www.hexoskin.com/ 9. https://www.wireshark.org/ 11
16 20 Data received from smartglass 90 Data received from smartwatch Data transfer via smartwatch Data received from smartwatch Data received from smartshirt 14 Direct data transfer from smartphone Data received from smartphone 80 ) 15
-2 12 70 Context Change 10 Context Change 10 5 60 8 Phone connected to 0 50 Smart-shirt is available 6 a network which has Heart Rate higher throughput
-5 40 Data Rate (Mbps)
Acceleration (ms 4 User started hand exercises Function -10 is 30 Context Change 2 User started walking moved -15 20 0 0 20 40 60 80 100 120 140 160 0 50 100 150 200 250 300 350 400 0 5 10 15 20 25 30 35 Time (s) Time (s) Time (s) (a) Accelerometer data received by an AFV- (b) Heart rate data received by an AFV- (c) Dynamically switching to the higher data enabled application installed in smartphone. enabled application installed in smartwatch. rate network for data uploading.
Fig. 12. Maximizing the functional quality with AFV.
700 100 Smartphone Starts Sensing Smartwatch Watch with Android Sensing and Phone with Android 600 Smartphone Transmitting Smartglass Watch with AFV+Android 80 starts in phone Phone with AFV+Android 500 Context Change
400 System Adaptation 60 Smartwatch is Context Change 300 Sensing 40 Threshold SoC Sensing and for AFV Power (mW) 200 Transmitting stops in watch 20 100
0 Battery State of Charge(SoC) (%) 0 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 1 2 3 4 5 6 7 8 Time (s) Time (Hours) (a) Energy consumption profiles for devices in the PAN. (b) Battery state of charge measured in smart- phone and smartwatch during AFV-enabled and not enabled cases. Fig. 13. Extending the device uptime with AFV.
5.3.2 Extending the device’s uptime. Smartphone Data Usage 700 Smartwatch Data Usage We use the same AFV-enabled app used previously. In 600 addition, we developed two other apps for the smartphone Data Plan Cap Context Change and smartwatch that have the same functionality but do not 500 use AFV (default Android). In both cases, the app installed 400 smartwatch is available with in the smartphone requests accelerometer data, and the Data Usage (MB) 300 a lower monetary cost network
user preferred the app to get accelerometer data from the 200
smartwatch which is transmitted to the smartphone once 0 500 1000 1500 2000 per minute. Time (S) In the case of AFV, when the SoC reaches the threshold Fig. 14. Dynamically switching to the less costly network for data up- (i.e. 20%), it triggers a context change. Figure 13(a) illus- loading. trates the devices’ power profiles during the context change. Initially in this experiment, the smartwatch is sensing at sensing function offloading. normal speed and sending data to the smartphone once in a minute. When the context is changed at t = 15 seconds, 5.3.3 Minimizing the monetary cost of data usage the smartwatch broadcasts the context change to the Master We virtualize the Internet connectivity function in order to Device, which triggers the Decision Engine on the Master minimize the monetary cost of data transfer. The monetary Device to selects smartphone with a higher SoC for sensing, cost for each data plan is pre-configured at system bootstrap and informs devices. The smartwatch then stops sensing and can be changed at any time via the AFV user interface. and the smartphone takes over the sensing function. Assume that the AFV-enabled app needs to upload files The high power peaks of all devices after t = 15 seconds to the Internet. Also assume at first, only the smartphone is due to the messages received and transmitted by each has Internet connectivity, but the smartphone’s data plan device, which is followed by high power idle states. The has exceeded the available data cap and excess data costs high power idle state is longer for the smartphone (until $0.10/MB. After a while, the smartwatch’s Internet con- t = 26 seconds) compared to the smartwatch (until t = nectivity, which has not exceeded the data cap, becomes 20 seconds). Figure 13(a) shows that the delay of system available. Since this data plan has not exceeded the data adaptation to context changes is less than one second as the limit, this plan costs $0.00/MB. smartphone starts sensing even before t = 16 seconds. The availability of the additional network connection In the default case, the smartwatch keeps running its triggers a context change and the decision is made to use accelerometer and transfers data to the smartphone until its the low cost network. AFV notifies the device connected SoC reaches 0%. Figure 13(b) shows results for the increased to network with lower cost to take over the connectivity longevity of the smartwatch battery when using AFV. The function. Figure 14 shows the data usage of the smartphone smartwatch uptime is increased by 5 hours due to the and smartwatch before and after the context change. 12
6 RELATED WORK The authors develop classifiers to infer context in sensing 6.1 Context monitoring applications, while we use a simpler sensing strategy, but provide adaptation to achieve application goals. There has been substantial work on context awareness and All of the above specified work consider a single device sensing for mobile apps. Always-on sensing can quickly for the resources utilization. In contrast to these work, drain battery resources [9], yet continuous context monitor- AFV targets to utilize the resources in a network of multiple ing is essential for proper response to context changes [4]. smart-wearable devices in order to achieve the user selected This suggests a distinction between always-on and continu- objective at the runtime. ous that does not degrade application adaptivity nor battery life. These tradeoffs are explored in several research projects. The most comprehensive sensing framework is SeeMon 6.3 Multi-device resource utilization [4]. Their approach leverages the relationship between sen- Mechanisms to utilize the resources from multiple devices sor values and higher level “context” states to minimize has been receiving increasing attention, and the adaptive the number of sensors and their associated energy costs framework designs enable developers to create tasks for while continuously recognizing context changes. Another multiple devices [23], [24]. There are several studies such approach to sensing is to use a low-powered sensor proces- as ErdOS [5], CoSense [8], OSone [25] and M+ [26]. sor to save energy. MobileHub [9] provides a framework ErdOS leverages resources in nearby devices based that determined optimized alerts and submission of sen- on user modeling and stated user preferences. It uses a sor data that reduce energy without affecting application lightweight IPC and network stack to securely broadcast semantics. Our context has a limited number of sensors and important context information and application data in a a small number of devices capable of performing context user-level communication manager. The implementation in recognition, therefore, we have simplified the evaluation of CoSense distributes the sensing tasks between familiar de- sensor readings with a call-back mechanism for each acti- vices that are in close proximity. The group formation is vated sensor to inform the smart device regarding changes done by the cloud backend once the devices are registered to to the value of interest. the cloud backend with their mac address. Once the groups are formed, the data is transferred via local connection. 6.2 Single-device resource utilization OSone distributes the functionality of the operating sys- Adaptive system/framework for the context changes is tem in a similar fashion to how Barrelfish [27] separates a key concept in resources utilization. Adaptive systems functionality onto different cores. The architecture consists designs have been in existence for nearly 20 years [10]. of a kernel node in charge of various host nodes that Early work provided context based systems development can be kept simpler. M+ allows cross-device functionality [11], prototype implementations [12], [13], programming sharing. It uses remote procedure call scheme based on the language support for existing applications [14], and ar- binder IPC mechanism to utilize application and system chitectures for system design [15], [16]. Applications on functionalities across devices. commercially available devices have only recently been Moreover, the work such as in Reptor [28] allows third deployed, due to the challenges of battery and device form, parties to easily distribute their modifications for a platform among other issues [17], [18], [19]. For the purpose of re- without the need to update the entire platform. This provide source utilization, Martins [20] aims to tune the background ease for the open innovation for the multi-device platforms applications in Android selectively to improve the battery for resources utilization. In contrast to the above systems, lifetime. They use an OS mechanism to control the frequency Rio [29] presents a system that a device’s resources are of handling background tasks. utilized by remotely accessing them with the help of another CAreDroid [21] is a framework in which to design An- device in the close proximity. droid applications to select the most appropriate functions We implement AFV in a similar fashion with the poten- to run for a given application on a single device depending tial to have multiple controlling nodes over time, depending on the context. It takes care of context-monitoring, adapta- on remaining resources and application needs. AFV runs on tion decisions and allows the developer to focus on appli- a PAN where the devices are already connected with each cation logic only. Their work provided the inspiration for other via Bluetooth. Therefore, dynamic group formation is our focus on distributed system applications for wearable not considered in AFV. Moreover, most of these systems are computer network applications. AFV differs in that it pro- designed for the optimal usage of sensing function. How- vides seamless function placement across devices of a PAN ever, AFV framework consider all the available common and function sharing across applications. Our optimization functions (i.e., sensing, connectivity and computing) in the engine runs as a lightweight separate process on Tier 1 wearable personal area network. Also, we consider different devices and the adaptation selects which functions from optimization objectives than energy related matics such as which devices are active at any point in time and what network quality, the quality of the functionality and also the communication strategy will be deployed. monetary cost. Senergy [22] utilizes the sensing functionality in a way We follow the philosophies initiated in the early design that it reduces the energy usage. This work does not re- work on wearables. In particular, Speakeasy [15] motivates quire programmer intervention via the Latency, Accuracy the need for domain independent interfaces, mobile code, Battery (LAB) abstraction. These 3 components are the main and user interpretation of semantics. Our representation of considerations in our framework as well, as they provide a context is similar to that provided by Speakeasy and we meaningful set of tradeoffs for the user and the developer. retain user discernment as well. We are less ambitious in the 13 overall goals as we leverage existing APIs and focus on the improve the user-level development to release AFV as a adaptive nature of wearable network applications. We do software development kit (SDK) for app developers, and not implement code migration; we provide a system-level also, envisage the implementation in multiple OSs. extension to code already available on wearable devices. Smailagic and Sieworek [16] provide key design princi- ples/challenges for future wearable applications: user inter- 8 CONCLUSION face models, input/output modalities, matched capability Majority of devices in a personal area network that consists with requirements, and quick interface evaluation method- of multiple smart wearables and hand-held devices have ology. We focus on the third of these challenges to meet the a number of common capabilities and resources. However, user’s needs with the lowest resource utilization. current popular mobile and wearable applications do not utilize these resources efficiently that leads to multiple of application function executions in the same personal area 7 DISCUSSION network. As a result, the users may not get the best outcome, AFV is designed with the premise that all devices in a PAN may incur higher networking cost and may also result in are always connected and managed by the same person. higher energy consumption of devices. Therefore, we have not considered the option of dynamic In this paper, we proposed AFV, an architecture that device group formation with nearby devices owned by overcomes the above inefficiencies, while reducing the over- other people. This is primarily to reduce the privacy and all energy usage, without adding any latency and mini- security concerns of communicating with untrusted devices mizing the communication overhead. AFV enables context- of strangers. On the other hand, we assumed that there are aware application function virtualization in a personal area no privacy or security risk in communicating or utilizing network with a set of APIs that can be easily leveraged by functions on the trusted devices on the same PAN. However, app developers during application development. Our simu- this assumption may not always be true, as the third- lation results showed that the proposed function allocation parties such as trackers, intruders and manufacturers have algorithm enables system uptime improvement of up to 35- the access and partially control some functionalities of the 40% compared with typical configurations of current wear- devices and its data. Therefore, we intend to mitigate the able/mobile applications. Then, we showed the viability of potential threats of information leakage with the PAN by the architecture by implementing AFV in Android devices extending AFV with a context-aware security framework without loss of generality. Finally, we showed the real world incorporating a set of pre-defined and also user defined applicability of AFV and user benefits via emulating multi- device access policies. These policies will then be considered ple use cases with real devices. during function allocation as another context information. For example, if a device is connected to a public WiFi access point, the device may not be used to virtualize functions by APPENDIX A the Decision Engine. The defined message formats for Inter-device communica- In this paper, we have only validated AFV performance tion are shown in Table 3. These messages are byte streams for limited functionalities, i.e. sensing and Internet connec- and start with an eight bit ID field that is reserved to tivity, although AFV is designed for efficient utilization of announce the message type. many other functions such as compression, encoding and Initialization Message: The message starts with the 1) anonymization. We have noticed the potential difference device ID and device type, a combination that is used in overheads associated with each function. Therefore, we to uniquely identify the device in the PAN followed by aim to further strengthen our function allocation algorithm connected/available network information and supported considering available memory and CPU power as additional functions information. context. In addition, for each particular use case, we con- Context (Sensor) Message contains the source device sidered a single objective, which are specified in Table 1. ID along with the updated information. The current However, user may wish to achieve multiple objectives at AFV prototype implementation is limited to the context the same time. As an example, user may wish to have the information detailed in Table 3. best quality of information while achieving the minimum Context (Request) Message contains an identifier possible energy consumption. This can be addressed by for the request type (e.g., accelerometer data) and formulating a mutli-objective optimization problem in the the request related information. The request related Decision Engine with different weighting factors for each of information is unique to each request type. For exam- the objective. These weighting factors are to be specified by ple, sensing request contains sensing frequency, and down- the user via the UI provided by AFV. loading request contains a URL. Therefore, we introduce Although we developed AFV prototype as a standalone a message length field that can be used to parse the user-level application and a library, it can also be realized message byte by byte in combination with request type. by integrating to the OS as a module, which requires root Assignments Message contains the mapping data of access permission to the kernel. OS module implementation Rd 7→ D and Vd 7→ D. will be efficient in terms of systems overheads of AFV, but Data Message transfers application functions’ in- it requires significant development effort as well as reduces put/output data and contains the data itself along with the deployability of AFV. However, despite this implemen- the request type. For instance, data would be a file to tation overheads, we showed that AFV outperforms the upload if the request type is internet access, or would be an vanilla scenario without AFV. Therefore, we aim to further array of sensing information if the request type is sensing. 14
TABLE 3 [11] D. Chu, A. Kansal, J. Liu, and F. Zhao, “Mobile Apps: It’s Time to Message formats. move up to condos,” in Proceedings of the 13th USENIX Conference on Hot Topics in Operating Systems, 2011, pp. 1–5. Description Length [Bytes] [12] G. Kortuem, Z. Segall, and M. Bauer, “Context-aware, Adaptive Wearable Computers as Remote Interfaces to ’Intelligent’ Envi- Initialization Message Proc, ISWC Message Type 1 ronments,” in , New York, NY, 1998, pp. 58–65. Device ID 8 [13] M. Conti, B. Bruno Crispo, E. Fernandes, and Y. Zhauniarovich, Device type (Phone/Watch/Glass) 1 “CRePEˆ : A System for Enforcing Fine-Grained Context-Related Number of networks in the array 1 Policies on Android,” IEEE Transaction on Information Forensics and Length of ID, Security, vol. 7, no. 5, pp. 1426–1438, 2012. < 1, n1, 4 > SSID/ Operator ID, Monetary cost [14] P. K. McKinley, S. M. Sadjadi, E. P. Kasten, and R. Kalaskar, “Pro- Number of function types in the array 1 gramming Language Support for Adaptable Wearable Comput- Function type, Energy (per function) < 1, 4 > ing,” in Proceedings of the 6th International Symposium on Wearable Context (Sensor) Message Computers, New York, NY, 2002, pp. 205–212. Message Type 1 [15] W. K. Edwards, M. W. Newman, J. Sedivy, T. Smith, and Battery level 1 S. Izadi, “Challenge: Recombinant computing and the speakeasy Charging status 1 approach,” in Proceedings of the 8th Annual International Conference Moving status 1 on Mobile Computing and Networking, New York, NY, 2002, pp. 279– Connected network type (Wifi/Cellular), < 1, 1, n2 > 286. Length of ID, SSID/ Operator ID [16] A. Smailagic and D. Siewiorek, “Application Design for Wearable Average link speed 4 and Context-Aware Computers,” IEEE Pervasive Computing, vol. 1, Context (Request) Message no. 4, pp. 20–29, Oct. 2002. Message Type 1 [17] S. Brachmann, “Wearable Gadgets: What is Request type 1 the Secret to Commercial Success?” 2014. [On- Request related information n3 line]. Available: http://www.ipwatchdog.com/2014/11/15/ Assignments Message wearable-gadgets-the-secret-to-commercial-success/id=52159/ Message Type 1 [18] J. Mischke, “Wearables for Professional Length of the R 7→ D mapping 1 d and Industry Applications,” 2014. [Online]. R 7→ D