Subject: [MOBILE-IP] Applicability of IP Mobility to CDMA Soft Handoff

From: James Kempf <[email-masked]>
Date: Wed, 3 May 2000 08:19:33 -0700

There has been some discussion on the mobile IP and SIP lists about
replacing CDMA soft handoff with IP mobility mechanisms. The attached draft,
authored by Pete McCann, Phil Roberts, and myself, attempts to explain how
a CDMA RAN works and why soft handoff is not a promising candidate
for replacing with IP mobility mechanisms in the near term. In contrast,
the analysis is not applicable to hard handoff, which is a potential
candidate for replacing with IP mobility. We have submitted this to
the drafts alias as an individual contribution

Comments are welcome.

                jak

INTERNET DRAFT                                                James Kempf
Category: Informational                             Sun Microsystems, Inc.
Title: draft-kempf-cdma-appl-00.txt                           Peter McCann
Date: April 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 October 2000                  [Page 1]

INTERNET DRAFT                                                April 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 RANs rather than between base
   stations within a RAN.

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
   RANs is very frequent, their utility is lessened in the presence of

Kempf, McCann, Roberts    expires October 2000                  [Page 2]

INTERNET DRAFT                                                April 2000

   link-layer mobility like that offered by today's TDMA and CDMA
   systems.  In fact if the link-layer offers transparent mobility
   throughout a given domain these proposals do not contribute anything
   since they are essentially intra-domain mobility management
   protocols.  As cellular networks evolve towards more pervasive IP
   technologies, mobility for traffic within those networks must
   accommodate some level of movement of IP traffic.

   In this paper, we discuss CDMA radio access networks and why IP
   mobility solutions (including mobile IP) are not applicable to soft
   handoff in a CDMA radio access network. In effect, the CDMA RAN
   network with soft handoff is an application layer transport and
   mobility mechanism, and therefore not an appropriate candidate for
   moving into the network layer. 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.

   hard handoff
     The process by which a moving mobile terminal is transferred

Kempf, McCann, Roberts    expires October 2000                  [Page 3]

INTERNET DRAFT                                                April 2000

     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 contain complete IP
     packets, 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:

     1) Receive packets from the core network destined to the mobile
     terminal,

Kempf, McCann, Roberts    expires October 2000                  [Page 4]

INTERNET DRAFT                                                April 2000

     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,

     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
   the radio frames.

   The following figure illustrates the architecture and how the CDMA

Kempf, McCann, Roberts    expires October 2000                  [Page 5]

