Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: Virtual cell in mobile computer communications
CITATION PDF VIEWER THUMBNAILS PAGE IMAGE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00095290/00001
 Material Information
Title: Virtual cell in mobile computer communications
Alternate Title: Department of Computer and Information Science and Engineering Technical Report ; TR94-020
Physical Description: Book
Language: English
Creator: Lim, Kyungshik
Lee, Yann-Hang
Publisher: Department of Computer and Information Sciences, University of Florida
Place of Publication: Gainesville, Fla.
Copyright Date: 1994
 Record Information
Bibliographic ID: UF00095290
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.

Downloads

This item has the following downloads:

1994141 ( PDF )


Full Text










TR94-020
Virtual Cell in Mobile Computer Communications


Kyungshik Lim and Yann-Hang Lee
Computer and Information Sciences Department
University of Florida
Gainesville, FL 32611


Abstract
This paper describes a virtual cell concept for the
transmission of IP datagrams in mobile computer com-
munications. A virtual cell consists of a group of phys-
ical cells whose base stations are implemented by re-
mote bridges and interconnected via high-speed data-
gram packet-switched networks, supporting host mo-
bility at the data link layer. Thus, as far as the IP
layer is concerned, it appears as if the communication
between two mobile hosts in different physical cells
were taking place directly as in the same physical cell.
It eliminates the necessity of IP-level protocols for mo-
bility management which may interfere with the con-
ventional IP protocol in a practical sense, and achieves
a logically flexible coverage area according to mobility
and data traffic patterns among physical cells. Vir-
tual Cell Protocol (VCP) which consists of handover,
address resolution, and data transfer modules is de-
signed based on the distributed hierarchical location
information of mobile hosts. To measure data which
will be used as parameters to a performance model for
the virtual cell, we implement VCP on a simulated en-
vironment.

Key Words: Wireless Networks, Mobile Computer
Communications, IP


1 Introduction

As computers become more powerful and portable
with the appearance of high-speed wireless interfaces,
there is an increasing demand on the provision of mo-
bile computer communications in TCP/IP environ-
ments. A fixed host in internets is always assigned an
IP address which not only serves a unique identifier
used by the higher layer protocols but also represents
the current location of it. An inherent problem from
the transmission of IP datagrams in mobile computer


communications is that when a mobile host (MH) mi-
grates, its IP address is only valid as the identifica-
tion information but not able to represent the current
location information. To solve this problem, various
researches and developments have focused on how to
integrate the functionality of host mobility into the IP
layer, preserving the compatibility with the conven-
tional IP protocol [1, 2, 3, 4, 5, 6].
Although these mobile host protocols vary on how
to represent and maintain location information for ef-
ficient tracking of MHs, the techniques of using the IP
options and IP encapsulation have been considered.
Typical examples of the first technique are Virtual In-
ternet Protocol (VIP) [2, 3] and the mobile host pro-
tocol using IP Loose Source Routing option[4]. IP-
within-IP (IPIP)[1] and Internet Packet Forwarding
Protocol[6] use the second technique. Even though
the details of these mobile host protocols are different,
we consider one representative mobile host protocol for
each technique, VIP and IPIP, to illustrate common
features and problems of integrating host mobility into
the IP layer.
In VIP, the network layer is divided into two layers;
the VIP layer resides on top of the normal IP layer.
The VIP packet header is implemented as an option of
the IP packet header. An MH keeps its permanent IP
address used at the VIP layer for its identification and
acquires a transient IP address used at the IP layer
for its current location information when it migrates.
If the MH is in its native network, both addresses are
the same. After acquiring a transient IP address, the
migrating MH sends its native network a notification
packet whose header contains the permanent and tran-
sient IP addresses. As the packet propagates to the na-
tive network, every network entity including MHs, mo-
bile support gateways (\I1Gs), and even intermediate
gateways on the path snoops the header information
and stores address conversion information to a cache.
In the same way, the header information of all data











packets in transit is also used by the network entities
to maintain their caches. If the source has the cache
entry for the destination, the source executes address
conversion before sending a packet. The existing rout-
ing protocols of the IP layer can then correctly deliver
this packet to the destination. Otherwise, the source
assumes that the destination resides in its native net-
work and sends the packet accordingly. As the packet
traverses to the native network of the destination, if
an intermediate gateway has the cache entry for the
destination, the gateway executes address conversion
and forwards the packet to the current location of the
destination.
Unlike VIP, intermediate gateways in IPIP are not
involved in the support of host mobility but merely
in transport service. The source \I'G encapsulates
a network control packet for mobility management or
an IP datagram from an MH into another IP data-
gram whose source and destination addresses specify
the communicating ~\IGs, and transmits it over an in-
ternet. The existing routing protocols of the IP layer
then correctly deliver it to the destination \I'G. Thus,
S1IGs consider internets as a full mesh of logical point-
to-point links to interconnect them. A mobile network
consists of a number of \ I Gs, each of which maintains
the location information of its own MHs. Every MH
in the mobile network is assigned a unique IP address
but the network part of the IP address is the same.
When the MH migrates, a forwarding pointer is set
from the previous M'\IG to the new M'\IG for location
tracking. If the \I'G has no location information for
a specific MH, it broadcasts the other \I'Gs in the
same mobile network an inquiry message asking who
has the MH. However, IPIP also requires a transient
IP address when the MH visits a foreign mobile net-
work.
Regardless of which technique is used, the integra-
tion of host mobility into the IP layer reveals several
implications. First, underlying networks differ widely
in their network size, bandwidth, protocol, and packet
size so that they or some of them may not meet perfor-
mance needs for the support of host mobility such as
rapid migration and tracking of MHs. Moreover, be-
cause they are usually under different administrative
controls, efficient network management and optimiza-
tion for the global mobile network may not be easy
tasks.
Second, intermediate gateways may cause some per-
formance problems no matter they are involved in the
support of host mobility or not. If they are involved
in, as in VIP, they must be modified or replaced to
understand VIP so that the benefit from using ex-


