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

2. NICTA Copyright 2010From imagination to impact 2 Outline Introduction Related Work Our Main Ideas Tree-Based Double-Covered Broadcast (TreeDCB) Evaluation Conclusions and Future Work

3. NICTA Copyright 2010From imagination to impact 3 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.

4. NICTA Copyright 2010From imagination to impact 4 Introduction (cont’d) A key component for these broadcast applications is a broadcast routing protocol.

5. NICTA Copyright 2010From imagination to impact 5 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.

6. NICTA Copyright 2010From imagination to impact 6 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

7. NICTA Copyright 2010From imagination to impact 7 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:

8. NICTA Copyright 2010From imagination to impact 8 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.

9. NICTA Copyright 2010From imagination to impact 9 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

10. NICTA Copyright 2010From imagination to impact 10 Differences between DCB and TreeDCB DCBTreeDCB 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

11. NICTA Copyright 2010From imagination to impact 11 Tree-based Double-Covered Broadcast (TreeDCB) Roles of a node Hello packet format Protocol description Some discussions on TreeDCB

12. NICTA Copyright 2010From imagination to impact 12 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.

13. NICTA Copyright 2010From imagination to impact 13 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-Children Self-ID Cost

14. NICTA Copyright 2010From imagination to impact 14 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.

15. NICTA Copyright 2010From imagination to impact 15 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.

16. NICTA Copyright 2010From imagination to impact 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 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:

17. NICTA Copyright 2010From imagination to impact 17 Protocol description (cont’d)

18. NICTA Copyright 2010From imagination to impact 18 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.

19. NICTA Copyright 2010From imagination to impact 19 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.

20. NICTA Copyright 2010From imagination to impact 20 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

21. NICTA Copyright 2010From imagination to impact 21 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).

22. NICTA Copyright 2010From imagination to impact 22 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 densityAverage node degree 508.49 10015.6 15022.06 20028.55 25033.73 30038.41

23. NICTA Copyright 2010From imagination to impact 23 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 network100 Maximal node speed in RWP model2.8m/s Node Density150 nodes/km 2 Bandwidth2Mbps CBR Source Packet Rate40 pkts/s Data Packet Length200 bytes Period of sending Hello packet0.5s Simulation Time150s Confidence Interval95% Number of Trials50

24. NICTA Copyright 2010From imagination to impact 24 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. The ratio of forwarding nodes at different node densities.

25. NICTA Copyright 2010From imagination to impact 25 Ratio of forwarding nodes (cont’d) The ratio of forwarding nodes at different mobility levels.

26. NICTA Copyright 2010From imagination to impact 26 The amount of control traffic The Hello packet lengths at different node densities.

27. NICTA Copyright 2010From imagination to impact 27 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. Packet delivery ratio at different node densities.

28. NICTA Copyright 2010From imagination to impact 28 Packet delivery ratio (cont’d) Packet delivery ratio with different number of nodes.

29. NICTA Copyright 2010From imagination to impact 29 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. Average path length of a packet at different node densities.

30. NICTA Copyright 2010From imagination to impact 30 Average path length of a packet (cont’d) Packet path lengths with different number of nodes.

31. NICTA Copyright 2010From imagination to impact 31 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.

32. NICTA Copyright 2010From imagination to impact 32 Thank you! Questions and Comments?