7/28/2019 FACH Congestion_telecomsource.net

1/3

Dear all,

did anyone know the maximum number of user in FACH channel?

also what will happen if the maxium allow number of user exceed the threshold, any

experience what will happen?

There is no actual limit on how many users are supported in CELL_FACH. it is

important to remember that FACH is used by both signalling (e.g. RRC connection,

RRC state transitions etc) and also user plane traffic (if you have one S-CCPCH in the

cell you may have also paging traffic as well).

This means that you should not have any packet users in CELL_FACH transmitting

packet traffic. becareful i am not saying to disable CELL_FACH. actually CELL_FACH isideal for efficient use of system resources. however, you should configure event 4a

such that whenever even a single packet appears, then the system should try to send

the user to CELL_DCH. With this configuration, system can have a very large number

of packet users in CELL_FACH.

RACH capacity could be monitored through Node-B counters. Some vendors provide

counters on RACH performance, and if a cell experiences large number of collisions

(NACKs) it is time to add extra RACH hardware. However, if you follow the

recommended configuration discussed earlier would reduce the amount of users

requesting RACH resources. and so you would be OK.

In order to measure current FACH throughput, it is possible to use the following

counter (Huawei)

VS.MAC.CRNCIubBytesFACH.Rx

This measurement item takes statistics of the number of DL MAC PDU bytes sent by

the CRNC on the FACH FP over the Iub interface in a cell.

(you need to convert this number from bytes/15-min to kbps, but this is easy...)

if you see results in the area of 75% utilisation (assuming a single FACH, with data rate

= 32 kbps), then this cell experiences FACH congestion

7/28/2019 FACH Congestion_telecomsource.net

2/3

Important, if you have a single S-CCPCH configuration you may have FACH congestion

even though the calulated FACH throughput could be very small. the reason being

that over a single S-CCPCH the various transport channels have the following

priorities:

1. PCH

2. FACH-c (signalling)

3. FACH-u (user plane)

as a result we always use 2 S-CCPCHs (one for PCH and the second for FACH-c/u,

again FACH-c has higher priority than FACH-u)

unfortunately, Huawei does not have any proper RACH counters apart from

>> VS.MAC.CRNCIubBytesRACH.Tx

This measurement item takes statistics of the number of DL MAC PDU bytes sent by

the CRNC on the RACH FP over the Iub interface in a cell

comment: useful to measure RACH throughput

>> VS.ULBler.PSNrt.Rach8

This measurement item takes statistics of the UL BLER on the RACH transport channel

carrying the PS 8 kbit/s non-real-time service in the best cell

comment: useful to see RACH error performance

7/28/2019 FACH Congestion_telecomsource.net

3/3

Very details explanation, appreciate your feedback networkdoctor

1. From the congestion part on calculation, 75% of utilization, can further explain on

this?

2. I understand in some vendor, highly recommended for Max of FACH user of 64

(apply to single S-CCPCH), is this because to avoid affected the PCH capacity? as from

the service priority as explain, I assume althought too much of FACH user, but PCH

user with not affected, is this statement valid?

a. PCH

b. FACH-c (signalling)

C. FACH-u (user plane)

3. As cell is having FACH congestion, either meeting 75% of utilization or reach max

number of user, will the cell still try to downswitch the inactive user into FACH? if

yes, will this causing call drop or the user can back to cell_DCH

4. In the case of FACH limitation, 2nd-SCCPCH will be the solution. can share if notice

poor RACH error performance, what is the suggested solution.