+ All Categories
Home > Documents > CBRP: A Cluster-based Routing Protocol for Mobile Ad hoc Networks Authors : Mingliang Jiang Jinyang...

CBRP: A Cluster-based Routing Protocol for Mobile Ad hoc Networks Authors : Mingliang Jiang Jinyang...

Date post: 29-Dec-2015
Category:
Upload: kimberly-stafford
View: 215 times
Download: 1 times
Share this document with a friend
Popular Tags:
30
CBRP: A Cluster-based Routing Protocol for Mobile Ad hoc Networks Authors : Mingliang Jiang Jinyang Li Y.C. Tay Presented by: Hiren Shah
Transcript

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

Related WorksCBRP data structuresCBRP cluster formationCBRP route discoveryConclusion and Future Work

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)

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

CBRP: Protocol Overview

Source of the diagram : Author’s web site

http://www.comp.nus.edu.sg/~tayyc/cbrp/

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.

HELLO MESSAGES

Every node periodically broadcasts HELLO messages to its neighbors.

HELLO messages sent by a node contain the neighborhood information of that node.

DATA STRUCTURES

Neighbor Table Id, Role , Status of the link

Cluster Adjacency Table (CAT) Keeps info. about adjacent clusters Contains

Id of neighboring clusterthe gateway node (a member) to reach the

neighboring cluster head the status of the link

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.

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.

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.

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.

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.

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.

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.

Adjacent Cluster Discovery

3

84

1

5

2

6

7

910

11

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

Adj cluster ID Gateway8 96 2

Source of the diagram http://www.comp.nus.edu.sg/~tayyc/cbrp/

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.

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.

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.

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.

Route Discovery

Source S “floods” all clusterheads with Route Request Packets (RREQ) to discover destination D

[3]

[3,1,8,11]

1

2

4

5 67

8

9

10

3

11

3 (S)

11 (D)

[3,1]

[3,1,6]

[3,1,8]

Source of this and the following diagrams – Author’s web site.

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.

1

2

4

5 67

8

9

10

3

11

3 (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 computedstrict source route of3->11 is: [11,9,4,3]

[11,9,4]

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.

1

2

4

5 67

8

9

10

3

11

3 (S)

11 (D)

the reversed loose source route of RREP: [11,8,1,3]

the computedstrict source route of3->11 is: [11,9,4,3]

Route Error Detection

1

2

4

5 67

8

9

10

3

11

3 (S)

11 (D)

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

Source route header of datapacket: [3,4,9,11]

Route error (ERR)down link: {9->11}

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.

Local Route Repair

1

2

4

5 67

8

9

10

3

11

3 (S)

11 (D)

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

Source route header of datapacket: [3,4,9,11]

Route error (ERR)down link: {9->11}

Local Route Repair

1

2

4

5 67

8

9

10

3

11

3 (S)

11 (D)

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

Source route header of datapacket: [3,4,9,11]

Modified source route [3,4,9,8,11]

Local Route Repair

1

2

4

5 67

8

9

10

3

11

3 (S)

11 (D)

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

Source route header of datapacket: [3,4,9,11]

Gratuitous route reply[3,4,9,8,11]

SOME PROBLEMS WITH CBRP

Pitfalls with uni-directional links Discovery of (dead) uni-directional links Problems with 802.11

RTS/CTS/Snd/Ack, ARPSource Routing, overhead bytes per

packet.Clusters small, 2 levels of hierarchy,

scalable to an extend.

FURTHER WORK

Merge stable clusters into super clusters.

QoS, and Multicast support for CBRP.


Recommended