Cell_FACH state – capacity calculations.

[Bob.]

Hello,
Could you please tell me how to assess the UMTS FACH channel capacity? I know that it’s throughput is 32kbps but how it is shared among users. I’d like to make sure, that timers/buffers settings are correct in order to provide service for all UEs in Cell_FACH. Briefly speaking – i’d like to check, how many users can be in Cell_FACH state at the same time depending on the network settings.
Another question related to that issue reffers to RACH. When it’s paramatrization become an issue when it comes to successful change of states (from Cell_FACH to Cell_DCH) and appropriate service (data transmission) on RACH itself? When RACH becomes the bottleneck and what eventually should be taken into account.
Thanks for your help.

[mobilink999]

nice question. would love if some guru can help.

[adewijaya]

Hello,
Could you please tell me how to assess the UMTS FACH channel capacity? I know that it’s throughput is 32kbps but how it is shared among users. I’d like to make sure, that timers/buffers settings are correct in order to provide service for all UEs in Cell_FACH. Briefly speaking – i’d like to check, how many users can be in Cell_FACH state at the same time depending on the network settings.
Another question related to that issue reffers to RACH. When it’s paramatrization become an issue when it comes to successful change of states (from Cell_FACH to Cell_DCH) and appropriate service (data transmission) on RACH itself? When RACH becomes the bottleneck and what eventually should be taken into account.
Thanks for your help.

read on this related link : http://www.finetopix.com/live-optimization/18906-ps-call-drop-increase-after-enabling-fach-state.html

[boring]

Hello,
Could you please tell me how to assess the UMTS FACH channel capacity? I know that it’s throughput is 32kbps but how it is shared among users. I’d like to make sure, that timers/buffers settings are correct in order to provide service for all UEs in Cell_FACH. Briefly speaking – i’d like to check, how many users can be in Cell_FACH state at the same time depending on the network settings.
Another question related to that issue reffers to RACH. When it’s paramatrization become an issue when it comes to successful change of states (from Cell_FACH to Cell_DCH) and appropriate service (data transmission) on RACH itself? When RACH becomes the bottleneck and what eventually should be taken into account.
Thanks for your help.

hi

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

Thanks

[Bob.]

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 buffers 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 available for packet traffic assuming certain user's profile, only one S-CCPCH in a cell, blocking probability, etc.?

By the way, do you know are there any performance counters in HW system (ver. V900R012C01SPH220) i should look at regarding the topic (except from state transitions 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 UMTS system? If they are, it's impossible for me to find them.

Best Regards,
Bob.

[boring]

hi Bob
i will try to answer to your question.
could you tell me in the meantime which vendor you refer with this HW version (V900R012C01SPH220)?
thanks

[Bob.]

Hello Boring,

HUAWEI is the vendor i'm talking about. Sorry for confusion.

Thanks for your help,
Bob.

[agenov]

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 buffers 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 available for packet traffic assuming certain user's profile, only one S-CCPCH in a cell, blocking probability, etc.?

By the way, do you know are there any performance counters in HW system (ver. V900R012C01SPH220) i should look at regarding the topic (except from state transitions 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 UMTS system? If they are, it's impossible for me to find them.

Best Regards,
Bob.


If you check in M2000 you may find all available performance counters as well as to create KPI and etc.

BR

[adewijaya]

VS.CellFACHUEs - UE State in Connected Mode (CELL-DCH, CELL-PCH, URA-PCH, CELL-FACH)
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 on EFACH
VS.RRC.ConnEstabTimeMean.CCH.FACH the mean delay time of RRC Setup process on FACH
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 process 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 process on FACH
VS.RAB.Estab.PS.CCH.HSDSCH.MeanTime the mean delay time of PS Domain RAB Setup process 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>

[boring]

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 buffers 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 available for packet traffic assuming certain user's profile, only one S-CCPCH in a cell, blocking probability, etc.?

By the way, do you know are there any performance counters in HW system (ver. V900R012C01SPH220) i should look at regarding the topic (except from state transitions 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 UMTS system? If they are, it's impossible for me to find them.

Best Regards,
Bob.

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

please let me know if you want further clarifications
br