isting internets as transport networks is diminished.
Furthermore, because intermediate gateways have to
snoop every packet in transit to maintain location in-
formation, and examine every data packet in transit
to try to perform address conversion, the protocol pro-
cessing and memory loads at intermediate gateways
may severely affect overall performance. Even in case
that they are not involved in, as in IPIP, because they
usually implement packet switching operation in soft-
ware, protocol processing time coupled with possible
network delay between multiple hops of IP gateways
may greatly affect cell switching latency.
Third, each physical cell administered by an \IsG
is in principle assigned an IP network address because
every MH and intermediate gateway is a network en-
tity in TCP/IP environments. It means that locating
the MH in a different physical cell necessitates a differ-
ent network address to represent its current location.
Some undesirable features of IP-level mobile host pro-
tocols essentially comes from this fact. VIP requires a
large amount of the transient IP address space which
becomes a very scare network resource as internets are
rapidly growing. IPIP uses one permanent IP address
for each MH but relys on the broadcast inquiry among
\I'Gs when the location information is not available
by a forwarding pointer, restricting the scalability of
IPIP to a local area.
Fourth, although IP-level mobile host protocols
based on options keep the compatibility with the con-
ventional IP protocol in their specifications, in a prac-
tical sense they may interfere with it because most
existing fixed hosts and intermediate gateways do not
implement the IP options and their implementations
to support the IP options may not feasible in the near
future. In addition, the current efforts to provide IP
multicasting protocols and connection-oriented proto-
cols require IP-level mobile host protocols to be com-
patible.
As high-speed, connectionless, packet-switched net-
works are emerging to extend LAN-like performance
across a wide area, we believe that they can greatly
affect the support of host mobility in mobile computer
communications. Examples are ATM networks[13][14]
and Switched Multimegabit Data Services(, ll)S)
] i- ..,- .'i] I[)] which are subnetworks providing an
MAC service across a wide area in a large intercon-
nected network. To take advantage of these networks,
it is desirable to push the interconnection level of base
stations (BSs) down to the data link layer, supporting
host mobility in a distributed fashion. In Section 2, we
explains the virtual cell concept to solve the problems
of supporting host mobility at the IP layer. The vir-






















Mobile Base Base Mobile
Host Station Station Host


Figure 1: The Virtual Cell Concept


tual cell architecture is described in Section 3. Section
4 gives the structure of the distributed hierarchical lo-
cation information, the detailed procedures of VCP,
and the outline of the VCP implementation. The com-
parison of VCP with existing protocols and discussion
are given in Section 5, and we conclude with future
works in Section 6.



2 Virtual Cell Concept

Consider the transmission of IP datagrams between
two MHs within a physical cell. Because radio links
provide the broadcast ability, the source can deliver
IP datagrams to the destination using the normal Ad-
dress Resolution Protocol (ARP) protocol. Thus, the
broadcast ability of radio links itself eliminates the
necessity of locating MHs, resulting in no mobility
management protocols at the IP layer and no mod-
ifications to the normal ARP protocol. To apply the
similar rationale to MHs crossing physical cell bound-
ary, we propose the virtual cell concept, as depicted in
Figure 1.
A virtual cell is a logically extended cell of physical
cells whose BSs are implemented by remote bridges
and interconnected via a base station network. Be-
cause remote bridge BSs enable to preserve the inter-
connection level of physical cells at the data link layer,
the whole virtual cell is assigned an IP network ad-
dress. In order to make it possible for MHs in a virtual
cell to directly deliver IP datagrams using the conven-
tional IP and ARP protocols, a mobility management
protocol, called Virtual Cell Protocol (VCP), is im-
plemented at the data link layer of BSs. Each virtual
cell is also allocated an ARP/Location server (ALS)
which implements VCP and supports the normal gate-
way function with other virtual cells or fixed networks.
VCP supports handover, address resolution, and loca-
tion tracking for datagram delivery, based on the dis-


A fixed host or a mobile host
in a different network

ALS B ALS A ALS C
E=F


The migration path of MH1
---- The data path when MH1 is in
the virtual cell B
-- The data path when MH1 is in
the virtual cell C


Virtual Cell A

Virtual Cell B

Virtual CellC

Figure 2: The Data Path Between Virtual Cells


tribute hierarchical location information of BSs and
the ALS, as described in detail in Section 4.
It should be noted that the identification and loca-
tion information of an MH is represented by two differ-
ent data link layer addresses in the virtual cell, Radio
network MAC (RMAC) address and Base station net-
work MAC (BMAC) address, respectively. Note that
the BMAC address is not only used as the location
information of the MH but also as the identification
information of a virtual cell. For example, the '1I 1)S
addresses can be formatted with a similar structure
used for the North American Numbering Plan to rep-
resent the geographic semantics. This separation elim-
inates the necessity of acquiring a temporary address
to represent the MH's current location as it migrates.
In addition, unlike IP-level mobile host protocols, the
IP network address also represents the correct loca-
tion information of the MH while it moves to a dif-
ferent physical cell in the virtual cell. This is possible
because the whole virtual cell is assigned an IP net-
work address and host mobility is shielded from the
IP layer.
Even when the MH migrates between virtual cells,
the IP network address is still valid as the near-
location information in the virtual cell environment.
Figure 2 shows the data path from a fixed host or
an MH in a different network to MH1 which migrates
from its native virtual cell A to virtual cell B to virtual
cell C. Whenever MH1 crosses the boundary of vir-
tual cells, a one-hop forwarding pointer is maintained
from ALSA in its native virtual cell to the ALS of its
current virtual cell, ALSB or ALSc, by the handover
procedure of VCP. Note that the forwarding pointer is
not maintained at the IP layer but at the VCP layer.
When a fixed host or an MH in a different network
wants to send an IP datagram to MH1 in virtual cell
B or C, the existing routing protocols of the IP layer
correctly deliver it to ALSA. Then ALSA redirects











