Mute call on 3G

[djordjebeg]

Hi NSN 3G experts,
since one year almost we have here and there mute call occurred.
It occurrs randomly event when radio conditions are perfect.
We run RU20 MP5 at the moment .

Do you have some experiance why it happens?
It happens for different cases - 3G AMR NB - 3G/2G AMR NB; 3G WB-3GWB, 3GWB-2GNB, 3G-Fixed.

Kind Regards,

[ChristopherAlbertini]

Hi NSN 3G experts,
since one year almost we have here and there mute call occurred.
It occurrs randomly event when radio conditions are perfect.
We run RU20 MP5 at the moment .

Do you have some experiance why it happens?
It happens for different cases - 3G AMR NB - 3G/2G AMR NB; 3G WB-3GWB, 3GWB-2GNB, 3G-Fixed.

Kind Regards,

We are exactly facing the same issue.
Our RAN is NSN and the core Ericsonn.

Can anyone help to locate where the issue is?

[djordjebeg]

We are exactly facing the same issue.
Our RAN is NSN and the core Ericsonn.

Can anyone help to locate where the issue is?

dear,

we have also E/// Core.
I asked also E/// yesterday to check if they have observed similar case somewhere else. it might happen that problem is in core.
But we I had traced one of my collegue and traces showed that UE had just lost connection for 15 seconds ( no measurement reports seen) and than cell update happenda with cause radio link failure .
Colleague had multirab and also seen RLC reset in RNC.
As a workaround to diminish negative perception ( until we solve problem completely) decrease T313 timer from 8 to 3 sec and increase T314 from 4 to 8 sec.
So the problem could be L1 radio synchronization as well.
We are confused now and NSN support is hopeless...

have you open the ticket to NSN. Mybe our and your NSN support can contact each other ?..

regards,

[ChristopherAlbertini]

dear,

we have also E/// Core.
I asked also E/// yesterday to check if they have observed similar case somewhere else. it might happen that problem is in core.
But we I had traced one of my collegue and traces showed that UE had just lost connection for 15 seconds ( no measurement reports seen) and than cell update happenda with cause radio link failure .
Colleague had multirab and also seen RLC reset in RNC.
As a workaround to diminish negative perception ( until we solve problem completely) decrease T313 timer from 8 to 3 sec and increase T314 from 4 to 8 sec.
So the problem could be L1 radio synchronization as well.
We are confused now and NSN support is hopeless...

have you open the ticket to NSN. Mybe our and your NSN support can contact each other ?..

regards,

Can you please share the results of the traces done?
Also, can you please explain what you are expecting by changing T313 and T314 timers?

[djordjebeg]

3058030580

please find attached trace.
if we decrease T313 than UE will sooner start procedure searching new cell and re-establishment will eventually occur faster - so less silent experience from end user observed.
now user can see silent for N312x50 ms + T313 ~ 9 sec and than it can start with cell update ( re-establishment) .
This is not solution, just a workaround at least try.
Another ting we will do is to increase EbNo for SRB3.4( associated) from default 8 db to 10 db.

regards,

[ChristopherAlbertini]

3058030580

please find attached trace.
if we decrease T313 than UE will sooner start procedure searching new cell and re-establishment will eventually occur faster - so less silent experience from end user observed.
now user can see silent for N312x50 ms + T313 ~ 9 sec and than it can start with cell update ( re-establishment) .
This is not solution, just a workaround at least try.
Another ting we will do is to increase EbNo for SRB3.4( associated) from default 8 db to 10 db.

regards,

Thanks
But I though increasing the timer could help...

Can you have a look on the attached document.

Anyway, is the situation better after decreasing the timer?

[djordjebeg]

Thanks
But I though increasing the timer could help...

Can you have a look on the attached document.

Anyway, is the situation better after decreasing the timer?

we have planned to implement changes on one RNC monday next week.
Tonight is going changes of Planned EbNo for 13.4/3.4 from 8 to 10 db as NSN recommendation according to TN159.

I will inform you about result for sure.

regards,

[djordjebeg]

yes CS drop is decreased from statistic point of view. But on the other hand you have masked problem with radio interface failure and i suggest to look to KPI relating to ratio of rl failuers and toatl established rab.



