A network infrastructure for IP mobility support in metropolitan areas.
The original design of the Internet and its underlying protocols did not anticipate users to be mobile. With the growing interest in supporting mobile users and mobile computing, a great deal of work is taking place to solve this problem. For a solution to be practical, it has to integrate easily with existing Internet infrastructure and protocols, and offer an adequate migration path toward what might represent the ultimate solution. In that respect, the solution has to be incrementally scalable to handle a large number of mobile users and wide geographical scopes, and well performing so as to support all application requirements including voice and video communications and a wide range of mobility speeds. In this paper, we present a survey of the state-of-the-art and propose a scalable infrastructure to support mobility in Internet protocol networks. In that respect, we exploit local area network (LAN) technologies to create the network infrastructure necessary to offer connectivity to mobile users across any geographical area (building, campus and metropolis). The intrinsic properties of LAN technologies and their underlying protocols, namely flat address space, transparent learning and low complexity renders this solution particularly cost effective for supporting user mobility. In particular, we propose a network topology and a set of protocols that render the infrastructure scalable to a large geographical area and many users.
To address this issue, a proposal was introduced
in [1], known as hierarchical foreign agents
or HFA. In this proposal, hierarchical foreign
agents (HFAs) are introduced to smooth out the
process when a MH transitions between
subnets. This optimization is accomplished via
hierarchical tracking of MHs by the FAs, and via
packet bu?ering at FAs.
Within a domain, the FAs are organized into a
tree structure that handles all the hando?s in that
domain, with one FA serving as the root of the
tree. (The tree organization is unspeci?ed and left
up to the network administrator of that domain.
One popular con?guration is to have a FA associated
with the ?rewall to that domain be the root
of the tree??also known as a gateway foreign agent
or GFA??and all the other FAs provide the second
level of the hierarchy.)
A FA sends advertisements called Agent Advertisements
in order to signal its presence to the
MHs. An Agent Advertisement includes a vector
of COAs, which are the IP addresses of all its
ancestors (up to the root) as well as the IP address
of that FA. When an MH arrives at a subnet, it
records these IP addresses as its COAs. A registration
goes through and is processed by the FA,
all its ancestors and the HA. The FA processing a
registration records the next lower-level FA as the
COA to which to forward packets sent for the
MH, and the HA records the root FA for this
purpose. A registration reply goes through in the
opposite direction from the HA to the MH. When
a hando? occurs, MH compares the new vector of
COAs with the old one it had recorded previously.
It chooses the lowest-level FA that appears in both
vectors, and sends a regional registration request
to that FA, and all the lower level FAs speci?ed in
the new vector. Any higher-level agent needs not
be informed of this movement.
When a packet for the MH arrives at its home
network, the HA tunnels it to the root FA. The
root FA re-tunnels it to the lower-level FA, which
in turn re-tunnels it to the next lower level FA.
Finally, the lowest-level FA delivers it to the MH.
Mobile IP route optimization [19] extends the
use of binding cache and binding update messages
to provide smooth hando?. However, tunneled
packets that arrive at the previous FA before the
arrival of the required binding update are lost. To
address this issue, HFA includes a mechanism for
packet bu?ering at the FAs. Besides decapsulating
tunneled packets and delivering them directly to
an MH, the FA also bu?ers these packets. When it
receives a binding update with a new COA, it re-
tunnels to that COA the bu?ered packets along
with any future packets tunneled to it. Clearly,
how much packet loss can be avoided depends on
how quickly an MH ?nds a new FA, and how
many packets are bu?ered at the previous FA.
This in turn depends on how frequently FAs send
out beacons or agent advertisements, and how
long the MH stays out of range of any FA. To
reduce duplicates, the MH bu?ers the identi?ca-
tion and source address ?elds in the IP headers of
the packets it receives and includes them in the
bu?er hando? request so that the previous FA
does not need to retransmit those packets that the
MH has already received.
While HFA helps reduce the overhead of hand-
o? by handling hando? closer to the MH, it introduces
additional complexity at the MH, and in
constructing and maintaining the FA hierarchy,
and it may add latency due to the need for packet
encapsulation and decapsulation at every FA in
the FA tree along the path from the CH to the
MH. Moreover, scalability issues may arise at the
root FA and the FAs close to the root of the FA
tree because of their involvement in packet tunneling
for all the MHs of that domain. Finally,
packet bu?ering can result in latency overhead,
while encapsulation still generates bandwidth overhead

