Turning ad hoc networks into distributed service providers
This presentation is the property of its rightful owner.
Sponsored Links
1 / 48

Turning Ad Hoc Networks into Distributed Service Providers PowerPoint PPT Presentation


  • 57 Views
  • Uploaded on
  • Presentation posted in: General

Turning Ad Hoc Networks into Distributed Service Providers. Cristian Borcea Department of Computer Science New Jersey Institute of Technology. Ubiquitous Computing Environments. Wireless systems embedded everywhere Large scale ad hoc networks will soon become reality.

Download Presentation

Turning Ad Hoc Networks into Distributed Service Providers

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Turning ad hoc networks into distributed service providers

Turning Ad Hoc Networks into Distributed Service Providers

Cristian Borcea

Department of Computer Science

New Jersey Institute of Technology


Ubiquitous computing environments

Ubiquitous Computing Environments

  • Wireless systems embedded everywhere

  • Large scale ad hoc networks will soon become reality


Ad hoc networks as data carriers

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


Ad hoc networks as distributed service providers

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


Problems with tcp ip client server model in ad hoc networks

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


Traffic jam predictor service

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


Entity tracking service

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


Parking spot finder service

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


Requirements for new service model in ad hoc networks

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


Outline

Outline

  • Motivation

  • Context-Aware Migratory Services

  • Migratory Services Framework

  • Implementation & Evaluation

  • Conclusions

  • Other Current/Future Work


Migratory service model

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


Migratory service model cont d

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


Key ideas of migratory services model

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


Outline1

Outline

  • Motivation

  • Context-Aware Migratory Services

  • Migratory Services Framework

  • Implementation & Evaluation

  • Conclusions

  • Other Current/Future Work


Migratory services framework at nodes

Migratory Services Framework at Nodes


Framework s tasks

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


Migratory services framework

Migratory Services Framework


Smart messages sm

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)


Sm node architecture

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


Tag space

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)


Sm migration

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


Routing example

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);

}


Migratory services framework1

Migratory Services Framework


Context manager

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)


Validator

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


Context rules specification

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


Communication manager

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)


Reliability manager

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


Migratory services framework2

Migratory Services Framework


Tjam migratory service example

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


Tjam pseudo code

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


Outline2

Outline

  • Motivation

  • Context-Aware Migratory Services

  • Migratory Services Framework

  • Implementation & Evaluation

  • Conclusions

  • Other Current/Future Work


Implementation

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


Implementation current status

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


Evaluation

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


Sm micro benchmark results

SM Micro-Benchmark Results

Used 2 WiFi-equipped HP iPAQs running Linux

Cost of data serialization

Cost of single hop migration


Sm simple routing algorithm results

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


Tjam constantly executes in the user specified region

TJam Constantly Executes in the User-Specified Region

  • Ad hoc network of 11 HP iPAQs with WiFi cards & mobility traces


Tjam simulations

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


Response time vs number of clients

Response Time vs. Number of Clients

  • Vehicles average speed: 30m/s with an average gap of 150m


Response time vs average speed

Response Time vs. Average Speed

  • Number of clients: 150


Conclusions

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


Outline3

Outline

  • Motivation

  • Context-Aware Migratory Services

  • Migratory Services Framework

  • Implementation & Evaluation

  • Conclusions

  • Other Current/Future Work


Turning ad hoc networks into distributed service providers

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


Smartcampus ubiquitous social computing middleware applications

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


What s next for ubiquitous computing

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.


Acknowledgments

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


Turning ad hoc networks into distributed service providers

Thank you!

http://www.cs.njit.edu/~borcea/


  • Login