Subject: RE: [seamoby] I-D ACTION:draft-ietf-seamoby-mm-problem-00.txt

From: [email-masked]
Date: Tue, 27 Feb 2001 09:46:06 -0600

Hi folks,  time to join the fray!

A few comments.

Sent by:  "Dana L. Blair" <[email-masked]>

At 08:45 AM 2/23/01 -0800, James Kempf wrote:
>Hi Mike,
>
>> > Don't forget the cellular case where the network between the
>> > AP and the Access Router may not even have full mobile packets
>> > on it. It may have radio frames. I think this needs to be supported
>> > as well.

...and this is precisely why 3G is doomed.

>>
>>   Supported in what way? Certainly not by SEAMOBY, I hope.
>>   If we have to "support" every bad network design, we
>>   might as well give up now.
>>
>
...well there's always 4G think positively.

<snip>
>
>In point of fact, macrodiversity resolution must be done at some point
>back in the wired network. One can argue how useful or necessary including
>macrodiversity is for a radio protocol, but CDMA currently
>has it and there are good reasons (e.g. combatting Rayleigh fading) for
>having it in. So having some kind of wired networks over which radio
>frames are running to the macrodiversity resolution point
>is a necessity for CDMA protocols.

WRONG.  See US. Patents 6072790, 6141559 both Motorola, ...SDU at BTS.
Macrodiversity done at BTS.  Radio CDMA radio frames backhauled over
IP from the BTS!  Its not a necessity James.  Its just a hangover from
AMPS design.

>>That is true but don't assume that the resolution point is in the middle of
the
>>network.   It could be co-located with the cell tower and an Internet
connection.

Don't know who said the above but right on man (think it was Dana)!
>
>Given that and the desire of many 3G operators and vendors
>to use IP in their RANs, I don't see any reason why it should not
>be considered. If one does consider it, it makes an even stronger case
>for using a routing update based protocol instead of a tunnelling protocol,
>because the time constraints on doing soft handoff are pretty strict,
>and the need to avoid mobile node involvement argues for maintaining the IP
>address. This kind of mobility is currently handled by dedicated radio
>network layer protocols, but, given the right kind of micromobilty
>protocol, I think it could be handled by IP transport mechanisms in the
>future.

The timing constraints are only strict because of their brain dead circuit
switched mentallity.  If you go all packets with jitter buffers every thing
works very nicely.  The operators have their heads collectively stuck up
up their multi-gillion dollar PSTN's.  I am feeling quite truculent today!

>
>In short, including these kind of networks strengthens your argument
>about the need for routing based approaches to micromobility.

Yeah!  Routers aren't even the answer.  Its light pipes.  Its PON's to the
freakin antenna.  Light mixed down to radio is the now I want.

>>This is an interesting point.  Maybe we should include macro-diversity in
>>the next revision of the micro-mobility problem statement draft.

Not quite.  What we can do, is get MIP AND SeaMoby to agree that its an
edge activity that can involve ARs that have "legs" going locally and
non-locally macro (this reminds me of OBAST!!!).

As always sorry for my scorched feathers mail list policy,

Thanks,

Phil Neumiller

---

From: James Kempf <[email-masked]>
Date: Tue, 27 Feb 2001 12:33:59 -0800

Hi Phil,

>IP from the BTS!  Its not a necessity James.  Its just a hangover from

Thanx for the reference.

Even if the BTS is doing the resolution, there still needs to be backhaul from
other BTSs in soft handoff to the BTS handling the SDU point to get the
macrodiversity resolved.

My point was, it has to be somewhere in the network. Whether it's on the edge
or somewhere in the core should depend on what network resources are
available. Trying to do a fully meshed BTS layout in central Nebraska might
not cut it if all you've got are T1 lines. It will probably work well in 
Silicon
Valley where there are plenty of network resources available.

But this is way off topic (apologies to the rest of the list)...

                         jak