CROSS REFERENCE TO RELATED APPLICATIONS

[0001]
The present application is a continuation of U.S. patent application Ser. No. 13/693,368, filed Dec. 4, 2012, which is a continuation of U.S. patent application Ser. No. 12/779,934, filed May 13, 2010, now U.S. Pat. No. 8,325,612, issued Dec. 4, 2012, which is a continuation of U.S. patent application Ser. No. 11/565,105, filed Nov. 30, 2006, now U.S. Pat. No. 7,719,988, which is a nonprovisional of U.S. Provisional Patent Application No. 60/740,865, filed Nov. 30, 2005, the entirety of which are expressly incorporated herein by reference.
BACKGROUND OF THE INVENTION

[0002]
A mobile ad hoc network consists of a set of mobile nodes which are free to move and are interconnected through wireless interfaces. Nodes which are not able to communicate directly, use multihop paths using other intermediate nodes in the network as relays. So, a mobile ad hoc node can act both as a mobile router and a mobile host. In addition, the continuous topology changes, the strong requirements in minimizing battery consumption (in devices which are power constrained) as well as the limited network resources, make the problem of routing in these networks a real challenge. However, their completely distributed nature and their ability to operate without depending upon the deployment of any infrastructure, makes them an ideal component of future mobile computing scenarios. These scenarios include among others emergency situations, battlefield assistance and search and rescue operations. Hence, the interest in mobile ad hoc networks is expected to increase in the future.

[0003]
Multicast is one of the areas in mobile ad hoc networks which is to play a key role in future wireless networks. Key to this is the fact that most of the application scenarios for mobile ad hoc networks are strongly based on manytomany interactions and they require a high degree of collaboration among terminals. Many services such as multimedia applications, service discovery and many other bandwidthavid applications can strongly benefit from the underlying support of efficient multicast communications.

[0004]
The problem of the efficient distribution of communication traffic from a set of senders to a group of receivers in a datagram network was initially studied by Deering [1]. Several multicast routing protocols like Distance Vector Multicast Routing Protocol (DVMRP) [2], Multicast Open Shortest Path First (MOSPF) [3], CoreBased Trees (CBT) [4] and ProtocolIndependent Multicast (PIM) [5] have been proposed for Internet Protocol (IP) multicast routing in fixed networks. However, these protocols are not able to perform well in highly mobile and topology changing scenarios such as ad hoc networks. The main reason is that their forwarding structures are fragile. Thus, the cost in terms of the control overhead which they would require to recompute their multicast trees whenever one of the links in the tree breaks, makes unreasonable their deployment in a mobile ad hoc network.

[0005]
Several multicast routing solutions specifically designed for ad hoc networks have been proposed in the literature [6]. In general, these protocols can be classified into two groups: treebased and meshbased approaches. Treebased schemes construct a multicast tree from each of the sources to all the receivers. Examples of protocols following this approach are Adhoc.

[0006]
Multicast Routing protocol utilizing Increasing idnumberS (AMRISU) [7], Multicast Ad Hoc OnDemand Distance Vector (MAODV) [8], Lightweight Adaptive Multicast (LAM) [9] and Adaptive Demand Driven Multicast Routing (ADMR) [10]. The main advantage of using a tree as the underlying forwarding structure is that the number of forwarding nodes tends to be reduced (although not necessarily optimized). However, a tree is very fragile when there is a high mobility in the network. Meshbased approaches like OnDemand Multicast Routing Protocol (ODMRP) [11] and CoreAssisted Mesh Protocol (CAMP) [12], by using additional links in their underlying forwarding structure, manage to deal with mobility very efficiently. The main drawback of using a mesh is that, due to the additional paths which are created, duplicated data packets can make an excessive consumption of network resources even if a duplicate detection is used. The usual metrics used in the literature to assess the effectiveness of a multicast ad hoc routing protocol are usually related to the control packet overhead. Previous studies have generally neglected the huge impact that the data overhead may have in the overall performance of a protocol. In fact, if we take into account that data traffic consumes more bandwidth than control traffic, the overhead due to the selection of suboptimal routes may easily become more expensive in terms of bandwidth and energy consumption than the cost of sending a few more control packets.

[0007]
Data Overhead in Ad Hoc Multicase Routing

[0008]
The goal of multicast routing protocols in ad hoc networks is finding a set of relay nodes so that data packets sent out by multicast sources can be delivered to multicast receivers. Obviously, the number of those relay nodes is lower than the number of nodes except in the case of flooding. The paths defined by the union of all these nodes may resemble different forwarding structures such as shortest path trees, shared trees, minimal Steiner trees, acyclic meshes, etc. In general, the underlying forwarding structure is protocolspecific because it strongly depends on the path creation process implemented by that particular protocol. We define forwarding nodes as those nodes which are in the path between any source and any receiver. Note that even a source or a receiver can also be a forwarding node. FIG. 1 shows a multicast tree in which we identify forwarding nodes by a double circle. Wider lines represent the forwarding structure induced by the forwarding nodes.

[0009]
There are two basic approaches to build multicast trees: shortest path trees and shared trees [18]. Given a multicast source s, a shortest path tree is formed by the aggregation of the shortest paths from any receiver r to s. The main advantage of this kind of tree is that each destination receives multicast data through its best route, which usually means that the latency from s to each r is also minimized. However, these trees are not optimal in terms of the overall number of transmissions required or the number of forwarding nodes which are required. So, they do not provide optimal bandwidth consumption.

[0010]
A second variant are the socalled shared trees. Shared trees try to reduce the cost of the multicast tree by reducing the number of links which are required to connect sources and receivers. This is done by selecting the links in the tree which can be used by a bigger number of receivers. Of course, in the resulting tree, individual paths from sources to receivers might not be optimal. For the particular case of ad hoc networks, other approaches like the use of multicast meshes with redundant links have been proposed in protocols like ODMRP [11] and CAMP [12]. These structures are particularly interesting to deal with mobility of the nodes, but obviously they do not minimize the cost of multicast forwarding.

