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 is ideal 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

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

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.