Virtual infrastructure for collision prone wireless networks
Sponsored Links
This presentation is the property of its rightful owner.
1 / 49

Virtual Infrastructure for Collision-Prone Wireless Networks PowerPoint PPT Presentation


  • 90 Views
  • Uploaded on
  • Presentation posted in: General

Virtual Infrastructure for Collision-Prone Wireless Networks. Seth Gilbert Gregory Chockler Nancy Lynch. Wireless Ad Hoc Networks. Unreliable communication Contention Collisions Noise Lost messages. Unknown Availability Fault-prone devices

Download Presentation

Virtual Infrastructure for Collision-Prone Wireless Networks

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Virtual Infrastructure for Collision-Prone Wireless Networks

Seth Gilbert

Gregory Chockler Nancy Lynch


Wireless Ad Hoc Networks


Unreliable communication

Contention

Collisions

Noise

Lost messages

Unknown Availability

Fault-prone devices

Ad hoc deployments

Unknown topology

Unknown participants

Mobility

Dynamic joining/leaving

Wireless Ad Hoc Networks


Fixed Infrastructure

For Example:

Simplifies wireless networks:

Communication

  • Avoids contention and collisions

    Unknown availability

  • Reliable overlay

  • Known topology

    Mobility

  • Fixed and predictable

cell towers

base stations

servers


Virtual Infrastructure


Today’s Topics

  • Introduction

  • Modeling

  • Emulating a virtual node:

    • Convergent History Agreement

  • Emulating virtual infrastructure


Wireless Networks

  • Mobile nodes

    • Crash failures

    • Location updates

  • Unreliable wireless broadcast

    • Synchronous

    • Collision detection

    • Contention manager


Wireless Networks

  • Broadcast: within some radius R.

  • Interference: up to some radius R’.

R’

R


Wireless Networks

  • Eventually, if only one nearby node broadcasts in a round, then its message will be delivered.


Wireless Networks

Bob either:

  • Gets both messages

    or

  • Detects a collision

Bob

Collin

Alice

CD

A-C: complete, eventually accurate:

  • Detect if any message is lost.

  • Eventually no false positives (after stabilization).


Collision-Prone Network

  • Eventually reduces contention/collisions

    Example: backoff protocol

  • Advice only: nodes can ignore.

  • Eventually, if only 1 node broadcasts, then no collisions (after “stabilization”).

Each node contends when it wants to broadcast.

Each contention manager outputs advice:

  • active: it is safe for the mobile node to broadcast

  • passive: the mobile node should not broadcast.


Wireless Networks

Eventually non-interfering:

  • Eventually, nearby nodes are not advised to be active.

    Eventually regionally fair:

  • Eventually, if:

    • Only nearby nodes contend.

    • Any non-failed node contends for sufficiently long.

  • Then:

    • Somenon-failed, contending node is advised to be active for sufficiently long.


Wireless Networks

  • Mobile nodes

    • Crash failures

    • Location updates

  • Unreliable wireless broadcast

    • Synchronous

    • Collision detection

    • Contention manager


Today’s Topics

  • Introduction

  • Modeling

  • Emulating a virtual node:

    • Basic Idea

    • Convergent History Agreement (CHA)

    • CHA Protocol

  • Emulating virtual infrastructure


Building Virtual Infrastructure


Building Virtual Infrastructure


Building Virtual Infrastructure

Leader / backup

Leader sends & receives messages for the virtual node

Each participant is a replica.

Replicas execute a consistency protocol


Consistency: First Attempt

  • For each virtual round:

    • Run consensus.

    • Replicas agree on:

      • Messages for virtual node to receive.

      • Message for virtual node to send.

      • State update.

    • Update state.

    • Leader sends message for virtual node.


First Attempt

Problems:

  • Consensus does not terminate until collisions stop.

    • Virtual rounds are non-constant sized

    • Rounds are unsynchronized!

  • Virtual nodes do not detect collisions

    • Delay until collisions stop.


Goals

  • Can communicate with both real and virtual nodes.

  • Detect collisions when a message is lost.

  • Emulation of virtual nodes is transparent.

  • Rounds are synchronized

  • Rounds are constant length

  • In each round, replicas have a consistent view

  • Constant-sized messages


Convergent History Agreement

  • Sequence of instances:

  • For each instance k:

    • Each node proposes an input.

    • Each node receives a history output h, or .

CHA

k4

h1

propose(x)

h2

propose(y)

propose(z)

CHA

k7

CHA

k5

CHA

k3

CHA

k2

CHA

k6

CHA

k1

CHA

k4


Convergent History Agreement

  • A history is a sequence of proposals, one per instance, e.g.:

    Validity: Each history contains only real proposals.

    Agreement: Every pair of histories shares a common prefix of proposals/non-proposals.

    Liveness: Eventually, every instance outputs histories, and every element in the history is a proposal.

CHA

k7

CHA

k5

CHA

k3

CHA

k2

CHA

k6

CHA

k1

CHA

k4


