Essay details:

  • Subject area(s): Engineering
  • Price: Free download
  • Published on: 7th September 2019
  • File format: Text
  • Number of pages: 2

Text preview of this essay:

This page is a preview - download the full version of this essay above.

Chapter 7

QOS for Multicast Routing “MTQOSM”

In this chapter, we describe the Multiple Trees Quality of services Multicast protocol (MTQOSM) in detail. Experimental results are presented, which illustrate the effectiveness and high performance of the MTQOSM compare with the same protocol with one tree and double trees in WMNs.

7.1 Introduction

Wireless Mesh Network has emerged recently as a new class of networks. A WMN is self-organized; self-configured, self-established and self-maintained the connectivity between nodes, these characteristics bring many advantages to WMNs such as low installation cost, reliability, self-management and easy maintenance [1]. Multicast is one of the most challenging in WMN which is the delivery of Information from one sender to many receivers simultaneously in an efficient manner. Important applications of multicast include audio/video conferences, distance education, and distributed software and games. One of the famous challenging issues in WMN is how to efficiently support multimedia applications like mobile TV and audio/video conferencing. Multimedia communications have more stringent QoS requirements that must be fulfilled to provide an acceptable service. In particular, multimedia traffic is characterized by strong time sensitivity and inelastic bandwidth requirements. These applications require a guarantee on delay, jitter, packet loss, and throughput to guarantee QoS to end users. Although multicasting is an enabling technology for bandwidth management, however, owing to the shared nature of the wireless medium and limited bandwidth, designing multicast routing algorithms and protocols able to satisfy a set of QoS constraints for different application services on wireless mesh networks is still a challenging research problem [2].

7.2 The Proposed protocol (MTQOSM)

In this section, we elaborate our proposed MTQOSM protocol.

7.2.1 Brief

MTQOSM is an efficient approach to robust multicasting using multiple trees. The tree used in multicast session must be has the maximum number of nodes-disjoint to obtain reliability in case of breakdown in the path and to guarantee the QoS lead to high performance in the network. Our objective here is to find out nodes-disjoint trees between source & destination where each tree has at least all those nodes which wants to participate as receivers in that tree and each receiver has a list of trees that it wants to participate in is represented through a bit vector.

7.3 Graph approaches

      To achieve the maximum reliability even in the case of breakdown of trees, multicast session must be as disjoint as possible. Hence communication in multicast trees has to find out node-disjoint as possible (meaning forwarding nodes in each tree are separate). Theoretically we can have many node-disjoint trees as the network allows. But the network can afford in case of resource constraints at nodes impose some upper bounds on the number of such trees. Hence there is a trade-off between resource usage video qualities. We need in such a case to construct node-disjoint multicast trees as max as we can in the network. Also based on the video encoding and streaming options available at the multicast source, maybe some receivers only want to connect up-stream. Hence a list of trees in each receiver aims to participate in. These trees have to be node-disjoint for robustness. Hence we need to maintain maximal node-disjoint multicast trees where receivers need not be a part of all the trees. Some nodes which are receiving from other nodes can be as forwarding node. Further, a node that is receiver can be in one or more multicast session as an intermediate node. A finding the maximum number of node-disjoint paths between two given nodes can be solved in polynomial time [3]. Our objective is to find out node-disjoint trees between the source and receiver nodes such that each tree contains at least all those nodes which wish to participate as receivers (leaves) in that tree. That is each receiver has a list of trees that it wants to participate in. we participate through bit vector the list of trees that a receiver wants to participate in. If the ith bit in the bit vector is set then the receiver wants to participate in the ith tree.

7.3.1 Online heuristic

