OGHAM: On-demand global hosts for mobile
ad-hoc multicast services
Chia-Cheng Hu
a,*, Eric Hsiao-Kuang Wu
b,1, Gen-Huey Chen
aa
Department of Computer Science and Information Engineering, National Taiwan University, No.1, Sec. 4, Roosevelt Road, Taipei, Taiwan, ROC
b
Department of Computer Science and Information Engineering, National Central University, Chung-Li, Taiwan, ROC Received 12 December 2004; received in revised form 30 April 2005; accepted 30 August 2005
Available online 26 September 2005
Abstract
Recent advances in pervasive computing and wireless technologies have enabled novel multicast services anywhere, any-time, such as mobile auctions, advertisement, and e-coupons. Routing/multicast protocols in large-scale ad-hoc networks adopt two-tier infrastructures to accommodate the effectiveness of the flooding scheme and the efficiency of the tree-based scheme. In these protocols, hosts with a maximal number of neighbors are chosen as backbone hosts (BHs) to forward packets. Most likely, these BHs will be traffic concentrations or bottlenecks of the network and spend significant amount of time forwarding packets. In this paper, 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. BHs thus found have the advantages of shorter relay and less concen-tration. Besides, BHs are selected on-demand and can be globally reused for different multicast groups without flooding again. Simulation results show that the proposed protocol has shorter transmission latency, fewer control/data packets and higher receiving data packet ratios than other existing multicast protocols. Besides, the two-tier infrastructure constructed by the proposed protocol is more stable.
2005 Elsevier B.V. All rights reserved.
Keywords: Ad-hoc network; Distributed algorithm; Linear programming; Multicast
1. Introduction
With the advent of IP technologies and the tre-mendous growth in data traffic, novel applications
that require multicast support are becoming more and more widespread. Another interesting recent development is the emergence of dynamically wire-less ad-hoc networks to interconnect mobile hosts. In contrast to traditional cellular networks, Ad-hoc networks require no fixed infrastructure or central-ized administration, and hosts must communicate one another via packet radios in a collaborated man-ner. Disaster recovery and automated battlefields are 1570-8705/$ - see front matter 2005 Elsevier B.V. All rights reserved.
doi:10.1016/j.adhoc.2005.08.003
* Corresponding author. Tel.: +886 2 23625336 407; fax: +886
2 23628167.
E-mail address:[email protected](C.-C. Hu).
1
Tel.: +886 3 4227151 4514; fax: +886 3 4222681.
two typical applications of ad-hoc networks. Recent advances in wireless telecommunication technolo-gies and portable computing are continuing to drive the revolution towards large-scale networks and flexible new generation e-services.
Multicast communication enables a number of novel e-services, such as mobile auctions, game ranking update, audio/video conferencing and distribution of stock quotes. A multicast group in a mobile ad-hoc network (MANET) contains a special host (server) that is responsible for transmit-ting data packets to the other hosts (clients) in the same group. A typical example of multicast groups is a commander and his soldiers in a battlefield. The soldiers need to keep listening to the commander. There are other examples in which multicast groups need to be established.
Recently, several MANET multicast protocols
have been proposed in the literature [1–6]. They
can be classified into tree-based protocols[1–4]and
mesh-based protocols [5,6]. Tree-based protocols
build a tree for each multicast group, whereas mesh-based protocols create a mesh of hosts for forwarding packets between multicast members. For both protocols, adding a new member into an existing multicast group will cause the flooding of a join request message over the entire network. Fur-ther, they also trigger the flooding of control packets during the maintenance of the infrastructures. The flooding process is very time-consuming and
band-width-consuming, especially, for a large-scale
MANET.
To avoid the inefficiency of flooding, some
rout-ing protocols, e.g., Spine[7], CEDAR[8]and VDBP
[9], and multicasting protocols, e.g., MCEDAR[10]
and ADB [11], adopt two-tier infrastructures for a
large-scale MANET. Some of the hosts, named backbone hosts (BHs for short), are responsible for managing the flooding, maintaining the infra-structures and determining multicast routes. These protocols all select BHs by finding dominating sets with a maximal number of neighbors.
Since most of packets are initiated and processed by BHs, a proper way to select BHs is crucial to a two-tier infrastructure. In MANETs, a host can transmit packets in omni directions, and so each transmission is a local broadcast. Since only one host is allowed to broadcast within a transmission
range at a time, the BHs determined in [7–11] are
likely to be traffic concentrations or bottlenecks of the networks, i.e., to consume more time in contend-ing radio channels with their neighbors. They also
suffer from frequent changes in highly mobile MANETs. Frequent changes of BHs adversely affect the performance of the networks.
In this paper, a novel multicast protocol, named on-demand global hosts for ad-hoc multicast (OGHAM for short), is presented for large-scale MANETs. OGHAM adopts a new methodology to construct a two-tier infrastructure on-demand for ad-hoc multicast services. Once the infras-tructure for a particular multicast group is con-structed, the selected BHs are globally available for the other ad-hoc multicast groups. Therefore, it is not necessary for follow-up multicast groups to flood again in order to construct additional infrastructures.
In OGHAM, a distinct strategy for selecting BHs is proposed, which minimizes the total number of hops to the other hosts. BHs thus found can deter-mine shorter multicast routes than those deterdeter-mined in [7–11]. To obtain shorter routes is one of the major concerns in most of existing routing/multicast protocols. It can reduce the number of hosts partic-ipating in packet forwarding so as to lower
band-width consumption and shorten transmitting
latency from servers to clients. In particular, the issue of shorter routes must be carefully scrutinized for large-scale multicast services, because the BHs attached by servers transmit packets to multiple clients over the networks.
2. Finding backbone hosts
Given a set N of users, the facility location prob-lem is to determine a feasible subset (i.e., facilities) of N so that a predefined objective function is
optimized [12]. This problem is known to be
NP-hard[13], and it can be formulated as a 0/1 integer
linear programming (ILP). The problem of selecting BHs in a two-tier infrastructure is similar to the facility location problem in some aspects. They both intend to determine a feasible subset from a gi-ven set so that a predefined objective function is optimized. The major differences between them are the objective functions and the constraints. This motivates us to attack the problem of selecting BHs with an ILP approach. That is, we first attempt to formulate our problem as a 0/1 ILP, and then work out a solution method to the formulated 0/1 ILP.
Suppose that there are n hosts, denoted by
v1, v2, . . . , vn, and let di,jbe the number of hops from
di,j= 0 if i = j, and di,j> 0 an integer if i 5 j. We
assume di,j= dj,i for all pairs of i and j. Let
wi¼P16j6ndi;j be the total number of hops from
vi to the other n 1 hosts. We use xi= 1 (xi= 0)
to denote that vi is (is not) chosen to be a BH,
and yi,j= 1 (yi,j= 0) to denote that host vi is (is
not) attached to BH vj. The hosts that are not
BHs are called NBHs.
The objective is to minimize the total number of
hops from each BH to the other n 1 hosts, i.e., to
minimize P16i6nxiwi. In a two-tier infrastructure,
each host is required to be attached to exactly one BH with at most r hops distant, where r P 1 is a
predefined integer. Therefore, two constraints
are induced: P16j6nyi;j¼ 1 for all 1 6 i 6 n and
xj yi,jP0 for all 1 6 i 6 n and 1 6 j 6 n. Initially,
we set yi,j= 0 if di,j> r. The 0/1 ILP formulation for
our problem is as follows:
If xi2 {0, 1} and yi,j2 {0, 1} are relaxed to
0 6 xi61 and 0 6 yi,j61, then an LP results,
which is polynomial-time solvable. Suppose that xi
and y
i;j are the optimal solution to the LP, where
1 6 i 6 n and 1 6 j 6 n. In the following, we present
a rounding algorithm that can round x
i and yi;jto x0i
and y0
i;j, where x0i2 f0; 1g and y0i;j2 f0; 1g are a
fea-sible solution to the 0/1 ILP. Initially, we set x0
i¼ xi
for all 1 6 i 6 n and let X ¼ fx
ij0 < xi <1g.
The rounding algorithm is executed iteratively
until X is empty. In each iteration, a host vc is
selected as a BH if the increment (i.e., D+) of the
objective function induced by setting x
c ¼ 1 is
min-imum, where x
c 2 X . To offset the increment, we
then set x
j ¼ 0 for all hosts vj with at most r hops
distant from vc. That is, hosts vjare determined as
NBHs. We use D to denote the total decrement
induced by setting x
j ¼ 0. If D
+
D> 0, the
objec-tive function is further decreased by reducing some
values x
l to fx
l, where 0 < f < 1. We intend to have
the objective function as small as possible under constraints. The rounding algorithm is presented below. 1. Determine xc 2 X so that ð1 x cÞwc¼ min fð1 x iÞwijxi 2 X g. 2. Compute Dþ¼ ð1 x cÞwc.
/*D+ is the increment of the objective function
induced by setting x
c¼ 1*/.
3. Set x0
c¼ xc ¼ 1 and delete xc from X.
4. Determine Y ¼ fx jjxj2 X and dc;j6rg. 5. Compute D¼Px j2Yx jwj.
/* Dis the decrement of the objective function
induced by setting x
j¼ 0*/.
6. Set x0
j¼ xj ¼ 0 and delete xj from X for all
x
j 2 Y .
/* Each vjthat is at most r hops distant from vcis
determined as an NBH*/.
7. If D+ D> 0 and X is not empty, determine
0 < f < 1 satisfying Px l2Xðx l fx lÞwlP Dþ
D and then set x
l ¼ fx
l for all xl 2 X .
/* When D+ D> 0, the objective function is
further decreased by reducing x
l to fx
l*/. 8. If X is not empty, go to 1.
9. For each host vi, determine a BH, say vp, that is
closest to viand then set y0i;p¼ 1 and y0i;q¼ 0 for
all 1 6 q 6 n and q 5 p.
/* Each host is attached to the closest BH*/.
As a consequence of step 9, if vi is a BH, then
y0
i;i¼ 1 and y0i;q¼ 0 for all 1 6 q 6 n and q 5 p. In
other words, when y0
i;j¼ 1 (i 5 j), we have x0i¼ 0
and x0
j¼ 1. Suppose that xi and yi;j are the optimal
solution to the 0/1 ILP, where 1 6 i 6 n and
1 6 j 6 n. Let S¼P16i6nxi wi, S¼P16i6nxiwi
and S0¼P16i6nx0iwi. Clearly, S**6S*. In the
fol-lowing lemma, we show that the approximation
ratio, which is defined as S0
S, is bounded above by
1þmaxfwij16i6ng
S .
Lemma 1. S0
S 61þmaxfwSij16i6ng .
Proof. We assume that nkiterations are executed by
the rounding algorithm, and let Dþt and Dt denote
Minimize X
16i6n
xiwi
subject to X
16j6n
yi;j¼ 1 for all 1 6 i 6 n
xj yi;jP0 for all 1 6 i 6 n and 1 6 j 6 n
xi2 f0; 1g for all 1 6 i 6 n
Dand D+, respectively, evaluated at the tth
itera-tion, where 1 6 t 6 nk. Also, let St¼
P 16i6nxiwi¼ P x i2Xx iwiþPx0 j62Xx 0
jwj denote the value of the
objective function evaluated at the tth iteration.
Clearly, S0¼ Snk. We first consider t = 1. If Dþ1 D1 60, then S1¼ Sþ ðDþ1 D 1Þ 6 S . If Dþ1 D1 >0, then
further decrement (i.e., Px
l2Xðx
l fx
lÞwlÞ of
the objective function is made in step 7, and
so S1¼ Sþ ðDþ1 D 1Þ P x l2Xðx l fx lÞwl6S.
Then, we consider 2 6 t 6 nk 1. Similarly,
St¼ St1þ ðDþt D t Þ 6 St1 if D þ t D t 60, and St ¼ St1þ ðDþt D t Þ P x l2Xðx l fx lÞwl 6St1 if Dþt D t >0. Hence, ðS PÞS P S 1 P S2 P P Snk1.
Finally, we consider t = nk. Since X is empty after
step 6, we have S0¼ Snk ¼ Snk1þ ðD þ nk D nkÞ. Then, S0 S6 Snk 1þðDþ nkD nkÞ Snk 1 61 if D þ nk D nk 60. Otherwise, since S P Snk1¼ S 0 ðDþ nk D nkÞ, we have S06Sþ ðDþ nk D nkÞ 6 S þ Dþ nk 6Sþ maxfð1 xiÞwij1 6 i 6 ng 6 Sþ maxfwij1 6 i 6 ng, which implies S0 S61þ maxfwij16i6ng S . h
Next, we show that every NBH vpis attached to
one BH vqthat is at most 2r hops distant.
Lemma 2. dp,q62r if y0p;q¼ 1, where 1 6 p 6 n,
1 6 q 6 n, and p 5 q.
Proof. Suppose that vp is an NBH, i.e., x0p¼ 0. It
suffices to show that there exists a BH that is at
most 2r hops distant from vp. According to the
exe-cution of the rounding algorithm, we have either
0 < x
p<1 or xp¼ 0. If 0 < xp<1, then xp2 X
ini-tially. Assume that there are nkiterations executed.
Then, x
pis selected in Y at step 4 of some iteration,
say the tth iteration, where 1 6 t 6 nk. At the same
iteration, host vcis determined as a BH, as a
conse-quence of step 3. We have dc,p6r as specified at
step 4. That is, the distance from vpto vcis at most
r hops.
If xp¼ 0, let Zp¼ fvjjdp;j6r; xj >0 and 1 6 j
6ng, i.e., Zpis the set of hosts that are candidates
to be the attached BH of vp. We have Zpnonempty,
due to the constraints of the LP. For each vz2 Zp,
we have either x0z¼ 1 or x0z¼ 0 at the end of the
rounding algorithm. If x0z¼ 1, then vzis a BH and
its distance to vpis at most r hops. If x0z¼ 0, then
0 < xz <1. With the same arguments as the
previ-ous situation (i.e., 0 < xp<1), there exists a BH
that is at most r hops distant from vz. Hence, the
distance from vpto the BH is at most 2r hops. h
3. OGHAM protocol
OGHAM constructs a two-tier architecture by selecting BHs on-demand for multicast applications. Each multicast member must be attached to a BH. BHs are responsible for determining multicast routes, forwarding data packets, handling dynamic group membership (the clients can dynamically join or leave the group), and updating multicast routes due to host movement.
All hosts are assumed to use a common wireless channel for communication, and they have the same transmission radius. Two hosts can communicate directly if they are within the transmission range of each other. We assume that the communication is bi-directional. A host can transmit in omni direc-tions, and so each transmission is a local broadcast. Due to the common radio channel, only one host is allowed to broadcast within a transmission range at a time. We assume that there is a supporting MAC protocol that is responsible for channel access (scheduling, queuing, and contention resolution).
When a server (client) viattempts to create (join)
a multicast group, vifirst tries to find a BH within a
region with a radius of 2r hops centered at vi, where
r P 1 is a predefined integer. If such a BH can be
found, then viis attached to it. Otherwise, vi
broad-casts a message in a larger region, called multicast
region, with a radius of c hops centered at vifor
col-lecting neighboring information, where c P 2r is a
predefined integer. Then, viselects BHs for the
mul-ticast region and determines the attachment from
NBHs to BHs by the method of Section2. Also, vi
sends the list of all BHs and the neighboring infor-mation to each BH. A distributed algorithm for selecting BHs in a multicast region is detailed in Appendix A.
For example, suppose that a server s intends to create a multicast group and it cannot find a BH within 2 hops (r = 1 for this example). So, s reacts by triggering the selection of BHs in a multicast re-gion with a radius of c = 4 hops centered at s. Refer toFig. 1. First, s broadcasts a message in the
multi-cast region (refer to Fig. 1(a)). Upon receiving the
message, hosts in the multicast region reply their neighboring information to s. With the neighboring information, s then selects BHs and attaches NBHs
After BHs in the multicast region are selected, clients can join the multicast group by asking the attached BHs to query the location of the server. The BH attached by the server then replies to the queries. Through the round-trip communica-tion (querying and replying), the BH attached by server can determine the multicast routes from the server to the clients. A distributed algorithm for
determining multicast routes is detailed inAppendix
B.
With the same example ofFig. 1, assume that c1
and c2are two clients. They join the multicast group
by attaching themselves to b1 and b3, respectively.
The server s is attached to b2. Both b1and b3can
lo-cate s by querying b2. At the same time, the
multi-cast routes, i.e., s–b2–f1–b1–f2–c1and s–b2–f1–b3–c2,
from s to c1and c2, respectively, can be determined
(refer toFig. 2).
According to Lemma 2, each host is at most 2r hops distant from a BH in the multicast region. Hence, follow-up clients in the same group or mem-bers of subsequent multicast groups, all in the mul-ticast region, can be attached to BHs within 2r hops, without the need of further broadcasting. That is, the overheads to construct additional infrastruc-tures can be avoided.
As described above, the BHs attached by clients are responsible for querying the location of the server. For a client within a different multicast region from the server, the attached BH fails to lo-cate the server, and so it floods a query message over the entire network, in order to locate the server. Through the flooding, the two multicast regions where the client and the server are posi-tioned can be merged into a larger one. The merging
algorithm is detailed in Appendix C. After the
merging, a multicast route from the server to the client can be determined by the algorithm of Appendix B.
Following the example ofFig. 2, we assume that
there is a client c3, which is outside the multicast
re-gion of Fig. 2, attempting to join the multicast
group created by s. The gray portion ofFig. 3shows
the multicast region created by c3. There are two
BHs, i.e., b01and b02, selected in the new multicast
re-gion and c3is attached to b01. In order to locate s, b
0 1
floods a message. Upon receiving the message, b2
re-plies to b01. Through the message exchange, a
multi-cast route, i.e., s–b2–f1–b1–f2–f4–b01–c3, from s to c3
is then determined.
In OGHAM, the BHs attached by the members of the multicast groups determine multicast routes by the aid of neighboring information. However, the neighboring information has to be updated as hosts move. There are three mechanisms to relieve the mobility problem. First, a timestamp is stamped onto each entry of the neighboring information. An entry with an outdated timestamp will be removed from the neighboring information. Each host is re-quired to piggyback the up-to-date neighboring information onto the packets which it transmits or forwards. When BHs receive the packets, they up-date their neighboring information and refresh the timestamps with the piggybacked information. In this way, multicast routes with better availability
: server : BH : physical link : broadcasting s : attaching bi (a) s b1 b3 b2 (b) s
Fig. 1. BH selection in a multicast region. (a) Broadcasting and (b) selecting BHs and attaching NBHs to BHs.
: server : BH : physical link : multicast route s bi s b1 f2 f1 b3 b2 ci : client c1 c2 fi : forwarder
can be determined, and the size of the neighboring information is limited.
Second, when a BH detects a route disconnection, it determines an alternative route by the aid of the neighboring information to replace the disconnected
one. Let vsbe the server, vcbe a client, and vx(vy) be
the BH that vs(vc) is attached to. We use ps,xto
de-note a route from vsto vx(px,yand py,chave similar
meanings). Any route from vs to vc has to pass
through vxand vy. When a host vi(62{vs,vx}) in ps,x
detects a disconnected link to the downstream
(up-stream) host, it transmits a packet to notify vs (vx)
of this disconnection. The detection of disconnection
in pp,qand pc,qis alike. Compared with most of
pre-vious routing/multicasting protocols, which deter-mine a new route in the case of disconnection by flooding a message over the network, less frequent flooding is induced and the robustness of the infra-structure is enhanced in OGHAM.
Third, a threshold a is introduced for guarantee-ing the transmission quality of the multicast routes. The value of a is predefined, which depends on the quality requirement of the multicast applications. If a BH that is attached by a client counts a greater number of continuously lost data packets than a, i.e., more than a successive data packets transmitted from the server are not received by the BH, then it broadcasts a packet to all BHs for querying the cur-rent location of the server. On the other hand, if more than a successive data packets from the attached BH are not received by the client, then the client is attached to a new BH. Hence, by the aid of a, the transmission quality of the multicast routes can be assured.
It should be noted that a highly mobile BH will decline the performance. For such a situation, the second and third mechanisms proposed above can be applied to relieve the problem. When route
dis-connection occurs due to a highly mobile BH, the multicast members that are attached to it are in-formed of this disconnection by the second mecha-nism. Then, with a high probability, they can be attached to new BHs within 2r hops. It is revealed by Lemma 2 that the BHs selected by OGHAM are evenly distributed over a multicast region. On the other hand, if the data transmission to a client has a quality lower than a, then the third mecha-nism forces the client to be attached to a new BH. 4. Related two-tier multicast protocols
MCEDAR [9]and ADB [11] are two
represen-tative multicast protocols based on two-tier
infrastructures. MCEDAR, which is an extension
to CEDAR[8], has only a subset of the network
in-volved in computing multicast routes by extracting a dominating set (cores) from the network to be used for reducing the number of control messages. Each host periodically broadcasts a control message for selecting one of its neighbors with the largest degree as its core.
ADB, which is derived from VDBP [10], selects
BHs based on the concept of the dominating set. It relaxes the property of the dominating set and allows a host to be attached to a BH more than one hop away. It creates a forest of varying-depth trees, each of which is rooted at a BH. The selection of the BHs is based on the combination of normal-ized link failure frequency and neighbor degree. Data forwarding from members of the multicast groups are directed toward the BHs, instead of being broadcast to other irrelevant hosts or the en-tire network. Then, a flooding mechanism is em-ployed over the network of BHs to disseminate the data packets. Upon receiving data packets from a downstream host, a BH will forward them to
b2 c3 b1 f4 : physical link : multicast route s bi ci fi s b1 f2 f1 b3 b2 f3 c1 c2 : server : BH : client : forwarder ' '
every other BH. Table 1shows the comparison of OGHAM with MCEDAR and ADB.
5. Performance evaluation
Simulations for evaluating the performance of OGHAM and other multicast protocols are imple-mented using the Network Simulator 2 package
(ns-2) [14]. The simulation environment models
a large-scale MANET of 200 hosts distributed
randomly over a 1000 m· 1000 m area. The IEEE
802.11 MAC is used as the MAC layer protocol. Each host is equipped with a radio transceiver that is capable of transmitting up to approximately 100 m over a wireless channel. The transmission capability of each network interface is 2 Mbps and the size of data payload is 512 bytes. Ten runs with different seed numbers are conducted for each scenario and collected data are averaged over those runs.
The performance of OGHAM is studied by extensive simulations in three aspects. First, com-parisons are made between our strategy and those
adopted in other two-tier protocols[7–11]for
select-ing BHs. Second, performance comparisons are made among OGHAM, MCEDAR and ADB. Third, the performance of OGHAM is investigated by assigning different values of group size, group number and r.
5.1. Comparisons of two-tier infrastructure strategies
Two strategies, i.e., minimum dominating set and maximal number of neighbors, are adopted in
previous two-tier protocols [7–11] for selecting
BHs. They can be formulated as two 0/1 ILPs. Compared with the 0/1 ILP formulated in Section
2 for OGHAM, they have the same constraints
for two-tier infrastructures, but different objective functions.
The strategy of minimum dominating set aims to select a minimum number of BHs that can dominate
the entire network. Let xi= 1 (xi= 0) represent that
host viis (is not) chosen as a BH. The objective is to
minimizeP16i6nxi. On the other hand, the strategy
of maximal number of neighbors aims to select BHs whose total number of neighbors is maximal.
The objective is to maximize P16i6nnixi, where ni
is the number of neighbors of host vi. The two
resulting 0/1 ILPs can be solved, similar to the 0/1 ILP for OGHAM. During their execution of the rounding algorithm, r is relaxed to 2r.
To evaluate the qualities of multicast services, simulations are performed regarding the sion latency from the server to clients, the transmis-sion time between two neighboring hosts, and the number of lost packets. These simulations are car-ried out based on the infrastructures established by the three 0/1 ILPs mentioned above. Six
multi-cast groups, denoted by G1, G2, . . . , G6, are
ran-domly chosen from 200 hosts. Each group consists of one server and six clients. Each server sends a data packet to its clients every 4 s. The simulations proceed for 1800 s. The servers are scheduled to
start data traffics every 300 s. That is, G1starts at
the first, G2starts after 300 s, G3starts after 600 s,
and so on. Simulation results are collected from
G1for every interval of 300 s.
Simulation results are exhibited inFigs. 4–6. Two
kinds of latency are calculated and compared for
delivering each data packet inFigs. 4 and 5.
Trans-mission latency inFig. 4indicates the elapsed time
to send a packet from the server to a client along
the multicast route; transmission time inFig. 5
indi-cates the elapsed time to transmit a packet between
two neighboring hosts. Figs. 4 and 5 reveal that
when the number of multicast groups increases, Table 1
Comparison of OGHAM with MCEDAR and ADB
OGHAM MCEDAR ADB
Infrastructures Strategies to select BHs Minimal number of hops Maximal number of neighbors
Maximal number of neighbors and low link failure frequency Control messages Transmitted by multicast
members and the attached BHs on-demand
Transmitted by each host periodically
Transmitted by each host periodically
Multicast routes From a BH to the attached members
Tree Tree Tree
From a BH to the other BHs
OGHAM has less transmission latency and trans-mission time than the other two strategies. OG-HAM has less transmission latency because its objective of selecting BHs is to minimize the total number of hops to all hosts. On the other hand, since the BHs selected by the other two strategies have more neighbors, they consume more time in contending radio channels with their neighbors. This explains why OGHAM also has less transmis-sion time.
Fig. 6 shows the numbers of lost data packets. OGHAM and the strategy of minimum dominating set have fewer lost data packets than the strategy of maximal number of neighbors. Since the latter strat-egy is to maximize the number of neighbors, the selected BHs have higher probabilities of collision during packet transmission.
To sum up, our simulations show that the BH selection strategy adopted in OGHAM is superior to the other two strategies in transmission latency, transmission time and lost data packets. In other words, OGHAM has a more effective traffic distri-bution than the other two strategies.
5.2. Comparisons of two-tier multicast protocols One or two multicast groups are randomly chosen from 200 hosts; each consists of one server and seven clients. The simulation proceeds for 300 s and the average speed for host movement
var-ies from 0 to 30 m/s. Table 2summarizes the
para-meters and their assigned values for OGHAM, MCEDAR and ADB. The assigned values for MCEDAR and ADB are the same as those assigned in [8,11], respectively.
In order to investigate the effectiveness, attach-ment stability and receiving data packet ratios of OGHAM, MCEDAR and ADB, six metrics are adopted. They include (1) the number of control packets, (2) the number of data packets transmitted by servers or forwarders, (3) transmission time between two neighboring hosts, (4) transmission latency from servers to clients, (5) the number of messages init_group and join_request (introduced in Appendix B), and (6) the ratio of receiving data packets (i.e., the ratio of the number of data packets received by clients to the number of data packets delivered from servers). Since init_group and join_ request are issued when multicast members are attached to BHs or re-attached to new BHs, metric (5) can measure the attachment stability of multicast members to BHs. In the simulation, all three
proto-0 300 600 900 1200 1500 1800 5 10 15 20 25 30 35
Elapsed time (sec)
Transmission time between neighboring hosts (msec)
Minimum dominating set Maximal number of neighbors OGHAM
Fig. 5. Transmission time between two neighboring hosts.
0-300 300-600 600-900 900-1200 1200-1500 1500-1800 0 20 40 60 80 100 120 140 160 180 200
Elapsed time (sec)
N u mb er of lo s t d a ta pa c k e ts
Minimum dominating set Maximal number of neighbors OGHAM
Fig. 6. Numbers of lost data packets.
0 200 400 600 800 1000 1200 1400 1600 1800 30 40 50 60 70 80 90 100 110 120
Transmission latency from servers to clients (msec)
Minimum dominating set Maximal number of neighbors OGHAM
Elapsed time (sec)
cols have the same number of data packets delivered from servers.
We use a simplified instance to illustrate metrics (2) and (6). Consider a multicast group that consists
of the server s and two clients c1, c2. Assume that the
multicast routes are s–f1–f2–c1and s–f1–c2, where f1
and f2are forwarders. For each data packet
deliv-ered from s, three broadcasts (by s, f1 and f2) will
be induced, i.e., three data packets will be generated. If there are five data packets delivered from s, then
there are 3· 5 = 15 (the value of metric (2)) data
packets generated in the entire network. Further, if four and five data packets are received finally by
c1 and c2, respectively, then the ratio of receiving
data packets is counted as (4/5 + 5/5)/2 = 90% (the value of metric (6)).
The effectiveness of OGHAM, MCEDAR and
ADB is investigated by metrics (1)–(4). Figs. 7 and
8 show the numbers of control packets and data
packets, respectively, generated in the network.
The data packets counted in Fig. 8 are restricted
to those transmitted by servers or forwarders. In MCEDAR and ADB, all hosts periodically transmit control packets for constructing and maintaining the two-tier infrastructure. In OGHAM, only the multicast members and the attached BHs are required to transmit control packets on-demand. Hence, OGHAM generates fewer control packets. On the other hand, OGHAM also generates fewer data packets, because it selects BHs with the objec-tive of minimizing the total number of hops to all hosts. The objective can result in shorter multicast routes. ADB generates more data packets than MCEDAR because it uses a flooding mechanism to disseminate data packets over the network of BHs.
Fig. 9shows the transmission time consumed by transmitting a packet between two neighboring hosts. Since MCEDAR and ADB select BHs with a maximal number of neighbors, they spend more transmission time than OGHAM. Also, ADB spends more transmission time than MCEDAR, as a consequence that it generates more data packets Table 2
Parameters and their assigned values
Parameters Meanings Values
OGHAM MCEDAR ADB
r Maximal number of hops from an NBH to the attached BH 3 1 3
c Radius (number of hops) of multicast regions 7
maxhopcount Maximal number of hops for a flooding 20 20 20
a Number of successively lost data packets 3
period Period for each host to broadcast a control packet to its neighbors 1.5 s 1.5 s
R Robustness factor 2
Nlff Time window for computing normalized link failure frequency 3 s
a Smoothing factor 0.6 0 5 10 15 20 25 30 0 1 2 3 4 5 6 7 8 9 10 11x 10 4 Speed (m/sec) N u mb er of c o nt ro l p a c k et s MCEDAR:one group MCEDAR:two groups ADB:one group ADB:two groups OGHAM:one group OGHAM:two groups
Fig. 7. Numbers of control packets.
0 5 10 15 20 25 30 0 2000 4000 6000 8000 10000 12000 14000 16000 Speed (m/sec) N u mb er of d a ta p a c k e ts MCEDAR:one group MCEDAR:two groups ADB:one group ADB:two groups OGHAM:one group OGHAM:two groups
than MCEDAR. Fig. 10 shows the transmission latency induced by transmitting data packets from servers to clients. OGHAM has less transmission latency than MCEDAR and ADB, which is an immediate consequence of shorter multicast routes and less transmission time.
A highly mobile environment will result in a high frequency of BH re-selection, multicast member re-attachment, and multicast route re-construction. Since MCEDAR and ADB select BHs with the strategy of maximal number of neighbors, the neighborhoods of the selected BHs are inclined to
change as hosts move. Fig. 11 shows that
MCE-DAR and ADB have higher frequency of re-attach-ment than OGHAM by counting the numbers of messages init_group and join_request.
Fig. 12shows the ratios of receiving data packets. When the host speed is low, OGHAM has higher
ra-tios than MCEDAR and ADB. The reason is that OGHAM has better effectiveness (fewer packets, shorter transmission time and transmission latency) and more stable attachment. When the host speed increases, the ratios for all three protocols decline, but OGHAM and ADB are superior to MCEDAR. Both OGHAM and ADB have comparable ratios, even though ADB employs a flooding mechanism to disseminate data packets. Flooding of data pack-ets will incur extra overheads and decline the perfor-mance and throughput of the entire network. 5.3. Performance of OGHAM versus group size, group number and r
Since control packets are generated for con-structing and maintaining two-tier infrastructures,
0 5 10 15 20 25 30 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 MCEDAR:one group MCEDAR:two groups ADB:one group ADB:two groups OGHAM:one group OGHAM:two groups Speed (m/sec) T ra n s m is s ion l a tency f rom s e rv e rs t o c lie n ts (sec )
Fig. 10. Transmission latency from servers to clients.
0 5 10 15 20 25 30 0 100 200 300 400 500 600 700 800 900 MCEDAR:one group MCEDAR:two groups ADB:one group ADB:two groups OGHAM:one group OGHAM:two groups Speed (m/sec) Numb er of th e me s s a g e s i n it _ _gr o up an d jo in _ _ re q u e s t
Fig. 11. Numbers of messages init_group and join_request.
0 5 10 15 20 25 30 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 MCEDAR:one group MCEDAR:two groups ADB:one group ADB:two groups OGHAM:one group OGHAM:two groups Speed (m/sec) R a ti o of re c e iv in g da ta p a c k et s
Fig. 12. Ratios of receiving data packets.
0 5 10 15 20 25 30 0.01 0.015 0.02 0.025 0.03 0.035 0.04 MCEDAR:one group MCEDAR:two groups ADB:one group ADB:two groups OGHAM:one group OGHAM:two groups Speed (m/sec) T ran s m is s io n ti me bet w e en n e ig hb or in g h o s ts ( s ec )
they can be used as a measure for the effectiveness of a multicast protocol. An ineffective multicast protocol will generate a large number of control
packets. In the simulations ofFigs. 13 and 14,
OG-HAM reconstructs the infrastructure whenever 1000 data packets are delivered from a server to its clients.
Fig. 13 shows the ratios of control packets for different group sizes and different group numbers, which are computed as the number of control pack-ets divided by the total number of control packpack-ets and data packets. In OGHAM, since the BHs se-lected for a multicast group are globally available, it is not necessary for follow-up multicast groups to construct additional infrastructures. Hence, as
group size or group number increases, the ratio of control packets declines.
Fig. 14 shows the numbers of control packets
generated by OGHAM for different group numbers and different values of r. Each multicast group con-sists of one server and six clients. It is observed that OGHAM generates fewer control packets when r increases. The reason is that when the value of r gets greater, OGHAM will select fewer BHs, which causes fewer control packets generated for main-taining the infrastructure.
6. Conclusion
In order to obtain shorter multicasting routes, we have introduced a new strategy for selecting BHs whose objective is to minimize the total number of hops to all hosts. A multicast protocol named OG-HAM is proposed to construct a two-tier infrastruc-ture and determine multicast routes. OGHAM has the following advantages over previous two-tier multicast protocols (MCEDAR and ADB).
As a consequence of our strategy of select-ing BHs, OGHAM has shorter multicast routes and more stable attachments from multicast mem-bers to BHs than MCEDAR and ADB. Stable attachments can reduce the frequencies of BH re-selection, multicast member re-attachment, and multicast route re-determination. Also, the problem of traffic concentrations and network bottlenecks in OGHAM is less serious than in MCEDAR and ADB. On the other hand, compared with MCE-DAR and ADB in which all hosts need to broad-cast control packets periodically for maintaining the infrastructure, OGHAM asks only members of the multicast groups to construct the infrastruc-ture on-demand. Hence, OGHAM incurs fewer overheads for constructing and maintaining the infrastructure.
The problem of selecting BHs can be formulated as a 0/1 ILP, which is an NP-hard problem. In order to find a feasible solution to the 0/1 ILP, an approx-imation algorithm whose approxapprox-imation ratio is
bounded above by 1þmaxfwij16i6ng
S is proposed. This
guarantees a limited difference between the obtained feasible solution and the optimal solution. Further,
since the fractionmaxfwij16i6ng
S is very small in most
in-stances, the obtained feasible solution is very close to the optimal solution. Therefore, the multicast routes determined by OGHAM are shorter than those determined by the other two-tier multicast
4 6 8 10 12 14 16 2 4 6 8 10 12 14 16x 10 -3 Group size Rati o o f c o n tr o l p a c k e ts Group number = 1 Group number = 2 Group number = 3 Group number = 4
Fig. 13. Ratios of control packets for OGHAM.
2 4 6 8 10 12 14 16 18 20 0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 Numb er of c o nt ro l pa c k e ts Group number r=2 r=3 r=4 r=5
protocols, which was also verified by our simula-tions.
Acknowledgements
This work was supported by the MediaTek Inc. under the project ‘‘Wireless Communication Sys-tems’’. This work was also supported by National Science Council of Taiwan under the NSC93-2524-S-008-002 Project.
Appendix A. Selecting BHs
We use Rito denote a multicast region associated
with a host vi, which is a region with a radius of c
hops centered at vi. In other words, Ricontains all
hosts that are at most c hops distant from vi. We
assume c P 2r. Let Vi be the set of hosts that are
located in Ri. A distributed algorithm for selecting
BHs within Riis presented below.
Four variables: t, hopcount, Njand Mjare used in
the algorithm. t is the elapsed time required for transmitting a message between two neighboring
hosts. hopcount counts the number of hops to vi.
Nj is a set containing all neighbors of vj. Mj is a
set containing some Nks (explained later). Initially,
we set Mj= {Nj}. Two messages: init and echo are
transmitted over the network. init, which carries
hopcount, is initiated by vi and propagated over Ri.
Upon receiving an init from a host, say va, a host
vjrelays it to its neighbors and then waits for a time
period to receive echos from its neighbors. If
time-out occurs, vj replies an echo to va. Mj is carried
by echo. Upon receiving an echo from a host, say
vb, a host vj augments Mj with Mb. A message is
redundant to a host if the host received the same message before.
The execution of the algorithm is described as follows:
1. viperforms the following.
1.1. Set hopcount = 0.
1.2. Transmit init(hopcount) to all its neighbors. 1.3. Wait echo messages from the neighbors for a
time period of 2(c 1) · t.
2. Upon receiving a nonredundant init(hopcount)
from a host, say va, a host vj(5vi) performs the
following.
2.1. Set Mj= {Nj}.
2.2. If hopcount < c 1, perform the following.
2.2.1. Set hopcount = hopcount + 1.
2.2.2. Transmit init(hopcount) to all its
neighbors.
2.2.3. Wait echo messages from the
neigh-bors for a time period of 2(c 1
hopcount)· t.
2.3. If hopcount = c 1, reply echo(Mj) to va.
3. Upon receiving echo(Mb) from one, say vb, of the
neighbors, a host vj(5vi) performs the following.
3.1. Set Mj= Mj[ Mb.
If timeout occurs at step 2.2.3, vjreplies echo(Mj)
to va. If timeout occurs at step 1.3, the algorithm
ter-minates and Vi can be determined from Mi as
follows: Vi= {vkj vk2 Nj and Nj2 Mi}. Without
loss of generality, suppose Vi= {v1, v2, . . . , vh}. An
adjacency 0/1 matrix for the hosts of Vi can be
obtained from Miso that a 1 (0) in the (x, y) entry
denotes that vx and vyare (are not) two
neighbor-ing hosts, where 1 6 x 6 h and 1 6 y 6 h. With
this matrix, all dx,yÕs can be computed by the
DijkstraÕs algorithm [15]. The hosts in Vi are then
classified into two categories: BHs and NBHs by
the method of Section 2. Let Bi be the set of
all BHs in Vi. Each host in Vican determine which
category it belongs to and compute shortest routes
to the other hosts in Vi if vibroadcasts Biand Mi
over Ri.
Let n be the number of hosts within Riand l be
the number of hosts that are c hops distant from
vi. There are n l messages init generated at steps
1 and 2, and there are n 1 messages echo
gener-ated at step 3. Hence, the distributed algorithm
generates 2n l 1 messages. On the other hand,
the distributed algorithm terminates at step 1.3,
and so it takes 2(c 1) · t time.
Appendix B. Determining multicast routes
We let vsbe the server and vcbe any client. First,
vs and vc are attached to two BHs, say vp and vq,
respectively. If vs is a BH, then vp= vs. If vs is an
NBH, then vpis the closest BH to vs. If there exists
a BH whose distance to vsis within 2r hops (vsis
nei-ther a BH nor an NBH), then vpis the BH.
Other-wise, Bs is determined and vpis the closest BH to
vs which can be determined by the aid of Bs and
Ms. vq can be determined similarly. We assume
vq2 Bwfor some 1 6 w 6 n.
In OGHAM, vp(vq) acts like a proxy for vs (vc).
All messages that are initiated from or destined
for vs (vc) have to be processed by vp(vq). When vc
request to vq which is responsible for forwarding
the request to vp. Upon receiving the request, vp
replies to vqand sends the request to vs. The route
from vcto vshas to be kept. A distributed algorithm
for constructing a multicast group is presented below.
We use ps,pto represent a route from vsto vp. pp,s,
pp,q, pq,p, pq,r and pr,q all have similar meanings.
These routes can be obtained by the DijkstraÕs algo-rithm and they are included as parts of messages. Four messages: init_group, echo_group, join_request and join_echo are transmitted for group
initializa-tion. init_group and echo_group are between vsand
vp, while join_request and join_echo are between vc
and vq. Another four messages: join_request, join_
echo, join_ack and join_nack are transmitted for
joining vc to the group. They are all between vc
and vq.
Two messages: query_server and query_ack are
transmitted between vp and vq for vq to query the
location of the server. query_server also informs
the server that vcis one of the clients. There is a
cli-ent list, denoted by Lc, kept in the server that stores
all the clients. Initially, Lcis empty. In case vs (vc)
fails to connect with vp(vq), two messages:
init_reat-tach and echo_reatinit_reat-tach are transmitted to reatinit_reat-tach vs
(vc) to a new BH. Message flows for determining
multicast routes are shown inFig. 15, where vp2 Bw
is assumed. The execution of the algorithm is described as follows:
4. vs performs the following for group
initialization.
4.1. Set Lcempty.
4.2. Transmit init_group(ps,p) to vp.
4.3. Wait an echo_group message from vp for a
time period of 4r· t.
5. Upon receiving init_group(ps,p), vpperforms the
following.
5.1. Transmit echo_group(pp,s) to vs.
6. Upon receiving echo_group(pp,s), vsperforms the
following.
6.1. vsfinishes the group initialization.
7. vc performs the following for group
initialization.
7.1. Transmit join_request(pc,q) to vq.
7.2. Wait a join_echo message from vqfor a time
period of 4r· t.
8. Upon receiving join_request(pc,q), vq performs
the following.
8.1. Set waiting_time = 2· max{dq,kj for all
vk2 Bw}· t.
8.2. Transmit join_echo(pq,c, waiting_time) to vc.
8.3. Transmit query_server(vc, pq,k) to all
vk2 Bw.
8.4. Wait a query_ack message from vp for a
time period of waiting_time.
9. Upon receiving join_echo(pq,c, waiting_time), vc
performs the following.
9.1. Wait a join_ack or join_nack message from
vqfor a time period of 2r· t plus waiting_
time.
10. Upon receiving query_server(vc, pq,p), vp
per-forms the following.
10.1. Transmit query_server(vc, pp,s) to vs.
10.2. Transmit query_ack(pq,p) to vq.
11. Upon receiving query_server(vc, pq,k), vk
(62{vp, vs}) performs the following.
11.1. Discard the message.
12. Upon receiving query_server(vc, pp,s), vs
per-forms the following.
12.1. Add vcto Lc.
13. Upon receiving query_ack(pq,p), vqperforms the
following.
13.1. Transmit join_ack(pq,c) to vc.
14. Upon receiving join_ack(pq,c), vc performs the
following.
14.1. vcfinishes the group initialization.
15. Upon receiving join_nack(pq,c), vcperforms the
following.
15.1.Wait a join_ack or join_nack message from
vq.
/* A join_nack message from vqmeans that vp
cannot be found in Bw. In this case, another
algorithm is invoked to locate vp. The
algo-rithm will be presented in Appendix C*/.
vs vp vc vq init_group(ps,p) join_request(pc,q) join_echo(pq,c) query_server(vc, pq,p) vk query_server(vc, pq,k) Bw query_server(vc, pp,s) echo_group(pp,s) query_ack(pp,q) join_ack(pq,c) join_nack(pq,c)
16. Upon receiving any message above, a host
(62{vs, vc, vp, vq}) forwards it to the next host
according to the carried path.
If timeout occurs at step 4.3, vs transmits an
init_reattach message to all hosts that are at most
2r hops distant from vs. Upon receiving an
init_reat-tach, a BH replies an echo_ reattach. After receiving
replies from BHs, vsselects the closest one as new vp
and is re-attached to it (i.e., perform steps 4.2 and
4.3). In case vsdoes not receive any echo_ reattach,
it constructs Rs and then selects new vp from Bs.
If timeout occurs at steps 7.2 or 9.1, vc does
similarly.
If timeout occurs at step 8.4, vqtransmits a join_
nack message to inform vcthat vpcannot be found in
Bw. Besides, vq invokes a distributed algorithm to
locate vp, as detailed in Appendix C. After vs
receives an echo_group message from vp (step 6)
and every vc receives a join_ack message from vq
(step 14), the algorithm terminates and a path from
vs to vcis established.
The distributed algorithm mainly accomplishes
two tasks: one is to attach vsto vpwhen vsattempts
to create a multicast group (refer to steps 4–6 and
16), and the other is to attach vcto vqand establish
a path from vsto vcwhen vcattempts to join a
mul-ticast group (refer to steps 7–16). At most 4r
mes-sages and at most 8rþPvk2Bwdq;kþ dq;pþ msgC
messages are generated for the first and second
tasks, respectively, where msgC is the number of
messages generated for the distributed algorithm
of Appendix C. Also, 4r· t time and at most
6r· t + 2 · max{dq,kj for all vk2 Bw}· t + timeC
time are required for the two tasks, respectively,
where timeCis the time required for the distributed
algorithm ofAppendix C.
Appendix C. Merging multicast regions
In case vqcannot find vpin Bw, vqstarts a merging
algorithm to locate vpby searching a region with a
radius of maxhopcount hops centered at vq, where
maxhopcount > c is a constant. Two messages: global_query and global_ack are transmitted over the region. global_query, which carries hopcount,
vc, Bwand Mw, is initiated by vq. Upon receiving a
nonredundant global_ query, a host vj (62{vp, vq})
relays it to its neighbors. When vpreceives a global_
query, it transmits a global_ack to vq. The global_
ack carries pp,q, Bz and Mz, where vp2 Bz is
as-sumed. The execution of the algorithm is described as follows:
17. vqperforms the following.
17.1. Set hopcount = 0.
17.2. Transmit global_query(hopcount, vc, Bw, Mw)
to all its neighbors.
17.3. Wait a global_ack message for a time
per-iod of 2 maxhopcount· t.
18. Upon receiving a nonredundant global_
query(hopcount, vc, Bw, Mw), a host vj (62{vp, vq})
performs the following.
18.1. If hopcount < maxhopcount, perform the following.
18.1.1. Set hopcount = hopcount + 1.
18.1.2. Transmit global_query(hopcount, vc,
Bw, Mw) to all its neighbors.
18.2. If hopcount = maxhopcount, perform the following.
18.2.1. Discard the message.
19. Upon receiving global_query(hopcount, vc, Bw,
Mw), vpperforms the following.
19.1. Transmit global_ack(pp,q, Bz, Mz) to vq.
19.2. Transmit query_server(vc, pp,s) to vs.
20. Upon receiving global_ack(pp,q, Bz, Mz), a host vj
(62{vp, vq}) forwards it to the next host according
to pp,q.
21. Upon receiving global_ack(pp,q, Bz, Mz), vq
per-forms the following.
21.1. Transmit join_ack(pq,c) to vc.
A timeout at step 17.3 means that vpcannot be
found in the region. On the other hand, if vqreceives
global_ack(pp,q, Bz, Mz), then vp2 Bz is found. For
either case, vqreplies to vcand the algorithm
termi-nates. A join_ack message received at step 15.1,
which comes from step 21.1, implies that vcwas
suc-cessfully added to Lc(at step 12.1). A join_nack
mes-sage received at step 15.1 is a consequence of step 17.3. The waiting time at step 15.1 is set to
(2max-hopcount + r)· t. In case vp2 Bz (z 5 w), Rz and
Rw are merged (Bzand Bware merged and Mzand
Mware merged therefore) into a larger multicast
re-gion. For any follow-up multicast group in which
the server is located in Rwand the clients are located
in Rz, a flooding to locate vpis no longer necessary.
Let m be the number of hosts within a region
with a radius of maxhopcount hops centered at vq.
The distributed algorithm generates at most
m + maxhopcount messages and takes
References
[1] M.S. Corson, S.G. Batsell, A reservation-based multicast (RBM) routing protocol for mobile networks_initial route construction phase, ACM/Baltzer Wireless Networks 1 (4) (1995) 427–450.
[2] E.M. Belding-Royer, C.E. Perkins, Transmission range effects on AODV multicast communication, ACM/Kluwer Mobile Networks and Applications 7 (2002) 455–470. [3] J. Xie, R.R. Talpade, A. Mcauley, M. Liu, AMRoute: adhoc
multicast routing protocol, ACM/Kluwer Mobile Networks and Applications 7 (2002) 429–439.
[4] S.K.S. Gupta, P.K. Srimani, Cored-based tree with forward-ing regions (CBT-FR), a protocol for reliable multicastforward-ing in mobile ad hoc networks, Journal of Parallel and Distributed Computing 61 (9) (2001) 1249–1277.
[5] S.J. Lee, M. Gerla, On-demand multicast routing protocol in multihop wireless mobile networks, ACM/Kluwer Mobile Networks and Applications 7 (2002) 441–453.
[6] J.J. Garcia-Luna-Aceves, E.L. Madruga, The core-assisted mesh protocol, IEEE Journal on Selected Areas in Commu-nications 17 (1999) 1380–1394.
[7] R. Sivakumar, B. Das, V. Bharghavan, Spine routing in ad-hoc networks, Cluster Computing 1 (2) (1998) 237–248, a special issue on mobile computing.
[8] P. Sinha, R. Sivakumar, V. Bhanghavan, CEDAR: a core-extraction distributed ad-hoc routing algorithm, IEEE Journal on Selected Areas in Communications 17 (1999) 1454–1465.
[9] U.C. Kozat, G. Kondylis, B. Ryu, M.K. Marina, Virtual dynamic backbone for mobile ad-hoc networks, Proceedings of the IEEE International Conference on Communications 1 (2001) 250–255.
[10] P. Sinha, R. Sivakumar, V. Bhanghavan, MCEDAR: multicast core-extraction distributed ad-hoc routing, Pro-ceedings of the IEEE Wireless Communications and Net-working Conference (1999) 1313–1317.
[11] C. Jaikaeo, C.C. Shen, Adaptive backbone-based multi-cast for ad hoc networks, Proceedings of the IEEE International Conference on Communications 5 (2002) 3149–3155.
[12] A. Meyerson, Profit-earning facility location, in: Proceedings of the 33th Annual ACM Symposium on Theory of Computing, 2001, pp. 30–36.
[13] V.V. Vazirani, Approximation Algorithms, Springer-Verlag, Berlin Heidelberg, 2001.
[14] Network Simulator (Version 2). Available from: <http:// www-mash.cs.berkeley.edu/ns/>.
[15] E.W. Dijkstra, A note on two problems in connection with graphs, Numerische Mathematik (1959) 269–271.
Chia-Cheng Hu received the B.S. degree from Chinese Naval Academy in 1988, and the M.S. degrees in Engineer Science from National Cheng Kung University in 1995, respectively. He is currently a Ph.D. candidate in Department of Computer Science and Information Engineering, National Taiwan Univer-sity, Taiwan. His research interests include Wireless Networks, Mobile
Computing and Combinatorial
Optimization.
Eric Hsiao-Kuang Wu received his B.S. degree in Computer Science and Infor-mation Engineering from National Tai-wan University in 1989. He received his Master and Ph.D. in Computer Science from University of California, Los Angeles (UCLA) in 1993 and 1997. He is an Associate Professor of Computer Science and Information Engineering at National Central University, Taiwan. His primary research interests include Wireless Networks, Mobile Computing and Broadband Net-works. He is a member of IICM (Institute of Information and Computing Machinery) and IEEE.
Gen-Huey Chen was born in Taiwan in 1959. He received the B.S. degree in Computer Science from National Tai-wan University in June 1981, and the M.S. and Ph.D. degrees in Computer Science from National Tsing Hua Uni-versity, Taiwan, in June 1983 and Janu-ary 1987, respectively. He joined the Faculty of the Department of Computer Science and Information Engineering, National Taiwan University, in Febru-ary 1987, and he has been a Professor since August 1992. He received the Distinguished Research Award from the National Science Council, Taiwan in 1993, 1995, 1997, and 1999. His current research interests include graph theory and combinatorial optimization, graph-theoretic interconnection networks, wireless communication, parallel and distributed computing, and design and analysis of algorithms.
