行政院國家科學委員會專題研究計畫 成果報告
應用數學規劃在大型隨意網路上多重通訊之研究(3/3)
研究成果報告(完整版)
計 畫 類 別 ： 個別型 計 畫 編 號 ： NSC 95-2221-E-002-449- 執 行 期 間 ： 95 年 08 月 01 日至 96 年 07 月 31 日 執 行 單 位 ： 國立臺灣大學資訊工程學系暨研究所 計 畫 主 持 人 ： 陳健輝 計畫參與人員： 碩士級-專任助理：蔡秉穎、林士傑、郭育良、陳毓訓、洪韶 憶、洪俊竹、洪浩舜、黃秋溶 報 告 附 件 ： 出席國際會議研究心得報告及發表論文 處 理 方 式 ： 本計畫可公開查詢中 華 民 國 96 年 06 月 11 日
行政院國家科學委員會專題研究計畫成果報告
應用數學規劃在大型隨意網路上多重通訊協定之研究
Mathematical Programming Approaches to Multicasting on Large-Scale Mobile Ad-Hoc Networks
計畫編號：
NSC 92－2213－E－260－018－
執行期限： 93 年 8 月 1 日 至 96 年 7 月 31 日
主持人：陳健輝
教授
國立暨南國際大學資訊工程學系
計畫參與人員：
蔡秉穎, 林士傑, 郭育良, 陳毓訓, 洪韶憶,
洪俊竹, 洪浩舜, 黃秋溶
中文摘要 為 了 有 效 管 理 封 包 之 傳 遞 ， 近 年 來 在 大 型 隨 意 網 路 (MANET) 上 之 多 重 通 訊 協 定 (multicast protocols)主要採取兩階層架構(two-tier infrastructures)之設計。但是這 些多重通訊協定有以下三個缺點。第一，它們選取有較多相鄰通訊點之通訊點作為主幹通 訊點(backbone hosts)來代理封包的遞送。此種選取方式易造成大量封包集中在這些主幹 通訊點而形成網路瓶頸。第二，它們在選取主幹通訊點時未考量其移動性，因此易造成大 量封包之遺失。第三，它們未能提供不同等級傳輸服務品質(Quality-of-Service)之功能。 為滿足多媒體或其它有及時性需求之應用程式，多重通訊協定必須具備此功能。 在本計劃執行的第一年裏，我們針對大型隨意網路設計一個不同的主幹通訊點選取方 式，為了能產生較短的多重通訊路徑(multicast routes)，我們選取離其他通訊點最近的 通 訊 點 作 為 主 幹 通 訊 點 ， 並 將 此 種 主 幹 通 訊 點 選 取 方 式 表 成 數 學 規 劃 之 目 標 函 數 (objective functions)與限制條件(constraints)。然後，藉由解出數學規劃之一組有效 解(feasible solution)，主幹通訊點便可決定。我們將運用這些主幹通訊點來完成一套符 合我們需要的多重通訊協定。本計劃執行的第二年，我們進一步考量通訊點的移動性 (Mobility)，以作為主幹通訊點選取方式的重要依據。我們選取離其他通訊點較近與有較 長的連接時間(Connecting Time)的通訊點作為主幹通訊點。此種選擇主幹通訊點的方式的 目標，不僅能建立較短的多重通訊路徑，而且能建立一個具有較少控制封包與較少遺失封 包之穩定兩階層架構。 今年(本計劃執行的第三年)，為滿足多媒體或其它有及時性需求之應用程式，我们增 加設計的多重通訊協定具備提供不同等級傳輸服務品質(Quality-of-Service)之功能。現 有在隨意網路上提供傳輸服務品質之通訊協定與多重通訊協定，必須建立滿足應用程式頻 寬需求之路徑，然而他們在設計上因為未考量 two-hop neighbors 的頻寬消耗狀況，所以 其路徑會導致兩個違反頻寬需求之問題產生。今年，我們設計一個演算法能避免上述兩個 問題之發生，而建立滿足應用程式頻寬需求之多重通訊樹(multicast trees)。另為了減少 頻寬與電力之消耗，挑選具有越少傳輸點(forwarders)的多重通訊樹為我們的目標。實驗 驗證此演算法能提高整體系統之產能。 關鍵詞：隨意網路, 數學規劃, 多重通訊, 最佳化。英文摘要
Recent multicast protocols for large-scale mobile ad hoc networks (MANETs) adopted two-tier infrastructures to achieve effective flooding schemes. They have three disadvantages. First, hosts with a large number of neighbors were selected as backbone hosts (BHs) for forwarding packets. It is very likely that these BHs will become traffic concentrations or bottlenecks of the networks. Second, they suffered from more lost packets because they did not consider host mobility in selecting BHs. Third, they did not provide quality-of-service (QoS) function. A multicast protocol is desired to provide different levels of QoS for multimedia and real-time applications.
In the first year of this project, a distinct strategy is proposed for constructing a two-tier infrastructure in a large-scale ad-hoc network. Hosts with a minimal number of hops to the other hosts rather than those with a maximal number of neighbors will be adopted as BHs in order to obtain shorter multicast routes. The problem of determining BHs can be formulated with linear programming. Then BHs will be determined by solving the formulated MP for a feasible solution. Finally, the new multicast protocol will be developed based on the selected BHs. In the second year of this project, host mobility is further taken into consideration in selecting BHs. Hosts with fewer hops and longer remaining connection time to the other hosts will be selected as BHs. The objective is not only to obtain short multicast routes, but also to construct a stable two-tier infrastructure with fewer lost packets.
In this year (the third year of this project), the proposed multicast protocol is enhanced to provide different levels of QoS for multimedia and real-time applications. Previous quality-of-service (QoS) routing/multicasting protocols in mobile ad-hoc networks determined bandwidth-satisfied routes for QoS applications. However, they suffer from two bandwidth-violation problems since the bandwidth consumption of two-hop neighbors is not taken into consideration. In this year, a novel algorithm that can avoid the two problems is proposed to construct bandwidth-satisfied multicast trees for QoS applications. Further, it also aims to minimize the number of forwarders so as to reduce bandwidth and power consumption. Simulation results show that the proposed algorithm can improve the network throughput.
Keywords: Ad-hoc network, distributed algorithm, linear programming, multicast
一、前言
Motivated by increasing importance of real-time and multimedia applications with different quality-of-service (QoS) requirements, e.g., VoIP and video-conference, several QoS-constrained multicast algorithms for multimedia communication in wired networks have been proposed in the literature [3-5]. These algorithms aim to construct least-cost multicast trees with the constraints of delay and/or bandwidth requirement.
communicate with one another without the aid of any centralized point or fixed infrastructure. Because of recent provision of high-speed wireless internet services, QoS-guaranteed applications are now crucial to new-generation wireless multimedia communication systems. To meet the QoS requirements of the applications, multicast protocols are required to construct routes with QoS guaranteed. On the other hand, cellular networks have fixed base stations as access points for wireless communication.
In contrast with cellular networks, MANETs do not need any infrastructure and their topologies may dynamically change in an unpredictable manner because mobile hosts are free to move. Besides, each transmission in MANETs is a local broadcast and each mobile host shares the common radio channel with all its neighbors. MANETS have much less available bandwidth than cellular and wired networks. An inadequate bandwidth reservation may degenerate network performance, which is more serious in MANETS because of shared channel and limited bandwidth.
Several routing protocols [6-8] and multicast protocols [9, 10] have been proposed for MANET QoS services. In [6], a QoS routing protocol, named CEDAR, was proposed, which constructed routes by selecting high-bandwidth and stable links. In [7], another QoS routing algorithm was proposed, which constructed routes satisfying delay and/or bandwidth requirements. In [8], another QoS routing protocol, named AQOR, was proposed, which estimated available bandwidth and end-to-end delay for admission control and bandwidth reservation in determining QoS-satisfied routes.
In [9], a QoS multicast protocol, named MCEDAR, was proposed, which is a direct extension of CEDAR. In [10], another QoS multicast protocol, named M-CAMP, was proposed, which adopted a measurement-based approach to estimating the bandwidth availability from the server to the clients. Then, probe packets were sent along the multicast tree to test if the network satisfied the bandwidth requirement. All QoS routing/multicasting protocols mentioned above adopted some admission control mechanisms for determining bandwidth- satisfied routes. However, they may lead to bandwidth violation, as described below.
When a new flow with bandwidth requirement is permitted, a control packet from the source is flooded in order to determine a bandwidth-satisfied route. Each host in the neighborhood of some ongoing flows may be determined as a forwarder for the new flow if the bandwidth increment does not induce bandwidth violation of it and its neighbors. However, even so, bandwidth violation may happen to its neighbors because it fails to take into account the bandwidth consumption of those hosts that are two hops distant from it. This induces a new bandwidth-violation problem in MANETs. The problem is named the hidden route problem (HRP).
Currently, two QoS routing protocols have been proposed by Yang et al. [19] and. Chen et al. [20]. They considered the bandwidth consumption of the one-hop/two-hop hosts when a new flow with bandwidth requirement was permitted. So, HRP can be avoided. However, a QoS multicast protocol should determine multiple bandwidth-satisfied routes from a server to all
clients concurrently. Another bandwidth-violation problem is induced if multiple flows are
二、研究目的
Since bandwidth and battery power are limited in MANETs, they should be taken into consideration in routing/multicasting protocols. One way to reduce bandwidth and power consumption is to decrease the number of hosts (i.e., forwarders) participating in packet forwarding. The problem of finding a multicast tree with minimum number of forwarders can be modeled as the Steiner tree problem (STP) that is known to be NP-hard (see [11]). If the bandwidth consumption is considered additionally, the resulting problem is also NP-hard. In this paper, we study the problem of determining a bandwidth-satisfied multicast tree with minimum number of forwarders. The problem is referred to as BSMTP in the rest of this report, and we propose to provide a feasible solution to it.
A number of good heuristics for approximate STP [21-26] have been proposed. They can be classified into centralized approach [21-24] and distributed approach [25, 26]. In the centralized approach, a center node that is aware of the state of the whole network computes the tree. In the distributed approach, on the other hand, each node of the network actively contributes to the algorithm computation. However, the approximate Steiner trees determined in [21-26] are insufficient to characterize a good multicast tree for multimedia applications with different QoS requirements (delay and/or bandwidth).
The problem of determining a delay-satisfied multicast tree with minimum number of forwarders (denoted as DSMTP) is a constrained Steiner tree. The most relevant work in the area of DSMTP has been done in [2, 12, 27, 28]. The algorithm proposed in [27, 28] was based on a minimum spanning tree, which encapsulated the minimum delay routes between any two nodes and the corresponding delays, rooted at the server over the entire network. A delay-satisfied multicast tree was derived by removing the unnecessary edges from the spanning tree. On the other hand, the algorithm proposed in [2, 12] modified the cheapest insertion heuristic algorithm proposed in [1] to solve DSMTP. In [1], a tree rooted at the server connected to the nearest client, which was not connected, on each step.
BSMTP is similar to DSMTP in some aspects. They both intend to determine a multicast tree so that the number of forwarders in the tree is minimized. The major differences between BSMTP and DSMTP are the constraints, i.e., bandwidth and delay. In DSMTP, the delay of a route can be obtained easily by summing the delays of the edges along the route, where the delay on each edge is a predefined constant. But in BSMTP, The bandwidth increment to a host is not a constant. In MANETs, a host shares the radio channel with its neighbors so that its bandwidth increment induced by a new flow relies on whether it and its neighbors are selected as the forwarders for the flow. Similarly, bandwidth violation happened to its neighbors should be avoided when it is selected as a forwarder. Therefore, to determine a feasible solution of BSMTP is more difficult.
A novel algorithm that can avoid the two problems is proposed to construct bandwidth-satisfied multicast trees, which is a feasible solution to BSMTP, for QoS applications. Further, it also aims to minimize the number of forwarders so as to reduce bandwidth and power consumption. Simulation results show that the proposed algorithm can improve the network throughput.
三、文獻探討
To meet the bandwidth requirements of bandwidth-constrained applications, a proper admission control mechanism is needed to judge if a host is allowed to forward the packets for a
requested flow. In wired networks, there is a dedicated point-to-point link, denoted by li,j,
between two adjacent nodes vi and vj. If vi (vj) transmits packets to vj (vi), the bandwidth
consumption is bounded by the maximal available bandwidth of li,j. When a neighbor of vi (vj)
transmits packets to vi (vj), it does not consume the bandwidth of li,j. So, vi and vj are aware of the
remaining available bandwidth of li,j. Suppose that a new flow from the source vs to the
destination vd is initiated and its bandwidth requirement is b_req. Let b_ri,j be the current
remaining available bandwidth of li,j. If b_ri,j≥b_req, then vi (vj) is allowed to forward the flow to
vj (vi). Finally, if vs→v →f1 v →f2 vf3→ …→vfm →vd is determined as the bandwidth- satisfied
route for the flow, then it should have min{
1 , _rs f b , 2 1, _rf f b , 3 2, _rf f b , …, b rf ,d 3 _ }≥b_req.
The MANET QoS routing/multicasting protocols in [6, 7, 9, 10] borrowed the concept of point-to-point links from the wired networks to construct bandwidth-satisfied routes. However, a host in MANETs shares the radio channel with its neighbors so that the bandwidth is consumed
not only by it, but also by its neighbors. For example, suppose that vs→v →f1 v →f2 vf3→ … →
m
f
v →vd is a bandwidth-satisfied route in MANETs. When vf1 transmits packets to v , the f2
bandwidths of 1 , f s l , 2 1, f f l and 3 2, f f
l are consumed. Therefore, it is more difficult to determine a
bandwidth-satisfied route in MANETs, because the computation of li,j also relies on the neighbors
of vi and vj.
On the other hand, AQOR [8] determined a bandwidth-satisfied route differently. The
bandwidth computation is from the viewpoint of a host, instead of a link. Let b_ri be the current
remaining available bandwidth of vi. With the same example of vs→v →f1 v →f2 vf3→… →vfm
→vd above, the bandwidths of vs and vf1 are consumed when vs transmits packets to v , the f1
bandwidths of vs, vf1 and vf2 are consumed when vf1 transmits packets to v , and so on. f2
Consequently, the total bandwidth consumptions of vs, v ,f1 v ,f2 vf3, …, vfm and vd, caused by
the flow, are 2×b_req, 3×b_req, 3×b_req, 3×b_req, …, 3×b_req and b_req, respectively.
All QoS routing/multicasting protocols described above may suffer from two bandwidth- violation problems, i.e., HRP and HMRP, because the hosts in the neighborhood of ongoing flows fail to compute the bandwidth consumptions of those hosts that are two hops distant from them.
Refer to Figure 1, where an illustrative example is shown. There are two ongoing flows from
determination for the new flow proceeds to c. Suppose that each host has the same available bandwidth, say 11 units, and the bandwidth requirements for the three flows are 2 (from e to f), 7 (from g to h) and 3 (from a to d) units, respectively. If c serves as a forwarder, then total 9-unit bandwidth of c will be consumed (c, the predecessor of c and the successor of c each require 3-unit bandwidth). Since the ongoing flow from e to f is in the radio coverage of c, it consumes
2-unit bandwidth of c. Consequently, the remaining available bandwidth of c is 11−2=9 units,
and so c is allowed to be a forwarder.
Now we turn our attention to the bandwidth consumption of e. Since both c and g are in the
radio coverage of e, the bandwidth requirement of e is 2+3+7=12 units, which exceeds its
available bandwidth (11 units). The reason for the bandwidth violation is that c was not aware of the ongoing flow from g to h when it was determined to be a forwarder. In short, the bandwidth violation happened because the ongoing flow from g to h was hidden from the new flow from a to d. The problem is henceforth referred to as the hidden route problem (HRP). In contrast to the hidden terminal problem [13], which arises in the MAC layer, the hidden route problem arises in the network layer.
d e a b c f h g Figure 1. An example of HRP. d e a b c f g h Figure 2. An example of HMRP.
An illustrative example for HMRP is shown in Figure 2, where there is a multicast group and a new flow from a (server) to e and h (clients) is permitted. Suppose that each host has the same available bandwidth, say 11 units, and the bandwidth requirement of the flow is 3 units. Also note that bandwidth reservation will be made for the flow when data flow through the routes. Both c and g can be forwarders for the flow from a to e and from a to h, respectively, because their bandwidth requirement (9 units) is smaller than their available bandwidth (11 units). However, since they are in the radio coverage of each other, 3-unit bandwidth is required additionally when data flow from a to e and h. This increases their bandwidth requirement to 12 units, which causes a bandwidth violation. The bandwidth violation happens because the two multicast routes from a to e and from a to h are mutually hidden from each other. It is henceforth referred to as the hidden multicast route problem (HMRP).
The influence of HRP and HMRP on network performance is demonstrated by simulations using the Network Simulator 2 package (ns-2) [14], where 50 hosts are randomly distributed over
a 1000m×1000m area. The data transmission capability (available bandwidth) of each host is
assumed.
The probabilities of HRP and HMRP are investigated in Figure 3 and Figure 4, where forty runs with different seed numbers are conducted for each scenario and collected data for these runs are averaged. In Figure 3 (Figure 4), the number of source-destination pairs (multicast trees) varies from 1 to 20 (from 1 to 10). The sources and destinations are randomly chosen from 50 hosts and each multicast group has three clients. The bandwidth-satisfied routes (multicast trees) are obtained according to AQOR (MCEDAR). The probability of HRP (HMRP) means the probability that bandwidth violation happens to at least one route.
0 2 4 6 8 10 12 14 16 18 20 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
Number of source-destination pairs
Pr obab ilit y o f H R P load: 25 Kbps load: 50 Kbps Figure 3. Probability of HRP. 1 2 3 4 5 6 7 8 9 10 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Number of multicast trees
Pr oba bi lit y of H M R P load: 25 Kbps load: 50 Kbps Figure 4. Probability of HMRP.
The simulations exhibit that when the network traffic is saturated, HRP and HMRP will happen very frequently to AQOR and MCEDAR, respectively, or AQOR and MCEDAR will be very likely to make improper bandwidth reservation.
四、研究方法
A multicast group contains a server that is responsible for transmitting data packets to the clients in the same group. In this section, we propose a MANET bandwidth-aware multicasting protocol that can determine a bandwidth-satisfied multicast tree to admit a flow with the requested bandwidth. To offer bandwidth-guaranteed multicasting, the residual bandwidth at a given host must be known. However, how to calculate the residual bandwidth using the IEEE 802.11 MAC is still a challenging problem, because the bandwidth is shared among neighbors, and a host has no knowledge about other neighbors’ traffic status [20]. In Section 3.1, we show a method to estimate residual bandwidth, which will act as a soft upper bound on the residual bandwidth of the host for bandwidth-satisfied multicast tree discovery/recovery.
Recall that each host shares the radio channel with its neighbors. So, its bandwidth increment induced by a new flow relies on whether it and its neighbors are selected as the forwarders for the flow. If it is selected as a forwarder, bandwidth violation to it and its neighbors must be avoided. Besides, all bandwidth-satisfied routes (which constitute a bandwidth-satisfied multicast tree) from a server to its clients must be determined concurrently, which is different from QoS routing protocols that determine a bandwidth- satisfied route in one time. In (2), an algorithm that can discover a bandwidth- satisfied multicast tree, which represents a feasible solution to BSMTP, is proposed. The algorithm collects the entire network information in order to determine the
bandwidth- satisfied multicast routes concurrently.
The bandwidth-satisfied multicast tree determined in (2) may become outdated or disconnected due to host movement. In (3), a distributed algorithm is proposed to recover the tree.
(1)
Residual bandwidth estimation
It is rather difficult to estimate the residual bandwidth of a host, because the bandwidth is shared among neighboring hosts and these neighboring hosts are not aware of the traffic status of one another. Recently, there are two QoS routing protocols, proposed by Yang et al. [19] and Chen et al. [20], which estimate the residual bandwidth of a host by monitoring the amount of idle channel time. In this section, based on the same concept as [19] and [20], a method for residual bandwidth estimation is proposed.
As shown in Figure 5, each host vi maintains two neighbor tables: the one-hop neighbor table
and the two-hop neighbor table, where vj (vk) denotes a one-hop (two-hop) neighbor of vi and b_oj
(b_ok) denotes the currently consumed bandwidth for all ongoing flows that are forwarded by vj
(vk). Besides, there is a link directed from vj to vk if vk is a one-hop neighbor of vj.
One-Hop Neighbors Consumed Bandwidth . . . . . . vj b_oj . . . . . . (a) (b) Two-Hop Neighbors Consumed Bandwidth . . . . . . vk b_ok . . . . . .
Figure 5. Two neighbor tables. (a) One-hop neighbor table. (b) Two-hop neighbor table.
In order to maintain the two neighbor tables for all hosts, every two neighboring hosts, say vx
and vy, have to exchange their one-hop neighbor tables together with b_ox and b_oy periodically
via control packets b_hello. Whenever vx (vy) receives a b_hello packet from vy (vx), vx (vy) uses
the one-hop neighbor tables of vy (vx) that are carried by the b_hello packet to update its two
neighbor tables and the associated links.
When vi has the currently consumed bandwidths, i.e., b_ojs, of all its one-hop neighboring hosts
vjs, its residual bandwidth can be estimated as the maximal available bandwidth minus
∑
+ j
i b o
o
b_ _ , divided by a weighted factor α. Also, vi can estimate the residual bandwidths of
all vjs similarly. We need to divide these residual bandwidths by α due to the IEEE802.11 MAC’s
nature and some overheads induced by the MAC. Since the control packets (i.e., RTS, CTS and ACK packets) consume bandwidth, the back-off scheme fails to use the entire bandwidth and the
data/control packets may collide, α can be calculated as follows.
Data ACK IPHdr MACHdr Data CTS RTS+ + + + + = ( ) α
header, IP header and ACK, respectively. Since fading errors may cause retransmission of
control/data packets, the value of α used in the algorithm (presented below) should be greater
than the value calculated above.
(2)
Discovery of bandwidth-satisfied multicast trees
A heuristic algorithm that can provide a feasible solution to BSMTP is proposed. The algorithm can admit a new flow with bandwidth requirement for some multicast service by constructing a bandwidth-satisfied multicast tree. Besides, the algorithm attempts to minimize the number of forwarders for the new flow. The execution of the algorithm involves a basic procedure, named Shortest_Routes, which can establish shortest (minimum number of hops) routes to a particular destination.
Shortest_Routes has four input parameters: vd, b_req, ∆ and Φ, where vd is a destination of
the new flow, b_req is the bandwidth requirement for the new flow, and ∆, Φ are two sets of hosts.
Shortest_Routes also has two output parameters: H and P (explained later). The execution of Shortest_Routes invokes another procedure, named B_Violation, which returns true if bandwidth
violation happens and false else. B_Violation uses ∆ and Φ for checking bandwidth violation,
which will become clear later.
Shortest_Routes is a modification of the well-known Dijkstra’s shortest-path algorithm [15],
which can compute the shortest paths from a node to the other nodes. Differently,
Shortest_Routes establishes shortest routes in a reverse direction from all hosts to vd. For each
host vi in the shortest routes, let hi,d denote the minimum number of hops from vi to vd, and Pi,d
denote the set of forwarders along the shortest vi-vd route. Initially, set hi,d =1 and Pi,d ={vi} if vi is
neighboring to vd and the inclusion of vi in the shortest routes will not cause bandwidth violation.
Otherwise, set hi,d =∞ and Pi,d ={} (the empty set). Host vi will (will not) cause bandwidth
violation if B_Violation(b_req, ∆, {vi}∪Φ) returns true (false).
The shortest routes are established iteratively by a repeat-until loop. In each iteration, a host
vx that is closest to vd (i.e., hx,d is minimum) and was not selected before is determined. Then, for
each neighbor vj of vx, the vj-vd route (i.e., Pj,d) is replaced with the vx-vd route augmented with the
vj-vx hop (i.e., Px,d ∪ {vj}), if the new vj-vd route is shorter and does not cause bandwidth
violation. The latter can be checked by invoking B_Violation(b_req, ∆, {vj} ∪ Px,d ∪Φ).
Finally, the shortest routes are represented by means of H and P, which are two sets containing all
hi,ds and Pi,ds, respectively. Shortest_Routes is detailed below.
Procedure Shortest_Routes(vd, b_req, ∆, Φ, H, P);
/* V is the set of all hosts. */
X ← V−{vd};
for each vi ∈X do
if vi and vd are neighboring and B_Violation(b_req, ∆, {vi}∪Φ) = false
else hi,d← ∞ and Pi,d← {};
repeat
determine vx ∈X so that hx,d = min{hi,d | vi ∈X} and delete vx from X;
if hx,d≠ ∞
then for each neighbor vj of vx do
if hj,d > hx,d +1 and B_Violation(b_req, ∆, {vj}∪Px,d ∪Φ) = false
then hj,d← hx,d +1 and Pj,d← Px,d ∪{vj}
until hx,d = ∞ or X = {};
H ← {} and P ← {};
for each vi ∈V−{vd} do
H ← H∪{hi,d} and P ← P∪Pi,d.
Next, we explain the execution of B_Violation. B_Violation has three input parameters: b_req,
∆ and Φ’, where b_req and ∆ are inherited from Shortest_Routes and Φ’ is a superset of Φ. The
hosts in ∆ (Φ’) are destinations (forwarders) of the new flow. Let N
i be the set of hosts that are
neighboring to vi and b_ri be the residual bandwidth of vi. Also, let M=∆∪Φ’∪
U
' Φ ∈ j v j N .
B_Violation checks if the forwarders in Φ’ cause bandwidth violation to every host in M. By
means of checking the hosts in
U
' Φ ∈ i v i
N , HRP can be avoided to the ongoing flows that pass
through the one-hop neighbors of the forwarders in Φ’. Bandwidth violation happens to a host v
i
in M if the bandwidth increment induced by the forwarders in Φ’ exceeds v
i’s residual bandwidth,
i.e., |(Ni∪vi)∩Φ’|×b_req>b_ri. If bandwidth violation happens, then B_Violation returns true.
Finally, B_Violation returns false, if no bandwidth violation happens. B_Violation is detailed below. Procedure B_Violation(b_req, ∆, Φ’); M=∆∪Φ’∪
U
' Φ ∈ j v j N ; for each vi ∈M do begin if |(Ni∪vi)∩Φ’|×b_req>b_rithen return true;
end;
return false.
The proposed heuristic algorithm, named B_Satisfied_Multicast_Tree, has three input
parameters: vs, D and b_req, where vs is the source (i.e., the server) of the new flow, D is the set
of the destinations (i.e., the clients) of the new flow, and b_req is the bandwidth requirement for the new flow. B_Satisfied_Multicast_Tree intends to establish a bandwidth-satisfied multicast tree for
the new flow. Let ∆⊆D be a subset of the destinations and F be the set of forwarders in the
multicast tree. Initially, set ∆={} and F={vs}.
The bandwidth-satisfied multicast tree is established iteratively by a repeat-until loop.
Without loss of generality, assume D={
1
d v ,
2
d
v , …, vdc}, where c=|D| and vdi is the ith client
in D, In each iteration, a client vy who was not selected before is determined and is connected to
the server vs. In the first iteration, the shortest bandwidth-satisfied routes from vs to every vdiare
selected from Ps (computed by Shortest_Routes).
i
d s
P, s are selected, which are the shortest
routes from vs to vdis. Then, the client vy with the minimum distance to vs among the all clients is
determined. F (∆) is replaced with F∪P’s,y (∆∪{vy}) and vy is removed from D. It should be
noted that P’s,y is a bandwidth- satisfied route from vs to vy.
In the second iteration, a bandwidth-satisfied multicast tree will be determined. For every client
i
d
v in D, a forwarder vx ∈F that is closest to vdi is first determined. Then, Px, di ∈P is
selected as the shortest route to
i
d
v . Then, the client vy with the minimum distance to the
forwarders in F is determined and F (∆) is updated. Now F represents a tree that connects vs with
two clients. The tree is bandwidth-satisfied (hence can avoid HMRP), as a consequence of executing Shortest_Routes(
i
d
v , b_req, ∆, F, H, P) in the first iteration. The execution for the
other iterations is very similar. Finally, when the execution of B_Satisfied_Multicast_Tree
terminates, F represents a bandwidth-satisfied multicast tree that connects vs with v ,d1 v , d2 …,
c
d
v . B_Satisfied_Multicast_Tree is detailed below.
Procedure B_Satisfied_Multicast_Tree(vs, D, b_req);
repeat D’ ← {}; for i ← 1 to |D| do begin Shortest_Routes( i d v , b_req, ∆, F, H, P);
determine vx ∈F so that hx,di= min{hj,di| vj ∈F};
if hx≠ ∞ then D’ ← D’∪{ vx }, h'x,di← i d x h , and P'x,di← i d x P, else exit end
determine vy ∈D’ so that h’k,y = min{h’k,y | vk ∈F};
F ← F∪P’k,y and ∆ ← ∆∪{ vy } and delete vy from D;
until D=∞.
Recall that the adjacency of hosts is necessary to Shortest_Routes. Also, all b_ris are
necessary to Shortest_Routes and B_Violation. Hence, they should be made available before
B_Satisfied_Multicast_Tree is invoked.
The new proposed algorithm is responsible to collect the two items of data. The adjacency of
hosts is conveniently represented by an adjacency 0/1 matrix, where a 1 (0) in the (vx, vy)- entry
denotes that vx and vy are (are not) neighboring. Two new control packets named b_join_query
and b_join_reply are used, instead of join_query and join_reply. Let vs denote the server and vi
denote an arbitrary host. Five variables: t, hopcount, Ni, Ňi and B_ri are introduced, where
t: the elapsed time required to transmit a packet between two neighboring hosts;
hopcount: the number of hops distant from vs;
Ni : the set of all neighbors of vi;
Ňi : the set of Njs collected by vi;
B_ri : the set of b_rjs collected by vi.
When vs intends to initiate a flow with bandwidth requirement b_req to the clients, it
broadcasts a b_join_query, which carries hopcount, over a region with a radius of maxhopcount
hops centered at vs, where maxhopcount is a predefined integer. Upon receiving a non- redundant
b_join_query from a host, say vα, vi relays it to its neighbors and then waits for a time period to
receive b_join_replys from its neighbors. If timeout happens, vi replies a b_join_reply to vα,
Initially, set Ňi ={Ni} and B_ri ={b_ri}. Upon receiving a b_join_reply from a host, say vβ, Ňi
(B_ri) is replaced with Ňi ∪ Ňβ, (B_ri ∪ B_rβ). The new algorithm is elaborated below.
(1) The server vs performs the following.
(1.1) Set hopcount=0.
(1.2) Transmit a b_join_query(hopcount) to its neighbors.
(1.3) Wait for b_join_replys from its neighbors for a time period of 2×(maxhopcount−
1)×t.
(2) Upon receiving a non-redundant b_join_query(hopcount) from a host, say vα, a host vi
performs the following.
(2.1) Set Ňi ={Ni} and B_ri ={b_ri}.
(2.2) If hopcount<maxhopcount−1, perform the following.
(2.2.1) Set hopcount=hopcount+1.
(2.2.2) Transmit b_join_query(hopcount) to its neighbors.
(2.2.3) Wait for b_join_replys from its neighbors for a time period of 2×(maxhopcount−
1−hopcount)×t.
(2.3) If hopcount=maxhopcount−1, reply a b_join_reply(Ňi, B_ri) to vα.
(3) Upon receiving a b_join_reply(Ňβ, B_rβ) from a host, say vβ, a host vi performs
the following.
(3.1) Set Ňi =Ňi ∪Ňβ and B_ri =B_ri ∪B_rβ.
When timeout happens at step (2.2.3), vi replies a b_join_reply(Ňi, B_ri) to vα. Finally, the
algorithm terminates when timeout happens at step (1.3), and vs can obtain the adjacency 0/1
matrix for all hosts and all b_ris from Ňs and B_rs, respectively. Recall that the adjacency of hosts
and all b_ris are necessary to B_Violation and Shortest_Routes, which are two procedures in
B_Satisfied_Multicast_Tree. Then, vs can discover a bandwidth-satisfied multicast tree by
invoking B_Satisfied_Multicast_Tree.
(3)
Recovery of bandwidth-satisfied multicast trees
Two control packets, i.e., b_join_query and b_join_reply, are used to collect the network information in order to discover bandwidth-satisfied multicast trees. An inadequate multicast tree is likely to be established if some control packets are lost. Besides, routes may become outdated or disconnected due to host movement. In this section, a distributed algorithm is proposed to recover inadequate multicast trees
A client can monitor the receiving packets delivered from the server in order to check that the receiving rate is bandwidth-satisfied. Once it detects an un-satisfied route, it initiates a distributed algorithm to find a new bandwidth-satisfied route to the server. The found route reconnects the client to the server. In the case, the client broadcasts a control packet b_recovery_query, which
carries F＝{} (F is the set of forwarders in the found route), to its neighbors. When a host vi (i.e., a
neighbor) receives the packet, vi checks if the requested bandwidth causes bandwidth violation to
vi, i.e., |(Ni∪vi)∩F|×b_req>b_ri, or vjs (neighbors of vi), i.e., |(Nj∪vj)∩F|×b_req>b_rj. Recall
that vi can estimate b_ri and b_rj by the method of Section 3.1. If not, vi replaces F with F∪{vi}
and then forwards the packet. Otherwise, it discards the received packet.
A host who receives the forwarding packet executes the same checking and forwarding procedure. Once a host along the existing multicast tree receives the packet, it replies another control packet b_recovery_reply to the client along the reverse route. The client may receive multiple replied packets from multiple hosts. Since we attempt to minimize the number of forwarders along the recovery tree, the client selects the host with the minimum number of hops to it and connects to the server by the corresponding reverse route to this host. Then, the multicast tree can be recovered.
五、結果與討論
Simulations are implemented using the Network Simulator 2 package (ns-2, version 2.27) [14]. IEEE 802.11 distribution coordination function (PCF) is used as the MAC layer protocol. Packets are sent using the un-slotted Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA). Each host is equipped with a radio transceiver whose transmission range is up to 250 meters over a wireless channel. We use Two Ray Ground model to predict the signal power received by the receiver. In this model, reflection of ground is considered and the power of a
signal attenuates as 1/d2, where d is the distance between the two hosts.
In the simulations, CBR data traffic flows are injected into the network from the servers and the size of data payload is 512 bytes. Each host has a MAC layer FIFO transmission queue of 64 packets at maximum.
Three performance measures: receiving rate, admission rate and number of control bytes are adopted. The receiving rate is the ratio of the number of data packets received by clients to the number of data packets delivered from servers. If bandwidth violation happens, it will drop drastically. The admission rate is the ratio of the number of multicast groups admitted to the number of multicast groups requested. When the admission rate goes up, the network performance increases. On the other hand, the number of control bytes can reflect the overheads incurred for constructing/maintaining the multicast routes.
For convenience, we use Heu to denote our bandwidth-satisfied multicasting protocol. Since
B_Satisfied_Multicast_Tree is heuristic, an optimal algorithm for BSMTP is necessary in order to
evaluate the performance of B_Satisfied_Multicast_Tree. In [16], the authors formulated BSMTP as a 0/1 integer linear programming, which can be well solved by a branch-and-bound algorithm (see [17]). We use Opt to denote the 0/1 integer linear programming solved by such a branch-and-bound algorithm. Opt can serve as a benchmark for evaluating the performance of
B_Satisfied_Multicast_Tree.
The simulations are performed with four aspects. First, we use two examples to show the effectiveness of Heu in avoiding HRP and HMRP. Second, performance comparison is made among Heu, Opt and MCEDAR under the assumption of static hosts. Third, the same performance comparison is made for mobile hosts. Fourth, the performance of Heu is investigated by assigning different values of network size and group size. Forty runs with different seed numbers are conducted for each scenario and collected data for these runs are averaged.
(一)
Avoidance of HRP and HMRP
We first present a simple simulation in a 1000m×1000m area with 50 randomly positioned
hosts. Figure 6 shows the three routes constructed by AQOR for three flows, i.e., Flow 1, Flow 2 and Flow 3. Each flow requires 140 Kbps. Flow 1 starts transmission first, Flow 2 starts transmission after 2000 seconds elapsed, and Flow 3 starts transmission after 4000 seconds elapsed. Their receiving rates, which are collected every 10 seconds, are exhibited in Figure 7. During the first 4000 seconds, the receiving rates of Flow 1 and Flow 2 approach one. However, after 4000 seconds elapsed, the receiving rate of Flow 2 drops drastically, as a consequence of HRP triggered by Flow 3. Bandwidth violation occurs at two forwarders for Flow 2.
Figure 8 shows the multicast tree constructed by MCEDAR for a multicast group, which carries a flow from the server to three clients, i.e., Client 1, Client 2 and Client 3. The flow requires 140 Kbps. Although each server-to-client route is self-bandwidth-satisfied, the multicast routes as a whole are not bandwidth-satisfied. When the flow goes over the multicast tree, HMRP is triggered and bandwidth violation occurs at two forwarders of the route to Client 2. The receiving rates are exhibited in Figure 9.
Figure 10 and Figure 11 (Figure 12 and Figure 13) demonstrate the effectiveness of Heu in avoiding HRP (HMRP) that was triggered in Figure 6 and Figure 7 (Figure 8 and Figure 9), respectively. Two additional QoS routing protocols, proposed by Yang et al. [19] and Chen et al. [20], are also simulated and evaluated in Figure 10 and Figure 11.
As observed from Figure 10, the three protocols (i.e., Heu, protocol of [19] and protocol of [20]) construct the same bandwidth-satisfied routes for Flow 1, Flow 2 and Flow 3, because they all try to determine shorter routes. The receiving rates for the three flows are exhibited in Figure 11, which are all equal to one, because the bandwidth consumption of the two-hop hosts is considered in these protocols.
0 100 200 300 400 500 600 700 800 900 1000 0 100 200 300 400 500 600 700 800 900 1000 Flow 1 Flow 2 Flow 3 Destination
Sender Forwarder Bandwidth violation
Figure 6. Three routes constructed by AQOR.
0 1000 2000 3000 4000 5000 6000 7000 8000 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 Time (sec) R e c e iv in g r a te Flow 1 Flow 2 Flow 3
Figure 7. Receiving rates for the three flows of Figure 6. 0 100 200 300 400 500 600 700 800 900 1000 0 100 200 300 400 500 600 700 800 900 1000 Client
Server Forwarder Bandwidth violation
Client 1 Client 2
Client 3
Figure 8. The multicast tree constructed by MCEDAR. 0 1000 2000 3000 4000 5000 6000 7000 8000 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 1.1 Time (sec) R e c e iv in g r a te Client 1 Client 2 Client 3
Figure 9. Receiving rates for the three clients of Figure 9. 0 100 200 300 400 500 600 700 800 900 1000 0 100 200 300 400 500 600 700 800 900 1000 Flow 1 Flow 2 Flow 3 Destination
Sender Forwarder Bandwidth violation
Figure 10. Three bandwidth-satisfied routes constructed by Heu, protocol of [19] and
protocol of [20]. 1000 2000 3000 4000 5000 6000 7000 8000 0.6 0.8 1 1000 2000 3000 4000 5000 6000 7000 8000 0.6 0.8 1 1000 2000 3000 4000 5000 6000 7000 8000 0.6 0.8 1 Time (sec) R e cxei v ing r a te s Flow 3 Flow 2 Flow 1
Figure 11. Receiving rates for the three flows of Figure 10.
Client 2 and Client 3. The receiving rates for the three clients are exhibited in Figure 13, which are all equal to one. For the two illustrative examples, Heu can avoid HRP and HMRP, while AQOR induces HRP and MCEDAR induces HMRP.
0 100 200 300 400 500 600 700 800 900 1000 0 100 200 300 400 500 600 700 800 900 1000 Client
Server Forwarder Bandwidth violation
Client 1 Client 2
Client 3
Figure 12. The bandwidth-satisfied multicast tree constructed by Heu.
0 1000 2000 3000 4000 5000 6000 7000 8000 0.6 0.8 1 0 1000 2000 3000 4000 5000 6000 7000 8000 0.6 0.8 1 R e c e iv in g ra te 0 1000 2000 3000 4000 5000 6000 7000 8000 0.6 0.8 1 Time (sec) Client 3 Client 1 Client 2
Figure 13. Receiving rates for the three clients of Figure 12.
(2)
Performance comparison: static hosts
The simulation environment is the same as that adopted in Section 2.4, where 50 hosts are
randomly distributed over a 1000m×1000m area. Ten multicast groups, denoted by G1, G2, …, G10,
are randomly created. They are identical with those created in Section 2.4. Each multicast group consists of one server and three clients. A flow requiring 50 Kbps is sent from the server to the
clients. The simulations proceed for 1000 seconds; G1 starts first, G2 starts after 100 seconds
elapsed, G3 starts after 200 seconds elapsed, and so on. Figure 14 and Figure 15 compare the
admission rates and receiving rates of Heu, Opt and MCEDAR under the assumption of static hosts.
Refer to Figure 14. When the number of multicast groups is smaller than 5, Heu has higher admission rates than MCEDAR, as a consequence that the multicast trees constructed by it with fewer forwarders. On the other hand, when the number of multicast groups exceeds 5, Heu has lower admission rates than MCEDAR. Recall that the probability that MCEDAR induces HMRP jumps up when the number of multicast groups exceeds 5 (refer to Figure 4). Also, Figure 15 demonstrates that the receiving rate of MCEDAR drops drastically when the number of multicast groups exceeds 5. When the number of multicast groups increases to 10, the receiving rate of Heu
1 2 3 4 5 6 7 8 9 10 0.5 0.6 0.7 0.8 0.9 1
Number of multicast groups
Ad m is s io n r a te MCEDAR Heu Opt
Figure 14. Admission rate for static hosts.
1 2 3 4 5 6 7 8 9 10 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 1 1.05
Number of multicast groups
Re c e iv in g r a te MCEDAR Heu
Figure 15. Receiving rate for static hosts. When there are feasible solutions to BSMTP, Opt can always determine the optimal one. However, it is likely that Heu fails to find a feasible one. Figure 14 also reveals the success rate of Heu in finding a feasible solution to BSMTP. The success rate can be estimated by means of the ratio of the admission rate of Heu to the admission rate of Opt. For one extreme case in which there
is one multicast group, the success rate is estimated as 1/1=1. For the other extreme case in which
there are ten multicast groups, the success rate is estimated as 0.497/0.54=0.92. For the other
cases, the success rate ranges from 0.92 to 1.
(3)
Performance comparison: mobile hosts
The simulation environment models a network of 50 hosts distributed randomly over a
1000m×1000m area. Host mobility is based on the random waypoint model [18], in which a
host’s movement consists of a sequence of random length intervals, called mobility epochs. During each epoch, a host moves in a constant direction and at a constant speed. The simulations
proceed for 1000 seconds and the speed varies from 5 to 20 meters per second (or 18 to 72
kilometers per hour). The first seven multicast groups, i.e., G1, G2, …, G7, that were created in
Section 4.2 are used in the simulations. A flow requiring 50 Kbps is sent from the server to the clients. 5 10 15 20 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 1 MCEDAR Heu A v eg ag e r e c e iv in g r a te Speed (m/sec)
Figure 16. Receiving rate for mobile hosts.
5 10 15 20 0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 1.5 1.6x 10 7 MCEDAR Heu N u m b er of c o n tr o l b y te s Speed (m/sec)
Figure 17. Number of control bytes for mobile hosts.
Figure 16 compares the receiving rates of Heu and MCEDAR under the assumption of mobile hosts. Like the previous situation of static hosts, Heu has higher receiving rates than
MCEDAR. Figure 17 shows that Heu generates fewer control bytes than MCEDAR. Control bytes are generated for constructing a new bandwidth-satisfied multicast tree if the current multicast tree cannot satisfy the bandwidth requirement.
六、參考文獻
[1] S. Voss, “Steiner’s problem in graphs: heuristic methods,” Discrete Applied Mathematics, vol. 40, no. 1, pp. 45-72, 1992.
[2] R. Novak and J. Rugelj, “Distribution of constrained Steiner tree computation in point-to-point networks,” Proceedings of the Mediterranean Electrotechnical Conference on
Industrial Applications in Power Systems, Computer Science and Telecommunications, 1996,
pp. 959-962.
[3] C. P. Low and X. Song, “On finding feasible solutions for the delay constrained group multicast routing problem,” IEEE Transactions on Computers, vol. 51, pp. 581-588, 2002. [4] V. P. Kompella, J. C. Pasquale, and G. C. Polyzos, “Multicast routing for multimedia
communication,” IEEE Transactions on Computers, vol. 51, pp. 581-588, 2002.
[5] Q. Sun and H. Langendoerfer, “Multicast routing for multimedia communication,”
Proceedings of the Second Workshop on Protocols for Multimedia Systems, 1995, pp.
452-458.
[6] R. Sivakumar, P. Sinha, and V. Bharghavan, “CEDAR: a core-extraction distributed ad hoc routing algorithm,” IEEE Journal on Selected Areas in Communications, vol. 17, pp. 1454-1465, 1999.
[7] S. Chen and K. Nahrstedt, “Distributed quality-of-service routing in ad hoc networks,” IEEE
Journal on Selected Areas in Communications, vol. 41, pp. 120-124, 1999.
[8] Q. Xue and A. Ganz, “Ad hoc QoS on-demand routing (AQOR) in mobile ad hoc networks,”
Journal of Parallel and Distributed Computing, vol. 41, pp. 120-124, 2003.
[9] P. Sinha, R. Sivakumar, and V. Bhanghavan, “MCEDAR: multicast core-extraction distributed ad-hoc routing,” Proceedings of the IEEE Wireless Communications and
Networking Conference, 1999, pp. 1313-1317.
[10] E. Pagani and G.P. Rossi, “A framework for the admission control of QoS multicast traffic in mobile ad hoc networks, “Proceedings of the ACM International Workshop on Wireless
Mobile Multimedia, 2001, pp. 3-12.
[11] H. Lim and C. Kim, “Multicast tree construction and flooding in wireless ad hoc networks,”
Proceedings of the ACM International Workshop on Modeling, Analysis and Simulation of Wireless and Mobile Systems, 2000, pp. 61-68.
[12] R. Novak and J. Rugelj, “Distribution of constrained Steiner tree computation in point-to-point networks,” Proceedings of the IASTED International Conference Applied
Informatics, 1996, pp. 279-282.
[13] V. Bharghavan, A. Demers, S. Shenker, and L. Zhang, “MACAW: a media access protocol for wireless LAN’s,” Proceedings of ACM SIGCOMM, 1994, pp. 212-225.
[15] E. W. Dijkstra, “A note on two problems in connection with graphs,” Numerische
Mathematik, vol. 1, pp. 269-271, 1959.
[16] C. C. Hu, E. H. K. Wu, and G. H. Chen, “Feasible bandwidth-satisfied multicast tree determination in MANETs,” Proceedings of the IEEE International Conference on Wireless
and Mobile Computing, Networking and Communications, 2005, to appear.
[17] A. Geoffrion and R. Marsten, “Integer programming algorithms: a framework and state- of-the-art survey,” Management Science, vol. 18, pp. 465-491, 1972.
[18] C. Bettstetter, G. Resta, and P. Santi, “The node distribution of the random waypoint mobility for wireless ad hoc,” IEEE Transactions on Mobile Computing, vol. 2, no. 3, pp. 257-269, 2003.
[19] Y. Yang and R. Kravets, “Content-aware admission control for ad hoc networks,” IEEE
Transactions on Mobile Computing, vol. 4, no. 4, pp. 363-377, 2005.
[20] L. Chen and W. Heinzelman, “Qos-aware routing based on bandwidth estimation for mobile ad hoc networks,” IEEE Journal on Selected Areas in Communications, vol. 23, no. 3, pp. 561-572, 2005.
[21] L. Kou, G. Markowsky, and L. Bermain, “A fast algorithm for Steiner trees,” Acta
Informatica, vol. 15, no. 2, pp. 141-145, 1981.
[22] S. Ramanathan, “Multicast tree generation in networks with asymmetric links,” IEEE/ACM
Transactions on Networking, vol. 4, no. 4, pp. 558-568, 1996.
[23] M. Smith and P. Winter, “Path distance heuristics for the Steiner problem in undirected networks,” Algorithmica, vol. 7, no. 23, pp. 309-327, 1992.
[24] H. Takahashi and A. Matsuyama, “An approximate solution for the Steiner problem in graphs,” Mathematica Japonica, vol. 24, no. 6, pp. 573-577, 1980.
[25] F. Bauer and A. Varma, “Distributed algorithms for multicast path setup in data networks,”
IEEE/ACM Transactions on Networking, vol. 4, no. 2, pp. 181-191, 1996.
[26] L. Gatani, G. L. Re, and S. Gaglio, “An efficient distributed algorithm for generating multicast distribution trees,“ Proceedings of the International Conference on Parallel
Processing Workshops, 2005, pp. 477-484.
[27] V. P. Kompella, J. C. Pasquale, and G. C. Polyzos, “Multicast routing for multimedia communication,” IEEE/ACM Transactions on Networking, vol. 1, no. 3, pp. 286-292, 1993. [28] V. P. Kompella, J. C. Pasquale, and G. C. Polyzos, “Two distributed algorithms for
multicasting multimedia information,” Proceedings of the International Conference on
Computer Communications and Networks, 1993, pp. 343-349.
[29] S. J. Lee and M. Gerla, “On-demand multicast routing protocol in multihop wireless mobile networks,” ACM/Kluwer Mobile Networks and Applications, vol. 7, pp. 441-453, 2002. 七、計畫結果自評
HRP and HMRP, which are two bandwidth-violation problems that may occur to previous QoS routing/multicasting protocols, were introduced in this paper. The simulation showed that when the network traffic is saturated (the number of multicast groups exceeds 5), AQOR will induce HRP and MCEDAR will induce HMRP. The network performance will drop
drastically if they are induced.
Since bandwidth and power are limited in MANETs, they should be taken into consideration in routing/multicasting protocols. The problem (i.e., BSMTP) of determining a bandwidth-satisfied multicast tree with minimum number of forwarders was studied in this paper. Two algorithms that can generate bandwidth-satisfied multicast trees were proposed. They can construct bandwidth-satisfied multicast trees without inducing HRP and HMRP.
Performance comparison was made among Heu, Opt and MCEDAR, where Opt served as a benchmark. Heu has higher receiving rates than MCEDAR, and it maintains high receiving rates (between 0.859 and 1) even if the network traffic is saturated. If the network traffic is not saturated (the number of multicast groups is smaller than 5), Heu can admit more multicast groups than MCEDAR, which is a consequence that the multicast trees constructed by it with fewer forwarders. Moreover, the admission rate of Heu is close to the benchmark. The ratio of the admission rate of Heu to the admission rate of Opt ranges from 0.92 to 1.
很高興有這次的機會可以參加在布拉格舉行的 ACM MSWIM 會議, 藉由這次的 會議, 不僅僅有技術上的許多收穫, 也增廣了我做研究的多方面思考方向
