Lecture 5: Programming Mobile Ad Hoc Networks
Cristian Borcea
Department of Computer Science
NJIT


Wireless systems cooperate
to achieve global tasks
Mobile devices don’t interact
with each other directly
 Traditional client-server model
predominates

No interaction between mobiles
and static sensors
2

Hard to program applications over mobile ad hoc
networks (MANETs)
 Systems
▪ Mobile and distributed across physical space
▪ Internet connectivity may be unavailable or too expensive
▪ Resource-constrained: battery, bandwidth
▪ May contain highly sensitive data: location, social contacts
▪ Heterogeneous: both hardware and software
 Networks
▪ Large scale
▪ Volatile: ad hoc topologies, dynamic resources
▪ Less secure than wired networks
3
Introduction
 3 MANET programming models

[Ref. 1]
 Migratory Services: context-aware client-service
programming
 Spatial Programming: location-aware imperative
programming
 Contory: SQL-like declarative programming

Smart Messages: implementation platform for all 3
models
4
 Acquire, process, disseminate real-time information from proximity
of regions, entities, or activities of interest
 Have context-aware execution
OAK AV
 Many times, interact for longer period of time with clients
P
P
CLA
RK S
T
C
ELMWOOD AVE

Typical devices: smart phones and vehicular systems
Distributed sensing services
S
RIDGE AVE
Traffic jam
predictor
CHURCH ST
P
S
GR
OV
ES
T
C
OLD
TOWN
P
P
DAVIS ST
MAPLE AVE

S
LA
KE
ST
BURNSIDE ST
C
COLLEGE ST
Parking spot
finder
Entity
tracking
5

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

End-to-end data transfers may hardly complete
6


Context-aware client-server programming 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
7
Virtual service
end-point
Migratory
Service
MS
State
n3
Client
Service
Migration
C
n1
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
8
MS1
C1
State
n4
Create
Migratory Service
n1
Metaservice
M
MS1
State
MS2
State
C2
n3
MS2
State
n2
n5
9
Client Application/Service
Context
Manager
MonitoredCxt

InCxtRules
Monitors context identifiers specified by
programs
Validator
OutCxtRules
Communication
Reliability
 Manager
Evaluates context
rules specified
by programs
Manager
Discover
meta-services
 control
Transfer
messages
IN context rules
incoming
databetween

Based on the classical
primary-backup
approach
communicating
end-points
– Used for meta-services
to accept/refuse
requests
with two modifications
Smart
Messages
Platform
 Carry
out service
migration
– – Used
for
clients
to
accept/refuse
responses
Secondary node dynamically selected
in a
OUTcontext-aware
context
rules
control
manner outgoing
  Provides
execution
migration,
routing, data
property-based
Operating
System/
Wireless
Communication
/ Sensors
naming
– – Used
for
migratory
services
toadapted
decide whether
to
Backup
frequency
constantly
based
on the
operating
conditions
send
a response
ornetwork
trigger a
migration

10

Predict 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
Inform me when there is high
probability of traffic jam 10 miles ahead
11
monitoredCtx = {location, speed}
inCtxRule = {<responseLocation, OUT_REGION, region>,
rejectResponse && sendUpdate}
serviceParameters = {region, frequency}
request = {clientName, serviceParameters}
Client
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
12
Introduction
 3 MANET programming models

 Migratory Services: context-aware client-service
programming
 Spatial Programming: location-aware imperative
programming
 Contory: SQL-like declarative programming

Smart Messages: implementation platform for all 3
models
13

Imperative programming model with fine-grained control
over individual systems

Provides a virtual name space over MANETs
 Systems

referenced by their locations and properties
Runtime system takes care of name resolution, reference
consistency, and networking aspects

Implementation on top of Smart Messages: SP applications
execute, sequentially, on each system referenced in their
code
14
Distributed application Variable accesses
Shared virtual address space
Page table + OS + Message passing
Distributed physical memory
Programs access data through variables
 Variables mapped to physical distributed memory locations
 Page Table and OS guarantee reference consistency

 Runtime system translates variable accesses into message passing

