a new multicast routing protocol based on xcast

7/28/2019 A New Multicast Routing Protocol Based on Xcast

1/6

A New Multicast Routing Protocol Based On Xcast

and Stable Link Repair for Mobile Ad Hoc Networks

Xia Li Zou Jian Su Xin Liu ZongqiCollege of Information Science and Engineering, Northeastern University

Shenyang, China

E-mail: [email protected] , [email protected], [email protected], [email protected]

AbstractIn view of the compromise between overhead and

performance, this paper proposes a MAODV-X multicast routing

protocol by incorporating the excellence of Explicit Multicast

with the multicast-tree based routing protocol and stable link

repair in Ad Hoc network, which simplifies the MAODV

multicast trees by establishing the specific routing table in

intermediate nodes in order to reduce the control overhead,

predigests the compression code of explicit multicast IP address

to lower the complexity of explicit multicast IP header,furthermore, computes the stability coefficient based on

maximum entropy in Shannon theorem by taking into account

the energy consumption and the congestion level to choose one of

the most stable links during the repairing procedure and avoid

frequent link repair. The simulation results demonstrate that the

MAODV-X protocol performs better in the scenarios of different

size of multicast group, different maximum moving speed

compared with the counterparts including MAODV and E2M.

Keywords-Xcast; multicast tree; maximum entropy; stable link

repair

I. INTRODUCTIONAd hoc is a kind of characteristic temporary network

formed by a group of mobile nodes, which is independent ofany existing network infrastructure or centralized management.With strong self-organizational, robust and indestructiblecharacteristic, it is mainly used for military battlefield, medicalemergency, flood fighting relief and some emergent situationwithout wire communication devices

[1]. Todays multicast

schemes can not only reduce the processing overhead of themulticast transmission, but also minimize the bandwidthconsumption. Therefore, using multicast group communicationmechanism is quite necessary for the mobile Ad Hoc networkwhose bandwidth is extremely limited. However, the Ad hocenvironment is typically characterized by energy and

bandwidth-constrained, dynamic and security, leading tofrequent and unpredictable connectivity changes [2, 3], thedesign of routing protocols becomes a challenge.

While traditional IP multicast schemes are scalable forlarge multicast groups, they have scalability issues with a largenumber of distinct multicast groups. The Xcast (Explicit Multi-unicast) is a new multicast scheme with complementary scaling

properties: Xcast supports a very large number of smallmulticast sessions. Xcast achieves this by explicitly encodingthe list of destinations address in the data packets, instead ofusing a multicast group address. Explicit Multicast doesnt

need to maintain multicast routing state, reduces the calculatingof the protocol [4, 5].

The rest of the paper is organized as follows. Section 2introduces some of the related work, section 3 gives a detaileddescription of the proposed MAODV-X protocol while insection 4 we implement simulation experiments of MAODV,E2M and MAODV-X in different scenarios, analyze the

network performance of three protocols. Finally, section 5concludes the paper and outlines our future research plan.

II. RELATED WORKGenerally, there are two classifications of multicast routing

protocols in Ad Hoc Network, one category is initiative andon-demand, the other is according to the topological structureof multicast transmission nodes involved, and the routing

protocols can be divided into tree-based multicast routingprotocol, mesh-based multicast routing protocol and hybridmulticast routing protocol.

MAODV (Multicast Ad hoc On-demand Distance Vector)

is a typical tree-based multicast routing protocol. There is onlyone path from any source node to the destination node,therefore the bandwidth of data forwarding is reduced and thetransmission efficiency is higher. In the case of fewer nodes,there will be many non-multicast members becoming a part ofthe multicast tree, which need to maintain the multicast treerouting tables, increasing the network control overhead [6, 7,8]; On the other hand, due to the characteristics of limited

battery power as well as low processing capabilities of Ad Hocnetwork nodes, the link is frequently in case of failure,increasing the number of link repair. Whats more, MAODVdoes not have a stable link repair mechanism, which will incurhigher end-to-end latency and network overhead [2].

