Fw: stds-802-16-mobile: Handoff Ad Hoc group
For some reason this did not post to the reflector last night. So I am
re-posting it. This is a response to Changhoi Koo's posting of Oct 14, 8pm.
I have removed attached history for brevity sake.
It is important to note that Beacon itself, as well as the various Beacon
TLV items separately, are optional for inclusion. Implementers can pick and
choose what they think is valuable and what to apply in their solution.
Thanks,
Phillip Barber
----- Original Message -----
From: Phillip Barber
To: Changhoi Koo ; stds-802-16-mobile@ieee.org
Sent: Tuesday, October 14, 2003 10:21 PM
Subject: Re: stds-802-16-mobile: Handoff Ad Hoc group
I respectfully disagree.
The currently proposed hand-over mechanism has several critical draw-backs,
some of which I identified for you--notification mechanisms for initiation
of hand-over and recovery on failed or terminated hand-over attempts being
the most noticeable and objectionable. With a minimum amount of
reorganization of the hand-over process and increased specification and
liberalization of opportunities to notify of intent to hand-over, it is
possible to correct for these deficiencies. Quite frankly, these changes
also streamline the hand-over process making it far simpler to implement as
well.
As far as Beacon is concerned, Beacon's function is to give MSS that may
become needful of hand-over a starting point of where to look. Beacon gives
MSS a list of potential target Neighbor BS, their operating parameters, and
even some limited information on recent air interface loading activity (even
if dated) and QoS support, all without ever having to disconnect from its
current Serving BS attachment. Armed with that information MSS could build
a 'short list' of Neighbor BS to start Scanning to determine likely air
interface and performance suitability in real time. The current MOB_NBR-ADV
message provides only enough information to let the MSS know where to find
Neighbor BS (in the RF space). Since MOB_NBR-ADV does not include any
operating information, even moderately dated information, MSS have no
information on which to formulate any decision to prioritize a potential
hand-over target list. Thus with MOB_NBR-ADV, MSS are forced to Scan
without priority selection Neighbor BS until a suitable match is found, and
likely not the best performance match.
With Beacon we are trying to balance slightly increasing backhaul loading
and downlink Beacon data loading with reducing Scanning and Ranging
activity. I believe the Beacon savings to unproductive Scanning and Ranging
activity can be significant. Unproductive Scanning and Ranging can cause a
geometric death spiral in performance on loaded networks. You have to
remember, even in mobile networks, significant changes in BS dynamic loading
USUALLY occur over periods measured in 10s of seconds or minutes. So
providing say, 30 second operational performance updates, across the
backhaul and transmitting them through the Beacon certainly does provide
some meaningful information, in most cases, for MSS to make critical
decisions regarding prioritizing hand-over targets. All by adding perhaps
2k to 4k of data transmitted every 30 seconds or so. Certainly not a burden
for backhaul. More of a concern for the air interface loading. Quite
frankly, I submit a more meaningful Beacon message transmitted every 30
seconds is far more useful and far less of an air interface and backhaul
loading factor than transmitting MOB_NBR-ADV message every 1 second.
For example, with 12 Neighbor BS for an MSS needful of hand-over to select
from (both current operator and affiliated foreign network), an MSS
selecting based on Beacon has a much higher chance of Scanning and Ranging
an MSS with much more favorable operating characteristics than one using
MOB_NBR-ADV, and doing so in far fewer Scanning and Ranging events. And, I
cannot emphasize this enough, nothing can degrade performance on a mobile
network like having a lot of unproductive Scanning and Ranging activity.
Thanks,
Phillip Barber