problem in the Paging causing degdation on SDCCH blocking and DCR and INHSR

[wael]

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]

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


many thanks again

[zhanglw268]

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]

Thanks a lot , . Useful Information