1. Turning Ad Hoc Networks into Distributed Service Providers Cristian Borcea Department of Computer Science New Jersey Institute of Technology

2. 2 Ubiquitous Computing Environments Wireless systems embedded everywhere Wireless systems embedded everywhere Large scale ad hoc networks will soon become reality Large scale ad hoc networks will soon become reality

3. 3 Ad Hoc Networks as Data Carriers Traditionally, ad hoc networks used to Traditionally, ad hoc networks used to –Connect a mobile system (e.g., laptop, PDA) to the Internet –Exchange data between mobile systems Internet Internet Read email, browse the web File transfers

4. 4 Ad Hoc Networks as Distributed Service Providers New class of services deployed in ad hoc networks New class of services deployed in ad hoc networks –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 Entitytracking Parking spot finder Traffic jam predictor CServiceClient

5. 5 Problems with TCP/IP Client-Server Model in Ad Hoc Networks No support for context-awareness No support for context-awareness –When service stops satisfying context requirements, only solution is to discover new service Not always possible to find new service Not always possible to find new service Overhead due to service discovery Overhead due to service discovery The state of the old service is lost The state of the old service is lost No support for dynamic binding of names to IP addresses No support for dynamic binding of names to IP addresses –Difficult to ensure that name resolution ends up with new service when necessary No support for dynamic service deployment No support for dynamic service deployment –Cannot guarantee that a node satisfying all context requirements has the necessary service

6. 6 Traffic Jam Predictor Service Problem: service responses are semantically incorrect if the car hosting the service moves out of the region Problem: service responses are semantically incorrect if the car hosting the service moves out of the region Solution: discover a new service running on a node satisfying the context requirements Solution: discover a new service running on a node satisfying the context requirements CServiceClient Region of interest

7. 7 Entity Tracking Service Problem: service cannot satisfy the request when entity is out of the “range” of camera Problem: service cannot satisfy the request when entity is out of the “range” of camera Solution: discover new service & transfer the execution state of the old service Solution: discover new service & transfer the execution state of the old service CServiceClient

8. 8 Parking Spot Finder Service Problem: service needs to run on a mobile node in the proximity of parking meters in the region of interest Problem: service needs to run on a mobile node in the proximity of parking meters in the region of interest Solution: discover nodes in this region and potentially transfer service code on these nodes Solution: discover nodes in this region and potentially transfer service code on these nodes CServiceClient

9. 9 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

10. 10Outline Motivation Motivation Context-Aware Migratory Services Context-Aware Migratory Services Migratory Services Framework Migratory Services Framework Implementation & Evaluation Implementation & Evaluation Conclusions Conclusions Other Current/Future Work Other Current/Future Work

11. 11 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

12. 12 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

13. 13 Key Ideas of Migratory Services Model Services migrate to nodes where they can accomplish their tasks Services migrate to nodes where they can accomplish their tasks –Present single virtual end-point to clients –One-to-one mapping between clients and services –Carry execution state across migrations –Transfer their code if necessary Service migration Service migration –Triggered by context changes –Regulated through context rules –Transparent to clients –Typically multi-hop

14. 14Outline Motivation Motivation Context-Aware Migratory Services Context-Aware Migratory Services Migratory Services Framework Migratory Services Framework Implementation & Evaluation Implementation & Evaluation Conclusions Conclusions Other Current/Future Work Other Current/Future Work

15. 15 Migratory Services Framework at Nodes

16. 16 Framework’s Tasks Provide send/receive API for service programmers Provide send/receive API for service programmers Translate Migratory Services into lower-level Smart Messages Translate Migratory Services into lower-level Smart Messages Enforce specification of context parameters and context rules by all programs Enforce specification of context parameters and context rules by all programs Ensure service fault-tolerance Ensure service fault-tolerance Use naming, routing, and security offered by Smart Messages platform Use naming, routing, and security offered by Smart Messages platform

17. 17 Migratory Services Framework

18. 18 Smart Messages (SM) Distributed programs executing sequentially on nodes of interest named by properties Distributed programs executing sequentially on nodes of interest named by properties Migrate between nodes of interest Migrate between nodes of interest Self-route at every node in the path during migrations Self-route at every node in the path during migrations Composed of: Composed of: –Code bricks (e.g., Java class files) –Data bricks (e.g., Java objects) –Execution control state (e.g., instruction pointer, operand stack pointer)

19. 19 SM Node Architecture Network SMPlatform AdmissionManagerAdmissionManager Network SMSM Operating System & I/O CodeCacheCodeCache Virtual Machine Interpreter Interpreter TagSpaceTagSpace SM Ready Queue AuthorizationAuthorization