Here we will go profoundly on an online heuristic answer for locate a given number of node-disjoint multicast trees. We mean to discover the maximum node-disjoint multicast trees (permitting some measure of cover) in the network. Additionally, keep up them for transporting video sub streams given by MDC coder. This cover prompts minimizing in robustness however as demonstrated even with the complete knowledge of network topology we may have no polynomial time answer for our issue of discovering node-disjoint trees. Also, it is surely understood that keeping up complete network topology in Ad hoc networks includes high overhead as the topology keeps consistently changing because of mobility of the nodes. Subsequently we require a dispersed way to deal with build multicast trees and not a centralized one. Additionally in a practical multicast situation collectors continue joining and leaving the multicast group as time progresses. Subsequently a centralized heuristic methodology would not work proficiently as the heuristic needs to connect over and over to represent receivers joining and leaving. The heuristic must be online to accept receiver request to join and to leave on the fly. These two requests are adequate to model such a network where there is no mobility or mobility is low to the point that it could never influence the topology of the network. Mobility is a trademark highlight of Ad hoc network and keep changing the topology of the network continues. Henceforth to model this sort of element framework, we additionally need to incorporate a request called the movement request. This request changes the network topology, unquestionably. The change may be reflected in the various multicast tree system, that is, it may prompt tree break or it may make conceivable outcomes for a superior system (lesser cover). Thus every movement demand changes the nearness matrix and makes probability of upkeep or improvement of the numerous tree system. Heuristic methodologies can lessen the cover by minimizing the quantity of normal nodes among various trees. Thus we propose an distributed online heuristic answer for minimize the quantity of intersections, while serving the request online , among the trees it needs to keep up. Let us consequently call such a system as M-Tree system where we are attempting to keep up M maximally node-disjoint multicast trees. A join request would include passing some control messages in the network and getting the new M-Tree system. A leave request would include permeating up the trees an erase message until a hub without-degree more than one (which demonstrate minimum number of recipients under its branch of tree) in that tree position as indicated by the request. For effortlessness let us expect movements happen in bursts. The explanation behind this suspicion is that it is hard to show a consistently moving node theoretically. Hence we expect that a node moves in blasts of separation and these movement’s' blasts are immediate. These blasts partially catch what can happen in a real network. A network system does not hold up until a node has ended up stationary. Indeed, even mobile nodes take an interest in tree arrangements and repairs. Thus a decent model ought to consider this and make fundamental suppositions to consider investments while the node movement. In this way we accept all movement requests are in blasts of little separations. It is as of now simple to see that, that online algorithm is the best one which serves the request with least message passing, including the least number of message passing, and making minimal expansion in the number of intersections among the trees in the network. In any case, some idea would specifically provoke us to the way that there is mobility. Minimization of forwarding nodes can prompt an issue. At the point when a node moves starting with one place then onto the next, in the network, it may prompt a generous number of receivers subject to this to go vagrant for the time until the system deals with them. Consequently it is to the best advantage not to go for trees attempting to minimize the number of forwarding nodes. In the meantime it would not be suitable to incorporate numerous forwarding nodes. This is on account of a tree system with all the more forwarding nodes prompts more movement request prompting upkeep demands. This perception originates from the way that not all movement request can prompt support demands. but as number of nodes expands, the division of movement request prompting upkeep asks for additionally increments. Thus the issue now comes down to finding an algorithm which serves the requests by minimizing the number of forwarding nodes and minimizing the control overhead furthermore minimizing the part of movement requests prompting support demands furthermore the number of intersections among the trees. We attempt to take care of this issue by a weight (a positive amount used to judge a node) model.

Weight model: we consolidate a punishment system. We punish a node for taking an interest in more than one tree. The punishment instilled increments with the number of trees the node takes an interest in for a given multicast session. We relate a weight with every node. The punishment builds the heaviness of the node as the number of trees it takes an interest in expansions. The system, for every request of multicast session, needs to decrease the aggregate increment in weight of the nodes in the network. In allotting weights to the nodes it must be noticed that a single node serving two trees must measure more than two nodes, which are every serving a tree. So also, it must be noticed that picking a single node for l trees ought to expand the weight more than the situation when l diverse nodes are decided for the l trees. Henceforth the base weight of a node taking an interest in l trees ought to be in any event l times the weight of a node partaking in l - 1 tree. The accompanying cost model fulfils these conditions

The weight of a node in the graph is zero if it participates in no trees for a given multicast session.

