FACH Congestion Optimization

[khurrambilal01]

Hi Experts,

What are the possible ways to improve FACH Congestion? Any software features?
Cell_PCH? or Fast Dormancy?

[Muhammad Imran Rafique]

Dear Experts,

We have some updates from e*******, how they are planning to improve it. I will share shortly.
Lets brainstorm here how we can manage via parameters especially "channel switching"

BR//
Imran

[agenov]

Generally speaking not so much options. Either you may increase the capacity by introducing 2nd fach/Efach channel at the price of less DL power and etc. or you may play with your state transition settings and use more DCH. i tried to do some sort of traffic balancing between neighboring cells based on antenna design and CPICH but not so big advantage and improvement and i do not recommend it. There are some features depending on the vendor but again the purpose is to use DCH resource so to improve the FACH performance. Which is the vendor u use?

BR
Alex


Hi Experts,

What are the possible ways to improve FACH Congestion? Any software features?
Cell_PCH? or Fast Dormancy?

[electron]

Hi,

How did you find FACH congestion and what KPI u checked ? What will be FACH congestion draw back?
Generally speaking not so much options. Either you may increase the capacity by introducing 2nd fach/Efach channel at the price of less DL power and etc. or you may play with your state transition settings and use more DCH. i tried to do some sort of traffic balancing between neighboring cells based on antenna design and CPICH but not so big advantage and improvement and i do not recommend it. There are some features depending on the vendor but again the purpose is to use DCH resource so to improve the FACH performance. Which is the vendor u use?

BR
Alex

[agenov]

i am dealing with H// so i can talk about them only. There is counter for Fach congestion.If fach is in congestion state and admission is allowed then you can not go in FACH so if you are in PCH or DCH can not transit to FACH thus if you are in DCH you will consume the resources without need, and if u are in PCH u can not go in some of the other state so to start transmission that's bad user perception. From the other side if you are in FACH and in one moment it become congested then you will have PS drop counted.

BR
Alex


Hi,

How did you find FACH congestion and what KPI u checked ? What will be FACH congestion draw back?

[khurrambilal01]

Generally speaking not so much options. Either you may increase the capacity by introducing 2nd fach/Efach channel at the price of less DL power and etc. or you may play with your state transition settings and use more DCH. i tried to do some sort of traffic balancing between neighboring cells based on antenna design and CPICH but not so big advantage and improvement and i do not recommend it. There are some features depending on the vendor but again the purpose is to use DCH resource so to improve the FACH performance. Which is the vendor u use?

BR
Alex

Hi,
Vendor is Huawei R14.0 & ZTE. What do you think fast dormancy will improve FACH Congestion?

[agenov]

even worst because by activating of fast dormancy you will put much more users in FACH/PCH state.

br
alex


Hi,
Vendor is Huawei R14.0 & ZTE. What do you think fast dormancy will improve FACH Congestion?

[P.T.E.]

Hi,
Vendor is Huawei R14.0 & ZTE. What do you think fast dormancy will improve FACH Congestion?

Dear khurrambilal01,

enabling EFD for sure will increase the FACH cong. my suggestion to overcome this issue is to increase FACH IuB Bandwidth or FACH Radio (SF)

BR,

[agenov]

Have u tried to change the SF of the Fach? Any observations, drawback etc?

[khurrambilal01]

Have u tried to change the SF of the Fach? Any observations, drawback etc?
Changing SF of FACCH needs to change SF of SCCPCH....

[dadoba]

Agenov,

I don't know in Huawei Network but in E/// according the vendor we will just have URA_PCH + Fast Dormancy Handling working 100% in W13B.

In E/// you put more users in FACH State when you set URA References per cell this means activate URA_PCH. This happens cause if you check state transitions you will see 2 new transitions from and to FACH.

If you activate Fast Dormancy Handling you put less users in FACH cause you can send UEs directly from CELL_DCH to URA_PCH, the problem here is pre release 8 UEs can have baseband restart and for this reason E/// has a parameter state128..... that you have to set TRUE to avoid these restarts but there is a problem here...

When you activate it all UEs will just follow the same way CELL_DCH -> FACH -> URA_PCH and this disable the real benefit of Fast Dormancy Handling.

In W13B there is a feature that works with pre release 8 UEs enabling the real Fast Dormancy Handling that supports (CELL_DCH->URA_PCH) and avoiding baseband restarts in UEs that not supports this transition, there is also now in W13A a new feature that E/// is testing that enables the transition URA_PCH->CELL_DCH.