20. 20 Tag Space Collection of application tags and I/O tags Collection of application tags and I/O tags Essentially, tags are (name, value) pairs Essentially, tags are (name, value) pairs –Application tags: persistent memory across SM executions –I/O tags: access to operating system and I/O subsystem Tags used for Tags used for –Content-based naming migrate(tag) –Inter-SM communication write(tag, data), read(tag) –Synchronization block(tag, timeout) –I/O access read(temperature)

21. 21 SM Migration migrate(Taxi) sys_migrate(2) sys_migrate(3) sys_migrate(4) TaxiTaxi 1 234 migrate() migrate() –multi-hop content-based migration –migrates application to node of interest named by tags –implements routing algorithm using tags and sys_migrate sys_migrate() sys_migrate() –one hop migration –captures SM state, transfers SM to next hop, resumes SM execution

22. 22 Network Routing Example 12i RouteToTaxi = 2 Taxi RouteToTaxi = ? RouteToTaxi = j migrate(Taxi){ while(readTag(Taxi) == null) if (readTag(RouteToTaxi)) sys_migrate(readTag(RouteToTaxi)); else create_SM(DiscoverySM, Taxi); createTag(RouteToTaxi, lifetime, null); block_SM(RouteToTaxi, timeout); }

23. 23 Migratory Services Framework

24. 24 Context Manager Context Manager Monitors context identifiers specified by programs Monitors context identifiers specified by programs Translates context identifiers into SM tags Translates context identifiers into SM tags Accesses context data by polling or blocking on corresponding SM tags Accesses context data by polling or blocking on corresponding SM tags –Location, time, speed using GPS –System status information (e.g., battery level, free memory) –One-hop neighbors list (includes location & speed)

25. 25 Validator 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 If response refused, update of client context sent to migratory service If response refused, update of client context sent to migratory service OUT context rules control outgoing data OUT context rules control outgoing data – –Used for migratory services to decide whether to send a response or not If not, service migration is triggered

26. 26 Context Rules Specification Condition/action statements Condition/action statements Conditions are full binary trees of Boolean expressions Conditions are full binary trees of Boolean expressions –Example: {OR,, } } Actions Actions –Migrate service –Send client update –Accept/refuse request –Accept/refuse response

27. 27 Communication Manager Communication Manager Discovers meta-services Discovers meta-services Routes messages between end-points Routes messages between end-points Carries out service migration Carries out service migration Uses naming conventions defined by SM platform Uses naming conventions defined by SM platform Uses two basic SM routing algorithms: Uses two basic SM routing algorithms: –Geographical routing (similar to GPSR) –Region-bound content-based routing (similar to AODV)

28. 28 Reliability Manager Reliability Manager Fault-tolerance to one failure Fault-tolerance to one failure Inactive version of the service created after first migration Inactive version of the service created after first migration –Its state is periodically updated In case of failure of the active version, the inactive version takes over In case of failure of the active version, the inactive version takes overResponse Response Update Update Update Update Update Response Response Response ResponseActiveService InactiveService Client Timeout Request Request ResponseDeleteResponse Response

29. 29 Migratory Services Framework

30. 30 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

31. 31 TJam Pseudo-Code monitoredCtx = {location, speed} inCtxRule = {, rejectResponse && sendUpdate} rejectResponse && sendUpdate} serviceParameters = {region, frequency} request = {clientName, serviceParameters} send(TJam, request); while (NOT_DONE) response = receive(msName) monitoredCtx = {location, speed, region} outCtxRule = {, migrateService} migrateService} while (NOT_DONE) response = computeResponse(); send(clientName, response) Client MigratoryService

32. 32Outline Motivation Motivation Context-Aware Migratory Services Context-Aware Migratory Services Migratory Services Framework Migratory Services Framework Implementation & Evaluation Implementation & Evaluation Conclusions Conclusions Other Current/Future Work Other Current/Future Work

33. 33Implementation Framework is a Java package on top of SM platform Framework is a Java package on top of SM platform –Implemented TJam prototype over this framework –Works for one-request/multiple-replies service model SM platform SM platform –Modified version of Sun’s Java K Virtual Machine –Architectural components inside virtual machine, and API implemented as native methods –Tested on WiFi-equipped HP iPAQs running Linux

34. 34 Implementation – Current Status Framework on top of portable SM platform Framework on top of portable SM platform Portable SM platform Portable SM platform –Works over unmodified Java VM –Architectural components & API implemented on top of Java VM –Migration state captured using bytecode instrumentation –Tested on Smart Phones running Symbian OS & Java CVM Nokia Communicator 9500 with WiFi 9500 with WiFi Ericsson P900 with Bluetooth