A number of explicit multicast protocols in Ad Hocnetworks have been raised currently, and the mostrepresentative ones are DDM and E2M protocol . DDM(Differential Destination Multicast), which is source-initiatedand controlled, is very efficient both in terms of dataforwarding and control channel access. Especially for smallgroups, and more sensitive to network traffic level compared to

protocols using redundant forwarding path. E2M (ExtendedExplicit Multicast) is named Extended Explicit Multicast,which is based on the novel concept of dynamic selection ofXcast Forwarder (XF) between a source and its potential [5].


2/6

III. MAODV-XPROTOCOL DESCRIPTIONMAODV-X is an optimized multicast routing protocol

based on Xcast and stable link repair, which combines theideas of explicit multicast with the multicast tree structure ofMAODV and uses maximum entropy for the election of stablelinks. Only the multicast group members and the multicastintermediate nodespossess the specific multicast intermediatenode routing tables (INT) which are exclusively defined in the

MAODV-X protocol. The node has decided to be a multicastintermediate node as the number of nodes served by it isgreater than a threshold. The structure of extended multicastintermediate routing table is shown in Figure 1.

Figure 1 Structure of INTIn this structure of INT, the item of upstream node refers to

the previous multicast intermediate node. The field of upstreamnode address is set to be empty by the source node. Thedownstream nodes are connected by the chained list and thedata packets are forwarded by the way of unicast. The field ofdownstream node address is set to be empty by the destinationnode.

A. Establishment of multicast group based onexplicit multicast

1) route requestWhen a node A wants to join or have data to send to the

multicast group and has not a valid path to the group will senda route request (RREQ) message, in which J flag bit is set to 1,named Join RREQ. The request node A determines broadcastor unicast Join RREQ message according to the availableinformation in it. If node A has a path to reach the multicastintermediate nodes, multicast group member nodes or the headof the multicast group, then the Join RREQ message willcontain the node's IP address in the multicast group G, and thenwill be unicasted to the node. After receiving the Join RREQmessage, only the node which is a multicast intermediate node,a multicast group member node or head node of multicastgroup can respond the message, other nodes unicast or

broadcast it directly. If node A does not know any nodes in themulticast group, it only broadcasts RREQ messages untilfinding a multicast intermediate node, member node or headnode of the multicast group.

The request node will rebroadcast another RREQ messageif it doesnt receive any RREP messages before timeout, and it

will add 1 to the Broadcast_ID of the Join RREQ message.This process will continue in accordance with the same way ifit still has not received the RREP messages before timeout, butrebroadcast times should not exceed the value ofRREQ_RETRIES. The source node considers the multicastgroup G is unreachable or not exists if it doesnt receive RREPmessages ultimately. At this time, the source node A is the onlygroup member, that is, the head node of the multicast group,and it will also initialize the sequence number (set to 1) of themulticast group G. If the head node of the multicast group Gcant be found, or the node is no longer the head of the

multicast group or multicast intermediate node, Join RREQmessage should be broadcasted; the field of destination addressshould be set to the IP address of the multicast group G whilethe expansion domain which contains the address of the headof the multicast group is canceled.

The nodes who receive the Join RREQ message for the firsttime will look up the intermediate node routing tables toexamine the existence of the entries of multicast group G. Ifthere are no entries of G, then it will simply unicast or

broadcast the received Join RREQ message. This process onlystops if the head node of G is found and the successful pathestablished. The node is probably the head node of themulticast group if the upstream nodes are not in the table.

2) route responseIf a node which is a multicast intermediate node or a

multicast group member node of G receives a Join RREQmessage which is sent to the multicast group, it can respond theJoin RREQ message only when the recorded sequence numberof the multicast group G is no less than the one contained in theJoin RREQ message. The response node updates the field ofdownstream node address information in routing table and theINT with the request node information, and then generates aRREP message and unicast it to the request node of the JoinRREQ message. The node who receives the Join RREQmessage will check whether it has an INT and then checkwhether it holds the item of G in the INT. It will continue tounicast or broadcast the Join RREQ message if it has not theitem of G in the INT, otherwise, the multicast member nodewill examine the corresponding control information (J flag bit,etc.) and then send the Join RREP message (J flag bit set to 1),or the multicast intermediate nodes will send Join RREPmessage directly.

