A New Multicast Routing Protocol Based On Xcast and Stable Link Repair for Mobile Ad Hoc Networks

Xia Li Zou Jian Su Xin Liu Zongqi

College of Information Science and Engineering, Northeastern University Shenyang, China E-mail: xiali@ise.neu.edu.cn , zoujian_neu@163.com, okey19841106@gmail.com, lzq_1232006@126.com
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

need to maintain multicast routing state, reduces the calculating of the protocol [4, 5]. The rest of the paper is organized as follows. Section 2 introduces some of the related work, section 3 gives a detailed description of the proposed MAODV-X protocol while in section 4 we implement simulation experiments of MAODV, E2M and MAODV-X in different scenarios, analyze the network performance of three protocols. Finally, section 5 concludes the paper and outlines our future research plan. II. RELATED WORK

Generally, there are two classifications of multicast routing protocols in Ad Hoc Network, one category is initiative and on-demand, the other is according to the topological structure of multicast transmission nodes involved, and the routing protocols can be divided into tree-based multicast routing protocol, mesh-based multicast routing protocol and hybrid multicast routing protocol. MAODV (Multicast Ad hoc On-demand Distance Vector) is a typical tree-based multicast routing protocol. There is only one path from any source node to the destination node, therefore the bandwidth of data forwarding is reduced and the transmission efficiency is higher. In the case of fewer nodes, there will be many non-multicast members becoming a part of the multicast tree, which need to maintain the multicast tree routing 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 Hoc network nodes, the link is frequently in case of failure, increasing the number of link repair. Whats more, MAODV does not have a stable link repair mechanism, which will incur higher end-to-end latency and network overhead [2]. A number of explicit multicast protocols in Ad Hoc networks have been raised currently, and the most representative ones are DDM and E2M protocol . DDM (Differential Destination Multicast), which is source-initiated and controlled, is very efficient both in terms of data forwarding and control channel access. Especially for small groups, and more sensitive to network traffic level compared to protocols using redundant forwarding path. E2M (Extended Explicit Multicast) is named Extended Explicit Multicast, which is based on the novel concept of dynamic selection of Xcast Forwarder (XF) between a source and its potential [5].

I.

INTRODUCTION

Ad hoc is a kind of characteristic temporary network formed by a group of mobile nodes, which is independent of any existing network infrastructure or centralized management. With strong self-organizational, robust and indestructible characteristic, it is mainly used for military battlefield, medical emergency, flood fighting relief and some emergent situation without wire communication devices [1]. Todays multicast schemes can not only reduce the processing overhead of the multicast transmission, but also minimize the bandwidth consumption. Therefore, using multicast group communication mechanism is quite necessary for the mobile Ad Hoc network whose bandwidth is extremely limited. However, the Ad hoc environment is typically characterized by energy and bandwidth-constrained, dynamic and security, leading to frequent and unpredictable connectivity changes [2, 3], the design of routing protocols becomes a challenge. While traditional IP multicast schemes are scalable for large multicast groups, they have scalability issues with a large number of distinct multicast groups. The Xcast (Explicit Multiunicast) is a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations address in the data packets, instead of using a multicast group address. Explicit Multicast doesnt

III.

MAODV-X PROTOCOL DESCRIPTION

MAODV-X is an optimized multicast routing protocol based on Xcast and stable link repair, which combines the ideas of explicit multicast with the multicast tree structure of MAODV and uses maximum entropy for the election of stable links. Only the multicast group members and the multicast intermediate nodes possess the specific multicast intermediate node routing tables (INT) which are exclusively defined in the MAODV-X protocol. The node has decided to be a multicast intermediate node as the number of nodes served by it is greater than a threshold. The structure of extended multicast intermediate routing table is shown in Figure 1.

