PS call drop increase after enabling the FACH state

[tareq1010]

Dear experts,
PS call drop increase after enabling the FACH state. plz share your experience to reduce the call drop and what is the best values for the parameters related to FACH state.

[gprastomo]

Dear experts,
PS call drop increase after enabling the FACH state. plz share your experience to reduce the call drop and what is the best values for the parameters related to FACH state.

Hi,

It should nt be degraded, should be good to implement this FACH.

PS is PS R99 ?
What is your vendor and the parameters setting DCH/HS to FACH to PCH ?

br

[plannerguy]

Hi

pls check the timer T317

Regards
Plannerguy

[tareq1010]

Dears,
the vendor is huawei and the call drop on both R99 and HSDPA.
the T317 is 30 sec.

thanks for sharing idea

[romagdinio]

Hi,
we had the same problem in our network, and after troubleshooting we found that there are certain types of UEs that don't respond to the RB Reconfiguration message. we think it is a UE issue, so we disabled the Cell FACH in our network to enhance the CDR. so I think you have it is a trade off between the PS CDR and the resources congestion :D

[plannerguy]

Hi

To my knowledge T317 should be set to infinity.3GPP 25331 also recommends the same.


Regards
Plannerguy

[agenov]

Dear experts,
PS call drop increase after enabling the FACH state. plz share your experience to reduce the call drop and what is the best values for the parameters related to FACH state.


-> What is the cause value of these drops? Which counter is increased?
-> Have u done drive test and LMT trace?
-> do u use default ones settings of Huawei when ednabled FACH?

Br
Alex

[oswe]

-> What is the cause value of these drops? Which counter is increased?
-> Have u done drive test and LMT trace?
-> do u use default ones settings of Huawei when ednabled FACH?

Br
Alex

....;)
the reason for increasing ps_drop is because during FACH state, you dont have cell_change nor soft handover.... but only cell_reselection.
this fach channel is less protected than the other hs or dch....
that is the reason...
you will win less resources reserved in the network as when you are in fach, you are not using a whole HSDSCH.... but this wont come for free...

[agenov]

....;)
the reason for increasing ps_drop is because during FACH state, you dont have cell_change nor soft handover.... but only cell_reselection.
this fach channel is less protected than the other hs or dch....
that is the reason...
you will win less resources reserved in the network as when you are in fach, you are not using a whole HSDSCH.... but this wont come for free...


Not completely agreed with you. Of course FACH has its own disadvantages but it doesn't mean that his drop is only because of this. In my network we have activated fach long time ago and don't have problems with that.

@tareq
what is the DCR value before and after FACH ?

BR

[adewijaya]

Huawei NETWORK

UlRateThresForDCCC: The DCCC algorithm capability may be very low for some Best Effort (BE) service with very low applied maximum rate. The UL DCCC algorithm does not activate for the BE service whose applied uplink maximum rate is smaller than or equal to the threshold. Default value: 64k.
DlRateThresForDCCC: The DCCC algorithm capability may be very low for some Best Effort (BE) service with very low applied maximum rate. The DL DCCC algorithm does not activate for the BE service whose applied downlink maximum rate is smaller than or equal to the threshold. Default value: 32k.
Event4AThd: Event 4A trigger threshold. Default value: 1024bytes.
Event4BThd: Event 4B trigger threshold. Default value: 64bytes.
DtoFStateTransTimer: This parameter is used to detect the stability of a UE in low activity state in CELL_DCH state. Default value: 180s.
FtoDTVMthd: The parameter is used to define the traffic volume measurement threshold for event 4a when the state transition form FACH to DCH will be triggered. Default value: 1024bytes.
FtoPStateTransTimer: This parameter is used to detect the stability of a UE in low activity state in CELL_FACH state. Default value: 180s.
CellReselectTimer: This parameter is used to detect whether a UE is in the state of frequent cell reselection. Default value: 180s.
CellReselectCounter: For a UE in CELL_PCH, if the number of cell reselections exceeds this parameter within the [cell reselection timer], it can be considered that the UE is in the state of frequent cell reselection. Default value: 9

[jan74]

