PDA

View Full Version : problem in the Paging causing degdation on SDCCH blocking and DCR and INHSR



wael
2010-12-30, 02:51 AM
Dear experts
We have strange thing on our network , during the weekend the paging request increase in two LAC both of them having 5 BSC the paging / sec reach to 35 but the problem that we get degdation on SDCCH blocking and DCR and INHSR and the strangest thing that the call volume decreased , as action we change the paging attempt from the MSC side from 4 to 2 but it was not working then we reduce the size of the BSC paging buffer from open to 100 but it was working

Any explanation will be appreciated

zhanglw268
2010-12-30, 09:01 PM
What's the below parameters setting in your cells?
wait_indication_parameters
ccch_conf
bs_ag_blks_res
bs_pa_mfrms
extended_paging_active
max_retran
tx_integer
rr_t3101

What's the below statistics in cell level?
ACCESS_PER_RACH
OK_ACC_PROC_SUC_RACH
ALLOC_SDCCH_FAIL
ALLOC_SDCCH
CHAN_REQ_MS_BLK
ACCESS_PER_AGCH
CHAN_REQ_MS_FAIL

Were you having high/unusual chan_req_ms_fail building up gradually, then ALLOC_SDCCH_FAIL and CHAN_REQ_MS_BLK were high at the same time in a lot cells?

wael
2010-12-31, 11:39 PM
Below is the setting is parameters
wait_indication_parameters


6
ccch_conf


0
bs_ag_blks_res


2
bs_pa_mfrms


2
extended_paging_active


1
max_retran


1
tx_integer


12
rr_t3101


2000


I don’t think there is any issue on the parameter setting
Regarding to the below stats , all of them are going very high due to the very high paging that come suddenly from the MSC , but don’t know what is the reason for this paging
I can say may be the degradation in KPi’s due to BTS stuck =èdue to the high paging but I’m not sure .
. yesterady I split the LAC ,at least to reduce the paging and monitor the stats . till this momment no issue and

I have one senario let ‘s suupos there are a lot of traffic in some cells ( congstion ) under one LAC, what will happened for the MT calls , I think will be like the MS out of coverage . I mean the network will be busy and then the MSC will send the paging over and over againe on this LAC . as respons the PCH will be congestion but why RACH and AGRH and SDCCH why they respond to thos paging at all cells in the LAC .that’s why I split the LAC .

Till this moment every thing is ok

wael
2010-12-31, 11:43 PM
Below is the setting is parameters
wait_indication_parameters6


6
ccch_conf0


0
bs_ag_blks_res2


2
bs_pa_mfrms2


2
extended_paging_active1


1
max_retran1


1
tx_integer12


12
rr_t31012000


2000

zhanglw268
2011-01-04, 11:50 PM
Did you see below event/alarms a lot in the system while the problem existed?

[0] Flow control procedure has started barring normal calls from access classes 0-9 - FMIC - Warning -/-.
02 .

Please note that the additional informaton field is 02 not 01 or 03.

kais
2011-01-05, 12:29 AM
see attached file for 3G paging analysis...

wael
2011-01-05, 05:31 PM
Yes the below alarms existed on many cells , do you think the problem was due to the flow control, if yes can you explain?

I’m thinking if the MS was blocked due the flow control on certain cell , may be can camp on other cell specially if the MS was moving . and then these Scenario will be repeated over and over again .

zhanglw268
2011-01-06, 05:31 AM
Final question, What's rach_load_threshold value in these alarms cells?

wael
2011-01-06, 06:59 PM
Many thanks , pls find below the setting of the flow control

rach_load_period


8
rach_load_thresh


117
ccch_load_period


8
tch_flow_control


0
flow_control_t1


5000
flow_control_t2


15000

zhanglw268
2011-01-09, 08:17 AM
The problem you had is exactly the same problem which happened in another network in the same country more than 1 years ago. I had the explanation at that time and also shared with the people in this network.

This is network cell level parameters setting issue, with current settings, this can happen at any time if the conditions are right.

You shall be able to get the explanation and solution as there are still people working there along with you.

