Subject: [Seamoby] Examples of CAR discovery

From: "Hemant Chaskar" <[email-masked]>
Date: Sun, 24 Mar 2002 21:33:50

Hi all:

After the CAR discovery discussion in IETF53, it seems that we need to 
emphasize certain points about CAR discovery. They are as follows:

- CAR discovery always considers MN requirements while choosing CARs from 
GAARs.

- CAR discovery _does not_ make any handoff decisions. It merely chooses 
CARs (by matching MN's requirements with GAARs' capabilities) and makes this 
information available to TAR selection algorithms. TAR selection algorithms 
(whether they reside in MN or network or both) make decision about TAR for 
handoff.

- CAR discovery does not force any handoffs and it does not advocate any 
network-based handoff decision making.

- The problem statement does not advocate any specific way (network-based or 
MN-based or hybrid) of performing CAR discovery.

Below are some examples of CAR discovery (two of them are paraphrased from 
the issues draft) that emphasize above points. They are for illustrative 
purposes only and not to advocate any solution. Such examples may be useful 
for discussing CAR discovery topic further.

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.

Example 3:
----------

Here MN is connected to cellular network over one interface and its other 
interface (WLAN) is sleeping for power saving purposes.

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.

During scanning, MN can do further capability discovery either as in example 
1 (AR_current assisted) or example 2 (AR_current non-assisted) mentioned 
above. 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!

Please provide your feedback on these.

BR,
Hemant

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

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

---

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

> - CAR discovery always considers MN requirements while choosing CARs
from

This statement sounds like some other entity beside the MN is doing the
choosing (TAR selection).  I can't see the relevance of CAR discovery
other than in the following cases:

1) There are multiple wireless media options (e.g. cellular and WLAN)
and one medium has wider coverage than the other (e.g. cellular is
typically a WAN while WLAN is typically only for hotspots).
2) The MN has two interfaces.
3) The MN wants to keep one interface off while using the other.
4) The MN wants to be informed when it enters or leaves the coverage
area of the less dense coverage option.

Only the MN is in a position to make a choice, that's what Steve's talk
was all about. So I would rephrase this:

    CAR discovery provides the MN with information on CARs for the MN to
choose which TAR it wants to
    hand over to.

> (whether they reside in MN or network or both) make decision about TAR
for

Can you give me an example of when the network would want to select? In
every case where I can think of needing CAR discovery, intertechnology
handover is required and the MN must be involved in order to bring up
and connect the new interface. For single technology handover, you don't
need CAR discovery. In that case, either the network or the MN can do
it, but the choice of next AR is predetermined by the Layer 2 power
characteristics.

> network-based handoff decision making.

OK, but like I said, I don't see the relevence to network handover to
CAR discovery.

> Example 1:

If MN can hear the beacon, why doesn't it simply solicit a router
advert? There's no need for the current AR to get involved.

> be discovered as well. CAR discovery ends here.

This is too complicated. After solcitiing the new RA, the MN can decide
whether to connect or not.
What's the point of all this communication with the old AR when the MN
can already hear the
new one?

> may have to be sent to the MN for selection.

Why is this any different than Example 1? If the MN can get a beacon,
why can't it solicit an RA? And if it can't solicit an RA, then what is
the point of the MN even bringing up the interface to get a beacon? It
should just leave the interface down and use CAR discovery with the
current AR to find out if there are any routers on the other medium
around.

> towards fast/smooth handoff protocols, MN power saving etc.

This is the only example I think makes sense.

> fire up the WLAN interface and start scanning.

The current AR doesn't have to be involved if the MN periodically polls.
That's an implementation assumption.

---

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

---

From: "Eunsoo Shim" <[email-masked]>
Date: Mon, 25 Mar 2002 16:28:23 -0800

Hi, James,

My comments are inline.
Thanks.

