- This topic has 6 replies, 1 voice, and was last updated 2 years, 9 months ago by Lemaure.
25th September 2017 at 17:14 #70091AlexRGuest
I’m facing a problem in 2G GSM with immediate assignement on SDCCH.
CSSR is split in three parts:
– sdcch establishment success rate
– sdcch drop
– tch establishment success rate
Our problem is with SDCCH establishment.
The degradations occurs suddenly without any correlation with others events in the network.
I check BTS hardware, coverage, parametres and interference and nothing seems to be wrong.
I’m out of ideas. 🙁
Modifying params is not a solution, because, as i said, the degradations occurs suddenly.
I have to mention that the vendor is E///
Can the problem come from 3G?(i also checked Kpis of 3G neighbours and all are ok)
Can you help me with this issue, please?
Thanks in advance.25th September 2017 at 21:14 #70092pixGuest
Glad to hear some interesting issues like this 🙂
So you need to do few more things.
1/ verify which counter is pegging … is it CESSTIMASS ? or is it the SDCCH blocking (CCONGS I believe) ?
2/ verify the SDCCH traffic (erlang) during those hours. Is it higher than usual ?
3/ what is the SDCCH MHT ? (mean holding time)
4/ now it’s interesting to know what’s happening BEFORE the sdcch establishment. That’s called the RACH phase. In E/// several counters are available to know what is the kind of Random Access that’s occuring (i’ll let you find the related counters). Another counter is counting ALL of the random accesses. So by substracting the RA causes to the total RA, you can find the “ghost” RA.
From there I think you’ll get a clear picture of what’s occuring. I hope so 🙂
Last step is to do a RACH trace on the BTS itself, but it involves advanded tracing techniques that i havent done in years, and which are reserved for E/// personnel (afaik).
Let me know how it goes !
Pix26th September 2017 at 11:40 #70093AlexRGuest
Thank you for your replay. 🙂
I’ve done the checks that you asked:
1. It’s CESTIMMASS(number of SDCCH establishment failure due to timeout after sending Immediate Assignment, timer T3101 expired.) that goes up when the SDCCH establishment succes rate goes down
2. The trafic is the same. No changes before/after the degradation
3. SDCCH_mht is also constant. No chagens before/after the degradation
4. I didn’t find nothing that could help me. I made the analysis on MO, MT, LU and SMS but nothing.
I also mention that i played a little with MAXTA and TA and i obtained great results: CESTIMMASS was reduced to low valeus and SDCCH_establishment_rate was good again.
But again, i don’t implement this solution because with the same values the performance was good.
I guess i have to go and ask for RACH traces.28th September 2017 at 07:27 #70094pixGuest
We had the exact same issue in our network, caused by “ghost rach”.
The RACH counters can really confirm the existence of ghost RACH. You have to gather all those counters (from CPI), there is a dozen of them.
No need to do a trace, you ‘ll waste your time.
Ask for the Market Adaptation that will automatically reject suspected ghost rach. Ericsson has developped such M.A. and we are using them on my network since 5 yrs !
Tuning the Timing Advance is, I think, the simplest way to do it though.
But, there, here you have you answer : your issue is caused by Ghost Rach.
further confirmation : look at nightly values. Ghost RACH should be also seen during the night.
If you see spikes, and only on specific cells, then you may want to scan the area with a scanner, and find what kind of equipement is polluting your freq band.
If you see a background noise, all along the day, then … nothing you can do. EM pollution 🙂
br / pix2nd October 2017 at 13:41 #70095AlexRGuest
Thank you very much for your help. 🙂
I managed to extract the counters for RACH phase (request) and SDCCH establishment(establi)
Here are two tables for two different days of the same cell: one with the values of the counters when the rate of SDCCH establishement is ok and the other one when the rate is not ok.
EASDCCH assignment ok:
|request | establ | Difference
MO | 718 | 631 | 87
LU | 11870 | 11378 | 492
MT | 823 | 780 | 43
SMS | 474 | 218 | 256
EC | 13 | 1 | 12
Total| 13898 | 13240 | 658 (CESSTIMMASS)
EASDCCH assignment not ok:
|request | establ | Difference
MO | 593 | 504 | 89
LU | 13613 | 11030 | 2583 => probleme
MT | 835 | 741 | 94
SMS | 456 | 156 | 300
EC | 10 | 3 | 7
Total| 15507 | 12686 | 2821 (CESSTIMMASS)
*EC = emergency call
As you can see, the problem appears for Location Update.
I have one more question: Are really the RACH phantom counted as LU requests?
Thanks in advance.3rd October 2017 at 08:58 #70096manikinGuest
I am in a telecom org. for almost 15 years and i have not seen experts of your calibre in mobile technology ..
How did you master so much information in mobile technology ?
can you share the secret ? i mean the sequence of your steps to know the technology,how did you study ? .. Hard work of course will be there9th October 2017 at 22:04 #70097LemaureGuest
This issue looks like a device failing to access the network during LU process.
Make a trace and find out if you have during the same window many LU rejection from the same IMSI. Ghost RACH are also usually related to overlapping same bsic-bcch which inconsistency you need to check And fix if need be