- This topic has 9 replies, 1 voice, and was last updated 8 years, 7 months ago by pix.
20th January 2009 at 14:31 #55465ZachGuest
I just brought up a site on GSM and am experiencing high SDCCH drop ratios….mostly confined to the ABIS fail ratio. I have not seen this before and wanted to know if you guys had ever seen anything like this. The entire BTS has been replaced with no effect. The only thing to be looked at is the backplane and my techs did not want to go into that without exhausting other options. The sweeps all came up clean and the TRX tests were also fine. The sector is going through an MCPA but we have brought up several of these before with no issue. Please advise on any tests or ideas you might have.20th January 2009 at 18:08 #55466PixGuest
We’re not working with the same equipment as yours, but there are some concepts that are shared by all vendors.
What you could do is, on the TRX / Air interface:
1/ change the position of the SDCCH timeslot (to another TRX)
2/ add another sdcch timeslot (on a different TRX)
On the Abis / BSC interface, try locating your sector on another BSC board (called TSU / TCU in alcatel), so that all signalling messages are handled by another BSC board than the current one.
You are not measuring any call drop (tch drop) ? Since TCH and SDCCH are sharing the same abis link, it means your abis is probably fine. You can focus on the signalling boards only.
Now, i don’t know the specifics of your vendor, but it might be software related also? In this case, deleting and recreating the sector in the OMC might solve the problem. Or might not… 🙂
Pix20th January 2009 at 19:47 #55467ZachGuest
Thanks for the tips Pix.
I am seeing some call drop values above our usual metrics. Some hours it will be below 2% and other hours it will even exceed 4%.
We have added additional control channels but have not looked into juggling the existing one around. I think I will give that a shot initially.20th January 2009 at 20:54 #55468ZachGuest
Juggling the SDCCHs has not shown any improvement either. The boards have also been replaced with no apparent change in the issue. The software re-install may be the route we have to take but probably as a last resort.20th January 2009 at 21:22 #55469PixGuest
What is the cause of call drop ? Hardware / Abis as well ?
2% to 4% is what I’d call pretty bad…
Ok, let’s focus on the radio:
Are there coverage or interference issues in the sector’s coverage ?
Is this sector pointing towards another Location Area ?20th January 2009 at 22:09 #55470ZachGuest
NDW only breaks the DCR into three categories
for 3pm the total DCR was 2.51….1.67 was RF related, 0.42 was HO, and 0.42 is Transmission…..These categories all vary from hour to hour….but RF usually carries the majority
I completed a drive test with TEMS and had no real issues during the drive. My shot in the dark would be possible interference from the Gamma sector since the Beta sector azimuth is 205 and Gamma is 285. However the beam width of beta is 88 deg while Gamma has only 45 deg. If they were shadowing, could that possibly be responsible?20th January 2009 at 23:13 #55471pixGuest
not if both sectors use different frequencies… are you in SFH 1×1? Even though, the BCCH would not hopping, and i assume your sdcch timeslot is located on the first TRX, am i right?
0.4% call drops due to transmission is bad. can you split the DCR per TRX, rather than the average for the whole cell?
If yes, do you notice more transmission call drops on the TRX that carries the SDCCH?
Do you notice drops due to transmission on other sectors as well, in the same percentage?
Finally: how many calls per hour and how many sdcch requests per hour on the bad sector?11th June 2009 at 15:55 #55472DilipGuest
can you pls which bts you r using?19th July 2012 at 05:07 #55473mathiasGuest
please want to know how many sdcch to be used per TRX?22nd July 2012 at 06:00 #55474pixGuest
A ratio of “1 SDCCH/8” per TRX is a safe strategy.
You can reduce to
2 SDCCH/8 per 3 TRX
And the minimum should be:
1 SDCCH/8 per 2 TRX