Subject: [Seamoby] Re: Regarding CAR Discovery - Sleeping WLAN interface case

From: "James Kempf" <[email-masked]>
Date: Sun, 24 Mar 2002 16:20:23 -0800

(note: I've taken this to the list...)

> - MN is attached to AR_current of cellular and "MN has expressed the
requirement with AR_current" to let it know whenever hot-spot access
opportunity exists. Note that, MN may not  be able to detect hot-spot
access by itself as WLAN interface is sleeping for power saving. Since
AR_current knows the capabilities of GAARs  (thanks to AR <-> GAAR
capability exchange part of CAR discovery), it knows that WLAN access
exists in neighborhood and it can intimate so to MN. It is then "upto
the MN to decide" if it wants to fire up the WLAN interface and start
scanning.

So the key is "expressed the requirement." What does this mean? Does the
MN periodically poll the AR for this information, or does it send a
subscription to receive a notification that then gets passed along as
part of the MN's context transfer when the MN moves?

> - During scanning, MN can do further capability discovery either as in
example 1 (AR_current assisted) or example 2 (AR_current non-assisted)
mentioned below. Note that, MN may detect more than one WLAN beacons
during scanning as well. Also, it is worth noting that it is not the
only option that CAR discovery information be available through WLAN
interface. It could be obtained over cellular interface from AR_current
(example 1) or over WLAN interface from GAAR (example 2).
Performance/implementation tradeoffs will determine the best option. In
fact, if AR_current's assistance is sought for CAR discovery (example
1), there may not be need to unnecessarily fire up WLAN interface if the
capabilities of WLAN access do not match MN requirements. Even more
power saving!

I had in mind primarily the latter. If the MN brings up the WLAN
interface, there is no need for CAR discovery because it just needs to
Neighbor Discovery (in IPv6). CAR discovery is only of interest if the
MN wants to find out about other media options prior to bringing up the
interface.

> The requirement of indication of WLAN access in neighborhood, may be
"expressed by MN explicitly with AR_current", or "statically configured
in MN's profile" which may get transferred from AR to AR as handoffs
occur. The requirement can be even more fine-tuned: "Tell me when WLAN
access of certain provider (organization) is available in neighborhood"
or "tell me when WLAN access which I am authorized to access is
available in the neighborhood" etc.

Sure, but the issue is whether the MN periodically polls or there is
some kind of subscription/notification protocol that gets passed along
with context transfer. The former is simpler, the latter more bandwidth
efficient.

            jak

> Please let me know what you think about it.
>
> Best Regards,
> Hemant
>
> -----Original Message-----
> From: ext James Kempf [mailto:[email-masked]]
> Sent: Sunday, March 24, 2002 12:31 AM
> To: Chaskar Hemant (NRC/Boston); [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> Trossen Dirk (NRC/Boston); Krishnamurthi Govind (NRC/Boston); Chaskar
> Hemant (NRC/Boston)
> Subject: Re: Regarding CAR Discovery
>
>
> Hemant,
>
> These ignore what is likely to be a common case, namely:
>
> Example 3:
>
> The MN has two interfaces, a WAN interface and a WLAN interface. The
> WLAN interface is turned off to save power. The user wants to know
when
> the MN enters a "hot spot" area so she can switch to the WLAN
interface.
> The CAR discovery information must be available through the WAN
> interface.
>
>             jak
>
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> Sent: Friday, March 22, 2002 2:20 PM
> Subject: Regarding CAR Discovery
>
>
> Hi Steve:
>
> Thanks for your short but insightful presentation on CAR discovery in
> Seamoby @ IETF53. Allow me to say few words in this email about the
> thought process that we went through during the CAR discovery problem
> formulation. This will enable us to clarify some of the points that
you
> mentioned during this presentation.
>
> For this, I would like to use two illustrative examples of CAR
> discovery.
>
> -------
>
> Example 1:
>
> Here, an MN connected to AR_current hears a beacon from a nearby
access
> point (AP_new). Note that this beacon may not contain the IP address
of
> AR_new that governs this AP_new. MN passes on this beacon information
to
> AR_current, and AR_current has to map it to the IP address of AR_new.
> AR_current then compares the capabilities of AR_new with the
> requirements expressed by MN. These requirements are expressed by MN
> prior to handoff and are made available to AR_current for CAR
discovery.
> If good match is found, AR_current deems AR_new as a CAR. A similar
> process could occur for every AP beacon heard by MN and other CARs
could
> be discovered as well. CAR discovery ends here.
>
> CAR discovery output, i.e., this set of CARs, is one parameter used by
> the target AR (TAR) selection algorithm. The output of TAR selection
> decides where the MN actually hands off to. It could even be to an AR
> different than CARs discovered as above. This TAR selection algorithm
> may reside in the MN and/or the AR. Depending upon implementation of
TAR
> selection process, the CAR IDs (possibly along with their
capabilities)
> may have to be sent to the MN for selection.
>
> Example 2:
>
>
> In this example, an MN can actually connect to the AP_new and then by
> using, say, router solicitation, get the IP address of AR_new. It can
> then solicit the capabilities of AR_new over the new IP layer
connection
> it has established and compare them with its requirements to identify
> whether AR_new is a CAR. This process can be repeated for every beacon
> heard by MN. Again CAR discovery ends here.
>
> The output of CAR discovery is fed as one input to the TAR selection
> algorithm, wherever it resides, and the TAR selection algorithm then
> decides the AR that the MN will be handing off to.
>
> ------
>
>
> There are performance differences between examples 1 and 2 with
respect
> to wireless bandwidth efficiency, speed of CAR discovery, utility
> towards fast/smooth handoff protocols, MN power saving etc.
>
> Nonetheless, the following is true:
>
> - MN's requirements are always considered during CAR discovery. In
> example 1, this is done by expressing them with AR_current a priori,
> thereby allowing AR_current to compare them with the capabilities of
> AR_new, and in example 2 by doing comparison of MN's requirements and
> AR_new's capabilities in MN itself. Thus, the network does not
"decide"
> on behalf of MN, it however may do some processing for efficiency
> purposes.
>
> - Following CAR discovery, it is TAR selection process which decides
> where the MN is handed off to. This selection process, as pointed out
> earlier,
> uses CAR discovery as one possible input for this final decision.
Also,
> CAR discovery, either network- or MN-based, does not force any
handoffs.
>
> Thanks for your patience in reading through this email.
>
> Best Regards,
>
> Hemant
>
>
>

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

---

From: "James Kempf" <[email-masked]>
Date: Sun, 24 Mar 2002 16:20:23 -0800

jak

when
interface.
you
access
of
to
discovery.
could
TAR
capabilities)
connection
respect
"decide"
Also,
handoffs.