Eunsoo
----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "Hemant Chaskar" <[email-masked]>; <[email-masked]>
Sent: Sunday, March 24, 2002 4:40 PM
Subject: Re: [Seamoby] Examples of CAR discovery

> it, but the choice of next AR is predetermined by the Layer 2 power
Please just let me remind you that the CAR discovery protocol also provides
mapping of L2 ID to IP address of the new AR which is necessary for the
low-latency handoff mechanism proposed in the MobileIP WG. So there is a
case CAR discovery is helpful for single technology handovers.

I understand the IETF is pro-end-point-control. Anyway, regarding your
question, couldn't we imagine a case when a network provider wants do a kind
of load-balancing between different access networks in the wireless overlay
network?

> advert? There's no need for the current AR to get involved.

I think the beacon in this example is L2 beacon. Isn't there a case the MN
needs to go several steps before it can send a router solicitation message?
I think it depends on the involved L2 technology. Anyway the MN can get the
information it needs without soliciting the new AR by using CAR discovery.
The point of this example seems to me that the MN does not go through such
steps to save power.

---

From: "Eunsoo Shim" <[email-masked]>
Date: Mon, 25 Mar 2002 16:28:23 -0800

Hi, James,

My comments are inline.
Thanks.

Eunsoo

---

From: "Satish Jamadagni" <[email-masked]>
Date: Mon, 25 Mar 2002 14:21:03 +0530

Dear All,
Some comments on CAR discovery -

We all agree that the CAR discovery protocol should assist in identifying
GAARs, arrive at CARs from GAARs and finally a TAR from the CARs. Throughout
this process one can see that there will be varied level of information
exchange (context information basically). When identifying the GAARs either
the MN or the AR or a edge device needs to know the geographic coverage of
that AR (one can argue that more can be added at this stage itself). Now
from GAARs to CARs one would expect that the CAR discovery protocol would
provide more than just the geographic coverage. An exchange of a very high
level view of QoS or context support information between ARs (QoS and
context types will have to be agreed upon for this) is what is expected to
arrive at a set of CARs - now till this stage the MN need not come into play
at all. The use of a MNs personal settings and preferences will come into
play at the stage of CARs to TAR. Usually (I dont know if in the future
classes of MNs can be identified and TARs selected for them as a class) the
TAR selection will be biased by the MN considerations - but then again the
MN might have prevelages with the AR so that the AR itself can achieve this
for a (or a class of) MNs.

Also there should be provision for an AR to do a TAR selection given the
fact that the service provider can have policies that can force a mobiles to
handover due to load conditions, inorder to provide better QoS when the load
on other ARs or the underlying L2 becomes available (One of the most
critical understanding of a 4G network is that there are a host of L2s with
a common IP layer and above) in the present understanding and spectrum
sharing in future SDR scenarios (Please note that inter-technology handover
is where much in the understanding of future 4G and SDR networks - we dont
want our CAR protocol to undergo a lot of changes when the notion of
seamless ness as required by a 4G or an SDR network hits the scene) .

The idea of a CAR discovery protocol SHOULD be to make available the right
amount of information at the right time for the GAARs to CARs to TAR
process. The rest i.e. the exact selection of a subset of GAARs as CARs and
the selection of a TAR should be left open for people like us to make a
living by fitting algorithms in place.

Also there were Qs like CAR being relavent in some scenarios - I think we
should not restrict ourselves to just the MN option - you never know when
the service providers would start offering that extra bit of processing at
the network level as a service differentiator -

The MN is of course the king in the TAR selection, but he can have a better
understanding with his home network when the AR can do a TAR selection for
the MN considering the MNs very private settings too. The AR if bound by a
QoS policy might want a user to go to another specific AR with or without an
underlying L2 change at his bidding.

With all the paging and solication protocols evolving there should also be a
provision for any AR to "entice" a MN into his domain - so to say there
should be provision for an AR to declare to an MN that he is the best AR for
the MN (target triggered case) - Of course how does the AR come to know of
the MN and his QoS settings - at some high level this is possible - going
lower and being sensitive to privacy issues - one will have to work out the
issues.