INTERNET DRAFT                                                April 2000

   RAN network works:

                         Core Network

                            ^
                            |   incoming/outgoing octet stream
                            |    from/to corresponding node (129.142.68.79)
                            |
                            V
   +-----------------------------------------------------+
   | RAN Gateway                                         |
   |                                                     |
   |    +-------------+  +-----------+  +----------+     |
   |    |             |  |           |  |          |     |
   |    | Frame       |  | Frame     |  | Soft     |     |-----------
   |    | Selection   |  | Splitting |  | Handoff  |     |       to another
   |    |             |  |           |  | Control  |     |       RAN Gateway
   |    +-------------+  +-----------+  +----------+     |
   |                                                     |
   |    +---------------+                                |
   |    |               |                                |
   |    | Radio Frame   |                                |
   |    | Processing    |                                |
   |    |               |                                |
   |    +---------------+                                |
   |                                                     |
   +-----------------------------------------------------+
            |             |              |            |    *
            |             |              |            |      *
            |             |     ...      |            |       * radio
            |             |              |            |       * frames
            |             |              |            |      *
            |             |              |            |    *
       +---------+   +---------+   +---------+   +---------+
       | Base    |   | Base    |   | Base    |   | Base    |
       | Station |   | Station |   | Station |   | Station |
       |   B1    |   |   B2    |   |  B42    |   |   B43   |
       +---------+   +---------+   +---------+   +---------+
            \              |
             \             V
              \--------->
                           |
                         -----
                        /     \
                    -----       -----           162.42.42.42
                   | mobile terminal|(  --->
                   ------------------
                     ( )        ( )

Kempf, McCann, Roberts    expires October 2000                  [Page 6]

INTERNET DRAFT                                                April 2000

   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
   responsible for making sure that the jitter and delay constraints are
   met, and for processing packets from the core network into radio
   frames.

Kempf, McCann, Roberts    expires October 2000                  [Page 7]

INTERNET DRAFT                                                April 2000

   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 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
   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

Kempf, McCann, Roberts    expires October 2000                  [Page 8]

INTERNET DRAFT                                                April 2000

   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. It is
   therefore not a good candidate for replacing with 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
   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.

Kempf, McCann, Roberts    expires October 2000                  [Page 9]

INTERNET DRAFT                                                April 2000

   However, there is still a problem with 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. A multicast routing algorithm with routing tree
   modifications that converge in real time might contribute to solving
   the problem. On the other hand, the reverse leg traffic would still
   need to be combined in the wired network behind the base stations.

   While the prospects for moving IP into the RAN are good, it seems
   unlikely that IP mobility will play any role in replacing CDMA soft
   handoff in the immediate future. CDMA soft handoff appears to be a
   very specialized form of transport-level or link layer mobility, 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

  [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-

Kempf, McCann, Roberts    expires October 2000                 [Page 10]

INTERNET DRAFT                                                April 2000

        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.

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: [email-masked]

      Peter McCann
      Bell Laboratories
      263 Shuman Boulevard
      Room 2Z-305
      P.O. Box 3050
      Naperville, IL, 60566
      USA

       Phone: +1 630 713 9359
         Fax: +1 630 713 4982
      E-Mail: [email-masked]

      Philip Roberts
      Motorola, Inc.
      1501 W. Shure Dr.
      Arlington Heights, IL, 60015

      Phone:  +1 847 632 3148
      E-Mail: [email-masked]

9.0  Full Copyright Statement

Kempf, McCann, Roberts    expires October 2000                 [Page 11]

INTERNET DRAFT                                                April 2000

   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 October 2000                 [Page 12]

---

From: Gerald Maguire <[email-masked]>
Date: Thu, 4 May 2000 16:57:06 +0200

In draft-kempf-cdma-appl-00.txt, you state that "the reverse leg
traffic would still need to be combined in the wired network behind
the base stations." Why is this necessary? If the corresponding host
receives multiple copies of the packet, it can decide to accept the
first one to arrive which is correct and throw away the other copies.

You also state:
   " ... 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."

Why add this processing (and hence additional delay) in the RAN
gateway, when the voice encoding/decoding can simply be done at the
mobile? Any necessary robustness can be provided by end points and
thus you avoid any possible need to transcode in the RAN.

Although the draft very thoughtfully describes the current CDMA
systems and the requirements, it does not provide a proof that
end-to-end IP can't be done. So I don't think Jim Willkie's statement
"Hopefully this paper and any potential enusing discussions will quell
any effort to use mobileIP for soft handoff on CDMA networks...." has
any basis. What is missing is some real measurements on the delays
involved in controlling a device which can replicate packets for
transmission over tunnels to several base stations and implementation
and measurement of a base station which does IP directly over RLP.

Christian Olrog showed in April 1999, in his M.S. thesis "Direct Radio
Link Protocol Interface", that GSM's RLP processing could be done on a
PC running Linux -- rather than requiring a real-time OS. Prior to his
implementation and measurements everyone thought this couldn't be done.
What is the chance that we will see the same thing happen with regard
to end-to-end IP?

Regards,
Chip

---

From: Pete McCann <[email-masked]>
Date: Thu, 4 May 2000 10:47:02 -0500

Hi, Gerald,

Gerald Maguire <[email-masked]> (GM) writes:

GM> In draft-kempf-cdma-appl-00.txt, you state that "the reverse leg
GM> traffic would still need to be combined in the wired network behind
GM> the base stations." Why is this necessary? If the corresponding host
GM> receives multiple copies of the packet, it can decide to accept the
GM> first one to arrive which is correct and throw away the other copies.

This is necessary to support the macrodiversity features of a CDMA
RAN.  The radio frame received by any given base station is likely to
contain errors, and in any case will be just one chunk of an IP
packet.  The frame selector combines the frames from multiple base
stations, hopefully correcting any errors and producing a single frame
that contains data for the octet stream that carries IP traffic.  So
an individual radio frame received by a base station is *not* an IP
packet and cannot be routed directly to a correspondent host without
being processed by a frame selector.

If you don't believe that macrodiversity is important, then you would
eliminate the centralized frame selector and try to reconstruct the
packets from only one stream of radio frames.  However, this would
degrade performance from current CDMA systems.

GM> You also state:
GM>    " ... In addition, even if IP is
GM>    used for transport in the RAN, if voice over IP is to completely
GM>    replace the current radio voice protocols, voice packets may need to
GM>    be processed at the RAN gateway for maximum efficiency and robustness
GM>    over the radio medium."

GM> Why add this processing (and hence additional delay) in the RAN
GM> gateway, when the voice encoding/decoding can simply be done at the
GM> mobile? Any necessary robustness can be provided by end points and
GM> thus you avoid any possible need to transcode in the RAN.

The point is just that vocoders specifically designed for wireless
should be used over the wireless link.  If the CH has such a vocoder
that's great, but it's not clear that all wired hosts would support a
wireless-specific vocoder.  So transcoding has to take place somewhere
(although admittedly not necessarily in the RAN gateway itself).

GM> Although the draft very thoughtfully describes the current CDMA
GM> systems and the requirements, it does not provide a proof that
GM> end-to-end IP can't be done. So I don't think Jim Willkie's statement
GM> "Hopefully this paper and any potential enusing discussions will quell
GM> any effort to use mobileIP for soft handoff on CDMA networks...." has
GM> any basis. What is missing is some real measurements on the delays
GM> involved in controlling a device which can replicate packets for
GM> transmission over tunnels to several base stations and implementation
GM> and measurement of a base station which does IP directly over RLP.

The draft points out that "replication" is done at the level of radio
frames, not IP packets.  The draft does not argue for or against
end-to-end voice-over-IP, but it does point out that BTSs are not
the individual, IP-addressable entities visible from MNs that some
people have assumed them to be.  Even if the RAN network is IP-based
and the BTSs have IP addresses, the MNs do not see them as their IP
point of attachment.  That point is farther back in the network, at
the RAN gateway.  If you want to combine such a gateway with a BTS
it will have negative performance implications because you will lose
macrodiversity.

GM> Christian Olrog showed in April 1999, in his M.S. thesis "Direct Radio
GM> Link Protocol Interface", that GSM's RLP processing could be done on a
GM> PC running Linux -- rather than requiring a real-time OS. Prior to his
GM> implementation and measurements everyone thought this couldn't be done.
GM> What is the chance that we will see the same thing happen with regard
GM> to end-to-end IP?

What you are saying is that a RAN gateway could be implemented on a
Linux box.  (I would question whether such a gateway would have nice
scaling properties as you increased the system load, btw).  That's
great but doesn't really say anything about where architecturally the
RAN gateway (frame selector) should be placed.  All we are saying is
that you can't see the MN's IP packets before that point.

-Pete

---

From: Jim Willkie <[email-masked]>
Date: Thu, 4 May 2000 09:01:59 -0700

At 04:57 PM 5/4/00 +0200, Gerald Maguire wrote:
--cut--
>thus you avoid any possible need to transcode in the RAN.

The catch here is the 'necessary robustness'. One can accurately claim that
the current CDMA air-interface has done all this  'necessary robustness'
and has done it best. So the premise of Gerald's claim holds but the work
is already done and optimal.

>and measurement of a base station which does IP directly over RLP.

I suppose the actual proof is missing. One could derive the proof. I think
the key factors would be 1) some reasonably accurate CPU-load processing
factors for a typical mobile phone/data device, 2) model the more extensive
IP layer processing needed, including the 'price' paid for IP header
overhead. I would guess that we are 3 or 4 Moore's Law generations away,
perhaps more.

