Subject: RE: [seamoby] MM vs CT ( was FW: CT problem statement and CNP

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 7 Mar 2001 17:53:30 -0500

We discussed this issue on the CT team.  Below you will find the short
thread.

A better place for it might the MM mechanism, or MM protocol.

- Kulwinder.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2001 3:21 PM
> To: [email-masked]
> Subject: [seamoby] MM vs CT
> 
> 
> Hi all,
> 
> I'd like to get everyone's feeling about an issue.
> 
> It has been suggested that a handoff mechanism
> may like to know the capabilities of a handoff 
> target.  This could be useful, for example, when
> there is more than one target.  The handoff 
> mechanism may want to chose the one which
> fufills the QoS requirements, for example.
> 
> My question is: what design team should tackle
> this issue, MicroMobility or Context Transfer?
> 
> thanks,
> John
> 

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Thursday, January 18, 2001 2:23 PM
To: [email-masked]
Subject: CT problem statement and CNP

Hi,

I changed the subject a bit.

I agree with Kulwinder about the administrative context, and Phil: I am not
talking about negotiations either:) In order to make context transfer/
handover as successful as possible, the source should know about its
neighbors and their capabilities, such as supported QoS, AAA mechanisms
(diameter, radius) and such.

So we might want to talk about possibility of capability transfer (in
reverse direction and maybe prior to context transfer) as a part of problem
statement.

This might be going into solution space, but we are talking a lot about
context transfer failure and protocol mismatch, so I feel, we should at
least take a position about whether we want to have capability transfer as
part of a context transfer protocol or not (I am favorable to it) and if not
mention it in the problem statement.

The reason, I am for it, is that, it would also make any protocol like
Phil's contract net protocol go smoother by making it proactive, rather than
ACK/Nack type protocol.

Regards,
Madjid

-----Original Message-----
From: Jukka Manner [mailto:[email-masked]]
Sent: Thursday, January 18, 2001 1:26 AM
To: [email-masked]
Subject: Re: About CT & 'Negotiation'

        Hi,

        I know the idea of deciding on the target of CT is part of the
solutions
space, but I would (not sure though) see that some mentioning of this could
be
part of the the problem discussion: what could Seamoby do better than the
present schemes don't do...

        Jukka

On Wed, 17 Jan 2001, Kulwinder Atwal wrote:

>
>
> >     Hi, addiotonal question to that:
> >
> >     If there are two candidate ARs (CARs), of which one
> > could provide a PQ
> > and the other can only provide MAQ. Shouldn't the current AR
> > have a way to know
> > this beforehand, or at least get feedback from the new AR
> > about how well it can
> > support the transfered context?
> >
> >     I know we are moving into the implementation/technology
> > too soon...
> >
> >
> >     Jukka
> > > > I've clipped your comments out, but I wanted to address Context
> > > > Negotiation & Context Transfer thread.
> > > >
> > > > IMO, the 'entity' (the piece of code, for example) that decides
> > > > whether to hand-off or not, should decide if the target
> > > > node can support the handoff.  I don't think that should be
> > > > part of the context transfer.
>
> I referred to this about a month ago, but I was accused of jumping into
the
> solution space way too early.  We need two classes of context:
>
> - Micro-flow Context
> - Administrative Context:
>
> Administrative Context: Context that describes the QoS policy of the APs
> nearby.
>
> I referred to it as a Radio Map for a hetrogenous neighbourhood, and a
> Tri-cell for a homogenous neighbourhood.  A Tri-cell because a minimum of
> three pionts are needed to triangulate the relative position of a mobile
> based on signal strength.  And a Bi-cell becuase a minumum of two points
are
> needed to get a fix on relative velocity.  This of course assumes that
> Multi-path and other types of Interference are managable.
>
> But, again I have digressed into solution space.
>
> - Kulwinder.

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 7 Mar 2001 18:16:38 -0600

Thanks Kulwinder, for sending the emails.
Boy, I have the memory span of a parrot, I did not think of the thread!!

My  feeling is (cheating and reading from the old email :) )
that the knowledge of neighbors capability is necessary to make a wise
handoff decision. The MM team is mentioning this in their plug and play
discussion. Although, I fail to locate the exact section in the draft right
now, I believe the MM team has taken on the task of solving the problem of
[which AR/AP to handoff to] (if not blame, it on my parrot memory).

So it makes sense that the capability discovery should be considered as part
of handoff decision (in MM team). However, I think that signalling of
capability (since it is a "type of context", but in reverse direction) is
part of the data that needs to be transferred during a handover, so IMHO,
the transfer of capabilities should be handled by CT DT.

Did I make any sense?

Madjid

-----Original Message-----
From: Kulwinder Atwal [mailto:[email-masked]]
Sent: Wednesday, March 07, 2001 4:54 PM
To: [email-masked]'; [email-masked]
Subject: RE: [seamoby] MM vs CT ( was FW: CT problem statement and CNP

- Kulwinder.

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
Sent: Thursday, January 18, 2001 2:23 PM
To: [email-masked]
Subject: CT problem statement and CNP

Hi,

Regards,
Madjid

-----Original Message-----
From: Jukka Manner [mailto:[email-masked]]
Sent: Thursday, January 18, 2001 1:26 AM
To: [email-masked]
Subject: Re: About CT & 'Negotiation'

        Hi,

        Jukka

the
are

---

From: Kulwinder Atwal <[email-masked]>
Date: Wed, 7 Mar 2001 19:45:25 -0500

> Sent: Wednesday, March 07, 2001 7:17 PM
> To: 'Kulwinder Atwal'; [email-masked]'; [email-masked]

Some parts may not need to be transferred during handover, but can be
transferred during Neighbour Capability Discovery.  For example, what are
the max. physical limits of neighbour AR/AP?  Here think MNs / Mobile
Routers/ Auto Configurable APs/ARs.  

If a device has a request that exceeds the physical limits of a neighbour
there is no point in even starting the handoff signalling.  The current
AP/AR can inform the mobile that the handoff is denied due to an unsupported
feature (ie. 100 Mbps channel) on the neighbour.

But, also there are the max. logical limits (ie. too many current
connections) on the next AP/AR that can be apart of the Handoff Negotiation.

- Kulwinder.

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 8 Mar 2001 09:17:28 -0500

Why don't we wait and see what comes out of the CT and MM requirements
and solution discussions before deciding. It would seem that we don't have
a good shared handle on the issues, and we certainly do not know yet what
capabilities
CT or MM might have to support this function.

gary

> Sent: Wednesday, March 07, 2001 5:54 PM

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 8 Mar 2001 14:37:01 -0600

Gary/ James,
 
That is a good point, however, as I suggested, the two (or three, if people
want) groups should keep the line of communications open through at least
through meeting minutes (Not that I am adding to the formality here, so far
we had minutes, that is all) and not wait until the end of the requirement
work. 
I think Phil N. had these sort of issues in mind, when he once posted the mm
meeting minutes on the WG list, I personally enjoyed the news break. This
should happen regardless of which team the item goes to.
 
BR,
 
Madjid

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Thursday, March 08, 2001 8:17 AM
To: 'Kulwinder Atwal'; [email-masked]
Subject: RE: [seamoby] MM vs CT ( was FW: CT problem statement and CNP

gary 

> From: Kulwinder Atwal [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> From: Nakhjiri Madjid-MNAKHJI1 [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> From: Jukka Manner [ mailto:[email-masked]
<mailto:[email-masked]> ]