Access time has an (acceptable) upper bound
15
Hill = new Space({lat, long}, radius);
{lat,long}
radius
Virtual representation of a physical space
 Similar to a virtual address space in a distributed shared
memory system
 Defined statically or dynamically

16
{Hill:robot[0]}
Hill
r2
r7
{Hill:robot[1]}
m5
{Hill:motion[0]}
Defined as {space:property} pairs
 Virtual names for wireless systems
 Similar to variables in conventional programming
 Indexes used to distinguish among similar systems in the
same space region

17
At first access, a spatial reference is mapped to a
system located in the specified space
 Mappings maintained in per-application Mapping
Table (MT) – similar to a page table

{space, property, index}

{unique_address, location}
Subsequent accesses to the same spatial reference
will reach the same system (using MT) as long as it
is located in the same space region
18
Right Hill
Left Hill
r5
r2
r7
{Left_Hill:robot[0]}.move = OFF;
ON;
19
Left Hill
Right Hill
r7
{Left_Hill:robot[0]}
{Right_Hill:(Left_Hill:robot[0])}
20
Systems may move, go out of space, or disappear
 Solution: associate an explicit timeout with each
spatial reference access

try{
{Hill:robot[0], timeout}.move = ON;
}catch(TimeoutException e){
// the programmer decides the next action
}
21
Left Hill
Right Hill
- Find sensor that
detected “strongest”
motion on Left Hill
- Turn on a camera in the
proximity of this
sensor
for(i=0; i<1000; i++)
try{
if ({Left_Hill:motion[i], timeout}.detect > Max_motion)
Max_motion = {Left_Hill:motion[i], timeout}.detect;
Max_id = i;
}catch(TimeoutException e)
break;
intrusionSpace = rangeOf({Left_Hill:motion[Max_id].location}, Range);
{intrusionSpace:robot[0]}.camera = ON;
{intrusionSpace:robot[0]}.focus = {Left_Hill:motion[Max_id].location};
22
Introduction
 3 MANET programming models

 Migratory Services: context-aware client-service
programming
 Spatial Programming: location-aware imperative
programming
 Contory: SQL-like declarative programming

Smart Messages: implementation platform for all 3
models
23

Declarative programming model that sees MANETs as
distributed database for context (i.e., sensing) information
Flexible and adaptive context provisioning based on dynamic
operating conditions
 May also query internal sensors and Internet-accessible sensors
MANET part
Application
Application
Cxt
Query
Cxt
Query
Application
O
E
P
Query
Manager
Cxt
Query
Context Factory

on demand query
event-based query
periodic query
Context
Context
Aggregator
Aggregator
Resources
Monitor
Local
Facade
O
O
E
E
P
AdHoc
Facade
P
LocalCxt
LocalCxt
Provder
Provider
Internal
Reference
Infra
Facade
O E P
O E P
O
O
E
E
P
P
InfraCxt
InfraCxt
Provder
Provider
AdHocCxt
AdHocCxt
Provder
Provider
MANET
commun.
MANET
commun.
BT
Reference
WiFi
Reference
Event-based
commun.
2G/3G
Reference
SensorData
SensorData
SensorData
SensorData
SensorData
SensorData Sources SensorData
SourceSensorData Sources
Sources
Sources
Sources
Sources
Sources
24