The weight of a node in the graph which participates in one tree is x, for some x > 0.

The weight of a node in the graph which participates in l trees, wl, l <= k is l *wl-1+ ‏ y for some y > 0.

The cost of a path is the sum of the weights of the nodes in the path.

The cost of an operation on the graph is the positive change in the total weight of the graph.

The term y can be utilized to measure the quantity of intersections among the trees while node cooperation can be caught by the term x. In the event that x is larger than y then, in the aggregate weight of a path, the commitment made by node interests will overwhelm the commitment made by the number of intersections and the other way around. Getting different parameters like local contention, node bandwidth, remaining battery lifetime, link latency, number of multicast sessions a node participate in, and so forth into weight computation of forwarding nodes could help us in discovering more effective trees. Be that as it may, getting values for some of these extra parameters at the routing layer requires cross-layer arrangements, which is past the extent of our work. In any case, weight capacity proposed in this work gives a general structure to getting other applicable parameters effortlessly into node's weight computation.


     We present our M-trees protocol which is an online algorithm based on the weight model, the weight model is incorporate system which is participate  the nodes with trees in given multicast session, the weight associated with each node, the weight of the node is increase as the number of trees it participates in increases with this node. The M-trees protocol define and manage the requests(join, leave, movement) which movement in wireless mesh network is less compare with Ad hoc. The main things in this protocol:

Minimize the weight

Maximize the node-disjoint multicast trees while processing a request sequence reducing the overhead causes by control messages while the changes in multicast session in topology.

Algorithm 1:    Broadcast Session

S = Sender, AP = Access Point ,

(G,S) = group of multicasting

S sends unicast message to its AP

S register with Information (G,S)

AP broadcast information (G,S) to other APs

The tree initialization stage is started by the receivers. Every node in the network can take part in the M-Tree system either as a receiver or a forwarder. Consequently every node represents  its cooperation in the M-Tree system utilizing a M-bit vector, Mvp. if the jth bit in Mvp is set then the node is either a receiver or a forwarder for the jth tree, Xj. When some node wishes to wind up a receiver, it utilizes a M-bit vector, Mvj, to represent the trees that it wishes to join. In the event that the jth bit is set in Mvj then the node wishes to be a receiver in tree Xj. A node which wishes to end up a receiver in Xj can inconsequentially turn out to be thus, in the event that it is as of now a forwarder in Xj. In this manner the receiver needs to join just those trees where it is not at present taking an interest as a forwarder. Consequently it shapes a K-bit vector, Mvs, which represent the trees for which it is not a forwarder but rather it needs to join. On the off chance that jth bit is set in Mvs, then the node is not a forwarder in tree Xj but rather it needs to participate in that tree now. It then floods the network with a Join Request control packet communicating its desire to participate in the trees represent by Mvs. Subsequently a node needing to wind up a receiver takes after the Algorithm 2, Join Group. The flooded Join Request control bundle achieves diverse node in the network. Any flooding procedure needs a control mechanism to stay away from the circumstance where nodes constantly continue trading the same packet again and again. Thus a node when gets a Join Request control packet needs to check if the packet has been as of now handled by the node some time recently. To make this recognizable proof, every Join Request control packet conveys the full path that it has navigated. On the off chance that the node is in the way crossed by the packet, then the packet is dropped. Generally the node needs to check on the off chance that it can answer to the sender of this Join Request control packet. An answer can be sent just for the situation when the node getting the packet takes an interest in any of the trees looked for by the Join Request control packet. The accepting node needs to check its Mvp to discover to what number of trees it can send an answer. The node then answers utilizing a K-bit vector, Mvr to the sender of Join Request control packet utilizing the Join Reply control packet. In the event that jth bit in Mvr is set then the node is answering for the tree Xj, which means the node takes an interest in Xj furthermore that the Join Request control packet sender needs to join Xj. The Join Reply control packet contains the complete path data to the source, that is, the node and their support vectors in the path to the source for each of the trees represented by Mvr. For whatever length of time that there are trees for which the node can't answer (as it may not participating in them right now), the Join Request control packet must be sent to different nodes. That is, regardless of the possibility that there is one tree for which an answer has not been sent by this node then the node needs to forward the Join Request control packet with the vector Mvf. In the event that the jth bit in Mvf is set then it implies the node can't answer to the Join control packet sender for tree Xj as it doesn't take an interest in it. Algorithm 3, Process Join Request control packet, clarifies how a node that gets a Join control packet forms it.

