Smart wearable devices such as smartphones, tablets, smartwatches and fitness bands enable mobile users to form Personal Area Networks (PANs). Some of the devices in the PAN are capable of providing the same functionality. For instance, a fitness band, a smartwatch and a smartphone are each likely to have an accelerometer, a gyroscope, and a heart rate monitor. Similarly, a number of devices on the PAN may have direct Internet connectivity, providing multiple network interfaces. Furthermore, some wearable devices will have sufficient computing resources to perform functions such as data encoding, compression and encryption, while others may not.
Previous analysis of several popular wearable health and fitness tracking applications [Kolamunna2016] shows that app developers tend not to leverage available resources on other devices. For examples, the smartwatch pedometer will still use its own accelerometer when the battery level is low, despite an accelerometer being available on a fully-charged smartphone. The primary reason for relying on local resources only is the app developers reliance on the APIs provided by the target device.111These APIs abstract a large spectrum of functions (e.g., sensing, communication) that are actually implemented by the operating systems (OS) or third party libraries and executed in the device where the application is running.
To harness the collective capabilities of PAN devices, developers have to implement each app individually to utilize the distributed device resources, managing the cost of running these functions in each device and communication costs explicitly. This requires developers to have a wider understanding of distributed systems and increases the complexity of mobile app development. Therefore, an architecture that takes user and device context into account, enabling app developers to utilize all PAN resources easily is needed.
In this paper, we present such an architecture that extends the concept of network function virtualization [MijumbiComSurTot15] to device functions. We show the proposed architecture’s advantages to users and application developers and make the following contributions:
Provide an architecture (AFV) that enables wearable/mobile application function virtualization for the development of adaptive wearable/mobile applications.
Design AFV’s inter-device and intra-device communication protocols to minimize the overhead added by the architecture and maximizes the advantages.
Propose and evaluate a greedy heuristic algorithm for adaptive function allocation across devices considering the available resources and dynamic context of devices in the PAN.
Demonstrate AFV’s ability to adapt to context changes dynamically and demonstrate user and performance benefits of using AFV using a number of applications, and their usage.
The rest of this paper is organized as follows. We first present the AFV architecture, describing each module of AFV followed by the context-aware adaptive function allocation algorithm. Next, we show the realization of AFV with implementation in Android and the experimental calibrations. Performance evaluation with simulation and experiments are presented in details with the experimented use cases of AFV. Finally, we overview related work and complementary systems, and provide conclusions with future work.
2 AFV: Application Function Virtualization
Current PAN devices can be divided into two broad categories, which we refer to as Tier 1 and Tier 2, depicted in Figure 1. Tier 1 devices, (e.g. smartglasses, smartwatches, smartphones), are relatively more resourceful than Tier 2 devices. Tier 2 devices, (e.g. smartshirts and bio-patches) simply carry out sensing functions. In contrast to Tier 2 devices, Tier 1 devices have the following additional features: a) availability of heterogeneous long-range network connectivity (WiFi, cellular), and b) ability to process sensed and received information.
Therefore, Tier 1 devices may be equipped with a rich-set of sensors, multiple connectivity interfaces, storage and computing power to perform wide set of functions such as compression, encoding, rendering, intrusion detection, firewall filtering and encryption. Some of these resources are context dependent, e.g. WiFi connectivity will only be available in limited locations, GPS location will not be available indoors and devices may be disconnected if the battery is depleted.
Since, Tier 2 devices provide complementary and specific functionality that may be duplicated on available Tier 1 devices, an application does not usually need sensors on all devices to be active simultaneously. It is also the case that different sensors have differing output quality and resource requirements that make the selection of functionality for optimal user benefit at run-time a challenge. Thus if all the resources available on a PAN can be effectively utilized in an automated fashion, depending on the user/device context, it should be possible to significantly improve both the dimensions of user utility: functional requirements (precision, accuracy), and performance (energy consumption, latency).
As mentioned, application developers do not effectively utilize all the available resources in a PAN, when developing applications. We believe to facilitate the use of PAN wide resources, that it is necessary to provide methods for designers to seamlessly access the resources, taking in to account the context of use. We further believe this is achievable by virtualizing the commonly used functions distributed across multiple devices on a PAN, and orchestrating the use of the functions depending the context of use, and the system 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 configuration burden of the users; and c) maximizing the user quality of experience.
2.1 AFV Architecture
AFV is a collaborative platform, which runs on the Tier 1 devices and interacts with the Tier 2 devices in a PAN as shown in Figure 1, makes available all potential resources to application developers and/or users seamlessly through APIs.
Figure 2 provides a schematic view of the AFV architecture. To use AFV, applications register requests for the required functions via the AFV APIs explained in Section 2.2. Within AFV, application function registration requests are handled by the Function Manager module as described in Section 2.3. The Context Monitoring module periodically monitors device and user context as detailed in Section 2.4. One of the Tier 1 devices on a PAN is elected as the Master Device. This can either be done by the user or automatically based on a set of criteria such as the lowest ratio between current state of charge and energy usage (i.e., the Tier 1 device that would be least affected by the master tasks).
The automated Master Device selection is done in the Decision Engine (described in Section 2.5) as a collective process of all the Tier 1 devices. The Decision Engine of the selected Master Device then determines the optimal mapping of each application function request to a function provided by a device on the PAN. All the other Tier 1 devices transfer context changes to the Master Device to be used by the Decision Engine. The Communication Manager maintains efficient Inter-device and Intra-device communication as detailed in Section 2.6. Finally, the Function Execution module performs function invocation on devices as described in Section 2.7. Figure 3 shows the diagrammatic representation of the flow of events in AFV when a request is made, which is explained throughout this section.
2.2 AFV APIs
AFV provides two main types of APIs: Function APIs that are executed during run time and Preference APIs that are executed at application start-up.
2.2.1 Function APIs
For each supported function, AFV provides a specific API to the developer. As such, the AFV APIs augments the existing APIs provided by the operating system.
As an example, Figure 4 describes how the AFV API for the sensing function, enhances the API provided by Android. The onSensorChanged and unregisterListener Android APIs are not changed, but are simply reimplemented as AFVonSensorChanged and AFVunregisterListener to be consistent with other APIs.
The registerListener API requires simple modifications. AFVregisterListener augments maxReportLatencyUs input to define the data exchange frequency between applications and devices, and the precision input indicate the required measurement accuracy with respect to absolute correctness, provided as a list of contexts and ranges (e.g., running, 5%, 10%, walking, 5%, 15%). In addition, the optional mapping parameter which provides a list of (context, device) pairs (e.g., walking, smartphone, sitting, smartwatch), is used to enable the developer to force the Decision Engine to select a particular device where possible.
All Function APIs are designed with a similar structure with minimal changes to the existing APIs to reduce the complexity of AFV for the application developers.
2.2.2 Preference APIs
There may be different preferred configurations for the user, application and the device itself when executing an application. These configurations are managed in AFV via the Preference APIs. AFV provides three types of Preference APIs, namely application (setAppPrefs()), user (setUserPrefs()) and device (setDevicePrefs()), which have the same structure. An example of setAppPrefs() is illustrated in Figure 5. The configurations (application, user and device) could be conflicting. This is mitigated by certain possible configurations being mandated, or eliminated. In the current implementation the following order of priority is used: Device, User, Application.
Consider a scenario where the developer (via setAppPrefs()) may specify a fitness tracking application to synchronize data with an Internet server, whenever data connectivity is available. However, the user may wish to override the application’s settings (via setUserPrefs()) by configuring the application to synchronize data only when WiFi connectivity is available. For this example, the preference input in setAppPrefs() is connectivity, 0, where “0” denotes “any network”. And the preference input in setUserPrefs() is connectivity, 1, where “1” denotes “WiFi network”. However, the user Preference API is not directly exposed to the user; rather, it is leveraged by the developer to take user preferences as inputs. For instance, the UI of the application could provide an interface with radio buttons or drop-down lists to allow the user to select required or forbidden device/context mappings.
Additionally, each device may have configurations defined by the manufacturer. For example, iOS devices are recommended to operate below 35 °C.222https://support.apple.com/en-au/HT201678 These configurations are set by the developer via the setDevicePrefs(), so any user specified configurations beyond this is ignored.
All the preferences received via Preference APIs and functional requests received via Function APIs are first transferred to the Function Manager for the management (cf. and in Figure 3).
2.3 Function manager
The Function Manager is responsible for (i) keeping track of device capabilities in terms of supported functions and their associated costs, and (ii) managing the function registration requests and preferences received from AFV-enabled applications. The Function Manager in the Master Device additionally stores the supported functions and associated costs for all Tier 1 devices and their paired (passive) Tier 2 devices in the PAN. These stored information is transferred to the Decision Engine (cf. in Figure 3).
A pre-defined list of supported functions of each device is provided with AFV architecture. The associated cost of each function is composed of two main components; the cost of executing the function and the cost of exchanging inputs/outputs between the requested application and the function running device. Costs would be energy, monetary, latency or any other form. The associated costs are either be provided in the list, which is provided with AFV architecture, or obtained at the initialization using methods available in the devices (e.g., getPower() method in Android). Each time a new AFV-enabled Tier 1 device or a passive Tier 2 device joins the PAN, the Function Manager of the Tier 1 device first discovers the supported functions, and then it announces the availability of functions and related costs to the Master Device (cf. Section 2.6).
Next key role of the Function Manager is the management of function requests and preferences. The preferences received via Preference APIs are considered for the requests where applicable, and apply bound conditions to the requests. For an instant, if the user preferred to use WiFi connectivity, the Internet connectivity function requests from that particular application is bound with the condition to use WiFi connectivity only. The Function Manager aggregates multiple registration requests for the same function from different AFV-enabled applications, and only invokes the function on one of the devices where possible by considering the preferences (cf. Requests Aggregation in Figure 3). Any change in the list of registration requests () notifies as a change of context and transferred to the Context Monitoring module of the device (cf. in Figure 3). Eventually, this is transferred to the Context Monitoring module of the Master Device (cf. ,, in Figure 3), and then triggers the Decision Engine of the Master Device (cf. in Figure 3).
After each re-evaluation of the function allocation in the Decision Engine of the Master Device, the Function Manager receives the mapping between function registration requests and the device selected to execute the function () (cf. ,, in Figure 3). This is re-mapped to each function requesting AFV-enabled application and the device selected to execute the function (). Finally, the Function Manager transfers the mapping to the Communication Manger in order to perform the data transfer from/to the AFV-enabled applications (cf. in Figure 3).
|(i) Maximizing the Functional Quality|
|Precision of fitness tracking||Moving status (i.e. walking or not)|
|Network throughput||Average link speed of the network|
|(ii) Energy Utilization|
|Extend the battery uptime||Battery level, Default energy usage|
|(iii) Minimizing the Monetrary Cost|
|Not exceeding the cap data level||Each device’s connected network|
2.4 Context monitoring
We consider the context monitoring component as an additional virtual function, which runs on a device capable of receiving information from (i) Function Manager, on the changes in registration requests, (ii) sensors, either directly or indirectly (cf. in Figure 3), and transferring to the Decision Engine of the Master Device. The context retrieval function operates as needed and only reports changes relevant to the Decision Engine.
It is possible for context monitoring to be carried out on different devices, depending on the context induced from the sensor values. Each sensed context is directly or indirectly mapped to a system objective function as shown in Table I. Context monitoring is an essential element of AFV. Several implementations of context monitoring exist in the literature [Beach:2010, seemon]. These can be adapted for AFV. The context monitor evaluates the cost of obtaining the measures and selecting the appropriate mechanism/sensor with which to obtain this information. It is also possible that the context may be obtained from the device’s operating system, if those features at that level are enabled [Vallina-Rodriguez:2011].
Since AFV is intended to be used across multiple devices and multiple applications, contexts are represented in the common format described as (name, value) pairs. Context pairs can be defined per-application and per-device in the specific configuration files. The state of a particular context pair is expressed and stored as an enumerated type or string. The value field could be a) a threshold, b) ranges (e.g. moderate temperature could be 20-30 C), or c) a binary value (e.g. the device is either charging or discharging). The context value triggers a context change event and orchestrates appropriate flow of events to notify the Master Device.
2.5 Decision engine
Initially, at the system bootstrap, the Decision Engine module of each device performs the master selection algorithm and elects the Master Device. Then the Decision Engine module on the Master Device executes the function allocation problem (fap (cf. Section 3)), based on received context information from all client devices in the PAN. It determines the mapping of application function registration requests to actual function execution across devices.
The Decision Engine is triggered for a new assignment of functions by the Context Monitoring module on changes of context. First, the decision engine performs the preferred mappings and filters out infeasible function executions by considering the preferences of device, user and application. The preference information is transferred at the context changes. Then, each remaining function registration request is mapped to one of the feasible implementations as described in Section 3.
Then, the Master Device creates individual messages for each device which has (i) the mapping between function registration requests and the device selected to execute the function (), (ii) the mapping between function executions in the device and each requesting device (). These messages are then transferred to the Communication Manager of the Master Device in order to communicate to all the devices in the PAN (cf. in Figure 3).
2.5.1 Objective functions
Although the overall objective of AFV is to maximize the user quality of experience, there can be specific objectives for individual users. We have categorized the potential user specific objectives into three groups: i) Quality, ii) Energy, and iii) Monetary cost. An example set of context information that is required by the Decision Engine to achieve a specific objective is summarized in Table I. We have given the user and/or application developer the ability to configure the optimization preference (via the UI or Preference APIs); by default AFV is configured to optimize Energy. In the case of Quality, we assume the user prefers quality of service improvements, e.g., maximize the precision of sensing information or network throughput, over energy consumption of devices and monetary cost. Then, in the case of Energy, we presume the user prefers to keep all devices in the PAN active for the longest possible time compromising Quality and Monetary cost. Finally, if the user opts for Monetary cost, the Decision Engine makes external communication decisions based on cost per byte information provided by the user (via the UI provided by AFV). However, achieving one objective does not gurentee the achievement of another objective. In order to support different objectives and function categories the Decision Engine runs an instance of the function allocation problem (fap) per objective-function category pair (cf. Section 3).
2.6 Communication manager
This module manages all AFV communications. There are two types of communication modes in AFV: i) Inter-device communication and ii) Intra-device communication.
2.6.1 Inter-device Communication
Communication among devices in the PAN is performed via Bluetooth or other similar low-powered wireless technologies. We define AFV specific message formats rather than using existing data structures (e.g., Java-defined, csv) in order to minimize the amount of data transferred. The defined message formats and descriptions are shown in Appendix A. In addition, the Communication Manager aggregates messages and batches data transfers to further limit communication costs. Inter-device communication in AFV is performed in following situations.
(i) During the system bootstrap or after any device joins/leaves the PAN. All the devices broadcast their own capabilities (e.g., via DataAPI in Android). Initialization Message is used in this phase. The main purpose of this message is to announce the device to the PAN along with its supported functions.
(ii) Changes in the context. In this phase, a Context (Sensor) Message or Context (Request) Message is transmitted from client devices to master device when there is a change in any of the context information.
(iii) Once the Decision Engine module on the Master Device executes the function allocation algorithm. The Communication Manager of the Master Device notifies the other devices with the assignments using Assignment Message, which contains the , and mappings.
(iv) Data transfer from/to other devices in the PAN. When the requested function is selected to run in a different device than the requesting device, the required data is transferred using a Data Message. The Communication Manager is designed to aggregate data for different requests to a particular device in order to remove the additional tail energy after each message transmission.
2.6.2 Intra-device communication
Intra-device communication involves in data exchanges between the AFV and AFV-enabled applications. Data Message format is used for these transfers. There are four methods available for intra-device communication: broadcasting, sockets streams, content provider (specifically in Android), and service callbacks. In broadcasting, all the apps registered with a given broadcast listener receive the broadcasted data, while apps that are not registered with the listener will discard the message. The socket streams, content provider and service callbacks methods provide one-to-one data transmission instead, where data is directly exchanged between AFV and the targeted app.
Intuitively, the most suitable mechanism for intra-device communication depends on the requested function. For example, in the case of sensing functions where multiple different applications are requesting the same function, the use of broadcasting would be efficient. On the other hand, in case of data transfer towards the Internet where applications have different data to transfer, it should be more efficient if data is transferred directly to the application. We experimentally evaluate the energy efficiency of all these methods in Section 5.
2.7 Function execution
This module is responsible for the invocation of functions on the devices selected by the Decision Engine. The Communication Manager forwards the required function invocations (cf. in Figure 3) Then, the Function Execution module leverages operating system APIs to execute functions. Essentially, Function Execution maps the function requests made by AFV APIs to operating system APIs and then invokes the operating system APIs accordingly. The data exchanges in between the AFV-enabled applications and AFV is performed via via the Communication Manager (cf. in Figure 3).
3 Context-aware Function Allocation
We define to be the registration for virtual function , at device , for application , where is the set of applications installed in the PAN. and represents the set of registrations and the list of devices providing implementations respectively for a given virtual function . Thus, the objective of the context-aware function allocation is to map each function registration request to its chosen implementation, i.e. , to optimize the total cost of executing the all requested functions.
3.1 Function costs
The function costs are related to the usability objective of the system, i.e. monetary, quality and/or energy, which can be defined either by the app developer or the user. For each objective, there are two types of costs associated with each function request and its implementations; 1) communication costs and 2) implementation costs. If the objective is to optimize the monetary costs, internal communication (e.g., Bluetooth), can be considered as zero. On the other hand, if the objective is to optimize the energy consumption of the devices, communication is not negligible. Usually, local mapping incurs zero cost. For the same function, the implementation cost can be different for multiple devices, for example, the energy cost of activating the WiFi network interface compared to the total battery capacity on the smartphone is lower than on the smartwatch.
The implementation function cost in device is represented as . Similarly, the communication costs between a given function registration request and an implementation on device are denoted as .
3.2 Problem formulation
We first define a binary variablewhere , if function registration request can be mapped to implementation on device , and otherwise, depending on the current context of the user and the device. For instance, even if the GPS sensor is implemented on the device , it may not be able to map with any request if the current remaining battery capacity on is below the threshold. If no function implementation is available for a particular function registration request, we remove that function from the problem formulation. That makes for all considered functions . Given the set function registrations and function implementations and the associated costs as input, the optimal function allocation problem (fap) can be formulated as follows:
The sets of and would be the solution of the fap. if the function registration request is assigned to the device and if the device is required to be activated to satisfy certain requests. Only mappable implementations will be assigned and each function registration request will be mapped to an implementation.
3.3 Solution to function allocation
When is given , it is trivial to show that fap is equivalent to Uncapacitated Facility Location (ufl) problem where every function implementation is a facility with facility opening cost and every function registration request corresponds to a customer associated with service cost. It immediately follows that fap is also an NP-Hard problem. However, there are number of approximation algorithms for the well-studied ufl problem. We build on the approximation algorithm proposed by Williamson and Shmoys [approxbook] to take into account the use of valid mappings () after context aware constraints. The iterative greedy solution to fap is described in Algorithm 1.
The algorithm iteratively selects a function implementation and the valid registrations associated to it. Assigned registrations are then removed from the problem and the implementation cost set to 0. At each iteration, an implementation is selected as to minimize the total cost of function registrations that will be associated to the implementation. The algorithm can be efficiently realized by maintaining the list of registrations not yet satisfied for each implementation in increasing cost order. fap is performed for each type of function separately, and aggregate the solutions to get the final solution. This further increases the efficiency of fap.
4 Realization of AFV Framework
Our prototype realizes AFV as a library that can be compiled into an application and as a stand-alone user-level application. For simplicity and without loss of generality, it is assumed that all Tier 1 devices in the PAN run the same OS (e.g., Android). The library, AFV lib, provides access to the AFV APIs for the developer once imported to application. To support AFV services to multiple applications in parallel at the user-level, the other components of AFV are implemented in a standalone application, AFV app. At the time of installation of an AFV enabled application, it checks whether the AFV app is already installed. If not, it initiates the installation of the AFV app.
The communication between AFV-enabled devices is implemented using MessageAPI and DataAPI as Android Services. Context monitoring is also implemented as an Android Service. A Master Device is selected among the devices in the network and it runs fap algorithm described in Section 3 to check for optimal function placement.
Device arrival/departure is monitored using the onCapabilityChanged method. When an AFV-enabled device joins/leaves the PAN, all AFV-enabled devices send Initialization Messages via DataAPI to all the connected devices. In addition, Context Monitoring runs in the background and collects information such as battery level, charging status, moving status, connected network, and link speed. When a context of a device changes, it reports the change to the Master Device by sending a Context (Sensor) Message via MessageAPI. This context change will trigger the Decision Engine of the Master Device to make new decisions.
Also, as shown in Figure 6, once an application registers a function (e.g., AFVregisterListener(this, Sensor.TYPE _ACCELEROMETER), AFVHTTPGet), AFV lib sends a broadcast with an Intent about the function registration to AFV app. The BroadcastReceiver in the AFV app transfers the request to the Function Manager. Then, it is identified as a context change and reports to the Master Device by sending a Context (Request) Message via MessageAPI. Then Master Device’s Decision Engine checks for the optimal placement of the function.
The Decision Engine implements the fap algorithm by using efficient ordered data structures (i.e., TreeMultimaps and ArrayLists). Function Execution registers the function using Android APIs and returns data in a self-defined data format to the Communication Manager (Data Message). The Communication Manager aggregates all the Data Messages per device and sends it via MessageAPI. Once the Data Message is received by a device, the Communication Manager broadcasts the data stream. Each app that has a registered listener for the function will receive the data stream.
In Section 5, we use AFV lib and AFV app to evaluate the practical feasibility of AFV and user benefits with use cases.
4.2 Experimental Calibrations
4.2.1 Energy costs of functions
For the fap algorithm to allocate functions optimally, the Function Manager should contain a list of supported functions and their associated costs. We measured energy consumption of several application functions for sensing, communication,333Only WiFi receive measured, transmit is between 20% and 30% higher [modeling-wifi]. and processing. We use a smartphone running Android 6.0 and LG Watch Urbane running Android 5.1.1 with 2300 mAh and 410 mAh battery capacities respectively for all experiments. The functions are reported in Table II.
|Sensing (Speed (NORMAL - UI - GAME - FASTEST ) [mJ/s])|
|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|
|Magnetometer||8.12 - 15.45 - 28.46 - 28.28||17.04 - 30.21 - 57.82 - 79.73|
|Connectivity (Per Byte [mJ/B] - High Power Idle [mJ] - Low Power Idle [mJ])|
|Bluetooth||0.0095 - 305 - 300||0.0024 - 126.07 - 64.23|
|WiFi||0.00054 - 66 - N/A||0.00039 - 50 - N/A|
|Processing (Per Byte [mJ/B])|
The energy consumption for each function is obtained with a Monsoon power monitor444https://www.msoon.com/LabEquipment/PowerMonitor/ 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 at 0.2 ms time intervals. The experiment energy usage is computed by deducting the fixed energy of the background processes from the total energy consumed. Sensing energy is measured for multiple sampling frequencies that are offered by Android by default.555http://developer.android.com/reference/android/hardware/SensorManager.html These energy cost values are used in the experimental validation of AFV architecture and to show user benefits.
4.2.2 Intra-device communication modes
As mentioned in Section 2.6, there are four potential modes for intra-device communication. We experimentally evaluate the energy efficiency of four methods (broadcasting, socket streams, content provider, service call-backs) in the case of AFV message exchanges. Figure 7(a) shows the results for different intra-device communication methods in transferring 2.5 KB of data from AFV to an app. The measurements are done in an Android smartphone. As expected, intra-device communication has much lower energy usage than inter-device communication (cf. Table II). In this particular case, smartphone inter-device communication consumes 23 mJ without tail energy (650 mJ with tail energy) and intra-device communication consumes 1 mJ-6 mJ.
Moreover, we observe that broadcasting requires the minimum energy for transactions even in case of a single application. Therefore, we further experiment with the case where up to eight external apps requesting the same data from AFV architecture. Figure 7(b) illustrates that energy consumption of broadcasting to eight apps is still lower than any other method of intra-app communication for a single one app as shown in Figure 7(a). We thus select broadcasting as the intra-device communication mode in AFV.
5 Performance Evalaution
We first evaluate the performance of the fap algorithm with data driven simulations.
5.1 Evaluation of the FAP Algorithm
5.1.1 Evaluation methodology
We developed a custom simulator to analyze the effectiveness of the Decision Engine, inparticular, fap algorithm. We compared AFV function allocation against three strategies:
manual: User assignment of functions in a static manner, e.g., MyFitnessCompanion [Kolamunna2016].
all: Running functions on all available devices in parallel, which is one of the common strategies in today’s wearable applications, e.g., UP [Kolamunna2016].
optimal: Function allocation, using the optimization problem solver Gurobi.666https://www.gurobi.com
5.1.2 Efficiency and robustness of the FAP algorithm
Figure 8(a) shows the cost reduction obtained when using the fap algorithm with respect to manual, all and optimal as a function of the ratio of function implementation cost () to communication cost (). Communication costs are incurred for any transmission of an individual sensor stream to the device executing the application.
We consider 5 active wearable devices in a PAN. Intuitively, if the communication cost is too high, it is more efficient to execute the function on each device, resulting in parallel apps with no coordination. This is reflected in the region where . Under these conditions all performs as well as optimal and fap. However, fap significantly reduces the cost compared to manual selection. As increases the significance of the communication cost decreases. Thus, executing a function in all devices becomes inefficient as there is potentially a device with a very low relative function execution cost. Since there is a 1/5 chance of selecting the right device, manual performs comparatively well with a high standard deviation. fap performs equally well (error is less than 1%) compared to optimal irrespective of the value.
Figure 8(b) shows that fap increases its cost savings compared to both manual and all along with the number of functions when . Furthermore, fap accuracy does not vary significantly compared to optimal (error is about 2-3%). Overall, Figure 8 shows that the fap algorithm is often able to map the function registration requests to the optimal device for executing the function providing significant cost savings.
5.2 Evaluation of prolong system uptime
We analyze AFV effectiveness by considering system uptime (i.e. time until at least one device drains out its battery) as an example of the quality metric. First, we evaluate the system uptime varying the power status of devices with simulations. Then, we augment simulation results by conducting experiments with real-devices. We consider a smartphone and a smartwatch for both simulations and experiments.
5.2.1 Evaluation with simulations
Uptime of a device depends on its remaining battery percentage (i.e. State of Charge (SoC)) and current energy usage. To simulate typical user behaviour, we assume the smartphone battery would completely drain in two days linearly and the smartwatch would last only one day. We consider the “sensing accelerometer in FASTEST speed” function and 60 second data synchronization frequency: the Decision engine takes decisions to maximize system uptime.We use measurements in Table II to derive energy consumption for the functions. As an example, for sense only on smartphone (Accelerometer FASTEST speed) and data synchronization frequency of one minute (70KB of data), we can get the energy consumption per minute from Table II as =(77.71*60)+((0.0095*70000)+305+300)=5932mJ.
Figure 9(a) illustrates the battery drain profile for manual selection, i.e. sense only on the smartphone or on the smartwatch, and when AFV is running. Due to a lower relative impact on the smartphone, AFV selects the smartphone as the sensing device if the smartphone has sufficient SoC. However, if the smartphone’s SoC drops below 20% (context change), the Context Monitor triggers the Decision Engine and sensing switches to the smartwatch if the smartwatch has sufficient SoC (Figure 9(a)). To show this context change, we consider the following initial conditions: smartphone - 45% SoC, smartwatch 100% SoC. The smartwatch uptime increases by approximately 2 hours compared to sensing on the smartwatch. The gain for the smartphone is approximately 1/2 hour compared to only sensing on the smartphone.
Since uptime gain is dependent on the initial SoC of devices, in Figure 9(b) we change the initial smartphone SoC. If the smartphone remaining SoC is greater than 60% at the beginning, AFV increases the system uptime between 35-40% compared to sensing on the smartwatch and on 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 to sensing only on the smartphone. AFV may marginally reduce the system uptime when the SoC of one or more devices drops below the threshold. To minimize the application energy consumption, while respecting user preferences, the Decision Engine selects the only available device or the most energy efficient when both are under the threshold, although this solution may reduce system uptime. This can be observed when initial Phone SoC is approximately 35% and 55%.
5.2.2 Evaluation with experiments
Next, we quantify the energy consumption of the devices with and without AFV experimentally. We installed AFV on an Android smartphone and a smartwatch. Without AFV, we use counterpart applications that are installed on both devices. We consider the “sensing accelerometer in NORMAL speed” function and 60 second data synchronization frequency. Most current apps select both devices to perform a certain functionality and then exchange data [Kolamunna2016]. Therefore, we selected all function allocation strategy.
Figure 10(a) shows the measured energy consumption for each type of message passing in AFV (cf. Section 2.6). The energy requirement for group formation (Initialization) is J that is much lower compared to the group formation energy in [Hemminki2013]. Figure 10(b) shows the reduction of battery SoC in smartphone and smartwatch. Using AFV achieves lower energy usage by approximately 3 times for one function request, despite the additional energy consumption of AFV (e.g., Initialization, Context Monitoring). Moreover, the battery SoC decreases much faster as the number of functions increases, especially without AFV. Thus more energy is saved with AFVwhen the number of function requests increases.
5.3 Experimental validation of AFV-enabled PAN
We now present experimental results to show quantitative benefits of AFV. As shown in Figure 11, we consider a PAN consisting of 4 devices (3 Tier 1 devices and a Tier 2 device). The Tier 1 devices (smartphone, smartwatch and smartglasses777https://developers.google.com/glass/) are connected with each other via Bluetooth and each have Internet connectivity. The Tier 2 device (smartshirt888https://www.hexoskin.com/) consists with three different sensor types and paired with the smartphone. We developed an AFV enabled fitness tracking application requiring accelerometer and heart rate information to be uploaded to Internet servers, that is similar to the applications previously identified [Kolamunna2016],that is the current popular health and fitness applications. The app was installed in the smartphone, smartwatch and smartglasses.
We investigated five scenarios, to investigate the benefit of using AFV. These experiments evaluated three main objectives described in Table I. For the first objective of achieving the maximum functional quality, we conducted two experiments, one to achieve the best information quality, and the other to achieve the maximum network throughput. For the objective of energy utilization, we examined how the usage of AFV extends the device uptime. Finally, we examined the case of minimizing the monetary cost of data usage.
5.3.1 Maximizing the Functional Quality
(1) Maximizing the precision of fitness/health tracking.
(a) Requesting accelerometer data: The AFV-enabled app requires accelerometer data for fitness tracking. The user is wearing the smartglass and the smartwatch, and has the smartphone nearby while standing and exercising. At first, the user is doing head stretching exerecises and then moves to body stretching exercises. After a while, the user starts walking, carrying the smartphone in the pocket. We consider that the smartphone provides the best quality information when user is walking, smartwatch provides the best quality information when user is doing body stretching activities, and the smartglass provides the best quality information when doing head stretching exercises. This rule is used in the Decision Engine in order to feed the app with best quality of data.
At first, while the user is doing head stretching exercises, as there is no walking detected by the smartphone on the table, and no activities are detected by the smartwatch, the smartglass performs the accelerator function and feeds to the AFV-enabled app. When the user starts doing body stretching exercises, the accelerometer sensing function is moved to the smartwatch and feeds data to the AFV-enabled app. When the smartphone detects that the user is walking, the sensing function moves from the smartwatch to the smartphone. Figure 12(a) shows the accelerometer data that 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 continues 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. Although the AFV architecture is not installed in the smartshirt (as being a Tier 2 device), it is considered as a remote sensor. The smartphone is responsible for pulling data from its remote sensors and feeding it to the AFV.
Assume that the best heart rate measurements are given by the smartshirt as it is dedicatedly designed for sensing. In the absence of the smartshirt, the data is provided by the smartwatch. Therefore, the Decision Engine will select the smartshirt when ever it is available. The context change of the availability of the smartshirt via the smartphone triggers the AFV architecture and the Decision Engine selects the smatrshirt via the smartphone to feed the AFV-enabled app.
Figure 12(b) shows the heart rate data received by the AFV-enabled smartphone app every 10 seconds. It illustrates that the smartshirt is feeding stable and accurate HR data when the user is doing the same activity. In this particular case, the smartshirt’s data is available for third party application development via the cloud. Therefore, the phone is connected to the cloud and retrieves the smartshirt’s real-time data and feeds it to AFV. However, managing resources in Tier 2 devices depends on the accessibility provided by the device manufacturers.
(2) Maximizing the network throughput. In this use case, the AFV virtualizes the Internet connectivity function in order to maximize the network throughput in a heterogeneous environment.
Assume that an AFV-enabled app on the smartphone requires to upload sensor data from the smartphone to an external server periodically (i.e. per second). We created two WiFi networks with different throughputs to emulate the heterogenous network. At first, the smartwatch has Internet connectivity but not the smartphone. After a while, we enable another higher speed network, to which the smartphone is connected. The device’s connectivity to a new network triggers a context change which invokes the Decision Engine to select the higher throughput network to upload the file.
At first, when the smartphone does not have direct Internet connectivity, the data from the smartphone is uplaoded to the Internet servers by relaying through the smartwatch. After a while, when direct Internet connectivity for the smartphone becomes available, the AFV-enabled app on the smartphone automatically suspends the data transfer via the smartwatch and starts transferring directly to the Internet. The achieved throughput is measured at the access points by using a network analyzer (Wireshark999https://www.wireshark.org/). Figure 12(c) depicts the throughput at the access points for data uploads before and after context change.
5.3.2 Extending the device’s uptime.
We use the same AFV-enabled app used previously. In addition, we developed two other apps for the smartphone and smartwatch that have the same functionality but do not use AFV (default Android). In both cases, the app installed in the smartphone requests accelerometer data, and the user preferred the app to get accelerometer data from the smartwatch which is transmitted to the smartphone once per minute.
In the case of AFV, when the SoC reaches the threshold (i.e. 20%), it triggers a context change. Figure 13(a) illustrates the devices’ power profiles during the context change. Initially in this experiment, the smartwatch is sensing at normal speed and sending data to the smartphone once in a minute. When the context is changed at seconds, the smartwatch broadcasts the context change to the Master Device, which triggers the Decision Engine on the Master Device to selects smartphone with a higher SoC for sensing, and informs devices. The smartwatch then stops sensing and the smartphone takes over the sensing function.
The high power peaks of all devices after seconds is due to the messages received and transmitted by each device, which is followed by high power idle states. The high power idle state is longer for the smartphone (until seconds) compared to the smartwatch (until seconds). Figure 13(a) shows that the delay of system adaptation to context changes is less than one second as the smartphone starts sensing even before seconds.
In the default case, the smartwatch keeps running its accelerometer and transfers data to the smartphone until its SoC reaches 0%. Figure 13(b) shows results for the increased longevity of the smartwatch battery when using AFV. The smartwatch uptime is increased by 5 hours due to the sensing function offloading.
5.3.3 Minimizing the monetary cost of data usage
We virtualize the Internet connectivity function in order to minimize the monetary cost of data transfer. The monetary cost for each data plan is pre-configured at system bootstrap and can be changed at any time via the AFV user interface. Assume that the AFV-enabled app needs to upload files to the Internet. Also assume at first, only the smartphone has Internet connectivity, but the smartphone’s data plan has exceeded the available data cap and excess data costs $0.10/MB. After a while, the smartwatch’s Internet connectivity, which has not exceeded the data cap, becomes available. Since this data plan has not exceeded the data limit, this plan costs $0.00/MB.
The availability of the additional network connection triggers a context change and the decision is made to use the low cost network. AFV notifies the device connected to network with lower cost to take over the connectivity function. Figure 14 shows the data usage of the smartphone and smartwatch before and after the context change.
6 Related work
6.1 Context monitoring
There has been substantial work on context awareness and sensing for mobile apps. Always-on sensing can quickly drain battery resources [Shen:2015], yet continuous context monitoring is essential for proper response to context changes [seemon]. This suggests a distinction between always-on and continuous that does not degrade application adaptivity nor battery life. These tradeoffs are explored in several research projects.
The most comprehensive sensing framework is SeeMon [seemon]. Their approach leverages the relationship between sensor values and higher level “context” states to minimize the number of sensors and their associated energy costs while continuously recognizing context changes. Another approach to sensing is to use a low-powered sensor processor to save energy. MobileHub [Shen:2015] provides a framework that determined optimized alerts and submission of sensor data that reduce energy without affecting application semantics. Our context has a limited number of sensors and a small number of devices capable of performing context recognition, therefore, we have simplified the evaluation of sensor readings with a call-back mechanism for each activated sensor to inform the smart device regarding changes to the value of interest.
6.2 Single-device resource utilization
Adaptive system/framework for the context changes is a key concept in resources utilization. Adaptive systems designs have been in existence for nearly 20 years [randell-2005]. Early work provided context based systems development [Chu2011], prototype implementations [adaptive-wearables-korteum1998, Conti2012], programming language support for existing applications [rapidware-2002], and architectures for system design [Edwards:2002, Smailagic:2002]. Applications on commercially available devices have only recently been deployed, due to the challenges of battery and device form, among other issues [personal-wearables-2014, industry-wearables-2014, Rawassizadeh:2014]. For the purpose of resource utilization, Martins [Martins2015] aims to tune the background applications in Android selectively to improve the battery lifetime. They use an OS mechanism to control the frequency of handling background tasks.
CAreDroid [caredroid] is a framework in which to design Android applications to select the most appropriate functions to run for a given application on a single device depending on the context. It takes care of context-monitoring, adaptation decisions and allows the developer to focus on application logic only. Their work provided the inspiration for our focus on distributed system applications for wearable computer network applications. AFV differs in that it provides seamless function placement across devices of a PAN and function sharing across applications. Our optimization engine runs as a lightweight separate process on Tier 1 devices and the adaptation selects which functions from which devices are active at any point in time and what communication strategy will be deployed.
utilizes the sensing functionality in a way that it reduces the energy usage. This work does not require programmer intervention via the Latency, Accuracy Battery (LAB) abstraction. These 3 components are the main considerations in our framework as well, as they provide a meaningful set of tradeoffs for the user and the developer. The authors develop classifiers to infer context in sensing applications, while we use a simpler sensing strategy, but provide adaptation to achieve application goals.
All of the above specified work consider a single device for the resources utilization. In contrast to these work, AFV targets to utilize the resources in a network of multiple smart-wearable devices in order to achieve the user selected objective at the runtime.
6.3 Multi-device resource utilization
Mechanisms to utilize the resources from multiple devices has been receiving increasing attention, and the adaptive framework designs enable developers to create tasks for multiple devices [Kaler:2010, Ravindranath:2012]. There are several studies such as ErdOS [Vallina-Rodriguez:2011], CoSense [Hemminki2013], OSone [osone-pasztor2013] and M+ [MobilePlus].
ErdOS leverages resources in nearby devices based on user modeling and stated user preferences. It uses a lightweight IPC and network stack to securely broadcast important context information and application data in a user-level communication manager. The implementation in CoSense distributes the sensing tasks between familiar devices that are in close proximity. The group formation is done by the cloud backend once the devices are registered to the cloud backend with their mac address. Once the groups are formed, the data is transferred via local connection.
OSone distributes the functionality of the operating system in a similar fashion to how Barrelfish [Baumann-barrelfish] separates functionality onto different cores. The architecture consists of a kernel node in charge of various host nodes that can be kept simpler. M+ allows cross-device functionality sharing. It uses remote procedure call scheme based on the binder IPC mechanism to utilize application and system functionalities across devices.
Moreover, the work such as in Reptor [Reptor] allows third parties to easily distribute their modifications for a platform without the need to update the entire platform. This provide ease for the open innovation for the multi-device platforms for resources utilization. In contrast to the above systems, Rio [Sani2014] presents a system that a device’s resources are utilized by remotely accessing them with the help of another device in the close proximity.
We implement AFV in a similar fashion with the potential to have multiple controlling nodes over time, depending on remaining resources and application needs. AFV runs on a PAN where the devices are already connected with each other via Bluetooth. Therefore, dynamic group formation is not considered in AFV. Moreover, most of these systems are designed for the optimal usage of sensing function. However, AFV framework consider all the available common functions (i.e., sensing, connectivity and computing) in the wearable personal area network. Also, we consider different optimization objectives than energy related matics such as network quality, the quality of the functionality and also the monetary cost.
We follow the philosophies initiated in the early design work on wearables. In particular, Speakeasy [Edwards:2002] motivates the need for domain independent interfaces, mobile code, and user interpretation of semantics. Our representation of context is similar to that provided by Speakeasy and we retain user discernment as well. We are less ambitious in the overall goals as we leverage existing APIs and focus on the adaptive nature of wearable network applications. We do not implement code migration; we provide a system-level extension to code already available on wearable devices. Smailagic and Sieworek [Smailagic:2002] provide key design principles/challenges for future wearable applications: user interface models, input/output modalities, matched capability with requirements, and quick interface evaluation methodology. We focus on the third of these challenges to meet the user’s needs with the lowest resource utilization.
AFV is designed with the premise that all devices in a PAN are always connected and managed by the same person. Therefore, we have not considered the option of dynamic device group formation with nearby devices owned by other people. This is primarily to reduce the privacy and security concerns of communicating with untrusted devices of strangers. On the other hand, we assumed that there are no privacy or security risk in communicating or utilizing functions on the trusted devices on the same PAN. However, this assumption may not always be true, as the third-parties such as trackers, intruders and manufacturers have the access and partially control some functionalities of the devices and its data. Therefore, we intend to mitigate the potential threats of information leakage with the PAN by extending AFV with a context-aware security framework incorporating a set of pre-defined and also user defined device access policies. These policies will then be considered 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 the Decision Engine.
In this paper, we have only validated AFV performance for limited functionalities, i.e. sensing and Internet connectivity, although AFV is designed for efficient utilization of many other functions such as compression, encoding and anonymization. We have noticed the potential difference in overheads associated with each function. Therefore, we aim to further strengthen our function allocation algorithm considering available memory and CPU power as additional context. In addition, for each particular use case, we considered a single objective, which are specified in Table I. However, user may wish to achieve multiple objectives at the same time. As an example, user may wish to have the best quality of information while achieving the minimum possible energy consumption. This can be addressed by formulating a mutli-objective optimization problem in the Decision Engine with different weighting factors for each of the objective. These weighting factors are to be specified by the user via the UI provided by AFV.
Although we developed AFV prototype as a standalone user-level application and a library, it can also be realized by integrating to the OS as a module, which requires root access permission to the kernel. OS module implementation will be efficient in terms of systems overheads of AFV, but it requires significant development effort as well as reduces the deployability of AFV. However, despite this implementation overheads, we showed that AFV outperforms the vanilla scenario without AFV. Therefore, we aim to further improve the user-level development to release AFV as a software development kit (SDK) for app developers, and also, envisage the implementation in multiple OSs.
Majority of devices in a personal area network that consists of multiple smart wearables and hand-held devices have a number of common capabilities and resources. However, 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 network. As a result, the users may not get the best outcome, may incur higher networking cost and may also result in higher energy consumption of devices.
In this paper, we proposed AFV, an architecture that overcomes the above inefficiencies, while reducing the overall energy usage, without adding any latency and minimizing the communication overhead. AFV enables context-aware application function virtualization in a personal area network with a set of APIs that can be easily leveraged by app developers during application development. Our simulation results showed that the proposed function allocation algorithm enables system uptime improvement of up to 35-40% compared with typical configurations of current wearable/mobile applications. Then, we showed the viability of the architecture by implementing AFV in Android devices without loss of generality. Finally, we showed the real world applicability of AFV and user benefits via emulating multiple use cases with real devices.
The defined message formats for Inter-device communication are shown in Table III. These messages are byte streams and start with an eight bit ID field that is reserved to announce the message type.
|Device type (Phone/Watch/Glass)||1|
|Number of networks in the array||1|
|Length of ID,||1, , 4|
|SSID/ Operator ID, Monetary cost|
|Number of function types in the array||1|
|Function type, Energy (per function)||1, 4|
|Context (Sensor) Message|
|Connected network type (Wifi/Cellular),||1, 1,|
|Length of ID, SSID/ Operator ID|
|Average link speed||4|
|Context (Request) Message|
|Request related information|
|Length of the mapping||1|
|Length of the mapping||1|
|Request type, Data length,Data||1,4,|
Initialization Message: The message starts with the 1) device ID and device type, a combination that is used to uniquely identify the device in the PAN followed by connected/available network information and supported functions information.
Context (Sensor) Message contains the source device ID along with the updated information. The current AFV prototype implementation is limited to the context information detailed in Table III.
Context (Request) Message contains an identifier for the request type (e.g., accelerometer data) and the request related information. The request related information is unique to each request type. For example, sensing request contains sensing frequency, and downloading request contains a URL. Therefore, we introduce a message length field that can be used to parse the message byte by byte in combination with request type.
Assignments Message contains the mapping data of and .
Data Message transfers application functions’ input/output data and contains the data itself along with the request type. For instance, data would be a file to upload if the request type is internet access, or would be an array of sensing information if the request type is sensing.