[0011]
The problem of finding a minimum cost multicast tree is wellknown as the minimum Steiner tree problem. Karp [19] demonstrated that this problem is Nondeterministic Polynomial (NP)complete even when every link has the same cost, by a transformation from the exact cover by 3sets. There are some heuristic algorithms to compute minimal Steiner trees. For instance, the Minimal Steiner Tree (MST) algorithm ([20, 21]) provides a 2approximation, and Zelikovsky [22] proposed an algorithm which obtains an 11/6approximation. However, given the complexity of computing these kinds of trees in a distributed way, most of the existing multicast routing protocols use shortest path trees, which can be easily computed in polynomial time. For meshbased forwarding, the multicast mesh is usually computed as the union of various shortest path trees.

[0012]
However, the problem of minimizing the cost of a multicast tree in an ad hoc network needs to be reformulated in terms of minimizing the number of data transmissions. Given the broadcast nature of wireless ad hoc networks, a minimum Steiner tree does not minimize the cost of the multicast tree. The cost assignment function used in wired networks is not welldefined for ad hoc networks. That is, by assigning a cost to each link of the graph, existing formulations have implicitly assumed that a given node v, needs k transmissions to send a multicast data packet to k of its neighbors. However, in a broadcast medium, the transmission of a multicast data packet from a given node v to any number of its neighbors can be done with a single data transmission. Thus, in ad hoc networks the minimum cost tree is the one which connects sources and receivers by issuing a minimum number of transmissions.

[0013]
FIG. 2 shows different multicast trees connecting the source (5) to the set of receivers (R). As it is depicted in FIG. 2( a), the union of the shortest path trees results in 3 forwarding nodes. Thus, number of transmissions is 4, one performed by the multicast source and one for each of the forwarding nodes. Similarly, the number of transmissions for the Steiner tree (see FIG. 2( b)) is also 4. We can see from FIG. 2( b), how the Steiner tree tries to minimize the number of nonterminal nodes (i.e. nodes which are not either senders or receivers) which take part in the tree. These nodes are also known as Steiner nodes. Finally, we see in FIG. 2( c) that the minimal data overhead tree, which takes into account the broadcast medium of the network, is able to cover all the receivers with only 3 transmissions. This shows that the Steiner tree problem fails to provide the minimal cost multicast tree in these networks.

[0014]
Several protocols have been proposed for multicast routing in mobile ad hoc networks. They can be classified into tree or meshbased depending upon the underlying forwarding structure that they use. Treebased schemes [710, 13] construct a multicast tree from each of the sources to all the receivers using any of the tree computations schemes, discussed in more detail below. Meshbased approaches [11, 12], compute several paths among senders and destinations. Thus, when the mobility rate increases they are able to tolerate link breaks better than treebased protocols. Hybrid approaches [14, 15] try to combine the robustness of meshbased ad hoc routing and the low overhead of treebased protocols. Finally, there are stateless multicast protocols [16, 17] in which there is no need to maintain a forwarding state on the nodes. For instance, if the nodes to traverse are included in the data packets themselves. The heuristic proposed herein is mainly targeted to meshbased multicast routing protocols and we therefore focus our discussion on the protocols falling in this category.

[0015]
ODMRP [11] and CAMP [12] are the bestknown meshbased multicast ad hoc routing protocols. CAMP was designed as an extension of the “Core Based Trees” (CBT [4]) protocol, offering multiple paths, and relieving the core nodes from doing data forwarding. On the other hand, ODMRP introduces the concept of the forwarding group (FG) as the set of intermediate nodes taking part in the multicast mesh. Both of them are able to achieve very high packet delivery ratios, and they both guarantee that the shortest paths are included in the multicast mesh. However, they do not attempt to minimize the data overhead incurred by not selecting minimal cost paths. Most of the works in the literature dealing with the problem of minimizing the costs of multicast trees are related to wired multicast routing. There are many works which propose approximations to Steiner trees. For instance, Jia [27] proposed a distributed heuristic for the Steiner tree problem being able to provide suboptimal multicast trees satisfying certain delay bounds. Waxman [28] also provided two approximation algorithms to the Steiner tree problem in the static case. Chen et al. [29] proposed approximation algorithms to minimize the number of Steiner nodes. However, these proposed approximations are not useful for mobile ad hoc networks because minimal Steiner trees are very fragile to topology changes.

[0016]
For ad hoc networks, most of the works in the literature devoted to the improvement of multipoint forwarding efficiency for routing protocols have been related to the particular case of flooding (i.e. the broadcast storm problem). Only a few papers study those mechanisms for multicast ad hoc routing. Lim and Kim [30] analyzed the problem of minimal multicast trees in ad hoc networks, but they defined several heuristics based on the minimum connected dominating set (MCDS) which are only valid for flooding. Lee and Kim [31] worked on a solution to reduce the number of forwarding nodes using a probabilistic approach. However, the overhead reductions were lower than the results according to the present invention, discussed below, and their fixed path selection probability makes their proposal unable to perform well under different mobility rates.
SUMMARY OF THE INVENTION

[0017]
In accordance with the present invention, the problem of creating multicast forwarding structures minimizing data overhead is analyzed. It is shown that forwarding structures used by existing ad hoc multicast routing protocols such as shortest path trees (SPT), multicast meshes or minimal Steiner trees (MST) do not offer minimal data overhead. In particular, meshbased multicast routing protocols are analyzed because of their suitability for mobile scenarios. The problem of finding a multicast mesh which yields the minimal data overhead is NPcomplete, and therefore a heuristic is proposed to approximate minimal data overhead forwarding meshes. The proposed heuristic is based on the epidemic propagation of the number of forwarding nodes during the process of creating multicast paths. In this way, ad hoc nodes are provided with the information required to select between a shortest one or a low dataoverhead one. In addition, an adaptive mobilityaware mesh construction algorithm is proposed based on a probabilistic path selection function. The function is defined so that low dataoverhead paths are selected with a higher probability when there are enough backup links in the current mobility conditions of the network. When more reliability is needed the function assigns a lower probability to the low dataoverhead paths.

[0018]
Simulation results show that the proposed approach, when incorporated into the ODMRP meshbased ad hoc routing protocol, yields around a 20 to 50% improvement in the forwarding efficiency. In addition, it achieves a reduction of the mean delivery latency due to the reduced link layer contention while still offering similar packet delivery ratios to the original ODMRP.
BRIEF DESCRIPTION OF THE DRAWINGS

[0019]
The invention will now be described by way of the drawings, in which:

[0020]
FIG. 1 shows a graphic example of a treebased multicast forwarding architecture;

