PowerPoint Presentation

Mute call issueConceptual Planning, Djordje BegenisicMonday, 26 May 2014Access Network | Confidential

7/191/241206/21/39255/122/0255/122/0143/21/62218/0/420/112/192223/0/81255/112/0119/109/106255/196/101199/80/127255/102/102102/169/217174/166/164201/196/195IntroductionMute 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.

Monday, 26 May 2014Page 2Access Network | Confidential7/191/241206/21/39255/122/0255/122/0143/21/62218/0/420/112/192223/0/81255/112/0119/109/106255/196/101199/80/127255/102/102102/169/217174/166/164201/196/195AnalysisThe 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.

Monday, 26 May 2014Page 3Access Network | Confidential7/191/241206/21/39255/122/0255/122/0143/21/62218/0/420/112/192223/0/81255/112/0119/109/106255/196/101199/80/127255/102/102102/169/217174/166/164201/196/195First step - accomplishedAfter we decreased initial SIR target by applying :

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 tracesAnother 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.

Monday, 26 May 2014Page 4Access Network | Confidential1703 RN50_MAINT_27RNC00x4240H1704 RN50_MAINT_28RNC00xA864H

7/191/241206/21/39255/122/0255/122/0143/21/62218/0/420/112/192223/0/81255/112/0119/109/106255/196/101199/80/127255/102/102102/169/217174/166/164201/196/195Second Step done not soled MCAs problem is not yet solved we have shrinked 2 ms TTI HSUPA area by changing :

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

Monday, 26 May 2014Page 5Access Network | ConfidentialRNCHSPA- CPICHRSCPThreEDCH2MS WCEL130125RNHSPA- CPICHEcNoThreEDCH2MS WCEL-10-8

7/191/241206/21/39255/122/0255/122/0143/21/62218/0/420/112/192223/0/81255/112/0119/109/106255/196/101199/80/127255/102/102102/169/217174/166/164201/196/195Third step week 51 20.12.2012 done pretty much solved MCNext 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.

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!

Monday, 26 May 2014Page 6Access Network | ConfidentialPrxtargetWBTSMaxWCEL1510

TC45 analysis :7/191/241206/21/39255/122/0255/122/0143/21/62218/0/420/112/192223/0/81255/112/0119/109/106255/196/101199/80/127255/102/102102/169/217174/166/164201/196/195VIP Mobile HQ Interference peaksNSN 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 L3Monday, 26 May 2014Page 7Access Network | Confidential

7/191/241206/21/39255/122/0255/122/0143/21/62218/0/420/112/192223/0/81255/112/0119/109/106255/196/101199/80/127255/102/102102/169/217174/166/164201/196/195Forth step week 52 it should be revised !Not to be done at the moment! Disable feature RAN974 for BGR02 :

Monday, 26 May 2014Page 8Access Network | ConfidentialRAN974: HSUPA with Simultaneous AMR Voice Callfeatureonoff7/191/241206/21/39255/122/0255/122/0143/21/62218/0/420/112/192223/0/81255/112/0119/109/106255/196/101199/80/127255/102/102102/169/217174/166/164201/196/195Mute 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}}}}}}}}Monday, 26 May 2014Page 9Access Network | Confidential7/191/241206/21/39255/122/0255/122/0143/21/62218/0/420/112/192223/0/81255/112/0119/109/106255/196/101199/80/127255/102/102102/169/217174/166/164201/196/195Silent call first analyze from NSNMonday, 26 May 2014Page 10Access Network | Confidential

7/191/241206/21/39255/122/0255/122/0143/21/62218/0/420/112/192223/0/81255/112/0119/109/106255/196/101199/80/127255/102/102102/169/217174/166/164201/196/195Exports from forum discussion about mute call http://www.finetopix.com/showthread.php?33055-Mute-call-on-3G/page2I 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 CoreOne our suspect is multiRAB, but still trial to disable MultiRABCoz 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? Monday, 26 May 2014Page 11Access Network | Confidential7/191/241206/21/39255/122/0255/122/0143/21/62218/0/420/112/192223/0/81255/112/0119/109/106255/196/101199/80/127255/102/102102/169/217174/166/164201/196/195Monday, 26 May 2014