multicast group or multicast intermediate node, Join RREQ message should be broadcasted; the field of destination address should be set to the IP address of the multicast group G while the expansion domain which contains the address of the head of the multicast group is canceled. The nodes who receive the Join RREQ message for the first time will look up the intermediate node routing tables to examine the existence of the entries of multicast group G. If there are no entries of G, then it will simply unicast or broadcast the received Join RREQ message. This process only stops if the head node of G is found and the successful path established. The node is probably the head node of the multicast group if the upstream nodes are not in the table. 2) route response If a node which is a multicast intermediate node or a multicast group member node of G receives a Join RREQ message which is sent to the multicast group, it can respond the Join RREQ message only when the recorded sequence number of the multicast group G is no less than the one contained in the Join RREQ message. The response node updates the field of downstream node address information in routing table and the INT with the request node information, and then generates a RREP message and unicast it to the request node of the Join RREQ message. The node who receives the Join RREQ message will check whether it has an INT and then check whether it holds the item of G in the INT. It will continue to unicast or broadcast the Join RREQ message if it has not the item of G in the INT, otherwise, the multicast member node will 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 RREP message directly. The Join RREP which is sent back to respond the Join RREQ will set the J flag to 1 which represent the RREP for Join RREQ, and it is unicasted along the reverse path of Join RREQ until forwarded to the request node. After receiving the extended RREP, the request node will send an extended HELLO message to its unicast previous node. The node who receives the extended HELLO will add 1 to the threshold counter, the key word of which is the combination of the source IP address and the multicast group address, and then compares the value of the threshold counter with the preset value, thus determine whether there arise a new multicast intermediate node. The unicast previous node will continue to forward the extended HELLO to its unicast previous node when the value of the threshold counter is less than the preset value; otherwise, the unicast previous node turns into a multicast intermediate node, it will add the request node address in the extended HELLO into the field of downstream node address of INT, then send a extended HELLO back to the request node to inform the appending of the upstream node, finally send a extended HELLO to its unicast previous node to show the accession of a new multicast intermediate node. The unicast previous node who receives the extended HELLO message will be carried on recurrently until the extended HELLO message arrive the node in which the value of threshold counter is bigger than the preset value or the extended HELLO message is sent to the head node of the multicast group.

Figure 1

Structure of INT

In this structure of INT, the item of upstream node refers to the previous multicast intermediate node. The field of upstream node address is set to be empty by the source node. The downstream nodes are connected by the chained list and the data packets are forwarded by the way of unicast. The field of downstream node address is set to be empty by the destination node. A. Establishment of multicast group based on explicit multicast 1) route request When 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 send a route request (RREQ) message, in which J flag bit is set to 1, named Join RREQ. The request node A determines broadcast or unicast Join RREQ message according to the available information in it. If node A has a path to reach the multicast intermediate nodes, multicast group member nodes or the head of the multicast group, then the Join RREQ message will contain the node's IP address in the multicast group G, and then will be unicasted to the node. After receiving the Join RREQ message, only the node which is a multicast intermediate node, a multicast group member node or head node of multicast group can respond the message, other nodes unicast or broadcast it directly. If node A does not know any nodes in the multicast group, it only broadcasts RREQ messages until finding a multicast intermediate node, member node or head node of the multicast group. The request node will rebroadcast another RREQ message if 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 if it still has not received the RREP messages before timeout, but rebroadcast times should not exceed the value of RREQ_RETRIES. The source node considers the multicast group G is unreachable or not exists if it doesnt receive RREP messages ultimately. At this time, the source node A is the only group member, that is, the head node of the multicast group, and it will also initialize the sequence number (set to 1) of the multicast group G. If the head node of the multicast group G cant be found, or the node is no longer the head of the

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

our proposed scheme also considers the queue utilization of each intermediate node. As the intermediate node selected is almost exhausted, it probably induces frequent and unpredictable connectivity changes. On the other hand, if the queue is nearly at full capacity (is nearly loaded to full capacity), the arriving packets appear to be lost in the event of congestion. Consequently, both remaining energy and queue utilization would impact on link stability. The following paragraph will describe about how to achieve relative stable links to establish a backup path. a) metric of node energy In view of some nodes being exhausted due to the heavy traffic in the Ad hoc networks, if such nodes are chose to make a backup path as disconnection happens, it would deplete energy supplies utterly and incur more frequent link repair, increase process spending. Accordingly, the residual energy of nodes is an important fact depicted as bellow:

Figure 2

Topology after joining multicast group

