Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors

High SDCCH Assignment Failure

Viewing 15 posts - 1 through 15 (of 50 total)
  • Author
  • #53408

    Hi All,

    Can anyone please help me with the reason(s) for high SDCCH Assignment failure? We have been experiencing it for a long time and it seems to be moving from one site/cell to another.

    I am looking for the diagnostic steps to trace this problem.

    Our vendor is ZTE.

    Thank you very much for your support.



    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.



    Hi Flo,

    Thanks for the reply.

    At least I can start with the Abis trace and see the outcome.

    I will share my result with you.



    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



    I also have seen SDCCH assignment failures in our network, there are three most probable reasons ;

    1. Bad BCCH usage (co & Adjacent channel interference high)

    2. Bad BSIC usage (actually this is because of bad BCC plan) refer below for some of the examples for bad re-use (I’ve used BCCHs 115, 114, 116 & BSICs 75, 65 for illustrations)
    BCCH 115, BSIC 75 re used closer to BCCH 115, BSIC 65


    BCCH 115, BSIC 75 re used closer to BCCH 114 OR 116, BSIC 75 OR 65

    in above cases try with changing the BCCH/BSIC

    3. TRX failures- in this case try with resetting the TRXs, most of the time we have overcome the issue.

    ali abbas

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


    Hi Ali,
    Main cause for SD and TCH drop are : 1)Poor Coverage 2)Interference 3)HW Problem
    To improve:U have to identify the cause and solve. Best way to take call traces for the particual cell and then to analyze.

    SD should be assigned in the interference free TRX…and then also u can change the sd_priority..(high priority for good TRX…
    Also u can set priority for tch.

    ali abbas

    Thanks for reply.I also want to know about SDCCH/4 and SDCCH/8.what are sub 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.


    have you tried typing these questions in google ? i suggest you spend time there…


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




    thanks for the interesting analysis. on my side, i still don’t see what is the cause of the problem. I’ve analyzed such an issue in alcatel lucent network (exactly the same problem).

    We did an Abis trace as well, but with no luck.
    A channel request
    –> an immediate assignment with same random reference
    –> an establish indication.

    the problem is that the channel request is not followed by an establish indication… but how can you link these two messages ? There is no common reference on the abis… therefore I could not manage to extract the *faulty* channel request.

    What do you think ? did I miss something ?


    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 ?


    Hi Guys,

    It seems this problem is common in ericsson networks.

    In out anlysis we split it into 2 parts.

    1) CCALLS-CMSESTAB showing total # of failure to establish an SDCCH.
    We found cells with huge values were at the location border.

    This affected the overal BSC CSSR.


    This affected cell CSSR & we were able to fish out cells with co BCCH.

    The problem is we could not find the counter CESTIMMAS and CESTCHACTIV.

    I serched in objects SDCCH & SDCCHO but to no avail. Can someoone help me on how to find it & what command to use in OSS to get the T 3101 timer?


    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:

    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!




    Hi all,

    i want to ask same question with EugeZ. what command to use in OSS to get the T 3101 timer?

Viewing 15 posts - 1 through 15 (of 50 total)
  • The forum ‘Telecom Design’ is closed to new topics and replies.