Section headingSub-header goes hereAccess Network | Confidential7/191/241206/21/39255/122/0255/122/0143/21/62218/0/420/112/192223/0/81255/112/0119/109/106255/196/101199/80/127255/102/102102/169/217174/166/164201/196/195RAN optimization

Technical ChangeTC 36

Initial SIR target for low bitrate HSUPA channels -

VIP Mobile, Serbia, 04.12.2012Conceptual Planning & RAN optimization

This document shell provide proof of changes and optimsation activites for VIP mobile network. All changes of RAN parameters should be notified and verified if need through the specific Technical change request fill in form. The document contains reasons for the change , test case description, parameters impacted, possible drawbacks , input and output results and VIP Mobile decision about global roll out.

Technical Change 36

Purpose : decrease UL RTWP and eliminate mute call issue

Parameter impacted : - 0x4240H for 1703 RN50_MAINT_27- 0xA864H for 1704 RN50_MAINT_28.

Setup:Netact reporting suiteTems automatic2 drive test engineers1 optimization engineer

Test Procedure:Change - 0x4240H for 1703 RN50_MAINT_27- 0xA864H for 1704 RN50_MAINT_28.

On BGR02 from value 0 to NSN proposed values ( TN159 RRM optimization).Change is done 4.12.2012.Observe mute call occurrence for next 7 days.Observe reporting suite statistics after 7 days of monitoring.

Make tems automatic drive tests in Belgrade (BGR02) of two days.

8.1.26 HSUPA Initial SIR target offset enhancement

Problem: Especially when the low bit rate optimized HSUPA power offsets are used, the initial UL DPCCH SIR targets of HSUPA connections are higher than the stabilized values, which the SIR targets finally converge to. Therefore high HSUPA traffic results to the excessive RTWP. The higher the number of the HSUPA users are, the lower is the average bit rate of each E-DCH MAC-d flow, and therefore the longer periods it takes for the SIR targets to be reduced to the stabilized values. Especially the high power of the L1 control channels may keep the user plane bit rates low at least in the beginning of the convergence periods; HSUPA throughput tends to decrease though the UL BLER keeps low at the same time. Therefore the modification in the initial SIR target definition will reduce the RTWP, reduce the UL AC blocking and improve the PS call setup success rate

Output :

Expected results:Expected that mute call is minimized subjective feelingRRC-reestablishment should be decreasedData and voice setup success rate should be increased

Drawbacks:There is fear of decreased throughput for HSUPA

Netact KPis and reports :Reporting suite RNC Level reportCell capacity reportService report accessibilityService report retainabillityHSPA overview reportPower report cell level

Global Roll-out decision:

Subjective feeling is that mute call is not reduced and that mute periods last much shorter than before.DT measurements showed that there is no degradation in radio performances, au contraire, and HSUPA. throughput is slightly improved.

KPI analysis:RRC setup success rate is slightly degraded due to radio access not correlated with changes AMR performances are stable MRAB performances are not impacted Not visible impact on PS performances ( RAB drop ) No visible impact on SHO SR No visible impact on ISHO SR No visible impact on HSDPA throughputs HSUPA BLER increased NRT SSR ( RNC_576E) is improved for 25% ( 0.07%) !!! UL RTWP for marginal and overload area is decreased UL 2 ms TTI usage is increased AMR access failure due to UE decreased HSDPA and HSUPA RL failure rate decreased RL failure due to SHO rate in general increased because initial power for DCCH is lower EbNo for HSUPA is increased BLER for HSUPA is decreased RAB setup SR is increased RRC Re-establishment SR is stable Amount of UL DCH ISHO attempts I increased Amount of UL ISHO attempts due to Tx power is decreased

There are some misunderstandingsRL failures are increased while HSxPA radio failure rates are decreased.L3 BLER is decreased while L1 BLER is increased.Less interference in UL as it was expected.

Decision:Change should be implemented on whole network. Besides of that NSN should provide some answers on these uncertainties.

STATISTIC:

DRIVE TEST MEASUREMENT RESULTS:

Row LabelsUMTS PS Data Transfer Time (sec)UMTS PS Service Access Time (sec)RTT_AVG

mts6,952,07366,19

