Re: stds-802-16-mobile: Handoff Ad Hoc group
Title:
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
>>