[0021]
FIGS. 2( a), 2(b) and 2(c) show differences in cost for several multicast trees over the same ad hoc network;

[0022]
FIG. 3 shows a graph of packet delivery ratio versus mean link duration;

[0023]
FIG. 4 shows a three dimensional graph of values for probablistic path selection with respect to number of sources and mean link duration; and

[0024]
FIGS. 5( a), 5(b), 5(c) and 5(d); 6(a), 6(b), 6(c) and 6(d); and 7(a), 7(b), 7(c) and 7(d) show graphs of packet delivery ratio, normalized packet overhead, forwarding efficiency, and latency for differing conditions, respectively, with different numbers of sources and receivers, and using different protocols.
DETAILED DESCRIPTION OF THE INVENTION

[0025]
Network Model and Problem Formulation

[0026]
We now provide formal definitions of data overhead and minimal data overhead trees. In addition, we give a formulation for the problem of finding a minimal data overhead multicast mesh, and we demonstrate that the problem is NPcomplete.

[0027]
A. Network Model

[0028]
We represent the ad hoc network as an undirected graph G=(V,F) where V is the set of vertices and E is the set of edges. We assume that the network is two dimensional (every node v ∈ V is embedded in the plane) and mobile nodes are represented by vertices of the graph. Each node v ∈ V has a transmission range r. Let dist(v1,v2) be the distance between two vertices v1;v2 ∈ V. An edge between two nodes v1;v2 ∈ V exists iff dist(v1;v2)≦r (i.e. v1 and v2 are able to communicate directly). In wireless mobile ad hoc networks some links may be unidirectional due to different transmission ranges. However, given that lower layers can detect and hide those unidirectional links to the network layer, we only consider bidirectional links. That is, (v1,v2) ∈ E iif (v2,v1) ∈ E.

[0029]
The set of all multicast sources and receivers is denoted by V′ (V′⊂V ). More precisely, V′ is defined as R∪S where R is the set of multicast receivers and S is the set of multicast sources.

[0030]
B. Defining Data Overhead

[0031]
Before formulating the problem of computing the minimal data overhead multicast mesh, we give some definitions.

[0032]
Definition 1 Given a multicast tree T, we can define the number of transmissions required to deliver a multicast datagram from the source to all the receivers in T as a function C: T→Z+. We denote by C(T) the number of such transmissions.

[0033]
Definition 2 Given a graph G=(V,E), a multicast source {s} ∈ V, and a set of receivers R ⊂V, we denote by T*⊂G the multicast tree satisfying that C(T*)≦C(T) for every possible multicast tree T⊂G. T* is the multicast tree requiring the minimal number of transmissions.

[0034]
Definition 3 Given a multicast tree T we define the data overhead of T as ω_{d}=C(T)−C(T*). It is immediate from this definition that ω_{d}(T*)=0. In addition, it is also easy to show that the minimal multicast tree in terms of number of transmissions is also the minimal data overhead multicast tree.

[0035]
The previous definition can also be extended for multicast meshes. However, before that, we need an additional definition and the following theorem.

[0036]
Definition 4 Given a graph G=(V,E) and a multicast mesh M⊂G (i.e. a subgraph of G formed by the sources, the receivers and the forwarding nodes), we can define the number of transmissions required to deliver a multicast datagram from each of the sources to all the receivers in a mesh M as a function C′: M→Z+. We denote by C′(M) the number of such required transmissions in the mesh M. In addition, given the set of forwarding nodes F⊂V, and the set of sources S⊂V, C′(M)=Sj×(1+F). That is, provided that in a multicast mesh a forwarding node sends each multicast data packet only one time, the number of transmissions for each source is the one for the source itself plus one for each forwarding node.

[0037]
Theorem 1 Given a graph G=(V,E), a set of multicast sources S⊂V, and a set of receivers R⊂V the minimal number of transmissions required to deliver a datagram from each of the sources to all the receivers is Σ^{S} _{i=1}C(T_{i}*) being T_{i}* the minimal data overhead multicast tree for each source i ∈ S.

[0038]
Proof Lets assume that there is a minimal number of transmissions mesh (or shared tree) T′ which connects all sources and receivers so that

[0000]
$C\ue8a0\left({T}^{\prime}\right)<\sum _{i=1}^{\uf603S\uf604}\ue89eC\ue8a0\left({T}_{i}^{*}\right)$

[0039]
Let F be the set of forwarding nodes in T′. Then, by definition 4, (T′)=S×(1+F). Let T_{max}* be minimal data overhead tree with the bigger number of transmissions. That is, C(T_{max}*)≧C(T_{i}*) for every source i ∈ S. The number of forwarding nodes in T_{max}* is then C(T_{max}*)−1. Given that T_{max}* is the minimum number of transmissions tree for one of the sources, and provided that T′ also contains that source, then F≧C(T_{max}*)−1. This means that the following relation holds:

[0000]
1+F≧C(T _{max}*) (1)

[0040]
However, by definition of T′ our initial assumption should be satisfied. This is equivalent to say that the following relation should hold

[0000]
$\uf603S\uf604\times \left(1+\uf603F\uf604\right)<\sum _{i=1}^{\uf603S\uf604}\ue89eC\ue8a0\left({T}_{i}^{*}\right)$

[0041]
But this can only happen if 1+F<C(T_{i}*) for every source i ∈ S. Which is a contradiction provided that 1+F≧C(T_{max}*)≧C(T_{i}*), i=1 . . . S.

[0042]
Using the previous theorem, we can give the following definition of data overhead for a multicast mesh.

[0043]
Definition 5 Let G=(V,E) be a graph, S⊂V be a set of sources, and R⊂V be a set of receivers. Let T*={T_{1}*, T_{2}*, . . . ;T_{i}*; . . . ; T_{S}} be the set of trees containing the minimal dataoverhead multicast tree for each of the sources. Let M⊂G be a multicast mesh and let F be the set of forwarding nodes in M. The data overhead of M can be defined as:

[0000]
$\begin{array}{cc}{\omega}_{d}\ue8a0\left(M\right)=\uf603S\uf604\times \left(1+\uf603F\uf604\right)\sum _{i=1}^{\uf603S\uf604}\ue89eC\ue8a0\left({T}_{i}^{*}\right)& \left(2\right)\end{array}$

