Turning Ad Hoc Networks into Distributed Service Providers

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

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

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

4. Ad Hoc Networks as Distributed Service Providers Service Client C • 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 How to program such distributed services? Parking spot finder Entity tracking Traffic jam predictor

5. Problems with TCP/IP Client-Server Model in Ad Hoc Networks • 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 • Overhead due to service discovery • The state of the old service is lost • 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 • Cannot guarantee that a node satisfying all context requirements has the necessary service

6. Traffic Jam Predictor Service Service Client C Region of interest • 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

7. Entity Tracking Service Service Client C • 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

8. Parking Spot Finder Service Service Client C • 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

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

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

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

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

13. Key Ideas of Migratory Services Model • 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 • Triggered by context changes • Regulated through context rules • Transparent to clients • Typically multi-hop

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

15. Migratory Services Framework at Nodes

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

17. Migratory Services Framework

18. Smart Messages (SM) • Distributed programs executing sequentially on nodes of interest named by properties • Migrate between nodes of interest • Self-route at every node in the path during migrations • 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. SM Node Architecture Network Network SM Ready Queue Virtual Machine Interpreter SM SM Admission Manager Authorization Code Cache SM Platform Tag Space Operating System & I/O

20. Tag Space • Collection of application tags and I/O tags • 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 • Content-based naming migrate(tag) • Inter-SM communication write(tag, data), read(tag) • Synchronization block(tag, timeout) • I/O access read(temperature)

21. SM Migration migrate(Taxi) Taxi Taxi sys_migrate(3) sys_migrate(2) sys_migrate(4) 1 2 3 4 • 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() • one hop migration • captures SM state, transfers SM to next hop, resumes SM execution

22. Routing Example Network 1 2 i Taxi RouteToTaxi = 2 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. Migratory Services Framework

24. Context Manager • Monitors context identifiers specified by programs • Translates context identifiers into 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. Validator • 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 • If response refused, update of client context sent to migratory service • 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. Context Rules Specification • Condition/action statements • Conditions are full binary trees of Boolean expressions • Example: {OR, <batteryLevel, EQUAL, low>, <responseLocation, OUT_REGION, userRegion>} • Actions • Migrate service • Send client update • Accept/refuse request • Accept/refuse response

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

28. Reliability Manager Response Response Response Response Response Response Response Request Response Response Update Update Update Active Service Inactive Service • Fault-tolerance to one failure • 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 Client Timeout Delete

29. Migratory Services Framework

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

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

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

33. Implementation • 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 • 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. Implementation – Current Status • Framework on top of 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 Ericsson P900 with Bluetooth

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

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

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

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

39. TJam Simulations • 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 • 802.11b, 11Mb, transmission range 250m • Highway of length 25km with 3 lanes • 800 vehicles, 50 service nodes

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

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

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

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

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

45. SmartCampus: Ubiquitous Social Computing Middleware & Applications • 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 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. What’s Next for Ubiquitous Computing? • 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 • Applications will span non-traditional computing domains (e.g., transportation, healthcare, homeland security) • Collaborations with civil engineering, cognitive sciences, biology, nursing, etc.

47. Acknowledgments • 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

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