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