Multicasting in Ad Hoc Networks

October 28 ,2003徐建鈞

AMRIS Adhoc Multicast Routing Protocol utilizing I

ncreasing id-numberS

Definition AMRIS is a multicast routing protocol for a

d-hoc wireless networks Operates independently of the underlying u

nicast protocol. Assigns every node (on demand) in a multic

ast session with an id-number.

Protocol Implementation

On Demand protocol Constructs shared delivery tree

Key Idea Each participant in the multicast session has a sess

ion-specific multicast session member id (msm-id). Significance of msm-id ->Provides each node with t

he indication of its logical height in the multicast delivery tree

Protocol Implementation TREE INITIALIZATIONDetermine which node will assume the role of Sid(core no

de)

If Single Sender Multiple Receiver->Sid is the Single Sender.

If Multiple Sender Multiple Receiver->Sid may be selected among the Senders.

Protocol Implementation TREE INITIALIZATIONSid broadcasts NEW SESSION message to itsNeighbours

New Session

Protocol Implementation TREE INITIALIZATIONNew Session contains -> Sid’s MSM-id, Multicast Session ID, Routing metrics.

Nodes that’s are interested in being a part of theMulticast session called I-Nodes join in the InitializationPhase.Uninterested nodes U-Nodes may still become part ofthe multicast session.

Protocol Implementation TREE INITIALIZATION

New Session

Sid I node

I node

I node

Protocol Implementation TREE INITIALIZATION

JOIN REQ

Sid I node

I node

I node

Protocol Implementation TREE INITIALIZATION

JOIN ACK

Sid I node

I node

I node

Protocol ImplementationNodes receive the New Session messageGenerate their own msm-id, a value larger and notconsecutive so that there are gaps between msm-ids

ofsender and receiver………Useful for quick local repair of the delivery tree

Protocol Implementation TREE INITIALIZATIONReceiver replaces the msm-id in the message with itsown msm-id, also its routing metrics and rebroadcast

sthe message

Multicast Tree

Rebroadcasted message

Protocol Implementation TREE INITIALIZATIONInformation derived from New Session Message is keptIn the Neighbor-Status Table for up to T1 seconds (T1 usually set as a multiple of beacon interval)

Node receiving Multiple messages keeps the messageWith best Routing metrics and calculates its msm-idbased on value from that message ONLY if it has notRe broadcasted any message.

Otherwise multiple messages received may be dropped

Protocol ImplementationTREE FORMEDAMRIS maintains a Neighbour-Status table -> stores alist of existing neighbor and their msm-id.

Each node sends a periodic BEACON (containing node’s

present msm-id) to signal their Presence to neighbors

Protocol Implementation

TREE FORMED

Beacon Signal Informing their presence contains their msm-ids

Neighb. MSM

Protocol Implementation

TREE FORMED

Beacon Signal Informing their presence contains their msm-ids

X

Protocol Implementation

TREE FORMED

New Session Message

X

Protocol Implementation

TREE FORMED

Beacon Signal Informing their presence contains their msm-ids

X

Protocol Implementation TREE INITIALIZATIONLooks for neighbor with smaller msm-id than XSends out a Unicast JOIN-REQ to any one of thePotential parent node

When Say Y receives JOIN_REQ checks to see if it isAlready on the delivery tree

YES! -> sends a JOIN-ACK back to X

Protocol Implementation

TREE FORMED

Potential Parent

Potential Parent

X

Y

Protocol Implementation

TREE FORMED

Potential Parent

Y

JOIN-REQ

Protocol Implementation

TREE FORMED

Potential Parent

Potential Parent

X

Y

JOIN-ACK

Protocol Implementation

TREE FORMED

Potential Parent

Potential Parent

X

Y

Protocol ImplementationTREE MAINTENANCEThis mechanism runs continuously in the backgroun

dto ensure that the node remains connected to theMulticast session delivery tree.

LINK FAILURE between 2 nodes??Node with larger msm-id responsible for rejoining

Done by Branch Reconstruction having 2 subroutinesBR1 and BR2

Protocol Implementation TREE MAINTENANCEBR1 works as followsNode X selects potential parent node say YSends JOIN_REQ to Y If Y already registered member and has smaller msmid? ----------YES! Y sends JOIN-ACK

NO! Y repeats the process sending out JOIN_REQ tobecome a member of tree BUT provided it has one neighboring Potential parent node otherwise sends aJOIN-NACK back to XIf X receives a JOIN-NACK or times out repeats process and if it still fails executes BR2 subroutine

Protocol Implementation TREE MAINTENANCEBR2 Node X starts sending out broadcast JOIN-REQs.The Broadcasted JOIN-REQ had only a range field Rthat specifies nodes within R hops from X are allowedto Re broadcast the JOIN-REQ

Node Y receives a JOIN-REQ and checks to see if it canSatisfy the requestYES! Sends back JOIN-ACK but WAITS does notForward multicast traffic to X since X may receive morethan one JOIN-ACKS

Protocol Implementation TREE MAINTENANCEX receives the JOIN-ACKs (more than one)Chooses one of them and sends a JOIN-CONF to pare

ntNode to start receiving the multicast traffic.

References

[1] Leiner, B.M, Neison, D.L. and Tobagi, F.A, “Issues in Packet Radio Network Design”. Proceeding of the IEEE Special issue on “Packet Radio Networks”,,75,1:6-20,1987

[2]Jubin, J and Tornow, J.D, “The DARPA Packet Radio Network Protocols”, In Proceedings of IEEE, volume 75,1, pages 21-32, Jan. 1987

[3]Deering, S.E., Partridge, C., and Waitzman, D., Distance vector multicast routing protocol”, RFC 1075, NOV 1988