The Join RREP which is sent back to respond the JoinRREQ will set the J flag to 1 which represent the RREP forJoin RREQ, and it is unicasted along the reverse path of JoinRREQ until forwarded to the request node. After receiving theextended RREP, the request node will send an extendedHELLO message to its unicast previous node. The node whoreceives the extended HELLO will add 1 to the thresholdcounter, the key word of which is the combination of thesource IP address and the multicast group address, and thencompares the value of the threshold counter with the presetvalue, thus determine whether there arise a new multicastintermediate node. The unicast previous node will continue toforward the extended HELLO to its unicast previous nodewhen the value of the threshold counter is less than the presetvalue; otherwise, the unicast previous node turns into a

multicast intermediate node, it will add the request nodeaddress in the extended HELLO into the field of downstreamnode address of INT, then send a extended HELLO back to therequest node to inform the appending of the upstream node,finally send a extended HELLO to its unicast previous node toshow the accession of a new multicast intermediate node. Theunicast previous node who receives the extended HELLOmessage will be carried on recurrently until the extendedHELLO message arrive the node in which the value ofthreshold counter is bigger than the preset value or theextended HELLO message is sent to the head node of themulticast group.


3/6

According to the Figure 2, assume that node A sends JoinRREQ to node N1. Afterwards, R1 which is a multicastintermediate will send back a Join RREP to node A along thereverse path of Join RREQ.

Figure 2 Topology after joining multicast groupAs shown in Figure 2, N1 sets the J flag to 1 before replies

the Join RREP along the path of Join RREQ, then node A willsend an extended HELLO message to node N1 and add 1 to thethreshold counter after received the RREP message. As N1 is amulticast intermediate node, it needs to update its downstreamnodes item in INT and sends an extended HELLO message tonode A. Node A will set its upstream node to N3 after receivesthe extended HELLO which is send by N1. The changed

intermediate node routing table of N1 is shown in Figure 3.

Figure 3 Intermediate node routing table of N1 after Join RREP

B. Tramission of multicast group dataAs shown in Figure 4, when the source node S wants to

send multicast data to the multicast member nodes R1 to R6,the source node S will unicast data based on the downstreamnode N2 in its INT, as S is the source node, the item of

upstream node address is set to be empty. The packets will beforwarded firstly to the node N1, N1 will check whether it hasa multicast intermediate routing table and whether it concludessource node S and the multicast group address in its INT. Node

N1 will forward the data packets to N2 along the path ofunicast. Node N2 will check its source node address andmulticast group address after receiving a data packet andunicasts the received data packet to its downstream nodes N3and N6 according to the downstream node address in its INT,The process of data forwarding is the same with above, andwill continue until a multicast member node receives themulticast data packets. When all the multicast member nodesreceive the multicast packets, the multicast process will beover.

C. Stable-aware link repairThe features of MANET and the heterogeneity of its nodes

may lead to frequent disconnect and link repair. It is necessaryto find a stable link to construct backup path and postpone thenext repair operation, therefore to extend the survival time and

promote the stability of repaired path.

1) Consideration on the stable link selectionNodes in Ad Hoc networks, such as PDA, are typically

characterized by energy and bandwidth limited, meanwhile,

our proposed scheme also considers the queue utilization ofeach intermediate node. As the intermediate node selected isalmost exhausted, it probably induces frequent andunpredictable connectivity changes. On the other hand, if thequeue is nearly at full capacity (is nearly loaded to fullcapacity), the arriving packets appear to be lost in the event ofcongestion. Consequently, both remaining energy and queueutilization would impact on link stability. The following

paragraph will describe about how to achieve relative stablelinks to establish a backup path.

a) metric of node energyIn view of some nodes being exhausted due to the heavy

traffic in the Ad hoc networks, if such nodes are chose to makea backup path as disconnection happens, it would depleteenergy supplies utterly and incur more frequent link repair,increase process spending. Accordingly, the residual energy ofnodes is an important fact depicted as bellow:

