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

Virtual Infrastructure for Collision-Prone Wireless Networks PowerPoint PPT Presentation


  • 84 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

Virtual Infrastructure for Collision-Prone Wireless Networks

Seth Gilbert

Gregory Chockler Nancy Lynch


Wireless ad hoc networks

Wireless Ad Hoc Networks


Wireless ad hoc networks1

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

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

Virtual Infrastructure


Today s topics

Today’s Topics

  • Introduction

  • Modeling

  • Emulating a virtual node:

    • Convergent History Agreement

  • Emulating virtual infrastructure


Wireless networks

Wireless Networks

  • Mobile nodes

    • Crash failures

    • Location updates

  • Unreliable wireless broadcast

    • Synchronous

    • Collision detection

    • Contention manager


Wireless networks1

Wireless Networks

  • Broadcast: within some radius R.

  • Interference: up to some radius R’.

R’

R


Wireless networks2

Wireless Networks

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


Wireless networks3

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

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.


Virtual infrastructure for collision prone wireless networks

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 networks4

Wireless Networks

  • Mobile nodes

    • Crash failures

    • Location updates

  • Unreliable wireless broadcast

    • Synchronous

    • Collision detection

    • Contention manager


Today s topics1

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 infrastructure1

Building Virtual Infrastructure


Building virtual infrastructure2

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

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

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

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

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 agreement1

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

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

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


Update state

Ballot

Veto 1

Veto 2

Result

green

yellow

orange

red

Update State

Accept

Reject


Update state1

Ballot

Veto 1

Veto 2

Result

green

yellow

orange

red

Update State

Accept

Tentative Accept

Tentative Reject

Reject


Update state2

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

Ballot history

  • Reconstructing the history

    Example:


Ballot history1

Ballot history

  • Reconstructing the history

    Example:


Ballot history2

Ballot history

  • Reconstructing the history

    Example:


Ballot history3

Ballot history

  • Reconstructing the history

    Example:


Ballot history4

Ballot history

  • Reconstructing the history

    Example:

History:

1. propose(P)

2. propose(O)

3. propose(D)

4. propose(C)

=> PODC


Chap output

CHAP Output

  • If round is green:

    • Output history.

    • Include proposal where indicated, otherwise.

  • Else if round is not green:

    • Output .


Analysis key idea 1

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

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 topics2

Today’s Topics

  • Introduction

  • Modeling

  • Emulating a virtual node:

    • Convergent History Agreement

  • Emulating virtual infrastructure


Virtual infrastructure1

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 infrastructure2

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 infrastructure3

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 infrastructure4

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


Ongoing and future work1

Ongoing and Future Work

  • Optimization

    • Smaller messages

    • Less redundant communication

    • Shorter virtual rounds

  • Implementation aspects

    • Collision detectors

    • Contention managers

    • Synchronization


Ongoing and future work2

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 work3

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 work4

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

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


The end1

The End


  • Login