Hi
Folks,
There was some confusion regarding the
definition of virtual soft handoff and it would be beneficial if we can all
come to the same understanding of these terms. We can then discuss the
implications of these scenarios and backbone messages required to implement
these scenarios. Some of the HO scenarios are listed below. Please comments
on these such that we can come to a common
understanding.
All scenarios refer to a SS
which due to some trigger (load balancing at BS, geographical movement of
SS) disconnects from one BS (primary BS) and moves to the secondary
BS.
1.
Hard Hand-Off:
The SS disconnects from the
primary BS and then reconnects to the secondary BS. At a time the SS is
either connected to the primary BS, not connected to any BS or connected to
the secondary BS.
2.
Make before break (MBB HO)
While the SS is connected to the
primary BS, the SS also connects to the secondary BS and then disconnects
from the primary BS. At a time the SS is either connected to the primary BS,
connected to both the primary and the secondary BS, or connected only to the
secondary BS.
3.
Virtual Soft Hand-Off
Same operation as in
(2).
4.
Soft Hand-Off:
Same operation as in
(2).
As
can be see scenarios 2,3 and 4 describe a very similarly situation. The
difference is in the type of macro diversity gain
obtained.
According to my understanding:
1. Hard Hand-Off:
provides no diversity gain.
2. Make before break (MBB HO) provides no diversity
gain.
3. Virtual Soft
Hand-Off provides diversity gain by combining layer 2 information. This is
achieved by multicasting the same information through multiple BSs. On the
uplink the diversity gain is obtained by receiving the Layer 2 PDUs from
both the primary and secondary BS and using an appropriate combining
algorithm.
4. Soft Hand-Off: provides diversity gain by
combining PHY information (e.g. MRC of the OFDM/OFDMA signals). This is
again obtained by simultaneous multicast of downlink information from
multiple BS to obtain the downlink diversity and MRC the received OFDM
signals from different BSs at the central RNC to obtain the uplink
diversity.
Virtual Soft Handoff and soft handoff therefore
places different requirements on the backbone messages to be transferred and
also the information which needs to be shared to achieve the macro diversity
gain.
Please comment on this such that we have to same
basic understanding.
Regards,
-Raja
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).
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).
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.
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.
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).
Just some of
my thought. Thanks.
Best
Regards,
Mary