[0044]
The lefthand term of the subtraction in (2) is obtained from the fact that in a multicast mesh every forwarding node makes a single transmission of each data packet generated by any of the sources. The righthand term is simply the minimal number of transmissions required to deliver a message from each of the sources to all the receivers (as proved by theorem 1). In addition, combining definition 4 and theorem 1 we can also introduce the following corollary.

[0045]
Corollary 2 A multicast mesh M connecting several sources and receivers does not offer the minimal data overhead. The proof is immediate by substituting the inequality (1) in (2) to show that ω_{d}(M)≧0.

[0046]
C. Problem formulation Although a multicast mesh does not offer the minimal number of transmissions, multicast meshes are very interesting for multicast ad hoc routing due to their reliability. However, it is of paramount importance to be able to control their data overhead. Thus, it makes sense to consider the problem of finding minimal data overhead multicast meshes. This particular problem can be formulated as follows: Given a graph G=(V,E) and a set of nodes V′=R∪S so that V′⊂V, find the smallest set of nodes X⊂G such that the following conditions are satisfied:

[0047]
(1) X⊃

[0048]
(2) G_{X }is connected

[0049]
(3) G_{X }is a vertex cover for R

[0050]
Condition (1) means that X must contain at least all the sources. This is because we want X to be the set of all nodes performing multicast transmissions or forwardings. Thus, at least all the sources should be in X and eventually, other nodes required to connect sources and receivers will also be in X. Condition (2) requires that the subgraph induced by the set of nodes X in G, denoted by G_{X }is connected. This means that there is at least one path in G_{X }connecting every source and every receiver. Finally, condition (3) states that given any node r ∈ R, there is a node x ∈ X so that dist(x, r)≦1. In other words, it means that every receiver is at no more than 1 hop from one of the nodes sending or forwarding multicast packets. Note that in the particular case in which a receiver rj ∈ R belongs to X the condition still holds because in that case dist(r_{j}, r_{j})=0<1. Note that by finding the smallest set of nodes X we are inherently asking for the induced subgraph with the minimal C(G_{X}). In addition, as G_{X }is a mesh, that also means minimizing ω_{d}(G_{X}).

[0051]
D. NPCompleteness

[0052]
We demonstrate through the following theorem that the problem of finding a minimal data overhead multicast mesh is NPcomplete.

[0053]
Theorem 3 Given G=(V,E) and V′⊂V so that V′=R ∪S, the problem of finding the smallest X so that X⊃S, G_{X }is connected and G_{X }is a vertex cover of R, is NPcomplete.

[0054]
Proof: We consider a special case of our problem in which R=V−S. For this particular case given S⊂V, we are interested in finding the smallest X⊃S which covers (V−S). This is equivalent to say that we are looking for the smallest X⊃S such that for any vertex v ∈ V, dist(v,X)≦1.

[0055]
Given a graph G=(V,E), the problem of finding the smallest X⊂V such that dist(v,S)≦1 for any v ∈ V is the well known vertex cover problem. This problem, which is NPcomplete [23], is thus a special case of our problem when R=V−S. Then, we can conclude that our original problem is also NPcomplete.

[0056]
Heuristic for Minimal Data Overhead Meshes

[0057]
Given the NPcompleteness of the problem of finding the minimal dataoverhead multicast mesh, we propose use of a heuristic algorithm. In addition, we justify the validity of the proposed approach.

[0058]
A. Proposed Heuristic

[0059]
From the definition the data overhead of a multicast mesh given in definition 5, it is clear that minimizing the data overhead of a multicast mesh, requires the minimization of the expression S×(1+F). The number of sources (S) is something the routing protocol cannot change. So, the only way to reduce the overhead of a multicast mesh is reducing the number of forwarding nodes (F) which are used.

[0060]
From this observation, we provide a distributed heuristic to approximate the minimal data overhead multicast mesh by reducing the number of forwarding nodes which are required to connect multicast sources and receivers. The proposed algorithm (see algorithm 1) is a distributed counting process inspired on epidemic algorithms. Basically, a counter is added to route request (RREQ) messages. A multicast source initially sets this counter to zero. During the propagation of RREQ messages throughout the ad hoc network, this counter is modified by intermediate nodes to reflect the number of nonforwarding nodes in their path to that multicast source. So, this counter (denoted by FNCount) computes the number of new forwarding nodes which would be added to the multicast mesh if that particular path is selected. By giving more preference to those routes with the lower FNCount, ad hoc nodes can reduce the data overhead and the resulting multicast mesh will be an approximation to the minimal data overhead multicast mesh.

[0061]
As algorithm 1 shows, the way in which an intermediate node updates the FNCount field is very simple and intuitive:

[0062]
If the node is not a forwarding node, then increment the counter.

[0063]
If the node is a forwarding node, do not increment the counter.

[0064]
If the node is a receiver and a multicast forwarder, set the counter to zero. If it is only a receiver then set the counter to one.

[0065]
The latter case in which the node is a receiver has been defined in that way to reflect that the receiver will have to join the source through its lower FNCount route anyway. So, every intermediate node in that route will become a multicast forwarder. Thus, the multicast receiver acts as if he would have received a best route with an FNCount of zero.

[0066]
The use of the proposed heuristic produces multicast meshes in which there is a very low redundancy. Although that is excellent from the point of view of the data overhead reduction, the performance in mobile environments may suffer a noticeable degradation because the minimal mesh is less resilient to topological changes. However, our interest in the minimal data overhead multicast mesh stems from the possibility of being able to control the reliability of the underlying mesh, by simply adding or reducing links to that minimal mesh depending on the mobility of the network.

[0067]
We also propose an adaptive and mobilityaware mesh construction algorithm based on the principle of adjusting the reliability of the minimal data overhead multicast mesh to the changing conditions of the network.

[0000]

Algorithm 1 Minimal Data Overhead Mesh Heuristic 


