Networking for Pervasive Computing
Hari BalakrishnanNetworks and Mobile Systems GroupMIT Laboratory for Computer Science
http://nms.lcs.mit.edu/
The real new, new thing
• Natural technology trends– Computation is becoming essentially free– Communication is becoming ubiquitous
• Smart devices– Huge numbers of computing devices in the world– What are we doing with them?
• Modes of operation– Programs controlling other programs in our environment– Human-in-the-loop: computing should be only as visible
as I desire; no more, no less...
MIT Project Oxygen
• Pervasive, human-centered computing• Improve human productivity and comfort
– Move computation into the mainstream of our lives– Improve ease-of-use and accessibility– “Do more by doing less”
• The real challenge:“To develop a deep understanding of how to develop,
deploy, and manage systems of systems in dynamic environments”
• Build to use; use to build
“Situated”computing Projector
Phone
Camera array
Microphone array
Speech & vision
- Handheld, mobile computers (e.g., Handy21)- Situated computing resources & sensors (e.g, Enviro21)- Networked “smart” devices
- And tons of software making all this work together!User technologies & system software
The Oxygen environment
An example:Context-aware network services
• Resource discovery and secure information access
• Unconstrained, adaptive mobility
• “Zero” configuration • Context-aware, location-based,
speech-driven active maps
This talk: context-aware networking
• Enable applications to adapt to real-world context and conditions• Physical location
– Location-aware applications– Requires location-support system (Cricket)
• User/application intent– Resource discovery mechanism must allow applications to express what
they want– Intentional Naming System (INS)
• Mobility– Devices using multiple networks at the same time– Application-controlled end-to-end mobile routing to capture network
context (Migrate)
Cricket design goals
• Preserve user privacy• Recognize spaces, not just physical position
– Good boundary detection is important • Operate inside buildings• Easy to administer and deploy
– Decentralized architecture and control• Low cost and power consumption• GPS-oriented solutions do not provide required
precision, reliability, or cost-effectiveness
Traditional approach
Networked sensor grid
Location DB
ID = u
ID = u?
Responder
Problems: privacy; administration; granularity; cost
Cricket: Private location-support
Beacon
Listener
No central beacon control or location databasePassive listeners + active beacons preserves privacyStraightforward deployment and programmability
space = “a1”
space = “a2”
Pick nearest to infer space
• A beacon transmits an RF and an ultrasonic signal simultaneously– RF carries location data, ultrasound is a narrow
pulse
• The listener measures the time gap between the receipt of RF and ultrasonic signals– A time gap of x ms roughly corresponds to a
distance of x feet from beacon– Velocity of ultra sound << velocity of RF
Determining distance
RF data(space name)
Beacon
Listener
Ultrasound(pulse)
Uncoordinated beacons
• Multiple beacon transmissions are uncoordinated
• Different beacon transmissions can interfere– Causing inaccurate distance measurements at
the listener
Beacon A Beacon B
tRF B RF A US B US A
Incorrect distance
Handling spurious interactions
• Combination of three different techniques:– Bounding stray signal interference– Preventing repeated interactions via
randomization– Listener inference algorithms
Bounding Stray Signal Interference
• RF range > ultrasonic range– Ensures an accompanied RF signal with
ultrasound
tRF A US A
t
S/b
r/v (max)
S = size of space advertisementb = RF bit rater = ultrasound rangev = velocity of ultrasound
Bounding Stray Signal Interference
(RF transmission time) (Max. RF-US separation at the listener)
S rb v
Bounding stray signal interference
• Envelop ultrasound by RF• Interfering ultrasound causes RF signals to
collide• Listener does a block parity error check
– The reading is discarded
tRF A US A
RF B US B
Preventing repeated interactions
• Randomize beacon transmissions: loop:
pick r ~ Uniform[T1, T2];delay(r);xmit_beacon(RF,US);
• Optimal choice of T1 and T2 can be calculated analytically – Trade-off between latency and collision probability
• Erroneous estimates do not repeat
Inference Algorithms
• MinMode– Determine mode for each beacon– Select the one with the minimum mode
• MinMean– Calculate the mean distance for each beacon– Select the one with the minimum value
• Majority (actually, “plurality”)– Select the beacon with most number of readings– Roughly corresponds to strongest radio signal
Inference Algorithms
Distance(feet)
Frequency A B
5 10
5
107Number of samples
6.46.14Mean (feet)
86Mode (feet)
86Actual distance (feet)
BA
Closest beacon may not reflect correct space
I am atB
Room A Room B
Correct beacon positioning
Room A Room B
x x
I am atA
• Position beacons to detect the boundary
• Multiple beacons per space are possible
Implementation• Cricket beacon and listener
• LocationManager provides an API to applications
• Integrated with intentional naming system for resource discovery
Micro-controller
RF
US
Micro-controller
RF
USRS232
Mobile listener performance
Location Algorithm Error Rates
024
68
101214
161820
2 3 4 5 6
Sampling Interval
Erro
r Rat
e (%
)
MinMeanMinModeMajority
Room A Room B
Room C
Context-aware resource discovery
• Services advertise/register resources• Consumers make queries for services• System matches services and consumers• This is really a naming problem
– Name services and treat queries are resolution requests
– Problem: most of today’s naming systems name by (network) locations
– Names should refer to what, not where
[service = lcs.mit.edu/thermo][building = NE43 [floor = 5 [room = *]]][temperature > 250C]data
[service = mit.edu/camera][building = NE43
[room = 510]][resolution=800x600][access = public][status = ready]
Intentional names
• Expressive name language (like XML)• Providers announce attributes• Clients make queries
– Attribute-value matches– Wildcard matches– Ranges
INS architecture
[service = camera][building = NE43
[room = 510]]
Intentional name
Late binding: integrate resolution and message routing
image
Lookup
camera510.lcs.mit.edu
Resolver self-configuration
Intentional name resolvers form an overlay network
Status
• Cricket v1 being deployed with location-aware applications using INS– Lots of interesting deployment issues and interactions with
the real-world• INS deployed at LCS
– Starting to be used in wider Oxygen context– Mobile applications using late-binding– Cricket beacons disseminate INS “vspaces”
• Enabling technologies for location-aware applicationshttp://nms.lcs.mit.edu/