Tree-Based Double-Covered Broadcast for Wireless Ad Hoc Networks Weisheng Si, Roksana Boreli Anirban...

Tree-Based Double-Covered Broadcast for

Wireless Ad Hoc Networks

Weisheng Si, Roksana BoreliAnirban Mahanti, Albert Zomaya

2NICTA Copyright 2010 From imagination to impact

Outline

• Introduction

• Related Work

• Our Main Ideas

• Tree-Based Double-Covered Broadcast (TreeDCB)

• Evaluation

• Conclusions and Future Work


Introduction

• Smartphones with WiFi interfaces are becoming popular, enabling the formation of ad hoc networks in a crowd (e.g., in a stadium or concert event).

• Typical applications in such ad hoc networks are the broadcast of multimedia streams and contents among the smartphones.


Introduction (cont’d)

A key component for these broadcast applications is a broadcast routing protocol.


Introduction (cont’d)

• Most of the existing protocols let their nodes maintain k-hop (k ≥ 2) neighborhood information. To realize this, a node needs to include the (k-1)-hop information in its periodical Hello packets.

• In the crowd scenario where each node has many neighbors, Hello packets become considerably long.

• This paper proposes a broadcast routing protocol that uses fixed length Hello packets.


Our Main Ideas

• TreeDCB uses the basic shortest path tree technique to build a spanning tree with source node as the root– The Hello packets in TreeDCB only carry a constant

amount of information

• When a node selects its parent, the neighbor that has the greatest number of children is chosen– This reduces the number of parents in the tree.

• A non-parent node volunteers to be a forwarding node if it hears no forwarding nodes from its upstream and sibling nodes other than its parent– This ensures double coverage


Our Main Ideas (cont’d)

• Fixed-length Hello packets are desired• The number of broadcasting nodes should be

kept small• The broadcast redundancy can be highly utilized

Though our ideas are simple, they suit the characteristics of dense wireless networks:


Related Work

• Most of the existing protocols with k-hop (k ≥ 2) neighborhood information are based on the concept of connected dominating set (CDS).

• For a graph G(V, E), a CDS is a subset of V, such that – The nodes in this subset are connected– Each node in V is either in this subset or

connected to at least one node in this subset• The basic idea of these protocols is to find a CDS

among all the nodes and only let the nodes in CDS broadcast.– The number of broadcasting nodes is reduced.– A packet can still reach every node in the network.


Related Work (cont’d)

• Among those CDS-based protoocls, the Double Covered Broadcast (DCB) protocol inspires our work

• In DCB, when a node v forwards a packet, it selects a subset of its 1-hop neighbors as the forwarding nodes with the constraints that– The selected forwarding nodes cover all the 2-hop

neighbors of node v– The 1-hop neighbors of node v are either selected as

forwarding nodes or covered by at least two forwarding nodes (e.g., once by node v itself and once by one of the selected forwarding nodes)

– The number of forwarding nodes is minimized


Differences between DCB and TreeDCB

DCB TreeDCB

Each node includes its 1-hop neighbor list to its Hello packets, so the Hello packets can be very long

Each node only includes constant amount information in the Hello packets

A node attaches the IDs of its selected forwarding nodes to every data packet it forwards, which increases the control overhead

A node decides whether is a forwarding node by its own, adding no control overhead to a data packet

Any node can be the source node

A single source node is assumed to lower the control overhead


Tree-based Double-Covered Broadcast (TreeDCB)

• Roles of a node

• Hello packet format

• Protocol description

• Some discussions on TreeDCB


Roles of a node

• Parent node: a node that has children in the current tree topology. A parent serves as a forwarding node.

• Volunteer node: a node that has no children in the current tree topology but volunteers to be a forwarding node.

• Leaf node: a node that has no children in the current tree topology and is not a volunteer node.


Hello Packet Format

• Src-ID: the ID of the source node, which indicates the root of the tree.

• Self-ID: the ID of the sender. • Cost: the shortest path length (in number of hops) from the

source to the sender.• Num-Children: if this field is larger than 0, it indicates the

sender is a parent node and it gives the number of children that the sender has. If this field equals 0, it indicates the sender is a leaf node. If this field equals -1, it indicates the sender is a volunteer node.

• Parent-ID: The ID of the sender’s parent node in the current SPT.

Src-ID Parent-ID Num-ChildrenSelf-ID Cost


Protocol description

• Each node periodically broadcasts Hello packets to its 1-hop neighbors.

• During the exchange of Hello packets with its neighbors, a node updates the Cost, Num-Children, and Parent-ID fields in its own Hello packet.


Protocol description (cont’d)

The updating rules are as follows.• Cost: The source node always sets its Cost

value to 0. A non-source node sets its Cost to minCost + 1.– minCost is the smallest Cost value in the Hello

packets it receives.• Num-Children: A node v counts how many

neighbors send Hello packets carrying the ID of node v in their Parent-ID fields.

• Parent-ID: A node selects its parent by checking which neighbor has the least Cost value. – If several neighbors have the same least Cost value,

the tie is broken by first favoring a larger Num-Children value and then by a larger Self-ID.



• If node v is a parent node, it serves as a forwarding node.

• Else, v decides whether to be a volunteer node by examining its neighbors with Costs less than or equal to v’s.– If there are more than one parent nodes among these

neighbors, v knows that it is covered at least twice and will not volunteer.

