xcast: controllable, movable, personalized...

1

XCast: Controllable,

Movable, Personalized Broadcasts

Sung-Hyuck Lee

[email protected]

Viral Communications Group, MIT Media Lab

2

Contents

• Abstract

• Backgrounds

• Usage scenarios

• XCast framework

– Mobile Interactive Participatory web

– Event Coordination Protocols

– XC Controller

• Future Work

– IVY Networks

– Graspable Tower

– XC MAC

• Plan

3

Abstract

• XCast is a project to build a controllable, mobile, personalized broadcast

system in a cooperative infrastructure-free milieu.

• It has two goals: to permit people to create instant multimedia broadcast

"stations" for extemporaneous events or individually motivated

presentations, and to explore the ways by which such trust-based networks

can be made robust in the face of external disruptions such as spam and

overloading.

• This project is targeted at mobile versions of a participatory Web where

each member is fluidly and easily a consumer and producer of information

to which others can contribute and explore.

• There are two challenges: reliable transport over open and existing

networks and making it an attractive application.

4

Backgrounds

• Motivations for personal broadcasts

– From ‘AndyCast’

• Who broadcasts and receives?

– FluidVoice is not controllable

• No controller

• A natural habitat for Spam

– Extemporaneous, yet timely social events

– The architecture of a collaborative communications system will help us design

cooperative, spectrum-sharing radios. We envision such cooperation as both a

social and a technical optimum; indeed the formative notion of the Viral

Communications group was based on turning every cell phone into a

tower. Fluid voice considers it as an intelligent tower.

• Graspable Towers

5

Usage Scenarios

• Possibly

– Benefit from Impromptu, yet timely scenarios

• Street DJCast, 911Cast, OrchestraCast, TalkCast, AlarmCast,

FleamarketCast, NoteCast, etc.

– ‘MIT-campus-tour’ -> Media Lab tour

• Thoughts for ‘Living The Future’

– EduCast: Interactive Broadcast Lecture

• Professors broadcast their lectures through XC.

• MIT community in local areas selects desirable lectures

on XC devices and give questions or comments on them.

• All feedbacks list on XC boards in classrooms.

6

Concerns

• Applications

– Local Interactions

– Not many applications for local events and interactions

• Event Coordination Protocol (ECP)

– Controls application and network events

• E.g., Broadcasting Queue of XCast

• Network Framework: IVY Networks

– Interactive infrastructure-free networks based on “Tower” and “Cell”

– Graspable Tower (GT) < GT Network < Personalized Networks

– Local mobile + “grass-roots” networks

• XCast MAC

– A novel 802.11 MAC for broadcasting

7

Mobile Participatory Web

• Local interactions for 24 hours – but we have not had applications to deal with local events.

– XCast delves for applications to resolve traits of local events

• Traits of local events– Extemporaneous, Impromptu

– Now days, emergent

– Vital, etc.

• “Mobile participatory (broadcast) web (?)– Based on ad-hoc/mesh networks

– Fluidly Localize (personalize) Database • On mobile devices, or servers in local personalized networks

• Not Google, but Your web

– A web per person, or local community • Created (or disappeared) by individuals’ needs

– Its feature fluidly changes according to persons (or groups), or events.• Exchange information among the mobile participatory webs

• Controlled by Event Coordination Protocol (ECP)

8

Event Coordination Protocol (ECP)

• Motivated from David’s idea for network event coordination protocol

• What to do

– Keep good throughput (Networks)

– Help create novel interactive applications (Application)

• How to do

– Control network events

• depending on types or events of applications

• Audio, video streaming, images, text, etc.

– Guide application events

• according to network conditions.

• Wireless noise, signal strength of neighbor nodes

• ECP of XCast: Broadcasting Queue (BQ)

– Decides the order of broadcast dependent on the application events

– Helps create interactive queuing applications running by users’ inputs.

– Results in alleviating issues on mayhem of Spam broadcasts

9

ECP Example 1:

OLPC OrchestraNets

• OLPC OrchestraNets

– Each OLPC plays a single musical instrument

– Broadcasting Queue (BQ): a virtual orchestra conductor

• BQ (ECP) monitors performance of a mesh network

• controls broadcasting for a virtual orchestra according to the

musical note queued.

10

ECP Example 2: AutoNets