it at the VCP layer to the corresponding ALS, ALSB
or ALSc, which keeps track of the exact location of
MH1 in its virtual cell.
Thus, every MH resides in its native virtual cell
from the IP layer's viewpoint but practically may re-
side in an adjacent virtual cell because of a one-hop
forwarding pointer from the native virtual cell to the
current virtual cell maintained at the VCP layer. It
means that the combination of the existing routing
protocols of the IP layer and the forwarding pointer
between virtual cells at the VCP layer gives the same
effect that we have a fully duplicated location informa-
tion among virtual cells for the global mobile network.
To configure neighboring and geographically dis-
tributed physical cells into virtual cells, the underly-
ing transport network should provide high-speed data-
gram packet-switched services and the group address-
ing capability at the data link layer. The flexible con-
figuration allows network managers and designers to
customize the logical coverage area of the virtual cell
to their requirements according to host mobility and
data traffic patterns among physical cells.
Consider an environment that a number of physical
cells are deployed in a metropolitan area. The cell size
in the urban area is usually smaller than that in the
suburban area in order to accommodate a larger pop-
ulation of mobile users. Even though user mobility is
inherently unpredictable, there could be a high possi-
bility that the daily routine of mobile users is usually
confined to several physical cells in the urban area.
Because of a relatively small cell and large population
of mobile users in the urban area, it becomes very
important to achieve the fast location tracking of mo-
bile users and the small cell switching latency between
physical cells, mitigating the effect of a large volume
of mobility management information. Thus, the phys-
ical cells covering the urban area could be combined
into one or a few number of virtual cell(s) for efficient
mobility management and data delivery. As another
example, we can consider a campus environment con-
sisting of several campuses that are geographically dis-
tant. In order to handle both of the intracampus and
intercampus traffic efficiently, the physical cells cover-
ing these campuses can be combined into a virtual cell
in spite of their distance. The same rationale can be
also applied to a business environment where a num-
ber of distant companies belong to one organization.


3 Virtual Cell Architecture

Because the virtual cell is a logical concept, the
same transport network may support several virtual


Fixed Networks Fixed Networks


Figure 3: The Virtual Cell Architecture


cells simultaneously. As shown in Figure 3, there are
two roles of the transport network: base station net-
work and backbone network. The base station net-
work is used to interconnect a number of BSs and an
ALS to build a virtual cell, and the backbone net-
work is used to interconnect among virtual cells and
fixed networks. Note that the base station network
utilizes both point-to-point and multicast communi-
cations, while the backbone network does only point-
to-point communication.

3.1 Base Station Network

The base station network should meet some require-
ments from two different viewpoints:

Application's viewpoint. IP operates under the
assumption that packet arrivals are independent
and unpredictable. If IP is coupled with the
connection-oriented base station network, one
connection establishment and release may be
needed for each individual packet over a fixed
link between a pair of BSs. Although a bundle
of packets could be transmitted over one con-
nection by some multiplexing techniques, when
communicating MHs migrate to different physical
cells with the connection, the problem becomes
complex and even intractable. In addition, be-
cause location tracking has inherently connection-
less properties, the base station network should
support the datagram delivery. The current ubiq-
uitous coverage of TCP/IP networks and applica-
tions also requires that the base station network
be able to cover a wide area.

Mobility management's viewpoint. Combined
with the distributed location information of MHs
among BSs, host mobility is a main cause of the




























Physical Cell Base Station Network

Figure 4: The Base Station Architecture


inconsistency. In order to maintain the consis-
tency of the distributed location information effi-
ciently, the base station network should support
the multicast ability. Furthermore, because the
network control information for mobility manage-
ment is expected to be greatly increased as the
cell size becomes smaller, the base station net-
work should have high-bandwidth not so as to
affect the normal data traffic greatly.

We consider \ II)S as an example with these char-
acteristics. Both individual and group addressing ca-
pabilities combined with a set of addressing-related
service features (e.g., source address validation, source
and destination address screening) enables to create
a number of logical networks over \I I)S. Every BS
and ALS is attached to a Subscriber Network Interface
(SNI) and individually addressed. At the same time,
a group address identifies all BSs in a virtual cell, en-
suring that each group address identifies uniquely only
one set of individual addresses. The number of SNIs
to be supported by a switching system is at least '_".
SNIs and the future number is up to 4096 SNIs within
a Local Access Transport Area. Considering that the
range of a physical cell is usually 3-5 km in the urban
area or 10-15 km in the suburban area, the capacity
of a very few number of switching systems may be
enough to support base station networking within a
metropolitan area.

3.2 Base Station

The communication architecture in a BS is shown
in Figure 4. The internal port connected to a physical
cell implements an RMAC entity, while the external


port connected to the base station network implements
a BMAC entity. The MAC relay entity translates the
information format between the physical cell and the
base station network. The protocol identifier field of
both the RMAC and BMAC frame headers is set for
LLC type 1 Unnumbered Information format. For ex-
ample, the Higher Layer Protocol Identifier field of
the \ II)S Interface Protocol L3_PDU used as BMAC
frames is set to 1. The LLC Service Access Point of
the RMAC frame is set for Subnetwork Access Proto-
col (SNAP), while that of the BMAC frame is set for
VCP.
The VCP header has three fields: VCP type, VCP
length, and RMAC address. The VCP type is set to
one of ADDRESS, DATA and HANDOVER to spec-
ify the address resolution, data transfer and handover
modules of VCP, respectively. Depending on the VCP
type, the information field of the VCP frame has a
different format. The DATA type indicates that the
information field has an IP datagram, and the informa-
tion fields for the HANDOVER and ADDRESS types
are given in the next section. The VCP length indi-
cates the length of the VCP header. Note that the
RMAC address is only used with the DATA type.
Each BS maintains a partial location information
of the virtual cell in its Internal Membership Table
(IMT) and External Membership Table (EMT). IMT
keeps track of all MHs currently roaming in its physical
cell. The IMT entry for an MH has two fields, the IP
and RMAC addresses, each of which is used as an iden-
tifier but has a different role. The IP address is used
as an identifier by the higher network layers as usual,
but the network part of the IP address represents the
MH's native virtual cell to which it initially belongs.
This IP address obtained by the handover procedure
is only needed for fast address resolution, as described
in the next section. On the other hand, the RMAC
address is the other identifier used by VCP for the
support of host mobility at the data link layer. EMT
has a relatively small number of entries for MHs roam-
ing in different physical cells of the same virtual cell.
The EMT entry for an MH has three fields, the IP,
RMAC and BMAC addresses, respectively, of which
the BMAC address represents the MH's current net-
work address.
If the source MH wants to send an IP packet to the
destination MH whose native virtual cell is the same,
the source performs ARP and sends the IP packet
using the destination RMAC address. On the other
hand, if the source wants to send an IP packet to
the destination whose native virtual cell is different,
the source does not perform ARP and sends the IP












