SOUL: An Edge-cloud System for Mobile Applications in a Sensor-rich World

Summary:
This paper focuses on challenges faced today in terms of different kinds of sensors available and management of corresponding protocols, how to overcome bottlenecks as far as resource constraints of devices are concerned, access privilege management for the data generated and scalability as far as number of sensors available and their mobile(dynamic) nature. SOUL stands for Sensors of Ubiquitous Life and it moves all the processing(interaction between sensors and actuators) to edge or remote cloud. It always tries to provide applications with best sensor and corresponding actuator available as far as resource availability and proximity is concerned. Access privileges for third party applications to access certain end users sensor-actuator is given at runtime. Paper presents a system for virtualizing sensors-actuator-services triplet to provide consistent and easy access to them. Authors compare the performance of apps and effect on battery life when using android sensor framework vs SOUL aggregate. Authors believe that SOUL will help applications use more(100s) number of sensors with ease of use and without actually effecting the battery of a mobile device as compared to current usage of 1 sensors by around 98.08% of apps analysed in the survey.

Design:
There are two main components of SOUL:
1. SOUL core : Built on top of edge cloud infrastructure(PCloud). It processes all the requests coming in from apps and gathers necessary data from sensor-actuator-service triplet.
2. SOUL engine : It exposes a virtual layer called aggregate to the apps. It runs on user's device and is a middle layer between the app and SOUL core.

Sensor data when requested is first stored in SOUL's sensor datastore before delivering it to the app. This helps SOUL to provide past and current data which will realize into better sensor processing. One more important aspect of SOUL is runtime access permissions for nearby sensors. Authors rightly say that there are few use cases which makes sensor data sharing inevitable. For better user experience SOUL assists users to setup privacy policies via reference monitor. Since all of the processing is done at remote resources, the app code is executed sand-boxed. The access authentication is driven by a Facebook app between the user app and owner of the sensor.

SOUL provides two kinds of data access, 1) Glance, which means that you can get summarized data(based on what sensor owner wants to expose for everyone) even without access permission, 2) Read, for which the app needs to have proper access privilege before requesting data and it will be detailed.

Strengths of the Paper:
1. One very good feature I liked about SOUL is that it uses social network(Facebook) to decide on policy that should be applied to a user. I feel that there's a lot of context between both the parties that can be leveraged, hence there's a lot of scope of finding new heuristic for policy generator.
2. Segregating glance and read type of access request helps SOUL cover a lot of use cases as compared to other similar systems. It uses the fact that there's always some processed data that can be broadcasted to everyone for community benefit.
3. Improved performance because of enhancement in data record transfer through batching.
4. Ability to provide composition of several different sensors as one helps app leverage better dataset. Composed sensor can serve entirely different objective than individual ones.
5. Demonstrated benefits achieved in all the stated key principles well in the evaluation section.

Weaknesses of the Paper:
1. There's no support for sensors connected via USB or Bluetooth, because for that there needs to be a custom SDK which may not support legacy apps and SOUL's one of the key principle is to provide full support to legacy apps.
2. There's no support for apps to specify QoS requirements to SOUL. This can eventually turn out to be a great user-experience feature.
3. Authors extensively(via results) show that SOUL gives better scalability for sensor use but they haven't shown any performance evaluation on how a mobile/moving app will have seemless execution of sensor access.

Discussion Points:
1. Guest token is renew every 2 hours. Authors state that estimating social ties is time consuming because of tracing all the social ties on the owners facebook account. Is there a smarter way to reduce social ties to look at based on past data?
2. Privacy aspect for sensor datastore in SOUL core is not discussed in this paper.
3. There's a room for discussion on discovery mechanism followed by SOUL. Currently there is a directory service hosted on remote cloud. What are few other mechanisms(technologies) that we can look into and their pros and cons?
4. There's not much discussion about why authors chose externalization as a default option for running app's SOUL aggregate. Sometimes it's better to run it locally.