As 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 will send an extended HELLO message to node N1 and add 1 to the threshold counter after received the RREP message. As N1 is a multicast intermediate node, it needs to update its downstream nodes item in INT and sends an extended HELLO message to node A. Node A will set its upstream node to N3 after receives the extended HELLO which is send by N1. The changed intermediate node routing table of N1 is shown in Figure 3.

Si ( n ) =
Where

Eri ( n ) E 0i ( n )

Si ( n )
i

and 0 represent the surplus energy and initial energy respectively.

Figure 3 Intermediate node routing table of N1 after Join RREP

E ( n)
i r

E (n)

express the survival probability of node i,

B. Tramission of multicast group data As 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 downstream node N2 in its INT, as S is the source node, the item of upstream node address is set to be empty. The packets will be forwarded firstly to the node N1, N1 will check whether it has a multicast intermediate routing table and whether it concludes source node S and the multicast group address in its INT. Node N1 will forward the data packets to N2 along the path of unicast. Node N2 will check its source node address and multicast group address after receiving a data packet and unicasts the received data packet to its downstream nodes N3 and N6 according to the downstream node address in its INT, The process of data forwarding is the same with above, and will continue until a multicast member node receives the multicast data packets. When all the multicast member nodes receive the multicast packets, the multicast process will be over. C. Stable-aware link repair The features of MANET and the heterogeneity of its nodes may lead to frequent disconnect and link repair. It is necessary to find a stable link to construct backup path and postpone the next repair operation, therefore to extend the survival time and promote the stability of repaired path. 1) Consideration on the stable link selection Nodes in Ad Hoc networks, such as PDA, are typically characterized by energy and bandwidth limited, meanwhile,

b) metric of queue length As the queue buffer exceeds the supply, the traffic will be bottled up at the egress. If the buffer is overflow, the arriving packets would be dropped, thereby, the relative empty buffer implying no or less congestion is suitable to be utilized during the link repair process. The congestion degree is evaluated:

Ci ( n ) = 1
Where

Qci ( n ) i Q0 ( n)

Ci ( n )

and present the length of occupied queue buffer and length of original queue buffer respectively. The essential factors introduced above which impact on link stability, is normalized to achieve stability coefficient shown as Equ.3:

Qci ( n )

i Q0 ( n)

indicates the congestion degree of node i

pi ( n ) = Si ( n ) + Ci ( n )
Where

pi ( n )

node stability,

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

and are normalized parameters, constants,

is stability coefficient used to evaluate the

h ( x ) = p ( x ) log 2 p ( x )

Where of event x.

h ( x)

is value of entropy,

p ( x)

is the probability

In order to measure the stability of link, in the maximum entropy theorem is regarded as stability coefficient. The bigger the value of entropy is computed, the more uncertain the link is, and vice versa. Thus it is concluded that the link which has a least entropy of stability coefficient is the most stable link. The entropy of stability coefficient is given as:
i hi ( n ) = pk ( n ) log 2 pki ( n ) k =0 t

p ( x)

RREQ message and compares the entropy values of stability coefficient in the received Repair RREQ messages during the interval before the Timer T is time out, then choose the links with the least entropy value accumulation to construct an new path, which is considered as the most stable one. The other Repair RREQ messages received after the Timer T is time out are dropped directly. As shown in Figure 4, N6 transmits the Repair RREQ message to its neighbors with the initial entropy value=0. The node receiving the first message computes the stability coefficient value and portion of entropy value of stability coefficient according to Equ.5, and adds up with the value placed in the message that is forwarded or broadcasted continually. It is supposed that the Repair RREQ messages forwarded by R1 and R2 are delivered to source node S. If the entropy value accumulation of stability coefficient from R1 is less than from R2, then node S choose the path from R1 to S as backup path. If the entropy value accumulation of stability coefficient from R1 and R2 are equal, then node S choose the path along which the Repair RREQ message comes to S first to be backup path. At present, node S transmits RREP message with flag bit R set to 1, named Repair RREP, return to N6 through R1 along the same path as Repair RREQ. The repaired path is shown as in Figure 5.

Where link i,
i k

hi ( n )
i pk (n)

