Hierarchical Home Agent Architecture for Mobile IP Communications

Imed Romdhani(1), Jose Munoz(1), Hatem Bettahar(2), Abdelmadjid Bouabdallah(2)

Napier University (1)

School of Computing
10 Colinton Road
Edinburgh, EH10 5DT
UK
(+44) 0131 455 2726
{I.Romdhani, J.Munoz}@napier.ac.uk

Université de Technologie de Compiègne (2)

HeuDiaSyc, CNRS UMR 6599
BP 20529 - 60205 Compiègne Cedex. France.
(+33) 03 44 23 44 23
{bettahar, bouabdal}@utc.fr

Abstract mobile node (MN) and its correspondent node (CN),

While the Mobile IP protocol does not exclude the use
of multiple Home Agents (HAs), it does not impose any
particular model either. Recent solutions propose that
a mobile node uses multiple HAs located in different
physical links in his home network. However, no
architectural scheme is proposed either for unicast or
multicast communications. In this paper, we propose a
Hierarchical Home Agent architecture in which each
Home Agent (HA) is assigned a specific topological
level in its domain. The mobile node is notified about
such hierarchy and chooses the closest HA on a per-
connection basis. Our primary goal is to optimise both
unicast and multicast routing for mobile nodes. We
prove that our solution avoids redundant multicast
traffic in the home domain and it is easy to implement
using the current Mobile IP specification without extra
cost.
1. Introduction
IP mobility allows mobile hosts to continue
receiving services while moving amongst different IP
networks. While moving, IP address changes are kept
transparent to the higher layers in order to avoid their
possible temporal disconnection. Thus, to guarantee the
transparency of the handover, the IP routes between a
which is the mobile host’s communication endpoint,
should be updated to reflect the current location of the
MN. This requires special routes between MN and its
CN as the MN’s Home Address (HoA) can no longer
be used with the conventional IP routing protocols to
deliver packets to the MN’s current location. This is
because the HoA is topologically incorrect and cannot
be used in foreign networks due to ingress filtering
restrictions. For a highly-dynamic MN, the special
route should be updated regularly, such by the MN
itself, or by a third party. Depending on the location
update and notification mechanisms, different mobility
management schemes were proposed by the Internet
community to support unicast communication. Some
schemes were designated to handle IP mobility of
IPv4-based mobile host [1], where others were
developed for IPv6 [2].
While the Mobile IP protocols do not exclude the use
of multiple Home Agents (HA), they do not impose any
particular model either. Recent solutions have proposed
that a mobile node uses multiple HAs located in
different physical links. These solutions have been
designed to solve different problems, such as: binding
update load balancing between HAs [9] [14] [18]; fault
tolerance [6] [10] [11]; or unicast route optimisation
between a CN and an MN [9][10][12]. These solutions