Kouung ivioaule IP layer


Global Membership
Table (GMT)
SVCP layer
Virtual Cell Protocol
(VCP)


Base Station Backbone MAC layer
Network Network


Figure 5: The Communication Architecture in an
ARP/Location Server


packet using the RMAC address of its current BS,
which is obtained by a beacon message. When the BS
receives an SNAP/LLC/RMAC frame from the inter-
nal port, it checks the Protocol Identification (PID)
field of the SNAP header. If the PID field is set for
ARP, the ARP packet is sent to the address reso-
lution module which performs Virtual Cell Address
Resolution Protocol (VCARP). VCARP achieves the
IP-to-RMAC address binding for the destination and
also distributes the location information of the source
and destination. If the PID field is set for IP, the
IP packet is sent to the data transfer module with
the destination RMAC address. If the destination
RMAC address is the BS's RMAC address, the data
transfer module sets the RMAC address field of the
VCP header to the BS's RMAC address and relays a
VCP/LLC/BMAC frame to the ALS without search-
ing IMT and EMT. Otherwise, the data transfer mod-
ule keeps track of the destination MH's current loca-
tion using IMT and EMT. If the corresponding entry is
not found, the data transfer module transmits to the
ALS a VCP/LLC/BMAC frame whose VCP header
contains the destination RMAC address.

3.3 ARP/Location Server

