CBRP : A C luster- b ased R outing P rotocol for Mobile Ad hoc Networks

1. CBRP: A Cluster-based Routing Protocol for Mobile Ad hoc Networks Authors : Mingliang Jiang Jinyang Li Y.C. Tay Presented by: Hiren Shah

2. Presentation Outline • Related Works • CBRP data structures • CBRP cluster formation • CBRP route discovery • Conclusion and Future Work

3. Related Works • Re-active Routing Protocols • prohibitive flooding traffic in route discovery • route acquisition delay • every route breakage causes a new route discovery • Works in trying to reduce flooding traffic • LAR (GPS for every mobile node?) • DSR (aggressive caching)

4. CBRP: Features • use clustering approach to minimize on-demand route discovery traffic • use “local repair” to reduce route acquisition delay and new route discovery traffic • suggest a solution to use uni-directional links

5. CBRP: Protocol Overview Source of the diagram : Author’s web site http://www.comp.nus.edu.sg/~tayyc/cbrp/

6. SOME TERMINOLOGIES • A cluster head must have bi-directional links to all its member nodes. • A node will be a member of all those clusters for which it has a bi-directional link to the cluster heads. • These are called host clusters for the node.

7. HELLO MESSAGES • Every node periodically broadcasts HELLO messages to its neighbors. • HELLO messages sent by a node contain the neighborhood information of that node.

8. DATA STRUCTURES • Neighbor Table • Id, Role , Status of the link • Cluster Adjacency Table (CAT) • Keeps info. about adjacent clusters • Contains • Id of neighboring cluster • the gateway node (a member) to reach the neighboring cluster head • the status of the link

