Is your Car Talking with my Smart Phone? or Distributed Sensing and Computing in Mobile Networks

1. Is your Car Talking with my Smart Phone?orDistributed Sensing and Computing in Mobile Networks CristianBorcea Dept. of Computer Science, NJIT

2. Wireless Systems • >2B cell phones vs. 500M Internet-connected PC’s in 2005 • >400M cell phones with Internet capability, rising rapidly • New cars come equipped with GPS, navigation systems, and lots of sensors • Sensor deployment just starting, but some estimates ~5-10B units by 2015

3. Ubiquitous Computing Vision • Computing, communication, and sensing anytime, anywhere • Wireless systems cooperate to achieve global tasks • How close are we from this vision?

4. So Far … Not Very Close • Nomadic computing • Devices: laptops • Internet: intermittent connectivity • Work: typical desktop applications • Mobile communication • Devices: PDAs, mobile phones, Blackberries • Internet: continuous connectivity • Work: read email, potentially web • Experimental sensor networks • Devices: Berkeley/Crossbow motes • Internet: Possible through base station • Work: Monitor environment, wildlife

5. Why? • Hard to program distributed applications over collections of wireless systems • Systems • Distributed across physical space • Mobile • Heterogeneous: both hardware and software • Resource-constrained: battery, bandwidth, memory • Networks • Large scale • Volatile: ad hoc topologies, dynamic resources • Less secure than wired networks

6. My Research • What programming models, system architectures, and protocols do we need when everything connects?

7. Outline • Motivation • MobiSoC: A middleware for mobile social computing • Migratory Services: A context-aware service model for mobile ad hoc networks • RBVT: Road-based routing using real-time traffic information in vehicular networks • Conclusions and future research directions

8. Social Computing in the Internet • Social networking applications that improve social connectivity on-line • Stay in touch with friends • Make new friends • Find out information about events and places Myspace Facebook LinkedIn

9. Mobile Social Computing • More than just social computing anytime, anywhere • New applications will benefit from real-time location and place information • Smart phones are the ideal devices • Always with us • Internet-enabled • Locatable (GPS or other systems) • 200-400 MHz processors • 64-128 MB RAM • GSM, WiFi, Bluetooth • Camera, keyboard • Symbian, Windows Mobile, Linux • Java, C++, C#

10. Mobile Social Computing Applications (MSCA) • People-centric • Are any of my friends in the cafeteria now? • Is there anybody nearby with a common background who would like to play tennis? • Place-centric • How crowded is the cafeteria now? • Which are the places where CS students hang out? • How to program MSCA? • Challenges: capturing the dynamic relations between people and places, location systems, privacy, power

11. MobiSoC Middleware • Common platform for capturing, managing, and sharing the social state of a physical community • Discovers emergent geo-social patterns and uses them to augment the social state

12. MobiSoC Architecture

13. Learning Emergent Geo-Social Patterns Example: GPI • GPI – algorithm that identifies previously unknown social groups and their associated places • Fits into the people-place affinity learning module • Clusters user mobility traces across time and space • Its results can • Enhance user profiles and social networks using newly discovered group memberships • Enhance place semantics using group meeting times and profiles of group members

14. Location System • Hardware-based location systems not feasible • GPS doesn’t work indoors • Deploying RF-receivers to measure the signals of mobiles is expensive and not practical for large places • The user has no control over her location data! • Software-based location systems that run on mobile devices preferable • Use signal strength and known location of WiFi access points or cellular towers • Allow users to decide when to share their location

15. Mobile Distributed System Architecture • MSCA split between thin clients running on mobiles and services running on servers • MSCA clients communicate synchronously with the services and receive asynchronous events from MobiSoC • Advantages • Faster execution • Energy efficiency • Improved trust

16. Clarissa: Location-enhanced mobile social matching MatchType=Hangout Time: 1-3PM Co-Location: required Match Alert Match Alert MatchType=Hangout Time: 2-4PM Co-Location: required

17. Tranzact: Place-based ad hoc social collaboration Hungry What’s on the menu? Chicken teriyaki Cafeteria

18. MobiSoC Implementation • Runs on trusted servers • Service oriented architecture over Apache Tomcat • Core services written in JAVA • API is exposed to MSCA services using KSOAP • KSOAP is J2ME compatible, hence can be used to communicate with clients • Client applications developed using J2ME on WiFi-enabled Windows-based smart phones • Clarissa: http://apps.facebook.com/matching/ • Location engine: modified version of Intel’s Placelab • At least 3 WiFi access points visible in most NJIT places • Accuracy 10-15 meters

19. Outline • Motivation • MobiSoC: A middleware for mobile social computing • Migratory Services: A context-aware service model for mobile ad hoc networks • RBVT: Road-based routing using real-time traffic information in vehicular networks • Conclusions and future research directions

20. Ad Hoc Networks as Distributed Service Providers Service Client C • New class of services: acquire, process, disseminate real-time information from the proximity of geographical regions, entities, or activities of interest • Computation is context-aware • Many times, interact for longer period of time with clients Entity tracking Parking spot finder Traffic jam predictor

21. Requirements for New Service Model in Ad Hoc Networks • Context adaptability: service always executes on nodes that satisfy context requirements • Dynamic context monitoring and evaluation • Discovery of new nodes satisfying context requirements • Service continuity: client sees continuous interaction with service • Transparent service name re-binding • Service execution state transfer • On-demand code distribution: service code can be dynamically transferred to nodes