• Collision Avoidance for Vehicles– Broadcast Queue (BQ) is automatically created

• when cars are close each other (an ad-hoc network)

– BQ gives guidelines on or controls speeds (engines) and directions (handles) of all cars.

11

ECP Example 3: PriNets

• Motivated from Andy’s idea for printers

• Load balancing through ECP– Guide to find the most appropriate printer

– Previously notify “who is hard working”, “who is hungry (no paper)”, “who is sick (paper jam)”, “who is printing same materials”, etc.

• Analysis of materials printed – Is this scare?

– Provides References to help Information sharing

• Is this an item for “Living The Future?”

12

XCast Procedures

• Control mechanisms according to the data classification

Urgent or

not?

Identification is

includedWant PB

community?

BroadcastQueue (ECP) is

created

File sharing by

XCast Collection

Broadcast in PB

community

Broadcast

Filtering by BC

controller

Yes

Yes

No

No

“Mobile Participatory Web”

13

Broadcast Controller (1/2)

• XC-Controller

– An interface

• Allow users to select their favorite broadcast like a television or a radio

receiver

• Each broadcast is same as a program or channel to users

– Provide a snapshot for broadcasts to users

– Broadcast Messenger

• Share favorite ones through relay or re-broadcasting of “software tower”

• A talebearer

• Broadcasts outside of communities

– Senders freely broadcast data.

– Yet, receivers may want to filter them (through XC-Controller)

14

Broadcast Controller (2/2)

PB lists

Community lists

Orchestra (5)

Flea Marget (10)

DJCast (20)

MAS960 (18)

MediaGate

AndyTalk

Notices from Media Lab

LTF (32)

DavidStory

Collection

MediaGate

Paris Hillton.mpg

Reflection.mp3

Quiz1.pdf

DJCast (20)

MediaGate

Hi..

How are you?

Reflection

Let it be

Memory

Viralstones.mp3

Text

messenger

Video

messenger

(VidTorrent)

Voice

messenger

(FluidVoice)

What are seeds for personal broadcasts?

Medley

15

HowToControl

• Data Classification– Decide which data should be filtered

• Emergency data

• Non-emergency data (v)

– Emergency data

• Must be broadcast without a glitch.

• Identification should be required.

• Optionally, location information is helpful.

• Need to be got reach to local helpers such as police or 911 station.

• Relay or re-broadcasting (by towers)

– Non-emergency data

• Communities

• Queues

• Controllers: filter and share files 911CAST

SOS

16

HowToControl:

Personal Broadcast Community

• Why?– A Trust method

– The order of broadcasts

– Basement for Mobile Participatory Web

• Features– Temporarily established

– Freely join and leave

– A Queue

– Personal Broadcast Maps

– Relay and re-broadcasts among communities

– Open or closed community dependent on traits of group

17

HowToControl:


• Personal Broadcast Map

– A signaling message which shows a broadcast status of a

community

– Initiates and Ferret out a community

– Synchronize the status of queues within a community

Sender Members (in order of broadcast) No. of members

Community ID

Req. Q

SlotCurrent Q slot Queue slots (in order of broadcast)

Node information

Community info

Queue info

PB-MAP

- Nodes [Q5;Q1,Q2,Q3,Q4;5]

- Community ID [JukeBox]

- Queue [1;Q5;1,1,1,1,2]

Q5

Q4 Q3

Q1

Q2

Q1Q2Q3Q4Q5Q5

18

HowToControl:


• Creation of PB Community

a) Searching for PB nodes

PB-MAP

- Nodes [Qi;;]

- C-ID [JukeBox]

- Queue [;;]

Qd

Qc Qb

Qe

QaQi

PB-MAP

- Nodes [Qb;Qi;2]

- C-ID [JukeBox]

- Queue [;;]

PB-MAP

ACK

Q5

Q4 Q3

Q1

Q2

c) Update of PB-MAP

PB-MAP

- Nodes

[Q4;Q1(i), Q2(a), Q3(b),Q5(d);5]

- C-ID [JukeBox]

- Queue [1;;1,,,1,]

Qd

Qc Qb

Q1

Qa

PB-MAP

- Nodes [Q1 (i); Q2(a), Q3(b),Q4(c),Q5(d);5]

- C-ID [JukeBox]

- Queue [1;;]

