HSDPA Handover

[xcatas]

Dear friend,

Anyone could share more about handover in HSDPA? (events, parameters, performance, etc)

Any help will be appreciated.
Thank you very much.

BR//

[_lisi4king]

Dear friend,

Anyone could share more about handover in HSDPA? (events, parameters, performance, etc)

Any help will be appreciated.
Thank you very much.

BR//

About perfomance:

VS.HSDPA.SHO.ServCellChg.AttOut
VS.HSDPA.SHO.ServCellChg.SuccOut

[rishi]

Dear friend,

Anyone could share more about handover in HSDPA? (events, parameters, performance, etc)

Any help will be appreciated.
Thank you very much.

BR//



From the nature of the 3GPP R5, the HSPDA does not
support soft handover when UEs move across the
multiple Node-Bs so that it may cause a severe
throughput degradation and a high handover latency .
Typical VoIP applications require that minimum interarrival time (IAT) between every two incoming packets
should be less than 20 msec. Since the latency of the hard
handover is about 300׽500 msec, it cannot guarantee the
requirement of the VoIP applications. Therefore, in this
paper, we propose a new soft handover mechanism for
HSDPA to reduce the handover latency under 20 msec.
The proposed mechanism utilizes DCH as a
supplementary channel to support soft handover. When
an UE performs an inter Node-B handover, from a
serving Node-B to a drift Node-B, utilizing the DCH
enable the UE to continue its data reception gracefully
through the HS-DSCH. The UE establishes a DCH and
continues receiving data from the serving Node-B by
switching the HSDSCH into the DCH. Then, the UE
performs soft handover destined to a drift Node-B by
using general DCH handover mechanism, and changes
back the current data reception to the HS-DSCH if the
drift Node-B supports the HSPDA. We evaluate our
proposed soft handover mechanism with ns-2 simulator to
compare the performance with existing hard handover
mechanism in terms of handover latency. In
addition, we show that the proposed mechanism
minimizes the handover latency to guarantee the
requirement of VoIP applications, less than 20 msec


Events Used are 1E and 1F

[agenov]

Dear friend,

Anyone could share more about handover in HSDPA? (events, parameters, performance, etc)

Any help will be appreciated.
Thank you very much.

BR//


More info will be Ok like for which vendor you are asking for and etc...

BR

[boring]

Event 1d is typically used for HSDPA mobility (bue under specific circmstances other events could result in HSDPA mobility as well).

if you tell us which vendor that would help a lot...

[dk2000]

Which vendor are you using?

[Junio]

Hi all
Can you help me to reduce low HO success rate:(3G to 2G handover success rate_HSUPA = 18,18%)

In general all handover 3G to 2G is very low

Thanks for your help .

[auto_art]

From the nature of the 3GPP R5, the HSPDA does not
support soft handover when UEs move across the
multiple Node-Bs so that it may cause a severe
throughput degradation and a high handover latency .
Typical VoIP applications require that minimum interarrival time (IAT) between every two incoming packets
should be less than 20 msec. Since the latency of the hard
handover is about 300׽500 msec, it cannot guarantee the
requirement of the VoIP applications. Therefore, in this
paper, we propose a new soft handover mechanism for
HSDPA to reduce the handover latency under 20 msec.
The proposed mechanism utilizes DCH as a
supplementary channel to support soft handover. When
an UE performs an inter Node-B handover, from a
serving Node-B to a drift Node-B, utilizing the DCH
enable the UE to continue its data reception gracefully
through the HS-DSCH. The UE establishes a DCH and
continues receiving data from the serving Node-B by
switching the HSDSCH into the DCH. Then, the UE
performs soft handover destined to a drift Node-B by
using general DCH handover mechanism, and changes
back the current data reception to the HS-DSCH if the
drift Node-B supports the HSPDA. We evaluate our
proposed soft handover mechanism with ns-2 simulator to
compare the performance with existing hard handover
mechanism in terms of handover latency. In
addition, we show that the proposed mechanism
minimizes the handover latency to guarantee the
requirement of VoIP applications, less than 20 msec


Events Used are 1E and 1F


this is nice info..!

[twenty8]

Take note that HSDPA is a hard handover and not a SHO like R99. Its referred to as serving cell change.

[zeezzoo]

Take note that HSDPA is a hard handover and not a SHO like R99. Its referred to as serving cell change.

nope . HSDPA supports soft handover also .

but i have a question in mind :
let's assume that I'm a UE that have 3 radio links in the active set ie : in soft handover state . what are the uplink & downlink physical channels that the UE has in case R99 & HSDPA ?

is it difference when the UE in softer handover state ?

[twenty8]

nope . HSDPA supports soft handover also .

but i have a question in mind :
let's assume that I'm a UE that have 3 radio links in the active set ie : in soft handover state . what are the uplink & downlink physical channels that the UE has in case R99 & HSDPA ?

is it difference when the UE in softer handover state ?

HSDPA does not support softhandover , HSUPA supports SHO. HSDPA is a DL channel, its return channel can be HSUPA or R99 in which both supports SHO.

[boring]

HSDPA does not support SHO. there is only one serving cell

HSUPA supports SHO but it does not require it as it is the case with R99 DCHs. for example, you can set the HSUPA maximum active set size to 1 and the system will still be working without problems (although not optimally)

many people make the mistake while doing drive testing to think that HSDPA actually supports SHO. for example, when you do an HSDPA test you will often see with TEMS that the UE is in SHO. Actually the associated DCH (which carries RRC and NAS signalling which is the 3.4 kbps R99 DCH) enters/leaves SHO.

[brianm]

Thanks for the good post