Each ALS maintains Global Membership Table
(C \I 1') for MHs roaming in its virtual cell, as shown
in Figure 5. The entry format of C \I is the same
as that of EMT. There are two types of frames from
the backbone network for data transfer. One is the
VCP/LLC/BMAC frame redirected from other virtual
cells that maintain one-hop forwarding pointers at the
VCP layer, and the other is the SNAP/LLC/BMAC
frame from fixed networks or other virtual cells. The
first type of frame is sent to the data transfer mod-


ule which identifies the destination BS by searching
C \I 1 with the RMAC address of the VCP header,
and transmits it to the base station network. The
second type of frame is, however, directly sent to the
routing module which extracts the IP packet. If the
network part of the destination IP address indicates
the same virtual cell, the packet is sent to the data
transfer module of VCP where the IP-to-RMAC ad-
dress binding occurs and a VCP/LLC/BMAC frame
is transmitted to the base station network or to the
backbone network, depending on whether the destina-
tion MH resides in this native virtual cell or moved to
another virtual cell, respectively. If the IP packet is in
transit, it is transmitted to the next-hop router.
The VCP/LLC/BMAC frame from the base sta-
tion network is always sent to the VCP module. If the
frame carries a VCARP packet, the address resolu-
tion module performs the IP-to-RMAC address bind-
ing with C \1 1 and sends it back to the base station
network. If the frame carries an IP packet with a
BS's RMAC address of the virtual cell in the VCP
header, the data transfer module dose not search C1 \ I'
and directly pass the IP packet to the routing mod-
ule where the next-hop router is determined. Other-
wise, the data transfer module searches C \I1' with
the destination RMAC address and then transmits
a VCP/LLC/BMAC frame back to the base station
network or to an adjacent virtual cell following a for-
warding pointer. At the same time, if the destination
MH resides in this virtual cell, the ALS sends to the
source BS a VCARP reply which conveys the desti-
nation BMAC address so that the subsequent data
transfer can directly go to the destination BS.


4 Virtual Cell Protocol

4.1 Distributed Location Information

There are generally three different ways to dis-
tribute location information: centralized, partitioned,
and duplicated. Depending on which way is used to
treat location information, there is a tradeoff between
location registration and paging. In a centralized sys-
tem, a large volume of location updates at one physi-
cal site may degrade the network performance signif-
icantly. However, the consistency of location infor-
mation is obtained and simple paging is achieved. A
typical example is the first generation of mobile cel-
lular telephone systems. In a partitioned system, the
different partitions of location information are held at
different sites. An example is IPIP where every BS
maintains its local location information and paging is












'"A Conceptuall'y"
S Centralied
'.Location Serverv,'
Virtual Cell A ,-- --.. Virtual Cell B


MH1 MH4
BSMH4


BS BS MH3


BS2 MH2


SX Message transfer failure
Short message latency
----- Long message latency
----..... Movement of a MH


BS1 BS2


BSn BS1 BS2 BSm


Figure 6: The Distributed Location Information in a
Virtual Cell


basically required when two remote physical cells are
involved in communication unless a forwarding pointer
is found. Thus, this approach can alleviate the prob-
lem of location registration in the centralized system,
but may need frequent paging. In a duplicated sys-
tem, on the other hand, the same location informa-
tion is held at the different sites. VIP is an example
where the location information of an MH is held on
several intermediate gateways. Although it can give
an optimal routing path in the normal case, when a
communicating MH migrates, the inconsistent loca-
tion information may be spread over several interme-
diate gateways.
In order to support mobility management in a dis-
tributed manner, the virtual cell takes advantage of
the distributed hierarchical location information which
involves a combination of partitioning, duplication,
and centralization, as shown in Figure 6. \I 1' is
partitioned between virtual cells. On the other hand,
IMT is partitioned with other IMTs and duplicated
with C;\I 1 in a virtual cell. EMT partially dupli-
cates a part of ;\ I' for MHs in different physical
cells in the same virtual cell so that address resolution
and location tracking for data transfer are first tried
to accomplish among BSs independent of the ALS.
Thus, C \ 11 is only referred in case that they cannot
be solved among BSs.
It should be noted that there is another conceptual
hierarchy above the C \I level. When MH1 migrates
from its native virtual cell A to virtual cell B, forward-
ing pointers are maintained from ALSA to ALSB to
the current BS at the VCP layer. ;From the prospec-
tive of the IP layer, however, MH1 is regarded as if
it were in its native virtual cell. Thus, when a re-
mote fixed host or an MH in a third network wants to
send a packet to MH1, the existing routing protocols
of the IP layer correctly deliver the packet to ALSA.
Then ALSA traces MH1 using the forwarding point-
ers. Therefore, the IP network address of a migrating


Figure 7: An Example of the Inconsistency Problem


MH represents at least the near-location information
of the MH, and when coupled with the existing rout-
ing protocols of the IP layer it can give the same effect
that we maintain a conceptually centralized server for
the whole mobile network. If MH1 migrates within a
virtual cell, the IP network address of MH1 gives the
exact location information.

4.2 Impact of Mobility

The location registration due to the handover pro-
cedure is a main source of inconsistent location in-
formation. To achieve the consistency of distributed
information is not trivial at all and many researchers
have been working on this problem in fixed network
environments[15, 16, 17]. In the virtual cell environ-
ment, however, host mobility is integrated with fixed
networks, which makes the problem even more com-
plex. To solve this problem, the handover procedure
should utilize the multicasting ability of the base sta-
tion network.
Assuming that the distributed location information
is initially consistent, consider that MH1 moves from
BS4 to BSI which periodically broadcasts its identity,
as shown in the Figure 7. When MH1 receives a bea-
con packet, it sends a greeting message containing its
identity to BS1. BS1 detects the entry of MH1 to
its local cell, deletes its corresponding EMT entry if
exists, and inserts a new IMT entry. Then, BS1 mul-
ticasts a location registration message to every BS so
that it maintains the consistent location information
for MH1. However, some BSs may fail to receive the
message due to communication errors and buffer over-
flows. The long propagation delay also has the similar
effect as the message loss at a point in time due to mo-
bility. To explore a practical solution, we should be-
gin with the assumption that the base station network
supports the atomic multicasting by using an existing
protocol such as the Trans protocol[17]. The basic idea
of the Trans protocol is that acknowledgements for
multicast messages are piggybacked on messages that











are themselves multicast, using a combination of pos-
itive and negative acknowledgement strategies. This
piggyback feature is suitable for the handover proce-
dure because in the steady state, if some MHs move
out then there will be a high possibility that other
MHs move in.
Note that although the atomic multicast is sup-
ported, the message loss can still occur if BSI multi-
casts the location registration message. Assume that
BS3 failed to receive it and BS4 received it with a
long message latency. Then, the following four cases
can happen when other MHs transmit a message to
MH1 during the process of the atomic multicast:

1. If BS4 has the old location information for MH1,
the message transmitted from MH4 to MH1 will
be lost.

2. If BS4 has the new location information for MH1,
the message transmitted from MH4 to MH1 will
be received.

3. Because BS3 has the old location information
for MH1, the message transmitted from MH3 to
MH1 will be lost or received, depending on what
value BS4 has. If it has the old value, the mes-
sage will be lost. Otherwise, the message will be
redirected to BS1 by BS4.

4. Because BS2 has the new location information
for MH1, the message transmitted from MH2 to
MH1 will be received.

tFrom the above observation, we can see that at
least the previous base station BS4 must have the new
location information for MH1 as soon as possible in
order to avoid a possible message loss or to mitigate
the effect of long message latency.

4.3 Handover Procedure

The new BS informs the previous BS of an MH's
migration using point-to-point communication imme-
diately after detecting the MH's identity so that all
messages received at the previous BS during the han-
dover procedure can be correctly redirected to the new
BS. Next, the previous BS is responsible for maintain-
ing the consistency of the MH's location information
at all BSs using an atomic multicasting. Note that
the ALS is excluded from the multicasting group. If
the ALS is involved, every movement of the MH will
need an access to the ALS and there is no difference
from the centralized system. However, it may cause
another inconsistency problem between the ALS and


Figure 8: A Communication Model for the Handover
Procedure


BSs because the ALS may have old location informa-
tion for some MHs. Thus, the previous BS periodi-
cally backups the location information updated dur-
ing a predefined time interval to the ALS using point-
to-point communication. When an MH continues to
move to different physical cells, there can be a redi-
rection chain with multiple hops from the first BS to
the current BS. However, the chain is eliminated when
the newest location information is received through an
atomic multicasting.
Figure 8 shows a communication model for the han-
dover procedure. For convenient description, we define
the following notations where the VCP header infor-
mation is omitted:

A = B, .., N : {frame} implies that A multi-
casts {frame} to B,..., N over the base station
network, where {frame} consists of {source ad-
dress, destination address | frame data}.

A -- B : {frame} implies that A sends {frame}
to B via a point-to-point link.

A B : {frame} implies that A broadcasts
{frame} whose destination is B via radio links.

IP(A) implies the IP address of an MH A.

RMAC(A) implies the radio MAC address of A,
where A may be a BS or an MH.

BMAC(A) implies the address of A in the base
station network (BMAC), where A may be a BS
or an ALS.

Within a virtual cell. Consider that MHa moves
from BS2x to BSx,. In addition to its own addresses,
IP(MHa) and RMAC(MHa), MH, initially keeps
the current base station addresses, RMAC(BS2,) and
BMAC(BS2,).
1. BSnx MHa : {RMAC(BSUn), broadcast address
BMAC(BSu)}


I EMT 'TEEMTJ "Y M EMT
t -0 ------------ MY MT
........... .... --------------------


~












MHa receives a beacon including BMAC(BSUn) from
BSx., decides to switch from BS2x to BSnx, and up-
dates its base station address from RMAC(BS2x) and
BMAC(BS21) to RMAC(BSUn) and BMAC(BSUn), re-
spectively.
2. MHta BSnx : {RMAC(MHa), RMAC(BS,) I
IP(MHa), BMAC(BS2x)}
BSnx receiving a greeting message from MHa processes
its IMT and EMT using the source address RMAC(MHa)
as a key. If the EMT entry for MHa is found, the en-
try is deleted and then the IMT entry for MHa is added.
IP(MHa) in the EMT entry is used for fast address reso-
lution, as described in the VCARP section later.
3. BSn BS2x : {BMAC(BSnx), BMAC(BS2x)
IP(MHa), RMAC(MHa), BMAC(BSn)}
BS2x receiving the notification of MHa's migration sends
an acknowledgement to BSnx and then processes IMT and
EMT. The IMT entry for MHa is deleted and the new
EMT entry for MHa is added.
4. BS2x = BS1x,...,BSnx : {BMAC(BS2x), multicast
address I IP(MHa), RMAC(MHa), BMAC(BSUn)}
Every BS receiving the notification of MHa's migration
except BSn, processes its EMT. If the EMT entry for
MHa already exist, the entry is updated.
Between virtual cells. Consider that MHa moves
from BS., to BS1y. In addition to its own ad-
dresses, IP(MHa) and RMAC(MHa), MHa keeps
the current base station addresses, RMAC(BSnx) and
BMAC(BS, ).
1. BS1y MHa : {RMAC(BSly), broadcast address
BMAC(BS1y)}
2. MHa t BSy : {RMAC(MHa), RMAC(BSiy)
IP(MHa), BMAC(BSn)})
BS1y receiving a greeting message from MHa detects
from the previous base station address BMAC(BSx)
that MHa was in another virtual cell. BSly creates the
IMT entry for MHa.
3. BSIy ALSy : {BMAC(BS1y), BMAC(ALSy) I
IP(MHa), RMAC(MHa), BMAC(BSly),
BMAC(BSu,)}
ALSy receiving a location registration message creates the
GMT entry for MHa using IP(MHa), RMAC(MHa),
and BMAC(BSiy). Then, ALSy knows that BSn is
a base station in virtual cell X, using BMAC(BSUn).
4. ALSy ALSx : {BMAC(ALSy), BMAC(ALSx)
IP(MHa), RMAC(MHa), BMAC(ALSy),
BMAC(BSn)}
ALSx receiving a location registration message updates
the GMT entry for MHa using IP(MHa), RMAC(MHa),
and BMAC(ALSy). This entry serves as a forwarding
pointer at the VCP layer if ALSx is the ALS of MHa's
native virtual cell. If it is not, ALSx informs the ALS of
MHa's native virtual cell of MHa's migration to virtual
cell Y so that a forwarding pointer is maintained from
MHa's native virtual cell to virtual cell Y.
5. ALSx -- BSn : {BMAC(ALSx), BMAC(BSx)
IP(MHa), RMAC(MHa), BMAC(ALSx)}
BSn receiving the notification of MHa's migration sends
an acknowledgement to BSly in the reverse direction
and then processes IMT and EMT. The existing IMT