Not completely agreed with you. Of course FACH has its own disadvantages but it doesn't mean that his drop is only because of this. In my network we have activated fach long time ago and don't have problems with that.

@tareq
what is the DCR value before and after FACH ?

BR

Agreed, FACH is very useful. We have settings of 5seconds here for remaining in FACH before going to PCH and it works fine. Previously we had 10seconds for FACH, then idle and that was fine too. Currently, T317=180seconds and that is sensible in my book. You need to give some more details on the drops. Have you replicated them? What cause is given for the drop? Presumably this is only PS Drop as CS will not go in FACH. Are your state transitions working properly?(i.e. DCH to FACH)?

[tareq1010]

thanks for sharing.
the call drop increased from 0.8% to 1.3% after enabling the cell FACH state. all call drop causes were increased after enabling it. we are using the defualt values in our network and i tried to change to timers but the DCR is still high.
DCH to FACH 10Sec.
HS to FACH 10Sec
Inactivity timer 20Sec

Dear agenov,
could you please share the parameters setting for your netwok?

[adewijaya]

thanks for sharing.
the call drop increased from 0.8% to 1.3% after enabling the cell FACH state. all call drop causes were increased after enabling it. we are using the defualt values in our network and i tried to change to timers but the DCR is still high.
DCH to FACH 10Sec.
HS to FACH 10Sec
Inactivity timer 20Sec

Dear agenov,
could you please share the parameters setting for your netwok?

D2F = 5s
H2F = 5s
Inactivity Timer = 20s

Please notify with your counter, asking Huawei to double check. Then what type your Huawei Equipment 3810/3900? before 3900 need some patching software.

[jan74]

thanks for sharing.
the call drop increased from 0.8% to 1.3% after enabling the cell FACH state. all call drop causes were increased after enabling it. we are using the defualt values in our network and i tried to change to timers but the DCR is still high.
DCH to FACH 10Sec.
HS to FACH 10Sec
Inactivity timer 20Sec

Dear agenov,
could you please share the parameters setting for your netwok?

Not sure about those DCH to fACH timers.... Its unusual to hang around in DCH for so long, normally u should go straight down after DCH usage has dropped below a certain value or if there is no data left in the buffer.

Also, have u checked your FACH throughput counters to check for congestion? This is very unusual as Fach should be straightforward.

[oswe]

Not completely agreed with you. Of course FACH has its own disadvantages but it doesn't mean that his drop is only because of this. In my network we have activated fach long time ago and don't have problems with that.

@tareq
what is the DCR value before and after FACH ?

BR

Hi.
It is... unless the timers are not permitting the user to stay a considerable time in FACH... ...
we have increased the drop from 0.5 to 0.8 in every RNC where we activated cell_fach and some others RNCs doubled the value... just the next hour the feature was installed...

...of course for us is acceptable to have 0.8 with the benefit of less HS and IuB resources..... if you check the simultaneous HSDPA users youll see a huge difference.
BR.

[adewijaya]

Not sure about those DCH to fACH timers.... Its unusual to hang around in DCH for so long, normally u should go straight down after DCH usage has dropped below a certain value or if there is no data left in the buffer.

Also, have u checked your FACH throughput counters to check for congestion? This is very unusual as Fach should be straightforward.

using low packet threshold, ie : 16 or 32kb
another consideration is load of FACH refer to SDPCCH

[adewijaya]

please read it : http://www.finetopix.com/attachments/live-optimization/16992d1306851394-required-info-nbrofsccpchs-sccpch.jpg

[agenov]

thanks for sharing.
the call drop increased from 0.8% to 1.3% after enabling the cell FACH state. all call drop causes were increased after enabling it. we are using the defualt values in our network and i tried to change to timers but the DCR is still high.
DCH to FACH 10Sec.
HS to FACH 10Sec
Inactivity timer 20Sec

Dear agenov,
could you please share the parameters setting for your netwok?


Can you isolate the case at cell level to see whether there are some specific contributors or if u have nastar to see for some specific UEs and starting the investigation from there....

Adewijaya settings are OK. I would preferred them!

[agenov]

please read it : http://www.finetopix.com/attachments/live-optimization/16992d1306851394-required-info-nbrofsccpchs-sccpch.jpg