Proceedings of the 11th IEEE Symposium on Computers and Communications (ISCC'06)

0-7695-2588-1/06 $20.00 © 2006 IEEE
 suffer from different issues. First, they are network-
initiated, i.e. it is the network the one that decides,
transparently, to redirect the unicast route from a CN to
a new instance of an HA, that is different from the
primary HA. Second, these solutions are designed to
handle unicast communication between an MN and a
CN and they do not address the issues of multicast
communications such as: multicast route optimisation
inside the home domain; membership load balancing
between different HAs; and efficient IGMP/MLD
membership delivery to MNs. Finally, the proposed
solutions lack from an efficient implementation scheme
and require extra cost to modify current Mobile IP
protocols since the majority of them introduce new
architectural entities. For all these reasons, we propose
a new hierarchical architecture for both unicast and
multicast Mobile IP communications. Our architecture
is composed of a set of distributed HAs inside the
home domain and the selection of an HA is MN-
initiated and on per-connection basis (unicast or
multicast).
In this paper, we present the problem statement and the
related works in Section 2. In Section 3, we detail our
solution and we describe its implementation. We
conclude by highlighting the advantages of our solution
and its limits.
2. Related Work
The IETF has proposed the Mobile IP protocol to
allow a mobile node to change its points of attachment
to the network without losing IP transport layer
connectivity [1][2]. Mobile IP provides a mechanism to
a mobile node (MN) to retain one permanent IP
address, called hereinafter a Home Address (HoA),
from its home network and one temporal IP address,
called hereinafter a Care-of Address (CoA), from a
foreign network. The HoA does not depend on a
connection place to the Internet, whereas the CoA
depends on the connection place. To register its CoA
address, an MN sends a registration request message to
its HA. This message is used to create a binding
association between the MN’s HoA and the MN’s CoA
for a given lifetime. The HA acknowledges the
registration request by sending a registration reply
message. As soon as the HA is notified about the MN’s
CoA, it maintains a binding cache entry that binds both
the HoA and the CoA. Thus, when a CN sends data
packets to the MN’s HoA, the HA intercepts them and
tunnels them to the MN’s CoA. Such procedure of
forwarding suffers from triangle routing via the home
network. The triangle routing also called “dog-leg
Proceedings of the 11th IEEE Symposium on Computers and Communications (ISCC'06)
0-7695-2588-1/06 $20.00 © 2006 IEEE
routing” may have an undesirable effect on time
sensitive applications. Moreover, congestion is likely to
arise in the home network and the HA will be the
bottleneck point of such congestion.
Compared to the Mobile IP specification, recent
researches have proposed to use multiple HAs where
the HAs are placed in different physical links in the
home network. To have multiple HAs, two approaches
may be used: replication where the HAs are replicated
and each HA maintains the same binding information
of all MNs as other HAs and partition where HAs are
partitioned, and each HA maintains information for a
subset of MNs. These multiple HAs approaches aim to
solve different issues, such as: caching and traffic load
balancing; fault tolerance and reliability; and route
optimisation for unicast communications.
2.1 Caching and load balancing
Caching and load balancing consists of redirecting
packet from a busy HA to a vacant one. In fact, authors
in [14] have proposed a dynamic threshold load-
balancing policy, in order to improve the system
performance of the Mobile IPv4 protocol. Using a
double-threshold approach, they have defined upper
and lower thresholds to be used by HAs where an HA
is said to be “vacant” if its queue length falls below the
lower threshold, and “full” if it exceeds the upper
threshold. Each HA then advertises its queue
information each time the queue length moves over, or
below the threshold. When the queue length exceeds
the threshold, an HA attempts to transfer one
correspondent node (source) to another HA. Each time
a transfer is made, a packet timer is set. When this
timer expires, the queue status is re-evaluated and the
process is renewed. To define the accepted threshold,
the authors in [7] have suggested using a new load-
balancing information option in which each HA
regularly advertises the number of available MN
number that it is able to accept, and propose to
implement this option in the IPv6 router advertisement
message sent by the HA. To enhance these methods
and instead of using HA queue status and a fixed
number of MNs, the authors in [15] have proposed a
policy to distribute the load amongst multiple HAs in
the Mobile IPv4 protocol. Compared to the previous
approach, incoming unicast packets are transferred
from one HA to another based on a Stream Transfer
Time (Tstt). Then, initially, the MN chooses one of the
HAs to register with it. Each HA then maintains a Tstt
timer for the MN. When this timer expires, the HA with
which the MH is registered, chooses another HA to
serve the MN. The Tstt counter only begins to
 decrement once packets start arriving to MN from the
new HA. The authors have also proposed to use a
packet counter as an alternative to the Tstt timer.
2.2 Fault tolerance
If the primary HA fails, the mobility binding cache will
be lost and all MNs registered with the HA will lose
connectivity unless a redundancy mechanism is
employed. Thus, authors in [17] developed the “Mobile
IP Home Agent Redundancy” feature, which has two
types of HA are designed: one active HA and another
HA as a standby HA. These HAs then exchange
mobility binding updates, and on a failure, the backup
HA (standby HA) starts to serve MNs. Following the
same concept, authors in [18] proposed a multiple HAs
protocol extension called “Home Agent Redundancy
Protocol” (HARP). Their primary concern is system
robustness and their model is designed to serve all the
MNs by varying the degree of redundancy, when one,
or even several, HAs crash. This protocol is based on
one or more HARP peers that act as a single shared
HA, where each HARP peer is configured with
information about its peers and forwards any Mobile-IP
registration messages (BU) it receives to its peers.
HARP peers thus act in parallel to create or delete
tunnels to the MN’s remote CoA according to the last
registration message received.
2.3 Route optimisation
Authors in [9] have proposed the “Inter Home Agents
Protocol” (HAHA) to provide multiple HAs support
for IPv6 mobile nodes and mobile routers. The HAHA
protocol provides HA redundancy, load balancing, and
also optimises the interception of unicast packet
addressed to MN. For this purpose, the primary HA
synchronizes its binding cache with other HAs. As a
result, any HA can earlier intercept and tunnel unicast
packets to the current location of the MN, before they
go through the primary HA. Alternatively, an HA can
tunnel the intercepted packet to the primary HA. In
addition, authors have defined a “HA Switching”
mechanism where an HA can request from an MN to
switch to another HA, whereas instead of using the HA
switching, authors in [12] proposed to use dynamic HA
reassignment in Mobile IPv4. Compared to the HAHA
protocol, the dynamic reassignment supports
simultaneous binding, inter-HAs roaming and load
balancing, except that the MN’s HoA is no longer
permanent. Thus, whenever the MN changes the HA,
the HoA changes too. This reassignment procedure
Proceedings of the 11th IEEE Symposium on Computers and Communications (ISCC'06)
0-7695-2588-1/06 $20.00 © 2006 IEEE
requires: signalling procedure between the MN; a
Mobility Agent (MA); the Foreign Agent (FA); and the
AAA server. The MA entity dynamically attributes a
new HA to the MN, whenever the handover occurs.
Similar to the dynamic reassignment, authors in [16]
have addressed the triangle routing and the prolonged
handoff latency, and have proposed a new “Temporary
Home Agent” (THA). This THA aims to intercept
packet destined for the MN in the foreign domain and
tunnelling them to it. To do so, the THA is located at
the gateway to a foreign domain, and it dynamically
allocates a temporary home address for the MN. The
MN then uses this new HoA as its source address when
initiating a connection to a CN.
Compared to the THA technique, where the selection
of the HA is done at the IP level while addressing the
routing efficiency toward the MN, authors in [8] have
proposed a new session-layer-based mobility
architecture called DHARMA, which addresses the
issues of intermittent connectivity and optimised
routing overhead from the MN to the CN. This uses an
overlay network to deploy distributed HAs and uses
different routing algorithms to select the closest HA to
the CN. This selection is done transparently on a per-
connection basis when a mobile host initiates a
connection with a correspondent node. For this
purpose, a new architectural entity called “Mobility
Agent” (MA) is introduced. The MA serves as a
mobility-aware indirection point between MN and CN
and can be co-located with an HA. It then intercepts the
connection and finds an HA candidate close to the CN.
While all the previous methods are HA-initiated,
authors in [19] have proposed an MN-initiated method,
where the MN chooses the best HA. In their solution,
each HA has an access list containing the entire foreign
agent CoAs in its region. Thus, when an MN sends a
registration message to the best HA, with respect to
geographic location, this will be accepted or denied
depending on the CoA. If the registration is
unsuccessful, the MN attempts to register with another
HA with the next highest priority. The HA priorities
are set in the configuration settings in the MN, thus this
static configuration faces serious problems when the
home network is reconfigured and the HA addresses
are changed. In addition, this method is not scalable
and requires an important network management tasks.
As described above, the majority of the solutions
introduce an extra cost to achieve their goals. In
addition, these solutions are not easy to implement and
some of them introduce new architectural entities.
Despite these solutions solve relevant issues, we
 believe that there is an urgent need for an MN-initiated
solution where the nomadic user chooses on his will the
HA to be served with. The MN can select dynamically
the appropriate HA based for example on: economic
criteria (minimum billing cost), Quality of Service
(QoS) requirements (shortest path to CN, delay, etc.) or
security consideration. Moreover, we need a scalable
architecture that covers both the advantages of using
multiple HAs and optimises both unicast and multicast
communications for mobile hosts.
3. Our solution: Hierarchical Home Agents
3.1 General idea
In order to optimise both unicast and multicast routing,
we propose a new solution that uses a topological
hierarchical-level for each Home Agent, where the
level information is a hop-distance range from the exit
router. The exit router is defined as the router from
which Internet traffic leaves the home domain. Thus
the level is higher, if the HA is closer to the exit router
(egress router) of the home domain, with respect to
hop-distance. Each HA then computes its own level
metric, and advertises it to all the other HAs in a
manner similar to the HAHA protocol [9]. To compute
its level, each HA may be statically configured to use a
default exit router or chooses it based on unicast
routing protocol information (such as OSPF or BGP
protocol).
Our solution is designed to handle all Mobile IP
protocols [1][2]. In case of Mobile IPv6 protocol, each
HA builds and maintains a Home Agents List (HAs
List) and advertises it in response to an ICMP Home
Address Discovery Request message sent by an MN
[3]. In our method, we extend the basic HAs List of the
Mobile IPv6 protocol to introduce the hierarchy level
information. As a consequence, each entry of the HAs
List contains the hierarchy-level and the list of the IP
addresses of the HAs within the hierarchy. Thus, the
HAs are ordered based on their priorities. These
priorities are set in similar manner as in both Mobile
IPv4 and Mobile IPv6 protocols.
To support IP mobile multicast, The IETF has
suggested to use two approaches: Home Subscription
(HS) and Remote Subscription (RS) [4]. To join a
multicast group using the home subscription approach,
also called bi-directional tunnelling, each mobile
multicast receiver (MN) tunnels its multicast group
membership report message (IGMP/MLDv2) [3] to its
HA. When the HA receives the tunnelled multicast
report message, it decapsulates and forwards it to the
Proceedings of the 11th IEEE Symposium on Computers and Communications (ISCC'06)
0-7695-2588-1/06 $20.00 © 2006 IEEE
multicast router on the home network. The local
multicast router (MR) intercepts this membership
request and sends accordingly a join message to the
nearest on-tree router to join the requested multicast
group and source. Once a multicast branch is
established between the MR and the multicast delivery
tree, the HA intercepts and forwards the incoming
multicast packets down the tunnel to MN.
If a mobile receiver is already a member of a given
multicast group and detects that it is moving to a new
foreign network (case of macro-mobility), it attempts to
rejoin the multicast group in order to avoid packet loss.
If the multicast join is denied in the foreign network or
the multicast scope is limited, the mobile receiver
cannot join the multicast group from the foreign
network (i.e. using the remote subscription approach).
In such situation, the home subscription approach is
mandatory to avoid multicast disruption. Therefore, we
suggest that the mobile node sends its membership
report message to the higher level HA instead of using
its primary HA. The selected HA is closer in terms of
hop distance to the boundary of the domain and it is in
the shortest possible path toward the multicast source.
Before sending its request, the mobile receiver should
compare the hierarchical-level of its primary HA with
those of the Home Agents List. Based on the scope of
the multicast traffic and the location of the multicast
source, the mobile receiver selects the appropriate HA.
When the source is located outside the home domain,
the MN chooses the higher hierarchical HA and tunnels
its multicast group membership report to it. The higher
hierarchical HA and the home domain egress router or
VPN gateway may be collocated. The higher HA
checks first if the mobile receiver is authorized to join
the requested multicast group and if it is a valid
member of the home network. A binding registration
may be required to overcome the security issues. If the
mobile receiver is authorized to get multicast traffic
from home, the HA joins the multicast delivery tree and
forwards data through the reverse tunnel to it. As figure
1 illustrates, if the MN sends its membership report to
the higher hierarchical HA (HA2) instead of sending it
to its primary HA (HA1), the multicast delivery will be
more optimal and avoids redundant multicast traffic
(native and tunnelled multicast) in all the routers
between HA2 and HA1. When the multicast source is
located outside the home domain, the multicast traffic
will travel through a shortest path from the Ingress
Router to the Egress Router before reaching MN.
In case of a unicast communication, the mobile node
can register with the appropriate hierarchical HA based
on the location of its unicast CNs. If a CN is located
 outside the home domain, the MN selects the highest
HA, otherwise it chooses a lower HA. For QoS
performance reason, a mobile receiver can trigger a
new hierarchical HA if it faces for example serious
packet loss or join delay. The mobile receiver can
choose a new HA that belongs to the same hierarchy.
Multicast Source (S)
Ingress Router
Egress Router
HA 2
Mobile Receiver
Multicast Delivery
(CoA)
Tree
HA 1
Home Domain
Native Multicast Traffic
Tunnelled Multicast Traffic
Figure 1: Triangle routing inside the home
network
3.2 Implementation detail
To support our solution, we suggest extending the
Mobile IPv6 protocol [2]. Our extension consists of
adding hierarchy level information for each HA in the
ICMP Home Address Discovery Message sent by the
mobile node. To discover the address of a suitable HA
on its home link, a mobile node uses the Home Address
Discovery mechanism. To do so, the mobile node
sends an ICMP Home Agent Address Discovery
Request message to the Mobile IPv6 HAs anycast
address for its home subnet prefix. The HA on its home
link that receives this request message replies with an
ICMP Home Agent Address Discovery Reply message.
This reply message contains the addresses and the
preferences of all the HAs operating on the home link.
The mobile node, upon receiving this reply message
updates its HAs List data structure. Then it chooses one
HA and sends its home registration Binding Update
message to it. In case of failure, the mobile node may
attempt to register with another HA from the HAs List
until its registration is accepted.
To implement our extension, we introduce a simple
modification to the ICMP Home Agent Address
Discovery Reply message by adding a new field called
“Nr of Home Agent Records”. As Figure 2 illustrates,
our new field is added in the reserved field of the
ICMP Home Agent Address Discovery Reply message.
In fact, in the ICMP Home Agent Address Discovery
Reply message, we substitute the old Home Agent
Proceedings of the 11th IEEE Symposium on Computers and Communications (ISCC'06)
0-7695-2588-1/06 $20.00 © 2006 IEEE
Address field by a new Home Agent Address Record.
The Nr of Home Agent Records field specifies how
many Home Agent Address Records are present in this
report.
Each Home Agent Address Record is a block of fields
that contain the hierarchy level and the list of HAs in
such hierarchy and it has the internal format described
by Figure 3.
Type Code Checksum
Identifier Nr of HA Records [N]
Home Agent Address Record [1]
Home Agent Address Record [2]
…
Home Agent Address Record [N]
Figure 2: ICMP Home Agent Address Discovery
Reply Message
Record Type Hierachy Level
Home Agent Address [1]
Home Agent Address [2]
…
Home Agent Address [N]
Figure 3: Home Address Record format
Our hierarchy level is used in addition to the preference
value for each HA. The preference value is taken from
the Home Agent Preference field in the Router
Advertisement message [5], if the Router Advertisement
message contains a Home Agent Information Option. In
the basic Mobile IPv6, an HA uses this preference in
ordering the Home Agents List when it sends an ICMP
Home Agent Address Discovery message, but in our
solution, the ordering will be based first on the
hierarchical-level and then on the preference value. In
other words, for each hierarchical-level, the HA list
will be ordered based on the each HA’s preference.
3.3. Advantages and limitations
The hierarchical-based Home Agent architecture has
several key features. When used in an IP multicast
context, the solution enhances the home subscription
approach of the Mobile IP protocol by reducing the bi-
 directional tunnel diameter, and relocating the tunnel
entry-point to the appropriate hierarchical HA. With
this solution, the multicast route optimisation inside the
home network is done by the Mobile IP protocol itself.
Thus, no third multicast party is required. This
solution also optimises the unicast routing, however, it
introduces an extension of the HA address discovery
mechanism and requires a signalling mechanism
between HAs, compared to that used by the HAHA
protocol. In addition, MN can choose its HA on a per
communication basis and based on its location. In case
the of a unicast communication, an MN can rely on its
primary HA, but it switches to another HA when it
joins a multicast communication. Thus, this solution is
a dynamic MN-initiated solution and does not require a
static configuration in either in MN, or in the HA.
4. Conclusion
In this paper we have proposed an efficient solution to
implement multiple Home Agents in Mobile IP
protocols. Our solution introduces hierarchy-level
information for each HA. Our solution modifies the
ICMP Home Address Discovery mechanism in the
Mobile IPv6 protocol, but avoids redundant multicast
traffic inside the home network and enhances both
unicast and multicast routing. By using different
hierarchical HAs, the mobile node differentiates
between unicast and multicast services and chooses its
HA accordingly. Our solution is a dynamic MN-
initiated approach and does not require a static
configuration either in MN or in HA.
5. References
[1] C. Perkins, “IPv4 Mobility Support”, RFC 3344, August
2002.
[2] David B. Johnson, C. Perkins and J. Arkko, “Mobility
support in IPv6”, IETF RFC 3775, June 2004.
[3] L. Vida, and L. Costa, “Multicast Listener Discovery
Version 2 (MLDv2) for IPv6”, RFC 3810, June 2004.
[4] Imed Romdhani, Mounir Kellil, Hong-Yon Lach,
Abdelmadjid Bouabdallah, and Hatem Bettahar, “IP Mobile
Multicast: Challenges and Solutions”, IEEE
Communications Surveys & Tutorials, Volume 6, No. 1,
Pages 18-41, First Quarter 2004.
[5] T. Narten, E. Nordmark, and W. Simpson, “Neighbor
Discovery for IP Version 6 (IPv6)”, RFC 2461, December
1998.
[6] JinHo Ahn, and Chong Sun Hwang, “Low-Cost Fault-
Tolerance for Mobile Nodes in Mobile IP Based Systems”,
21st International Conference on Distributed Computing
Systems Workshops (ICDCSW '01), April 16 - 19, 2001.
Proceedings of the 11th IEEE Symposium on Computers and Communications (ISCC'06)
0-7695-2588-1/06 $20.00 © 2006 IEEE
[7] Hui Deng, Brian Haley, Xiaodong Duan, Rong Zhang,
and Kai Zhang, “Load Balance for Distributed Home Agents
in Mobile IPv6”, IETF Internet Draft, draft-deng-mip6-ha-
loadbalance-02.txt, October 2004.
[8] Yun Mao, Bjorn Knutsson, Honghui Lu, and Jonathan M.
Smith, “DHARMA: Distributed Home Agent for Robust
Mobile Access”, IEEE INFOCOM 2005, Miami, Florida,
March 2005.
[9] Ryuji Wakikawa, Vijay Devarapalli, and Pascal Thubert,
“Inter Home Agents Protocol (HAHA)”, IETF Internet Draft,
draft-wakikawa-mip6-nemo-haha-01.txt, 2004.
[10] Jenn-Wei Lin, and Joseph Arul, “An Efficient Fault-
Tolerant Approach for Mobile IP in Wireless Systems”,
IEEE Transactions on Mobile Computing, pp. 207-220, Vol.
2, No. 3, 2003.
[11] JinHo Ahn, and Chong Sun Hwang, “Low-Cost Fault-
Tolerance for Mobile Nodes in Mobile IP Based Systems”,
21st International Conference on Distributed Computing
Systems Workshops (ICDCSW '01), April 16-19, 2001.
[12] Chen Y. and Boult T, “Dynamic Home Agent
Reassignment in Mobile IP”, Wireless Communications and
Networking Conference 2002 (WCNC2002), Volume: 1, 17-
21 March 2002.
[13] Qiang Gao, and Acampora A., “A virtual Home Agent
based route optimization for mobile IP”, Wireless
Communications and Networking Conference (WCNC
2000), IEEE, Volume: 2, 23-28 September 2000.
[14] A. Vasilache, J. Li, and H. Kameda, “Threshold-Based
Load Balancing for Multiple Home Agents in Mobile IP
Networks”, Telecommunications Systems, vol. 22, issue 1-4,
pp. 11-31, January-April, 2003.
[15] Jue J.P., and Ghosal D., “Design and analysis of
replicated servers to support IP-host mobility in enterprise
networks”, Communications, ICC 97 Montreal, 'Towards the
Knowledge Millennium', Volume: 3, 8-12 June 1997.
[16] Rong Zheng, Ye Ge, Hou, J.C., and Thuel S.R., “A case
for mobility support with temporary home agents”, Computer
Communications and Networks, 15-17 October 2001.
[17] Kent Leung, and Madhavi Subbarao, “Home Agent
Redundancy in Mobile IP”, IETF Internet Draft, draft-
subbarao-mobileip-redundancy-00.txt, June 2001.
[18] Bjorn Chambless and Jim Binkley, “HARP - Home
Agent Redundancy Protocol”, IETF Internet Draft, draft-
chambless-mobileip-harp-00.txt, October 27, 1997.
[19] William D. Ivancic, David Stewart, Terry L. Bell,
Phillip E. Paulsen, and Dan Shell, “Use of Mobile-IP Priority
Home Agents for Aeronautics Space Operations and Military
Applications,” IEEE Aerospace Conference 2004, Big Sky,
Montana, March 2004.
[20] J. Faizan, H. El-Rewini, and M. Khalil, “VHARP:
Virtual Home Agent Reliability Protocol for Mobile IPv6
based Networks” in Proc. IEEE Int. Conf. Wireless
Networks, Communications, and Mobile Computing, Hawaii,
June 13-16, 2005.