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

it is imp
ortant 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 p
acket 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 c
ounters on RACH performance, and if a cell experiences large number of collision
s (NACKs)
it is time to add extra RACH hardware. However, if you follow the recommended co
nfiguration discussed earlier would reduce the amount of users requesting RACH r
esources. and so you would be OK
Dear Boring,
Thank you for your answer and sorry for responding so late. It's encouraging to
know that i shouldn't expect congestion if i set tresholds at the low level.
However i'm still thinking about dependencies between users in FACH state and bu
ffers occupancy thresholds that will trigger transition to DCH. Inevitably,
low buffers occupancy thresholds settings can cause more unnecessary transitions
back to the DCH state. On the other hand, as you wrote, it is getting risky to
increase them due to possible congestion.
So i'm wondering is there any chance to calculate FACH throughput that's availab
le for packet traffic assuming certain user's profile, only one S-CCPCH in a cel
l, blocking probability, etc.?
By the way, do you know are there any performance counters in HW system (ver. V9
00R012C01SPH220) i should look at regarding the topic (except from state transit
ions successes vs attempts)?
Does signalling plane, have higher priority than packet traffic when it comes to
FACH utilization? And finally, are there any RACH performance counters in HW UM
TS system? If they are,
it's impossible for me to find them.
Best Regards,
Bob.
VS.CellFACHUEs - UE State in Connected Mode (CELL-DCH, CELL-PCH, URA-PCH, CELL-F
ACH)
VS.RRC.AttConnEstab.EFACH Number of RRC setup request on EFACH
VS.RRC.SuccConEst.EFACH Number of successful RRC setup on EFACH
VS.RRC.ConnEstabTimeMax.CCH.FACH the maximum delay time of RRC Setup process on
FACH
VS.RRC.ConnEstabTimeMax.CCH.HSDSCH the maximum delay time of RRC Setup process o
n EFACH
VS.RRC.ConnEstabTimeMean.CCH.FACH the mean delay time of RRC Setup process on FA
CH
VS.RRC.ConnEstabTimeMean.CCH.HSDSCH the mean delay time of RRC Setup process on
EFACH
VS.RAB.AttEstPS.EFACH Number of PS Domain RAB Setup request on EFACH
VS.RAB.SuccEstPS.EFACH Number of successful PS Domain RAB Setup on EFACH
VS.RAB.Estab.PS.CCH.FACH.MaxTime the maximum delay time of PS Domain RAB Setup p
rocess on FACH
VS.RAB.Estab.PS.CCH.HSDSCH.MaxTime the maximum delay time of PS Domain RAB Setup
process on EFACH
VS.RAB.Estab.PS.CCH.FACH.MeanTime the mean delay time of PS Domain RAB Setup pro
cess on FACH
VS.RAB.Estab.PS.CCH.HSDSCH.MeanTime the mean delay time of PS Domain RAB Setup p
rocess on EFACH
VS.RAB.Abnorm.Rel.PS.EFACH Number of abnormal PS Domain RAB release on EFACH
VS.RAB.Norm.Rel.PS.EFACH Number of normal PS Domain RAB release on EFACH
VS.MAC.CRNCIubBytesEFACH.Tx Number of Bytes on IUB EFACH<Cell>
hi
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 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, 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
please let me know if you want further clarifications
br
Reply With Quote
Huawei NETWORK
UlRateThresForDCCC: The DCCC algorithm capability may be very low for some Best
Effort (BE) service with very low applied maximum rate.
The UL DCCC algorithm does not activate for the BE service whose applied uplink
maximum rate is smaller than or equal to the threshold. Default value: 64k.
DlRateThresForDCCC: The DCCC algorithm capability may be very low for some Best
Effort (BE) service with very low applied maximum rate.
The DL DCCC algorithm does not activate for the BE service whose applied downlin
k maximum rate is smaller than or equal to the threshold. Default value: 32k.
Event4AThd: Event 4A trigger threshold. Default value: 1024bytes.
Event4BThd: Event 4B trigger threshold. Default value: 64bytes.
DtoFStateTransTimer: This parameter is used to detect the stability of a UE in l
ow activity state in CELL_DCH state. Default value: 180s.
FtoDTVMthd: The parameter is used to define the traffic volume measurement thres
hold for event 4a when the state transition form FACH to DCH will be triggered.
Default value: 1024bytes.
FtoPStateTransTimer: This parameter is used to detect the stability of a UE in l
ow activity state in CELL_FACH state. Default value: 180s.
CellReselectTimer: This parameter is used to detect whether a UE is in the state
of frequent cell reselection. Default value: 180s.
CellReselectCounter: For a UE in CELL_PCH, if the number of cell reselections ex
ceeds this parameter within the [cell reselection timer],
it can be considered that the UE is in the state of frequent cell reselection. D
efault value: 9