Embed Size (px)
Citation preview
Middleware for Mobile SensingApplications in Urban Environments*
Oriana Riva
ETH Zürich
* This work was carried out at the University of Helsinki and HIIT
Research Summary
– Middleware for Mobile Sensing Applications in UrbanEnvironments (with Rutgers University and NJIT)
– Context-aware Service Discovery (with INRIA-Rocquencourt)
– Recommendation Systems for Mobile Users (with VTT Helsinki,TeliaSonera, Suunto and ICT-Turku)
– Design Patterns for Context-awareness Support (with NOKIA-NRCand University of Naples)
Toward a Sensor-Rich World
”Machines, buildings, fieldsand human bodies have alot to say, if only they aregiven a chance to talk”
First Generation Sensor Networks
Enable accurate real-time monitoring of thephysical world
Consist of homogeneous, static, tiny sensors
SinkInternet,Satellite, ...
TaskManager End user Sensor node
Fire in the forest
Habitat monitoring
... But does sensing impact oureveryday life? Structural integrity of
the bridgeNO!
The Key Question
How can we benefitfrom sensing in our
daily urban routine?
The Urbanet Revolution: Sensor Power tothe People!
People create and benefit from Urbanets, spontaneous mobile sensornetworks in urban environments
Urbanet Programming Challenges
Network volatility– Unstable configurations, unknown delays,
frequent failures
Naming
Sensor Variability and Fidelity– Heterogeneous sensing coverage– “Best effort” semantics
Functionally heterogeneous nodes
Limited Resources– Nodes are not fully dedicated to the sensing task
Large amount of data– Many concurrent sensing applications
How to Program Urbanets?
Existing people-centric mobile sensing solutions arecentralized– Central portals across the Internet
– Examples: Microsoft’s SenseWeb, UCLA’s Urban Sensing, MIT’sCartel, Dartmouth University’s MetroSense, Nokia’s SensorPlanet
Urbanets need distributed solutions– Potential for improved scalability, fault-tolerance, resource
utilization and privacy– Examples: ?
Lack of programming support and simple abstractions fordistributed computing in Urbanet-like environments
Solutions
Two different distributed middleware architectures thatabstract the system and networking details in two simpleprogramming models
– Contory provides support for declarative programming
– Context-aware Migratory Services provides supportfor client-server programming
Outline
þ Motivation
¨ Contory
¨ Context-aware Migratory Services
¨ Implementation and Evaluation
¨ Conclusions
Contory in a Nutshell
Support context-aware applications by monitoring both localand remote contexts (i.e., aggregated sensor data)
Integrate multiple strategies for sensor data collection
Dynamically adapt the sensing activity to the availableresources
Provide programmers with an SQL-like interface
Reliable Multi-Strategy Sensing
Sensors-based
Infrastructure-based
Ad hoc networks
Hard to rely only on one provisioning mechanismContory integrates all 3 strategies
SensingModule
Application
Sensorson device
SensingModule
SensingModule
Sensors in theenvironment
Application
Application
SensingModule
Application
SensingModule
Application
SensingModule
Application
SensingModule
Application
SensingModule
Serviceinfrastructure
Sensor dataacquisition
Informationdissemination
Sensors in theenvironment
Sensor dataprocessing
and reasoning
Resource-Driven Execution
Monitor available resources– Power, memory, running applications, local sensors, etc.
Trade off quality of result and resource consumption– Switch provisioning mechanisms
Reduce the global utilization of resources– Query aggregation
Prioritize tasks– Sensing is a background activity on phones
Contory Software Architecture
Con
text
Fact
ory
Query Template
SELECT <sensor data type>
FROM <source>
WHERE <predicate clause>
FRESHNESS <time>
DURATION <duration>
EVERY <time> | EVENT <predicate clause>
Application Example
Inform me whenthere is high
probability of trafficjam 10 miles ahead
SELECT speed
FROM adHocNetwork(all, remote_region)
WHERE accuracy > 70%
FRESHNESS 30 sec
DURATION 1 hour
EVENT AVG(speed)<min_speed
TJam: Traffic JamPredictor Application
Outline
þ Motivation
þ Contory
¨ Context-aware Migratory Services
¨ Implementation and Evaluation
¨ Conclusions
Migratory Services in a Nutshell
Support long-running stateful client-service interactions
Allow services to migrate in the network to carry out theirsensing tasks
Dynamically adapt the service execution to the operatingcontext
Provide programmers with communication primitives forclient-service programming
Requirements for a New Client-ServiceModel in Urbanets
Context-driven adaptability: the service always executes onnodes that satisfy the context requirements
Service continuity: the client sees a continuous interactionwith the service
On-demand code distribution: service code can bedynamically transferred to nodes
Region of interestRegion of interest
C
ServiceService
ClientClient
TrafficJamPredictor ParkingSpotFinderEntityTracking
Virtual serviceVirtual serviceendend--pointpoint
Migratory Services Model
ClientClient
nn11
CC
nn22
nn33
Context Change! (e.g., nContext Change! (e.g., n22 moves out of the region of interest)moves out of the region of interest)MS cannot accomplish its task on nMS cannot accomplish its task on n22 any longerany longer
ServiceServiceMigrationMigration
MSMSStateState MigratoryMigratory
ServiceService
MSMSStateState
MigratoryMigratoryServiceService
Migratory Services Model (Cont’d)
ClientClient
nn11
CC
nn22
MSMSStateState MigratoryMigratory
ServiceService
MetaMeta--serviceservice
nn44
MM
CreateCreateMigratory ServiceMigratory Service
MSMSStateState MigratoryMigratory
ServiceService
One-to-one mapping between clientsand migratory services
ServiceServiceMigrationMigration
Migratory Services Framework (MSF)
Smart Messages (SM)
Distributed programs executing sequentially on nodes ofinterest named by properties (tags)
Migrate between nodes of interest– Self-route at every node in the path during migrations
– Use geographical routing and content-based routing
Composed of:– Code bricks (e.g., Java class files)
– Data bricks (e.g., Java objects)
– Execution control state (e.g., instruction pointer, operand stackpointer)
Migratory Services Framework (MSF)
Proactive or reactive collection of context dataspecified in MonitoredCxt
Discover meta-services
Route messages betweencommunicating end-points
Carry out service migration
Evaluates if a service computation can be “correctly” carriedout on the current hosting node
If not, triggers migration
CxtRules are service/client-specific policies
CtxRules are condition/action statements
Based on the classical primary-backup approach with twomodifications– Secondary node dynamically selected, in a context-aware manner– Backup frequency constantly adapted based on the operating network
conditions
Request req = new Request(clientID,remote_region);
MSF.sendRequest(Tjam,req);
CxtRule rule = new CxtRule(serviceID);rule.setCondition(OutOfRegion,remote_region);rule.setAction(MIGRATE);MSF.registerCxtRule(rule);
while(NOT_DONE){tjam_p = computeTJamProbability(neighbors);if (tjam_p > MAX_PROB)
MSF.sendResponse(clientID,tjam_p);
}
TJam Implementation using MSF
Client
MigratoryService
Outline
þ Motivation
þ Contory
þ Context-aware Migratory Services
¨ Implementation and Evaluation
¨ Conclusions
Implementation
Implemented in Java– Java 2 Micro-Edition (J2ME) with CLDC
– J2ME with CDC
Development using HP iPAQs (running Linux), NokiaSeries 60 phones and Nokia Series 80 phones(running Symbian)
SM platforms– Original SM on modified KVM (HP iPAQs)
– Portable SM on Java VM, J2ME CDC (Nokia 9500 phones)
Experimental Evaluation
Goals:– Demonstrate the feasibility of our approaches– Analyze latency performance– Quantify the cost in terms of energy and memory consumption
Testbed– Ad hoc networks of smart phones
(Nokia 6630, 7610, 9500 phones),HP iPAQs and GPS devices
– Fluke 189 Multimeter
Get Context Item
Contory Latency Experiments
772.7Ext-infrastructure - UTMS
0.1Ad hoc network - WiFi
140.4Ad hoc network – BT
Avg latency (msec)Strategy
Ext-infrastructure - UTMS
Ad hoc network - WiFi
Ad hoc network - BT
Strategy
1 hop
2 hops
761.3
1473.0
1422.5
31.8
Avg latency (msec)
Publish Context Item
Contory Power Consumption:BT-GPS Failure
Contory Prototype Applications
Context-based serviceprovisioning
WeatherWatcher
Context-aware Migration Overhead
0
100
200
300
400
500
600
700
Avg
RTT
(mse
c)
1044 2088 4056 8010 16010
Data brick size (bytes)
DataTransfer +SM overhead41%
Serial./Deser.49%
DataTransfer +SM overhead 54%
Serial./Deser. 26%
CxtRule Validation: 530 sec on average for tested cxt rules
Migration Latency (1 hop)
Conn. establ. +thread switching10%
Conn. establ. +thread switching 20%
MSF Memory Consumption
Client: 68.827 KB (0.54%)
Meta-service and Migratory Service:
0
50
100
150
200
250
300
350
Mem
ory
cons
umpt
ion
(KB)
2669 8002 23922 71998 216000
MS state size (bytes)
MigratoryServiceMeta-service
Java on Nokia9500 has 12.7MB of RAM
0.88%
0.68%
2.57% 2.38%
TJam Prototype Migratory Service
Traffic jams are locally congested phases in which cars travelat slow or zero velocity– Inspired by RED algorithm for network congestion control
TJam uses two types of information that every car owns:– number of one-hop neighboring cars– speed of one-hop neighboring cars
n u m n u mn u m b e r n u m b e r
n u m n u m
s p e e d s p e e ds p e e d sp e e d
s p e e d s p e e d
t ja m n u m b e r s p e e d
ja mtja m tja m
to ta l
a v g - m inP = m a x P ×m a x - m in
a v g - m a xP = m a x P ×m in - m a x
P ' = × P + (1 - )× PNP = P ' ×N
α α
Outline
þ Motivation
þ Contory
þ Context-aware Migratory Services
þ Implementation and Evaluation
¨ Conclusions
Conclusions
Deployed two middleware architectures to support people-centric mobile sensing applications
Proposed adaptation strategies specifically designed forresource-constrained mobile devices
Implemented prototype systems on modern phone platformsand evaluated performance in small-scale ad hoc networks
Built appealing prototype applications targeting real-lifescenarios
Open Issues
Security and trust– Excessive resource utilization– Alter the state/code of a migratory service– Fake node’s resources and location
Privacy– Reduce storage of private data– Reduce dissemination of private data– Privacy preserving data mining techniques
Incentive models for cooperation
Interoperability among Urbanet platforms
Interference problems
Energy
Current and Future Work
Urbanets– Dynamic R-OSGi on resource-constrained devices– Large-scale evaluation in networks of phones
Query and data aggregation– From homogeneous and static sensor networks to heterogeneous
and mobile sensor networks– Opportunistic sharing of sensor information
Energy-awareness on mobile devices– Platform-independent resource management– Devise solutions at the OS layer