FTP DL11,732,42687,71

FTP UL11,991,68407,67

HTTP3,661,97350,53

Streaming

Ping54,67

HTTP DL File Transfer

Unknown

746,602,90297,74

FTP DL8,542,7267,63

FTP UL9,722,81220,80

HTTP4,903,00472,69

Streaming

Ping68,43

HTTP DL File Transfer

Unknown

vip5,881,59116,59

FTP DL8,091,64170,74

FTP UL7,781,4471,92

HTTP4,391,61131,69

Streaming

Ping60,32

HTTP DL File Transfer

Unknown

RAN optimization

Technical ChangeTC 39,TC42,TC42

UL interference elimination in order to minimize mute call -

VIP Mobile, Serbia, 14.12.2012Conceptual Planning & RAN optimization

This document shell provides proof of changes and optimsation activites for VIP mobile network. All changes of RAN parameters should be notified and verified if need through the specific Technical change request fill in form. The document contains reasons for the change, test case description, parameters impacted, possible drawbacks, input and output results and VIP Mobile decision about global roll out.

Technical Change 39;42;43

Purpose : Is to shrink HSUPA 2ms TTI area in order to minimize UL interference, allow faster call recovery by moving to 2G in case of Multi RAB calls and increase UL DRA algorithm

Parameter impacted :

Setup:Net act reporting suiteTems automatic2 drive test engineers1 optimization engineerLive RNC

Test Procedure:

Changes have been made on BGR02 ( Belgrade ) 14.12.2012.Change parameters:

Technical Change NumberParameterObjectVIPProposed value

TC39DeltaPrxmaxDwnWCEL0.82

TC42RNCHSPA- CPICHRSCPThreEDCH2MS WCEL130125

TC42RNHSPA- CPICHEcNoThreEDCH2MS WCEL-10-8

TC43Additiona windowFMCS42.53

TC43Drop windowFMCS445

TC43CPICH EcNo thresholdFMCS4-15-12

TC43CPICH EcNo cancelationFMCS4-13-10

TC43CPICH RSCP HHO cancelationFMCS4-110-106

TC43CPICH RSCP HHO ThresholdFMCS4-105-103

TC43 reverted back on 18.12.2012 in the morning.

Drive tests scheduled for 17-19.12 2012

KPI observation 14.12-19.12 2012 and then detailed KPI report shell be produced.

Output :

Expected results: It is expected that HSUPA/HSDPA SR is improved It is expected that HSUPA/HSDPA SR is improved Decreased UL interference Reduced mute call Improved voice retainabillity Improved MRAB retainabliility Improved SHO SR

Drawbacks:Degraded HSUPA throughput due decrease of 1 ms TTI usageIncreased amount of ISHO attempts for NRT and RTDecreased ISHO SRIncreased SHO OHIncreased OSVF usage and DL power usageIncreased signaling load

Netact KPis and reports :System report ( RNC level)Service Report ( accessibility and retainabillity )HSPA OverviewCell capacityRRC re-establishment Rate KPIRL failure counterISHO detailed statistics HSUPA BLER and TTi usageHSUPA throughputRTWP distributionMRAB performances

Global Roll-out decision:

HSDPA setup SR increased due to UE and UL DCH ( less uplink interference less UL blocking ) RAB setup success rate increased UL interference decreased NRT drop slightly increased due to radio RRC drop increased due to UE NRT SHO SR increased NRT ISHO SR degraded but after disabling TC43 reverted back tendentious Amount of compressed mode activations increased, but after disabling TC43 decreased expected! RL setup SR increased from NBAP RRC RAB setup increased SCC SR increased HSUPA BLER slightly decreased HSUPA Mac-e packets not received corectrly decreased 2 ms TTI usage is reduced for 8% HSDPA cell and end used throughput has same trend not degraded HSUA cell throughput not impacted CQI slightly degraded , but it could the weekend reason. MRAB setup SR slightly increased AMR performances are stable all the time RRC setup performances are stable RL failure decreased RRC re-establishment rate increased but after disabling TC 43 tending to be reverted back Cell update due to unrecoverable error decreased further RRC Re-establishment SR is same

