Subject: Re: [MOBILE-IP] CDMA misinterpreted and

From: Jim Willkie <[email-masked]>
Date: Tue, 10 Aug 1999 10:04:06 -0700

At 10:23 AM 8/10/99 -0500, Lipford, Mark wrote:
>I haven't been following this closely, but if I understand the concept
>correctly you are discussing have multiple IP connections over the RF link.
>Why would you want to do that when the problem with wireless data is limited
>RF resources?  Now you are suggesting using two times (or more) the RF
>resources required.  As a CDMA carrier we are fighting to reduce the traffic
>over the RF to allow for more subscribers, not the opposite.
>
>Tell me if I'm missing something here.

Mark:
You are missing nothing. The scheme being proposed seems built around the
premise that multiple CDMA traffic channels can be received to a single
user (which is how the IS-95B Medium Data Rate service provides higher
rates) but it seems suspect to split the channels into 2 distinct services,
especially if the split is at the IP layer. Seems like a good idea
(multiple traffic channels delivered to a single user) taken in a bad
direction (multiple IP end-points).

This is my opinion, for what it's worth.

Jim Willkie

>                -----Original Message-----
>                From:   Gerald Maguire [mailto:[email-masked]]
>                Sent:   Monday, August 09, 1999 12:37 PM
>                To:     [email-masked]
>                Subject:        Re: [MOBILE-IP] CDMA misinterpreted and
>
>                Pete McCann <[email-masked]> stated:
>
>                    ... So, if you want to have true multi-point
>                    connectivity, that is, you want to have two points of IP
>connectivity,
>                    you need to actually replicate a lot of hardware so that
>you can talk
>                    on two different CDMA spreading codes at once.  This is
>typically not
>                    done in the CDMA transmitters of today, and, although it
>may be a
>                    possibility in the future, my understanding is that this
>is not really
>                    being planned for (someone please correct me if I'm
>mistaken).
>
>                Assuming that the CDMA system is using a single frequency
>for these
>                two channels (i.e., that it is only a code difference betwen
>the two)
>                then the is very little that needs to be replicated to
>_receive_ two
>                different channels of CDMA - since the RF section can be
>shared, all
>                you need to have is an extra correlator (or three -
>depending on if
>                the user is moving or not) for the additional spreading
>code. Thus the
>                cost of receiving on multiple codes is low and you can
>easily go from
>                chips to bits in the basestations. If these are IP packets
>in some
>                sort of link frame, then you could immediately put these
>frames into a
>                routed IP infrastructure right from the base station.
>
>                The transmission problem is more complex if you are going to
>do
>                accurate power control - since the different chip streams
>may have to
>                have different power levels when transmitted. However, in
>the case
>                where the power can be identical (for example indoors over
>short
>                distances) - then there is no problem simply combining
>(or-ing) the
>                chip streams and then feeding them into the same RF section
>{since
>                after all it is the codes which separate the streams not
>their
>                freq. etc.}. [Note that in this case I have assummed that
>you are
>                generating the chips for the different streams synchronously
>- which
>                just makes things simpler.] Once again there is no reason
>not to do
>                this as close to the basestation as possible - since it
>conserves
>                bandwidth on the typically wired link to put off the bit to
>chip
>                conversion until as late as possible.
>
>                Unlike the voice case there is no problem (other than the
>transport of
>                duplicate packets) with each of the basestations which can
>receive a
>                mobile sending on the IP traffic that it receives. These
>extra copies
>                can be eliminated by administratively deciding which
>basestations(s)
>                will be forwarding traffic coming from a given mobile. There
>are
>                clearly cases (such as when the mobile is on the fringe of
>two cells)
>                when it may be quite reasonable for several basestations to
>be
>                forwarding traffic to or from a given mobile.
>
>                Pete further states:
>                    When trying to build a data-over-cellular network, it's
>important to
>                    keep in mind that traditional voice is still the most
>important
>                    service and will likely be that way for some time to
>come.  Therefore,
>                    you should try to piggyback the service as much as
>possible on the
>                    existing voice infrastructure, which has already solved
>many of these
>                    problems in a cost-effective way.  The more changes or
>additions to
>                    the infrastructure you require, and the closer these
>changes/additions
>                    are to the "fringes" of the network (base stations), the
>more
>                    expensive and harder to deploy it will be.  This is a
>lesson that
>                    should have been learned from CDPD.
>
>                There is an important distinction of if this
>data-over-cellular
>                network is being built by an incumbant who is already
>operating an
>                voice oriented cellular system or not. In the case where
>there is no
>                existing voice oriented cellular system - there is no need
>to use the
>                typical voice oriented infrastructure and you can build an
>IP oriented
>                infrastructure from the start. Clearly if you have an
>existing voice
>                oriented cellular infrastructure you want to preserve its
>value for as
>                long as possible - therefore you are more likely to take an
>incremental
>                approach rather than forklift replace it. However, I don't
>see that a
>                voice oriented infrastructure is inherently more
>cost-effective in the
>                wireless setting (just as it is not in the wired setting).
>
>                For example, consider an operator who does not have an
>existing GSM
>                infrastructure but decides to go into the GPRS business. Is
>there any
>                reason why they should build a circuit switched
>infrastructure? By
>                utilizing VOIP from the handset to the remote end - you can
>                potentially remove 60% of the processing required since you
>don't have
>                to transcode voice packets to a mu-law or A-law stream
>into/out of a B
>                channel. Of course if you do have to go through a voice
>gateway at the
>                national gateway or where you interconnection to other
>operators you
>                will have to do the transcoding, but thanks to the digital
>modems used
>                to create dialin modem pools (such as in the Ascend Max) you
>can do
>                this with very high density devices (i.e., 2-4 E1
>connections per 10cm
>                of rack space).
>
>                From a practical point of view there is evidence that
>putting all of
>                the processing in the center (i.e., not distributing it) is
>not always
>                the preferred solution - otherwise _everyone_ would use
>Ericsson's
>                AXEs to make their infrastructures (which they don't).  Even
>though
>                this was the case at the start of many cellular voice
>networks it is
>                not the case today.
>
>                Regards,
>                G. Q. "Chip" Maguire Jr.

---

From: Gerald Maguire <[email-masked]>
Date: Tue, 10 Aug 1999 19:39:22 +0200

Jim Willkie states:
    Mark:

Consider a mobile user who has a mobile IP client, if said user is
currently using operator A's network and is about to go into operator
B's network they might register a care-of address (with their home
agent) which will deliver traffic to operator B's cell which they are
about to enter. Thus the mobile user now has two care-of address and
will get copies of their IP traffic set to both of these addresses. As
the user moves from one infrastructure to the other there will now be
no period during which they have left one but not yet entered the
next, there need not be a delay in getting the home agent to start
sending traffic to their new point of attachment, etc. -- the result
is a soft handover -- even though it was across multiple operators.