Algorithm 2:  Joining multicast group

node ← node requesting to join;

Mvp ←M-bit vector representing the participation of node in the tree system as a forwarder;

Mvj ←M-bit vector representing the trees that node seeks to join;

Mvs ← M-bit vector representing the trees that node has to send with Join Request control packet;

needed ← 0;

for i ← 1 to M do

 Mvs[i] = 0;

    if Mvj[i]=  1 and Mvp[i]= 1 then

  Become a receiver in that tree using the existing path as a forwarder;

   end if

   if Mvj[i]=1 and Mvp[i]= 0 then

    Mvs[i]= 1;

    needed ←1;

   end if

end for

if needed = 1 then

Send Join Request control packet with bit vector Mvs;

Set a timer with value MAX_REPLIES_TIMER;

end if

The receiver when gets a Join Reply packet needs to gather the answer and store every one of the path that are gotten because of this answer. For every tree Xj , for which a Join Request control packet was sent, the receiver stores all paths that are gotten. It utilizes reserves to store the path got through Join Reply control packets. Every receiver that has an exceptional Join control packet, which means there is Join Request control packet which has been sent whose clock has not terminated yet, keeps up a reserve called ReplyBuf which stores a specific number of answers per tree. After the MAX_REPLIES_TIMER clock expires, the receiver needs to pick those paths to each of the trees that it looked for, which include minimal measure of weight to the numerous tree system, as this would be instinctively minimizing the intersections among the trees. It assesses all conceivable path mixes that can be achieved each of the trees. Yet, it picks those paths which include minimal measure of weight to the system. Henceforth a receiver upon the expiry of the clock takes after the Algorithm 4, Selected the shortest path.

Algorithm 3:  Process of Joining Request

node ←node that received the Join Request control packet;

Mvp ←M-bit vector representing the participation of node in the tree system as a eceiver/forwarder;

Mvj ←M-bit vector representing the trees that Join Request seeks;

Mvf ←M-bit vector representing the trees that the Join Request has to be forwarded with;

Mvr ←M-bit vector representing the trees that node can send Join Reply for;

path path traversed by Join Request control packet;

repwanted← 0;


 if node is in path do


 end if

for i ←1 to M do

   Mvf [i] ← 0;

   Mvr[i]← 0;

if Mvj[i] = 1 and Mvp[i]= 1 then


   repwanted← 1;

end if

 if Mvj[i]= 1 and Mvp[i]= 0 then

  Mvf [i]←1;


 end if

end for

 if repwanted= 1 then

  Form Join Reply with the complete path information to source for the trees represented by


  Send Join Reply control packet back in the path with Mvr as the vector;

end if

if fwdwanted= 1 then

 Append node to path;

 Forward Join Request control packet with Mvf as the vector;

end if

Algorithm 4:  selected the shortest path

Mvj ← M-bit vector representing the trees that the Join Request;

ReplyBuf ← Array which can store MAX_REPS number of replies per tree;

combo ← Array representing all possible combinations of paths in K trees;

/* comb[i][j] stands for the path to source in jth tree of ith combination of paths */

numCombos ←Number of combinations possible;

minAddedWeight ← INTEGER_MAX;

for i 1 to numCombos do

   nlist ← array of distinct nodes in the paths of combo[i];

 /* nlist now has the nodes in combo½i_ with their present participation vectors */

   oldWeight ← calcWeight(nlist); /* refer Algorithm 5*/

size ← size of nList;

for j 1 to size do

 for k 1 to K do

    if nList[j] is in path combo[i][k] then

Set kth bit in the participation vector of node nList[j];

    end if

  end for