>What is the chance that we will see the same thing happen with regard

Please note that a PC running Linux is still running with a CPU clock rate
of 300 to 400 Mhz. Typical mobile phone/device CPU clock rates are 10 to 20
Mhz. The cost of the CPU and the accompanying memory are orders of
magnitude different.

At some point processing power will grow to the point where some of the
arguments against mobileIP-for-softhandoff will disappear. There will still
be the issue of "why do something that is already in place?". There would
have to be a compelling reason at that point in time. For the near future
it is a solution looking for a problem.

Jim Willkie

---

From: Andras Veres <[email-masked]>
Date: Thu, 4 May 2000 13:06:13 -0500

All,

I think that draft-kempf-cdma-appl-00.txt assumes a scenario where
all components of a WCMDA network remain the same, only the networking
layer would be replaced by IP.

If this is the case, I am not surprised at all that we run into
serious problems. The reason is that WCDMA was designed based on the
circuit switched model and it follows the principle of
    ** total control for maximum efficiency (TM) **.

I think that one thing we can learn from IP is that by eliminating
total control, of course we loose in performance, but we gain a lot
in simplicity and scalability. (And who knows, this loss may
be negligible - just think of the great performance of IEEE 802.11)

I know that radio channels call for more control than usual IP
networks (e.g., Ethernet), but I do beleive that the current
WCDMA and 3G concepts are fundamentally problematic and not
scalable -- requiring terrible protocol stacks (IP over ATM
over UDP over IP over Whatever over AAL2 over ..... :-),
leading to such monsters like RNC.

James: Do you think that IP is still a non-feasible solution,
if we consider that even the curcuit switched model may be
redesigned based on IP principles?