This is quite interesting. Can you give more info about Huawei implementation ?

BR
Alex

[adewijaya]

This is quite interesting. Can you give more info about Huawei implementation ?

BR
Alex

we did it on existing network now, what's anything else you need for?

[agenov]

we did it on existing network now, what's anything else you need for?


Some settings for activation and possible feedback about drawback after activation or other observation you may have....?


BR

[gprastomo]

Hi,

DCH/HS to FACH -> 10 s, usually in some vendors it should have reporting periode about 5 s to report the buffer occupancy, depends on your setting.
So the total time after buffer reporting is 15 s + pending timer 5 s = 20 s. I think its better to set the Hs/DCH to FACH < than PS inact timer, since your call will be released wth inactivity cause.
Just try to set to 5 s or 2 s. What is FACH to PCH timer ?

And just make sure your DCR formula is correct. I use HS to FACH as normal release and i exclude inactivity as drop.
So the formula will be DCR = Number of Drop/(Number of Drop+Normal release+HStoFachSuccess+H2DSuccess+H2DinterfreSuccess+H2DIntrafreqSuccess)

Cos HS to FACH is considered as HSDPA release (not drop)

br



thanks for sharing.
the call drop increased from 0.8% to 1.3% after enabling the cell FACH state. all call drop causes were increased after enabling it. we are using the defualt values in our network and i tried to change to timers but the DCR is still high.
DCH to FACH 10Sec.
HS to FACH 10Sec
Inactivity timer 20Sec

Dear agenov,
could you please share the parameters setting for your netwok?

[tareq1010]

hi,
the RB reconfiguration failures are increased after enabling the FACH state also and the cuase is UE no reply. i need to know if the call drop is happend during the RB reconfiguration or during staying in the FACH state.
the FACH power relative threshold in our network is +1dB. can you please what is the value in your network.

[adewijaya]

hi,
the RB reconfiguration failures are increased after enabling the FACH state also and the cuase is UE no reply. i need to know if the call drop is happend during the RB reconfiguration or during staying in the FACH state.
the FACH power relative threshold in our network is +1dB. can you please what is the value in your network.

please see and learn i posted before, which state transition do you need?

[gprastomo]

hi,
the RB reconfiguration failures are increased after enabling the FACH state also and the cuase is UE no reply. i need to know if the call drop is happend during the RB reconfiguration or during staying in the FACH state.
the FACH power relative threshold in our network is +1dB. can you please what is the value in your network.

Hi I have almost the same as this before in Huawei networks, but the problem is not drop call, there is difficulties of moving from FACH to HS.

I conclude that the DRD is not working well, because at that time we have 2 carriers and we implement cell barred on the 2nd carrier and when we implement the fach, this problem happend and we have bad channel swithc Succ Rate from FACH to HS, only 2%.
Then i optimize the strategy (not to barred the 2nd carriers) and put idle q offset to maximum value, then everithing is ok. It improves from 2% to 99% (Ch type swotch from FACH to HS).

But in NSN, no problem on this strategy.
Can you share what kind of strategy that you use for 2 carriers ?

MaxFACH power +1 dB is enough, the coverage of FACH is greater than CPICH, so its enaough, no problem on the FACH power.

br

[adewijaya]

Hi I have almost the same as this before in Huawei networks, but the problem is not drop call, there is difficulties of moving from FACH to HS.

I conclude that the DRD is not working well, because at that time we have 2 carriers and we implement cell barred on the 2nd carrier and when we implement the fach, this problem happend and we have bad channel swithc Succ Rate from FACH to HS, only 2%.
Then i optimize the strategy (not to barred the 2nd carriers) and put idle q offset to maximum value, then everithing is ok.

But in NSN, no problem on this strategy.
Can you share what kind of strategy that you use for 2 carriers ?

MaxFACH power +1 dB is enough, the coverage of FACH is greater than CPICH, so its enaough, no problem on the FACH power.

br

yes i done before like you in Huawei Network, 2nd carrier barred for voice but enable for MultiRAB case, so set idle q offset to 50 ( i think is enough) not to barred itself. The real issue today is FACH congestion so we need 2 SCCPCH two split up Paging and FACH (i already describe all on above)

