----- Original Message -----
Sent: Tuesday, June 08, 2004 10:29
AM
Subject: Re: [STDS-802-16-MOBILE]
[Handoff] Some additional thoughts on Handover process
Hi
All,
I have the
following thoughts on HO process:
1. Since
we are considering the possibility of allowing SHO and fast BS
switching HO, we adopt an acitve set maintenance procedure regardless of the
HO type (BBM, MBB Hard HO, SHO or fast BS swiitching).
Accomodating these features can be as easy as a few
flags in the RNG-RSP.
2. I propose to
change the current HO process defined in 16e to make it more deterministic.
With the current definition, the HO decision point could be at the BS or the
MSS, and any of the messages maybe or may not be sent during a HO. I think
this allows for too many possibilities, it's hard to implement and maintain a
state machine with so many undeterminstic events. When operating and
optimizing a larget network, it would be easier to have a more defined HO
procedure. I propose we do the following:
a) The HO
decision point should be at the BS. The MSS can assist in the HO process by
reporting a list of recommaned target BS, but the BS directs to the MSS to
handover to a specific active set (the list of serving
BS).
Absolutely not. I agree that it would be nice to
simplify the option sets, but not by sacrificing core functionality.
Distributed decision topologies will be the lowest cost, first systems
deployed. Mandating BS control of HO decision guarantees higher cost and
complexity--and longer development cycles. Ultimately, the more complex
systems with their higher functionality will prevail. But smaller, early
deployments should not be constrained. In fact we should do
everyting possible to increase the likely successful solution models,
especially early penetration models, not restrict the solution set to our own
preferred models.
b) There is a
minimum pair of messages have to be sent during a HO: BS Handover Command (or
if we don't want to add a new message, we can just use BS Handover Request to
direct the MSS) and MS Handover Indication. When the BS decides a HO
should take place and chooses the new active set, the BS should send BS
Handover Command to the MSS. When the MSS has performed the HO, the MSS
should send MS Handover Indication to indicate the status of the handover. The
MSS can use this message to Reject the HO if it has to.
HO
information and decision messaging needs some clean-up. But I don't
believe wholesale change is required.
c) For the MSS
assisted HO, the HO can be triggered by the MSS sending MS Handover Request.
However, this message doesn't have to result in HO. The BS should send BS
Handover Response just to stop possible retransmission of MS Handover Request
message. For BS triggered HO, the BS just need to send BS Handover Command to
start the HO process.
You
can't stop MSS HO. A BS can always refuse to allow a MSS to HO.
And an MSS can go right ahead and drop that Serving BS and commence network
re-entry with a Target BS, with valid MSS context collected from the Serving
BS. And there is nothing the Serving BS can do about it. So BS
ability to restrict MSS HO is marginal at best. We reflect that reality
in our current HO processes.
d) I believe no
matter what type of HO we are supporting, we should use the same HO process as
defined above with possiblity different parameters included in the message.
i.e. For a HO with Level 3 backbone communication, the BS Handover Command
message can indicate skipping certain steps when the MSS performing network
entry at the target BS (maybe just ranging necessary).
Forget Serving BS telling MSS
what type of HO to expect at the Target BS. The Target BS can tell
the MSS itself in RNG-RSP. Better recovery mechanism
regardless.
Just some of my
thought. Thanks.
Best
Regards,
Mary