b) Exchanges of an initial PB-MAP

19

HowToControl:


• Relay and Re-broadcasting

– Joint Station

• “A natural tower”

– By individuals (or, maybe, companies)

• A broadcast node has more than a community, and re-broadcasts

or relays data broadcast from a community to others.

• e.g., broadcasting routing

Q5

Q4 Q3

Q1

Qj

Q5

Q3

Q1

Q2Q5

Q4 Q3

Q1

Q2

PBC-A (branch) PBC-B

PBC-C (branch)

20

HowToControl:

Broadcast Queue

• Traits

– A collaborative queue temporarily created at each XCast station of a

community.

– One-by-one applications, non-urgent data.

– Decide the order of broadcasts.

– Fair Queuing (based on FIFO): “First Join First Broadcast”

– Priority of queuing according to members’ preferences.

SQ5

Q4 Q3

Q1

Q2

Concept of a Server-like Queue

Q1Q2Q3Q4Q5

First Join First broadcast,

but be serve by one-by-one.

Operation of Serverless Queues

21

HowToControl:

Broadcast Queue

• Update rules

– Queuing: Whenever a station places a file in its queue

– Sending: Whenever receiving broadcast data

– Joining: Whenever a new station joins in a community

– Leaving: Whenever a station leaves at a community

Q1

Q2

Qn

…

Q1Q2Q3Q4Q5

22

HowToControl:

Broadcast Queue

• Update rules: Queuing

– Whenever a file is placed in a queue, all queues are updated by

exchange of the station’s PB-MAP.

PB-MAP

- Nodes [Q5;Q1,Q2,Q3,Q4;5]


- Queue [1;Q1;1,1,1,1,2]

Q5

Q4 Q3

Q1

Q2

Queue Update: When a file is placed at the

queue, PB-MAP is sent to other stations

Q1Q2Q3Q4Q5Q5

Q5

Q4 Q3

Q1

Q2

Queue Update: the remaining stations also

broadcast the PB-MAP after updating it

23

HowToControl:

Broadcast Queue

• Update rules: Sending

– Whenever receiving broadcast data, all queues are updated by

exchange of the station’s PB-MAP.

Q5

Q4 Q3

Q1

Q2

Q5

Q4 Q3

Q1

Q2

Q2Q3Q4Q5

Q3Q4Q5

When receiving Q1 data, Q1 slot is

removed in the queue.

When receiving Q2 data, Q2 slot is

removed in the queue.

Q5

Q5PB-MAP

- Nodes [Q3;Q1,Q2,Q3,Q4;5]


- Queue [;Q1;(),1,1,1,2]

Q5

Q4 Q3

Q1

Q2

PB-MAP header

- Nodes [Q1;Q1,Q2,Q3,Q4;5]


- Queue [;Q1;(),1,1,1,2]

24

HowToControl:

Broadcast Queue

• Update rules: Joining

– Search and join in a community through PB-MAP.

PB-MAP

- Nodes [Q2;Q1,Q3,Q4,Q5;5]


Qa

Q5

Q4 Q3

Q1

Q2 Q5

Q4 Q3

Q1

Q2

Searching for

a community

PBC: Juke Box PBC: anonymityRequestACK

Q5

Q4

Q3

Q1

Q2

Q6

Q4Q5Q1Q2Q3Q4Q5

PB-MAP

- Nodes

[Q6;Q1,Q2,Q3,Q4,Q5;6]

- C-ID [JukeBox]

- Queue [1;;]

Q4Q5Q1Q2Q3Q6 Q4Q5

Q5

Q4

Q3

Q1

Q2Q6

PB-MAP

- Nodes

[Q3;Q1,Q2,Q4,Q5,Q6;6]

- C-ID [JukeBox]

- Queue

[;Q4;1,1,1,2,2,1]

25

HowToControl:

Broadcast Queue

• Update rules: Leaving

– Notify leaving from the community and afterward re-arrange

station IDs.

Q1

Q5 Q4

Q2

Q3

Q1Q2Q5 Q3Q4

Q5

Q4

Q3

Q1

Q2Q6

Q5Q1Q2Q3Q6 Q4Q5

PB-MAP

- Nodes

[Q2;Q1,Q3,Q4,Q5,Q6;6]


- Queue [-1;Q5;1,,1,1,2,1]

Qa

