|
All,
I also
think that the best is to have both mechanisms and use the best that fit the
application.
Ofer
Phil, Itzik
and all,
This is
about advertising of BS's ability to supply proper QoS [beacons]. It is a
useful mechanism, but it hardly can be accepted as the only mechanism. I agree with
Phil that it should be rather some additional functionality that helps
MSS to shorten list of candidate HO targets.
We have
learned that there may be several tools in the standard serving the
same purpose (correct also for system design). For example, in 802.16
multicast polling and unicast polling serve the same reservation function.
They compliment each other in the sense that in one situation multicast
polling is more effective while in another situation unicast polling is.
I think,
this is correct also for advertising vs. query [of BS's ability to supply
proper QoS]. One can easily find situations where each of above tools is more
effective than another. Particularly, query [during Association procedure] has
clear advantage of getting precise up-to-date information while consuming more
resources.
In my view, advertising QoS parameters through
beacons, though less expensive, provides fundamentally less information.
First of all, we need an estimation of
data rate(s) available for MSS at given location after MSS transmit
power adjustment and DL burst profile negotiation. The most precise way is "just do it" [initial ranging].
Second is
that there is no [known to me] way to measure capacity of BS in universal
units independent from specific QoS contracts. Bit/sec is not an appropriate
unit because of many reasons.
This is why advertising of BS capabilities [through beacons],
though useful, cannot be "one and only" mechanism for evaluation of potential
HO targets.
Vladimir
You are absolutely right Itzik. You
absolutely cannot avoid active Scanning during hand-over. It is the
first stage of network entry, including on a hand-over. But you can
reduce the number of unproductive Scanning and Ranging events that an MSS
goes through to locate the final Target BS that it alights on for
hand-over.
What I am hoping to do is provide just a little
more information to the MSS intending to hand-over so that it can prioritize
Neighbor BS for Scanning (and possible Ranging) and Scan fewer Neighbor BS
before it determines the suitable Target BS to begin a
hand-over.
Also, I think it is the combined Neighbor BS
advertisement of a coarse bits per second air interface availability COUPLED
with AvailableQoSParameter Name list that is meaningful enough to be worthy
of inclusion in Beacon. I will have to research 'Effective Bandwidth'
in the document to determine suitability.
Thanks,
Phillip Barber
----- Original Message -----
Sent: Wednesday, October 15, 2003
12:55 PM
Subject: RE: stds-802-16-mobile:
Handoff Ad Hoc group
Hello Russell and all,
I read again the NBR-BEA message, just to make
sure that I wasn't missing anything.
The effective addition of the NBR-BEA message to
the NBR-ADV message is the addition of some availability
parameters of neighbors BSs.
The advantage of such parameter is to
provide the MSS more information for an "intelligent" handoff
decision.
I think that it is not so trivial to advertise
the availability of the target BS just by using a "flat" bits per second
parameter. Availability of a BS more depends on it's specific admission
mechanism, which is implementation dependant and does not have to be well
known.
I think that approaches such
as "Effective Bandwidth" parameter (which defined with context
of admission control in the literature) should be examined to be verified
if it can fit to our needs, otherwise the approach of querying the BS
with relevant QoS requirements is more appropriate.
The relevancy of the information about the
availability of the BS is also an important issue, which should be
examined whether available BW advertised X seconds ago does provide the
MSS option have an "intelligent" handoff decision.
As for the Ranging discussion, I think that
the intention was (Phil, please correct me if I am wrong) that by
supplying enough information to the MSS, it would not need to make active
scanning. My thoughts on this issue are: (a) active scanning is just
an option, in which an MSS with enough available time can
perform also ranging with the neighbor BS, and by that reduces the time of
the handoff. MSSs can do only passive scanning (retrieve only
downlink parameters). (b) with the NBR-BEA, ranging will be done in
any case, but only with the target BS. (c) an optimization could be made
here by allocating different Ranging opportunities for handoff users, such
that they will not interfere with active users of the target
BS.
In any case, I think that downlink scanning, with
measurement of the target BS SNR cannot be avoided for fast and effective
handoff.
Regards,
Itzik.
Hi you handoff guys,
I just had to put in my two bits or is that bytes? I
think we must all agree that intrusive ranging is to be avoided as much
as conveniently possible and that we really want MSS to be as quiet as
possible. To the degree that I understand things, I think the 5
second (or whatever) beacon message makes sense.
Now I'll be silent.
Russ
Ofer Kelman <okelman@Airspan.com>
wrote:
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
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
Do you Yahoo!?
The
New Yahoo! Shopping - with improved product
search
This mail passed through
mail.alvarion.com
************************************************************************************
This
footnote confirms that this email message has been scanned by
PineApp
Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************
This
mail was sent via
mail.alvarion.com
************************************************************************************
This
footnote confirms that this email message has been scanned by
PineApp
Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************
|