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 congesti
on even though the calulated FACH throughput could be very small. the reason bei
ng 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, a
gain 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 chan
nel carrying the PS 8 kbit/s non-real-time service in the best cell
comment: useful to see RACH error performance