|
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
>>
|