Experiments with User-Centric Ad-hoc Applications Durga Prasad - - PowerPoint PPT Presentation

Experiments with User-Centric Ad-hoc Applications

Durga Prasad Pandey MIT Media Lab July 31st 2007 Presented at: IBM Watson Research Center Cambridge

~FluidVoice~

an infrastructure-less voice conferencing system

Wouldn’t it be cool if I could listen to everyone in the lab?

Maybe not!

Who’s playing loud music at work? Only Grace has the temerity to do that!

Actually, its D u r g a !!

Oops! ;)

Circle of influence, or ‘speak if you dare’

Grace Kwan Durga Robots Affects Andy David You’ve been FluidVoiced!!

9

Mann last night at the nightclub..psst psst… Hey dude! What did I just say? Isn’t FluidVoice on?

It is!!!

My reach? Its everywhere!

What is FluidVoice?

• A conferencing system
• No infrastructure
• Push to listen
• Ad-hoc
• Wireless
• A viral system

Why Voice?

• Heavy enough to stress the wireless

network and reveal weaknesses

– Video can buffer, sensors don’t send much data

• Time sensitive
• Its an application!

13

Compelling Application?

• 5000,000 Children’s Laptops(OLPC)
• Mesh Networking enabled
• Huge potential of on the fly voice

collaboration

• Testbed and Usebed

14

Architecture

15

What’s viral?

• Start small
• Scalable
• Incremental. Each node adds value.
• Examples: Skype, Google, eBay, Napster..

Why does it matter?

• Better characterize the wireless space
• Cynic: But wireless is unreliable, bad bla

bla…

– Well let me build a system, learn from it, fix it.

• Exploit inherent broadcast nature

– Wireless is not a link

• Collaborate on the fly!

Traditional Telephony

18

A C

FluidVoice-Many2Many

19

C

Technically speaking

• Broadcast UDP packets
• Mixer locally, not like

Yahoo chat!

• Gateway allows calls from cellphone/PSTN
• Neat Interface borrowed from Sociable

Media work

• More than 9 nodes = system starts getting

ill

• Built on

VIA boards = Free trip to LA!

Whats hot!

• Nodes running in offices
• Demo on N800
• Gateways to PSTN/cellphones and Avaya

p2p phones

• Web based UI
• Separation of UI, mixing and listening

22

To Sum Up

• Privacy - someone’s hearing me!
• Local mixing - everyone has a mixer.
• Identity - who’s allowed?
• Inversion of the telephone system -

– Traditional: Point to Point – FV: Many to Many with Point to Point as special case

• Philosophy - Open the communications

space to innovation.

23

Future Work

• FluidVoice on N80 Nokia Cellphones
• Deployment of FluidVoice in the Media Lab

building

• Deployment of a credit based multihop

system in FluidVoice

• Separate multiple conversations

24

UniPlug: A Framework For Ad-hoc Invention sharing

Invention

• Computer programs/software
• Diagrams
• New applications
• Websites
• Video tutorials
• Online Papers

What’s the problem?

• Invention sharing is currently not ad-hoc
• Need to be able to build systems that allow a

community to share inventions

• There are lots of inventions on the MIT

campus that are forgotten

• If I plug my iPod into the laptop, can I get all

the programs people have written for it?

What UniPlug does

• Ad-hoc sharing
• Plug-n-Play detection of devices
• Proximity detection of Bluetooth devices
• Automatic lookup and download for useful

software from UniServer

• User populated UniServer

Requirements

• Work well in Ad-hoc environment
• Populatable in a distributed way
• Code should be trusted or verifiable.

Malicious users must be punished.

• System should be scalable

Architecture

• UniClient
• UniServer
• OpenDHT

Mechanisms

• Leader election for LANs
• Inter-UniServer borrowing
• Store only whats relevant locally
• Context-oriented programming

Leader election

• Every LAN has a leader that responds to

requests for service discovery

• Leader can be chosen round robin or credit

system based

• Leaders signal to others when they are about

to relinquish

• No heartbeat means leader is no more

Local content

• Store inventions only for devices that are

registered for the community

• Look for content for those registered devices

periodically from other UniServers with frequency specified by users

• Credit based serving of number of requests

Models

• Peer-to-Peer
• InterLibrary
• Client-Server

Context Classification

• User Context(BP)
• Device Context(battery level)
• Surroundings Context(# of wifi networks)

Scaling

• System scales by having lots of users host

content

• Scaling only needed for the campus
• Everyone hosts content they need and

service others only on interlibrary.

• A machine will only perform a limited number
• f services.

Demo: UniPhone

Demo: UniBlue

UniBlue for Fluidvoice

Security Issues

• Trust networks for small communities
• Human moderated invention posting
• Damage control for malicious code released

Patient-centric UniPlug implementation scenario

Medical Devices PnP

• MGH based consortium
• Value in interconnecting Medical Devices
• Currently they aren’t interoperable across

vendors

• Doctors’/BioMed engineers’ inventions need

to be sharable

• Context-oriented programming will be

critical

To Sum Up

• Context-based invention sharing
• Better device utilization
• Inventions not lost over time
• Enables better collaboration

Future Work

• Demo with medical devices and OR of the

future

• Full P2P version of UniClient
• Deployment and testing with the MIT

community under Living The Future program

Questions?

• Thanks!
• Special thanks to Daniel Gruen and Ciaran

Dellafera.