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