Finally, we note that Mobile IP and solutions
similar to it are popular choices employed in
products and standards aimed to o?er IP connectivity
to users around the world. In what follows,
we describe two examples, namely the Ricochet
system from Metricom [16] and universal mobile
telecommunication system (UMTS) [10].
2.1.1. Ricochet
The Ricochet system o?ered by Metricom [15]
implements a solution for IP mobility that is
somewhat similar to the Mobile IP protocol. It
was designed more than a decade ago, and thus
predates the Mobile IP protocol. Wireless cells are
connected to IP gateways and name servers that
provide security, authorization and roaming support
to users. When a user ?rst connects to the
network, it sends a request to the local gateway
and the name server. If validated and authorized,
this request allows the user to receive an IP address
to connect to the Internet. The IP address identi-
?es a permanent connection between the user and
the network and thus remains ?xed for the entire
time the user is connected to the Internet. All Internet
tra?c for the user is tunneled through the
gateway to which the user was originally con-
nected. Beside the ?xed IP address, a MH is given
two layer-2addresses: one is ?xed and unique to
that user, and the other is dynamic and unique to
the cell where a user is located at that point in
time. The gateway maps the IP address of the user
to the layer-2address corresponding to the cell
where the user is located at any point in time.
As the user crosses cells, this mapping changes to
re?ect the new location of the user. In essence, this
gateway performs the function of the HA in Mobile
IP, by maintaining an up-to-date mapping of a
?xed user address to its temporary address, and by
redirecting tra?c received for the ?xed address of
the user, to the temporary address of that user.
2.1.2. Universal mobile telecommunication system
One example of a standard that may employ the
Mobile IP protocol is the UMTS, which is proposed
in [10]. UMTS aims to provide IP level
services via virtual connections between mobile
hosts and IP gateways connected to ISPs or corporate
networks at the edges of the mobile net-
work. Consistent with the Internet architecture, a
user is assigned domain names in order to identify
the ISP that can be accessed to provide Internet
connectivity to that user. When a user logs on, it is
assigned an IP address by the gateway to which
that ISP is connected, also known as the home
gateway. A connection is established, consisting of
two segments: one segment connects the mobile
and some foreign gateway, and another, connects
the foreign gateway and the home gateway, via the
Mobile IP protocol. The connection is maintained
as long as the mobile remains on and the foreign
gateway can be changed as the mobile roams from
the coverage area of one gateway to another. One
can think of the mobile as being linked to the
home gateway via an elastic global pipe. To the
external world, the mobile appears to be located at
the home gateway because it is this gateway that
provides the IP address for the mobile.
2.2. Cellular IP
Cellular IP [9] is a micro-mobility scheme that
aims to accelerate Mobile IP by deploying special-purpose
access networks, built as single IP subnets,
across some geographical regions. The description
of Cellular IP assumes that originally, each wireless
cell (or even pico-cell) constituted an IP sub-
net. Consequently, they propose that multiple
wireless cells be grouped into one subnet to improve
roaming between the cells of one subnet.
However, this concept is not completely new. For
example, the 802.11 standard uses extended service
sets (ESS) to interconnect multiple 802.11 cells
within a single subnet.
Cellular IP access networks, depicted in Fig. 2,
are connected to the Internet via gateway routers.
Fig. 2. A wireless access network in Cellular IP.
Cellular IP uses base stations (BSs) for wireless
access connectivity, and for mobility support inside
an access network. MHs attached to an access
network use the IP address of the gateway as their
COA. The gateway de-tunnels packets and forwards
them toward a BS. Inside a Cellular IP
network, MHs are identi?ed by their permanent
home address and data packets routed without
tunneling or address conversion. The Cellular IP
routing protocol ensures that packets are delivered
to the actual location of the host. Vice versa,
packets sent by the MH are directed to the gate-
way, and from there, to the Internet.
Cellular IP proposes methods for computing
connectivity among base stations and for routing
packets inside an access network. Periodically, the
gateway sends out beacons that are broadcasted
across the access network. Through this proce-
dure, BSs learn about neighboring BSs on the path
towards the gateway. They use this information
when forwarding packets to the gateway. More-
over, when forwarding data packets from users to
the gateway, BSs learn about the location of a
user, and use that information to deliver packets
sent for that user. We remark that, although Cellular
IP proposes protocols for con?guration and
routing in IP subnets, LAN protocols already exist
to accomplish these goals. For example, the algorithms
for building a spanning tree and for learning
as de?ned by the 802standards are widely
deployed and well known.
If a packet is received at a BS for a user that is
unknown to that BS, a paging request is initiated
by the BS. The paging request is broadcast across
a limited area in the access network known as a
paging area. The MH responds to the paging request
and its route to the paging BS gets estab-
lished. Each MH needs to register with a paging
area when it ?rst enters that area, regardless of
whether it is engaged in communication or idle.
Clearly, how fast paging occurs depends on the
size of the paging area and on the e?ciency of
spanning tree traversal. A small paging area can
help reduce the latency of paging, however it increases
the number of paging area required to
cover a given area, which in turn increases the
signaling overhead imposed on MHs.
We observe that the paging techniques in Cellular
IP are similar to those existent in the GSM
system [11]. In GSM, mobile users are located in
system-de?ned areas called cells that are grouped
in paging areas. Every user connects with the base
station in his cell through the wireless medium.
BSs in a given paging area are connected by a ?xed
wired network to a switching center, and exchange
data to perform call setups and deliver calls between
di?erent cells. When a call arrives at the
switching center for a given user, a paging request
for that user is initiated across all the cells in that
paging area. If the user answers, a security check
on the user is performed, and if the test passes, the
switching center sets up a connection for that user.
Cellular IP supports two types of hando?: hard
hando? and semisoft hando?. MHs listen to beacons
transmitted by BSs and initiate hando? based
on signal strength measurements. To perform a
hando?, the MH tunes its radio to the new BS and
sends a registration message that is used to create
routing entries along the path to the gateway.
Packets that are received at a BS prior to the
location update are lost. Just like in Mobile IP,
packet loss can be reduced by notifying the old BS
of the pending hando? to the new BS, and requesting
that the old BS forward those packets to
that BS. Another possibility is to allow for the old
route to remain valid until the hando? is estab-
lished. This is known as semisoft hando? and is
initiated by the MH sending a semisoft hando?
packet to the new BS while still listening to the old
BS. After a semisoft delay, the MH sends a hard
hando? packet. The purpose of the semisoft
packet is to establish parts of the new route (to
some uplink BS). During the semisoft delay time,
the MH may be receiving packets from both BSs.
The success of this scheme in minimizing packet
loss depends on both the network topology and
the value of the semisoft delay. While a large value
can eliminate packet loss, it however adds burden
on the wireless network by consuming precious
bandwidth.
Cellular IP speci?es an algorithm to build a
single spanning tree rooted at the gateway to the
access network as we described above. A spanning
tree is necessary for the broadcasting of packets, to
avoid packets from propagating to in?nity if the
topology of the access network has any loops.
However, because it uses only a subset of the links
inside the access network, a single spanning tree
can result in link overload if tra?c in the access
network is high. This can be a signi?cant draw-back
of Cellular IP as high-density access networks
supporting many Tb/s of tra?c become
possible to deploy. Moreover, a single spanning
tree can be prone to long periods of connectivity
loss. Connectivity loss would make this technology
unacceptable as a replacement to wired, circuit-switched
technology for telephone communica-
tions. Finally, Cellular IP speci?es an interconnect
between BSs that has a ?at hierarchy. As access
networks cover larger area and exhibit higher
pico-cell densities, a ?at hierarchy would result in
latencies of packet traversal across the access net-work
that may be unacceptable.
In conclusion, it is clear that deploying wireless
access networks as single subnets, like in Cellular
IP is important for mobility. In this light, it becomes
important to increase the size of IP subnets
to the largest size possible in order to maximize
their e?ectiveness in supporting IP mobility.
2.3. Hawaii
Hawaii [12] is a micro-mobility scheme intended
to accelerate Mobile IP inside portions of the
Internet by exploiting host-speci?c routing at the
routers present at those locations. Hawaii segregates
the network into a hierarchy of domains,
loosely modeled on the autonomous system hierarchy
used in the Internet [12]. The gateway into
each domain is called the domain root router.
When moving inside a foreign domain, an MH
Fig. 3. Diagram of a domain in the Hawaii architecture. A
domain root router acts as the gateway to each domain. Paths
are established between the routers of a domain.
retains its COA unchanged and connectivity is
made possible via dynamically established paths,
as shown in Fig. 3. Path-setup update messages are
used to establish and update host-based routing
entries for the MHs at selective routers in the do-
main, so that packets arriving at the domain root
router can reach the MH. The choice of when, how
and which routers are updated constitutes a particular
setup scheme. Hawaii describes four such
setup schemes, which trade-o? e?ciency of packet
delivery and packet loss during hando?. The MH
sends a path setup message, which establishes host
speci?c routes for that MH at the domain root
router and any intermediary routers on the path
towards the MH. Other routers in the domain
have no knowledge of the IP address of that MH.
Moreover, the HA and CH are unaware of intra-domain
mobility. We observe that, by sending
path setup messages to a router in the tree, the MH
is doing what a router would normally do in OSPF
to load state for that MH, but without having
to ?ood this information to all the routers inside
the domain. The state maintained at the routers
is soft: the MH infrequently sends periodic refresh
messages to the local BS. In turn, the BS
and intermediary routers send periodic aggregate
hop-by-hop refresh messages toward the domain
root router. Furthermore, reliability is achieved
through maintaining soft-state forwarding entries
for the MHs and leveraging fault detection mechanisms
built in existing intra-domain routing
protocols.
In conclusion, Hawaii exploits host-speci?c
routing to deliver micro-mobility. By design, routers
perform pre?x routing to allow for a large
number of hosts to be supported in the Internet.
While routing based on host-speci?c addresses can
also be performed at a router, it is normally dis-
couraged, because it violates the principle of pre-
?x routing. Furthermore, host-speci?c routing is
limited by the small number of host-speci?c entries
that can be supported in a given router. However,
this concern can be addressed by appropriate sizing
of the domain and by carefully choosing the
routers that are updated when a mobile is handed
o?. One of the problems with the implementation
of Hawaii is that a single domain root router is
used. This router, as well as its neighbors inside the
routing tree can become bottlenecks routers for
the domain for two reasons: ?rst, they hold routing
entries for all the mobile users inside the do-
main, second, they participate in the handling of
all control and data packets for the mobile users
in that domain. Another disadvantage of Hawaii
comes from its use of routers as a foundation
for micro-mobility support. With cells becoming
smaller, it is possible that a larger number of routers
would be needed for user tracking and routing
in a given area; however, this can become prohibitively
expensive.
2.4. Multicast-based mobility
Numerous solutions for supporting mobility via
multicast routing have been proposed [2,6,7]. In
[2,6], multicasting is used as a sole mechanism to
provide addressing and routing services to MHs
in the Internet. Each MH is assigned a unique
multicast address. In [2], a MH initiates a group
membership registration with the multicast router
in its subnet (using the IGMP protocol). In turn,
this router informs neighboring multicast routers
about the multicast group (via one of several
known protocols such as MOSPF and PIM).
Multicast routers in the neighborhood of the user
join this multicast address, and thus form a multicast
tree for that address. Packets sent to the
multicast address of the MH ?ow down the multi-cast
1distribution tree reach the MH. In [6], a MH
sends source-speci?c join messages towards every
CH with which it wishes to communicate. As the
MH moves and connects to another location, the
multicast router at that location joins the group
address, and so a multicast tree, rooted at the CH
gets formed and is used for routing packets between
the CH and the MH. In [7], a multicast architecture
is used to accelerate Mobile IP, by
avoiding the need to inform the HA of every
change in location. MHs are assigned pre-arranged
multicast group addresses at the HA.
Neighboring base stations in the vicinity of the
MH adhere to this group address, and a multicast
tree gets formed, rooted at the HA. Packets are
then tunneled from the HA to the MH, along this
multicast tree.
The most signi?cant drawback of multicast-based
solutions is that they require routers to be
multicast capable; this capability either does not
exist, or it is not turned on in the Internet routers
of today. In essence, this solution requires that
routers learn multicast addresses, in the same way
that routers learn unicast addresses in Hawaii.
Unlike LAN switches, routers are not designed to
learn host addresses, and therefore they would
need to be modi?ed for this purpose. Other
drawbacks of mobility schemes based on multicast
routing are that they require unique multicast
addresses to be used, which creates address management
complexity and limits the addressing
space.
2.5. Micro-mobility and LAN switching
In all the solutions for micro-mobility that we
presented, ?xed IP addresses are used to track
mobile users inside some region. This is done via
learning at wireless BSs, routers or agents. Despite
the use of IP addresses, which are hierarchical,
routing to mobiles inside a region is performed in
a ?at-address space, just like in a LAN. Conse-
quently, MH addresses are tracked in a similar
fashion as layer-2addresses in LANs. We further
make the observation that, in fact, these addresses
are tracked in the same way as virtual channel
identi?ers in virtual circuit-switched solutions such
as ATM (e.g. employed in UMTS for the tracking
of users by foreign gateways). In their original
design, routers were not meant to perform tracking
of individual host addresses, and consequently
do not perform host-speci?c routing in an e?cient
way. It is unlikely that, in the near future, routers
in the Internet will be replaced by routers that
perform this function. It is also unlikely that an
infrastructure consisting of such modi?ed routers
would be deployed to support mobility inside a
micro-mobility region. However, it is feasible to
imagine that an overlay infrastructure consisting
layer-2switches, which, by design, can track host
e?ciently, could be deployed in a cost-
e?ective manner to achieve this goal.
3. A network infrastructure for mobility support
using layer-2 technology
Over the past decade, we have witnessed tremendous
developments in LAN technologies, such
as increases in switch processing by a few orders of
magnitude, and increases in link bandwidth and
distances (owing to the ?ber optics technology).
These advances resulted in an increase in the size
of LANs, and more recently, the deployment of
such technologies in metropolitan areas. Mobile
users can roam inside a LAN without having to
update their addresses. The reason why this is
possible is because LAN switches learn the users
location and can route packets to them quickly
using this information. Furthermore, layer-2tech-
nology is cost-e?ective by virtue of its simple
protocols and large-scale deployment. For these
reason, layer-2technology is at the foundation of
our network design for mobility.
In addition to layer-2, functionality at layer-3
and possibly the directory (DNS) layer is needed
to support mobility at a global level across the
Internet. As described earlier, Mobile IP may be
used to tunnel tra?c appropriately when users
move between subnets. Furthermore, dynamic
DNS may be used to improve performance by
avoiding triangle routing through the HA, as
mentioned in the Introduction. A description of
such a solution is depicted in Fig. 4.
In the rest of the paper, we focus on the design
and analysis of one possible implementation of our
Fig. 4. A multi-layer architecture for IP mobility.
layer-2for mobility support in metropolitan areas.
This network has a number of design goals,
namely: fast tracking of users, for the purpose of
supporting mobility and applications with time
constraints; a simple, low cost design for easy de-
ployment; incremental scalability from small cities
to large cities with many users (tens of millions),
each consuming high data bandwidth (tens of
?nally, support for Internet connectivity, at
high speeds (microseconds) and high bandwidth
(tens of Tb/s).
To achieve the fast tracking of users, it is necessary
that a ?xed address be maintained for each
user while it roams inside the network, to avoid the
penalty of acquiring and releasing many di?erent
addresses. From this perspective, a mechanism for
address tracking is necessary, similar to that performed
by the switches in a LAN. However, unlike
in LANs, the tracking of users must happen at a
faster pace, to accommodate for user mobility at
many speeds. In LANs, switches learn about user
location via the snooping of data packets originated
at that user. Instead, what needs to take
place is the explicit registration of users with the
switches in the network. This network exhibits
functionality that is not typically present in LANs,
thus we refer to it as MobiLANe (i.e. LAN for
mobile users).
The number of switches involved in tracking
each user has to be carefully considered so as to
ensure the fast completion of location updates for
each such user. To achieve this goal, the Mobi-
LANe could be decomposed into control partitions
that include only a subset of the switches in
the MobiLANe. Each user is tracked by the control
partition that includes the switch local to the
user. Note that each switch tracks only a subset of
the users (according to the placement of users at a
given time). Thus, another bene?t of this approach
is that the tracking databases at each switch can be
made smaller and thus the switches can be faster
and cheaper. A protocol similar to the generic attribute
registration protocol (GARP) [14] is designed
to track users inside a given control
partition according to the user location. Since the
location information for a user is not ?ooded
across the entire MobiLANe, an algorithm must
be designed for routing user packets that properly
exploits the information at the control partition
for that user. This can be achieved by employing
the multicast feature of LAN switches, which allows
us to selectively multicast data packets towards
the control partition for that user, from
where the packet can be delivered directly to the
user. To this end, the protocol could also decompose
the MobiLANe into data partitions. Each
control partition must have one or more switches
in common with every data partition. Similarly,
each data partition must have one or more switches
in common with every control partition. Data
packets for a given user are propagated along a
given data partition (as given by the location
where the data packet was ?rst injected into the
MobiLANe) until the control partition for that
user is reached and the packet delivered to the
user. More details are given in the following sub-sections

In this paper, we choose to interconnect a large
number of switches via the grid topology (e.g. the
Manhattan Street Network) as shown in Fig. 5.
For this topology, each row in the grid could be a
control partition and each column, a data parti-
tion, as depicted in Fig. 6. The choice of the grid
topology is partly driven by the fact that the grid
matches the topology of cities themselves??with
the streets being rows and column. In addition, the
grid is scalable by virtue of its distributed nature,
which does not result in the aggregation of tra?c
at some central location such as a root. Further-
more, because of its uniformity, the grid lends
Fig. 5. A MobiLANe implementation using switches connected
by a grid topology.
Fig. 6. A user and its control partition along the horizontal
arrow.
itself to a simple, low cost deployment, that allows
the same switches and link interconnects to be
deployed at all locations across the area. This
eliminates the need to study and understand the
tra?c in the area, in order to properly scale each
individual switch and link bandwidth in the net-
work. However, due to their large number, wireless
cells are connected to MobiLANe switches in a
hierarchical fashion. This hierarchy is necessary to
reduce the number of hops to be traversed when
communicating between two access points in the
grid, and therefore reduce latency.
The MobiLANe topology may not be a perfect
grid for various reasons: the MobiLANe can not
be deployed as a regular structure due to terrain or
administrative restrictions; some switches or links
may fail, resulting in rows and columns of varying
length. To cope with this situation, we developed
the following algorithm to render a grid structure
over an irregular topology: we de?ne a virtual row/
column to be a set of switches and all the edges
between them, such that for any pair of switches in
that row/column ha; bi, the path between a and b is
entirely contained in that row/column. The following
properties are true:
1. The MobiLANe is represented by the sum of all
virtual rows and by the sum of all the virtual
columns.
2. Each virtual row/column must intersect all virtual
columns/rows.
We partition MobiLANe into virtual rows and
columns to create the desired grid structure. Let us
take the example of a missing switch, or a ??hole??.
Intuitively, work around ??holes?? in the topology
by including the switches that neighbor the hole
into virtual rows/columns as follows: for a hole at
location hI; Ji, where I is the row number and J
the column number:
1. Add switches hI
J 1i to virtual column J (assuming these
switches are not holes).
2. Add switches hI
J ? 1i to virtual row I (assuming these switches
are not holes).
To connect to the Internet backbone, a scalable
and distributed gateway router is necessary to
support the aggregate tra?c between the Internet
and all the cells in the MobiLANe. Indeed, if the
numbers of cells and users are large, this band-width
can become very large. For example, for a
LAN supporting two million users, consuming 2
Mb/s each, the routing bandwidth is 4 Tb/s. Fur-
thermore, the router must be physically distributed
across many smaller routers to allow for
load balancing at the links connecting the LAN
switches to the subnet router. To address this, in
this implementation we superimpose a number of
IP subnets onto MobiLANe (at the logical level),
each controlled by one of the IP gateways, which
are placed at di?erent locations in the area, as
shown in Fig. 5.
When a user enters the MobiLANe, it is given
an IP address by the gateway controlling one of
the subnets (this gateway is, say closest to where
the user is located). Evidently, the user IP address
does not change while the user is still in the Mo-
biLANe. It is the responsibility of the switches
inside the MobiLANe to appropriately route
packets to and from the user regardless of the
location of that user. Switches track a user by
learning either the MAC or the IP address of that
user. The advantage of MAC addresses is their use
in LAN switching today. One disadvantage of
using MAC addresses is that not all devices may
come with a built-in MAC address. Another disadvantage
is that some form of address resolution
like ARP needs to be performed at the Mobi-
LANe, to map the IP address of the user to its
MAC address. If the MobiLANe is large, this
operation may take a long time. To cope with the
later challenge, a database is used at each gateway
to map the IP addresses of users to their MAC
addresses. This database holds an entry for every
user belonging to the IP subnet for which that
gateway is responsible. The database of a gateway
is updated at the same time that the user enters the
MobiLANe and receives an IP address from that
gateway.
3.1. Registration protocol
As mentioned earlier, the propagation of
tracking information in the partition is by means
of a dynamic registration protocol similar to the
GARP [8]. The protocol, depicted in Fig. 7, consists
of a number of control messages:
1. The JOIN message informs switches of the arrival
of one or more users.
2. The LEAVE message informs switches of the
user(s)?s departure from the switch?s jurisdiction

3. An ACK message con?rms that the registration
updates have been received.
A switch of a partition is a local switch if it is
directly connected to the access point where a user
resides. The other switches in the partition are
Fig. 7. Registration protocol.
known as remote switches. A local switch propagates
control information to one or more remote
switches in the partition. If rings are used to connect
the switches along rows and columns, then the
control messages at the local switch are propagated
as follows:
1. either left or right when the control partition is
a row or a virtual row,
2. either up or down when the control partition is
a column or a virtual column,
3. either left and down, left and up, right and
down or right and up when a control partition
is a pair of rows (or virtual rows) and columns
(or virtual columns).
When the MobiLANe is con?gured, switches are
programmed to propagate control messages in a
?xed direction selected form the choices outlined
above.
When a control message arrives at a remote
switch, it is used to con?gure the routing tables
appropriately. It is also remembered and sent out
on the port directly opposite to the port where the
control message was received (e.g., if the control
message is received on the left port, it is propagated
on the right port). When a control message
arrives to a switch that has already seen it, it is
consumed and removed from the ring.
If a ring topology is not used to connect
switches in a row or column, the control message
at the local switch is multicast in two directions
when the control partition is either a row (virtual
row) or column (virtual column) (e.g. up and down
that column), and four directions when pairs of
rows (virtual rows) and columns (virtual columns)
are used (up, down, left and right). Note that if a
given control message did not cause the routing
tables for a given port to be updated, then the
message is not propagated along that port. One
such case occurs when the control partition is a
row and the user moves from one switch to the
next switch in that row. The new local switch observes
that the routing tables for the horizontal
ports need not be updated, hence a control message
is not sent to the remote switches.
Every time a mobile crosses cell boundaries, a
JOIN message is sent to the local switch by the
wireless cell to which the user is connected. The
JOIN is propagated across the new control parti-
tion. An ACK reply is propagated in the reverse
direction across the same control partition. Upon
reception of an ACK message for the JOIN at the
local switch, a LEAVE message is sent to the old
switch port, which then gets propagated across the
old control partition (we assume that communication
between the new and old local switches is
possible). An ACK reply is then propagated across
the old control partition and sent to the new local
switch, which completes the registration process.
Acknowledgements are used to ensure that user
registration and de-registration with the switches
of a partition are atomic. When moving from one
partition to another, a user leaves the old partition
only after it has joined the new partition and received
an acknowledgement from it. Notice that
simply receiving a packet from the switches in the
new partition is not enough to guarantee atomicity
because some switches may not have been properly
set. This is because the packet may come from
another user within the partition without traversing
all the switches in that partition. However note
that acknowledgements can be piggybacked to the
user packets that may be traversing the partition,
in order to reduce latency and bandwidth con-
sumption. This technique assumes that cell overlap
is possible and its extent long enough to allow
for the new JOIN to complete, and the ACK to be
received.
A terminal switch is a switch that determines
not to propagate a registration message received at
an input port to any output port. Each switch that
is not a terminal switch waits for acknowledgements
from other switches before submitting an
acknowledgement. Terminal switches update their
databases and then send acknowledgements without
further wait. When single rows or columns are
used for control partitions, the local switch waits
for a single acknowledgement before proceeding
with the LEAVE. When pairs of rows and columns
are used as control partitions, then the local switch
waits for two acknowledgements, one from the
row switches, and one from the column switches.
Note that if a switch moves from one partition
to another partition that have a common row or
column, then a single acknowledgement is needed,
corresponding to the column or row that is different

3.2. Routing
In our routing protocol, we capture the mechanism
by which routing at the switches is to be
performed along data and control partitions.
When a switch receives a data packet for some
user, the following possibilities arise:
1. If the user is known to the switch (i.e. the switch
belongs to the control partition for that user),
then the packet is routed according to the information
in the table.
2. If the user is not known to the switch (i.e. the
switch does not belong to the control partition
for that user but belongs to the data partition
for that data packet), then the data packet
is routed according to some routing algorithm
selected when the MobiLANe was originally
con?gured.
We identi?ed three such routing algorithms:
(1) Vertical. If the switch is the ?rst switch in the
data partition to see the packet, and the ring topology
was not used to connect the switches of a
row or a column, then the packet is routed BOTH
up and down. If the switch is the ?rst switch in the
data partition to see the packet, and the ring topology
was used to connect rows and columns,
then the data packet is routed either up or down,
depending on the switch con?guration. This
routing scheme is called vertical-?rst routing.
(2) Horizontal. If the switch is the ?rst switch in
the data partition to see the packet, and the ring
topology was not used to connect the switches of a
row or a column, then the packet is routed BOTH
left and right. If the switch is the ?rst switch in the
data partition to see the packet, and the ring topology
was used to connect the switches of a row
or a column, then the packet is routed either left or
right, depending on the switch con?guration. This
routing scheme is called horizontal-?rst routing.
(3) Sometimes horizontal and sometimes vertical.
Here we combine the two algorithms above. Some
packets are routed using vertical-?rst routing while
others are routed using horizontal-?rst routing.
We describe each algorithm in more detail in
the following subsections.
3.2.1. Vertical-?rst routing
Vertical-?rst routing refers to a scheme where a
switch in the grid routes vertically a packet that it
receives for a user unknown to it. Eventually, the
packet arrives at a switch that knows the user (at
the intersection of the control partition for that
user and the data partition for that data packet),
from where the packet is then routed home.
For this routing scheme to work, the tracking
protocol requires that the control partition for
every user include the row in which that user is
located. Vertical-?rst routing with row control
partitions is depicted in Fig. 6. At ?rst, the packet is
routed up the column, where it eventually reaches a
switch that ??knows?? the user. If the column is a
ring, the packet is only routed in one direction (ei-
ther up or down). Otherwise, the packet is multicast
up AND down. The ?rst switch that knows the user
routes the packet horizontally. If the row is a ring,
the packet is only routed in one direction (either left
or right). Otherwise, the packet is multicast left
AND right. From there on, the packet is routed
horizontally until the switch to which the user is
attached is found and the packet gets delivered.
3.2.2. Horizontal-?rst routing
This works identically to vertical-?rst routing,
except that the direction taken by a packet at a
switch is horizontal instead of vertical when that
switch does not recognize the user for which the
packet is intended.
3.2.3. Alternating vertical-?rst and horizontal-?rst
routing
Intuitively, one can see how vertical-?rst routing
or horizontal-?rst routing can lead to load
unbalance if the users or the input/output vertices
are concentrated along a particular row or col-
umn. For example, if the users are concentrated
along some column and horizontal-?rst routing is
used, then tra?c is routed along the vertical axes
by using primarily that column. Also, if the input
to the grid is concentrated along one column and
vertical-?rst routing is used, then tra?c is routed
vertically by using primarily that column. To
avoid this situation, the routers of the MobiLANe
must be distributed in a balanced fashion across
the MobiLANe. However, depending on the re-
gion, it may not be possible to control the distribution
of routers so to ensure uniform coverage of
all rows and columns. Under these circumstances,
a routing algorithm that distributes the load fairly
across the MobiLANe becomes essential. This is
particularly important when the link bandwidth
is scarce (e.g., microwave radio links or low-cost
MobiLANe infrastructure).
Consequently, in order to balance the load,
we designed a scheme that alternates vertical-?rst
routing with horizontal-?rst routing. The scheme
works as follows: instead of always routing horizontally
or vertically when the destination user is
unknown, switches route vertically sometimes and
horizontally other times. By alternating between
vertical-?rst routing and horizontal-?rst routing,
we ensure that, in the long run, the load is divided
fairly across all rows and all columns, regardless
of the user and router distribution. In order to
guarantee that all packets reach their intended
destinations, we must ensure that packets are
routed in the same fashion (vertically or horizon-
tally) at all the switches that do not recognize the
user for whom a given packet is intended. This is
achieved by having the ?rst switch that routes the
packet select the routing direction. This switch
marks the packet to communicate to the other
switches that a routing direction had been selected
for that packet. The other switches observe that
the packet is marked and are required to follow
suit and route in a similar fashion. They route the
packet to the port directly opposed to the incoming
port (e.g. the left port if the packet was received
on the right port). The ?rst switch selects
the routing direction by alternating between the
vertical and horizontal direction in a round-robin
or random fashion.
3.2.4. Clustering
It is expected that users visit cells in the neighborhood
of their location more frequently than
remote cells. In our schemes, when rows are used
as control partitions, and the user moves to the
next row, registration with the new row and de-registration
with the old row need to take place.
When pairs of rows and columns are used as control
partitions and the user moves either to the next
row or the next column, registration with the new
row or new column need to take place. If the user
moves frequently, then these updates can be ex-
pensive. One solution is to perform user tracking
in a hierarchical way that exploits the spatial locality
of user movement. Instead of a local switch,
we use a cluster of switches, called the local cluster.
As before, we use rows (or columns, or both) to
track and locate users. However, while before the
row (or column, or both) was used to obtain the
location of the user exactly, now it is used to obtain
the location of the user cluster to which the
user belongs. To ?nd the actual the location of
the user, we use the tracking at the switches inside
the local cluster. Tracking inside a local cluster is
performed as follows:
(1) If rows are used as control partitions to ?nd
the local cluster, then columns (or segments of
columns) must be used as control partitions to ?nd
the user inside that cluster. By using columns as
control partitions inside the local cluster, we
ensure that the registration information can be
propagated between the local cluster and the row
that tracks that cluster.
(2) If columns are used as control partitions to
?nd the local cluster, then rows are used as control
partitions to ?nd the user inside that cluster.
(3) If pairs of rows and columns are used to ?nd
the local cluster, then pairs of rows and columns
are used to ?nd the user inside that cluster.
When a user moves inside a local cluster,
tracking updates need to take place only at
switches in that cluster. When a user leaves a local
cluster and joins another, we update the tracking
databases in the rows and columns of the grid that
track the new local cluster, as well as inside the
new local cluster. Depending on the size of the
cluster, updating tracking databases inside the
local cluster can be signi?cantly less expensive than
updating an entire row or column of the Mobi-
LANe. Clustering can signi?cantly reduce the cost
of completing a location update.
Routing is performed in two steps: ?rst, the
local cluster is found, via one of the routing algorithms
we described before. Second, the actual
user location is found, via routing at the switches
inside the cluster. Fig. 8 shows the switches clustered
in di?erent clusters corresponding to di?er-
ent quadrants of the grid. The lines corresponding
to the column and row used for tracking the
cluster in which the user resides are shown by the
dotted lines. The switch where these lines intersect
is known as the head (or pivot) of the cluster. The
pivot is dynamic for each user, and is given by the
Fig. 8. MobiLANe clustering.
switch via which the user had joined the cluster. By
making the pivot dynamic, we allow the tra?c
load to be more uniformly distributed across the
rows and columns of MobiLANe.
3.3. Contributions of MobiLANe design
The MobiLANe design has a number of ad-
vantages. The MobiLANe does not rely on a single
spanning tree or root switch. This is important
for scalability as the MobiLANe extends to large
geographical scopes. By exploiting control and
data partitions, it minimizes the latency of user
location updates without a?ecting the latency of
packet routing inside the MobiLANe. Finally, its
operation relies signi?cantly on existing switching
techniques and protocols, which makes the solution
simple, inexpensive and easy to implement
and deploy.
4. Simulation environment
We use a stochastic mobility model from the
University of Waterloo [9], which simulates daily
movements of mobile subscribers, incorporating
realistic activity patterns. The input data to the
model includes an activity transition matrix and an
activity duration matrix, derived from the trip
survey [18] conducted by the Regional Municipality
of Waterloo in 1987. For this survey, a
travel diary was completed by each household
member over ?ve years of age, in which details
were recorded on all trips taken during the day of
the survey. Included for each recorded trip were
the trip start and end times, the trip purpose at the
origin and destination, and employment or student
status.
There are nine types of activities de?ned in the
model, which are as follows: work, school, shop-
ping, personal business, work-related, serve pas-
senger, social/recreation, return home and other.
Each activity has an associated time of day, duration
and location (at the level of a radio cell). In
a given simulation run, activities are selected based
on the previous activity and the current time pe-
riod. The probability of transition from one activity
to another uses the activity transition matrix.
Once the next activity is selected, its duration is
determined using the activity duration matrix.
Finally, the location of the activity is selected,
based on certain heuristics and the activity type
(e.g., if the activity purpose is ??shopping??, a cell is
randomly selected from a set of cells neighboring
the subscriber, within a radius as given by the retail
characteristics of the region). Once the location
of the next activity is selected, the intermediate
route (in terms of cells crossed) and the total distance
are determined from a geographical lookup
table. Using a user-de?ned system-wide average
speed, the time spent in each intermediate cell is
calculated. The subscriber stays in the destination
cell for the duration of the activity, and the sequence
is repeated. The output from the model is
thus a trace of the daily movement of individual
cellular subscribers over a period of several days,
in terms of cells crossed and time spent in each cell.
The geography of the region simulated, which
is shown in Fig. 9 (approximated from the geographical
lookup table), covers 312km 2 and is divided
into cells, each covering an average of
7km2. For each subscriber, a home cell, a work
cell and a school cell are selected randomly from
among the cells in the region. Starting at home,
users take daily trips such as going to work and
back, going shopping and going to the movies. We
simulated during which subscribers were
tracked on a per minute basis. The simulation is
event-driven and has a granularity of one minute.
An event that occurs between two minutes is
considered to have occurred at the earlier minute.
Fig. 9. Cell division for the region simulated.
Since they happen during the same minute, the
JOIN, LEAVE and ACK corresponding to a cell
crossing occur simultaneously in our model.
In our simulations, two wireless cell types are
employed: macro-cells and micro-cells. A macro-cell
maps directly to a cell as de?ned in the mobility
model discussed above. The characteristics
of the wireless macro-cells are summarized in

Table

1.
An architecture where cells are further subdivided
into micro-cells is also discussed (Table 2).
Macro-cells are subdivided into micro-cells to increase
user bandwidth. Mainly, one macro-cell is
subdivided into 700 smaller cells, allowing short-range
wireless protocols (like 802.11b) to be used
inside a micro-cell. This results in approximately
7.5 Gb/s bandwidth to be available inside a cell,
i.e. an increase by 770,000 in bandwidth per
cell. Higher user bandwidth is crucial for deliver-
Table
Macro-cell characteristics
Range 7 km2
Bandwidth 100 kb/s
Total number of cells 45
Example of protocol Cellular telephony

Table
Micro-cell characteristics
Range
Bandwidth 11 Mb/s
Total number of micro-cells 31,500
Example of protocol 802.11b
ing multimedia to mobiles. A single H.263 video
Kb/s, so this would allow for
approximately 770,000 users to receive di?erent
video streams simultaneously inside a cell. For this
con?guration, multiple switches are used to balance
the load across the region and to reduce the
number of ports needed for connecting the micro-cells
at a switch. Since the total load across all the
micro-cells in the region is about 340 Gb/s, we
chose to spread this load across 45 switches, each
responsible for 7.5 Gb/s sent to/from users in the
700 micro-cells of a cell. The switches are grouped
in a grid consisting of nine rows and ?ve columns
5).
To compare the performance of our system
against the performance of other schemes, we consider
three scenarios as follows:
(1) The Mobile IP scenario: nine foreign agents
populate the region, each responsible for one-ninth
of space (as given by a row in the grid). For experimental
purposes, the HA is considered to be
outside the region, with each FA being directly
connected to the HA (at equal distances). Location
updates are sent to the HA. To reach its destination
user, tra?c arrives at the HA from where it
gets forwarded to one of the foreign agents inside
the region. This is shown in Figs. 10 and 11 by the
interrupted line between the CH, HA and the re-
gion. Notice that Mobile IP allows the CH to receive
binding updates with the latest COA of the
user. However, in our simulations, each call is
generated by a di?erent CH, hence the information
in the binding cache is irrelevant.
Fig. 10. Simulation scenario with wireless macro-cells.
Fig. 11. Simulation scenario with wireless micro-cells.
(2) A typical micro-mobility algorithm (such as
HFA or Cellular IP), labeled Micro IP. 45 routing
devices (such as FAs in HFA or switches in Cellular
IP) populate the region, and are connected
via a hierarchical interconnect as shown in Fig. 12.
A gateway connects the root of the tree to the
Internet. Location updates are handled locally by
the hierarchy and do not need to reach the HA.
However, all tra?c from the CH traverses the HA
prior to arrival at the region.
(3) MobiLANe: The MobiLANe is populated
by 45 switches interconnected via a regular, 9 5
grid topology. Each switch controls one macro-cell
Fig. 12. The tree hierarchy in Micro IP. The gateway (G) is
connected to the root of the tree, and to the Internet. The region
is populated by 45 routing devices.
or 700 micro-cells in a cell area. To superimpose
the grid structure on the region, the switches are
grouped into irregular columns and rows (an example
of a column is shown in Fig. 9). Figs. 10 and
11 depict the MobiLANe implementation for each
wireless cell type we considered. In this paper,
vertical-?rst routing is used, and no clustering. For
the users in the MobiLANe, DNS is updated with
the COA of the gateway responsible for the region.
Tra?c from the CH arrives directly at the gateway
from where it is forwarded to the switches. This is
shown in the ?gure by the uninterrupted line between
the CH and the region. Location updates
are handled by the switch local to the moving user
and do not need to be forwarded to the HA.
A stochastic model for user voice tra?c is assumed
in order to test the impact of the mobility
architecture on user tra?c performance. Tra?c is
originated from a CH, located outside the area,
and is addressed to a user inside the area. Users
receive phone calls at random times throughout
the day. The number of phone calls per day and
the duration of each phone call are entered statically
as parameters to the simulation.
We identi?ed a number of important metrics
for evaluating our architecture: the peak per
minute control load, including the total number
of JOIN?s, LEAVE?s and ACK?s at a switch
BW_CTL; the peak per minute data load at a
switch BW_DTA; the time to complete a location
update, in terms of the number of switches
traversed LAT_CTL. Note that, to complete an
update, multiple switches may be traversed in
parallel (e.g., across the row and column of a
control partition). In this case, we consider update
latency to be the longest of the parallel tracks
traversed to complete the update. In the case of
LAT_CTL, we consider the time to setup paths to
users entering the region (Init), as well as the peak
and average (Avg) per minute values across
all users. We also consider the time for a packet to
travel from source to destination, which we call
routing latency or LAT_DTA. We measure routing
latency in terms of the average number of
switches traversed per packet across all users.
To compute BW_CTL, we count the number of
control messages per minute, multiply it by the
length of the control message and divide it by 60.
The length of the control message is assumed to be
B. We think 16 B is a good estimation since it
includes 12B for the source and destination ad-
dresses, 2B for the checksum and 2B for various
attributes and options.
To compute LAT_CTL, we measure the number
of cell crossings that occur during a simulation, and
multiply this number by the number of switches
involved in a location update for each algorithm.
The duration of the location update depends on the
scenario as follows: for the Mobile IP scenario, it
represents the time to update the database at the
local FA, to transfer the update message between
the FA and the HA and the time to update the
database at the HA; for the Micro IP scenario, it
represents the time to update the appropriate
routing devices in the tree; ?nally, for MobiLANe,
a location update includes the time to update the
appropriate switches in the MobiLANe.
To compute LAT_DTA, we measure the number
of switches involved in transferring each packet
across the MobiLANe and multiply it by the time
to transfer the packet at the switch. We add the
time to transfer the packet between the CH and the
gateway in charge of the mobile. For the Mobile IP
and Micro IP scenarios, we add to this number the
time to transfer the packet between the HA and the
region. We show the sensitivity of LAT_DTA to
time between the HA and the region. We
assume that the distances between the CH and the
HA, between the HA and the region and between
the CH and the region are the same.
5. Simulation results
5.1. Control load
In this section, we investigate the scaling of
control load with the size of population in the re-
gion, in the case of MobiLANe with macro-cells
and MobiLANe with micro-cells. It is important
that the control load amount to a small number
(relative to the capacity of the switches of today)
for MobiLANe to be a feasible solution, for a
variety of population sizes.
Fig. 13 shows BW_CTL for MobiLANe with
macro-cells and MobiLANe with micro-cells, and
Fig. 13. BW_CTL for di?erent population sizes for the cases of MobiLANe with macro-cells and MobiLANe with micro-cells.
for various population sizes between 1000 and
people. Prohibitively long simulation times
limited the population size studied to this range.
The dependency of BW_CTL on population
size is sub-linear. When scaling from 1000 to 5500
people, we noticed sub-linear e?ects: less than 3.3
and 2.5 increase for MobiLANe with macro-cells
and MobiLANe with micro-cells, respectively.
This is explained by the fact that, for this population
range, an increase in population size contributes
primarily towards the spreading of tra?c
across more cells and more time slots and only
secondarily towards increasing peak tra?c in a
given time slot and a given cell. More substantial
increases in BW_CTL are expected for high population
ranges due to the increased user concentration
in a given time slot.
As expected, cell subdivision results in a sig-
ni?cant increase in BW_CTL because of the increase
in the rate of cell crossings. The subdivision
of each macro-cell into 700 micro-cells results in
about 7 increase in BW_CTL. Assuming linear
increase for high population densities, a population
of 500,000 people (which is large for a region
of 312km 2), would generate about 200 Kb/s in
control tra?c in the case of MobiLANe with mi-
cro-cells. Assuming a registration latency of 1 ls,
(or the equivalent of 10 SDRAM lookups), a
single switch can support 1,000,000 registrations
per second, or an equivalent of 122 Mb/s. Since the
maximum value achieved by BW_CTL is 200
Kb/s, there is more than enough bandwidth to
support the registration bandwidth generated by
this region fully populated (at 500,000 people).
In this section we demonstrated the feasibility
of MobiLANe with macro-cells and MobiLANe
with micro-cells, with regard to supporting registration
tra?c for tracking user movement. In
the rest of the paper, we present results only for
MobiLANe with micro-cells, because it represents
a more interesting experimental case, and it delivers
higher data bandwidth to users.
5.2. Control latency
Fig. 14 shows the behavior of the average
LAT_CTL as a function of distance to the HA for
Mobile IP. LAT_CTL for MobiLANe with one
gateway is plotted for reference. A 1 ms processing
delay at the FA and every switch in the network is
assumed. Processing time at the HA in considered
part of the distance to the HA. As we can see from
the graph, Mobile IP does generally worse than
MobiLANe because of the overhead of communicating
with the HA upon every location change.
However, if the HA is nearby to where the user
is located, HA updates may take less time than
local updates in MobiLANe. This is because, for
MobiLANe, a larger number of electronic switches
need to be involved in one location update than for
Mobile IP.
Fig. 15 shows Init, Peak and Avg. LAT_CTL
for MobiLANe, Micro IP and Mobile IP. The
distance to HA is arbitrarily set to 20 ms. We
observe that MobiLANe performs better than
both Mobile IP and Micro IP in all three cases:
the time to setup connectivity to subscribers (Init),
and the peak and average LAT_CTL. The reason
Fig. 14. Avg. LAT_CTL for Mobile IP, for di?erent distances between the local FA and the HA.
Fig. 15. Init, Peak and Avg. LAT_CTL for MobiLANe with
micro-cells and one gateway, Micro IP and Mobile IP.
MobiLANe performs better than Mobile IP is
because no HA overhead is incurred. The reason
MobiLANe performs better than Micro IP is because
fewer switches need to be informed of the
location of users, due to the selective multicast
nature of the routing algorithm of the MobiLANe
used in MobiLANe.
5.3. Data load
Fig. plots di?erent numbers of
gateways, di?erent per-user application bandwidth
Kb/s, 128 Kb/s and 1 Mb/s) and for three different
schemes: Mobile IP, Micro IP and Mobi-
LANe (with ?ve di?erent numbers of gateways).
We notice that the best results are achieved for
Mobile IP. This is because, in this implementation
of Mobile IP, FAs only track and route to/from
users in their portion of the region and do not
transfer tra?c sent for another foreign agent in
that region. When multiple gateways are used,
decreases considerably from the case of
a single gateway. When four gateways are used,
less than half as much peak tra?c is born by
the switches than when one gateway is used. This
means that, when multiple gateways are used,
smaller, cheaper switches can be deployed in the
MobiLANe.
5.4. Data latency
5.4.1. Impact of dynamic DNS
Fig. 17 displays LAT_DTA for various distances
between the MH and the HA and the CH
and for three di?erent scenarios: MobiLANe with
one gateway, Micro IP and Mobile IP.
increases monotonically with distance; a slower
rate of growth is observed for MobiLANe (owing
to the use of dynamic DNS which circumvents the
need for tunneling through the HA). For a distance
value of 40 ms, LAT_DTA is almost twice
smaller if dynamic DNS is used. Notice that for
Fig. 17. LAT_DTA for MobiLANe with micro-cells and one
gateway, Mobile IP, Micro IP.
Fig. 16. BW_DTA for MobiLANe with micro-cells for di?erent number of gateways.
switching technologies, as well as load balancing
techniques and the use of multiple distributed
gateways which have the e?ect of lowering
the peak load and memory requirements at the
switches, make it possible to implement Mobi-
LANe with small and inexpensive technology.
7. Migration path
Fig. 18. LAT_DTA for MobiLANe with micro-cells for different
numbers of gateways.
small distance values (a few ms), LAT_DTA is
actually larger in the case of MobiLANe and Micro
IP than for Mobile IP. This is because of the
inherent overhead of traversing the switches populating
the region. In the case of Mobile IP, fewer
electronic components are traversed as packets are
routed between the CH, HA and the MH.
5.4.2. Impact of multiple gateways
Fig. shows the variation in LAT_DTA for
MobiLANe in terms of the number of gateways.
We notice that decreases slightly as
more gateways are used. This is for two reasons:
when the MobiLANe is populated with more gate-
ways, these gateways are placed closer to subscribers
than when fewer gateways are used. Secondly,
subscriber movement exhibits a small degree of
locality; on average, subscribers are closer to their
home gateways than to any other gateway in the
MobiLANe. A distance of 20 ms between the
MobiLANe and the CH, and a 1 ms processing
delay at the gateway are assumed.
6. Contributions of MobiLANe
Our simulations demonstrate that MobiLANe
is a scalable, feasible solution for supporting IP
mobility over a large metropolitan area. By virtue
of localized registration and distributed routing
algorithms and the use of dynamic DNS, Mobi-
LANe fairs better in performance than other existing
schemes. Reliance on existing, low-cost
To transition to the mobile network of tomor-
row, it may not be possible to design the supporting
network infrastructure from scratch.
Instead, support for mobility may need to be
built on existing network structures, such as small
subnets controlled by LAN switches and inter-connected
by IP routers with a small number of
host-speci?c entries. Under such circumstances,
one possibility is the use of virtual private networks
(VPN) to o?er extended LAN connectivity
across multiple small subnets. In order to support
mobile users in the most e?ective fashion, the
protocol to handle mobile users needs to be ?exi-
ble enough to operate at di?erent layers in the
protocol stack, and versatile enough not to require
changes in the implementation of the LAN
switches and IP routers of that network. In par-
ticular, the protocols running on LAN switches
should be based on existing 802protocols, since
they are implemented in hardware and therefore
cannot be easily replaced or reprogrammed. The
main challenge becomes how to use and optimize
existing protocols for the purpose of e?cient
support for mobility.
8. Conclusions
This paper surveys the state-of-the-art in providing
mobility support to mobile users in the
Internet. In particular, emphasis is placed on
micro-mobility techniques designed to accelerate
Mobile IP. One observation is that all micro-mobility
solutions work in a similar way by requiring
that network devices inside a given geographical
area learn about the location of users and keep
track of them as they move inside that area. The
di?erences among these techniques are the type of
device required to do the learning (it could be an
IP router, Mobile IP agent or LAN switch) and the
protocols for routing packets using the learning
databases. This paper also proposes the deployment
of an infrastructure based on simple and
cost-e?ective layer-2technology, to support user
mobility in geographical areas of many scopes.
One important feature of this infrastructure is its
scalable and e?cient MobiLANe design, geared at
accelerating Mobile IP in large geographical re-
gions. By relying on existing technologies, and by
virtue of working with Mobile IP, this solution is
global, cost-e?ective, easily deployable and compatible
with the Internet of today.