presents the entropy of stability coefficient in presents stability coefficient of node t in link i,

denotes a portion of entropy of stability coefficient computed in each node by which the whole entropy of stability coefficient of links is achieved, and source node can choose the most stable links to repair the disconnect path, furthermore to avoid frequent repair. 2) Link repair When an intermediate nodes upstream node is unreachable, the intermediate node send N_RERR message to the downstream node, which forwards the message to its downstream node, until the multicast destination node. Shown as Figure 4, the repair procedure is described.

i p ( n ) log 2 pk (n)

Figure 5

Repaired topology

Figure 4

Demonstration of multicast link repair

During the transmitting, the link between N4 and N5 is broken, N6 sends N_RERR message to N7 and R6 without receiving 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 to 1, named Repair RREQ. The neighbors receiving the message computes the stability coefficient itself according to Equ.5, and then gets the portion of entropy of stability coefficient which is added with the entropy accumulation in Repair RREQ message and broadcasts it continually, until reaching the multicast intermediate node or multicast group member node. The node forwards it looking up the multicast intermediate node routing table or broadcast it to the head of the multicast group. The head node actuates a timer T after receiving the first Repair

When the repair-actuating node N6 receives the Repair RREP message, it transmits an extended HELLO message to its previous hop R1, which is similar to the process to join the multicast group, to update the multicast group intermediate node routing table. Since R1 becomes a multicast intermediate node, it augments an entry of node R6 address as downstream node 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 downstream node N7 and R6 to inform the accomplishment of multicast repair procedure. IV. SIMULATION RESULTS

To evaluate the performance of the protocol MAODV-X, we use NS2-2.26 as the simulation platform. In our simulation study, it is assumed that 50 mobile nodes spread over a topology of 1500m300 m, with a channel bandwidth of 2 Mbps, each flow has been executed for 910 sec. The source node of CBR data flow and multicast group members who request to join the group are randomly selected. The source node and destination nodes of CBR flow are fixed in the simulation. In the following simulations, we have considered CBR traffic with payload size set to 512 bytes. Data packets

are generated at the selected source node at a constant rate of 2 packets per second. When the simulation starts, each node randomly picks a destination and moves towards it with a random constant speed which is specified. After a node reaches its destination, it stays for an interval and then randomly picks another destination and starts moving towards this 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 size The simulation results are shown in Figure 6~9. The performance in all aspects of these protocols including MAODV-X, MAODV and E2M, declines when the number of nodes in the multicast group increases from 10 to 50. This is because as the number of nodes within the multicast group increases, the group size will increase, thus lead to frequent and unpredictable connectivity changes which will generate additional overhead.
Figure 9 Number of Link Repair

As seen from Figure 6, the packet delivery rate of E2M is superior to that of MAODV-X and MAODV when the multicast group size is small, however, with the increase of multicast group size, the packet delivery rate obviously reduces due to the blind flooding scheme in the explicit multicast. Both MAODV-X and MAODV are better than E2M with the aid of the tree-based structure; furthermore, MAODV-X excels MAODV for its simplifing the tree-based structure. Figure 7 shows that E2M performs worse than MAODV-X and MAODV on the end-to-end delay similarly due to the blind flooding scheme.While MAODV-X and MAODV are both tree-based protocols, the end-to-end delay doesnt differ much during the multicast group size changes. The results in Figure 8 show that E2M demands minimum control overhead since it is based upon explicit multicast and adopts unicast approach to multicast, moreover the majority of control messages of it is based on definite link conditions. Nevertheless, MAODV is a tree-based protocol, many nonmulticast member nodes may become tree nodes, which will produce a large number of maintenance information in the multicast group, leading to the increase of network control overhead. MAODV-X is also based on explicit multicast, and it simplifies the multicast trees with downstream nodes and thus induces less control messages, so MAODV-X is also better than MAODV. The E2M forwards data by the way of blind flooding and it doesnt need to repair links, so we just compare the MAODVX and MAODV. Figure 9 depicts that there is almost no difference on the number of links repair when the multicast group is small. As the number of nodes within the multicast group increases, some nodes may be overloaded because of the unequal link distribution, this may easily results in disconnected link owing to the inadequate energy. MAODV doesnt take into account the stability of the link in the period of link repair while MAODV-X chooses one of the most stable links using the maximum entropy in Shannon theorem during the repairing procedure and avoids frequent link repair. B. Different maximum moving speed The simulation results are shown in Figure 10~13. Along with the maximum moving speed of each node gradually increases from 0m/sec to 20m/sec, the performance in all aspects of the MAODV-X, MAODV and E2M protocols are decreased, since the higher the moving speed is, the rapid the network topology changes.

