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

Presentation Outline zRelated Works zCBRP data structures zCBRP cluster formation zCBRP route discovery zConclusion and Future Work

Related Works zRe-active Routing Protocols yprohibitive flooding traffic in route discovery yroute acquisition delay x every route breakage causes a new route discovery zWorks in trying to reduce flooding traffic yLAR (GPS for every mobile node?) yDSR (aggressive caching)

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

CBRP: Protocol Overview Source of the diagram : Author’s web site

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

HELLO MESSAGES zEvery node periodically broadcasts HELLO messages to its neighbors. zHELLO messages sent by a node contain the neighborhood information of that node.

DATA STRUCTURES zNeighbor Table yId, Role, Status of the link zCluster Adjacency Table (CAT) yKeeps info. about adjacent clusters yContains xId of neighboring cluster xthe gateway node (a member) to reach the neighboring cluster head xthe status of the link

DATA STRUCTURES (Contd.) zTwo-hop Topology Database y each node broadcasts its neighbor table information periodically in HELLO packets. y 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.

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

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

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

CLUSTER FORMATION z 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. z If it does not find any head till the timer expires and it declares itself as a cluster head.

CLUSTER FORMATION z 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. z However the cluster heads wait for a certain period of time before this z 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.

Adjacent Cluster Discovery z 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. z A node can find out about its neighboring cluster heads by looking at the neighbor tables of its neighbors received in the HELLO messages.

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

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

ROUTE DISCOVERY z The idea is only cluster heads should forward the packet further. z If a member node receives RREQ packet it simply drops it. z 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.

ROUTE DISCOVERY z When a cluster head receives RREQ, it adds itself on the partial route contained in the packet. z 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.

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

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

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

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

Route Error Detection (S) 11 (D) zUse source routing for actual packet forwarding zA forwarding node sends a Route Error Message (ERR) to packet source if the next hop in source route is unreachable Source route header of data packet: [3,4,9,11] Route error (ERR) down link: {9->11}

ROUTE SHORTENING z 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. z The destination upon receiving this flagged packet sends and unsolicited RREP back to the source containing the shortened route.

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

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

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

SOME PROBLEMS WITH CBRP zPitfalls with uni-directional links yDiscovery of (dead) uni-directional links yProblems with RTS/CTS/Snd/Ack, ARP zSource Routing, overhead bytes per packet. zClusters small, 2 levels of hierarchy, scalable to an extend.

FURTHER WORK zMerge stable clusters into super clusters. z QoS, and Multicast support for CBRP.