1: BestRREQ null 
2: loop 
3: Receive route request packet RREQ 
4: if RREQ.seqno > BestRREQ.seqno then 
5: BestRREQ RREQ 
6: if forwarder node and not receiver then 
7: NewRREEQ.FNCount RREQ.FNCount 
8: else if forwarder node and receiver then 
9: NewRREQ.FNCount 0 
10: else if not forwarder and receiver then 
11: NewRREQ.FNCount 1 
12: else 
13: NewRREQ.FNCount RREQ.FNCount+1 
14: end if 
15: Schedule sending of NewRREQ 
16: else if RREQ.seqno = BestRREQ.seqno and RREQ.FNCount < 
BestRREQ.FNCount then 
17: if NewRREQ not sent out yet then 
18: BestRREQ RREQ 
19: if forwarder node and not receiver then 
20: NewRREQ.FNCount RREQ.FNCount 
21: else if forwarder node and receiver then 
22: NewRREQ.FNCount 0 
23: else if not forwarder and receiver then 
24: NewRREQ.FNCount 1 
25: else 
26: NewRREQ.FNCount RREQ.FNCount+1 
27: end if 
28: end if 
29: end if 
30: end loop 


[0068]
MobilityAware Mesh Construction Algorithm

[0069]
Improving the forwarding efficiency of a multicast ad hoc routing protocol without an impairment in the protocol's performance requires a tradeoff between reliability and data overhead. When the mobility rate in the network is high, it is interesting to count on the additional paths created when the number of forwarding nodes is increased. However, in scenarios with a lower mobility, having a big number of forwarding nodes is usually a waste of resources provided that there are few topological changes and most of the additional paths are not required. Thus, a meshbased multicast ad hoc routing protocol can benefit from being able to adaptively adjust the number of forwarding nodes which are created according to the network conditions. To achieve that, we introduce a probabilistic route selection scheme based on the heuristic described in the previous section. Depending on the network conditions, the probability of selecting the paths producing a lower data overhead or those incrementing the reliability of the mesh are adjusted.

[0070]
A. Network Metrics Under Consideration

[0071]
An adaptive routing scheme requires some feedback about the network conditions to properly adapt its behavior. One of the key network parameters which influences the protocol's performance is the stability of the network. There are several mobility metrics which can be considered. Examples are the mean duration of the paths, the link change rate and the link duration among others. The duration of a link is defined as the mean number of time units that the link is up during a certain time window. Thus, the mean link duration is defined as average of the link durations of all the links of a node. This metric is particularly interesting as it can be easily computed by a node in real scenarios using only local information (i.e. and without the need for additional equipment or location information such as Global Positioning System (GPS)). In addition, Boleng et al. [24] showed that link duration is much more interesting than previous mobility metrics used in the literature. They showed that the link duration and the packet delivery ratio for unicast ad hoc routing protocols are strongly correlated. In fact, other metrics such as the link break rate were not able to achieve such a big degree of correlation. That is why the mean link duration is selected as the mobility metric to use.

[0072]
One of the key parameters affecting the computation of the link duration is the time window under consideration. If the time window is too large, old links may very much influence the mean link duration, causing the feedback not to be very responsive. If the time window is too small, the link duration might fluctuate very much, without capturing the stability effect of long lived links. The determination of a proper time window was not addressed in [24]. However, from simulation results it has been found that a value of 120 seconds appears to be a good tradeoff. In addition, no additional control messages (e.g. beacons or HELLOs) are employed to compute mean link durations. Simply the control and data messages that the routing protocol would send anyway to assess the status of individual links are employed. So, there is no need for extra overhead when using this approach, and the measurements are accurate enough.

[0073]
Unfortunately, the studies in [24] did not consider the case of multicast ad hoc routing. Moreover, they did not consider the case of meshbased routing in which additional paths may help at reducing the effects of mobility. So, the relation between the packet delivery ratio and the link duration when using a multicast mesh was evaluated. To make that evaluation ODMRP challenged with the minimal data overhead mesh heuristic introduced before as the routing protocol was used. The results in FIG. 3 show that trying to fit a curve doing regression as the authors did in [24] gives a considerable fitting error, compared to the 98.5% coefficient of determination which they obtained. This indicates that there are other parameters in addition to the link duration which influence the packet delivery ratio in mesh based ad hoc routing.

[0074]
The key difference with the unicast case (and the results of Boleng et al.) are due to the additional reliability which a multicast mesh provides. In meshbased multicast routing in which redundant links or paths may exist, the link duration alone is not responsible for the differences in packet delivery ratios. For instance, given two scenarios with the same link durations, the one with the higher reliability can obtain a bigger packet delivery ratio. So, in addition to the link duration we need to consider another easytocompute metric to estimate the existing reliability that the multicast mesh already has.

[0075]
It has been found that the number of multicast sources has a strong correlation with the number of forwarding nodes. It is very easy to compute, and found to have a much better coefficient of determination can be obtained when considering independently the link duration correlation with the packet delivery ratio for each number of multicast sources. This is explained by the fact that as the number of sources increase, so does the number of forwarding nodes. Thus, the greater the number of sources, the higher the reliability of the multicast mesh. By considering both the link duration and the packet delivery ratio, the amount of additional reliability which the minimal data multicast mesh requires can be estimated. Concretely, a probability value which influences the probabilistic selection of the paths is estimated. Details about the probabilistic path selection are now described.

[0076]
B. Adaptive Mesh Construction

[0077]
The design of a deterministic mesh construction algorithm being able to balance the data overhead according to the network conditions, is very difficult. It requires the consideration of scenariospecific or overall network metrics which are usually difficult or expensive to obtain. In these cases, it is often more interesting to the use probabilistic schemes which can work with lossy or partial information and still provide good results in terms of performance.

[0078]
We thus build the multicast mesh by extending the minimal data overhead mesh according to the mobility of the network and considering the innate reliability that the minimal mesh already has. So, we can differentiate two different components affecting the probabilistic path selection: the mobility and the existing reliability in the minimal mesh. For the first component we use the mean link duration as a relevant metric. The number of multicast sources is used for the latter component. The probabilistic mesh construction is based on the minimal data overhead mesh construction algorithm depicted in algorithm 1. When a node receives a route request (RR), instead of selecting every time the route with the lower FNCount, it will select the route with the lower FNCount with a certain probability π_{s}. By adjusting the value of π_{s }we can control whether the selected paths are those adding reliability or those reducing data overhead. A bigger value of π_{s }reduces data overhead while a lower value of π_{s }increases reliability. Key to this, is to find a suitable probability assignment function π defined in the interval [0,1] such that given a link duration ld and given a number of multicast sources S, π(ld, S)=π_{s }ends up generating the required amount of redundancy.

