Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: stds-802-16-mobile: Handoff Ad Hoc group



Title:
Phil, Jeff
 
Small comment on this:
When you are looking at the case of MSS performing only passive scanning, i.e. without ranging, and I think that in most of the cases, this assumption is rational, then the beacon message does not have such an advantage. Making the availability checks when it's relevant, by the serving BS, either in a distributed method, centralized (by having a knowledgeable server) or totally unmanaged way (e.g. decide only based on MSS channel state information), seems to have the better performance.
There are several points which should be discussed here:
1. What will be the cycle rate of sending the beacon message
2. Is the information published is up to date.
3. How do we deal with the fact the even if the information published is up to date, it still does not provide enough effective information for a decision making.
 
Since our target is to have an efficient handoff scheme, in a verity of scenarios, we should make sure that we have a simple and effective solution.
Looking at the "both" approach, which was raised, must be analyzed and rationalized.
 
Regards,
Itzik.
-----Original Message-----
From: owner-stds-802-16-mobile@majordomo.ieee.org [mailto:owner-stds-802-16-mobile@majordomo.ieee.org]On Behalf Of Phillip Barber
Sent: Tuesday, October 28, 2003 17:51
To: stds-802-16-mobile@ieee.org
Subject: Re: stds-802-16-mobile: Handoff Ad Hoc group

Jeff, either I am confused or you have misunderstood one of my concerns.
 
I would describe a network where BS or BSC manage hand-over list prioritization as, at best, moderately distributed, but certainly network managed.  While this is common in current managed networks, we should fully expect an 802.16e network model (one of many we should seek to support) that can and is completely distributed and un-managed.  That is to say, the MSS build their own list for hand-over and manage and conduct the hand-over themselves without intervention or participation of a centralized control mechanism.  I expect this model, as well as many in between, to be valuable in advancing the popularity of the standard.  To accomplish this, the MSS must have information to base their hand-over list prioritization on, and must have a flexible hand-over process that MSS can initiate and control.  The advantages of this type of architecture, for certain applications, are obvious.
 
All that being said, I agree that your recommendation of using the HO notification and response would give MSS essentially the same information, probably less dated.  The problem I have with your proposed mechanism is that it is unicast, not broadcast.  In any sort of loading model, the unicast data, redundant in many respects amongst connected MSS, could start to seriously crunch into payload capacity.  I should expect a unicast model to seriously impact air interface and backhaul capacity in short order.
 
As far as the Beacon increasing MAC complexity, I think you will find that it vastly simplifies the hand-over and hand-over recovery processes, thus simplifying, not increasing complexity in the MAC.  Remember, so far all I have done is substantially decrease Beacon frequency while increasing Beacon payload some.  Also, I have made some backhaul and notification options optional and increased flexibility in the mechanics.
 
I agree completely that making backhaul notification to all or even some Neighbor BS should be made optional.  I have espoused a revision to the hand-over process that allows for several points in the hand-over process for the connection and service flow states to be transferred to the Target BS, and the Target BS only, and achieve a robust and successful soft hand-over.  My revision does not preclude or affect conducting the hand-over as currently conceived in the R4 doc.  Once again, each can choose the implementation specific, dynamically modified method they feel most appropriately meets their needs.
 
FYI to the group.  I continue to diligently work on my revision.  It is a hard slog, but I hope to be done shortly.  I am incorporating changes based on comments received at Session 27 and through this list.  Thanks for your patience.
 
Thanks,
Phillip Barber
----- Original Message -----
Sent: Tuesday, October 28, 2003 6:05 AM
Subject: Re: stds-802-16-mobile: Handoff Ad Hoc group

Philip hi,

You wrote:

>Your answer is very true for traditional, fully managed networks, both fixed
>and mobile. 

Agreed.

>But restricting distribution of dynamic network performance
>information precludes distributed hand-over decision mechanisms which likely
>will be an important supported network topology. 

The current HO decision mechanism is already "distributed" in the sense that the
MSS receives a prioritized (and possibly filtered) list of acceptable target BSes
from a centralized decisionmaker before choosing a BS according to the Rating
and its own criteria. 

I would suggest a qualification that might make a Beacon-less approach more
satisfactory to you:  

   - the requirement that all BS neighbors be informed about an impending handoff
    (as indicated by HO_Req/Rsp) could be eliminated  (or made optional). 

   - The MSS can then perform HO_Req/Rsp even without
   the handover event being immediately imminent.  The MSS will then know
   that "if I need to move,  BSes X and Y are available".  If the MSS then decides
   not to HO, no harm done.

   - This mechanism is similar to the beacon approach because it enables the MSS
    to know of its network conditions on a (minimally) ongoing basis.

>The answer is to support
>both managed and unmanaged networks by increasing the available, optional
>TLV elements in the beacon.  As Itzik points out, that is the crux of my
>argument.  For those not wanting to support distributed decision and
>unmanaged architectures, don't use those TLV elements.

I've tried to indicate why I think that the Beacon is unnecessary (and even
undesirable from the operator standpoint).  Additionally, it seems to lead
into adding network-management-type complexity into the MAC layer.

Regards,

- Jeff Mandin

>Thanks,
>Phillip Barber
>----- Original Message -----
>From: "Roger B. Marks" <r.b.marks@ieee.org>
>To: <stds-802-16-mobile@ieee.org>
>Sent: Monday, October 27, 2003 5:16 PM
>Subject: Re: stds-802-16-mobile: Handoff Ad Hoc group
>> [Forwarded for a non-subscriber.]
>>
>> To Philip and the TGe group,
>>
>> By way of introduction: my name is Jeff Mandin and I've started looking at
>the TGe mobility work. My specific interest is in how 802.16 mobility will
>integrate with higher level components such as Mobile IP, AAA issues etc.
>Previously I've worked on the PacketCable and CableHome standards, as well
>as with the IETF.
>>
>> Regarding the proposal for a beacon message as an alternative to the
>HO-REQ/HO-RSP exchange to select a target BS...
>>
>> The current approach is preferable for two reasons:
>>
>> 1. Service operators will not want to broadcast proprietary information
>about their network load (even if the information were encrypted). My
>experience with DOCSIS cable operators has been that they are careful to
>conceal all information about their internal network topology to the extent
>that they can.
>>
>> 2. If the BS selection decision is made at the headend, it can be based on
>policies that can include recognition of preferred customers, device types,
>traffic patterns etc.
>>
>> This is in addition to the reason mentioned before - namely that network
>load isn't fairly measured by flat bits/sec. etc.
>>
>> - Jeff
>>
>> ------------------------------
>> Jeff Mandin
>> Streetwaves Network Consulting
> >Jerusalem, Israel
>>
>> email: jmandin@streetwaves-networks.com
>> Tel: (972)-50-724-587
>> Vonage: (917)-438-9192
>>