Regards,
Andras

--
Andras Veres

http://comet.ctr.columbia.edu/~veres
Columbia University
Dept. of Electrical Engineering mc 4712
500 West 120th Street, H1
New York, NY 10027

Office phone:   (212) 854-3117
Office fax:     (212) 932-9421

---

From: Arthur Ross <[email-masked]>
Date: Thu, 4 May 2000 10:18:30 -0700

>leading to such monsters like RNC.
AMEN!

   -- A

---

From: Amanda Walker <[email-masked]>
Date: Thu, 4 May 2000 14:13:28 -0400

> redesigned based on IP principles?

I think that there are two separate threads of discussion here, and that
they are sometimes hard to tell apart:

1) Can we build networks that support mobile IP services from the "ground
up"?  I think this answer is "certainly."  CIP and HAWAII are great
examples, various people have built proof-of-concept demos of things like
VOIP over 802.11, and so on.  However, at least so far, these are all
experimental--in some cases very robust, but they run in labs, not in
airports and cars.  Nonetheless, they do show that it is both possible and
often advantageous to have as lightweight a link layer as possible and have
a single place for mobility decisions and policy to be implemented.

2) Can we overlay mobile IP services on top of existing networks?  I think
that this answer is also "certainly," but it's very much a different
problem.  Many networks support their own mobility features specifically
because at the time they were designed and deployed, there was no other
choice.  Even 802.11, for example, jumps through hoops (smaller hoops than
CDMA, to be sure, but hoops nonetheless) to give the illusion of an
Ethernet-like link, so that existing IP implementations can gain at least
limited mobility.

draft-kempf-cdma-appl-00 addresses question (2).  The same argument can be
applied to any existing network where discarding it and building a new one
from scratch is not an option.  Where the existing network handles mobility,
the most useful place to pick things up with MIP (e.g., a non-colocated FA)
is where that existing mechanism stops.

draft-kempf-cdma-appl-00 does not address question (1) at all.

Now, there's a third, often implicit, third question which is:

3) Which approach is better?

This is unanswerable in any absolute sense.  Operators and suppliers for
existing networks will tend to ask question (2), while innovators entering
the market will ask question (1).  It's a lot easier to build from scratch
if you don't already have a working network to have to throw away or write
off (and existing customers to lose while you do so).  On the other hand,
not keeping up with innovation will eventually render older systems
irrelevant anyway.

It's a classic dilemma.

Speaking personally, I don't think we're going to solve it here.  MIP needs
to be usable as both a building block *and* an overlay.  There's a lot of
useful experience represented here on both sides of this issue (and some
additional perspectives as well).  I'm much more interested in what everyone
has done and how it succeeds and fails, than in speculating about how things
should have been done differently in existing systems.

Amanda Walker <[email-masked]>
Lucent Technologies InterNetworking Systems

---

From: "Andrew T. Campbell" <[email-masked]>
Date: Thu, 4 May 2000 14:47:44 -0700

That is an excellent summary.

---

From: Andras Veres <[email-masked]>
Date: Thu, 4 May 2000 15:30:54 -0500

Amanda,

Fully agree! I did not intend to bring WCDMA standardization to this
forum :-)
My message is that there is are fundamental limitations in TCP/IP which
would
inhibit its use in WCDMA networks. And maybe we'll have it once - thanks
to those "innovators" you mentioned.
(Hey, aren;t we supposed to be the innovators here?)

:-)
Andras

--
Andras Veres

---

From: Andras Veres <[email-masked]>
Date: Thu, 4 May 2000 15:36:32 -0500

Oppps! I mean there are NO fundamental limitations!
Andras

--
Andras Veres

---

From: Jim Willkie <[email-masked]>
Date: Thu, 4 May 2000 15:11:18 -0700

>(Hey, aren;t we supposed to be the innovators here?)

Isn't this statement exactly backwards? That is, there are fundamental
limitations to WCDMA (the data protocols at least) that inhibit running
TCP/IP over it?

There are at least some of us out here that are convinced this is the case.
In fact I would further state that it appears that TCP/IP will run over
WCDMA rather nicely if the WCDMA GPRS-like protocols (and the associated
XXGNs) were stripped away.

Jim Willkie

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 5 May 2000 11:25:40 +0900

This mail is really great, thanks Amanda!
I think that the researchers in this field should work hard
in the direction of the second approach (rather than singling out 3G as
ATM-like)
and at the same time
we should keep an eye on the first one.
  I think that the approach 1 should set the stage for 4G together with
innovations
at the physical layer.

--
Behcet