Subject: RE: [seamoby] Reactive context transfer

From: "Gary Kenward" <[email-masked]>
Date: Fri, 15 Jun 2001 16:26:01 -0400

Charlie:

 Will the mobile actually initiate a ct or will it initiate a 
handover? Or are you expecting to do both? Do you expect to complete
MN initiated CT in less then 60ms? If not, how will ct in this context
provide seamless handover for VoIP?

Gary

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Friday, June 15, 2001 3:01 PM
> To: Syed, Hamid [WDLN2:AN22:EXCH]
> Cc: 'seamoby'
> Subject: Re: [seamoby] Reactive context transfer
> 
> 
> 
> Hello Hamid,
> 
> > Hamid Syed wrote:
> 
> > I guess we need to understand the boundaries of context 
> transfer and the
> > actual handover.
> 
> Yes, in fact I believe that maybe the word "handover" needs precise
> definition with respect to the process of context transfer (I 
> was going
> to say "in the context of ..." but that would be bad :-).
> 
> > The first two options you listed are handover scenarios 
> where the decision is
> > made where the mobile is going to handover. I am confused 
> how does it relates
> > to context transfer?
> 
> I can easily imagine four cases:
> - Network initiated predictive context transfer
> - Network initiated reactive context transfer
> - Mobile initiated predictive context transfer
> - Mobile initiated reactive context transfer
> 
> I am certain that all four cases can be handled by the same
> context transfer protocol messages.
> 
> I am myself confused about how to answer your question, 
> because it seems
> clear to me that these terms are in fact relevant to context transfer.
> 
> > The predictive context transfer is the same as the 
> proactive context transfer
> > where context is made available to the new AR before a 
> handover of occurs.
> 
> Agreed, except that I am suggesting the use of a different word.
> 
> > Your reactive context transfer definition is more like a 
> "break-before-make"
> > scenario. I do not know how context could be useful if the 
> transfer happens
> > after the handover completion.
> 
> I can think of very many examples.  As one example, multicast group
> membership MIGHT be established at the new access router AFTER the
> basic handover.
> 
> But I also want to clearly distinguish betwen "reactive" and
> "break-before-make".
> These is not at all the same things.  The latter is pretty 
> much confined
> to discussion below layer-3, at least for connectionless 
> protocols like IP.
> The former only just has to do with when the context transfer can get
> started.
> 
> Just as one example, of probably dozens, what if the context transfer
> request started immediately after link-establishment in a 
> make-before-break
> system?  This could easily happen, and in cooperation with 
> Mobile IP or
> stateless address autoconfiguration it might reduce the amount of time
> for the mobile node to get situated on the new network.
> 
> In fact, with make-before-break, maybe one would always want
> to use reactive context transfer instead of predictive.
> With make-before-break, there's nothing left to predict!
> 
> >                                  What will happen to the 
> traffic which has
> > already been handed over to the AR and the context 
> processing is not yet done?
> > particularly with the contexyt information that is 
> calculated on a per packet
> > arrival basis.
> 
> You probably have a specific case in mind, that I can't 
> exactly guess at.
> However, in general, the way that traffic is handled with 
> incomplete context
> transfer is going to be a problem, regardless of whether the 
> transfer is
> requested predictively or reactively.
> 
> >                   For example metering?. How metering 
> context could be useful if
> > the meter value at the new AR has already passed.
> 
> Here I am lost.  What does it mean for a meter value to be passed?
> 
> Why does it matter whether the new access router or the 
> previous access
> router is running the meter?
> 
> >                                                  I believe 
> the reactive
> > context transfer is also a make-before-break scenario with 
> context transfer
> > and the handover should occur simulataneously. Ofcourse, 
> context has to reach
> > the new AR before it becomes useless there.
> 
> I'm sort-of lost here, too, unfortunately.  I am sure we can 
> agree that
> context information sometimes has freshness requirements, but I don't
> see how predictive vs. reactive affects that statement.  Of 
> course, with
> predictive transfers, it will be easier to meet the freshness 
> requirement.
> 
> Regards,
> Charlie P.
>

---

From: Charlie Perkins <[email-masked]>
Date: Fri, 15 Jun 2001 13:59:27 -0700

Hello Gary,
Gary Kenward wrote:

> handover? Or are you expecting to do both?

It seems to me that quite often, if the mobile is going to
initiate a handover, it will request that the context features
should be transferred at the same time.  However, I do
not suggest that we should make such a restriction.
Is it necessary to be explicit?

> Do you expect to complete

I would hope that any system built to support VoIP would complete
a context transfer within 60ms.  Perhaps systems built that require
mobile-initiated context transfers will take longer than others, but
still fit within the time requirements.  It would depend on many
factors.

Regards,
Charlie P.