For E/// then of you have W13B you are able to activate new transitions that can offload CELL_FACH. Also to avoid FACH overload you can set agressive Channel Switching strategies making transitions faster from and to CELL_FACH avoiding overload this channel. Just make sure your RNC supports the MP LOAD and DC LOAD increasing cause agressive strategies increases RNC LOAD, tests that I have done here increased up to 5% of load.

For E/// then Fast Dormancy Handling do not overload FACH if it is really working properly what overload FACH in true is URA_PCH state active, of course URA_PCH is really important to reduce RNC MP and DC LOAD but you have to check the items below:

FACH Overload:

1) Try to balance the load with another carrier, deploy second or third carrier if have conditions for it.
2) If your RNC have conditions set agressive Channel Switching strategies.
3) Just activate URA_PCH if your RNC really needs but try to activate Fast Dormancy Handling really working as the theory (I don't know if another vendor has the same issue)
4) Check if is available the new transition URA_PCH -> CELL_DCH ans acivate it.

Just talking about item 3 there is a important thing to comment, URA_PCH is really necessary if you already have LTE in your network cause fisrt Software Versions of LTE just allows the cell reselection to LTE if the UEs is in IDLE or URA_PCH and if don't have URA_PCH with Fast Dormancy Handling working well in your network rarely Smartphones goes do IDLE (because background apps running all the time).

New versions as enabling reselection in FACH, enabling Handovers, etc.

[P.T.E.]

Changing SF of FACCH needs to change SF of SCCPCH....

Dear,

you can dedicate a new SCCPCH channel for FACH only :)

[dadoba]

P.T.E.

How is it possible in E///? Do you know?

[FrankPintor]

In the Huawei RAN, apart from enabling the second SCCPCH (I think most networks are using this configuration now?), you can enable the P2D and D2P transitions to skip CELL_FACH in case of congestion. Also, I guess you have the 60 FACH user switch enabled? You could reduce the time users spend in CELL_FACH by reducing the F2P time to trigger and transition time.

If the problem is FACH payload, then you could reduce the e4a traffic volume threshold so less traffic is sent on the FACH channel.

Huawei have some mechanisms to pre-empt the DCCH and CCCH queues for the FACH channel, I don't have the detail at hand though.

They also have the LDB feature if you have overloaded cells and lightly loaded neighbour cells, this works by varying the CPICH power according to the cell load, so users move to the less heavily loaded cells.

[faisaladeem]

You may also increase FACH bandwidth to 72kbps...it helps in FACH congestion

[FrankPintor]

You may also increase FACH bandwidth to 72kbps...it helps in FACH congestion
That's interesting... no problems with UE compatibility? Are you using Huawei equipment? How would you do this?

[Luis123]

UE State

State Transition

Trigger Condition

Switch



CELL_DCH

D2Idle

The IE "Volume" of all Event 4Bs is 0, triggering a D2F transition.
The D2F transition fails because the number of UEs in the CELL_FACH state has reached the upper limit.