entry is deleted and an EMT entry using IP(MHa),
RMAC(MHa), and BMAC(ALSx) is added.
6. BSn => BS1x,BS2x,...,BS(n,_1) : {BMAC(BSun),
multicast address IP(MHa), RMAC(MHa),
BMAC(ALSx)}
Every BS receiving the notification of MHa's migration
except BS-, manipulates its EMT. If the EMT entry ex-
ists, it is updated.

4.4 Address Resolution

VCARP is designed to get the physical address of
the MH in a remote physical cell of the virtual cell
and should satisfy at least the following three require-
ments. First, in order to achieve the compatibility
with ARP, VCARP must be shielded from MHs as
if they were in a physical cell. Second, because the
VCARP packet latency can directly affect the scala-
bility of a virtual cell, a distributed address resolution
mechanism should be considered rather than broad-
casting or a centralized solution. Third, when an MH
moves to an adjacent physical cell immediately after
sending an ARP request and further moves to another
physical cell, the ARP reply may be lost and then the
ARP request may be repeatedly generated. Hence,
VCARP must also support host mobility.
Figure 9 shows the ARP/VCARP packet format.
The ARP packet follows exactly the same format
as the existing ARP standard and has longer fields
SENDER HA and TARGET HA in order to make it
possible to accommodate the use of hierarchical 64-
bit E.164 network addresses in radio networks. The
VCARP packet format has an additional 64-bit field
BASE HA which is used to convey the location infor-
mation which is expected to be used for data trans-
fer in the very near future. The source MH performs
ARPing only when it resides in its native virtual cell
and the destination MH belongs to the same native
virtual cell. Otherwise, it directly transmits IP pack-
ets without ARPing.

Within a physical cell. The procedure is the same
as in the normal ARP. The same ARP request/reply
packet formats are used where an 8-bit hardware ad-
dress length field allows to accommodate arbitrary ra-
dio network addresses. The IP protocol of the source
MH checks the destination IP address with its address
resolution table. If the address binding is successful,
the source MH uses the RMAC address to transfers
datagrams. Otherwise, the source MH broadcasts an
ARP request. As soon as the destination MH receives
the ARP request, it responds with an ARP reply that
includes the requested physical address of the destina-
tion. At the same time, the BS that received the ARP












0 8 16 24 31
HARDWARE TYPE PROTOCOL TYPE
HLEN PLEN OPERATION
SENDER HA (octects 0-3)
SENDER HA (octects 4-7) ARP
SENDER IP (octects 0-3)
TARGET HA (octects 0-3)
TARGET HA (octects 4-7)
TARGET IP (octects 0-3)
BASE HA (octects 0-3) V R
--- -- --- -- -- --- -- --- -- -- --- -- --- -- -- V C A R P
BASE HA (octects 4-7) message format


Figure 9: The ARP/VCARP Packet Format

fMobileHost BaseStation LARPLocatlon Base Station Mobile Host

ARP request
ARP reply


VCARP reply


Datagram transfer


ARP reply


(a) The case that base station 1 resolves the address binding


ARP request
VCARP request
VCARP reply
ARP reply i i VCARPreply
SARP reply
Datagranm transfer

(b) The case that the ALS resolves the address binding

Figure 10: The VCARP Flow Diagram


request searches IMT and knows that the destination
MH is in the local physical cell so it discards the ARP
request.


Within a virtual cell. Figure 10(a) shows the flow
of messages when MH1 broadcasts an ARP request
to get the physical address of MH2 and it is resolved
at BS1. BS1 that received the ARP request searches
its EMT. The EMT entry for MH2 already contains
its physical address and BS1 directly sends an ARP
reply within the physical cell. At the same time, BS1
sends a VCARP reply to BS2. Then, BS2 transforms
the format of the VCARP reply to that of the ARP
reply by stripping out the field BASE HA and broad-
casts the transformed ARP reply in its local cell. This
VCARP reply also conveys the location information
of MH1 to BS2 through the field BASE HA which


