2012_1_e22be68f

Upload: anupamj4u

Post on 04-Jun-2018

219 views

Category:

Documents


0 download

TRANSCRIPT

  • 8/13/2019 2012_1_e22be68f

    1/31

    Broadcasting in VANET

    Speaker: Lin-You Wu

  • 8/13/2019 2012_1_e22be68f

    2/31

    Outline

    1. Introduction

    2. Different Regimes for Broadcasting in VANET

    3. Distributed Vehicular Broadcast (DV-CAST)protocol

    4. Conclusions

  • 8/13/2019 2012_1_e22be68f

    3/31

    1. Introduction(1/2)

    Broadcasting in vehicular ad hoc networks

    (VANET) is emerging as a critical area of

    research.

    This problem is the confinement of the

    routing problem to vehicle-to-vehicle (V2V)

    scenarios as opposed to also utilizing the

    wireless infrastructure.

  • 8/13/2019 2012_1_e22be68f

    4/31

    1. Introduction(2/2)

    We report the first comprehensive study on

    the subject whereby the extreme traffic

    situations such as dense traffic density, sparse

    traffic density, and low market penetration of

    cars using DSRCtechnology are specifically

    taken into account.

  • 8/13/2019 2012_1_e22be68f

    5/31

    DSRC

    DSRC

    5.9GHz DSRCMACPHYIEEE802.11p.

    802.11pIEEE2003802.11aWAVE(Wireless Access in the

    Vehicular Environment)DSRC

  • 8/13/2019 2012_1_e22be68f

    6/31

    2. Different Regimes for Broadcasting

    in VANET

    Our previous research has identified three

    different regimes of operation in VANET:

    A. Dense Traffic Regime;

    B. Sparse Traffic Regime;

    C. Regular Traffic Regime.

  • 8/13/2019 2012_1_e22be68f

    7/31

    A. Dense Traffic Regime

    When the traffic density is above a certainvalue, one of the most serious problems is thechoking of the shared medium by an excessive

    number of the same safety broadcast messageby several consecutive cars.

    Because of the shared wireless medium,blindly broadcasting the packets may lead tofrequent contention and collisions intransmission among neighboring nodes.

  • 8/13/2019 2012_1_e22be68f

    8/31

    Referred to as broadcast storm problem[1].

    In [1], we (i) explore how serious the

    broadcast storm is in VANET using a case study

    for a four-lane highway scenario;

    and (ii) propose three light-weight broadcast

    techniques; i.e., weighted p-persistence,

    slotted 1-persistence, and slotted p-

    persistence,

  • 8/13/2019 2012_1_e22be68f

    9/31

  • 8/13/2019 2012_1_e22be68f

    10/31

    The basic broadcast techniques follow either a

    1-persistence or a p-persistence rule.

    Gossip-based approach, on the other hand,

    follows the p-persistence rule which requires

    that each node re-forwards with a pre-

    determined probabilityp. This approach is

    sometimes referred to as probabilistic flooding

  • 8/13/2019 2012_1_e22be68f

    11/31

  • 8/13/2019 2012_1_e22be68f

    12/31

  • 8/13/2019 2012_1_e22be68f

    13/31

  • 8/13/2019 2012_1_e22be68f

    14/31

    To make the situation worse, there might be

    no cars within the transmission range of the

    source in the opposite lane either, see Figure

    3(c). Under such circumstances, routing and

    broadcasting becomes a challenging task.

  • 8/13/2019 2012_1_e22be68f

    15/31

    We propose to cope with such extreme cases

    via the so-called store-carry-forward

    mechanism.

    Our results show that depending on the

    sparsity of vehicles or the market penetration

    rate of cars using Dedicated Short Range

    Communication (DSRC) technology.

  • 8/13/2019 2012_1_e22be68f

    16/31

    C. Regular Traffic Regime

    For both sparse and dense traffic scenarios

    previously considered, a vehicle in a dense

    network is likely to observe a dense local

    topology while vehicles in a sparse networkare likely to have zero or only a few neighbors

    or observe a sparse local topology.

  • 8/13/2019 2012_1_e22be68f

    17/31

    3. Distributed Vehicular Broadcast

    (DV-CAST) protocol

    A. Design Goal

    B. Design Principle C. DV-CAST Protocol

  • 8/13/2019 2012_1_e22be68f

    18/31

    A .Design Goal

    A broadcast protocol for vehicular ad hoc

    wireless networks should be reliable, robust,

    and bandwidth efficient.

    More specifically, the protocol should be able

    to distribute broadcast information to all

    intended recipients of the message.

  • 8/13/2019 2012_1_e22be68f

    19/31

    B. Design Principle

    We propose to use a per-hop routing based

    approach which uses only local connectivity

    information (1-hop neighbor topology) to

    make a routing decision.

    The motivation for using local connectivity in

    the broadcast protocol design is to ensure the

    maximum reachability of the broadcastmessage.

  • 8/13/2019 2012_1_e22be68f

    20/31

    C. DV-CAST Protocol

    We propose a new Distributed Vehicular

    Broadcast protocol known as the DV-CAST

    protocol that is entirely based on the local

    information established by each node (car) viathe use of periodic hello messages.

  • 8/13/2019 2012_1_e22be68f

    21/31

    1) Routing Parameters: The most importantparameters for DV-CAST protocol are the local

    topology information and the Region ofInterest.

    In particular, each vehicle should be able to

    (i) determine whether it is the intendedrecipient of the message that is moving in thesame direction as the source.

    (ii) determine whether it is the last vehicle in the

    group/cluster.

    (iii) determine whether it is connected to atleast one vehicle in the opposite direction.

  • 8/13/2019 2012_1_e22be68f

    22/31

    These three parameters are denoted in this

    paper as Destination Flag (DFlg), Message

    Direction Connectivity (MDC), and Opposite

    Direction Connectivity (ODC), respectively.

    2) Routing Rules: In order to handle the

    broadcast message properly, we propose that

    each vehicle follows two basic routing rules:

  • 8/13/2019 2012_1_e22be68f

    23/31

    i) If DFlg is set to 1, vehicle should ignore any

    duplicate broadcast or follow the diagram in

    Figure 5 if the message is received for the first

    time.

    ii) If DFlg is set to 0, vehicle is a relay node and

    should follow the routing diagram.

  • 8/13/2019 2012_1_e22be68f

    24/31

    Decision Tree for DV-CAST Protocol (ODN = Opposite Direction Neighbor).

  • 8/13/2019 2012_1_e22be68f

    25/31

    Case I: Well-Connected Neighborhood

    A vehicle is said to be in well-connected

    neighborhood if it has at least one neighbor in

    the message forwarding direction (MDC = 1).

  • 8/13/2019 2012_1_e22be68f

    26/31

    According to Figure 6, each vehicle in Group 1,

    except forA which is the last vehicle in the

    cluster (MDC = 0), upon receiving the

    broadcast message from S, will have thefollowing flags .

    Vehicles in Group 3 except for B will also have

    similar flags, i.e., .

  • 8/13/2019 2012_1_e22be68f

    27/31

    Case II: Sparsely-Connected

    Neighborhood

    A vehicle is operating in a sparse traffic regime

    if it is the last one in a cluster.

    Furthermore, a vehicle in this regime is said to

    be in a sparsely-connected neighborhood if

    there is at least one neighbor in the opposite

    direction as in the case of vehiclesA and B in

    Figure 7.

  • 8/13/2019 2012_1_e22be68f

    28/31

    The parameters for these

    vehicle should be set to .

  • 8/13/2019 2012_1_e22be68f

    29/31

    Case III: Totally Disconnected

    Neighborhood

    A vehicle, operating in a sparse traffic regime,

    is said to be in a totally disconnected

    neighborhood if it has no neighbor in the

    message forwarding direction and is notconnected to anybody in the opposite

    direction, i.e., MDC = ODC = 0.

  • 8/13/2019 2012_1_e22be68f

    30/31

    4. Conclusions

    we have proposed a new Distributed VehicularBroadcasting protocol (DV-CAST) design forsafety and transport efficiency applications in

    VANET.

    The proposed DV-CAST protocol is fully

    distributed and relies on the local informationprovided by one-hop neighbors via periodichello messages.

  • 8/13/2019 2012_1_e22be68f

    31/31

    END