– Otherwise, if there is another volunteer neighbor with its ID larger than v’s, v will not volunteer either.

– Node v only volunteers when it hears no volunteer node with ID larger than v’s, thus avoiding duplicate volunteer nodes.

Determine whether to be a forwarding node:


Some discussions on TreeDCB (1)

• Assuming a single source enables low communication and computation overhead, but causes that the established tree is only optimized for this single source in terms of path length.

• When additional sources exist, the tree built for the given source can still be used to forward packets for other sources, since this tree is a spanning tree.

• If minimizing the path length is a primary goal of applications, building multiple trees for multiple sources is an alternative.


Some discussions on TreeDCB (2)

• In building the tree, the time when a node finds out its Cost (number of hops) is affected by the Cost itself and the period of sending Hello packets.

• In our implementation, we apply the optimization technique that when a node sees a smaller Cost, it sends its Hello immediately instead of waiting until the next Hello period, thus the tree can be established much faster.

• So the convergence will not be a problem for TreeDCB.


Evaluation

• Experiment setup• Ratio of forwarding nodes• Amount of control traffic• Packet delivery ratio• Average path length of a packet

We implemented TreeDCB in ns-2. For comparison, we also implemented DCB. We made our source codes available to the public at http://sourceforge.net/projects/tdcb


Experiment Setup

• MAC layer protocol: the IEEE 802.11.• Physical layer propagation: the Two Ray Ground

model.• Node mobility: the random waypoint (RWP)

model.• We place nodes in a square area with a uniform

distribution. • The transmission range of all nodes is set to be

250m. Since all nodes have identical transmission range, the resulting network topology is a unit disk graph (UDG).


Experiment Setup (cont’d)

• To offer an idea about the node connectivity at different node densities, we measured the average node degrees of the UDGs obtained at the transmission rage of 250m.

Node density Average node degree

50 8.49

100 15.6

150 22.06

200 28.55

250 33.73

300 38.41


Experiment Setup (cont’d)• We consider the impact of mobility level, node density, number of

nodes, and source packet rate.• To evaluate the impact of one parameter, we vary the value of this

parameter and use the default values for the other parameters.

Number of node in the network 100

Maximal node speed in RWP model 2.8m/s

Node Density 150 nodes/km2

Bandwidth 2Mbps

CBR Source Packet Rate 40 pkts/s

Data Packet Length 200 bytes

Period of sending Hello packet 0.5s

Simulation Time 150s

Confidence Interval 95%

Number of Trials 50


Ratio of forwarding nodes

The ratio of forwarding nodes is defined as the number of nodes doing the broadcast divided by the total number of nodes in the network.

0

0.1

0.2

0.3

0.4

50 100 150 200 250 300

Node density (per square km)

Ra

tio o

f fo

rwa

rdin

g n

od

es TreeDCB DCB

The ratio of forwarding nodes at different node densities.


Ratio of forwarding nodes (cont’d)

The ratio of forwarding nodes at different mobility levels.

00.05

0.10.15

0.20.25

0.3

static 2.8 20 40 80 160

Maximal node speed (in m/s)

Ra

tio o

f fo

rwa

rdin

g

no

de

s

TreeDCB DCB


The amount of control traffic

The Hello packet lengths at different node densities.

050

100150200250300350

50 100 150 200 250 300


Con

trol

traf

fic p

er n

ode

per

Hel

lo p

erio

d (

in b

ytes

)

TreeDCB DCB


Packet delivery ratio

The packet delivery ratio is defined as the ratio of the total number of packets received by all nodes versus the total number of packets to be received by all nodes.

0.85

0.88

0.91

0.94

0.97

1

50 100 150 200 250 300


Pa

cke

t de

live

ry r

atio

TreeDCB DCB

Packet delivery ratio at different node densities.


Packet delivery ratio (cont’d)

Packet delivery ratio with different number of nodes.

0.8

0.85

0.9

0.95

1

25 50 75 100 125 150 175 200

Number of nodes in a network

Pa

cke

t de

live

ry r

atio

TreeDCB DCB


Average path length of a packet

The average path length of a packet is defined as the average length of all the paths that this packet traverses to reach all the nodes in a network.

01234567

50 100 150 200 250 300


Avg

pa

th le

ng

th (

#h

op

s)

TreeDCB DCB

Average path length of a packet at different node densities.


Average path length of a packet (cont’d)

Packet path lengths with different number of nodes.

0

1

2

3

4

5

6

25 50 75 100 125 150 175 200

Number of nodes in the network

Avg

pa

th le

ng

th (

#h

op

s)

TreeDCB DCB


Conclusions

• TreeDCB uses fixed-length Hello packets and guarantees that each node v is either a forwarding node or covered by at least two forwarding nodes.

• Based on the basic technique of shortest path tree building, TreeDCB introduces two new techniques to improve the selection of forwarding nodes:– It selects parent nodes in the tree by examining which

one has the greatest number of children, thus significantly reducing the number of parent nodes.

– A leaf node will volunteer to be a forwarding node if it hears no forwarding nodes other than its parent, thus ensuring double coverage for non-forwarding nodes.


Thank you!

Questions and Comments?

Tree-Based Double-Covered Broadcast for Wireless Ad Hoc Networks Weisheng Si, Roksana Boreli Anirban...

Documents

Transcript of Tree-Based Double-Covered Broadcast for Wireless Ad Hoc Networks Weisheng Si, Roksana Boreli Anirban...