You are on page 1of 12

Mute call issue

Conceptual Planning, Djordje Begenisic

Wednesday, 12 February 2014 Access Network | Confidential

> Mute call is phenomena when A side cannot here B side or vice versa, and before call is normally established. It can happen rarely that both sides cannot hear each other. > User normally start speech call and during conversation feel muted connection. > Initially connection was muted > 6 sec and A or B side disconnected call after all. > Many users made complains event bellow the antenna site. > Mute call phenomena is first time observed in September 2011 but at the first time sporadically occurred. > Mass complaints , firstly from VIP employs and than from other customer, started to happened in April 2012. > In may 2012 ticket to NSN is opened for the issue called Silent call. > The wording was not appropriate as silent call means cannot hear you from the very beginning of the call. > NSN so far did not provide final solution.
Page 2 Wednesday, 12 February 2014 Access Network | Confidential


> The main problem is that we cannot correlate mute call occurrence with any counter without detailed analysis. > For detailed analysis iub tracing system was need and VIP did not have any . > Starting from beginning of December 2012. it was possible to trace problem in Belgrade via Megamon tracing tool. > First analyze from NSN technical analyst indicated problem in UL interference. > All calls which was muted had also PS session in parallel smart phones. > Analyst said that PS session in parallel indicated too many interference in UL. > First recommendation is to decrease interference by decreasing initial SIR target for low bit rate HSUPA . > Than it was recommended to shrink 2 ms TTTi HSUPA area as 2 ms TTIs indicated higher interference as well.
Page 3 Wednesday, 12 February 2014 Access Network | Confidential

First step - accomplished

> After we decreased initial SIR target by applying :

1703 RN50_MAINT_27
RNC 0 0x4240H 0 0xA864H

1704 RN50_MAINT_28


> We have achieved lower interference levels in UL, improved some KPIs and slight reduction of mute call.
> \NSN\OPTIMISATION\NIka_12Q4_13Q1 Detailed TC change description with results including EMIL traces

> Another change is important is to decrease T313 from 8 to 3 sec in order to aloe UE to find faster suitable call and make cell-re-establishment. > Result is that in many cases call recover faster and mute effect was minimized with naturally increased DCR for AMR, > On the other hand in order to keep voice DCR at same level we have changed T314 from 4 to 6 sec and AMR DCR vent back to the old values.
Page 4 Wednesday, 12 February 2014 Access Network | Confidential

Second Step done not soled MC

> As problem is not yet solved we have shrinked 2 ms TTI HSUPA area by changing :
WCEL WCEL 130 -10 125 -8

> Mute call is not solved sill and impact on KPIs is elaborated in the document :

Page 5

Wednesday, 12 February 2014

Access Network | Confidential

Third step week 51 20.12.2012 done pretty much solved MC

> Next step is to decrease PrxtargetWBTSMax from 15 to 10 db or even to 8 db. This will reduce real network HSUPA throughput for 10-15% but it will keep interference lower in the UL. > This might not be an issue as in RU30 FDE and PIC will compensate throughput loss.
TC45 analysis :
PrxtargetWBTSMax WCEL 15 10

> > >

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.


The question here : Why NSN UL scheduler is so imperfect !?!! Explanation from NSN needed ! For example for ZTE with PrxMaxBTS = 20 db we have not faced mute call issue!
Page 6 Wednesday, 12 February 2014 Access Network | Confidential

VIP Mobile HQ Interference peaks

NSN has imperfection in HSUPA scheduler. Despite PrxMaxtarhgetBTS was set to 10 db RoT went up to 20 db for 10 sec after averaging on L1 and L3

Page 7

Wednesday, 12 February 2014

Access Network | Confidential

Forth step week 52 it should be revised !Not to be done at the moment!

> Disable feature RAN974 for BGR02 :
RAN974: HSUPA with Simultaneous AMR Voice Call




Page 8

Wednesday, 12 February 2014

Access Network | Confidential

Mute call message before

> >

RadioLinkFailureIndication NBAP-PDU : initiatingMessage : { procedureID { procedureCode 25, ddMode common }, criticality ignore, messageDiscriminator dedicated, transactionID shortTransActionId : 31, value RadioLinkFailureIndication : { protocolIEs { { id 44, criticality ignore, value CRNC-CommunicationContextID : 81861 }, { id 199, criticality ignore, value Reporting-Object-RL-FailureInd : rL : { rL-InformationList-RL-FailureInd { { id 207, criticality ignore, value RL-InformationItem-RL-FailureInd : { rL-ID 2, cause radioNetwork : synchronisation-failure } } } } } } } }

Page 9

Wednesday, 12 February 2014

Access Network | Confidential

Silent call first analyze from NSN

Page 10

Wednesday, 12 February 2014

Access Network | Confidential

Exports from forum discussion about mute call
> 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? > > Hi , facing similar issue...NSN RAN and NSN Core. 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. 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 Ericcsson.



Can anyone help to locate where the issue is?

Page 11

Wednesday, 12 February 2014

Access Network | Confidential

Section heading

Sub-header goes here

Wednesday, 12 February 2014 Access Network | Confidential