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