SmartParcel : A Collaborative Data Sharing Framework for Mobile Operating Systems

1. SmartParcel: A Collaborative Data Sharing Framework for Mobile Operating Systems Bhanu Kaushik∗ Honggang Zhang† XinwenFu∗ BenyuanLiu∗ JieWang∗ ∗Department of Computer Science, University of Massachusetts, Lowell, MA. †Department of Computer and Information Science, Fordham University, Bronx NY

2. Outline • Introduction • Motivation and Related Work • Problem Definition • Architecture • Simulation Setup • Results • Conclusions and Future Work

3. Outline • Introduction • Motivation and Related Work • Problem Definition • Architecture • Simulation Setup • Results • Conclusions and Future Work

4. Introduction • Huge number of Mobile Devices such as Smartphones, Tablets, PDAs, portable media players etc. • “About 6.2 billion users around the globe” – Ericsson, 2012. • These devices support large number of Internet based applications. • These Applications work on simple one-to-one client-server data distribution model. • Results in: • Increasing concerns about volume of global online digital content generated by these devices. • Multi-fold increase in Network traffic originating from these devices • “100 PetaByte/Month in 2007 to 700 PetaByte/Month in 2012”-Ericsson, 2012. • Huge incumbent content availability and maintainability cost.

5. Outline • Introduction • Motivation and Related Work • Problem Definition • Architecture • Simulation Setup • Results • Conclusions and Future Work

6. Motivation and Related Work Motivation • Major challenges faced by mobile Internet users • Carrier enforced limited data plans, • Unavailability of hardware (3G or LTE), • Unavailability of access points, • Service outagesand • Network and server overloads. • Results in: • Unavailability of application data to the users • High service maintainability cost, to both the service providers and hosting servers.

7. Motivation and Related Work Related Work : Data Offloading • Proposed Solutions for data offloading • Large Scale • Alvarion, “Mobile data offloading for 3G and LTE networks.” • Cisco, “Architecture for mobile data offload over Wi-Fi access networks.” • Small Scale • Han et. al. “Mobile data offloading through opportunistic communications and social participation” • Lee et. al., “Mobile data offloading: How much can wifi deliver?” • Unaddressed Issues: • Entail huge changes in both, state of the art software and hardware technologies • Do not take into account the heterogeneity of application data.

8. Motivation and Related Work Related Work: Opportunistic Data delivery and Familiar Strangers • Delay-Tolerant Networks (DTN) • Target the interoperability between and among challenged networks • Familiar Strangers • Coined by Stanley Milgram in 1972, “Individuals that regularly observe and exhibit some common patterns in their daily activities”. • SmartParcel uses the idea of opportunistic connectivity and in-network storage and retransmission from DTN architecture to ensure data delivery among the nodes in a “Familiar Strangers” network set up.

9. Outline • Introduction • Motivation and Related Work • Problem Definition • Architecture • Simulation Setup • Results • Conclusions and Future Work

10. Problem Definition SmartParcel • Our Goal is to develop framework of a Mobile data offloading and Service Assurance scheme by encouraging collaborative data sharing among spatio-temporally co-existing mobile devices. Fig. 1 : Proposed SmartParcel Approach

11. Outline • Introduction • Motivation and Related Work • Problem Definition • Architecture • Simulation Setup • Results • Conclusions and Future Work

12. Architecture Components • Service Discovery Manager • Data Transfer Manager • Service Cache Manager • Dynamic Cache • Static Cache • Network Interface Manager • Service APIs • Central Control Manager Fig. 2 : SmartParcel Service Architecture.

13. Architecture Component Details • Service Discovery Manager: • Identifies the available candidates for data transfer by broadcasting a “SYN” message periodically • “SYN” packet contains meta-data about applications registered to SmartParcel. • The meta-data is organized as a key value pair, i.e., (“ApplicationId, TimeStamp”). • At receiver, based on the meta-data information it sets up a one-to-one connection • Data Transfer Manager: • Manages the data transfer. • Can manage concurrent connections to multiple devices. • To reduce the network overhead, sends data for multiple applications as one chunk.

14. Architecture Component Details • Service Cache Manager: • Service cache to store the application specific (heterogeneous) data . • Dynamic Cache • In-memory cache for storing the applications meta-data information. • Implemented as Hash Map with (Application Id, Timestamp) as key-value pairs. • Static Cache • Static cache for storing the actual application specific data. • Maintained as SQLite database. • Schema “Application Id (as string), Data (as blob), Time Stamp” • Primary key : Application id and timestamp • Flexibility to developer to assign “Time to live” and “Reset-Time” for the application data, end of day by default.

15. Architecture Component Details • Central Control Manager: • Manage the control from all components of the SmartParcel service. • All components work under same instance for synchronous operation. • Network Interface Manager: • Internal service, responsible for managing network connections. • Assists Service Discovery for identifying available devices on different network interfaces (3G, LTE, WiFi, BlueTooth etc.). • Service APIs: • Subscribe or unsubscribe to service • Update app data • Settings • Sharing statistics etc.

16. Architecture Android and SmartParcel • Android SDK • New set of permissions. • SMP_ALL, SMP_BLUETOOTH, SMP_WIFI, SMP_NFC and SMP_BT_WIFI. Table 1 : Resources used in different permissions Fig. 3 : Integration of SmartParcel in Android framework • Android OS • Integrated in the “System Server” module. • System Server is launched by Zygote. • Zygote forks the SmartParcel service as a system service. • Ensures system level privileges and independence from the application “context”.

17. Outline • Introduction • Motivation and Related Work • Problem Definition • Architecture • Simulation Setup • Results • Conclusions and Future Work

18. Simulation Setup Data Set • MIT Reality Mining Data Set • 100 unique devices, 500,000 hours, 9 months • We use the Bluetooth encounters data. Table 2 : Data Set Description Fig 4 : Hourly Variation of Device Encounters. Fig 5 : Distribution of Device Encounters. Fig 6 : Distribution of Active Devices Per Day.

19. Simulation Setup Setup Parameters • Data Refresh Rate (DRR) : The frequency with which the data is being refreshed. • Allowed Server Connections (ASC) : Number of devices allowed to get data from server on each day. • User Participation Probability (UPP) : The Probability of user acting selfish, i.e., limiting its participation by only receiving data and not sending data • We measure the Data Availability Ratio (DAR)

20. Outline • Introduction • Motivation and Related Work • Problem Definition • Architecture • Simulation Setup • Results • Conclusions and Future Work

21. Results Effect of user’s social activity level • User Participation Probability (UPP) = 100% • Data Refresh Rate (DRR) =1 Refresh interval Fig 6 : Effect of ASC on DAR over the Day, when ASC = 1 Fig 8 : Effect of ASC on DAR , when ASC =1 to 75 devices. Fig 7 : Effect of ASC on DAR over the Day, when ASC = 30

22. Results Effect of Data Refresh Rate (DRR) • User Participation Probability (UPP) = 100% • Data Refresh Rate (DRR) = 2 Refresh intervals, • 12:00am -11:59am and 12:00pm-11:59pm Fig 9 : Variation of Data Availability Ratio (DAR) with Data Refresh Rate (DRR) when DRR = 2 and Refresh Interval 12:00 am - 11:59 am. Fig 10 : Variation of Data Availability Ratio (DAR) with Data Refresh Rate (DRR) when DRR = 2 and Refresh Interval 12:00pm - 11:59pm.

23. Results Effect of Data Refresh Rate (DRR) • User Participation Probability (UPP) = 100% • Data Refresh Rate (DRR) = 3 Refresh intervals. Fig 12 : Refresh Interval 08:00am-03:59pm. Fig 11 : Refresh Interval 12:00am-07:59am. Fig 13 : Refresh Interval 04:00pm-11:59pm.

24. Results Effect of Selfishness • User Participation Probability (UPP) = 10%, 20%, 50% and 90%. • Data Refresh Rate (DRR) = 1 Refresh interval • Allowed Server Connections(ASC) = 1 to 90 devices. Fig 14 : Variation of Data Availability Ratio with User Participation Probability(UPP) and Allowed Server Connections(ASC). (*Median of 1000 Simulation runs)

25. Outline • Introduction • Motivation and Related Work • Problem Definition • Architecture • Simulation Setup • Results • Conclusions and Future Work

26. Conclusions and Future Work • “SmartParcel” - A novel approach for Data sharing among co-existing and co-located devices is presented. • “One for all”, multiple incentive system for application developers, Internet service providers and application data providers (eg. cloud services) with collateral benefits for the consumer itself. • We discussed the Design and implementation “SmartParcel” in Android. • Implementation in android framework dictates the feasibility of the architecture. • Flexibility of design ensures integration in almost every existing mobile operating system. • In the future, we intend to investigate the scalability and performance issues encountered on real devices.

27. Thank You ! Questions ?