--R


A new multicasting-based architecture for Internet host mobility

A multicast-based protocol for IP mobility support



HAWAII: a domain-based approach for supporting mobility in wide-area wireless networks

IEEE 802.1d MAC Layer Bridging Standard.
TRIAD: a scalable deployable NAT-based Internet architecture

Waterloo Region Travel Survey
Route Optimization in Mobile IP

where she worked on DSP systems.

design technologies.
including protocol design
In June
the School of Engineering at Stanford University

Computer Science.

served as Chief Technical O?
interests include packet switching in ground radio and
high speed local area networks

multimedia networking and

network systems.
computer communications and local area networks.
winner of the

cess protocols in packet communications networks?
winner of the IEEE Communications Society


Communications in the IEEE Transactions on Communications
for the period
Satellite Networks in the Journal of Telecommunications Networks
for the period
on local area networks of the IEEE Journal on Selected Areas
in Communications (November
in local area networks

issue on


Selected Areas in Communications (October
served as Co-Editor of Advances in local area networks
in the series Frontiers in Communications (IEEE Press

in high speed networks
He is a member of the Association for
Computing Machinery and has served as an ACM National
Lecturer for the period
Kuwait Prize in the
--TR
Internet mobility 4MYAMPERSANDtimes;4
A new multicasting-based architecture for Internet host mobility
An activity-based mobility model and location management simulation framework
An end-to-end approach to host mobility
Mobile communications
A multicast-based protocol for IP mobility support
IP Routing and Mobility
HAWAII

--CTR
Cristina Hristea Seibert , Fouad A. Tobagi, Assessment and optimization of schemes for tracking and routing to mobile users in packet-based networks, Computer Networks: The International Journal of Computer and Telecommunications Networking, v.44 n.1, p.103-133, 15 January 2004
Hidetoshi Yokota , Akira Idoue , Toru Hasegawa , Toshihiko Kato, Link layer assisted mobile IP fast handoff method over wireless LAN networks, Proceedings of the 8th annual international conference on Mobile computing and networking, September 23-28, 2002, Atlanta, Georgia, USA
scalability;mobility;seamlessness;IP networks;local and metropolitan area networks;overlay infrastructure