9. DATA STRUCTURES (Contd.) • Two-hop Topology Database • each node broadcasts its neighbor table information periodically in HELLO packets. • Therefore, by examining the neighbor table from its neighbors, a node is able to gather `complete' information about the network topology that is at most two-hops away from itself.

10. HELLO MESSAGES • HELLO message from a node contains its neighbor table and its cluster adjacency table (CAT). • Nodes update their neighbor tables and CAT when they receive HELLO messages from their neighbors.

11. HELLO MESSAGES (Contd.) • When a node A receives HELLO message from say a node B • A adds B to its neighbor table if B is not present in its table. • If B is already in the table update the status of link from B to A if required. • Update the role of B if it has changed.

12. CLUSTER FORMATION • A node can be in any of the three states • A cluster head • A cluster member • Undecided ( Looking for a head ) • An undecided node starts a timer and broadcasts a HELLO message. • Any cluster head that receives this message sends out HELLO message back.

13. CLUSTER FORMATION • If the node has bi-directional link to that cluster head it chooses that node as its cluster head and regards itself as a member of that cluster head. • If it does not find any head till the timer expires and it declares itself as a cluster head.

14. CLUSTER FORMATION • If two cluster heads have bi-directional links to each other one of them gives his status as a head and becomes member of the other head. The node with a smaller id continues to be a cluster head. • However the cluster heads wait for a certain period of time before this • This ensures that if two cluster heads are just close for a short time when they are on a move cluster re-formation does not happen.

15. Adjacent Cluster Discovery • For a member node neighboring cluster head is the one that is two hops away. i.e. one that can be reached via an intermediate node. This node is called a Gateway node. • A node can find out about its neighboring cluster heads by looking at the neighbor tables of its neighbors received in the HELLO messages.

16. 11 8 9 4 10 3 1 2 7 5 6 Adjacent Cluster Discovery Nodes also broadcasts their CAT in the HELLO message. Cluster heads can learn about other cluster head that are three hops away by looking at the CAT they receive. e.g. 4’s Cluster Adjacency Table Source of the diagram http://www.comp.nus.edu.sg/~tayyc/cbrp/

17. ROUTE DISCOVERY • When a node say A wants to discover route to a node say D it broadcasts a RREQ packet. • This packet contains a list of host and neighboring clusters heads. For neighboring cluster heads even the gateway nodes are mentioned.

18. ROUTE DISCOVERY • The idea is only cluster heads should forward the packet further. • If a member node receives RREQ packet it simply drops it. • However if a member node is listed as a Gateway node it unicasts the RREQ to the cluster head for which it is a Gateway node.

19. ROUTE DISCOVERY • When a cluster head receives RREQ, it adds itself on the partial route contained in the packet. • It adds the neighboring cluster heads to which the packet is to be forwarded from its own CAT along with their gateway nodes and then re-broadcasts their packet.

20. ROUTE DISCOVERY • Thus the RREQ passes through a number of cluster heads and eventually reaches D. • D upon receiving the RREQ sends and RREP back. • The RREP travels the same set of cluster heads that the RREQ traveled. • On the way entire hop-by-hop path is added to the RREP along with the Gateway nodes.

21. [3,1,8,11] 11 (D) 11 9 [3,1,8] 8 4 10 3 (S) 3 1 [3,1] 2 7 6 5 [3,1,6] Route Discovery Source S “floods” all clusterheads with Route Request Packets (RREQ) to discover destination D [3] Source of this and the following diagrams – Author’s web site.

22. 11 (D) 11 [11] [11,9] 9 [11,9,4] 8 4 10 3 3 (S) [11,9,4,3] 1 [11,9,4] the computed strict source route of 3->11 is: [11,9,4,3] 2 7 6 5 Route Reply • Route reply packet (RREP) is sent back to source along reversed “loose source route” of clusterheads. • Each clusterhead along the way incrementally compute a hop-by-hop strict source route. the reversed loose source route of RREP: [11,8,1,3]

23. 11 (D) 11 9 8 4 10 3 (S) 3 1 2 7 6 5 Route Reply • Route reply packet (RREP) is sent back to source along reversed “loose source route” of clusterheads. • Each clusterhead along the way incrementally compute a hop-by-hop strict source route. the reversed loose source route of RREP: [11,8,1,3] the computed strict source route of 3->11 is: [11,9,4,3]

24. 11 9 8 4 10 3 1 2 7 6 5 Route Error Detection • Use source routing for actual packet forwarding • A forwarding node sends a Route Error Message (ERR) to packet source if the next hop in source route is unreachable 11 (D) Source route header of data packet: [3,4,9,11] 3 (S) Route error (ERR) down link: {9->11}

25. ROUTE SHORTENING • Whenever a node receives a source-routed data packet, it tries to find out the furthest node in the unvisited route that is actually its neighbor. If it succeeds, it shortens the source route accordingly and FLAGS this in the packet. • The destination upon receiving this flagged packet sends and unsolicited RREP back to the source containing the shortened route.

26. 11 9 8 4 10 3 1 2 7 6 5 Local Route Repair • A forwarding node repairs a broken route using its 2-hop-topology information and modifies source route header accordingly. • Destination node sends a gratuitous route reply to inform source of the modified route 11 (D) Source route header of data packet: [3,4,9,11] 3 (S) Route error (ERR) down link: {9->11}

27. 11 9 8 4 10 3 1 2 7 6 5 Local Route Repair • A forwarding node repairs a broken route using its 2-hop-topology information and modifies source route header accordingly. • Destination node sends a gratuitous route reply to inform source of the modified route 11 (D) Source route header of data packet: [3,4,9,11] 3 (S) Modified source route [3,4,9,8,11]

28. Local Route Repair • A forwarding node repairs a broken route using its 2-hop-topology information and modifies source route header accordingly. • Destination node sends a gratuitous route reply to inform source of the modified route 11 (D) 11 Source route header of data packet: [3,4,9,11] 9 8 4 10 3 3 (S) 1 Gratuitous route reply [3,4,9,8,11] 2 7 6 5

29. SOME PROBLEMS WITH CBRP • Pitfalls with uni-directional links • Discovery of (dead) uni-directional links • Problems with 802.11 RTS/CTS/Snd/Ack, ARP • Source Routing, overhead bytes per packet. • Clusters small, 2 levels of hierarchy, scalable to an extend.

30. FURTHER WORK • Merge stable clusters into super clusters. • QoS, and Multicast support for CBRP.