( )( )

( )0

i

r

i i

E nS n

E n=

1

Where( )iS n express the survival probability of node i,

( )irE n and ( )0iE n

represent the surplus energy and initialenergy respectively.

b) metric of queue lengthAs the queue buffer exceeds the supply, the traffic will be

bottled up at the egress. If the buffer is overflow, the arrivingpackets would be dropped, thereby, the relative empty bufferimplying no or less congestion is suitable to be utilized duringthe link repair process. The congestion degree is evaluated:

( ) ( )( )0

1

i

c

i iQ nC nQ n

=

2

Where( )iC n indicates the congestion degree of node i

( )icQ n and ( )0iQ n

present the length of occupied queuebuffer and length of original queue buffer respectively.

The essential factors introduced above which impact onlink stability, is normalized to achieve stability coefficientshown as Equ.3:

( ) ( ) ( )i i ip n S n C n = +

3

Where( )ip n is stability coefficient used to evaluate the

node stability, and are normalized parameters, constants,

and + =1. The entire path ought to be calculated byestablishing a model based on Shannons Information Entropy.The maximum entropy theorem is shown as Equ.4:

( ) ( ) ( )2logh x p x p x= 4


4/6

Where( )h x

is value of entropy,( )p x

is the probabilityof event x.

In order to measure the stability of link,( )p x

in themaximum entropy theorem is regarded as stability coefficient.The bigger the value of entropy is computed, the moreuncertain the link is, and vice versa. Thus it is concluded thatthe link which has a least entropy of stability coefficient is themost stable link. The entropy of stability coefficient is given as:

( ) ( ) ( )20

log=

= t

i i

i k k

k

h n p n p n

5

Where( )ih n presents the entropy of stability coefficient in

link i,( )ikp n presents stability coefficient of node t in link i,

( ) ( )2logi i

k kp n p n

denotes a portion of entropy of stabilitycoefficient computed in each node by which the whole entropy

of stability coefficient of links is achieved, and source node canchoose the most stable links to repair the disconnect path,furthermore to avoid frequent repair.

2) Link repairWhen an intermediate nodes upstream node is

unreachable, the intermediate node send N_RERR message tothe downstream node, which forwards the message to itsdownstream node, until the multicast destination node. Shownas Figure 4, the repair procedure is described.

Figure 4 Demonstration of multicast link repairDuring the transmitting, the link between N4 and N5 is

broken, N6 sends N_RERR message to N7 and R6 withoutreceiving any message from upstream node N2 waiting for a

interval HELLO_INTERVAL 1+ALLOWED_HELLO_

LOSS. N7 forwards the N_RERR message to R3 ~ R5. Then

N6 will initiate the multicast link repair operation.

First, N6 broadcasts a RREQ message with flag bit R set to1, named Repair RREQ. The neighbors receiving the messagecomputes the stability coefficient itself according to Equ.5, andthen gets the portion of entropy of stability coefficient which isadded with the entropy accumulation in Repair RREQ messageand broadcasts it continually, until reaching the multicastintermediate node or multicast group member node. The nodeforwards it looking up the multicast intermediate node routingtable or broadcast it to the head of the multicast group. Thehead node actuates a timer T after receiving the first Repair

RREQ message and compares the entropy values of stabilitycoefficient in the received Repair RREQ messages during theinterval before the Timer T is time out, then choose the linkswith the least entropy value accumulation to construct an new

path, which is considered as the most stable one. The otherRepair RREQ messages received after the Timer T is time outare dropped directly.

As shown in Figure 4, N6 transmits the Repair RREQmessage to its neighbors with the initial entropy value=0. Thenode receiving the first message computes the stabilitycoefficient value and portion of entropy value of stabilitycoefficient according to Equ.5, and adds up with the value

placed in the message that is forwarded or broadcastedcontinually. It is supposed that the Repair RREQ messagesforwarded by R1 and R2 are delivered to source node S. If theentropy value accumulation of stability coefficient from R1 isless than from R2, then node S choose the path from R1 to S as