In order for this to work well the mobile needs to be able to know
that operator B's infrastructure exists, know how to request a care-of
address for B's cell that they are about to enter, and needs to be
able to receive traffic from both operators during the handover
process.

Jiang Wu ([email-masked]) has shown that by registering with an agent
in the network which you are going to enter you can even have your
multicast joins done (if necessary) before you arrive - thus you can
combine his results with the soft handoff described above and thus do
soft handoffs even while participating in a multicast.

Thus I don't think that multiple IP end-points is necessarily a bad idea.

Similarily doing simulcasts (sending the same IP packet to/from more
than one BS) can be used even within a single operator's
infrastructure in order to hide the effects of handoffs between parts
of their network (i.e., when the common point in the network is
distant although the cells are adjacent) -- assuming that the operator
has a packet network infrastructure and not a circuit switched network.

Chip

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 10 Aug 1999 14:26:29 -0700

All,

I am making the initial bake-off results available at www.diameter.org. Please
take note that the report is not final, and I still need to include the
information in a table format, but the challenge of creating a 3D ASCII table
is quite formidable.

I have looked at the last test-a-thon report, and will probably provide the
information in a similar format. I will post a mail when I am done updating the
document.

The URL is http://www.diameter.org/mip_results.txt

Enjoy,

PatC