Supports on-demand, periodic, and event-based MANET
queries
SELECT <sensing type>
FROM <source> [(# nodes, # hops | region)]
WHERE <predicate clause>
FRESHNESS <time>
DURATION <duration> | <number of samples>
EVERY <time> | EVENT <predicate clause>
Weather watcher application
Required
SELECT temperature
FROM adHocNetwork(3, 2)
WHERE fidelity = 0.2
FRESHNESS 30 sec
DURATION 1 hour
EVENT AVG(temperature)>25
25
Application’s
control
SELECT temperature
DURATION 1 hour
Max transparency
SELECT temperature
FROM adHocNetwork(3, 2)
WHERE accuracy = 0.2
FRESHNESS 30 sec
DURATION 1 hour
EVENT AVG(temperature)>25
Contory’s
control
Max awareness
26

Monitor available resources
 Power, memory, running applications, etc.
Trade off sensing quality and resource consumption
 Reduce the global utilization of resources

 Query aggregation for queries submitted by the same
device

Prioritize tasks
 Context-awareness is a background activity on phones
27
Contory
Advantages
Spatial
Programming
Migratory
Services
Adapt to MANET volatility
Easy to program:
familiar API &
high
transparency
Limitations Difficult to use
for complex
distributed
applications
Good for complex
distributed
applications: finegrained access to
resources.
Good for longrunning stateful
end-to-end
interactions
Significant effort
from programmers
Not
straightforward
for applications
that do not fit
client-server
model
Introduction
 3 MANET programming models

 Migratory Services: context-aware client-service
programming
 Spatial Programming: location-aware imperative
programming
 Contory: SQL-like declarative programming

Smart Messages: implementation platform for all 3
models
29
Lunch:
Appetizer
Entree
Dessert
Data migration
Execution migration
30

User-defined distributed applications
 Composed of code bricks, data bricks, and execution control state



Execute on nodes of interest named by properties (i.e., tags)
Migrate between nodes of interest
Self-route at every node in the path during migrations
Cooperative node
architecture
SM Ready
Queue
Network
SM
Virtual SM Network
Machine
Admission
Manager
Code
Cache
Authorization
SM
Platform
Tag
Space
Operating System & I/O
31
Takes place over a virtual machine
 Non-preemptive, but time bounded
 Ends with a migration, or terminates
 During execution, SMs can

 Spawn new SMs
 Create smaller SMs out of their code and data bricks
 Access the tag space
 Block on a tag to be updated (i.e., update-based
synchronization)

Collection of application tags and I/O tags on each node

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)
33
Ensures progress for all SMs in the network
 Prevents SMs from migrating to nodes that cannot provide
enough resources
 SMs specify lower bounds for resource requirements (e.g.,
memory, bandwidth)

 Determined a-priori through profiling


SMs accepted if the node can satisfy these requirements
More resources can be granted according to admission
policy
 If not granted, SMs are allowed to migrate
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
35
SMs carry the routing and execute it at each node
 Routing information stored in tag space
 SMs control their routing

 Select routing algorithm (migrate primitive)
▪ Multiple library implementations
▪ Implement a new one
 Change routing algorithm during execution in response to
▪ Adverse network conditions
▪ Application’s requirements
36
1
2
i
Network
RouteToTaxi = 2
RouteToTaxi = ?
j
Taxi
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);
}
37

Implemented in Java
 Java 2 Micro-Edition (J2ME) with CLDC 1.1 and MIDP 2.0
 J2ME with CDC


Development using HP iPAQs (Linux) and Nokia phones
(Symbian)
SM platforms
 Original SM on modified KVM (HP iPAQs) – migration state captured
in the VM
 Portable SM on Java VM, J2ME CDC (Nokia 9500) – migration state
captured using bytecode instrumentation
38
1.
Urbanets
 http://cs.njit.edu/~borcea/papers/ieee-pervasive07.pdf
2.
Migratory Services
 http://cs.njit.edu/~borcea/papers/ieee-tmc07.pdf
3.
Spatial Programming
 http://cs.njit.edu/~borcea/papers/spsm04.pdf
4.
Contory
 http://people.inf.ethz.ch/oriva/pubs/riva_middleware06_paper.pdf
5.
Smart Messages
 http://cs.njit.edu/~borcea/papers/sm03.pdf
39
Two decades of mobile computing
2. Infrastructure support for mobility
3. Mobile social computing
4. People-centric sensing
5. Programming mobile ad hoc networks
6. Vehicular computing and networking
1.
 Vehicular ad hoc network (VANET) applications: EzCab & TrafficView
 RBVT routing in VANET
 Dynamic traffic guidance in vehicular networks
7.
Privacy and security in mobile computing
40