end for

/* nlist now has the nodes with their updated participation vectors according to paths of combo[i] */

 newWeight ← calcWeight(nlist);

 addedWeight←  newWeight-oldWeight;

 if addedWeight < minAddedWeight   then

minAddedWeight ←  addedWeight;

minCombo combo[i];

 else if addedWeight = minAddedWeight  then

    Out of minCombo and combo[i], select the combination that gives maximal node-disjoint  

trees (i.e., the combination having minimum number of y terms in the added weight);

 end if

end for

 Send Join Ack control packets along the chosen

 combination of paths, minCombo;


Algorithm 5:    calculation the Weight (nList)

/* nList is an array of nodes along with their participation vectors */

  size ← size of nList;

  weight ← 0;

for i 1 to size do

   weight ← weight + weight of the node nList[i];

 /* Weight of a node participating in l trees is wl */

end for

return weight;

The receiver now at long last needs to send the Join Ack control packets to recognize the nodes in the paths chosen. It essentially unicasts Ack control packets to its prompt parents in each of the trees and they thusly permeate it up. The nodes getting Join Ack packets build up sending states and initialize clocks for tree support and tree tear down. Tree upkeep is activated when either an information packet or KeepAlive control packet does not touch base from the guardian in time KEEP_ALIVE_TIME. The multicast source begins sending KeepAlive control packets, inactively by piggybacking in information packets or expressly when the source is not sending information briefly. Forwarders thus continue sending these packets down the trees. The KeepAlive likewise has a K-bit vector representing the trees it wishes to revive, it conveys alongside it the path data for these trees, that is, the nodes and their investment vectors. KeepAlive bundles are additionally used to overhaul the path data by the nodes in the trees.

7.4 Simulation Design & Implementation

      For studying on our proposed approach MTQOSM protocol, for QoS multicast routing inside the mesh backbone, we utilized an occasion-driven network test system GloMoSim (Global Mobile Information Systems Simulation library) form 2.03. GloMoSim is a scalable simulation environment for extensive remote and wireline correspondence networks. GloMoSim utilizes a parallel discrete-occasion recreation ability gave by Parsec. GloMoSim reproduces systems with up to thousand nodes connected by a heterogeneous interchanges ability that incorporates multicast, unbalanced correspondences utilizing direct satellite broadcasts, multi-hop remote interchanges utilizing specially appointed network administration, and customary Internet protocols.

7.5 Simulation Steps

      GloMosim can be work in Unix and windows, we used GloMoSim in our simulation in windows 7 system. To carry out the performance study of our approach, we carried out a number of simulation runs using the MTQOSM protocol. In order to study the guarantee QoS multicast routing protocol we used different configuration of MTQOSM protocol. We configured the different parameters in “config” file which is available in bin directory in GloMoSim, and then we visualize the simulation by using GloMoSim visualization tool. Finally we generated static file to get the simulation information as Packet delivery ratio, throughput and End-to-End delay.

7.5.1 Simulation Parameters

Our simulations display a large-size network of 300 mesh routers switches put in a 3000m × 3000m territory. We utilize the expressions "router" and "node" reciprocally. The nodes are appropriated consistently over the sub-territories inside a landscape, and the nodes inside a sub-region are randomly put in that sub-range. There is no network participation through the simulation. Every simulation executes for 600s of simulation time. Numerous keeps running with various seed numbers are led for every trial and gathered information are arrived at the midpoint of over those runs. All nodes are furnished with a 802.11b radio with a data transfer capacity of 11 Mbps and a nominal scope of 250 meters. As MAC layer convention we utilize the 802.11. Traffic model is steady piece rate (CBR). The data packet size is 512 bytes. The extent of the line at each node is 50 Kbytes. All senders and receivers(unicast and multicast) are randomly chosen.

7.5.2 Simulation run time

In order to get stable statistics for the above mentioned combinations of the functions as well as network scenarios, we ran the simulations many times and studied the Packet delivery ratio, throughput and End-to-End delay  reported by the protocol. The next section describes the results and analysis of the simulation runs.


