Subject: RE: [Seamoby] Comments on the requirements draft

From: [email-masked]
Date: Tue, 26 Mar 2002 08:18:25 -0500

Hi Teemu,

some comments inline...

> [DOT] I certainly agree with scalability, just some comments to
> the number of several hundreds of overlapping access points. Even
> when I consider PANs, I can hardly think of scenarios where actually 
> hundreds of coverage areas overlap. Bluetooth coverage areas are not
> large enough, and I doubt that we had so many WLAN APs. But even then, 
> what counts is the number of ARs that have overlapping APs with APs of 
> other ARs. I don't quite see that this number would reach several hundreds. 
> Maybe you could elaborate a bit on the scenarios you have in mind.

Maybe "hundreds" is too much for near future, but I 
wanted to give a what-if scenario where the protocol must
also survive if there ever is such...?

[DOT] Yes, but it should be kept in mind that we don't have to design a 
protocol for picocells here since there might be better mechanisms. But again,
as I said, what counts are overlapping APs of different ARs. In most
of the cases of small picocells, I either assume many APs connected to
one AR (hence the overlapping APs of different ARs is rather small)
and/or APs with a small coverage area anyway (e.g., Bluetooth). It all
comes to the point if tens or even hundreds of APs of different ARs, overlapping a dedicated physical area is very likely. That's what I
doubt. But again, it has to scale to some extent, I agree.

> 
> 3.X INTEROPERABILITY
> 
> - Interoperability MUST exist with non-CAR ARs.
> 
> [DOT] How do you mean this? If a non-CAR is (due to the lack of identification
> and capability knowledge through CAR) not considered as a CAR, it should still
> be possible to handover to this AR? This is indeed true but not within the scope
> of CAR discovery. Since CAR discovery only gives you a set of CARs (which need to
> be identified for that), it should be ok that a CAR solution does not include 
> these non-CAR ARs (one reason might be that the non-CAR AR did not allow the 
> CAR solution's GAAR identifitication - another reasons might be that the non-CAR 
> did not reveal capabilities). However, if the MN (or the AR) would find any other 
> means to identify this non-CAR AR, and the MN (or the AR) makes the decision to 
> handoff to this non-CAR AR, that's fine and still possible. But this is TAR 
> selection, which is not within the scope of CAR discovery. CAR discovery only 
> gives you a list of CARs (i.e., ARs that match MN's requirements), which is ONE 
> input to TAR selection (wherever latter is implemented). Another input might be 
> the detection of non-CAR ARs which you might consider in your TAR selection algorithm 
> as well.

I agree with your comment. I should have written my comment:

"Interoperability MUST exist with ARs not implementing the 
CAR discovery protocol". 

What I don't know is whether interoperability is an implicit 
general requirement for all protocols or should it 
be explicitly written in the requirements draft? I guess
that even if it's not in the draft nobody will probably
make a solution where an MN can only handover to ARs
which support the CAR discovery protocol... 

[DOT] Remember, CAR discovery only determines a set of CARs,
it does not imply a certain handover decision. CAR discovery is only one of
maybe several inputs in the final decision, which is BTW called
TAR selection (and is defined out of scope for this work).
If your TAR selection, and therefore the handover algorithm, only relies 
on this set of CARs and totally neglects ARs that are not provided through 
CAR (since they do not implement the protocol), then the responsibility for 
that lies in your TAR selectio, not in the CAR discovery.  Hence,
it is the TAR selection that needs attention when considering
'non-CAR-compliant' ARs.

> 
> 
> 3.X PERFORMANCE
> 
> - CAR/GAAR protocol MUST NOT add to handover times in
>   cases when the connection to the old AR is lost and there
>   are ongoing communication waiting for network access. In
>   those cases the MN must get a new AR as fast as possible,
>   not spending much time on the TAR algorithm.
> 
> [DOT] How do decide whether it is worthwhile to spend time on CAR or not?
> If you have a TAR selection scheme that resides in the MN, it is fairly
> easy to do so. If your signal strength fades for instance too fast, you just
> skip CAR discovery and select one of the AR from which you receive a current
> beacon. But again, this is TAR selection and not within the scope of the problem.
> But if you choose to do CAR (wherever it is implemented), it will always add 
> to your handover time since you have to run certain mechanisms. How this tradeoff
> can be determined is not clear to me and looks like an implementation issue in
> the entity that runs the TAR selection (which again use CAR discovery as an input).

I agree.

[DOT] Does the agreement mean that we shouldn't consider this requirement
for CAR discovery, since it is related to TAR selection? 

Thanks,

Dirk

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Teemu Rinta-aho <[email-masked]>
Date: Tue, 26 Mar 2002 15:35:44 +0200 (EET)

Thanks for the comments, Dirk. My comments inline.

> doubt. But again, it has to scale to some extent, I agree.

I agree with that (but also see my reply to James Kempf).

Anyway, I think there should be something about scalability
in the draft..

> it is the TAR selection that needs attention when considering

With interoperability I meant that the implementation of the CAR
discovery, whatever it will be like, should not mess up existing things
and make the life of non-CAR-supporting ARs harder than necessary. I am
not sure if this kind of things should usually be written in the draft or
not, it just came to my mind when reading the draft that there is nothing
about interoperability. 

> for CAR discovery, since it is related to TAR selection? 

Exactly! It should be in the TAR requirements draft, if there
ever will be one..

BR,
Teemu

-- 
Teemu Rinta-aho                    Tel: +358 9 299 3078
NomadicLab, Ericsson Research      Fax: +358 9 299 5055
Oy L M Ericsson Ab                 Mobile: +358 40 562 3066
FIN-02131 Espoo, Finland           E-mail: [email-masked]

---

From: Teemu Rinta-aho <[email-masked]>
Date: Tue, 26 Mar 2002 15:35:44 +0200 (EET)

BR,
Teemu