contains the network address of BS1. Then, BS2 cre-
ates an EMT entry so that MH2 can directly transmit
data to MH1 without any additional address resolu-
tion in the near future communication. It is based on
the observation that computer communication is usu-
ally bidirectional; if MH1 has some reason to talk to
MH2, then MH2 will probably have some reason to
talk to MH1.
Figure 10(b) shows the flow of messages when the
address resolution is accomplished at the ALS. BS1
sends a VCARP request to the ALS because it has
no entry for MH2. Then, the ALS sends a VCARP
reply to BS1 after resolving MH2's address binding
using C \I '. At the same time, the ALS also sends
BS2 a VCARP reply with the same reason as in the
above case. The location information of MH1 and
MH2 is also conveyed via both VCARP replys to es-
tablish a logical bidirectional link between them. Now
we describe the support of host mobility in VCARP.
Consider the case that MH1 requested an address res-
olution to send datagrams to MH2 and then moved to
a third BS, before the VCARP reply is arrived. By
the handover procedure, BS1 knows that MH1 cur-
rently belongs to BSn. As soon as BS1 receives the
VCARP reply, it redirects the packet to BS,.

4.5 Data Transfer

For the transmission of packets between virtual cells
and fixed networks, we have already described in the
previous sections. This section deals with the packet
transmission within a physical cell and within a vir-
tual cell. Let BSij denote the i-th BS of virtual cell
j in Figure 6, where i = 1,...,n when j = A and
i = 1, ..., m when j = B. We assume that MHij be-
longs to BSij and M, initially belongs to BS1A. We
also assume that the address binding is achieved by
VCARP.

Within a physical cell. Consider the case that
MH1A wants to send a packet to MH,. By the ad-
dress resolution protocol, MH1A knows the RMAC
address of MH, and directly broadcasts the packet to
it. BS1A knows that MH, resides in its physical cell
by checking IMT using the RMAC address of MH, as
a key, and discards the received packet.

Within a virtual cell. Consider the case that MH,
moves from BS1A to BS2A and each of MH1A, MH2A,
and MHA wants to send a packet to MH,. By the
handover procedure, a forwarding pointer is set from
BS1A to BS2A at the EMT entry of BS1A and the
packet from MH1A is correctly delivered to MH, by












the forwarding pointer. The packet from MH2A is di-
rectly delivered to MH, and BS2A discards it because
the IMT entry for MH, is found. The delivery of the
packet from MHA has three cases. If the EMT en-
try for MH, is found before the completion of BS1A '
multicasting operation, the packet will be delivered to
BS2A via BS1A. If the EMT entry is found after the
completion of its multicasting operation, the packet
will be directly delivered to BS2A. If the EMT entry
is not found, the first packet from MHA will be de-
livered to BS2A through the ALS. At the same time,
the ALS generates a VCARP reply in order to have
BSA learn that MH, is currently belongs to BS2A.
It makes it possible to directly transfer the subsequent
packets following the first one to BS2A without going
through the ALS repeatedly.

4.6 VCP Implementation

The virtual cell is implemented as a distributed ap-
plication that uses TCP/IP as a transport mechanism.
There are five types of distributed network component
processes, each of which corresponds to a network en-
tity in the virtual cell: mobile host process, physical
cell process, base station process, base station network
process, and ARP/Location server process. The phys-
ical cell process simulates the broadcast ability of a
physical cell while the base station network process
simulates a full mesh of logical point-to-point links
with the multicast ability. Both are implemented as
servers and the other processes are implemented as
clients. The mobility and data traffic are generated at
the mobile host process. When a client process is initi-
ated, the user defines a simulated IP address, the des-
tination machine and protocol port number of the cor-
responding server processess. Because the socket ad-
dress structure contains an internet address and a pro-
tocol port number to identify a communication end-
point between a TCP connection, the port number> pair is used as an RMAC or BMAC
address of a client process. The purpose of this imple-
mentation is to demonstrate the correct operation of
VCP and measure data including the protocol process-
ing time of the VCP layer at a BS and an ALS, which
will be used as parameters to a performance model for
the virtual cell in the future research.



5 Comparison and Discussion

Figure 11 summarizes the characteristics of the vir-
tual cell and compares with IPIP and VIP. The fig-
ure also includes Cellular Packet Switch (CPS)[7, 8]


^etworks p eS vCp
IPIP VIP CPS VCP
Target Applications TCP/IP applications TCP/IP application packetedvoice TCP/IP applications
and data services
Target environment campus area wide area metropolitan area wide area
point-to-point point-to-point packet-switched
comiectlonless net
Base station networks physical inks physical links DQDB MAN oth multcast alit
(Internet) (Internet) (SMDS)
Mobility support layer network layer network layer data link layer data link layer
Type of movement mobility portability mobility mobility
mobility
Type of packet switching datagram datagram virtual circuit datagram
Address resolution Proxy ARP address mapping no VCARP
Scalability low high high high
Cell coverage area physically bounded physically bounded physically bounded logically flexible


Figure 11: Comparisons of the Virtual Cell With
Other Networks


which is designed for digitized voice and data services
in personal communications. The basic idea of CPS is
to interconnect BSs with high-bandwidth Metropoli-
tan Area Networks based on the IEEE 802.6 standard
and support mobility using the virtual circuit packet-
switching technique.
When considering the ubiquitous coverage of
TCP/IP networks and applications, the virtual cell
has several advantages against IP-level mobile host
protocols. Because the virtual cell uses a underlying
datagram network to interconnect BSs and to form
flexible coverage, the difficulties arising from diverse
underlying networks can be avoided in terms of the
performance of mobility management function and the
complexity of network management function. More-
over, because the virtual cell is a logical cell and the
bridge function is usually much faster than the gate-
way function, it is possible to increase performance
significantly if we can properly engineer the deploy-
ment of virtual cells so that the intra virtual cell traffic
is as much larger than the inter virtual cell traffic as
possible. Preserving the interconnection level of BSs
at the data link layer also makes it possible to shield
host mobility from the IP layer, and using the base
station network address as a contact point of an MH
makes it possible to avoid acquiring a temporary ad-
dress by some kind of local utilities whenever the MH
migrates. Thus, the problems of interfering with the
conventional IP layer and of reserving a large amount
of IP address space for location information can be
solved.
There are two major issues related to the perfor-
mance of VCP. Within a virtual cell, a BS first tries
to perform address resolution and data transfer locally
without the intervention of the ALS, based on its two












