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..
----- 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 t! iming 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