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
2
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
3
Ad Hoc Networks as Distributed
Service Providers

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
P
P
Traffic jam
predictor
P
CLA
RK S
T
ELMWOOD AVE
C
GR
OV
ES
T
CHURCH ST
OLD
TOWN
P
P
DAVIS ST
MAPLE AVE
RIDGE AVE
Entity
tracking
OAK AV
– Many times, interact for longer period of time with clients
Parking
spot finder
LA
KE
ST
BURNSIDE ST
C
COLLEGE ST
C
Service
C
Client
4
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
5
Traffic Jam Predictor Service
C
Region of
interest
Service
C


Client
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
6
Entity Tracking Service
Service
C
C


Client
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
7
OAK AV
Parking Spot Finder Service
P
P
ELMWOOD AVE
CLA
RK S
T

GR
OV
ES
T
Service
OLD
TOWN
P
P
DAVIS ST
MAPLE AVE
RIDGE AVE

CHURCH ST
P
C
Client
LA
KE
ST
BURNSIDE ST
C
COLLEGE ST
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
8
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
9
Outline

Motivation

Context-Aware Migratory Services

Migratory Services Framework

Implementation & Evaluation

Conclusions

Other Current/Future Work
10
Migratory Service Model
Virtual service
end-point
Migratory
Service
MS
State
n3
Client
C
n1
Service
Migration
MS
Migratory
n2 Service
State
Context Change! (e.g., n2 moves out of the region of interest)
MS cannot accomplish its task on n2 any longer
11
Migratory Service Model (Cont’d)
MS
Migratory
n2 Service
State
Client
C
n1
Create
Migratory Service
Meta-service

One-to-one mapping between
clients and migratory services
M MS
State
Service
Migration
Migratory
Service
n4
12
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
13
Outline

Motivation

Context-Aware Migratory Services

Migratory Services Framework

Implementation & Evaluation

Conclusions

Other Current/Future Work
14
Migratory Services Framework at Nodes
Client Application/Service
Context
MonitoredCxt
Manager
InCxtRules
Validator
Communication
Manager
Reliability
Manager
OutCxtRules
Smart Messages Platform
Operating System/ Wireless Communication / Sensors
15
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
16
Migratory Services Framework
Client Application/Service
Context
MonitoredCxt
Manager
InCxtRules
Validator
Communication
Manager
Reliability
Manager
OutCxtRules
Smart Messages Platform
Operating System/ Wireless Communication / Sensors
17
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)
18
SM Node Architecture
SM Ready
Queue
SM Admission
Network
Manager
Code
Cache
Virtual Machine SM
Network
Interpreter
Authorization
Tag
SM
Platform Space
Operating System & I/O
19
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)
20
SM Migration
migrate(Taxi)
Taxi
1

Taxi
sys_migrate(2)
2
sys_migrate(3)
3
sys_migrate(4)
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
21
Routing Example
1
2
i
Network
RouteToTaxi = 2
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);
}
Taxi
22
Migratory Services Framework
Client Application/Service
Context
MonitoredCxt
Manager
InCxtRules
Validator
Communication
Manager
Reliability
Manager
OutCxtRules
Smart Messages Platform
Operating System/ Wireless Communication / Sensors
23
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)
24
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
25
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
26
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)
27
Reliability Manager

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
Active
Inactive
Service
Service
Update
Response
Response
Update
Response
Response
Update
Response
Response
Client
Timeout
Request
Response
Response
Response
Delete
28
Migratory Services Framework
Client Application/Service
Context
MonitoredCxt
Manager
InCxtRules
Validator
Communication
Manager
Reliability
Manager
OutCxtRules
Smart Messages Platform
Operating System/ Wireless Communication / Sensors
29
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
avgnum - minnum
maxnum - minnum
avgspeed - maxspeed
Pspeed = maxPspeed ×
minspeed - maxspeed
P'tjam =  × Pnumber +(1-  )× Pspeed
Pnumber = maxPnumber ×
Ptjam = P'tjam×
Njam
Ntotal
30
TJam Pseudo-Code
monitoredCtx = {location, speed}
inCtxRule = {<responseLocation, OUT_REGION, region>,
rejectResponse && sendUpdate}
serviceParameters = {region, frequency}
Client
request = {clientName, serviceParameters}
send(TJam, request);
while (NOT_DONE)
response = receive(msName)
monitoredCtx = {location, speed, region}
outCtxRule = {<location, OUT_REGION, region>,
migrateService}
while (NOT_DONE)
response = computeResponse();
send(clientName, response)
Migratory
Service
31
Outline

Motivation

Context-Aware Migratory Services

Migratory Services Framework

Implementation & Evaluation

Conclusions

Other Current/Future Work
32
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
33
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
34
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
35
SM Micro-Benchmark Results
Used 2 WiFi-equipped HP iPAQs running Linux
7
30
Java object array
Java int array
6
Code Uncached
25
Code Cached
5
Time (ms)
Tme (ms)
20
4
3
15
10
2
5
1
0
0
2
4
8
16
Size (KBytes)
Cost of data serialization
1224
2236
4294
Code Size (Bytes)
8383
Cost of single hop migration
36
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
506.6
314.7
Completion Time
37
TJam Constantly Executes in the UserSpecified Region
Ad hoc network of 11 HP iPAQs with WiFi cards &
mobility traces
3600
3200
2800
2400
Location (m)

2000
1600
user location
service location/correct answer
service location/wrong answer
updates
user range
1200
800
400
0
0
50
100
150
200
time (sec)
250
300
350
400
38
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
39
Response Time vs. Number of Clients
Correct response generation time (Base)
Inter-response time (Smart)
Inter-response time (Base)
3,5
0,06
3
0,05
2,5
0,04
2
0,03
1,5
0,02
1
0,01
0,5
0
0
50
100
150
200
250
Inter-response time (sec)
Correct response
generation time (sec)
0,07
Correct response generation time (Smart)
300
Clients number

Vehicles average speed: 30m/s with an average gap of
150m
40
Correct response
generation time (sec)
0,06
Correct response generation time (Smart)
Correct response generation time (Base)
Inter-response time (Smart)
Inter-response time (Base)
3
0,05
2,5
0,04
2
0,03
1,5
0,02
1
0,01
0,5
0
Inter-response time (sec)
Response Time vs. Average Speed
0
10
20
30
Vehicles speed (meter/sec)

Number of clients: 150
41
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
42
Outline

Motivation

Context-Aware Migratory Services

Migratory Services Framework

Implementation & Evaluation

Conclusions

Other Current/Future Work
43
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
44
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
45
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.
46
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
47
Thank you!
http://www.cs.njit.edu/~borcea/
48