Subject: [MOBILE-IP] 3G RAN and IP mobility

From: "G. Ensuque" <[email-masked]>
Date: Fri, 27 Aug 1999 08:42:15 +0100

Hi all

on the question of 3G frame selection/distribution...

I find it a bit ironical that it is the same team that has proposed AAL2
switching for the RAN in UMTS (I don't know how this is handled in
Cdma2000), and Cellular IP in this working group (Ericsson Traffic Analysis
and Network Performance Laboratory, Budapest, Hungary).

If I understand things correctly, the requirements for AAL2 switching in the
RAN come from the peculiarities of CDMA in outdoor operation (near-far
problem --> power control --> soft HO/macro diversity --> synchronisation
--> need to 'quickly' transport bit frames from the splitting point in the
RAN down to the BS in the active set)

I think it would be very interesting to compare the transport performance of
AAL2 switching and a 'per-host entry forwarding' scheme such as Cellular IP
or HAWAII... for use in a 3G RAN

Personally (<DISCLAIMER>this is not necessarily a BT view </DISCLAIMER>), I
think that AAL2 switching is very ugly in the RAN since it requires not only
an ATM stack, but also Ericsson's new AAL2 Switching stuff, which is an
additional layer of complication, and is horrendously based on an extension
of good old B-ISDN (urg!).

This complexity will prevent from using UMTS Node Bs (e.g. TDD mode) in a
private environment, and as already pointed out by Gerald Maguire, it would
be nice to handle the mobility in pico cellular environments (WLAN,
HiperLAN, DECT, UMTS TDD...) with an IP-based scheme.

So if we can find an IP scheme that handles the requirements of CDMA, I
think we would hold the Holy Grail of 4G mobile communications. The
requirements on the transport protocol in the RAN are (from a paper I am
currently writing) are:

1.      The transport protocol must provide on-demand connectivity from any
RNC (~BSC) to arbitrary 'neighbour' Node Bs (~BTS) or RNCs.
2.      During handover, connectivity between the S-RNC (the RNC that does
the frame selection) and new members of an MT's active set must be
established within the delay bounds implied by the subscribed-to end-to-end
QoS (in the case of voice service, this may require association setup times
of less than e.g. 100ms).
3.      The transport protocol must provide tight synchronisation of L1 bit
frames transmitted on diversity sub-paths from the splitting point in the
downlink direction, so that radio Tx is synchronised between the Node Bs in
the active set (this may require to determine and guarantee an appropriate
delay/jitter behaviour on the diversity sub-paths). Uplink transport of bit
frames from the Node Bs to the combining point may not require such a tight
synchronisation, depending on the subscribed-to QoS for the upper layer
end-to-end service.
4.      The transport protocol must be able to meet the aggregate QoS
requirements of all MS's connected to the UTRAN.
Sorry, I have gotten a bit long...

BTW, Gerald, do you have an URL for the ICEBERG stuff ?

Guilhem Ensuque

Mobility Futures Unit                           [email-masked]
B55-131B
BT Advanced Communications Technology Centre
Adastral Park, Martlesham Heath
IPSWICH IP5 3RE                              Tel: +44 1473 645 232
UK                                                   Fax: +44 1473 646 885

> -----Original Message-----
> From: Casati, Alessio (Alessio) [SMTP:[email-masked]]
> Sent: 26 August 1999 23:50
> To:   [email-masked]
> Subject:      Re: [MOBILE-IP] I-D
> ACTION:draft-ietf-mobileip-reg-tunnel-01.txt
>
> Gerald,
>
> > While this was perhaps true in 2G, it need not be true for all
> > 3G. Especially if basestations are connected via IP (such as in the
> > case of ICEBERG) - why should you carry all this traffic up to a few
> > choke points - rather than route it as directly as possible.
> >
> On the contrary TDMA systems (GSM/EDGE/ANSI136) may be
> more amenable than
> UMTS and CDMA2000 (CDMA based 3G) in handling IP close to the
> BTS.
>
> This is due to the 3G RAN architectures
> that foresee the need of a frame selector/distributor
> to handle soft handover.
>
> Economical (and performance) reasons suggest the
> frame selector/distributor not to cover a very limited area.
>
> Hence IP will 'emerge' from the lower layers at points
> among which it's safe to state handoffs cannot occur very
> frequently.
>
> [...]
>
> > In an environment where there is a mix of WLAN and 2G (or 3G) overlays
> > - the mobility will have to be handled at the IP layer - since the
> > link layers can't talk to each other directly.
> >
> It's a fair one.
> Anyway it's quite a common understanding
> that intersystem HO should be possibly
> "rate limited", not to mention
> interdomain&system HO.
>
> > So I am not convinced that the rate of handoffs will be all that
> > low. Considering that I walk through at least 3 different DECT
> > environments when I walk 150m to the nearest hot dog vendor - I would
> > expect that in the future there will be at least this number of Mobile
> > IP networks that I will walk through.
> >
> I don't expect one to experience too frequent
> HO in going to a Hot dogs
> vendor, unless one is really hungry
> (in which case HO disruptions may not be what
> one would really most care about :).
>
> Alessio

---

From: "Andrew T. Campbell" <[email-masked]>
Date: Fri, 27 Aug 1999 05:26:11 -0700

Hello  Guilhem:

> and Network Performance Laboratory, Budapest, Hungary).

For the record your irony is tadd misplaced old chap.

Cellular IP is a project between Columbia University
with support from industry. Cellular IP has no notion of
circuits/ adaptation layers or influence there of. Its a layer
3 routing protocol that supports fast handoff
and passive connectivity for packet data developed at
Columbia initially with Andras Valko (Ericsson) and other Ph.D.
students including Javier Gomez, Chieh-Yih Wan and
Sanghyo Kim. It is a key part of Andras'
thesis which he completed at Columbia. His thesis
will be available later this fall on the Cellular IP
web page - once he is through the process.

The Cellular IP Project at Columbia
has nothing to do with AAL2 or the push for
that in RAN. Cellular IP and ATM/AAL2 in
the same breath - what a slur ;-)

As a footnote Columbia University will release the source code
for Cellular IP to the public domain this fall and hope to
demonstrate the network at MOMUC99. The code for the testbed and
NS2 environments will be available as freeware. The Cellular IP Project
at Columbia is broadly investigating the notion of a
"IP-based mobile telecommunication networks" that take a different
tact from 2.5/3G approaches. We are working on support for
wireless IP QOS and middleware services. The Cellular IP project
is more broadly supported by Ericsson, Intel and IBM.

On a *personal* note I think ATM/signaling is a very poor choice for the
RAN
and wireless in general. Cellular IP's soft-state
routing/switching would give good handoff performance
and one can build wireless IP QOS on that foundation too.
In addition there is no explicit signaling; so
SS7 et al evaporates. I have always considered
that Cellular IP could be refined for the mobile, RAN, core and
gateways as a basic transport and (in-band) signaling technology.

We have recently published a paper on some simulation results
of the protocol. We hope to publish results from our testbed
demonstrator (which are very promising in terms of performance)
in due course.

The NS2 paper is not on our project page but you will find the
PDF file on my pubs page. Look for:

"On the Analysis of Cellular IP Access Networks" , Proc. 6th IFIP
International
Workshop on Protocols for High Speed Networks , Salem, 25-27 August
1999.

Thanks for listening.

--
Andrew
http://comet.columbia.edu/~campbell