Subject: Re: [MOBILE-IP] Re charter review

From: Barani Subbiah <[email-masked]>
Date: Mon, 21 Aug 2000 10:35:28 -0700

I thought that the recent discussions on fast handoff and L2 assisted hand off
with L2 abstraction will address this problem.
If L2 informs the L3 about the SNR and other parameters then L3 can pro-actively
initiate to agent rather than wait for advertisement.

Few issues on the recent fast hand off discussion..

1. We need a single hand off mechanism that is fast, smooth, seamless and
reliable at the IP layer. It can use L2 for what ever reasons, however it should
be L2 agnostic.
2. We ought to be clear on what information we need from L2. I saw some one
mentioned about SNR . Other than that I have not seen any new parameters.
3. What does L3 accomplishes with L2 information and how decision made on L3
relates to L2 or vice versa. Are the decisions made on L3 and L2 independent of
each other or have some consequences on each other.

It will be useful if we are clear about what information L3 needs from L2 and
what does it accomplishes with it..

Barani.

"pcalhoun/@eng.sun.com" <Pat.Calhoun on 08/20/2000 08:04:40 PM

Please respond to "[email-masked]" <[email-masked]>

Sent by:  "[email-masked]" <Pat.Calhoun

To:   [email-masked]
cc:    (Barani Subbiah/HQ/3Com)
Subject:  Re: [MOBILE-IP] Re charter review

> Hi all
>
> There has not been not much discussion about about agent discovery recently.
> That is something i am quite puzzle when people are mentioning all sorts of
> fast handoff.
>
> How could one discuss fast handoff without discussing how much delay does
> agent discovery takes in place all sorts of environments.

Bingo! That is the point that Jim and I have been making all this time, and
the reason why we designed the pro-active FA I-D. It takes time for a mobile
to detect that it has moved (using traditional Agent Advertisements), not to
mention the latency added by the registration process (regardless of how far
the registration request has to be sent).

PatC

---

From: Gerald Maguire <[email-masked]>
Date: Mon, 21 Aug 2000 20:28:56 +0200

With respect to your three questions:

1. Well if you want to look for paramters from L2 with respect to "fast,
   smooth, seamless and reliable", you also many want to have information
   such as power in the channel (both for the channel you are using and
   the channels you might want to use) - since SNR may not be sufficient
   information to tell you if it is in use, detection of pilot/access
   point, past/current/projected future power consumption,
   past/current/project future data rate,
   past/current/project future corrected and uncorrected error rates, ... .

2. While the method can be L2 agnostic, the data dictionary of the
   attributes which have to be passed across this API should be
   extensible -- since we really don't have a good idea of the complete
   range of information that we would like to get. {Since in fact there
   is very little experience with providing this information outside of a
   specific wireless system.}

3. The decisions made on L2 and L3 shouldn't be independent or we would not
   care about passing information back and forth! One of our problems
   currently is that they are largely independent and sometimes at
   cross purposes. A clear example is that a specific L2 may not even
   be aware of another specific L2, both of which are available to L3
   -- thus the first L2 might increase power or decrease data rate --
   while if the L3 knew that this L2 were having problems, then as it
   knows that it has another L2 available it might try to use that
   instead (but only if it can know that it is worth using - which
   requires information).

Chip