If you need further help, please let me know.

wael
2011-01-09, 05:29 PM
Many thanks for your response

You know the problem back again in the weekend and the LAC spilt was not working to solve the issue

Could you please tell me what was the recommendation and what is the right setting for parameters ,

Your help appreciated

wael
2011-01-09, 05:35 PM
Boss this my personal mail if you can send me the recommendation and the parameter setting , and all the work done to resolve this issue

Wa2003elq@hotmail.com (Wa2003elq@hotmail.com)


many thanks again :)

zhanglw268
2011-01-10, 07:31 PM
Here I paste the past analysis for your reference so you can use the same method to work the current issue.


from the stats:


1. The BTS system can process the RACH very successfully until the AGCH part.
This can be checked that OK_ACC_PROC_SUC_RACH => CHAN_REQ_CAUSE_ATMPT => ALLOC_SDCCH + ALLOC_SDCCH_FAIL => ACCESS_PER_AGCH
The above stats are roughly equal all the time except very rare interval.
2. Also Mobile moved on SDCCH were connected to MSC successfully, this can be checked by stats OK_ACC_PROC = CONN_REQ_TO_MSC
3. The major problem is that mobiles RACHed and BTS sent Immediately assignment/extended but a huge amount of Mobiles didn't go to SDCCH in busy hours. This can be easily checked and proved. you can compare ALLOC_SDCCH and OK_ACC_PROC, system has SDCCH available for RACH and system reserved SDCCH and wait for mobile sending SABM to go to SDCCH, this measures how efficient the SDCCH is grabbed by Mobile. ALLOC_SDCCH/OK_ACC_PROC was 1.8-15 in busy hour, this means that Mobiles make 1 successful connection to MSC, BTS need at least 1.8 times SDCCH, system reserved SDCCH were wasted.

Another aspect is looking at the RACH to SDCCH conversion rate, i.e. the RACH retransmission ratio, OK_ACC_PROC_SUC_RACH/OK_ACC_PROC was around 2.4-4.5 during busy hour. in non-busy hour it is around 1. i.e. 1 RACH is enough to access the system successfully.



So the question will be: why the mobiles can't go to SDCCH even SDCCH was reserved in the system. if you look at the call setup diagram, you will find that there are 2 timers to control this. One timer is T3126 at the Mobile side which maximum value is 5 seconds per 3GPP that every mobile phone vendor will follow. the change to this timer is unlikely. Another timer is called T3101 in 3GPP, this T3101 in * system should be set to default value 5000 per MMI command manual but most of * systems set this as 1500/2000 (1.5/2 seconds), the argument maybe that Mobile only sends maximum 6 SABMs, this T3101 can be set to 6*235ms which is 1410ms, but people forget that *'s T3101 is not at radio side when the Immediate Assignment (Extended) is sent, T3101 is on BTS's main processor and T3101 is started when SDCCH resource is reserved, so rr_t3101's setting should cover the AGCH queuing time, DL transmission time and Mobile's SABM time.


...

At the same time, there is a timer at mobile side to control how long the mobile will wait for AGCH when it sends RACH, this timer is called T3126 which maximum value is 5 seconds. So we can see that the parameter T3101 = 2000 is too low when system is busy.

Mobiles can wait for more than 2 seconds to go to SDCCH, the low T3101 setting caused the system to stop call processing since the BTS timed out too early even the mobiles were moved to SDCCH. So huge chan_req_ms_fail were pegged and almost no calls could go through BTS to MSC. You could see the statistics that was the case.


The suggestions are:

1. change T3101 to default value 5000 (5 seconds) as first priority

2. change the max_retran to 0 to allow 1 retransmission of the RACH (this will reduce the stats OK_ACC_PROC_SUC_RACH/OK_ACC_PROC ratio to 2 maximum), this is best RACH flow control since it reduce every mobile's RACH 75% comparing with max_retran=3 without barring any mobile at the first place, this should be no side-effect to the KPI.....


Zhanglw268

wael
2011-01-11, 05:56 PM
Thanks a lot :), . Useful Information