High SDCCH Assignment Failure

Hi,

I have the same pb, Abis traces shows SDCCH establishment failure mapped on LAU procedure, failing due to MS problem : no answer to Immediate Assignment. (300 failure in 80 minutes)

CSSR is degraded and it seems that there is no solution to identifie IMEI cause SD assignment procedure is stop.

If anyone has idea on how to identify such MS causing this pb, please let us know.

tx

normaly, every vendor should have counters giving the causes of sdcch or tch drops like

radio,bts,bcsu,abis,a interface.. for nokia
or base on signal strength/quality, suden loss,other like in ericsson
so may be you should check first if you have corresponding counters. this will help you to investigate

BR

what are the reasons for SDCCH and TCH drops.How can it be improve.

Thanks for reply.I also want to know about SDCCH/4 and SDCCH/8.what are sub slots.how radio channels are combined.What is basic difference between SQI and RX Qual.What is meant by routing area update and Data link failure during Drive test.What is T200,n200 and 3162 Timers.

Hello to All.

I’ve been working with Ericsson GSM Networks for some time and since mid 2007 we noticed that we were expecting a very similar problem, or maybe the same one. At least in 3 countries I could certainly say that the problem is present.

The diagnostic is the following:

– Raise over the normal values of the following counters:

CNROCNT: Number of accepted random accesses
RAOTHER: Number of random accesses, Location Updates
CCALLS: Channel allocation attempt counter (on SDCCH)
CSIMMASS: Number of CS IMMEDIATE ASSIGNMENTS sent on the CCCH
CESTIMMASS: Number of SDCCH establishment failure due to timeout after sending Immediate Assignment, timer T3101 expired

– Fall of the SDCCH Access (SDCCH Assignment)
In Ericsson the formula is (CMSESTAB/CCALLS) x 100%
It falls because the number of Attempts on SDCCH (CCALLS) grows without control, but the number of successful attempts on SDCCH (CMSESTAB) remains the same.

– With ABIS traces, Ericsson found that (just like Flo said) the ms is not authenticated yet so there is no way to find the IMEI or the phone model. Ericsson agrees that it is a specific model or models from our network or from the competition. However A VERY INTERESTING FACT is that all the attempts come from a specific Timing Advance (TA) giving strength to the theory that it is indeed a mobile or group of mobiles that produce this effect. Also, if you use a MRR (Measurement Result Recording) or something similar for a specific hour, if the cell has the problem present, a certain Timing Advance grows beyond all others.

– The problem may be present for 1 or several hours.

– If the problem is caused by Location Updates, then one or more than one of the following procedures is “guilty”: normal registration (with the change of a Location Area), periodic registration and IMSI attach. We moved the Timer for the Periodic Registration from 1 hour to 4 hours in a very large group of cells and the problem persisted. Also we turned off the IMSI Attach procedure in a complete BSC for 1 day and the problem endured. And we have seen the problem in areas where there is no border of a location area. As you can see, it is a very complicated issue!

– It happens every day in at least 5% of the sectors of the network.

¿Any thoughts? Regards,

SA

Hi SA,

One solution to identify MS could be with the periodic LAU timer. We know that this timer set amount of time after MS execute automatic LAU procedure when last call/sms was sent/received.

Very occurate time of abis traces early in the morning could lead to identify one or a group of MS in HLR ?

Hello EugeZ.

You can try the following command on a BSC level in WinFIOL:

print var rmscs 94;

The Print will look something like this:

VARIABLE
RMSCS VAR H’05E=H’000E

With the hexadecimal value H’000E. You look for the decimal value, in this case 14. And use the following formula:

T3101 (decisecs) = ZINTERVAL x (CT3101 – 2) / 4

When you substitute the formula with ZINTERVAL=10 and CT3101=14, then the following value is obtained:

T3101 (dsecs) = 10 x (14 – 2) / 4 = 30deciseconds (3seconds)

The CCALLS and CMSESTAB are found in the dbo_CELL_MAIN table in the GRAN_seg1 (for example). In that very same table the counters CESTIMMASS and CESTCHACTIV are stored.

I hope this helps!

Regards,

SA