- This topic has 49 replies, 1 voice, and was last updated 3 years, 1 month ago by Kanchan Gupta.
7th August 2008 at 11:20 #53408WilosteqxGuest
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.7th August 2008 at 14:08 #53409FloGuest
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.
tx8th August 2008 at 10:17 #53410WilosteqxGuest
Thanks for the reply.
At least I can start with the Abis trace and see the outcome.
I will share my result with you.
Thx.17th August 2008 at 11:51 #53411migroGuest
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
BR18th August 2008 at 06:23 #53412ChathuraGuest
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.28th August 2008 at 15:34 #53413ali abbasGuest
what are the reasons for SDCCH and TCH drops.How can it be improve.28th August 2008 at 20:05 #53414RHGuest
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.29th August 2008 at 15:11 #53415ali abbasGuest
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.29th August 2008 at 15:25 #53416pixGuest
have you tried typing these questions in google ? i suggest you spend time there…2nd October 2008 at 03:41 #53417SAGuest
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,
SA2nd October 2008 at 06:56 #53418PixGuest
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 ?3rd October 2008 at 05:30 #53419fLOGuest
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 ?17th October 2008 at 16:44 #53420EugeZGuest
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?5th December 2008 at 02:44 #53421SAGuest
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!
SA9th January 2009 at 09:09 #53422mickeyknoxGuest
i want to ask same question with EugeZ. what command to use in OSS to get the T 3101 timer?