in order to measure current FACH throughput, it is possible to use the following counter (Huawei)VS.MAC.CRNCIubBytesFACH.RxThis 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 congestionImportant, 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. PCH2. 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.TxThis 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 cellcomment: useful to measure RACH throughput>> VS.ULBler.PSNrt.Rach8This 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 cellcomment: useful to see RACH error performance