Figure 6

Packet delivery ratio

Figure 7

End-to-end delay

Figure 8

Control overhead

The result in Figure 11 shows that the average end-to-end delay of MAODV-X is relatively stable. Links are likely to break down due to the frequently changed network topology due to the increase of maximum moving speed, and the endto-end delay of MAODV may often twitter accordingly while E2M performs even worse for its blind flooding mechanism. MAODV-X is more stable for it is capable of choosing a stable link to avoid frequent link repair. AS shown in Figure 12, MAODV-X make a better performance than MAODV but worse than E2M on control overhead for its tree-based structure, with the increase of the maximum moving speed. Figure 13 shows that the stability of MAODV-X is better than that of MAODV, as it is able to choose a stable link and use the unicast approach while building a multicast tree or updating the multicast intermediate node routing table. V. CONCLUSION

Figure 10 Packet delivery ratio

Figure 11 End-to-end delay

The investigation presents a multicast routing protocol MAODV-X by syncretizing the idea of tree-based routing approach and explicit multicast routing. The specific multicast intermediate node routing table is designed to simplify the multicast tree, reduce the control overhead to deal with construction of the multicast tree. The explicit multicast IP address is predigested due to the specific multicast routing stable to avoid analyzing the explicit multicast IP header. The maximum entropy theorem of Shannon is utilized to compute the entropy value of stability coefficient through remaining energy and queue utilization, by which the most stable backup path can be determined during the link repair to decrease the repair times. The experiment results demonstrate that the proposed protocol outperform the counterparts in some extent. REFERENCES
[1]

Figure 12 Control overhead

[2]

[3]

[4] [5]

[6] Figure 13 Number of link repair

Figure 10 shows that, with the maximum node moving speed increases, the packet delivery ratio of MAODV-X is superior to that of MAODV and E2M, because MAODV-X adopts the idea of explicit multicast at the moment of the multicast group establishment and simplifies the multicast tree by unicasting, reducing the dependence of some nodes, hence improves the average packet delivery ratio.

[7] [8]

Lee S J, Su WHsu J. A Performance Comparison Study of Ad Hoc Wireless Multicast Protocols [J]. IEEE INFOCOM2000565-574. Yu-Feng Jia, Ying-xin Hu. Improvement of Wireless Multicast Routing with Link State Based on MAODV [C], 4th International Conference on Wireless Communications, Networking and Mobile Computing, 2008, 1-5. Narsimha, G., Venugopal Reddy, A, Sarma, S S V N. The Effective Multicasting Routing Protocol in Wireless Mobile Adhoc Network[C], Sixth International Conference on Networking, ICN '072007 , 15-17. R Boivie, N Feldman, Y Imai, W Livens, D Ooms. Explicit Multicast(Xcast) Concepts and Options [S]. RFC5058, Nov 2007. Abderrahim Benslimane, Cdric Ferrari, Abdelhakim Hafid. EM2NET: an Energy-Saving Explicit Multicast Protocol for MANETs[C], Global Telecommunications Conference, 2007, 592-597. Malarkodi B, Gopal P, Venkataramani B. Performance Evaluation of Adhoc Networks with Different Multicast Routing Protocols and Mobility Models [C], Advances in Recent Technologies in Communication and Computing, 200981-84. [6] Prabha Ramachandran. Source authentication for mutlicast in Mobile Ad Hoc networks [D], University of Maryland, 2003. Morais Cordeiro, C Gossain, H Agrawal D P. Multicast over wireless mobile Ad Hoc networks: present and future directions [J], Network, IEEE , 2003, Vol17: 52-59.