[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03
INTERNET DRAFT James Kempf
Category: Informational Sun Microsystems, Inc.
Title: draft-kempf-cdma-appl-01.txt Peter McCann
Date: July 2000 Lucent Technologies
Philip Roberts
Motorola, Inc.
IP Mobility and the CDMA Radio Access Network:
Applicability Statement for Soft Handoff
Status of this Memo
This document is an individual contribution for consideration by the
Mobile IP Working Group of the Internet Engineering Task Force.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Copyright (C) The Internet Society 2000. All Rights Reserved.
Kempf, McCann, Roberts expires January 2001 [Page 1]
INTERNET DRAFT July 2000
Abstract
Recently, there have been a variety of proposals submitted to the
Mobile IP Working Group and to other IETF working groups for IP
mobility solutions that seek to enhance or replace mobile IP. These
proposals, often characterized as micromobility or fast handoff, are
addressed primarily at the perceived need of multimedia sessions such
as video or voice over IP for faster handoff between radio base
stations, and are primarily directed at real time multimedia traffic
in 3rd generation cellular access networks. In this paper, we discuss
the design of CDMA radio access networks (RANs) and the applicability
of IP mobility to soft handoff in a CDMA RAN. We attempt to show that
given current IP routing algorithms and the constraints on a CDMA
RAN, IP mobility solutions have little, if any, role to play in
handoff within the RAN. In contrast, an IP mobility solution is
likely to play a big role in fast handoff between RANs, also called
hard handoff. While future developments in IP networking may change
this situation, IP mobility in CDMA networks currently seems to apply
only when the mobile node roams between disconnected RANs rather than
between base stations within a RAN or between connected RANs.
Table of Contents
1.0 Introduction
2.0 Terminology
3.0 RAN Architecture and Characteristics
4.0 Applicability of IP Mobility to Soft Handoff
5.0 Applicability of IP Mobility to Hard Handoff
6.0 Future Prospects for IP Mobility in the CDMA RAN
7.0 Summary
8.0 References
9.0 Authors' Addresses
10.0 Full Copyright Statement
1.0 Introduction
Mobile IP [1] allows IP hosts that change their point of attachment
to the network to keep their IP address as they change from their
home subnet to other subnets. Recently, there have been a variety of
proposals advanced for augmenting or replacing mobile IP in access
networks for cellular telephony systems. These proposals are often
characterized as supporting micromobility or fast handoff, and are
directed towards real time multimedia streams in 3rd generation
cellular networks (see [2] [3] [4] [5] and [7]).
While these proposals may have some applicability if handoff between
disconnected RANs is very frequent, their utility is lessened in the
Kempf, McCann, Roberts expires January 2001 [Page 2]
INTERNET DRAFT July 2000
presence of RAN mobility like that offered by today's TDMA and CDMA
systems. In fact if the RAN protocols offer transparent mobility
throughout a given domain of interconnected RANs, these proposals do
not contribute anything since they are essentially intra-domain
mobility management protocols. As cellular networks evolve towards
more pervasive IP technologies, host mobility within these networks
must accommodate some level of movement of IP traffic.
In this paper, we discuss CDMA radio access networks and why current
IP mobility solutions (including mobile IP) are not applicable to
soft handoff in a CDMA RAN. In effect, the CDMA RAN network with soft
handoff is a mobility mechanism transparent to L3 and above on the
mobile terminal and its corresponding host, similar to but not
identical with the mechanisms used for interaccess point mobility in
wireless LAN technologies such as IEEE 802.11 [8]. It is therefore
not an appropriate candidate for moving into the network layer given
current IP routing algorithms. In contrast, IP mobility solutions
that are directed at improving handoff performance within the core
network, often called hard handoff, are likely to play an important
role in enhancing the performance of IP networking for CDMA (see [6]
for an example).
2.0 Terminology
mobile terminal
A mobile IP host. In mobile IP terminology, this is called the
mobile node.
base station
A fixed, land-based radio transmitter and receiver, used to provide
cellular telephony radio coverage in a limited geographic area. A
mobile terminal may be in contact with one or more base stations at
a time in CDMA networks. Also called the Base Transceiver Station
(BTS) or Node B.
RAN
The radio access network. This is a wired network that sits between
a collection of base stations and the core, wired telephone
network. The RAN in CDMA systems is involved in real-time
distribution and collection of physical layer radio frames to and
from base stations, a topic that is discussed in the next section.
soft handoff
The process by which a moving CDMA mobile terminal is transferred
between one base station or set of base stations to another within
the radio access network. Soft handoff is typically very fast (on
the order of 20 ms) and has a low probability of dropping ongoing
real time connections.
Kempf, McCann, Roberts expires January 2001 [Page 3]
INTERNET DRAFT July 2000
hard handoff
The process by which a moving mobile terminal is transferred
between one cellular service provider's network and another or
between two RANs that do not share a direct connection within a
provider's network. Hard handoffs have a higher probability of
connection droppage, and are slower (usually 100 ms or more).
macrodiversity
A term used to describe the fact that within the CDMA RAN, there is
no single octet stream corresponding to the data that arrives at or
is sent by the mobile terminal. Macrodiversity results because the
mobile terminal can be in contact with more than one base station
at a time.
frame selector
A combination software/hardware unit at the gateway to the RAN that
combines the multiple octet streams from multiple base stations in
contact with a single mobile terminal into a single octet stream. A
similar process happens at the mobile terminal. Also called the
macrodiversity combiner or Selection and Distribution Unit (SDU).
RAN gateway
A functional unit positioned between the RAN and the core network.
The RAN gateway includes the frame selector, in addition to
functional units that perform soft handoff and radio frame
processing. Also called the Base Station Controller (BSC) or Radio
Network Controller (RNC).
radio frame
A short (usually 20 millisecond) unit of transmission at the
physical radio layer used to transmit data over the air to and from
the mobile terminal. The frames do not usually contain complete IP
packets as sent or received by applications on the mobile terminal,
but rather contain small sections of octet stream data that must be
framed by a higher layer protocol (such as PPP) to form IP packets.
On a basic fundamental data rate channel one radio frame contains
about 20 octets. Radio frames may be retransmitted a small number
of times to increase the reliability of the octet stream transport.
This is performed by a negative- acknowledgement protocol known as
the Radio Link Protocol (RLP).
3.0 RAN Architecture and Characteristics
A RAN consists of a RAN gateway connected to one or more base
stations. In the network to mobile terminal (forward) direction, the
RAN gateway performs the following functions:
Kempf, McCann, Roberts expires January 2001 [Page 4]
INTERNET DRAFT July 2000
1) Receive packets from the core network destined to the mobile
terminal,
2) Process those packets into radio frames,
3) Replicate the radio frames and transmit copies to base stations
that are currently in contact with the mobile terminal in a way
such that the frames arrive at each base station in a timely
fashion,
4) Manage the retransmission of individual radio frames when
negative acknowledgements are received.
In the mobile terminal to network (reverse) direction, the RAN
gateway performs the following functions:
1) Collect copies of the radio frames fowarded by base stations
that are currently in contact with the mobile terminal,
2) Combine these (possibly errorful) copies into one (hopefully
error-free) radio frame using some algorithm,
3) From the resulting radio frame stream, synthesize an outgoing
octet stream of packets for the core network.
In both directions, the RAN gateway performs the following function:
1) Manage the power with which mobile nodes and base stations are
transmitting, so as to maintain a low error rate while at the same
time minimizing the transmitted power and therefore interference
among different transmitters (and drain on the mobile terminal's
battery).
2) In concert with the mobile terminal, manage the set of base
stations with which a mobile terminal is in contact such that the
quality of the radio signal is maintained as the mobile terminal
moves.
The use of multiple base stations to transmit and receive the same
radio frames to and from the mobile node at the same time is known as
"macrodiversity" and can help to improve the reliability of the
wireless link. Note that some of the base stations may be owned by a
neighboring RAN and this necessitates a RAN-to-RAN interface to carry
Kempf, McCann, Roberts expires January 2001 [Page 5]
INTERNET DRAFT July 2000
the radio frames.
The following figure illustrates the architecture and how the CDMA
RAN network works:
Core Network
^
| incoming/outgoing octet stream
| from/to corresponding node
| (e.g. 129.142.68.79)
v
+-----------------------------------------------------+
| RAN Gateway |
| |
| +-------------+ +-----------+ +----------+ |
| | | | | | | |
| | Frame | | Frame | | Soft | |----------->
| | Selection | | Splitting | | Handoff | | to another
| | | | | | Control | | RAN Gateway
| +-------------+ +-----------+ +----------+ | in neighboring
| | RAN
| +---------------+ |
| | | |
| | Radio Frame | |
| | Processing | |
| | | |
| +---------------+ |
| |
+-----------------------------------------------------+
| | | | *
| | | | *
| | ... | | * radio
| | | | * frames
| | | | *
| | | | *
+---------+ +---------+ +---------+ +---------+
| Base | | Base | | Base | | Base |
| Station | | Station | | Station | | Station |
| B1 | | B2 | | B42 | | B43 |
+---------+ +---------+ +---------+ +---------+
\ |
\ V
\--------->
|
-----
/ \
----- ----- 162.42.42.42
Kempf, McCann, Roberts expires January 2001 [Page 6]
INTERNET DRAFT July 2000
| mobile terminal|( --->
------------------
( ) ( )
The links between the RAN gateway and the base stations are typically
point to point links today, though provisions exist in the 3rd
generation standards for switched networks.
In the above figure, a mobile terminal with IP address 162.42.42.42
is corresponding with a host having the IP address 129.142.68.79,
through a CDMA cellular network. The mobile terminal is in contact
with two base stations, B1 and B2. The RAN gateway takes incoming
packets from 129.142.68.79 and splits them into two streams that it
sends to base stations B1 and B2. A mobile terminal can be in
communication with up to 3 and, in some CDMA systems, up to 6 base
stations at a time. When the multiple octet streams are received at
the mobile terminal, the mobile terminal performs a sophisticated
combination of the multiple packet streams at L1 to deliver the end
packet to the application.
Packets flowing in the other direction, from 162.42.42.42 to
129.142.68.79, are put into an octet stream which is then divided
into radio frames. Each radio frame is received by B1 and B2 and
delivered to the frame selector in the RAN gateway. The frame
selector performs signal processing on the incoming radio frames and
produces a single frame that is then sent to the re-sequencing buffer
where the octet stream is re-created. The IP packets are formed from
the octet stream and transmitted into the core IP network.
An important point to note about the RAN is that, even if the RAN
itself is running IP, routing in the RAN does not use the mobile's IP
address. In fact, the IP packets sent by the mobile terminal are not
tunneled through the RAN nor do they necessarily appear in a form
that would be recognizable using a packet sniffer. The packets in the
RAN contain radio frames that have been highly processed into a form
that is extremely efficient for the base stations to handle and that
efficiently uses radio spectrum, including compensations for the
inherently lossy nature of the radio medium.
On the forward leg to the mobile terminal, because the delay and
jitter constraints between multiple base stations transmitting to the
same mobile terminal are so tight (5ms to 80ms), the RAN gateway
essentially puts out streams of radio frames that the base station
can quickly pull off the wire and transmit over the air. On the
reverse leg from the mobile terminal, the base station simply pulls
the radio frames off the air and puts them on the wire without any
further processing. The RAN gateway's radio frame processor is
Kempf, McCann, Roberts expires January 2001 [Page 7]
INTERNET DRAFT July 2000
responsible for making sure that the jitter and delay constraints are
met, and for processing packets from the core network into radio
frames.
When the mobile terminal begins to move out of range of stations B1
and B2, the RAN gateway adds and deletes base stations from the set
currently serving the mobile node. This process is called soft
handoff. Note that new base stations may belong to a connected
neighboring RAN which requires closely-coupled RAN-to-RAN
interaction. The real time constraints on soft handoff are extremely
tight. All base stations involved in soft handoff must transmit the
command for the mobile to move at the same time. North American
cellular networks use the Global Positioning System as a time source
to assure that these timing constraints are met.
As shown in the figure, two RAN gateways can be connected together
through a direct link. This link allows radio frames containing data
and RAN control protocol to flow between two RANs. As a result, two
RANs can perform soft handoff between them, increasing the quality
and reliability of the connection when a user moves between coverage
areas. A RAN gateway and its collection of base stations can only
cover a limited geographic area, so RAN interconnection is very
important in cellular networks for maintaining good connection
quality over large geographic areas.
4.0 Applicability of IP Mobility to Soft Handoff
Most of the proposals for IP mobility in the RAN assume the
following:
1) An end-to-end IP routing model for routing through the RAN.
2) A one-to-one mapping between the mobile terminal and the base
station with which it is in contact.
3) The IP packets coming from the mobile terminal are transported
directly on L2 in the RAN.
As the above discussion has attempted to show, the extremely tight
real time constraints on traffic in the RAN require that RAN traffic
be highly processed as radio frames for efficient delivery into and
from the radio medium by the base stations. This precludes routing IP
packets from the mobile directly over the RAN. Furthermore, because
there are multiple octet streams flowing over the RAN that correspond
to one logical octet stream going to and from the mobile terminal,
there is no one-to-one mapping between the mobile terminal and a base
Kempf, McCann, Roberts expires January 2001 [Page 8]
INTERNET DRAFT July 2000
station.
Taking mobile IP as an example, using mobile IP in the RAN would
require that a mobile IP foreign agent (FA) be present at each base
station. However, because the mobile terminal can be in contact with
up to 6 base stations at once, there is no unique care-of address for
the mobile (unless the mobile uses a co-located care-of address).
Therefore, the home agent (HA) would need to forward packets to
multiple FAs. Furthermore, on the reverse leg, a frame selector is
still necessary to generate a single packet for the corresponding
node.
In effect, the RAN controller is an application level transport and
mobility mechanism specialized to the CDMA radio medium. An
application's packets to/from the mobile effectively run over a
"stratified stack" in the RAN, in which the bottom stratum is the RAN
protocol stack, and the upper stratum is the IP stack on the mobile
terminal and corresponding node. The RAN controller is therefore not
a good candidate for replacing with current network level mobility
mechanisms. Because of the hard real time constraints involved in
soft handoff, the RAN controller's soft handoff function is also not
a good candidate for replacing with more general application level
mechanisms, such as SIP [4].
5.0 Applicability of IP Mobility to Hard Handoff
Note that the above considerations do not apply to hard handoff,
which occurs outside of the RAN. When a mobile terminal moves between
two RANs that are not interconnected, the RAN controller defers
handoff to the core network. Some mechanism is necessary in the core
network to move the mobile terminal's point of attachement at the
network level. IP mobility solutions for fast handoff are applicable
here.
Proposals such as [6] that apply after frame selection do not involve
soft handoff and therefore are appropriate for implementing fast,
hard handoff.
6.0 Future Prospects for IP Mobility in the CDMA RAN
What would it take to enable IP mobility in the RAN? The question is
worth examining because the end-to-end model of networking which
would be required to make IP mobility work in the RAN has attractions
from the point of view of simplicity of network management and
transparency.
Certainly, routing the mobile's packets directly in the RAN would be
a major contributor. For that to happen, IP over the air interface
Kempf, McCann, Roberts expires January 2001 [Page 9]
INTERNET DRAFT July 2000
would be necessary. The major impediment to IP over the air is
currently header size, but new work in header compression may
eliminate this objection. Given that a spectrally efficient
representation of IP on the radio medium is possible, IP packets can
be sent out over the air by the mobile terminal, and the base
stations can handle the packets precisely as they currently do with
the specialized radio frames. The result would be that IP packets
from the radio would appear directly on L2 in the RAN, rather than in
a stratified stack.
However, there is still a problem with the multipath nature of
macrodiversity. On the forward leg, the routing from a single source
at the RAN gateway to multiple base stations looks like multicast,
but the real time constraints are extremely tight. On the the reverse
leg, however, traffic still needs to be combined in the wired network
behind the base stations. In order to accommodate macrodiversity, the
RAN would need to be a routing domain in which a multipath routing
protocol that performed frame selection in the border routers and
featured real time routing table convergence (for soft handoff) was
in use. These characteristics involve a considerable change from
existing IP routing algorithms (which do not require real time
convergence and do not involve multipath nor selection of particular
packets based on some algorithm).
While the prospects for moving IP into the RAN for transport of RAN
protocols and data/voice traffic from the mobile are good, it seems
unlikely that IP mobility will play any role in replacing CDMA soft
handoff in the immediate future. The stratified RAN stack supporting
CDMA soft handoff is a specialized, and therefore not a good
candidate for replacement by more general network or application
level mechanisms. In addition, even if IP is used for transport in
the RAN, if voice over IP is to completely replace the current radio
voice protocols, voice packets may need to be processed at the RAN
gateway for maximum efficiency and robustness over the radio medium.
7.0 Summary
Most proposals for IP mobility require a one-to-one mapping between
the mobile terminal and a base station with which it is in contact,
and assume end-to-end connectivity and consequently routing in the
radio access network based on the mobile's IP address. In CDMA
networks, macrodiversity and the need for extremely low delay and
jitter invalidate these assumptions. Consequently, IP mobility
solutions are not applicable to CDMA soft handoff. These
considerations do not, however, apply to hard handoff which occurs in
the core network after frame selection.
8.0 References
Kempf, McCann, Roberts expires January 2001 [Page 10]
INTERNET DRAFT July 2000
[1] Perkins, C. (ed.), IP Mobility Support for IPv4, revised, draft-
ietf-mobileip-rfc2002-bis.txt (work in progress), January, 2000.
[2] Vakil, Faramak, et. al., Host Mobility Management Protocol:
Extending SIP to 3G-IP Networks, draft-itsumo-hmmp-00.txt (work
in progress), October, 1999.
[3] E. Wedlund and H. Schulzrinne. Mobility Support Using SIP. Second
ACM/IEEE International Conference on Wireless and Mobile
Multimedia (WoWMoM'99). Seattle, Washington. Aug. 1999.
[4] O'Neill, A. and Corson, S., Edge Mobility Architecture, draft-
oneill-ema-00.txt (work in progress), October, 1999.
[5] Campbell, A., et. al., Cellular IP, draft-ietf-mobileip-
cellularip-00.txt, January, 2000.
[6] Kempf, J. and Calhoun, P., Foreign Agent Assisted Hand-off,
draft-calhoun-mobileip-proactive-fa-00.txt (work in progress),
January, 2000.
[7] Ramjee, R., et. al., IP micro-mobility support using HAWAII,
Internet Draft (work in progress), June 1999.
[8] IEEE, "Wireless LAN Medium Access Control and Physical Layer
Specifications", IEEE Std 802.11-1997, November 1997.
9.0 Authors' Addresses
Questions about this memo can be directed to:
James Kempf
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
901 San Antonio Rd., UMPK15-214
Palo Alto, CA, 94303
USA
Phone: +1 650 786 5890
Fax: +1 650 786 6445
E-Mail: james.kempf@sun.com
Peter McCann
Bell Laboratories
263 Shuman Boulevard
Room 2Z-305
Kempf, McCann, Roberts expires January 2001 [Page 11]
INTERNET DRAFT July 2000
P.O. Box 3050
Naperville, IL, 60566
USA
Phone: +1 630 713 9359
Fax: +1 630 713 4982
E-Mail: mccap@research.bell-labs.com
Philip Roberts
Motorola, Inc.
1501 W. Shure Dr.
Arlington Heights, IL, 60015
Phone: +1 847 632 3148
E-Mail: qa3445@email.mot.com
9.0 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this docu- ment itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Inter- net organizations, except as needed
for the purpose of developing Internet standards in which case
the procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English. The limited permis- sions granted
above are perpetual and will not be revoked by the Internet
Society or its successors or assigns. This document and the
information contained herein is provided on an "AS IS" basis and
THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Kempf, McCann, Roberts expires January 2001 [Page 12]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/