Networking for Pervasive Computing Hari Balakrishnan Networks and Mobile Systems Group MIT Laboratory for Computer Science

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 - 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 database Passive listeners + active beacons preserves privacy Straightforward deployment and programmability No central beacon control or location database Passive listeners + active beacons preserves privacy Straightforward 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 t RF BRF AUS 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 t RF AUS A

t S/b r/v (max) S = size of space advertisement b = RF bit rate r = ultrasound range v = velocity of ultrasound Bounding Stray Signal Interference (RF transmission time) (Max. RF-US separation at the listener) S r b 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 t RF AUS A RF BUS B

Preventing repeated interactions Randomize beacon transmissions: loop: pick r ~ Uniform[T 1, T 2 ]; delay(r); xmit_beacon(RF,US); Optimal choice of T 1 and T 2 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 Number of samples Mean (feet) 86Mode (feet) 86Actual distance (feet) BA

Closest beacon may not reflect correct space I am at B Room ARoom B

Correct beacon positioning Room ARoom B xx I am at A 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 US RS232

Mobile listener performance Room ARoom B Room C

Comparisons Space naming convention RF signal mapping and good radios Centralized database + wired IR sensors Centralized controller + matrix of sensors Deployment considerations ~2 feet for spatial resolution Room-wide Few cmPosition accuracy NoNo, if client has signal map Yes Track user location? CricketRADARActive badge Bat Attribute System

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 > 25 0 C] 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 applications

Cricket demo