Regards,
Satish Jamadagni.
Research Scientist
Sasken Communication Technologies Ltd
Bangalore.

---

From: "Satish Jamadagni" <[email-masked]>
Date: Mon, 25 Mar 2002 14:21:03 +0530

Dear All,

Regards,
Satish Jamadagni.
Research Scientist

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Mar 2002 11:03:08 -0800

> case CAR discovery is helpful for single technology handovers.

OK, so what you are saying is that there are two cases:

1) Provding the MN with CAR information on what choices are available
or, possibly, when the MN moves into an area where a new choice is
possible, like moving into a hot spot area, for MNs that have multiple
interfaces.

2) Providing the AR with reverse address translation for CARs for MNs
that have single interfaces and want fast handover support.

I agree.

I don't get the feeling that these two cases are clearly delineated in
the requirements. In fact, they seem to me like they are really two
separate protocols.

> of load-balancing between different access networks in the wireless
overlay

Sure, but I think that's a very special case. The more general case (and
in fact, the case that is showing up *today*) is that one network
provider owns one medium and the other another. Example: at the airport,
the cellular provider owns the CDMA network and some WLAN provider owns
the WLAN network.

And even if both media are owned by one provider, there are probably
cost considerations that will involve asking the user whether they want
to switch.

> The point of this example seems to me that the MN does not go through
such

But if the MN already has the interface up to the point where it can see
an L2 beacon, then presumably it can also bring up IP and solicit the
RA, right?

The only case where I can see this argument working is in the single
interface case, and there I think the L2 protocol will move the MN
(either from the MN side or the network side) regardless of what happens
at the IP layer. At least, if you want any kind of performance on the
handover.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Mar 2002 11:03:08 -0800

I agree.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Mar 2002 11:17:16 -0800

> GAARs, arrive at CARs from GAARs and finally a TAR from the CARs.
Throughout

Selecting a TAR is out of scope.

> that AR (one can argue that more can be added at this stage itself).
Now

Are you talking about GPS co-ordinates or something? I don't see how the
MN could make use
of this information. All it really needs to know is what options are
available at this point
in time for bringing up the interfaces it has.

> for a (or a class of) MNs.

The requirments already have a statement about capabilities. Is this
what you
mean?

> seamless ness as required by a 4G or an SDR network hits the scene) .

I disagree about allowing the AR to "force" a handover in
intertechnology situations. For intratechnology handover, I think there
is a case to be made for the AR to be involved in handover, for
performance reasons. For intertechnology, I think that a common
situation is that both networks are owned by different providers, and
even when they are owned by the same provider, the provider is more
likely to have tariff differences between them, for business purposes.
So the owner of the MN is likely to want to be involved in making the
decision.

> living by fitting algorithms in place.

Right, that's why it is out of scope.

> the network level as a service differentiator -

The MN is the only entity in a position to know if it has an interface
supporting a particular medium or not. How can the AR make the decision?

> lower and being sensitive to privacy issues - one will have to work
out the

???? I don't understand this at all. "entice"? You mean like a coupon in
the newspaper giving you half off if you use this network on Monday or
something?

My impression of current wireless service provider business models (and
what I can reasonably imagine them evolving to in the future) is that
this not realistic.

But, really, we're not here to solve this kind of problem. We just need
to figure out how to provide the MN what it needs to achieve an
intertechnolgy handover, that is what "seamless" means.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 25 Mar 2002 11:17:16 -0800

jak

---

From: "Satish Jamadagni" <[email-masked]>
Date: Tue, 26 Mar 2002 19:48:48 +0530