backup path. If the entropy value accumulation of stabilitycoefficient from R1 and R2 are equal, then node S choose the

path along which the Repair RREQ message comes to S first tobe backup path. At present, node S transmits RREP message

with flag bit R set to 1, named Repair RREP, return to N6through R1 along the same path as Repair RREQ. The repaired

path is shown as in Figure 5.

Figure 5 Repaired topologyWhen the repair-actuating node N6 receives the Repair

RREP message, it transmits an extended HELLO message toits previous hop R1, which is similar to the process to join themulticast group, to update the multicast group intermediatenode routing table. Since R1 becomes a multicast intermediatenode, it augments an entry of node R6 address as downstreamnode address, and returns an extended HELLO message to R6.

NowR6 needs to update its upstream node address to be R1

and transmits an extended HELLO message to downstreamnode N7 and R6 to inform the accomplishment of multicastrepair procedure.

IV.

SIMULATION RESULTSTo evaluate the performance of the protocol MAODV-X,

we use NS2-2.26 as the simulation platform. In our simulationstudy, it is assumed that 50 mobile nodes spread over atopology of 1500m300 m, with a channel bandwidth of 2Mbps, each flow has been executed for 910 sec. The sourcenode of CBR data flow and multicast group members whorequest to join the group are randomly selected. The sourcenode and destination nodes of CBR flow are fixed in thesimulation. In the following simulations, we have consideredCBR traffic with payload size set to 512 bytes. Data packets


5/6

are generated at the selected source node at a constant rate of 2packets per second. When the simulation starts, each noderandomly picks a destination and moves towards it with arandom constant speed which is specified. After a nodereaches its destination, it stays for an interval and thenrandomly picks another destination and starts moving towardsthis new direction with a newly selected random speed.

Nodes moving speed is a random value between 0m/s and a

maximum rate.

A. Different multicast group sizeThe simulation results are shown in Figure 6~9. The

performance in all aspects of these protocols includingMAODV-X, MAODV and E2M, declines when the number ofnodes in the multicast group increases from 10 to 50. This is

because as the number of nodes within the multicast groupincreases, the group size will increase, thus lead to frequentand unpredictable connectivity changes which will generateadditional overhead.

Figure 6 Packet delivery ratio

Figure 7 End-to-end delay

Figure 8 Control overhead

Figure 9 Number of Link RepairAs seen from Figure 6, the packet delivery rate of E2M is

superior to that of MAODV-X and MAODV when themulticast group size is small, however, with the increase ofmulticast group size, the packet delivery rate obviouslyreduces due to the blind flooding scheme in the explicitmulticast. Both MAODV-X and MAODV are better than E2Mwith the aid of the tree-based structure; furthermore,MAODV-X excels MAODV for its simplifing the tree-basedstructure.

Figure 7 shows that E2M performs worse than MAODV-Xand MAODV on the end-to-end delay similarly due to the

blind flooding scheme.While MAODV-X and MAODV areboth tree-based protocols, the end-to-end delay doesnt differmuch during the multicast group size changes.

The results in Figure 8 show that E2M demands minimumcontrol overhead since it is based upon explicit multicast andadopts unicast approach to multicast, moreover the majority ofcontrol messages of it is based on definite link conditions.

Nevertheless, MAODV is a tree-based protocol, many non-multicast member nodes may become tree nodes, which will

produce a large number of maintenance information in themulticast group, leading to the increase of network control

overhead. MAODV-X is also based on explicit multicast, andit simplifies the multicast trees with downstream nodes andthus induces less control messages, so MAODV-X is also

better than MAODV.

The E2M forwards data by the way of blind flooding and itdoesnt need to repair links, so we just compare the MAODV-X and MAODV. Figure 9 depicts that there is almost nodifference on the number of links repair when the multicastgroup is small. As the number of nodes within the multicastgroup increases, some nodes may be overloaded because ofthe unequal link distribution, this may easily results indisconnected link owing to the inadequate energy. MAODVdoesnt take into account the stability of the link in the period