[kilisuci_kdr]

yes i done before like you in Huawei Network, 2nd carrier barred for voice but enable for MultiRAB case, so set idle q offset to 50 ( i think is enough) not to barred itself. The real issue today is FACH congestion so we need 2 SCCPCH two split up Paging and FACH (i already describe all on above)
Hi Adewijaya,
Do you have the configuration if using 2 SCCPCH?
That describe how many used for FACH and how many used for Paging or is it 1 SCCPCH dedicated for each?

[adewijaya]

check this out : http://www.finetopix.com/attachments/live-optimization/16992d1306851394-required-info-nbrofsccpchs-sccpch.jpg

[jan74]

Hi,

DCH/HS to FACH -> 10 s, usually in some vendors it should have reporting periode about 5 s to report the buffer occupancy, depends on your setting.
So the total time after buffer reporting is 15 s + pending timer 5 s = 20 s. I think its better to set the Hs/DCH to FACH < than PS inact timer, since your call will be released wth inactivity cause.
Just try to set to 5 s or 2 s. What is FACH to PCH timer ?

And just make sure your DCR formula is correct. I use HS to FACH as normal release and i exclude inactivity as drop.
So the formula will be DCR = Number of Drop/(Number of Drop+Normal release+HStoFachSuccess+H2DSuccess+H2DinterfreSuccess+H2DIntrafreqSuccess)

Cos HS to FACH is considered as HSDPA release (not drop)

br

20s is very long. Just had a look at HS to FACH here and the settings are like this:
There are two possible causes for HS to FACH transition,
1. Low Utilisation
The settings are MACDFlowThroughputAveWin=3s. During that measurement time, if Throughput is less than or equal to MACdflowutilRelThr(0 bits), the time MACdflowutilTimetoTrigger starts. We have that seto to 0s so it starts immediately, as long as there is no data in the buffer.

2. Low Throughput
MACd flow Throughput needs to be below(or equal to) MACDflowThroughputRelThr (0 bits) during MACDflowthroughputAveWin(3s), the time MACdflowthroughputTimetoTrigger(5s) starts. In this case, if there is data in the buffer and the call is released, we count it as abnormal. In this case, a guard timer is started.

So basically, the max time to be in DCH here with no data in buffer is 8s. But Low Utilisation triggers after 3s. For me this makes sense and our DCR for PS is under 1%. As mentioned by somebody else, you should check the RB Reconfigurations to narrow down where the fails may be happening.

[Fredrick]

I have experienced this in our network, This happens only in cell with high traffic.

The major reason behind the call drop is increased uplink RSSI.

[adewijaya]

I have experienced this in our network, This happens only in cell with high traffic.

The major reason behind the call drop is increased uplink RSSI.

not agree with you, for this case we can see for RTWP result, ocasionally its could be related to this issue but another case maybe happend due to all that stated above

[mbouchamekh]

I think if u could have tried to increase T317, so u can make sure that the drop is not caused by radio

[hesh]

Dear experts,
PS call drop increase after enabling the FACH state. plz share your experience to reduce the call drop and what is the best values for the parameters related to FACH state.


Yes, after enabling FACH state, PS drop could increase as in FACH state there is NO POWER CONTROL coz FACH is common control cahnnel and no power control applied on common channels, secondly when UE is in FACH state,RAB attempts would decrease as RAB is resrved for the UE's in FACH, due to this PS drop would increase( AS RAB ATTEMPT IS DECREASED)

So in FACH state there is tradeoff between less signalling and fast access to call retainbilty.

Hope this could help...

[tareq1010]

one more addition, after enabling the Cell FACH state, the DCH to HSDPA ateempts are increased. do you konw what is reason behind this please.

thanks for sharing

[hesh]

one more addition, after enabling the Cell FACH state, the DCH to HSDPA ateempts are increased. do you konw what is reason behind this please.

thanks for sharing


Yes , It could be...coz when u r in FACH state..means low Traffic activity state..so when u r moving from low traffic to high traffic may move you to HSDPA RAB..(may be in your case your case at lower traffic HSDPA RAB is triggering)..