Subject: RE: [seamoby] cart-before-seamoby

From: "Michael A. Ramalho" <[email-masked]>
Date: Wed, 03 Jan 2001 11:00:53 -0500

Kulwinder,

I have few comments/questions below.

I would like to thank you for providing enough background
information for me to comment on.

Please take my comments as constructive comments and/or
questions ... I've included a lot of commentary whose purpose
is to help clarify seamoby assumptions ... I am specifically
trying not to flame you. Sometimes that is hard to tell via email :-).

Michael Ramalho

At 06:40 PM 12/29/00 -0500, Kulwinder Atwal wrote: 
>
> Thankyou for making me aware of some the SeaMoby history.
>  
> The reason that I agree with Mike's observation is that have not heard 
> the discussions mention two things: Time Scale and RF Energy Gradient.

These seem to be related to a particular network technology, right?

That is ... given a network (radio/spectrum) design ... then "network
handoff triggers" are determined by the network designers ... and these
triggers can use such information to help determine when the
"triggering events" should be requested, right?

There is nothing in our draft-blair-rt-mobileipv6-seamoby that precludes
such measurement or *network* triggering events.

What our draft includes is other triggering events potentially generated
by the mobile for the case where it desires to move to either a
different link layer technology (potentially provided by the same
or different service provider) or the same link layer technology
provided by another service provider.

For the case where the mobile can listen on more than one radio
interface/technology ... the *seamless* make-before-break case is
more likely ... and the "handoff decision" heuristic (based on these
"handoff triggers") can be based on whatever information the network
or mobile decides to use.

For the case where the mobile can only listen/tune to one radio
technology/frequency at a given time AND there is *not* sufficient overlap
of the coverage (of the present service provider) ... then *specific
technology link layer metrics* (as I presume the RF gradient
stuff is) is essential to the *design or layout* of the network/spectrum.

Of course, the design is, in turn, dependent upon how fast/efficient
the context transfer mechanism is ... so there is some circularity
in the argument ... but only FOR THE CASE OF NOT SUFFICEINT
COVERAGE OVERLAP AND ONLY ONE RADIO/TUNER. This is
an important case in the present ... but likely less so in the future.

In the future, I hope that:

1) a given volume will either be covered by more than one technology
and/or service provider, and
2) that mobile devices can listen/tune to more than one radio technology
at a given time (heck ... even my car radio is really two radios, using
diversity technology to decide which signal is stronger!).

Lets make sure that seamoby accommodates the "single radio/coverage"
case above ... but let us not optimize for it alone. Please.

>
>  
> The time scale of events will determine what parts of the context need to be
>  transferred when, what paging messages need to be sent and when, and what 
> the structure of the hand-off needs to be.  Since I am new, maybe this info 
> is in some document I have yet to read.  At the chance of re-hashing, 
> I will expand on what I mean by Time Scale and RF Energy Gradient.
>  
> In the draft Realtime Mobile IPv6 Framework looking at the first diagram, I
> have 
> noticed that the overall view of the network is in the static physical
> domain.  
> In real-time systems if we what to maximize the efficient use of available
> system
>  bandwidth the overall view has to be in time domain.  We need to do the
> right 
> thing at the right time in the right place.  

We have examples in the Appendix of particular handoff movements and
examples of how to transfer context for these cases. The sequencing
of events are important .... particularly so for a particular technology under
consideration. But this is a design issue for a particular technology (thus
these examples were put in our appendix ... and not a cornerstone of our
framework draft itself).

I hope that seamoby defines a kind of framework or unified design principles
that can be applied to particular technologies. That is ... we need to
understand
the constraints of present technologies ... but not necessarily optimize around
one of them at the *potential* expense of de-optimizing a lot of other link
layer technologies.

>
> Let me expand on the time scales that 
> are relevant to this problem.
>  
> Radio Map Time Scale:  The time it takes to traverse at least three endpoint
> service areas.

What is an "endpoint service area"? Sounds like a particular network technology
to me.

>
> This is different than a Trusted Domain as we are talking about the nearest
> three endpoints
>  in the hetro net.  ( Time Scale is : ~ minute minumum)

A Trust Domain was defined as it is likely to effect whether the context
from elements in one trust domain will be accepted by another. It has nothing
to
do with latency between access routers/APs ... only with security/trust
relationships.

>
> Endpoint Service Area Time Scale:  The time it takes to traverse the service
> area of an
> endpoint.  ( Time Scale is: ~ 10 seconds minumum)

Isn't this related to the assumed movement of the mobile and the size
of the coverage area (e.g., cell) .... that is ... a *network design* issue.
For a particular *network design* this is important.

>
> Real-Time Time Scale: The time that it takes for a video stream to lose its
> real-time 
> behaviour.  ( Time Scale is: < = 10 milliseconds)

Why is video significantly different from other interactive modes of
communications
(e.g., voice)?

>
> Mobile Node Switch Time:  The time that it takes for a mobile node to switch
> frequencies.
> ( Time Scale is: ~ microseconds)

Sounds again like you are assuming the single frequency/technology case. Why
should this case *alone* significantly drive seamoby design? I think it is an
important
case to study ... especially for present designs ... but not necessarily to
optimize
about.

>
>  
> So the overall goal for all the teams is to push decision making and packet
> transfers toward the 
> Radio Map time scale, and pre-configure where ever and when ever possible.

Network handoff decision heuristics can drive the handoff process .. but we
should
*not* limit our discussion in seamoby to only this case. More below.

