- This topic has 12 replies, 1 voice, and was last updated 12 years, 11 months ago by
.
-
Posts
-
Hello all,
After SDCCH analysis, we’ve found most of SDCCH Radio drops occur during Ciphering.
Vendor is NSN, we use SDCCH Drop observation to get such detail stats.
It shows a problem with Ciphering/MSC settings or just happening due to time interval at the moment of ciphering?
Best regards
i would suspect a problem linked to ho high is your SDCCH drop rate due to radio ?
how high is the ratio of drops during ciphering ?
regards
pixThx Pix,
A problematic cell summary
Daily SDCCH Drop # : 1000
SDCCH Abis Drop # : 200
SDCCH Radio Drop # : 800
SDCCH Radio Drop on Ciphering phase # : 700
Daily SDCCH Drop rate : 1.8/2 %Most of cells/BSC_SDR is above 1.5 % in our network.
hi,
sorry my previous post didn’t make much sense, i’m glad you understood it ! (i was writing in a hurry)
so no – i don’t think the problem has to do with ciphering. If that was the case, most subscribers would experience it.
It would be great if you could find out what is the “trigger” or the “peg event” of the counter “ciphering sd drop”.
Anyway, are you certain you can rule out coverage or interference problems in those cells ? The best way to be sure is to compare the sd drop % with the tch drop %, trx per trx.
If radio problems are ruled out, then you might want to check “location update rejects”, which might not be visible in the BSS counters, but most probably available in the MSC/VLR counters. LU rejections (during IMSI attach) seem to be happening a lot for the past 2 years in many networks.Finally, can you try to activate the SDCCH Handover ? That would definitely rule out radio problems.
If it’s possible, you should do a drive test, see if the problem occurs during your tests. If that doesn’t work, you can do A interface traces, where you will exactly see what’s going on for those 2%.
This value is really low, it’s way too low to suspect a major misconfiguration in your network. So I can tell you that this “minor” (but mind bogging) problem is going to be a major headache… 🙂Will do my best to help, but you’ll have to do most of the work now…
Cheers
pixHi Ciph,
Kindly do note that SD Drop Rate for NSN remains relatively high even for an optimized network. It is the way the SD Drop counters are designed. SDR values around 1.5% are normal. (You must have noticed that TCH Drop Rate is lower. It is always like that with the standard NSN KPI formulae).
However, i still think the ratio of your radio drop is very high. Is your core part of NSN or some other vendor?
I second DangerousMinds on that. SDR in NSN is relatively high due to counter pegging design.
hi both of you,
could you explain why it is pegged more often than it should ? what’s the trick ?
thanks
Thanks guys,
As DangerousMinds said that TCH drop rate is lower than 1 % while SDCCH Drop rare is around 1.5/2 %.
If you know another formula of SD drop, pls share with me. We use NSN default sdr_4.
Its multivendor operator, NSN & Huawei. Its strange that NSN BSCs which connect Huawei MSC, SD Drop rate is lower than which connect to NSN MSC. There are some minor A interface SD drop in NSN-NSN system’ but our problem is still mainly in Radio part seem.
Pix,
SDCCH drop during ciphering;
We have a kind trace sw which shows when connection failure comes that indicated SD Drop.And when we analyze a call with this SW, most of radio SD drops happen during Ciphering phase. It’s explained as no reply one of side or connecion lost or messages not delivered. Shortly SD drops recorded at time of Ciphering, not before not after. There are still some drops during Imm assign, but no major.
BR
ciph,
thanks for the info. I’ll let the nsn experts reply, but i just want to understand something:
in your trace, the drop occurs during the ciphering phase ? Which means between those two events (if i remember correctly…???) :
– the MSC sends the ciphering mode command (in DL)
– the MS replies in UL with the ciphering mode response
could you share here the content of those two messages when there is the drop?
I would guess the “response” is not sent, because the drop would occur just before…?Cheers
pixHi Pix,
SDCCH Drop trace, only show MAIN phases like Basic Assignment / Ciphering / MM signaling / Relase…
Ciphering Flow:
MSC > BSC : Ciphering Mode Command
BSC > BTS : Enctyption Command
BTS > MS : Ciphering Mode Command
MS > BSC : Ciphering Mode Complete
BSC > MSC : Ciphering Mode CompleteBut we cannot see where/which above message fail exactly.
hi,
are you able to record an A interface trace ?there, you would see which message fail, or where exactly the drop occurs.
from what i understand, you can’t see any detail yet, and the sdcch drop counter is not “pegged” to the ciphering phase exactly. So you are actually quite blind about what’s happening. The next steps for you are to
– do a A-interface trace.
– find the exact event-trigger for this countercheers
pixPix,
SDCCH drop counter pegs due to Radio reason at the moment of Ciphering phase. But we dont know where exactly in Ciphering.
A trace was done by Core guys but nothing found abnormal as they said due to they dont have a tool for A trace anaylsis, they did it in text I think. so nothing come up.
If we find which message not send/arrive in Ciphering , then what? it means something?
Exp. fail at BTS > MS : Ciphering Mode Command..
so ?
you seem to have all data at your disposal, so you should really dig into that trace. Analyzing the text trace is ok, it will take time but it’s feasable !
Now… the only thing we can do here is wait for someone to have experienced this problem before and share with us…
cheers
pix
- The forum ‘Telecom Design’ is closed to new topics and replies.