Q5Q1Q3Q6 Q4Q5

Q2

Q2

Q1

Q6 Q5

Q3

Q4

PB-MAP

- Nodes [Q4;Q1,Q3,Q5,Q6;5]


- Queue [;Q5;1,1,1,2,1]

26

Future Work: IVY Networks

• Keywords for future– “Personal”

• From Web 2.0 concepts

• Wikipedia, Youtube, etc.

– “Local Core”: interactive

• IVY Networks– Ivy expands its (living) area by connecting one stem to another.A stem seeks adequate habitat via communication with others according to its biological needs and the environment, and networks with nearby stems to help them reach their destination.

– Local core grass-roots networks

– Personalized mobile networks

– Based on “Graspable Tower” concepts

27

IVY Networks

Local Core Networks

XCast

Mobile Participatory Web:

personal DB

Mobile

Ad-hoc/Mesh

Networks

• A chain of personalized infrastructure-free networks

– Movement of finance from Core to Local

28

Graspable Tower

• What is Graspable Tower?

– An ad-hoc tower

• all mobile devices, which people carry daily, are capable of serving as a tower whenever routing or relay of data packets is required, and a novel logical ad-hoc cell consisting of a cluster of physical radio cells is built around such a tower node.

– Motives:

• From goals of Viral Communications Group

• How to handover stations in ad-hoc modes.

• How wide areas can ad-hoc stations cover cooperatively?

• Can an ad-hoc station be a tower?

• Can we make cells in ad-hoc network like infrastructure?

– Cell coverage– WiFi coverage = (physical) cell coverage = Pico cell

– Logical cell coverage? Several PB communities.Graspable Tower

29

Graspable Tower (1/4)

T

T

T

T911Cast

• Towers

– Stations which have more than a community.

• Keep connections with other towers within different communities.

– Cooperative, mobile (nomadic, or stand), personalized.

• Enable a handover like infrastructure base stations.

• Initially, Support for Software Towers rather than hardware ones.

– Rule: OTPC (at least, One Tower Per Community)

• Outside of communities

– Automatically radiated

30


T

T

T

T

• Communities

– Tower Stations may be attractive to other stations because of

their extended logical radiation.

• Ferret out towers, further spread data

• Most stations try to be Tower stations.

– Handover through Tower stations

31

Graspable Tower(3/4)

T

T

T

T

T T

• How to decide Graspable Tower– Should at least have more than a different community

– Community = Cell = WIFI radio coverage• Size of cells dependent on that of community.

– Display how many there are towers within a community.• Towers are shown based on your station location.

– Why are cooperative towers?• Tower-based routing

MIT

Harvard

32


• Issues– Tower-based routing vs. ad-hoc routing

• Queuing -> scheduling (mobile/wireless routers)

• Radio coverage != transmission coverage

– MAC/PHY modifications• Ad-hoc station + ad-hoc base station (?)

– Two modes: managed + ad-hoc• Simultaneously two connections

• Inter-connection??

Tower

33

Plan

• Development of mobile interactive participatory Web:

– This is controlled by the ECP, Broadcasting Queue.

– A conceptual demo for it was shown during the last open house

– Its initial version will be installed on OLPC by a mid of October, 2007.

• XC MAC

– Requirements and functions will be defined and elaborated by the end

of August, 2007.

– We will develop a novel broadcast MAC prototype on Mad WiFi driver

and GNU radio platform by the beginning of May, 2008.

• Graspable Tower

– Development of Graspable Tower: This is about creating a new local

personal network.

– The detailed functions and frameworks for it are incubating.

34

Abstract

• Problems– Issues on FluidVoice

• Uncontrollable: Various, continuous, temporary spam broadcasts.

• Non-wireless guy: CDMA/CA causes broadcast data to be dropped.

– Ad-hoc transmission coverage limit• The existing routing mechanisms have not resolved it.

• No mechanism to control ad-hoc cells

• Main goals– Broadcast messenger (GUI)

• Spam filtering (voice, text, video), the order of broadcasts

• Data classifications, community,

• Make MIT community use it

– Software Tower• Mobile, nomadic, or still towers (on stations)

• Generating logical cells,

• Fast retransmission, or re-broadcasting through “tower-based routing”

• Enabling “handover”

xcast: controllable, movable, personalized...

Documents