RL_FAIL_SRNC_RNL (M1005C204)/(


RNC_2008a (http://www.finetopix.com/#'Data'!Q1:Q1) +


RNC_2011a )


(http://www.finetopix.com/#'Data'!R1:R1)

[djordjebeg]

or it is even better formula for soft failure ( not counted as a drop but counted as service short brake ) :

(DEL SHO SRNC ACT RL SYN FAIL/
RL SETUP SUCC FOR FIRST RL+
RL BRANCH ADD SUCC SHO SRNC+
DEL SHO SRNC ACT RL SYN FAIL)

[ninjafine]

3058030580

please find attached trace.
if we decrease T313 than UE will sooner start procedure searching new cell and re-establishment will eventually occur faster - so less silent experience from end user observed.
now user can see silent for N312x50 ms + T313 ~ 9 sec and than it can start with cell update ( re-establishment) .
This is not solution, just a workaround at least try.
Another ting we will do is to increase EbNo for SRB3.4( associated) from default 8 db to 10 db.

regards,

Hi! Looking to your trace i may say that radio is almost perfect right before drop:
EcNo -4,5;
RSCP -85;
Ue Tx Power -4.

But during the call UE goes to Compressed Mode while being in MultiRAB. You may check if this RAB combination is tested good enough even for Compressed Mode
in your RAN+Core combination. You may check also if there is no alarms with NodeB synchronization.

[djordjebeg]

Hmm it seams that is related to multirab .
we have disabled PS sessions for few Ues where mute call occurred frequently for 2 days and mute call did not happens.
Anyway I still expect Root cause analysis from NSN as i have opened ticket to them.

thank you for you suggestions , I think that we are on the right direction to solve this.
i will keep you informed!

regards,

[djordjebeg]

hello , here is the nsns expert analysis of the problem:
seams reasonable...

In this failure case RLC reset happens to PS bearer and UE is transferred to PCH. But also CS Iub is removed. UE does cell update after 13 seconds and also the CS is setup again but user has disconnected the call already.

For RLC resets following findings:
HSUPA seems to be using low bit rate power offsets and used SIR target looks too high. No byte is coming from EDCH.
RNC SW TN 159: 6.1.26 HSUPA Initial SIR target offset enhancements has not been implemented. Please check and do the changes according to the TN:
- 0x4240H for 1703 RN50_MAINT_27
- 0xA864H for 1704 RN50_MAINT_28.

Also these parameters maybe reasonable to be modified:
RNCHSPA- CPICHRSCPThreEDCH2MS 130 ->125
RNHSPA- CPICHEcNoThreEDCH2MS -10dB to -6dB.

[ChristopherAlbertini]

hello , here is the nsns expert analysis of the problem:seams reasonable...In this failure case RLC reset happens to PS bearer and UE is transferred to PCH. But also CS Iub is removed. UE does cell update after 13 seconds and also the CS is setup again but user has disconnected the call already. For RLC resets following findings:HSUPA seems to be using low bit rate power offsets and used SIR target looks too high. No byte is coming from EDCH.RNC SW TN 159: 6.1.26 HSUPA Initial SIR target offset enhancements has not been implemented. Please check and do the changes according to the TN: - 0x4240H for 1703 RN50_MAINT_27 - 0xA864H for 1704 RN50_MAINT_28. Also these parameters maybe reasonable to be modified:RNCHSPA- CPICHRSCPThreEDCH2MS 130 ->125RNHSPA- CPICHEcNoThreEDCH2MS -10dB to -6dB.Did you manage to perform the changes?Is the problems fixed now?

[paboya]

Same ISSUE...even with NSN Core (ATCA) and ERIC Core
One our suspect is multiRAB, but still trial to disable MultiRAB
Coz in 2G Network no issue ?


We are exactly facing the same issue.
Our RAN is NSN and the core Ericsonn.

Can anyone help to locate where the issue is?

[ash_or]

Like Paboya said,

sometimes if parameter setting in multirab is not correct mute call will happen.
you should take look deeper in drivetest, and trace call using signalling trace analyzer, than you will find exactly signalling message before mute call happen.

[djordjebeg]

Hello,

we have changed parameter for lowbitrate HSUPA initial SIR target offset :
- 0x4240H for 1703 RN50_MAINT_27
- 0xA864H for 1704 RN50_MAINT_28
and problem did not disabpeard but mute periods are now much shorter ( before 8-12 sec) now ( 2-5 sec), and user perceprion is a bit improved , but far from that it is solved.

I guess that core has nothing to do with this.
Next step would be do disable multirab with hsupa, meaning that amr+HSDPA/DCH is only allowed.- planned for next Monday. Keep you informed people!
regards,

[gprastomo]

Hi,

I got this issue also on RNC Siemens, the problem was due to call reestablishment on CS Call, during this reestablishment, the cell update procedure was happened then produce mute call.
Then whem it swapped to NSN RNC it was solved, it was due to the minimum and max DL DPDCH power per connection for Siemens RNC was too low, the min was 3.4 dBm and max was 28.4 dBm, while for NSN 17 - 33 dBm, so it produced unnecessary out of sync which impact on call re establishment.

[plannerguy]

Hi

facing similar issue...NSN RAN and NSN Core.

Regards
Plannerguy

[ChristopherAlbertini]

Hello,

we have changed parameter for lowbitrate HSUPA initial SIR target offset :
- 0x4240H for 1703 RN50_MAINT_27
- 0xA864H for 1704 RN50_MAINT_28
and problem did not disabpeard but mute periods are now much shorter ( before 8-12 sec) now ( 2-5 sec), and user perceprion is a bit improved , but far from that it is solved.

I guess that core has nothing to do with this.
Next step would be do disable multirab with hsupa, meaning that amr+HSDPA/DCH is only allowed.- planned for next Monday. Keep you informed people!
regards,

Thanks for the feedback.

[kyokuman]

Hello,

we have changed parameter for lowbitrate HSUPA initial SIR target offset :
- 0x4240H for 1703 RN50_MAINT_27
- 0xA864H for 1704 RN50_MAINT_28
and problem did not disabpeard but mute periods are now much shorter ( before 8-12 sec) now ( 2-5 sec), and user perceprion is a bit improved , but far from that it is solved.

I guess that core has nothing to do with this.
Next step would be do disable multirab with hsupa, meaning that amr+HSDPA/DCH is only allowed.- planned for next Monday. Keep you informed people!
regards,


I am also having 3G mute calls. Investigations were done on L1 Reestablishment timers.. But problem still exists. I believe it has nothing to do with it..

My question to you is how the modification of those PRfile parameters could affect mute calls in a positive way? By Improving UL load by reducing Init SIR target for HSUPA?

[djordjebeg]

hello ,
after impleme ntation of the parameters RTW is decreased visibly from net act .
We have noted decreased amount of complaints.
BUT problem is not solved. On the other hand that clearly indicated that problem is UL interference.
Honestly my fear is that NSN algo inside hsupa scheduler does not work perfectly.

here is an answer form one of the NSN Rnd guys :

The issues with configuring PrxMaxTargetBTS with high values are:

- The Node B HSUPA scheduler will target PrxMaxTargetBTS so once there are a few HSUPA users in the cell, then the cell will experience high uplink interference increases and uplink coverage will shrink.

- The Node B HSUPA scheduler will become less accurate in terms of being able to target PrxMaxTargetBTS. High values of PrxMaxTargetBTS correspond to operating on the steep part of the exponential load curve. This makes it more difficult for the Node B to be accurate with its estimate of interference floor increases. The variance of the uplink interference floor will increase. The Node B may over-schedule during one instant, then under-schedule during the next instant. This may not be visible from the RNC due to the averaging of the PrxTotal measurements. UE may experience increases in their resource allocations, then decreases in their resource allocations as the Node B attempts to target PrxMaxTargetBTS.

SoThe issues with configuring PrxMaxTargetBTS with high values are:

- The Node B HSUPA scheduler will target PrxMaxTargetBTS so once there are a few HSUPA users in the cell, then the cell will experience high uplink interference increases and uplink coverage will shrink.

- The Node B HSUPA scheduler will become less accurate in terms of being able to target PrxMaxTargetBTS. High values of PrxMaxTargetBTS correspond to operating on the steep part of the exponential load curve. This makes it more difficult for the Node B to be accurate with its estimate of interference floor increases. The variance of the uplink interference floor will increase. The Node B may over-schedule during one instant, then under-schedule during the next instant. This may not be visible from the RNC due to the averaging of the PrxTotal measurements. UE may experience increases in their resource allocations, then decreases in their resource allocations as the Node B attempts to target PrxMaxTargetBTS.


So as a next step we will reduce parameter PrxMaxTargetBTS from 15 to 10 db . By that we will reduce hsupa throughput for 15% but expand congested cells in order to prevent UL interfernce.

Also 2 ms TTI range shell be shrinked by NSN.
This will also affect hsupa throughput but can prevent situations that 2 ms TTI can starve UL .



RNCHSPA- CPICHRSCPThreEDCH2MS

WCEL

130

125



RNHSPA- CPICHEcNoThreEDCH2MS

WCEL

-10

-6





Anyway it is optimization capacity vs quallity.
Good thing is that in RU30 PIC&FDE could compensate throughput loss..hopefully!

keep you updated.

[m121]

Hi, anybody finally solved this problem? Maybe you could share final solution?

[djordjebeg]

31193

Hello,

it was problem with UL excessive RTWP and after we have decreased it from 15 down to 10 db it was dramatically solved.
NSN also recommends 8 db .
usually networks have 8-12db in practice but I think that 10 is optimal.

I will request for further deep technical explanation of the slide 7 because NSN has pretty bad implementation of HSUPA scheduler ( not accurate at all). I compared with ZTE in my network and for ZTE I have similar parameter to PrxMaxTargertBTS of 20 db and there is no any mute call issue. Checking ZTE WBTS RTWP online logging i see that scheduler cut off interference to ROT .

Kind Regards,

[ash_or]

nice sharing,
should to try in our network.



31193

Hello,

it was problem with UL excessive RTWP and after we have decreased it from 15 down to 10 db it was dramatically solved.
NSN also recommends 8 db .
usually networks have 8-12db in practice but I think that 10 is optimal.

I will request for further deep technical explanation of the slide 7 because NSN has pretty bad implementation of HSUPA scheduler ( not accurate at all). I compared with ZTE in my network and for ZTE I have similar parameter to PrxMaxTargertBTS of 20 db and there is no any mute call issue. Checking ZTE WBTS RTWP online logging i see that scheduler cut off interference to ROT .

Kind Regards,

[ranflinho]

Hi,

We are having the same problem here and we are implementing some of the suggestions that are in djordjebeg's presentation. The problem is that when the mute periods occur, the BLER goes to the roof even though the EcIo and RSCP levels are optimal. Normally the mute periods are 5 seconds long.

Do you have an update on this issue or an additional recommendation?

Thanks!

[brianm]

Hi Experts

Facing a similar problem this side. Does anyone have a final solution to this problem?

[ranflinho]

Hi Experts

Facing a similar problem this side. Does anyone have a final solution to this problem?

Hi brianm,

After a lot of troubleshooting the problem was an incompatibility between RNC software version and Node B software version (we have RU30 RNC and RU20 node B). At least this was the problem in our network. You should check NSN Technical Note TS-RNC-SW-182 - H-RNTI allocation algorithm change in RU30 and implement it.

Hope this helps.

[djordjebeg]

You are right that is one of the problems for sure.
BUT even when you align software the problem will remain somehow.
the reason is CM delayed. UE enters CM and cancels it--> RNC sends exit CM to the node B but delays Measurement control commend to UE--> UE is still in CM for a while while Node B it is not--> radio link failure happends
Correction in RN6.0.2.3 mid of may ( 16.5.2013 expected GA)

beside of that the is one more issue in RU30. ISHO attempts fdue to DL DPCH are increased 4-5 times ( bug in Node Bs power calculation ). That causes mute calls as well. Suggestion is to disable DL DPCH cause for MRAB and Voice.

Another issue I am investigatoing now is that UE simply after RNC sents HO command cannot synch to 2G and gets stucked between 2G and 3G --> mute call. It could be that some Ue cannot read properly HO command but I am in mid of investigation and I'll info m you about results.



regards,
djordjebeg