- This topic has 10 replies, 1 voice, and was last updated 14 years, 6 months ago by
.
-
Posts
-
Hi, everybody!
In our network is anoying problem, that after handover from one cell to another for phones that are Geran feature 1 cappable starts problems with UL quality.
After first handover in alerting mode UL quality jumps to 7 and stays there till Connect. In that period of time Rx level is great, everyt other indicators are great.
This problem is so annoying because after UL qulity stays at 7 till Connect and that interval MS starts jumping between sectors due UL quality.
And this problem occurs only to Geran feature package 1 cappable phones.
Maybe anybody have any ideas whay it is like that and how to prevent it.
PS. Vendor Siemens.Hello Questener,
Before trying to help, I just need you to clarify this :
“After first handover in alerting mode UL quality jumps to 7 and stays there till Connect.”
What is this 1st HO…? Sounds like the Ms is doing a call setup, waiting for the CONNECT on its TCH. Why is there a 1st HO ? From which cell ? which timeslot ? (SDCCH ?)
UL Quality means the TRX is measuring a poor BER on the TCH coming from the MS. During this setup time, the TCH is empty though, because there are no speech frames in UL (nor in DL, for that matter).
1st possibility : DTX (again) Could you give me the UL_RXQUAL_FULL and the UL_QUAL_SUB values?
The only thing that is using the speech frames is called “TFO”. However, I am not sure if the TFO header in the speech frames is used in the BER computation. You could try to disable it ? If it is not enable, then don’t bother 🙂
Then finally, we could focus on the AMR. Because the GERAN feature package 1 brings some improvement on AMR (doesn’t it ?). So try disabling the AMR and see how it goes.
Does it happen on all cells ? or just one ?
Ok, i have to go,
best regards,
pixHi, pix.
Thanks for your answers.
1st Ho means that after call setup and TCH assignment if handover happens (Dual band configuration: Call is set up in GSM and then handovered to DCS band) problem that I described eralier happens.
But problem occurs even if there is no DCS:
Call is set up in one 900Mhz Cell, Alerting starts, MS moves and then is HO to another 900Mhz cell, UL quality jumps to 7 and stays, BSC trays to Ho it to another, then another then another cell, then comes Connect message, conversation starts and problem disapears.
If there is no handver (MS stays in the same cell all the time till Connect message) problem doesnt occure.
Sub and Full measurements both report UL Quality 7
Problem occurs only in cells where AMR is enabled and if for particular call AMR is not used, even if AMR is enabled, then problem doesnt occur.
TFO is disabled.it seems to point to an AMR problem… (hurray !)
I’m not familiar with siemens, but do you think there is any parameter that could cause such a weird behaviour?I don’t think so. Therefore I would tend to assume that either 3GPP or Siemens did a mistake somewhere.
Or perhaps it is still a problem with DTX ? Can you try to disable UL DTX for AMR calls ? that might improve the situation…
Cheers
pixho, and one more thing : why don’t you use the Forced directed Retry, instead of doing a TCH Handover ?
It is better to use FDR in your situation.
Cheers
pixHi,
Experimenting with UL DTX we will try next week, but for now I just wanted know if this kind of behavior are common in other networks and if there is any solution.
We couldnt find any parameters that could cause it. So at this moment problem is escalated to vendor and they are looking into it but till this moment only thing that they came up was that this is a phone manufacturer/3GPP fault but we are still fighting with they conclusion 🙂In our network Forced directed retry is active but it is used only when cell is congested and I dont see any point of using it in cases when TCH handover does just fine 🙂
If you have any good argument for using Forced directed retry over TCH HO then, please, point it out, maybe we will change our mind 🙂
PS. thanks for your answers Pixhi questner,
according to the vendor, what exactly would be the root cause of the problem ?
please let me know about your dtx experiments, it did fix AMR issues related to poor RxQual in ALU networks.
the FDR solution is usually used the other way around. Basically I would have a totally different approach than yours 🙂 Here is my strategy :
– call setup in 1800 rather than 900 (thanks to CRO)
– if 1800 is full, then we are happy, and we use FDR to direct excess voice traffic to 900
– if it is a GPRS TBF that is setup, then it should be redirected immediately to 900 cell (even if 1800 is not full). This can be done with specific NC2 parameters tuning.
Now, with your approach, a TCH HO makes more sense than FDR. I cannot say there are drawbacks with your method, except perhaps:
– allocating 2 TCHs for one call (one in the 900, another one in the 1800). Even if the 1st TCH is quickly deallocated, it still means there is a little waste here.
– when 1800 is congested, the 900 will still detect the HO cause, leading to poor outgoing HO congestion rate. Not impacting the subscribers though, so not really important.
– you are dedicated one HO cause for this specific purpose, therefore it cant’ be used for something else.
– your SDCCH radio quality depends on your 900MHz freq plan. Usually not that great… so perhaps you have higher SD drop rate and higher SD assign fails than you could.What do you think ? I’d like to hear your opinion 🙂
Pix
hi,pix
Our vendor is still experimenting in the lab so no final conclusion, but till this moment they found that this problem happens only with 2 phone manufacturers phones and they think that for particular AMR coding scheme MS indicates that it is sending traffic over TCH, but BS of corse doesnt receive any so it thinks that BER is very high.
With your strategy there are also some drawbacks:
You have to very accuratly use CRO because usually 900 coverage area is greater than 1800 and if you force MS to use 1800 all the time then MS in areas where 1800 coverage is very bad but 900 good will have problems.
FDR doesnt allways help so for your 1800 sectors CSSR statistics probably is pretty poor (in our network for every 20th MS that makes call in congested 1800 before he made cell reselection back to 900, FDR doesnt help, we have only 30-40 calls a day per congested 1800 cell so this is not big problem for us 🙂 )
Now about our drawbacks 🙂
Yes, our congestion, TCH blocking and Handocer success rate statistics looks very bad, but it doesnt affect customers so we arent bothering about most of them 🙂
Yes, there is also a TCH waste in 900 cells, but its small.
Also there is a benefit: we are traying to use 2 TRX per 900 cell, one for data traffic, other for calls and all exspansion, if possible, do in 1800 cell so we have greater coverage with smaller number of sites (different tilts and 3dBm makes all the difference :)) and its very helpfull in oasis like places.(in cities there is different story and aproach)
So our frequency plan is tight but not too much 🙂
SD assignment statistics for us are good and SD drops are over 0.15 only in 1800 because of very high congestion but we will try somehow to reduce it (althought doesnt have a clue how, yet)Questener,
Thank you for sharing, it’s very refreshing 🙂
Of course I wouldn’t push the CRO too high, and I would also use -as you do- an “early” TCH HO from 900 to 1800. However, starting from there, I would then increase the CRO as to decrease this number of early HO … but without creating situations where MS are attached to cells with bad level.
It’s all a matter of compromise in the end… I’m quite sure that even though we are looking at it from different point of view, our settings would probably be the same 🙂 What is your CRO & RXLEV ACCCESS MIN for 1800MHz & 900 MHz cells ?
I don’t understand why you said the CSSR in 1800 would be bad ? FDR is very effective, because the 900 coverage is always better than 1800. I can’t understand why a FDR would fail. (?)
Regarding the faulty MS’s : w8 & c 🙂
Cheers
pixHi, pix again 🙂
Yes, in places like this you allways can find a new way of doing everyday things 😀
For our network we use RxLev AccessMin the same for both cells and 1800 have 31 and 61 offset and pentime (i think that I remembered they values correctly) but 900 have 0 in both.
In your way of doing, tuning CRO – its just too much of a job because every BTS is “special” so in your case you must tune sector by sector and if there changes radio invarioment (external interference, new BTS and so on)?
Now about CSSR: for our network, for 1800 its pretty bad because every 20th call ends with no radio resources available message and without FDR. I will try next week to check it out, maybe we screw something up in parameters because in those unsuccsesful calls MS reports only 1800 neighbours and no 900 even if in MeasRep MS should report at least 3 different band cells. 1800 are congested so no FDR and CSSR goes down 🙂Quest,
CRO = 31 (dB !) and PT = 61 ? argh… doesn’t make sense 😀 you must have confused something.
In my case, I tune an average CRO for the whole 1800 cells in my network. Since all 1800 are collocated with 900, it works well. The goal is not to have perfect settings for each cell, but an average that works well everywhere.
As you noticed, most improvements come from frequency planning, antenna tilts, etc. Parameters should be simply tuned… (and fine tune only in some specific cases)I can certainly help you about FDR settings, if you need.
Regarding your 1800 congestion, the only solution is to load them less… –> load the 900 instead. One easy way to do it would be to reduce the sensitivity of your “early HO”.
Quest, you’ll be our “Geek of the Week End” ;-D (just kidding)
pix (Your Everyday’s Geek)
- The forum ‘Telecom Design’ is closed to new topics and replies.