22. Migratory Service Model Virtual service end-point Migratory Service MS Service Migration State C Client n3 MS Migratory Service State n2 n1 Context Change! (e.g., n2 moves out of the region of interest) MS cannot accomplish its task on n2 any longer

23. Migratory Service Model (Cont’d) Create Migratory Service Service Migration MS MS Migratory Service Migratory Service State State n2 n1 n4 C Client M Meta-service • One-to-one mapping between clients and migratory services

24. Migratory Services Framework • Monitors context identifiers specified by programs • Accesses context data by polling or blocking on corresponding SM tags • Discover meta-services • Route messages between communicating end-points • Carry out service migration • Evaluates context rules specified by programs • IN context rules control incoming data • Used for meta-services to accept/refuse requests • Used for clients to accept/refuse responses • OUT context rules control outgoing data • Used for migratory services to decide whether to send a response or trigger a migration • Based on the classical primary-backup approach with two modifications • Secondary node dynamically selected, in a context-aware manner • Backup frequency constantly adapted based on the operating network conditions • Provides execution migration, routing, property-based naming • Tag space used for common access to memory and I/O

25. TJam: Migratory Service Example • Predicts traffic jams in real-time • The request specifies region of interest • Service migrates to ensure it stays in this region • Uses history (service execution state) to improve prediction • TJam utilizes information that every car has: • Number of one-hop neighboring cars • Speed of one-hop neighboring cars Inform me when there is a high probability of traffic jam 10 miles ahead

26. Implementation • Implemented in Java • Java 2 Micro-Edition (J2ME) with CLDC 1.1 and MIDP 2.0 • J2ME with CDC • Development using HP iPAQs (running Linux), Nokia phones (running Symbian) • SM platforms • Original SM on modified KVM (HP iPAQs) • Portable SM on Java VM, J2ME CDC (Nokia 9500)

27. Outline • Motivation • MobiSoC: A middleware for mobile social computing • Migratory Services: A context-aware service model for mobile ad hoc networks • RBVT: Road-based routing using real-time traffic information in vehicular networks • Conclusions and future research directions

28. Safer driving Quick dissemination of traffic alerts More fluid traffic Real-time dissemination of traffic conditions, traffic queries, dynamic route planning In-vehicle computing & entertainment P2P file sharing, gaming, location-aware advertisements Vehicular Ad Hoc Networks (VANET) Vehicle-to-vehicle wireless communication

29. EZCab Need a cab • Use mobile ad hoc networks of cabs to book a free cab • Used HP iPaqs, GPS, WiFi

30. TrafficView • Provides dynamic, real-time view of the traffic ahead of you • Collaboration with Rutgers • Initial prototype • Laptop/PDA running Linux • WiFi & Omni-directional antennas • GPS & Tiger/Line-based digital maps • Road identification software • Second generation prototype adds • Touch screen display • 3G cards • Possibility to connect to the OBD system

31. Routing still a Big Problem for VANET D N1 S a) At time t S N1 N1 S D N2 N2 D Dead end road b) At time t+Δt • Topological routing (e.g., AODV, DSR) suffers from frequent broken paths • Geographical routing (e.g., GPSR) frequently routes packets to dead-ends

32. RBTV Routing S Source I1 I3 I2 A B C I5 I4 Path in header: I8-I5-I4-I7-I6-I1 I6 I8 I7 E D car Destination Ij Intersection j • Makes decisions based on • Road topology • Real-time data about vehicular connectivity on the roads • More stable paths • Consist of wirelessly-connected road intersections • Geographical forwarding used within road segments

33. Reactive & Proactive RBTV • RBTV-R (reactive) • Creates paths on-demand • Route discovery floods the network to find destination and records path • Route reply returns path to source • RBTV-P (proactive) • Connectivity packet unicasted periodically to discover the graph wirelessly-connected road segments • When complete, connectivity packet flooded in the network to update the nodes with the new graph • Nodes compute shortest paths using this graph

34. Improved Geographical Forwarding • Remove overhead-prone periodic “hello” messages • Used to learn the neighbors • Replace them with distributed receiver-based next hop election • Self-election based on distance to destination, received power, and distance to sender • Messages piggybacked on 802.11 RTS/CTS

35. Evaluation • NS-2 simulator with 250 cars moving at 20-60mph • 15 concurrent CBR flows • Implemented a realistic vehicular traffic generator • Average delivery rate: RBTV-R is 71% better than AODV and 41% better than GSR • Average end-to-end delay: RBTV-P is one order of magnitude better than AODV and GSR

36. Conclusions and Lessons Learned • Smart phones and vehicular systems create large scale real-life mobile networks • Significant amount of system/networking research necessary to build applications over these networks • Testing in real-life conditions is a must • Ideally, at a decent scale as well • Power is the most important resource of a mobile system • Communication failures are the norm rather than the exception • Applications must be able to adapt to context and be robust to sensing errors

37. Future Research Directions • Dependable mobile computing • Security/privacy/trust • Fault-tolerance • Energy efficient system architectures, protocols, and algorithms for mobile computing • Network architectures and protocols to integrate ad hoc and sensor networks with the Internet

38. Thank you! Work sponsored by the NSF grants CNS-0454081, CNS-0520033, IIS-0534520, IIS- 0714158 http://www.cs.njit.edu/~borcea/