The ReservedSwitch0 (http://localhost:7890/pages/GEB02251/03/GEB02251/03/resources/RNCParaHtml/mbsc/m-para/ucorrmalgoswitch_reservedswitch0.html)parameter is set toRESERVED_SWITCH_0_BIT16-1.



CELL_PCH/URA_PCH

P2D

The cause of a cell update is "uplink data transmission" or "paging response", triggering a P2F transition.
The P2F transition fails because the number of UEs in the CELL_FACH state has reached the upper limit.

The RsvdPara1 (http://localhost:7890/pages/GEB02251/03/GEB02251/03/resources/RNCParaHtml/mbsc/m-para/urrctrlswitch_rsvdpara1.html) parameter is set to RSVDBIT1_BIT20-1.




The D2Idle transition function is disabled by default, and can be enabled by running the SET UCORRMALGOSWITCH command. After a UE moves to the idle state, the RNC releases the dedicated channel for the UE in order to improve the cell resource utilization.
l The P2D transition function is disabled by default, and can be enabled by running the SET URRCTRLSWITCH command. During a P2D transition, the RNC delivers the UE a cell update confirm message on the CCCH, which prevents call drops because the delivery does not use up resources designated for UEs in the CELL_FACH state. The initial access rate of a PS service is 8 kbit/s after the UE has entered the CELL_DCH state.
− The rate of PS BE services (non-PTT services) can be limited to 8 kbit/s to prevent excess usage of the DCH resources. This function can be enabled by running the SET UCORRMALGOSWITCH command with the ReservedSwitch1 (http://localhost:7890/pages/GEB02251/03/GEB02251/03/resources/RNCParaHtml/mbsc/m-para/ucorrmalgoswitch_reservedswitch1.html) parameter set to RESERVED_SWITCH_1_BIT6-1. This function is enabled by default.
− The PS BE service (non-PTT services) can be set up on the HS-DSCH or E-DCH when the call drop rate increases because of a large number of P2D transitions as well as H attempts or DCCC rate increase attempts of users on the DCH. An H attempt refers to a channel shift from DCH to HS-DSCH or E-DCH. This function is disabled by default. To enable it, run the SET UCORRMPARA command with the PerfEnhanceSwitch (http://localhost:7890/pages/GEB02251/03/GEB02251/03/resources/RNCParaHtml/mbsc/m-para/ucorrmpara_perfenhanceswitch.html) parameter set to PERFENH_PSTraffic_P2H_SWITCH-1.
If the number of UEs in the CELL_FACH state reaches the upper limit, cell updates may fail, including those triggered by radio link setup failures. As a result, call drops may occur. To prevent this, you can reserve some UEs in the CELL_FACH state for cell updates. To set the number of reserved users, run the SET UCORRMALGOSWITCH command and modify theReservedU32Para1 (http://localhost:7890/pages/GEB02251/03/GEB02251/03/resources/RNCParaHtml/mbsc/m-para/ucorrmalgoswitch_reservedu32para1.html) parameter.
If the maximum number of UEs in the CELL_FACH state is 30 and the number of reserved UEs in the CELL_FACH state is 5, the D2F transition shown in Figure 4-2 (http://localhost:7890/pages/GEB02251/03/GEB02251/03/resources/FPD/Flow%20Control.htm#_Ref297972861) will not be implemented when the number of UEs in the CELL_FACH state reaches 25. Instead, the D2Idle transition may be triggered. The resources for reserved UEs are for the users who send cell update messages.
If the value of the counter VS.CellFACHUEs, which indicates the number of UEs in the FACH state, is within the interval of [25,55), run the LST UCACALGOSWITCH command to check the value of the CacSwitch (http://localhost:7890/pages/GEB02251/03/GEB02251/03/resources/RNCParaHtml/mbsc/m-para/ucacalgoswitch_cacswitch.html) parameter. If the value of this parameter is FACH_60_USER_SWITCH-0, it is recommended that you run the SET UCACALGOSWITCH command to set CacSwitch (http://localhost:7890/pages/GEB02251/03/GEB02251/03/resources/RNCParaHtml/mbsc/m-para/ucacalgoswitch_cacswitch.html) toFACH_60_USER_SWITCH-1, which means that the maximum number of UEs in the FACH state is 60.
If the value of the counter VS.CellFACHUEs is greater than or equal to 55, run the LST UCELLALGOSWITCH command to check the value of the NBMCacAlgoSwitch (http://localhost:7890/pages/GEB02251/03/GEB02251/03/resources/RNCParaHtml/mbsc/m-para/ucellalgoswitch_nbmcacalgoswitch.html) parameter, no matter what value the CacSwitch (http://localhost:7890/pages/GEB02251/03/GEB02251/03/resources/RNCParaHtml/mbsc/m-para/ucacalgoswitch_cacswitch.html) parameter has. If the value of the NBMCacAlgoSwitch (http://localhost:7890/pages/GEB02251/03/GEB02251/03/resources/RNCParaHtml/mbsc/m-para/ucellalgoswitch_nbmcacalgoswitch.html) parameter is FACH_USER_NUM_NOT_CTRL-0, it is recommended that you run the ADD UCELLALGOSWITCHcommand to set NBMCacAlgoSwitch (http://localhost:7890/pages/GEB02251/03/GEB02251/03/resources/RNCParaHtml/mbsc/m-para/ucellalgoswitch_nbmcacalgoswitch.html) to FACH_USER_NUM_NOT_CTRL-1, which lifts the restriction on the number of UEs in the FACH state.
http://localhost:7890/pages/GEB02251/03/GEB02251/03/resources/FPD/Flow%20Control.files/image016.jpg
After the restriction on the number of UEs in the FACH state is lifted, setting CacSwitch (http://localhost:7890/pages/GEB02251/03/GEB02251/03/resources/RNCParaHtml/mbsc/m-para/ucacalgoswitch_cacswitch.html) to FACH_60_USER_SWITCH-1 will not change the maximum number of UEs in the FACH state to 60.
When there are no restrictions on the number of UEs in the CELL_FACH state, more UEs can always stay online. However, FACH congestion may occur if a large number of UEs are in the CELL_FACH state. Therefore, it is recommended that functions used to alleviate FACH congestion be enabled after restrictions on the number of UEs in the CELL_FACH state are lifted. These functions include P2D transitions, D2Idle transitions, D2F based on SDU delay, CCCH flow control, DCCH flow control, and DTCH flow control. Therefore, the CELL_FACH user number may be not very high due to the above actions according to FACH congestion.