In this section we will illustrate the experimental results in details and showing differences graphs and analysis for MTQOSM.

7.6.1 Simulation Results

In this part, we clarify the execution and performance of the network in term Packet delivery ratio, throughput and End-to-End delay by simulation results to prove the achievement of MTQOSM protocol in WMNs. Our experiments were carried out using GloMoSim, a network simulator for wireless networks. We implemented the complete MTQOSM protocol in GloMoSim.

 We utilize the accompanying measurements to quantify the execution and performance of our protocol and compare it with other existing protocols:

Average Packet delivery ratio (PDR): the ratio of the number of data packet received in the destination compare with the number of data packet send.   (∑'▒'〖'number of packet receive'〗')/(∑'▒'〖'number of packet send     '〗')

Average throughput: Throughput is defined as the total amount of data a receiver divided by the time between receiving the first packet and the last packet.

Average End-to-End delay (EED): refer to the time of transmitted the packet from sender to receiver.

Control Packet Overhead: the total number of control packets originated and forwarded by the protocol.

Latency: is the time taken for a packet to be transmitted end-to-end across a network.

Latency = (Distance Delay) + (Forwarding Delay) + (Protocol Delay) + (Serialization Delay) + (Queue Delay).

All these metrics measure the QoS of multicast protocol.

7.6.2 Simulation Analysis

Here we show how the M-trees protocol performs better than a protocol of one tree or two trees and improving the quality of video at the receivers. We use MDC coder generates 2 descriptions with 24 kbs in each description whereas the total video rate is 48 kbps with 8 frames per second. We compare M=1, M=2, when M=2 we use one tree for each description similarly when M=3 we use one tree for each description which means split the video into 3 descriptions.


Figure 31: show Packet Delivery Ratio with different values of traffic load M=1,M=2

Figure 32: show Packet Delivery Ratio with different values of traffic load and M=1, M=2, M=3

Figure 33: show Throughput with different values of traffic load  and M=1, M=2

In Figure 31 we compare our protocol while using one tree and two trees we can see the different in PDR which is decrease slowly when use two trees compare with one similarly when we use three trees PDR is decreased more slowly than while using two trees as shown in Figure 32. In Figure 33, 34 we compare M=1, M=2, M=3 based on the throughput, as shown in the figures throughput increase. When the traffic is low throughput approximate similar for M=1, M=2 when the traffic is high throughput increased mostly when we use M=3. This is incur due to the upload in each node and path too.                      

We can significant the different in the all metrics the different between m=1,m=2,m=3.

In Figure 35, 36 M=3 has the lowest average End-to-End delay due to the maximum node-disjoint has in M=3 which able to forward the packets through multiple nodes/paths. M=1 provides the highest average EED due to the uploading occur in nodes along with one path only ( has minimum node-disjoint).

Figure 34: show Throughput with different values of traffic load and M=1, M=2,M=3

Figure 35: show End-to-End Delay with different values of traffic load and M=1, M=2

Figure 36: show End-to-End Delay with different values of traffic load and M=1, M=2,M=3



Figure 37: show Packet control overhead with different values of traffic load and M=1, M=2

In Figure 37, 38 we compare M=1,2,3 based on control packet the longest path and the minimum node-disjoint causes overhead under high traffic. M=3 has the lowest average of packet overhead due to the maximum node-disjoint has which distribute the overhead of packets.


Figure 38: show Packet control overhead with different values of traffic load and M=1, M=2,M=3

In Figures 39, 40. We examine the latency of network, M=3 has the minimum number of latency due to the maximum node-disjoint which distribute the packets and forward it through different paths

Figure 39: show Latency with different values of traffic load and M=1, M=2


Figure 40: show Latency with different values of traffic load       and M=1, M=2,M=3


7.7 Summary

In this chapter, we design a multiple trees protocol (M-trees) which define the maximum node-disjoint multicast tree. Our protocol has the ability to forwards video multicasting using two or three trees without doubling or tripling the overhead. Simulation result through Glomosim prove that multiple tree M=2 or M=3 enhance the QoS multicast routing.


