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