FACH Congestion Optimization

[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 ReservedSwitch0parameter 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 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 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 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 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 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 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 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 parameter, no matter what value the CacSwitch parameter has. If the value of the NBMCacAlgoSwitch parameter is FACH_USER_NUM_NOT_CTRL-0, it is recommended that you run the ADD UCELLALGOSWITCHcommand to set NBMCacAlgoSwitch to FACH_USER_NUM_NOT_CTRL-1, which lifts the restriction on the number of UEs in the FACH state.

After the restriction on the number of UEs in the FACH state is lifted, setting CacSwitch 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.