Emulating a Virtual Round

  • Determine proposals.

    • Mobile nodes broadcast their messages for the virtual round.

    • Calculate virtual node’s broadcast message, using most recent history, extended by collisions.

  • Execute convergent history agreement (CHA).

  • If CHA outputs a history, then:

    • Simulate receiving virtual node’s broadcast.

  • Otherwise:

    • Report a collisions.


CHA Protocol

Each client begins with a proposal for the current instance.

Round 1: [Ballot]

  • Ifadvice=activethenbroadcast(ballot)

    Round 2: [Veto-1]

  • If“collision”thenbroadcast(veto)

    Round 3: [Veto-2]

  • If“collision”thenbroadcast(veto)

  • Update state


Ballot

Veto 1

Veto 2

Result

green

yellow

orange

red

Update State

Accept

Reject


Ballot

Veto 1

Veto 2

Result

green

yellow

orange

red

Update State

Accept

Tentative Accept

Tentative Reject

Reject


Ballot

Veto 1

Veto 2

Result

green

yellow

orange

red

Update State

ballot={proposal, last green/yellow round}

Accept

Tentative Accept

Tentative Reject

Reject


Ballot history

  • Reconstructing the history

    Example:


Ballot history

  • Reconstructing the history

    Example:


Ballot history

  • Reconstructing the history

    Example:


Ballot history

  • Reconstructing the history

    Example:


Ballot history

  • Reconstructing the history

    Example:

History:

1. propose(P)

2. propose(O)

3. propose(D)

4. propose(C)

=> PODC


CHAP Output

  • If round is green:

    • Output history.

    • Include proposal where indicated, otherwise.

  • Else if round is not green:

    • Output .


Analysis: Key Idea (1)

  • If some instance is green, then all accept that instance’s ballot.

    • All histories agree on the same execution.

    • If a history is output for some instance, then all replicas receive the proposal for that instance.

  • If a ballot is red, then all the replicas reject it.

    • If a proposal is not received, then no history outputs it.

The color at any two replicas differs by at most one shade.


Analysis: Key Idea (2)

  • When the underlying network is well-behaved, then there are no vetos.

  • Used to prove that the virtual node satisfies:

    • Eventual collision freedom.

    • Eventual accuracy of the collision detector.

    • Contention manager eventually well-behaved.

After the network, collision detector, and contention manager stabilize:

Eventually, every round is green.


Today’s Topics

  • Introduction

  • Modeling

  • Emulating a virtual node:

    • Convergent History Agreement

  • Emulating virtual infrastructure


Virtual Infrastructure

Problems:

  • Virtual nodes communicate with each other.

    • Sender adds message to send to proposal.

    • Receiver adds messages to receive to proposal.

    • Both run agreement.

    • If sender-agreement fails, then receiver cannot receive the message.

    • Too late!!

  • Virtual node emulators may interfere with each other.

    • Contention managers are insufficient.


Virtual Infrastructure

  • Choose a schedule for all the virtual nodes:

    • Non-conflicting: no neighboring virtual nodes scheduled at the same time.

    • Fair: every virtual node is scheduled.

  • Use schedule to avoid contention in the emulation.

    ** Not sufficient to emulate each virtual node according to the schedule, since virtual nodes communicate.


Virtual Infrastructure

Four part protocol:

  • Data phases:

    • Client phase: clients broadcast messages to vns, each other.

    • VN phase: representative emulator sends msg for vn.

  • Scheduled Agreement Instance

    • Scheduled virtual nodes run the 3 phase agreement protocol, all at once.

  • Unscheduled Agreement Instance

    • Unscheduled virtual nodes run the 3 phase agreement protocol.

    • Lasts for s +2 rounds, where s is the size of the schedule.

  • Join + Reset phases.


Virtual Infrastructure

  • Bounded round emulation

    • 10 + (size of schedule)

  • Constant overhead

    • After stabilization, constant message overhead.

    • Can be optimized further.


Ongoing and Future Work


Ongoing and Future Work

  • Optimization

    • Smaller messages

    • Less redundant communication

    • Shorter virtual rounds

  • Implementation aspects

    • Collision detectors

    • Contention managers

    • Synchronization


Ongoing and Future Work

  • Coordination Problems

    • Traffic Coordination

    • Air traffic control

    • Rescue worker / military scenarios

  • Control Problems

    • Actuated sensors

    • Real-time applications

  • Mobile Sensors

    • Floating / submergible devices

    • Zebranet-like scenarios


Ongoing and Future Work

  • Malicious Devices

    • Can we emulate virtual infrastructure in the presence of non-cooperative mobile nodes?

    • Can we keep the state of the system secret from the participants?

    • Cryptography

    • Frequency hopping


Ongoing and Future Work

  • Energy Efficiency

    • How efficiently can we implement virtual infrastructure?

    • Mobile nodes share the work of implementing the virtual nodes.

    • More efficient replication via coding theory techniques?


Summary

Virtual Infrastructure

  • Simple abstraction for dependable ad hoc networks

  • Convergent History Agreement

  • CHA Protocol / VI Emulation

    • Collision detectors, contention managers

    • Efficient: constant overhead, constant time


The End


The End


  • Login