Download presentation
Presentation is loading. Please wait.
Published bySophia Nichols Modified over 9 years ago
1
Is your Car Talking with my Smart Phone? or Distributed Sensing and Computing in Mobile Networks Cristian Borcea Dept. of Computer Science, NJIT
2
2 Wireless Systems >2B cell phones vs. 500M Internet-connected PC’s in 2005 >2B cell phones vs. 500M Internet-connected PC’s in 2005 >400M cell phones with Internet capability, rising rapidly >400M cell phones with Internet capability, rising rapidly New cars come equipped with GPS, navigation systems, and lots of sensors New cars come equipped with GPS, navigation systems, and lots of sensors Sensor deployment just starting, but some estimates ~5-10B units by 2015 Sensor deployment just starting, but some estimates ~5-10B units by 2015
3
Ubiquitous Computing Vision Computing, communication, and sensing anytime, anywhere Computing, communication, and sensing anytime, anywhere Wireless systems cooperate to achieve global tasks Wireless systems cooperate to achieve global tasks 3 How close are we from this vision? How close are we from this vision?
4
4 So Far … Not Very Close Nomadic computing Nomadic computing –Devices: laptops –Internet: intermittent connectivity –Work: typical desktop applications Mobile communication Mobile communication –Devices: PDAs, mobile phones, Blackberries –Internet: continuous connectivity –Work: read email, potentially web Experimental sensor networks 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 Hard to program distributed applications over collections of wireless systems –Systems Distributed across physical space Distributed across physical space Mobile Mobile Heterogeneous: both hardware and software Heterogeneous: both hardware and software Resource-constrained: battery, bandwidth, memory Resource-constrained: battery, bandwidth, memory –Networks Large scale Large scale Volatile: ad hoc topologies, dynamic resources Volatile: ad hoc topologies, dynamic resources Less secure than wired networks Less secure than wired networks 5
6
6 My Research What programming models, system architectures, and protocols do we need when everything connects? What programming models, system architectures, and protocols do we need when everything connects?
7
7Outline Motivation Motivation MobiSoC: A middleware for mobile social computing MobiSoC: A middleware for mobile social computing Migratory Services: A context-aware service model for mobile ad hoc networks Migratory Services: A context-aware service model for mobile ad hoc networks RBVT: Road-based routing using real-time traffic information in vehicular networks RBVT: Road-based routing using real-time traffic information in vehicular networks Conclusions and future research directions Conclusions and future research directions
8
8 Social Computing in the Internet Social networking applications that improve social connectivity on-line Social networking applications that improve social connectivity on-line –Stay in touch with friends –Make new friends –Find out information about events and places LinkedIn MyspaceFacebook
9
200-400 MHz processors 200-400 MHz processors 64-128 MB RAM 64-128 MB RAM GSM, WiFi, Bluetooth GSM, WiFi, Bluetooth Camera, keyboard Camera, keyboard Symbian, Windows Mobile, Linux Symbian, Windows Mobile, Linux Java, C++, C# Java, C++, C# 9 Mobile Social Computing More than just social computing anytime, anywhere More than just social computing anytime, anywhere New applications will benefit from real-time location and place information New applications will benefit from real-time location and place information Smart phones are the ideal devices Smart phones are the ideal devices –Always with us –Internet-enabled –Locatable (GPS or other systems)
10
10 Mobile Social Computing Applications (MSCA) People-centric 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 Place-centric –How crowded is the cafeteria now? –Which are the places where CS students hang out? How to program MSCA? How to program MSCA? Challenges: capturing the dynamic relations between people and places, location systems, privacy, power Challenges: capturing the dynamic relations between people and places, location systems, privacy, power
11
11 MobiSoC Middleware Common platform for capturing, managing, and sharing the social state of a physical community 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 Discovers emergent geo-social patterns and uses them to augment the social state
12
12 MobiSoC Architecture
13
Learning Emergent Geo-Social Patterns Example: GPI GPI – algorithm that identifies previously unknown social groups and their associated places 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 Clusters user mobility traces across time and space Its results can 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 13
14
14 Location System Hardware-based location systems not feasible 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! The user has no control over her location data! Software-based location systems that run on mobile devices preferable 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
15 Mobile Distributed System Architecture MSCA split between thin clients running on mobiles and services running on servers 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 MSCA clients communicate synchronously with the services and receive asynchronous events from MobiSoC Advantages Advantages Faster execution Faster execution Energy efficiency Energy efficiency Improved trust Improved trust
16
16 Clarissa: Location-enhanced mobile social matching Match Alert MatchType=Hangout Time: 1-3PM Co-Location: required MatchType=Hangout Time: 2-4PM Co-Location: required Match Alert
17
17 Tranzact: Place-based ad hoc social collaboration What’s on the menu? Cafeteria Chicken teriyaki Hungry
18
18 MobiSoC Implementation Runs on trusted servers Runs on trusted servers Service oriented architecture over Apache Tomcat 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 KSOAP is J2ME compatible, hence can be used to communicate with clients Client applications developed using J2ME on WiFi- enabled Windows-based smart phones 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 Location engine: modified version of Intel’s Placelab –At least 3 WiFi access points visible in most NJIT places –Accuracy 10-15 meters
19
19Outline Motivation Motivation MobiSoC: A middleware for mobile social computing MobiSoC: A middleware for mobile social computing Migratory Services: A context-aware service model for mobile ad hoc networks Migratory Services: A context-aware service model for mobile ad hoc networks RBVT: Road-based routing using real-time traffic information in vehicular networks RBVT: Road-based routing using real-time traffic information in vehicular networks Conclusions and future research directions Conclusions and future research directions
20
20 Ad Hoc Networks as Distributed Service Providers New class of services: acquire, process, disseminate real- time information from the proximity of geographical regions, entities, or activities of interest 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 EntitytrackingParking spot finder Traffic jam predictor CServiceClient
21
21 Requirements for New Service Model in Ad Hoc Networks Context adaptability: service always executes on nodes that satisfy context requirements 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 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 On-demand code distribution: service code can be dynamically transferred to nodes
22
22 Virtual service end-point Migratory Service Model Client n1n1n1n1 C n2 n2n2 n2 n3 n3 n3 n3 Context Change! (e.g., n 2 moves out of the region of interest) MS cannot accomplish its task on n 2 any longer ServiceMigration MS State Migratory Service Service MS State Migratory Service Service
23
23 Migratory Service Model (Cont’d) Client n1n1n1n1 C n2 n2 n2 n2 MS State Migratory Service Service Meta-service n4n4n4n4 MCreate Migratory Service MS State Migratory Service Service One-to-one mapping between clients and migratory services One-to-one mapping between clients and migratory services ServiceMigration
24
24 Migratory Services Framework Monitors context identifiers specified by programs Monitors context identifiers specified by programs Accesses context data by polling or blocking on corresponding SM tags Accesses context data by polling or blocking on corresponding SM tags Evaluates context rules specified by programs Evaluates context rules specified by programs IN context rules control incoming data 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 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 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 Discover meta-services Discover meta-services Route messages between communicating end-points Route messages between communicating end-points Carry out service migration Carry out service migration Provides execution migration, routing, property-based naming Provides execution migration, routing, property-based naming Tag space used for common access to memory and I/O Tag space used for common access to memory and I/O
25
25 TJam: Migratory Service Example TJam: Migratory Service Example Predicts traffic jams in real-time 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: 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 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) Development using HP iPAQs (running Linux), Nokia phones (running Symbian) SM platforms SM platforms –Original SM on modified KVM (HP iPAQs) –Portable SM on Java VM, J2ME CDC (Nokia 9500)
27
27Outline Motivation Motivation MobiSoC: A middleware for mobile social computing MobiSoC: A middleware for mobile social computing Migratory Services: A context-aware service model for mobile ad hoc networks Migratory Services: A context-aware service model for mobile ad hoc networks RBVT: Road-based routing using real-time traffic information in vehicular networks RBVT: Road-based routing using real-time traffic information in vehicular networks Conclusions and future research directions Conclusions and future research directions
28
28 Vehicular Ad Hoc Networks (VANET) Safer driving Safer driving –Quick dissemination of traffic alerts More fluid traffic More fluid traffic –Real-time dissemination of traffic conditions, traffic queries, dynamic route planning In-vehicle computing & entertainment In-vehicle computing & entertainment –P2P file sharing, gaming, location-aware advertisements Vehicle-to-vehicle wireless communication
29
29EZCab Need a cab Use mobile ad hoc networks of cabs to book a free cab Use mobile ad hoc networks of cabs to book a free cab Used HP iPaqs, GPS, WiFi Used HP iPaqs, GPS, WiFi
30
30 TrafficView Provides dynamic, real-time view of the traffic ahead of you Provides dynamic, real-time view of the traffic ahead of you –Collaboration with Rutgers Initial prototype Initial prototype –Laptop/PDA running Linux –WiFi & Omni-directional antennas –GPS & Tiger/Line-based digital maps –Road identification software Second generation prototype adds Second generation prototype adds –Touch screen display –3G cards –Possibility to connect to the OBD system
31
31 Routing still a Big Problem for VANET Topological routing (e.g., AODV, DSR) suffers from frequent broken paths Topological routing (e.g., AODV, DSR) suffers from frequent broken paths S S N1N1 D N1N1 D a) At time t b) At time t+Δt N2N2 S D Dead end road N1N1 N2N2 Geographical routing (e.g., GPSR) frequently routes packets to dead-ends Geographical routing (e.g., GPSR) frequently routes packets to dead-ends
32
32 RBTV Routing Makes decisions based on Makes decisions based on –Road topology –Real-time data about vehicular connectivity on the roads More stable paths More stable paths –Consist of wirelessly-connected road intersections –Geographical forwarding used within road segments
33
Reactive & Proactive RBTV RBTV-R (reactive) 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) 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 33
34
Improved Geographical Forwarding 34 Remove overhead-prone periodic “hello” messages Remove overhead-prone periodic “hello” messages Used to learn the neighbors Used to learn the neighbors Replace them with distributed receiver-based next hop election Replace them with distributed receiver-based next hop election Self-election based on distance to destination, received power, and distance to sender Self-election based on distance to destination, received power, and distance to sender Messages piggybacked on 802.11 RTS/CTS Messages piggybacked on 802.11 RTS/CTS
35
35Evaluation NS-2 simulator with 250 cars moving at 20-60mph NS-2 simulator with 250 cars moving at 20-60mph –15 concurrent CBR flows Implemented a realistic vehicular traffic generator Implemented a realistic vehicular traffic generator Average delivery rate: RBTV-R is 71% better than AODV and 41% better than GSR 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 Average end-to-end delay: RBTV-P is one order of magnitude better than AODV and GSR
36
36 Conclusions and Lessons Learned Smart phones and vehicular systems create large scale real-life mobile networks 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 Significant amount of system/networking research necessary to build applications over these networks Testing in real-life conditions is a must 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 Power is the most important resource of a mobile system Communication failures are the norm rather than the exception Communication failures are the norm rather than the exception Applications must be able to adapt to context and be robust to sensing errors Applications must be able to adapt to context and be robust to sensing errors
37
37 Future Research Directions Dependable mobile computing Dependable mobile computing –Security/privacy/trust –Fault-tolerance Energy efficient system architectures, protocols, and algorithms for mobile computing Energy efficient system architectures, protocols, and algorithms for mobile computing Network architectures and protocols to integrate ad hoc and sensor networks with the Internet Network architectures and protocols to integrate ad hoc and sensor networks with the Internet
38
38 Thank you! Work sponsored by the NSF grants CNS-0454081, CNS-0520033, IIS-0534520, IIS- Work sponsored by the NSF grants CNS-0454081, CNS-0520033, IIS-0534520, IIS- 0714158http://www.cs.njit.edu/~borcea/
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.