35. 35Evaluation Experimental results for TJam over a small scale network Experimental results for TJam over a small scale network –Demonstrate feasibility Simulation results for TJam over large scale network Simulation results for TJam over large scale network –Comparison with a base-line centralized approach to demonstrate scalability and efficiency SM experimental results SM experimental results –Give idea about SM performance

36. 36 SM Micro-Benchmark Results Cost of data serialization Cost of single hop migration Used 2 WiFi-equipped HP iPAQs running Linux

37. 37 SM Simple Routing Algorithm Results Completion Time Routing algorithm Code not cached (ms) Code cached (ms) Geographic On-demand 415.6 126.6 506.6 314.7 user node node of interest intermediate node WiFi-based ad hoc network of 8 HP iPAQs running Linux

38. 38 TJam Constantly Executes in the User- Specified Region Ad hoc network of 11 HP iPAQs with WiFi cards & mobility traces Ad hoc network of 11 HP iPAQs with WiFi cards & mobility traces

39. 39 TJam Simulations Comparison of Comparison of –TJam-Smart: migratory service –TJam-Base: baseline centralized approach ns-2 simulator with the CMU-wireless extensions and Micro-VTG, our microscopic traffic generator tool ns-2 simulator with the CMU-wireless extensions and Micro-VTG, our microscopic traffic generator tool 802.11b, 11Mb, transmission range 250m 802.11b, 11Mb, transmission range 250m Highway of length 25km with 3 lanes Highway of length 25km with 3 lanes 800 vehicles, 50 service nodes 800 vehicles, 50 service nodes

40. 40 Response Time vs. Number of Clients Vehicles average speed: 30m/s with an average gap of 150m Vehicles average speed: 30m/s with an average gap of 150m

41. 41 Response Time vs. Average Speed Number of clients: 150 Number of clients: 150

42. 42Conclusions Migratory Services enable context-aware distributed services in ad hoc networks Migratory Services enable context-aware distributed services in ad hoc networks Easy to develop and deploy new services in the network Easy to develop and deploy new services in the network Quick adaptation to highly volatile networks Quick adaptation to highly volatile networks Experimental and simulation results demonstrate the feasibility, scalability, and efficiency Experimental and simulation results demonstrate the feasibility, scalability, and efficiency

43. 43Outline Motivation Motivation Context-Aware Migratory Services Context-Aware Migratory Services Migratory Services Framework Migratory Services Framework Implementation & Evaluation Implementation & Evaluation Conclusions Conclusions Other Current/Future Work Other Current/Future Work

44. 44 TrafficView: Real-time view of the traffic ahead of your car far beyond what you can see Design vehicular network architecture and build prototype for distributed vehicular computing Design vehicular network architecture and build prototype for distributed vehicular computing Sponsored by NSF, collaboration with Rutgers University Sponsored by NSF, collaboration with Rutgers University INVENT: INter-VEhicular Network Technologies

45. 45 SmartCampus: Ubiquitous Social Computing Middleware & Applications Build a location-aware mobile community test-bed of 100s of nodes carried by NJIT students everywhere Build a location-aware mobile community test-bed of 100s of nodes carried by NJIT students everywhere Sponsored by NSF, joint work with IS & ECE departments at NJIT Sponsored by NSF, joint work with IS & ECE departments at NJIT CampusMesh application leverages users’ geo-temporal data for: CampusMesh application leverages users’ geo-temporal data for: –Social matching recommendations –Location aware alerts and reminders –Real time group coordination KJam Smart Phone System Architecture

46. 46 What’s Next for Ubiquitous Computing? A significant amount of system research is required to make it reality A significant amount of system research is required to make it reality –Crossroad between networking, operating systems, embedded systems, computer vision, etc. –Build prototypes and test them in real-life settings –Define metrics and benchmarks Inter-disciplinary research is the key to success Inter-disciplinary research is the key to success –Applications will span non-traditional computing domains (e.g., transportation, healthcare, homeland security) –Collaborations with civil engineering, cognitive sciences, biology, nursing, etc.

47. 47 Acknowledgments The Migratory Services project is joint work with: The Migratory Services project is joint work with: –Oriana Riva (University of Helsinki) –Tamer Nadeem (Siemens Research) –Liviu Iftode (Rutgers University) This work is sponsored in part by the NSF grants CNS-0520033, CNS-0454081, and IIS-0534520 This work is sponsored in part by the NSF grants CNS-0520033, CNS-0454081, and IIS-0534520

48. 48 Thank you! http://www.cs.njit.edu/~borcea/