[0079]
In order to compute a suitable function π, we focus on finding appropriate functions π_{1}(S) and π_{2}(ld), which we shall later combine to find the probability assignment function π.

[0080]
B.1 Finding a Function for π_{1}(S)

[0081]
If we consider the minimal data overhead multicast mesh, we are interested in analyzing the rate at which the number of new forwarding nodes increases as the number of sources is augmented. Let S={s_{1}, s_{2}, . . . s_{n}} be the set of multicast sources. Let M_{i }be the forwarding mesh obtained when the source s_{i }is considered individually, and let F_{i }be the set of forwarding nodes of Mi. Then, if we consider the overall multicast mesh produced when considering all the n sources, M^{n}−M^{1 }⊕ M^{2 }⊕ . . . ⊕M^{n}, the number of forwarding nodes in M_{n }denoted as F_{n } can be recursively defined as

[0000]
F ^{n} =F _{n} +F ^{n−1} −F _{n} ∩F ^{n−1}

[0082]
Obviously, the new number of forwarding nodes added is

[0000]
F ^{n} −F ^{n−1} =F _{n} −F _{n} ∩F ^{n−1}

[0083]
So, given a fixed set of receivers R, a multicast mesh has a higher resilience as the number of sources increases, but the increasing rate is not linear. The bigger the number of sources, the lower will be the number of new forwarding nodes added. This is because for each forwarding nodef f ∈ F_{i }the probability of the event that that node was already considered in the mesh for any other source M_{j}, j≠i is increased. So, π_{1}(S) should be monotonously decreasing with a lower decreasing rate as S increases. By simulating different possible functions we found that a good approximation was given by (3).

[0000]
$\begin{array}{cc}{\pi}_{1}\ue8a0\left(\uf603S\uf604\right)=\frac{1}{1+{\uf603S\uf604}^{2}}& \left(3\right)\end{array}$

[0084]
B.2 Finding a Function for π_{2}(ld)