membership tables, IMT and EMT. Thus, the hit ra-
tio of the EMT search directly affect the degree of
referring to the ALS when remote MHs in different
physical cells are involved in communication. This is-
sue directly addresses the size and update scheme of
EMT and also closely related to the IP traffic and host
mobility pattern. A number of research results on the
internet protocol traffic analysis in fixed network envi-
ronment reveals that certain hosts communicate more
with one another than with other hosts[19, 20, 21].
Even in the virtual cell environment, the locality of
destination hosts can give an important implication
for each of the address resolution and data transfer
functions. A small ARP cache at each MH can greatly
reduce VCARP traffic within a virtual cell and then
address resolution should not severely burden the size
of EMT. If we do not consider host mobility, the lo-
cality property also means that data transfer does not
severely burden the size of EMT. When considering
host mobility, the update scheme of EMT could be
rather important if we can properly deploy virtual cells
based on mobility and traffic patterns among physical
cells.
The other issue is the amount of multicast traffic
among BSs, which is generated only by the handover
function of the virtual cell. Because the multicasting
ability is supported by switches in the base station
network, each BS is not related to the load of gener-
ating the multicast traffic, and the bandwidth usage
of the base station network is affected by it. The rela-
tively short length of the handover message should not
severely affect the high-bandwidth base station net-
work. This should be addressed quantitatively based
on mobility models.


6 Conclusion and Future Works

We have presented a new network infrastructure for
the transmission of IP datagrams in mobile computer
communications. With the virtual cell concept, physi-
cal cells are grouped into larger logical cells where host
mobility is shielded from the IP layer. It eliminates
the need of IP-level protocols for host mobility within
a virtual cell and provides the flexible coverage area
that can be properly engineered according to host mo-
bility and data traffic patterns among physical cells.
In order to achieve this concept, we have described
the virtual cell protocol which consists of handover,
address resolution, and data transfer modules, based
on the distributed hierarchical location information.
We are developing a performance model of the virtual
cell to capture protocol processing loads at the base


station and ARP/Location server and scalability in
terms of the number of physical cells. Based on the
analysis, we will deal with how to deploy virtual cells
to minimize the total cost of tracking mobile users in
a given environment.



References

[1] John Ioannidis,Dan Duchamp, and Gerald Q.
Maguire Jr., "IP-based Protocols for Mobile Internet-
working," ACM SIGCOMM'91, pp. 235-245, 1991.

[2] Fumio Teraoka, Yasuhiko Yokote, and Mario Tokoro,
"A Network Architecture Providing Host Migration
Transparency," ACM SIGCOMM'91, pp. 209-220,
1991.

[3] Fumio Teraoka, Kim Claffy, and Mario Tokoro, "De-
sign, Implementation, and Evaluation of Virtual In-
ternet Protocol," IEEE DCS'92, pp. 170-177, 1992.

[4] Charles Perkins and Yakov Rekhter, T. J. Watson
Research center, IBM Corp., "Short-cut Routing for
Mobile Hosts," draft RFC, July 1992.

[5] Charles Perkins and Yakov Rekhter, T. J. Watson
Research center, IBM Corp., "Support for Mobility
with Connectionless Network Layer Protocols," draft
RFC, Jan. 1993.

[6] Hiromi Wada, Tatsuya Ohnishi, and Brian Marsh,
"Packet Forwarding for Mobile Hosts," Matsushita
Corp., draft RFC, Nov. 1992.

[7] David J. Goodman, Gregory P. Pollini, and Kathleen
S. Meier-Hellstern, "Network Control for Wireless
Communications," IEEE Commun. Mag., pp. 116-
124, 1992.

[8] Kathleen S. Meier-Hellstern, Gregory P. Pollini, and
David J. Goodman, "A Wireless Service for the IEEE
802.6 Metropolitan Area Network," IEEE GLOBE-
COM'91, pp. 1964-1968, 1991.

[9] David M. Piscitello and Michael Kramer, "Internet-
working Using Switched Multi-megabit Data Service
in TCP/IP Environments," Computer Networks and
ISDN Systems, pp. 62-71, 1991.

[10] F. R. Dix, M. Kelly, and R. W. Klessig, "Access to
a Public Switched Multi-megabit Data Service Of-
fering," Computer Networks and ISDN Systems, pp.
46-61, 1991.

[11] D. Piscitello and J. Lawrence, "The Transmission of
IP Datagrams over the SMDS Service," RFC 1209,
1991.












[12] George H. Clapp, "LAN Interconnection Across
SMDS," IEEE Network Magazine, pp. 25-32, Septem-
ber 1991.

[13] Masatoshi Kawarasaki and Bijan Jabbari, "B-ISDN
Architecture and Protocol," IEEE J. Select. Areas
Commun., Vol. 9, No. 9, pp. 1405-1415, December
1991.

[14] Jean-Yves Le Boudec, "The Asynchronous Transfer
Mode: a tutorial," Computer Networks and ISDN
Systems, Vol. 24, pp. 279-309, 1992.

[15] Susan B. Davidson, "Consistency in Partitioned Net-
works," ACM Computing Surveys, Vol. 17, No. 3, pp.
341-370, September 1985.

[16] Jo-Mei Chang and N. F. Maxemchuk, "Reliable
Broadcast Protocol," ACM Trans. on Computer Sys-
tems, Vol. 2, No. 3, pp. 251-273, August 1984.

[17] P. M. Melliar-Smith, Louise E. Moser, and Vivek
Agrawala, "Broadcast Protocols for Distributed Sys-
tems", Vol. 1, No. 1, pp. 17-25, 1990.

[18] Samuel Sheng, Anantha Chandrakasan, and R. W.
Brodersen, "A Portable Multimedia Terminal," IEEE
Communications Magazine, pp. 64-75, December
1992.

[19] Andrew Schmidt and Roy Campbell, "Internet Proto-
col Traffic Analysis with Applications for ATM Switch
Design," ACM SIGCOMM'92, pp. 39-52, 1992.

[20] Ramon Caceres, Peter B. Danzig, Sugih Jamin,
and Danny J. Mitzel, "Characteristics of Wide-Area
TCP/IP Conversations," ACM SIGCOMM'91, pp.
101-112, 1991.

[21] K. M. Khalil, J. C. Hand, and M. Mariswamy, "Anal-
ysis and Traffic Characterization of A Wide Area Net-
work," IEEE ICC'93, pp. 1829-1835, 1993.




University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs