1 / 27

SmartParcel : A Collaborative Data Sharing Framework for Mobile Operating Systems

SmartParcel : A Collaborative Data Sharing Framework for Mobile Operating Systems . Bhanu Kaushik ∗ Honggang Zhang † Xinwen Fu ∗ Benyuan Liu ∗ Jie Wang ∗ ∗ Department of Computer Science, University of Massachusetts, Lowell, MA.

malise
Download Presentation

SmartParcel : A Collaborative Data Sharing Framework for Mobile Operating Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 ?

More Related