Subject: [seamoby] My interpretation of the consensus on issues

From: Pat Calhoun <[email-masked]>
Date: Tue, 26 Jun 2001 20:03:55 -0700

All,

Here is my interpretation on the consensus on certain issues
that are pending:

1. Issue 1 -> consensus shows that this change shouldn't be adopted
2. Issue 2 -> consensus seems to favor this issue, but I am having
   some trouble understand some folks comments. I think that I will
   need to revisit this one.
3. Issue 3 -> consensus shows that this change should be adopted.
4. Issue 4 -> This is another of those where I feel people favor
   changing it, but we don't seem to have an agreement on the end
   result.
5. Issue 5 -> consensus shows that this change should be adopted, but
   some folks had issues with my text. Perhaps someone could propose
   new text, or I could give it another shot.
6. Issue 6 -> consensus shows that people favored my option 3, and
   the text should be worded to reflect consensus.

That leave us with 2 and 4 open, and some new text needed for 5. Gary,
could you please incorporate 3 and 6 into the draft?

Thanks,

PatC

---

From: "Gary Kenward" <[email-masked]>
Date: Wed, 27 Jun 2001 11:35:11 -0400

Pat:

  For what it's worth...

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 11:04 PM
> To: [email-masked]
> Subject: [seamoby] My interpretation of the consensus on issues
> 
> 
> 
> All,
> 

I support Kulwinder's change. The language of 4.3 is a bit soft, but at
least it removes the specific references to layer 2 triggers, and the
following
text does explain the requirement well.

>    changing it, but we don't seem to have an agreement on the end

The discussion that has been going on the list has been cantered around 
implementation issues. Each suggestion has been valid, perhaps, in the
context of the networking technology that the author has been working on,
but there are simply too many different "triggering" alternatives. About the
only suggestion I have at this point is to scrap the whole concept and
simply change the requirement that context transfer SHOULD be initiated as
early as possible. bleh.

One last note: requiring that "reactive transfer" be defined by packets
arriving, or links being established at the new AR, ignores all the tricks
one can perform at layer one/two to detect the arrival of an MN in a new
cell (e.g. by detecting a sudden shift in signal strength), and provide some
warning to the network that a handover has initiated (what's the definition
of the start of a handover? well, the first requirement has to be that the
demodulators at the two receivers be able to detect and decode 1's and 0's
with a sufficiently low probability of error; what the network does beyond
that to set up other layer one/two facilities, and generated triggers to
layer 3 is way out of scope for SeaMoby). No mobile wireless designer is
going to throw out this bag of tricks simply to conform to a convenient
definition of the start of "reactive" ct.

Certainly there are, and probably will be, layer one/two designs that do not
provide such forewarning. However, ct is supposed to work with a wide range
of mobile wireless data networks.

>    new text, or I could give it another shot.

I would ask that the references to "size" and "priority" be removed. I sense
some echoing of this view on the list. "priority" can be replaced by
"delivered as the context is needed" or "delivered as the context becomes
available" or similar phrases. "priority" is a very loaded term (e.g. my
comment about operators taking exception to the idea that "accounting
context is low priority" was
only half in jest; accounting context is extremely important to some, it's
just not likely that it needs to be transferred right away).

> could you please incorporate 3 and 6 into the draft?

Done.

You are welcome,
Gary