[vns1_bk]

why HSDPA only use hard-handover?

[adewijaya]

are you sure about "HSDPA using soft handover" (as Zeezoo said) ? would you please prove it with your opinion above :confused:?

[_lisi4king]

Can you clarify for me HSDPA IRAT HO:

It is like HS->DCH->compressed mode -> EDGE\GPRS

or

HS->compressed mode->EDGE\GPRS ?

[boring]

Can you clarify for me HSDPA IRAT HO:

It is like HS->DCH->compressed mode -> EDGE\GPRS

or

HS->compressed mode->EDGE\GPRS ?

these days, it is the second option

[_lisi4king]

these days, it is the second option

May be you have description of it?

For me interesting: FS\2 in Compressed mode.

How it is possible, if HS this is SF=16. If will be SF=8 it is not HSDPA.

Or spreading changed only for SRB not for TRB.

:confused:

[soodlhor]

May be you have description of it?

For me interesting: FS\2 in Compressed mode.

How it is possible, if HS this is SF=16. If will be SF=8 it is not HSDPA.

Or spreading changed only for SRB not for TRB.

:confused:

What's SRB, friend? it mean control pane?

[zeezzoo]

dears

huawei R12 has the following KPI :

Service Cell Change Success Ratio with SHO (H2H)=(VS.HSDPA.SHO.ServCellChg.SuccOut/VS.HSDPA.SHO.ServCellChg.AttOut)*100%


Counter discription :


* VS.HSDPA.SHO.ServCellChg.SuccOut : This item is used to measure changes of serving cells in soft handover procedure instead of hard handover procedure. This item is used to measure changes of serving cells in soft handover procedure instead of hard handover procedure.


* VS.HSDPA.SHO.ServCellChg.AttOut : This measurement item provides the number of HSDPA serving cell change attempts for cell. This item is used to measure changes of HSDPA serving cells in soft handover procedure instead of hard handover procedure.


so here when the ue has HSDSCH (from one cell) & more than one DL & UL DCH (from different Cells) , so it's in soft handover mode . huawei call this soft handover in hsdpa .
This soft handover is done by a "Physical Channel Reconfiguration"

19494

[adewijaya]

okey, like Rishi explanation so for RAN12 is confirm about HSDPA using SoftHO :)

[twenty8]

Hi, just to make a comment on this topic. In DCH SHO there is a macro diversity gain since the actual data is send in the SHO RL's which gives the diversity gain.
For HSDPA , pre R8 there is always HHO for HS-DSCH which is the channel that carries the actual payload, as well as HS-SCCH.
Post Release8 , there is enhancement to the HSDPA mobility SCC which allows the UE to read the signalling from target cell for the purpose of serving cell change once the cell is added to active set. Further to this, the UE is able to read the HS-SCCH channel of the target cell once there is indication of change in serving cell (e1d). This may be considered SHO, but the actual data is still only send on the serving cell and not to all cell in the active set (as per DCH SHO) but the performance should be better then the pre R8 SCC.

I've attached a report which shows this performance improvements.

[twenty8]

Hi, just to make a comment on this topic. In DCH SHO there is a macro diversity gain since the actual data is send in the SHO RL's which gives the diversity gain.
For HSDPA , pre R8 there is always HHO for HS-DSCH which is the channel that carries the actual payload, as well as HS-SCCH.
Post Release8 , there is enhancement to the HSDPA mobility SCC which allows the UE to read the signalling from target cell for the purpose of serving cell change once the cell is added to active set. Further to this, the UE is able to read the HS-SCCH channel of the target cell once there is indication of change in serving cell (e1d). This may be considered SHO, but the actual data is still only send on the serving cell and not to all cell in the active set (as per DCH SHO) but the performance should be better then the pre R8 SCC.

I've attached a report which shows this performance improvements.

the attachment was rejected earlier...reattached.

[boring]

May be you have description of it?

For me interesting: FS\2 in Compressed mode.

How it is possible, if HS this is SF=16. If will be SF=8 it is not HSDPA.

Or spreading changed only for SRB not for TRB.

:confused:

Well, HSDPA uses SF 16 but don't forget that everything is scheduled on a TTI=2ms basis. HSDPA CM is implemented as higher layer scheduling (HLS) where during CM periods no data is transmitted (i.e. TTIs coinciding with CM periods are considered for schediling by the scheduler at the Node-B for this UE)

Now, for SRB you have two options:

1. if SRB is transmitted over DCH, this is using SF 256, and during CM we have again two alternatives (depending on the UTRAN vendor) either HLS (i.e. no tramsission at all during CM periods) or SF halving hence SF 128 is used.

2. In Rel7 we could have SRB over HSDPA, hence whatever we said earlier about HSDPA CM is applicable

hope this helps

[boring]

What's SRB, friend? it mean control pane?

SRB is signalling radio bearer (i.e. control plane)

[boring]

okey, like Rishi explanation so for RAN12 is confirm about HSDPA using SoftHO :)

Guys guys be careful
like i said HSDPA does not require SHO. don't forget SHO is there because of the associated-DCH for the SRB.

RAN12 also supports SRB over HSDPA which cancels the requirement for A-DCH. in this case if you use this feature then A-DCH is not activated at all and in the downlink the UE behaves like in GSM. just doing cell changes when moving from one cell to the other.

(for the uplink it depends what features you are using, but there is a possibility to have voice over HSPA calls which look identical to GSM calls in terms of mobility behaviour)

[Muaimuai]

Why I can not download att. file??
Who know the problem about it

[zeuscane]

Read forum rules
zeuscane


Why I can not download att. file??
Who know the problem about it