[1] R. Bruno, M. Conti, and E. Gregori, “Mesh Networks: Commodity Multihop  Ad Hoc Networks,” IEEE Communications Magazine, March 2005.

[2] Ajish Kumar K.S, Saumya Hegde: “Multicasting in Wireless Mesh Networks: Challenges and Opportunities” 2009 International Conference on Information Management and Engineering.

[3] L. Li, T.A. Marsland, A parallel algorithm for finding a maximum flow in 0–1 networks, in: Proceedings of Annual Conference on Computer Science, 1987, pp. 231–234.

[3] W.A. Shittu , Aisha-Hassan A. Hashim, F. Anwar, & W. Al-Khateeb: “A Proposed QoS multicast Routing Framework for Next-Generation Wireless Mesh Network”. IJCSNS International Journal of Computer Science and Network Security, 280 VOL.8 No.9, September 2008.

[4] Bo Rong et al:” Enhanced QoS Multicast Routing in Wireless Mesh Networks”. IEEE TRANSACTIONS ON WIRELESS COMMUNICATIONS, VOL. 7, NO. 6, JUNE 2008.

[5] Liang Zhao , Ahmed Y. Al-Dubai , Geyong Min:” GLBM : A new QoS aware multicast scheme for wireless mesh networks”. The Journal of Systems and Software 83 (2010) 1318–1326.

[6] Ehsan Pourfakhar , Amir Masoud Rahmani: “A hybrid QoS multicast framework-based protocol for wireless mesh networks”. Computer Communications 33 (2010) 2079–2092.

[7] Rehab F. Abdel-Kader: “Hybrid discrete PSO with GA operators for efficient QoS-multicast routing”. Ain Shams Engineering Journal (2011) 2, 21–31.

[8] Bheemarjuna Reddy Tamma, Anirudh Badam , C. Siva Ram Murthy , Ramesh R. Rao: “K-Tree: A multiple tree video multicast protocol for Ad hoc wireless networks”. Computer Networks 54 (2010) 1864–1884.

[9] Aaron Striegel and G. Manimaran, Iowa State University:” A Survey of QoS Multicasting Issues”. IEEE communications Magazine • June 2002.

[10] Chems eddine Bemmoussat , Fedoua Didi,  Mohamed Feham: “ A Survey on QoS in Wireless Mesh Network”. MESH 2012 : The Fifth International Conference on Advances in Mesh Networks.

[11] Aslam Qureshi, Dr. Trilok Chand Aseri : “Quality of Service Issues in Wireless Mesh Networks”. 2nd National Conference on Challenges & Opportunities in Information Technology (COIT-2008) RIMT-IET, Mandi Gobindgarh. March 29, 2008.

[12] X. Masip-Bruin et al : “Research challenges in QoS routing”. Computer Communications 29 (2006) 563–581.

[13] Nazanin Magharei, Reza Rejai, Yang Guo: “Mesh or Multiple-Tree: A Comparative Study of Live P2P Streaming Approaches”. INFOCOM 2007. 26th IEEE International Conference on Computer Communications. IEEE

[14] Garima Sharma, and Dinesh Arora: “ Performance Comparison of Mesh based and Tree based Multicast Routing Protocols in MANETs “.International Journal of Current Engineering and Technology.

[15] Ping Chen, Tian-lin Dong : “A fuzzy genetic algorithm for QoS multicast routing”. Computer Communications 26 (2003) 506–512.

[16] Chao-Hsien Chu et al : ”A Heuristic Ant Algorithm for Solving QoS Multicast Routing Problem”. ©2002 IEEE.

[17] Hua Wang et al : “A tree-growth based ant colony algorithm for QoS multicast routing problem”. Expert Systems with Applications 38 (2011) 11787–11795.


...(download the rest of the essay above)

About this essay:

This essay was submitted to us by a student in order to help you with your studies.

If you use part of this page in your own work, you need to provide a citation, as follows:

Essay Sauce, . Available from:< > [Accessed 06.06.20].