Tree-Based Double-Covered Broadcast for Wireless Ad Hoc Networks

1. Tree-Based Double-Covered Broadcast for Wireless Ad Hoc Networks Weisheng Si, Roksana BoreliAnirban Mahanti, Albert Zomaya

2. Introduction • Related Work • Our Main Ideas • Tree-Based Double-Covered Broadcast (TreeDCB) • Evaluation • Conclusions and Future Work Outline

3. 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

4. Introduction (cont’d) A key component for these broadcast applications is a broadcast routing protocol.

5. 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. Introduction (cont’d)

6. 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

7. Fixed-length Hello packets are desired • The number of broadcasting nodes should be kept small • The broadcast redundancy can be highly utilized Our Main Ideas (cont’d) Though our ideas are simple, they suit the characteristics of dense wireless networks:

8. 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

9. 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 Related Work (cont’d)

10. Differences between DCB and TreeDCB

11. Roles of a node • Hello packet format • Protocol description • Some discussions on TreeDCB Tree-based Double-Covered Broadcast (TreeDCB)

12. 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. Roles of a node

13. Src-ID Self-ID Cost Num-Children Parent-ID • 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. Hello Packet Format

14. 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

15. 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. Protocol description (cont’d)

16. Protocol description (cont’d) • 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 vonly 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:

17. Protocol description (cont’d)

18. 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 (1)

19. 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. Some discussions on TreeDCB (2)

20. 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 Evaluation

21. 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

22. 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. Experiment Setup (cont’d)

23. 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. Experiment Setup (cont’d)

24. 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. Ratio of forwarding nodes The ratio of forwarding nodes at different node densities.

25. Ratio of forwarding nodes (cont’d) The ratio of forwarding nodes at different mobility levels.

26. The amount of control traffic The Hello packet lengths at different node densities.

27. 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. Packet delivery ratio Packet delivery ratio at different node densities.

28. Packet delivery ratio (cont’d) Packet delivery ratio with different number of nodes.

29. 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. Average path length of a packet Average path length of a packet at different node densities.

30. Average path length of a packet (cont’d) Packet path lengths with different number of nodes.

31. 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. Conclusions

32. Thank you! Questions and Comments?