networking for pervasive computing hari balakrishnan networks and mobile systems group mit...

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/

Cricket demo