of link repair while MAODV-X chooses one of the moststable links using the maximum entropy in Shannon theoremduring the repairing procedure and avoids frequent link repair.

B. Different maximum moving speedThe simulation results are shown in Figure 10~13. Along

with the maximum moving speed of each node graduallyincreases from 0m/sec to 20m/sec, the performance in allaspects of the MAODV-X, MAODV and E2M protocols aredecreased, since the higher the moving speed is, the rapid thenetwork topology changes.


6/6

Figure 10 Packet delivery ratio

Figure 11 End-to-end delay

Figure 12 Control overhead

Figure 13 Number of link repairFigure 10 shows that, with the maximum node moving

speed increases, the packet delivery ratio of MAODV-X issuperior to that of MAODV and E2M, because MAODV-Xadopts the idea of explicit multicast at the moment of themulticast group establishment and simplifies the multicast tree

by unicasting, reducing the dependence of some nodes, henceimproves the average packet delivery ratio.

The result in Figure 11 shows that the average end-to-enddelay of MAODV-X is relatively stable. Links are likely to

break down due to the frequently changed network topologydue to the increase of maximum moving speed, and the end-to-end delay of MAODV may often twitter accordingly whileE2M performs even worse for its blind flooding mechanism.MAODV-X is more stable for it is capable of choosing astable link to avoid frequent link repair.

AS shown in Figure 12, MAODV-X make a betterperformance than MAODV but worse than E2M on controloverhead for its tree-based structure, with the increase of themaximum moving speed. Figure 13 shows that the stability ofMAODV-X is better than that of MAODV, as it is able tochoose a stable link and use the unicast approach while

building a multicast tree or updating the multicast intermediatenode routing table.

V. CONCLUSIONThe investigation presents a multicast routing protocol

MAODV-X by syncretizing the idea of tree-based routingapproach and explicit multicast routing. The specific multicastintermediate node routing table is designed to simplify themulticast tree, reduce the control overhead to deal withconstruction of the multicast tree. The explicit multicast IPaddress is predigested due to the specific multicast routingstable to avoid analyzing the explicit multicast IP header. Themaximum entropy theorem of Shannon is utilized to computethe entropy value of stability coefficient through remainingenergy and queue utilization, by which the most stable backup

path can be determined during the link repair to decrease therepair times. The experiment results demonstrate that the

proposed protocol outperform the counterparts in some extent.

REFERENCES

[1] Lee S J, Su WHsu J. A Performance Comparison Study of Ad HocWireless Multicast Protocols [J]. IEEE INFOCOM2000565-574.

[2] Yu-Feng Jia, Ying-xin Hu. Improvement of Wireless Multicast Routingwith Link State Based on MAODV [C], 4th International Conference onWireless Communications, Networking and Mobile Computing, 2008,1-5.

[3] Narsimha, G., Venugopal Reddy, A, Sarma, S S V N. The EffectiveMulticasting Routing Protocol in Wireless Mobile Adhoc Network[C],Sixth International Conference on Networking, ICN '072007 , 15-17.

[4] R Boivie, N Feldman, Y Imai, W Livens, D Ooms. ExplicitMulticast(Xcast) Concepts and Options [S]. RFC5058, Nov 2007.

[5] Abderrahim Benslimane, Cdric Ferrari, Abdelhakim Hafid. EM2NET:an Energy-Saving Explicit Multicast Protocol for MANETs[C], GlobalTelecommunications Conference, 2007, 592-597.

[6] Malarkodi B, Gopal P, Venkataramani B. Performance Evaluation ofAdhoc Networks with Different Multicast Routing Protocols andMobility Models [C], Advances in Recent Technologies inCommunication and Computing, 200981-84. [6]

[7] Prabha Ramachandran. Source authentication for mutlicast in Mobile AdHoc networks [D], University of Maryland, 2003.

[8] Morais Cordeiro, C Gossain, H Agrawal D P. Multicast over wirelessmobile Ad Hoc networks: present and future directions [J], Network,IEEE , 2003, Vol17: 52-59.

a new multicast routing protocol based on xcast

Documents