>
>  
> RF Energy Gradient:
>  
> In Pro-active hand-off we must ask "In our current direction of travel where
> will be the next strongest signal."  What we need is for  APs to tell us is,
> how is our signal changing over time as we travel on our current path.  This
> is the RF Energy Gradient.  
>  
> RF Energy Gradient = change in RSSI / change in time
>  
> What we need is for the APs to measure the MN RSSI at two points in time and
> send it to the mobile node.  Since the mobile node will most likely travel to
> the same places every day, the mobile node can store the QoS values for the
> APs.  When a mobile node enters an area it can send the last GUID it had for
> the area to see if the radio map has changed.  
>  

Fine ... engineering a particular network technology to measure these things
are
precisely what equipment manufacturers design. Is there any reason why access
points
that service a particular network technology uses cannot communicate this
information
to the point(s) in the network responsible for the (network, in your case)
decision.

That is, what of the above discussion is required to be specified by seamoby?

We have a lot of signaling transport and control protocols at our disposal for
this .... I see no reason why seamoby needs to (re)specify them.

In other words ... seamoby should not specify *network design* ... the market
will decide which manufacturers/designs work the best .... or other standards
bodies will offer design recommendations ... I think seamoby should steer clear
of such political rat-holes!

Again, I'd like to thank Kulwinder for the opportunity to comment ... but these
comments highlight the need for a seamoby "problem statement" that we
can all rally behind.

My hope is that such a problem statement will not suggest to the world that
we are effectively re-designing (ONLY) cellular network behavior over IP. I
would
like equipment manufacturers to do that specific job .. preferably using
(unified) design principles that are in seamoby's charter or framework
document.

Stepping off my soapbox.
>
>>
>> -----Original Message----- 
>> From: Gary Kenward [mailto:[email-masked]] 
>> Sent: Friday, December 29, 2000 5:01 PM 
>> To: 'Kulwinder Atwal'; [email-masked] 
>> Subject: RE: [seamoby] cart-before-seamoby
>>
>> You've missed the point, Kulwinder. The SeaMoby wg is tasked with writing  
>> problem statements for the three identified areas of concern, paging,
micro- 
>> mobility and context handoff. As far as I know, the ADs are also looking
for 
>> these problem statements. 
>>
>> Since the CRAPS BOF, the collection of people contributing to this area have
>> had  
>> a rough time convincing the IETF at large that there are real problems to
>> solve.  
>> Algorithms, protocols, etc., are all well and good, but the working group
>> will not  
>> proceed without the problem statements. Whether it is one or three problem  
>> statements is moot at this point. The working group consensus was to produce
>> three problem statements. Maybe once this has been completed, we can combine
>> the three into one, if that is considered a useful exercise. 
>>
>> I happen to agree with the observation that if we cannot collectively
agree  
>> on a definition of the problem, then we don't have much hope of ever
>> agreeing  
>> on a solution. Regardless, do not flame the messenger, it was not my
>> decision. 
>>
>> Gary 
>>
>> > -----Original Message-----  
>> > From: Kulwinder Atwal
>> [<mailto:[email-masked]>mailto:[email-masked]]  
>> > Sent: Thursday, December 28, 2000 4:05 PM  
>> > To: 'Michael Thomas'; [email-masked]  
>> > Cc: Dave Oran; [email-masked]  
>> > Subject: RE: [seamoby] cart-before-seamoby  
>> >  
>> > 
>> > I have been having the same thoughts.  I am of the opinion 
>> > that without an  
>> > algorithm we can only agree to disagree.  That is why I have  
>> > not made any  
>> > further input on context transfer, and instead I have been  
>> > thinking on how  
>> > to do just pro-active RF switching among dynamic hetro nets.   
>> > I have written  
>> > a two page outline for an algorithm on how to do the  
>> > pro-active switching  
>> > initiated by the MN across hetro nets using RSSI.  I will  
>> > work on it for  
>> > another day, or so before putting it out there to the wolves.  
>> >  Then at least  
>> > we will have a starting point.  
>> >  
>> > - Kulwinder.  
>> > 
>> > > -----Original Message-----  
>> > > From: Michael Thomas [<mailto:[email-masked]>mailto:[email-masked]]  
>> > > Sent: Thursday, December 28, 2000 2:03 PM  
>> > > To: [email-masked]  
>> > > Cc: Dave Oran; [email-masked]  
>> > > Subject: [seamoby] cart-before-seamoby  
>> > >  
>> > > 
>> > > 
>> > > I really wonder why we ended up with three design  
>> > > teams. I have no particular issue with the paging  
>> > > team, but it seems to me that it's really  
>> > > inappropriate to start thinking about context  
>> > > transfer isolated from what the overall  
>> > > requirements are. I assume that the goal of the  
>> > > [sic] "micro-mobility" design team is to come up  
>> > > with some set of scenarios which seamoby needs to  
>> > > consider, derive some requirements, and hopefully  
>> > > determine what the actual protocol work that needs  
>> > > to be done as well as a partition as to what  
>> > > seamoby should work on versus other working  
>> > > groups.  
>> > >  
>> > > While it seems pretty obvious that some sort of  
>> > > context transfer and forward tunnel establishment  
>> > > needs to be provided for, it's not at all clear to  
>> > > me that we should be looking to solve those  
>> > > problems without considering the framework that  
>> > > comes out of the other work; indeed, it seems  
>> > > likely to cause even more confusion.  
>> > >  
>> > >             Mike  
>> > >  
>> > 
>
>
>
>
> Michael A. Ramalho, Ph.D.
> Office email: [email-masked]
> Personal email: [email-masked]
> Office: +1.732.449.5762
> Cell: +1.732.809.0188
> Pager: +1.800.365.4578