|
All,
The
overhead issue is not deterministic since we did not specifically define the
required periodicity of the update. If we do that, it will be easier to show the
overhead with both approaches. Until then, it is a "hand waving" argument that
cannot be resolved. Anybidy have a knowledgeable suggestion for the timing
between subsequent NBR-BEA on one side or scanning interval on the
other?
Ofer
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
|