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

From: "Lipford, Mark" <[email-masked]>
Date: Tue, 10 Aug 1999 10:23:28 -0500

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.

                -----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: Qiang Zhang <[email-masked]>
Date: Tue, 10 Aug 1999 11:39:57 -0400

>
>At 10:23 AM 8/10/99 -0500, you wrote:
I believe people are talking about the arriving 3G or even 4G cellular
networks which can support up to 2M data rate in an indoor office WLL
environment. Beside the legacy forward/reverse channels you have for voice,
another seperated much wider bandwidth can be allocated for data purpose or
an overlapped frequency structure can be deployed... So ppl will have more
resource problem to worry :)

Qiang

---

From: [email-masked]
Date: Tue, 10 Aug 1999 12:29:23 -0500

When 3G arrives, bandwidth is no longer going to be an issue. Multi-point
connectivity will provide the necessary capabilities for enabling innovative new
data application - helping carriers bring their ARPU back to normal while
keeping churn rate down to a minimum.

"Lipford, Mark" <[email-masked]> (Mailed by: "Lipford, Mark"
<[email-masked]>)
08/10/99 03:23 PM GMT
Please respond to "Lipford, Mark" <[email-masked]>

cc:    (bcc: Shahid Ahmed)

                -----Original Message-----

                Pete further states:

                Regards,
                G. Q. "Chip" Maguire Jr.