|
Dear All..
Basically I agree with Itzik's view..
I think that current document does not have any
critical problem and unclear operation about handover...And I don't see any
benefit and enhancement from NBR-ADV message...
As you proposed, the NBR-BEA-ADV message may be useful
to assist the handover, However, I think there is one thing for that
message....
Because the NBR-BEA-ADV message containing neighbor
list BS's information (QoS, BW and so on) should be updated very quickly(nearyl
real time and in line with the neighbor BS) according to the nieghbor list BS
environment to notify the recent information to the MSS, it could be increased
that the BS exchanges its message through the backhaul network. As result
it could make overload on the backhaul network and air interface...And
also, If the information sent by NBR-BEA-ADV is not
recent information, the scanning by the MSS could not be useful and
give an unpredictable operation..
Thanks
Changhoi Koo
----- Original Message -----
Sent: Wednesday, October 15, 2003 12:41
AM
Subject: Re: stds-802-16-mobile: Handoff Ad
Hoc group
Itzik,
Beacon can decrease the incidence of MSS needing
to Range Neighbor BS by providing Neighbor BS information like course
measurement air interface loading and QoS availability that can give MSS
insight into whether it should even be interested in hand-over to Neighbor
BS. This is in addition to providing physical channel information that
can allow MSS to more quickly find and scan Neighbor BS. Beacon's intent
is to provide additional information on a periodic basis to allow slow moving
or immobile MSS in a given geography (the majority of mobile devices in use
usually fall into these categories) insight into the Neighbor
BS opportunities around them without the MSS having to Scan, and
especially without having to Range Neighbor BS. Efficient mobile
networks MUST avoid as much unproductive Ranging as possible. If a
Ranging event is not going to become a hand-over, it is essentially
unproductive and unnecessary overhead. To a lesser degree, Beacon can
also help reduce the time MSS spend unavailable to Serving BS while MSS are
Scanning Neighbor BS. MSS unavailable to Serving BS impacts QoS so is
less desirable structurally.
As far as replacing full sections in the current
document, in general I don't think I am espousing wholesale replacement.
My contribution 54 did have a lot of language changes, but it is clear that
the document needs a lot more clarity in its prose and most of the language
changes were clarification and extension, not the wholesale replacement of
concepts. Also, as we all agreed, the hand-over process definitely
needed work, and all of my other contributions only pertain to cleaning-up the
hand-over process.
Once again the primary function of my
contribution 54 is to clean-up what is currently a messy hand-over
process. When I say messy I am referring to excessive, non-productive
backhaul loading, Scanning and Ranging; a poor mechanism for recovery from
failed or discontinued hand-over events; inadequate advantage taken of the
many opportunities during hand-over to correct for missed or failed steps and
still have a successful soft hand-over; inability to conduct a soft hand-over
after MSS dropping from Serving BS (i.e. hand-over without prior
notification); etc....
Thanks,
Phillip Barber
----- Original Message -----
Sent: Tuesday, October 14, 2003 3:44
AM
Subject: RE: stds-802-16-mobile:
Handoff Ad Hoc group
Hello All,
First, let me say that I'm happy to see a
discussion going on.
Second, Phil, I may be missing something, but I
don't see how beacon message at the serving BS replaces Ranging at potential
target BSs.
Also a general note, from my perspective, there are
many ways to do a cretin functionality, different ways does not mean that
one is better than other.
I
would have liked to see a process ,in which problems (or points of
improvements) in the current document are identified and handled.
I
prefer to avoid of replacement of full sections if this not fully
necessary.
Thanks,
Itzik.
Thanks for the input. I will look at
breaking the MOB_BEA_ADV message up and adjusting broadcast
timing to reduce impact on the air interface efficiency.
Probably make allocations over several non-consecutive frames
optional. Can't leave the Beacon hanging too long or it interferes
with sleep-mode activity. Probably no more than 16 total frames
for Beacon transmittal.
It is problematic to only transmit change
information in the TLV. On the one hand, it reduces overhead to only
transmit change information, and full TLV information is redundant to MSS
attached to the Serving BS. On the other hand, providing change
information TLV only impacts MSS attempting to gain information for
initial network connection, not hand-over. On reflection, since MSS
initial network connection is less timing sensitive, I would agree that
transmitting only change information in the TLV is appropriate and
efficient. I would say that we would likely need to transmit
entire/clean Beacons every 10th or 20th Beacon transmittal or so to
provide accurate and complete information to MSS that have connected to
the Serving BS in the interim between full Beacon messages and therefore
do not have basis information from which to evaluate change only TLV
information.
I remain convinced that the broadcast Beacon
is the way to go instead of using intrusive and unnecessary/constant
Ranging of adjacent Neighbor BS. Better to have a larger broadcast
Beacon eating-up downlink airtime every five seconds or so than a lot
of unnecessary and intrusive Neighbor BS Ranging. Might even look at
stretching the max interval threshold. 5 seconds might be an
unsupported tight window for static cases. Most mobile systems spend
the vast majority of their time in relatively static performance making
excessive mobility management overhead (too frequent Beacon broadcast in
our case) an unproductive burden. To be sure, for high mobility
environments with frequent hand-overs, 5 seconds or less between Beacon
broadcast may be optimal. But I think we should caution on the side
of more relaxed specificity on max interval and leave it to
the manufacturer to create appropriate Beacon broadcast timing
mechanisms.
Thanks,
Phillip Barber
----- Original Message -----
Sent: Tuesday, October 14, 2003
1:43 AM
Subject: RE: stds-802-16-mobile:
Handoff Ad Hoc group
Phillip,
As you stated in your document, the MOB_BEA_ADV msg is much too
large. I would suggest to make another effort here and maybe fragment
the message and transmit it is pieces. One possible cut is to have the
"header" portion (BS ID, Operator ID, Network Type etc.) along with some
of the slow changing info of the BEA_ADV TLV transmitted once in a
while. You may also consider transmitting the neighbor info in pairs and
have the entire message come up at the receptor side in a slower rate,
but consuming lower bandwidth off the link.
We all are looking forward to review your
contribution.
Ofer
I hope to have my contribution ready for
submittal to the reflector for peer review by the end of this
week. I look forward to your comments.
Thanks,
Phillip Barber
----- Original Message -----
Sent: Tuesday, October 14, 2003
12:38 AM
Subject: Re:
stds-802-16-mobile: Handoff Ad Hoc group
Dear Phillip Barber.
I would appreciate your effort on AdHoc
activities
I think we need a clean-up version
including your comments as followings and it would be good reference
to peer review your contribution..
Even I have a couple of comments on your
contribution, it would not be better at this point according to your
mail.
And I'd like to know your schedule when
are you going to distribute a clean-up version so that I
can have a chance to revise my comments
Thanks
Changhoi Koo
----- Original Message -----
Sent: Tuesday, October 14, 2003
6:29 AM
Subject: stds-802-16-mobile:
Handoff Ad Hoc group
Itzik,
Just wanted to drop a note and let
the Handoff Ad Hoc group know that I am--taking into consideration
Vladimir and your comments from Session 27 in Denver--re-working
my contribution number 54 into r4 of the current 16e
document. I hope to have my submittal ready for the
reflector by the end of this week for peer review.
Based on comments at Session 27, I
plan two changes to my contribution 54 proposal. First, For
those who wish to use Association as a mechanism to set initial
power settings for 6.2.9.5 Ranging instead of using the refined
method based on received signal characteristics interpreted during
dowlink/uplink synchronization as presented in the current
iteration of the 16d document, I plan to continue to include
Association, but as an optional, passive activity with
application to 6.2.9.5. I will provide appropriate
language. I had previously espoused removal of Association
in its entirety. Second, I will clean-up my sleep-mode
changes to work with contributed changes as of Session 27.
Itzik, could you make a stab at providing my corrected
formula and send it to me for inclusion? I will also
clean-up my hand-over flow diagrams to reflect these changes,
including your comments regarding other-Target BS
notifications.
Thanks,
Phillip
Barber
|