Mute call is not resolved after this changes and NSN opinion is that we have too large value of parameter PrxMaxTargetBTS ( 15 db).Anyway this change reduced Ul RTWP, improved NRT accessibility , SCC and SHO performances.

STATISTICS:

RAN optimization

Technical ChangeTC 45.0

PrxmaxtargetBTS reduction -

VIP Mobile, Serbia, 20.12.2012Conceptual Planning & RAN optimization

This document shell provides proof of changes and optimsation activites for VIP mobile network. All changes of RAN parameters should be notified and verified if need through the specific Technical change request fill in form. The document contains reasons for the change, test case description, parameters impacted, possible drawbacks, input and output results and VIP Mobile decision about global roll out.

Technical Change 45.0

Purpose : To decrease UL RTWP peaks and eliminate mute calls

Parameter impacted : PrxMaxTargetBTS ( WCEL)

Setup: Netact Reporting suite Tems automatic 2 Drive test engineers 1 optimization engineer for analysis and setup BGR02 ( all cells)

Test Procedure:Set parameter PrxMaxTargetBTS from 15 to 10 db on all cells in BGR02 20.12.2012.Do drive tests after changes and monitor KPIs on netact for at least 5 days after TC45Make report after 5 or 6 days

Output :

Expected results: Mute call reduced UL RTWP decreased Accessibility improved Retainabillity improved

Drawbacks: HSUPA throughput decreased

Netact KPIs and reports : System report ( RNC level) Service report ( Accessibility and retainabillity ) Cell capacity HSPA general report RRC re-establishment rate KPI Cell update due to unrecoverable error Power report ( RNC level) HSUPA throughput ( RNC level)

Global Roll-out decision:Results : HSUPA throughput decreased for 200 kbps (10%) comparing to 2 days before TC45 has been applied. Measured BG (BGR02) with tems automatic. Regular work order. Also we have facing huge increase of hsupa and hsdpa data in the network before NY and that fact has also influenced throughputs on DL and UL both. RRC performances are stable. AMR KPIs are also stable NRT Setup success rate is improved slightly for few percent NRT SR is stable MRAB SR is improved slightly SHO SR Is not impacted ISHO SR is improved for AMR and slightly improved for NRT HSDPA SSR and SR are improved both for 10% HSUPA SR is improved for 15% and SSR for 12% SCC for HSDPA and HSUPA is reduced for20% Mute call seems to be reduced according to subjective feeling to be keeped observing

DRIVE TEST MEASUREMENTS:Before TC45:Values

Row LabelsWCDMA FTP DL Mean ThroughputWCDMA FTP UL Mean ThroughputWCDMA HTTP DL Mean Throughput

755.818,242.181,76421,19

Grand Total5.818,242.181,76421,19

After TC45:

Values

Row LabelsWCDMA FTP DL Mean ThroughputWCDMA FTP UL Mean ThroughputWCDMA HTTP DL Mean Throughput

755.554,351.955,94394,76

Grand Total5.554,351.955,94394,76

STATISTICS:

Hep Vladimir,Samples of the UL SIR target (value x 10).

SIR target keeps surprising low, though the high power offsets are used sometimes for HSUPA (default value for the initial SIR target is 9dB).Actually the MAC-d reports show that the PS are not very active and the PS is switched to 0/0 kbpsfrequently. Therefore AMR drives the UL outer loop and keeps the SIR target low.Low PS data rate, despite the fact, that the user plane is all the time reallocatedafter releasing it, may indicate that there coverage problems, maybe for the RTWP spikig.

In this log there are also taken the UL overload control measurements:start_ul_nrt_dch_downgrade_sreason: enhanced_overload_ctrl_c REQ_BR_1 = 800014:25:16.42

ccm_modification_command_sreason: enhanced_overload_ctrl_c14:25:16.42

brm_rb_resource_release_scause = default_c NRT REQ: DOWN: oper DCH = 4 DL_BR = 0 UL_BR = 800014:25:16.42

PrxMaxTargetBTS = 15dB is definitely too high, it makes the network unstable,I am not surprised for the dropped calls.TN159 recommends 8dB for it. It is better that you check the parameter plan of the network.

Actual muting problem of this call needs more investigation, I will check further whether, for instance, the compressed modehas any problem.BRPKo