Hi James,
> The requirments already have a statement about capabilities. Is this
The only thing I wanted to convey was that in the CAR discovery process
varied set of capabilities (also reflects the context supporting capability)
are exchanges at various times - Should not CT and CAR discovery be combined
( I dont know if some such discussion has happened earlier - if so please
forgive me for bringing this again). One can exchange a macro level context
support information as in the CT drafts during the GAARs and CARs stage -
finally let the MN solicit a near complete set of Context support
capabilities of the CARs to decide on a TAR - for all practical purposes the
CT would have been achieved by the time a TAR is decided..

So in the requirements spec we should have a mandate to classify the so
called context support capabilities into a hierarchy if possible (Such a
thing has been initiated in the CT drafts) so that a varied level of
information exchange can be initiated during the GAARs and CAR
identification. For TAR the MN can then solicit the remaining set.

> of this information.

MNs may not use that but the ARs can identify overlap radio coverage regions
(for both vertical and horizontal seamless handover support)

All it really needs to know is what options are
> in time for bringing up the interfaces it has.

The L2 tags achieve this dont they - provided that initially the geographic
coverage continuity of such an L2 has been verified by the AR.

Within the scope of 3G ( and other L2s) UE positioning is very much
supported (estimating the AR range can also be achieved) - Basically the
actual geographic location information handling capacity is available at
most emerging L2s - i.e. ARs tied to L2s can use the actual geographic
location information to decide on GAARs - I guess by the time we see 3G
deployments such services will also would have become equally available.
This has the advantage of supporting mobile routers or at least doesnt have
to be based on some static IDs(Then again PLEASE ignore this if you feel
this is not in the immediate scope)

Example of geo coordinatees in GAARs is that even if one were to use SLP for
GAARs - I think the "scope" will have to carry some geographic radio
coverage information. Please correct me if I am wrong.

Regards,
Satish Jamadagni

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "Satish Jamadagni" <[email-masked]>; "Eunsoo Shim"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, March 26, 2002 12:47 AM
Subject: Re: [Seamoby] Examples of CAR discovery

---

From: "Satish Jamadagni" <[email-masked]>
Date: Tue, 26 Mar 2002 19:48:48 +0530

Hi James,

Regards,
Satish Jamadagni

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Tue, 26 Mar 2002 23:12:29 +0100

Still catching up:

Satish wrote:
...<snip>...
> seamless ness as required by a 4G or an SDR network hits the scene) .

No, wait, stop. The handover policies, requirements etc. of a particular
network will guide or dictate what the relevant subset of GAARs are for
that particular network and access technology. But unless you *dictate*
that only MNs with only that particular network and access technology
may use CAR discovery, it *will* have to be the MN that does the GAAR -> CAR
and CAR -> TAR steps. If nothing else, it is only the MN that carries
knowledge of the User's particular policy with respect to cost, and which
QoS requirements the applications running at the moment has, which network
cards are there today, as James mentioned, and so on. And I really
don't think it is reasonable for the User to have information about his
policies or running applications or their QoS requirements gratuitously
transmitted to whatever APs he is currently connected to.

	Regards,
		Henrik

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Tue, 26 Mar 2002 23:12:29 +0100

Still catching up:

Satish wrote:
...<snip>...

	Regards,
		Henrik

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Tue, 26 Mar 2002 23:10:47 +0100

Catching up on this thread. Sorry if this point has already
been made:

Hemant wrote:
...<snip>>
> MN-based or hybrid) of performing CAR discovery.

I believe this is pointing us in the wrong direction. I believe it is
an essential part of CAR discovery that it is MN-centric. In other
words, CAR discovery is the process of the Networks, Current Active
Access Points and the MN itself (through stored information, scanning,
this, that, and whatever other magic is available) providing *the MN* 
with information that *the MN* can use to assemble the most appropriate
list of GAARs for *that MN* at that moment, from which *the MN* can
destill its CARs.

	Regards,
		Henrik

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Tue, 26 Mar 2002 23:10:47 +0100

Hemant wrote:
...<snip>>

	Regards,
		Henrik