[0085]
From our simulation results of the minimal data overhead mesh, the packet loss ratio for different link durations was computed. This ratio yields an approximation of the additional reliability which would have been required to deliver all the messages. This function, which is the inverse of the fitting function in FIG. 3, showed the exponential nature of the target function, being π_{2}(ld)˜e^{−(F×ld}. Through simulation we found that the value of aα□ was, as expected, dependent on the number of sources. For a higher number of sources, the needed reliability was lower because of the additional paths in the mesh.

[0086]
So, by further simulating combinations of π_{1}(S) and π_{2}(ld) with varying α, we found the function in (4) to be appropriate. In fact, this function, which is plotted in FIG. 4, meets all our requirements. As the number of sources increases, π(ld; S) decreases. As the link duration decreases π(ld; S) increases. And finally, when the number of sources provides enough reliability the contribution from the mobility metric is lower than when there are a few sources.

[0000]
$\begin{array}{cc}\pi \ue8a0\left(\mathrm{ld},\uf603S\uf604\right)=\frac{1}{1+{\uf603S\uf604}^{2}}\times \left(1+{\uf74d}^{\frac{\mathrm{ld}}{50}}\right)& \left(4\right)\end{array}$

[0087]
The integration of this approach into ODMRP is very straightforward, and the increase in control overhead is negligible. The only extensions are:

[0088]
(i) adding a new field to JOIN_QUERY messages in which the FNCount field is being updated,

[0089]
(ii) changing the route selection algorithm to use π(ld; S) according to (4) and

[0090]
(iii) make a node wait J_QUERY_AGG time to eventually receive a better dataoverhead route before propagating JOIN_QUERY messages.

[0091]
Simulation Results

[0092]
In order to assess the effectiveness of the proposed schemes, the proposed changes were implemented into the original ODMRP code from the Monarch extensions [26] to the NS2 [25]. ODMRP has been selected as the meshbased multicast routing protocol because it is very welldocumented in the literature where it is shown to offer very good performance results.

[0093]
Table 1 summarizes ODMRP parameters which have been used for the simulations. They are the standard values except for the J_QUERY_AGG parameter which has been introduced only for the particular case of the proposed modifications.

[0000]
TABLE 1 

ODMRP Parameters for simulation 
Parameter 
Meaning 
value 

REF_INTERVAL 
Time between JQ fbodings 
3 
s 
FG_TIMEOUT 
Timeout for the FG_GLAG 
9 
s 
J_REPLY_RET 
Max # of J. REPLY retransmissions 
3 
J_REPLY_AGG 
Timeout for aggregation of J. 
0.025 
s 

REPLY's 
J_QUERY_AGG 
Timeout for aggregation of J. 
0.015 
s 

QUERY's 


[0094]
A. Simulation Methodology and Performance Metrics

[0095]
The simulated scenario consists of 100 mobile nodes randomly distributed over an area of 1200×800 m^{2}, moving according to a random waypoint model at a speed uniformly distributed between 0 and 20 m/s. The rest of the simulation parameters used, are described in Table 2.

[0000]
TABLE 2 

Simulation parameters 



MAC layer 
IEEE 802.11b DCF at 2 Mb/s 

Comm. range 
250 m 

Sim. time 
900 s 

Traffic 
1, 2, and 5 CBR sources, 330 bytes/pkt, 5 pkt/s 

Receivers 
5, 15 and 30 



[0096]
To assess the effectiveness of the different protocols, we have used the following performance metrics:

[0097]
Packet delivery ratio. Defined as the number of data packet successfully delivered over the number of data packets generated by the sources.

[0098]
Normalized packet overhead. Defined as the total number of control and data packets sent and forwarded normalized by the total number of packets successfully delivered.

[0099]
Forwarding Efficiency. The mean number of times that a multicast data packet was forwarded by the routing protocol. This metric represents the efficiency of the underlying forwarding structure.

[0100]
Mean delivery latency. The mean of the latencies for a data packet at the different receivers. The mean delivery latency is then the average of these mean latencies over all the data packets.

[0101]
B. Performance Evaluation

[0102]
The data labeled as ‘DMRP’ corresponds to the original ODMRP protocol. The minimal data overhead heuristic is labeled as ‘DMRPNF’. The adaptive mesh construction using only the number of sources is labeled as ‘DMRPNS’ and the mobilityaware mesh construction approach is labeled as ‘DMRPLD’.

[0103]
The packet delivery ratio as a function of the pause time is depicted in FIG. 5( a) for the four variants in the 1 source and 15 receivers scenario. As expected, the minimal data overhead mesh heuristic yields around a 10% lower packet delivery ratio compared to ODMRP. That is due to the lack of redundant links. However, both ODMRP and the adaptive variants are able to deliver around 99% of the packets. ODMRP delivers around a 0.5% more packets than the mobilityaware approach. However, to achieve this packet delivery ratio, the original ODMRP version requires around a 20% more forwarding nodes (see FIG. 5( c)). In addition, the proposed alternative has a lower overhead. As we can see, the minimal data overhead mesh heuristic uses a 60% less overhead than ODMRP. This is because by reducing the number of forwarding nodes, the data overhead is also reduced. An additional benefit of reducing the data overhead is the reduction of the mean latency between the source and the receivers. The expected behavior is that ODMRP would have offered a lower latency because it uses the shortest path tree. However, the proposed approach by reducing the number of forwarding nodes also reduces the MAClayer contention and collisions among forwarding nodes. Thus, the overall average latency can be reduced.

[0104]
It is also interesting to point out, that the mobilityaware heuristic by considering the mean link durations is able to offer higher packet delivery ratios than the same heuristic considering only the number of sources. This is particularly noticeable for the scenarios with lower pause times.

[0105]
The cause for the important difference in the number of forwarding nodes between the different variants is that in the original ODMRP the randomness in the access to the MAC layer can make the shortest path routes to change very quickly even if the topology is relatively static. This is because ODMRP considers the path from which the JOIN_QUERY is first received to be the shortest path. Thus, provided that after a new route has been selected the forwarding nodes in the old path will still remain active for two additional refresh intervals, the number of forwarding nodes quickly increases. This means that ODMRP has a higher reliability which is obtained at the cost of increasing data overhead. The proposed schemes are based in the lower FNCount metric, which does not change as fast as the shortest path. Thus, the number of nodes can be reduced. In fact, in the case of the mobilityaware algorithm, the data overhead can be controlled by the selection of appropriate π_{s}, for the probabilistic path selection. That is why ‘ODMRPLD’ has a bigger data overhead when the network is less static (lower pause times) and the number of forwarding nodes reduces as the pause times increase.

[0106]
The performance results are very similar in the scenarios for 5 and 30 receivers. In general, the higher the number of receivers, the lower the differences in the packet delivery ratio and also the lower the differences in data overhead. This is because as the number of receivers increases, so does the number of forwarding nodes which are really needed.

[0107]
The evaluation of the scenarios with 2 sources and 15 receivers in FIG. 6 shows a similar trend. The packet delivery ratio of the mobilityaware approach is still around 0.5% lower than ODMRP. Moreover, the proposed approach becomes even more efficient compared to the original ODMRP. In FIG. 6( c) it is shown that the proposed approach manages to improve the forwarding efficiency by around a 50%. Given that in these scenarios the traffic load is doubled, both approaches experience a slight increase in the average latency. This is due to the higher contention at the MAClayer. However, as FIG. 6( d) depicts, the proposed approach improves even more its average latency compared to the one of the original ODMRP. This is explained by the 50% less forwarding nodes required by the proposed approach. Similar results were obtained for the case of 5 and 30 receivers. For the case of the minimal data overhead heuristic scheme, the differences in the packet delivery ratio compared to ODMRP are reduced to a 2.5% for the scenarios with a higher mobility and around a 1% for more static scenarios. This corroborates our studies in the previous section about the additional reliability automatically added to the multicast mesh by increasing the number of sources. In addition, by comparing ‘ODMRPLD’ and ‘ODMRPNS’ we can see that in this case the mobilityaware approach stills performs better under high mobility, but the differences in overhead are much lower. This is because the definition of π(ld, S) takes advantage of the additional reliability provided by having two sources.

[0108]
In the scenarios with 5 multicast sources, we can see that the traffic load is so high, that the ad hoc network starts getting congested. This can be shown by the reduction in the packet delivery ratio shown in FIG. 7( a) and the increments in latency shown in FIG. 7( d). The congestion for ODMRP is so high for the case of 15 and 30 receivers that we focus here in the case of 5 receivers, which is more representative. In fact, we can notice that the proposed approach improves the packet delivery ratio by 3.5% using a 50% less of data transmissions (see FIG. 7).

[0109]
Conclusions

[0110]
The present invention provides a mobilityaware heuristic algorithm to reduce the data overhead of meshbased multicast ad hoc routing protocols. The algorithm adapts the number of redundant paths of the multicast mesh to the mobility of the network. It starts with an approximation of the minimal data overhead multicast mesh, and increments or reduces the number of forwarding nodes as required. The NPcompleteness of finding such a minimal multicast mesh was determined, which fully justifies the heuristic nature of the proposed scheme.

[0111]
The proposed scheme was simulated using ODMRP as the baseline protocol. The performance evaluation shows that the mobilityaware mesh construction algorithm achieves similar packet delivery ratios than the original ODMRP protocol with a reduction between 25 to 50% in the number of forwarding nodes and an enhancement in the average latency. The results in scenarios with a high traffic load show that the mobilityaware mesh construction approach is able to achieve a higher overall network capacity. So, the proposed scheme allows meshbased multicast as hoc routing protocols to benefit from having a low data overhead like the one of multicast trees, while still providing an excellent reliability in face of mobility.

[0112]
The preferred embodiment of the present invention, improvements, and advanced features, is thus described. While the present invention has been described in particular embodiments, it should be appreciated that the present invention should not be construed as limited by such embodiments, but rather construed according to the below claims.
References

[0113]
[1] S. Deering, “Multicast Routing in a Datagram Internetwork,” Ph.D. Thesis, Electrical Engineering Dept., Stanford University, December 1991.

[0114]
[2] S.E. Deering and D.R. Cheriton, “Multicast Routing in datagram internetworks and extended LANs,” Transactions on Computer Systems, vol.8, no.2, May 1990, pp. 85110.

[0115]
[3] J. Moy, “Multicast routing extensions for OSPF,” Computer communications of the ACM, vol.37, no.8, August 1994, pp. 6166.

[0116]
[4] T. Ballardie, P. Francis and J. Crowcroft, “Core Based Trees (CBT)—An architecture for scalable interdomain multicast routing, ” Proc. of ACM SIGCOMM'93, San Francisco, Calif., October 1993, pp.8595.

[0117]
[5] S. Deering, D.L. Estrin, D. Farinacci, V. Jacobson, C.G. Liu and L. Wei, “The PIM architecture for widearea multicast routing,” IEEE/ACM Transactions on Networking, vol.4, no. 2, April 1996, pp. 153162.

[0118]
[6] C. Cordeiro, H. Gossain and D. Agrawal, “Multicast over Wireless Mobile Ad Hoc Networks: Present and Future Directions” IEEE Network, no. 1, January 2003, pp. 5259.

[0119]
[7] C.W. Wu, Y.C. Tay and C.K. Toh, “Ad Hoc Multicast Routing Protocol Utilizing Increasing idnumberS (AMRIS) Functional Specification,” Internetdraft, work in progress, draftietfmanetamrisspec00.txt, November 1998.

[0120]
[8] E.M. Royer and C.E. Perkins, “Multicast operation of the adhoc ondemand distance vector routing protocol,” Proceedings of ACM/IEEE MOBICOM' 99, Seattle, Wash., August 1999, pp. 207218.

[0121]
[9] L. Ji and S. Corson, “A Lightweight Adaptive Multicast Algorithm,” Proceedings of IEEE GLOBECOM'98, Sydney, Australia, November 1998, pp. 10361042.

[0122]
[10] J.G. Jetcheva, D.B. Johnson, “Adaptive DemandDriven Multicast Routing in MultiHop Wireless Ad Hoc Networks,” Proceedings of ACM MobiHoc'01, Long Beach, Calif., October, 2001, pp. 3344.

[0123]
[11] S.J. Lee, W. Su, and M. Gerla, Ondemand multicast routing protocol in multihop wireless mobile networks, ACM/Kluwer Mobile Networks and Applications, vol. 7, no. 6, pp. 441452, December 2002.

[0124]
[12] J. J. GarciaLunaAceves and E.L. Madruga, “The CoreAssisted Mesh Protocol,” IEEE Journal on Selected Areas in Communications, vol. 17, no. 8, August 1999, pp. 13801394.

[0125]
[13] C.K. Toh, G. Guichala, S. Bunchua, “ABAM: OnDemand AssociativityBased Multicast Routing for Mobile Ad hoc Networks,” Proceedings of IEEE VTC2000, Boston, Mass., September 2000, pp. 987993.

[0126]
[14] E. Bommaiah, M. Liu, A. MacAuley and R. Talpade, “AMRoute: Ad hoc Multicast Routing Protocol,” Internetdraft, work in progress, drafttalpademanetamroute00.txt, August 1998.

[0127]
[15] P. Sinha, R. Sivakumar and V. Bharghavan, “MCEDAR: Multicast CoreExtraction Distributed Ad hoc Routing,” Proc. of IEEE Wireless Commun. and Networking Conf., New Orleans, La., September 1999, pp. 13131319.

[0128]
[16] L. Ji, and M.S. Corson, “Differential Destination Multicast: A MANET Multicast Routing Protocol of Small Groups,” Proc. of IEEE INFOCOM'01, Anchorage, Alaska, April 2001, pp. 11921202.

[0129]
[17] J.G. Jetcheva, YihChun Hu, David A. Maltz and David B. Johnson, “A Simple Protocol for Multicast and Broadcast in Mobile Ad Hoc Networks,” Internetdraft, work in progress, draftietfmanetsimplembcast01.txt, July 2001.

[0130]
[18] K. BharathKumar and J.M. Jaffe, “Routing to Multiple Destinations in Computer Networks,” IEEE Transactions on Communications, no. 31 Vol. 3, 1983, pp. 343351.

[0131]
[19] R.M. Karp, “Reducibility among combinatorial problems,” In Complexity of computer computations, Plenum Press, New York, 1975, pp. 85103.

[0132]
[20] L. Kou, G. Markowsky, and L. Berman, “A fast algorithm for Steiner trees,” Acta Informatica, no. 15, vol. 2, 1981, pp. 141145.

[0133]
[21] J. Plesnik, “The complexity of designing a network with minimum diameter,” Networks, no. 11, 1981, pp. 7785.

[0134]
[22] A. Zelikovsky, “An 11/6approximation algorithm for the network Steiner problem,” Algorithmica, no. 9, 1993, pp. 463470.

[0135]
[23] S. Even, “Graph Algorithms,” Computer Science Press, 1979, pp. 204209.

[0136]
[24] J. Boleng, W. Navidi and T. Camp, “Metrics to Enable Adaptive Protocols for Mobile Ad Hoc Networks”, Proc. International Conference on Wireless Networks (ICWN), Las Vegas, Nev., June 2002, pp. 293298.

[0137]
[25] K. Fall, K. Varadhan, “ns, Notes and Documentation”, The VINT Project, UC Berkeley, LBL, LTSC/ISI, and Xerox PARC, November 2003.

[0138]
[26] The Monarch Project, mobile networking architectures, Rice University. [Online]. Available: http://www.monarch.cs.rice.edu/

[0139]
[27] X. Jia, “A Distributed Algorithm of DelayBounded Multicast Routing for Multimedia Applications in Wide Area Networks,” IEEE/ACM Transactions on Networking, vol. 6, no. 6, December 1998, pp. 828837.

[0140]
[28] B.M. Waxman, “Routing of Multipoint Connections,” IEEE Journal on Selected Areas in Communications, vol. 6, no. 9, December 1998, pp. 16171622.

[0141]
[29] D. Chen, D.Z. Du, X.D. Hu, G.H. Lin, L. Wang, G. Xue, “Approximations for Steiner trees with minimum number of Steiner points,” Theoretical Computer Science no. 262, 2001, pp. 8399.

[0142]
[30] H. Lim and C. Kim, “Multicast Tree Construction and Flooding in Wireless Ad Hoc Networks,” Proceedings of the 3rd ACM international workshop on Modeling, analysis and simulation of wireless and mobile systems, Boston, Mass., USA. August, 2000, pp. 6168.

[0143]
[31] S. Lee, C. Kim, “Neighbor Supporting Ad hoc Multicast Routing Protocol,” Proceedings of the 1st ACM MobiHoc', Boston, Mass., USA, 2000, pp. 3744.