Re: [STDS-802-16-MOBILE] [Handoff] Some additional thoughts on Ha ndover process
I support Phil's comments
Vladimir
-----Original Message-----
From: Phillip Barber
To: STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
Sent: 6/8/2004 7:32 PM
Subject: Re: [STDS-802-16-MOBILE] [Handoff] Some additional thoughts on
Handover process
See my comments in-line.
Thanks,
Phil
----- Original Message -----
From: Mary <mailto:mchion@ZTESANDIEGO.COM> Chion
To: STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
<mailto:STDS-802-16-MOBILE@LISTSERV.IEEE.ORG>
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
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.
************************************************************************************