Analysis Report on HSPA Data Transmission Problems of XX ProjectPUBLIC

Analysis Report on HSPA Data Transmission Problems of XX ProjectPrepared by: HSPA Solution Maintenance Group Date: 2012-11-27, 2012OverviewHSPA data transmission problems fall into the following four types: Throughput problems in traffic statisticsThroughput problem s in drive testsComplaintsPing delay To solve these problems, perform the following four steps:Identify and classify problems. Perform forward check and implement corresponding measures. The checking covers the same aspects in the preceding four problems, including abnormal operation, alarms, precautions, parameters, and transmission configuration specifications. Perform backward check and implement corresponding measures. For the preceding four problems, perform different checking actions by referring to the following attachment.

Check whether problems are solved. ---EndStep 1: Identifying and Classifying Problems.BackgroundThis section introduces the background information about the concerned project briefly, including the project name, scale, networking mode (whether in IP networking mode or microwave transmission mode), and significant events before the problem occurs.Xxx project refers to subnet swapping of Deutsche Telekom. In May, 2011, operators invited Huawei to swap their subnets by sending an LOI. Huawei swapped 680 GSM sites and 160 UMTS2100 sites, and deployed 100 new UMTS2100 sites and 70 UMTS900 sites. For RRU 900/1800/2100, the module type is 3mRRU. The module type of RFU900 and RFU1800 is MRFU. The type of RFU2100 is WRFUd.After finishing tests in 2011, Huawei helped to swap live networks on September 26 of the same year.Transmission bearing mode: UMTS adopts IP over FE and GSM adopts IP over E1. After swapping, 3G HSDPA service rates become lower. Operators stop swapping networks and require urgent solutions.Version InformationProvide version information of the current network, including RNC/NodeB software versions and BTS types. If more than one version is involved, list them all. In upgrade scenarios, provide versions before and after the upgrade and the time when the upgrade is conducted. Version information is as follows:RNC version: V900R013ENGC00SPC550NodeB version: DBS3900 V200R013C00SPC339ProblemsAnalyze the problems described by operators and then provide analysis data. For throughput problems in traffic statistics, provide counter statistics evaluated by operators, specify the scenarios (swapping scenarios or upgrade scenarios) and requirements for the target value and expected value of the rate, and list historical data, for example, rate counters of live networks within the latest two weeks. For throughput problems in drive tests, confirm the drive test tools and network layer. Provide the results in tables or change trend diagrams.The problem in xxx office is that the tested 3G HSDPA rate is lower than that before swapping. The tool used in the drive test is Qvoice and the throughput is measured at the application layer.Karpos RegionTest Date(DD month, yyyy)Ping(ms)FTP DL Throughput(Kbps)FTP UL Throughput(Kbps)HTTP(s)

Before swapping03.05.2011192.2730.7290.215.42

After swapping20.03.2012301561.2295.617.41

23.04.2012271646.8275.617.36

24.04.2012441598.1263.717.15

30.04.2012383634293.917.59

02.05.2012195743.1313.216.44

03.05.2012209690.7307.417.48

11.05.2012151729.1303.315.76

15.05.2012246663.5315.716.22

16.05.2012128712.3300.517.15

17.05.2012158698.1291.516.11

18.05.2012160839.730515.64

21.05.2012135707.4302.216.27

Provide formulas of HSPA service rate-related KPIs to be measured of the current office. In swap scenarios, provide both formulas of the original network and mapping formulas of Huawei. Unexpected cases need to be recorded in the Original Network Counter Documentation.The table below lists the related KPIs.HuaweiEricsson

KPI NameKPI FormulaKPI NameKPI Formula

Classifying Problems and Determining ScopesConfirm whether the problem is throughput problems in traffic statistics, or throughput problems in drive tests, or ping delay. Confirm whether the problem occurs in the entire network or top cells.The confirmed problem is: 3G HSDPA rates are lower than those before swapping. Therefore, it is a throughput problem in drive tests.The drive test is carried out under the whole RNC. Therefore, the problem is identified as a network-wide problem. Performing Forward Check, Implementing Measures, and Providing Implementation ResultsProvide the implementation results from required actions, including necessary deliverables, troubleshooting results, and current difficulties.For parameter lists, see HSPA Data Transmission Parameter Checklists.xlsx.Required ActionCompletion StatusDateEngineer NameDeliverable and Check Result

Action 1: Checking abnormal operationsOngoingSOP inspection report

Action 2: Checking alarmsOngoingSOP inspection report

Action 3: Checking precautionsOngoingSOP inspection report

Action 4: Checking parametersOngoingParameter check results

Action 5: Checking the transmission configuration specificationsOngoingCheck results of transmission configuration specifications

The following is check results:Required ActionCompletion StatusDateCheck ResultPerformed Action

Action 1: Checking abnormal operationsCompletedMay 18OK

Action 2: Checking alarmsCompletedMay 18OK

Action 3: Checking precautionsCompletedMay 182 ms precautions are not checked.Taking preventive measures

Action 4: Checking parametersCompletedMay 18Four parameter values are inconsistent with baseline valuesModifying parameter values

Action 5: Checking the transmission configuration specificationsCompletedMay 18OK

Performed actions:The parameter value of RSCALLOCM (resource allocate method) has been set to CODE_PRI (code priority) and the baseline value in RAN13.0 has been modified to POWERCODE_BAL.The value of PWRMGN in some cells is 20 and the baseline value is 5, which result in less available HSDPA power. Therefore, actions have been taken to modify parameters.The value of MXPWRPHUSR is 70 and the baseline value is 100, which restrict the power of test users. Therefore, actions have been taken to modify parameters.CQI adjust algorithm switches are turned off, therefore, the dynamic BLER correction switches are turned on.Preventive measures are taken for 2 ms precautions.Results after actions are performed: throughput increases by 3% to 4%.

Performing Backward Analysis, Implementing Measures and Providing Implementation ResultsAnalyzing Throughput Problems in Traffic StatisticsRequired ActionCompletion StatusDateCheck ResultPerformed Action

Action 6: Analyzing resourcesCompletedMay 18Power congestion occurs in the uplink and downlink. Changing the uplink load threshold of cells with a high RTWP to 85%. Changing the maximum transmit power of cells where congestion occurs in the downlink from 30 W to 40 W.

Action 7: Analyzing traffic modelsCompletedMay 18The traffic volume increases by 1.8 times compared with that before swapping. Optimizing the HSUPA 2 ms policy and expand dual carriers (long-term policy).

Action 8: Analyzing coverageCompletedMay 18OK

Action 9: Analyzing the traced data about the single user throughputNot requiredMay 18OK

Action 10: Analyzing the traced data about the single user delay N/AMay 18OK

Action 6: Analyzing ResourcesIn swapping or upgrade scenarios, observe the resource congestion changes (power, CE, codes, and bandwidth) in the same area within the latest two weeks before and after swapping or upgrade respectively.In inventory networks, analyze resource congestion (power, CE, codes, and bandwidth) in a certain period.RNCIDULPower Cong TimesDLPower Cong TimesULCE Cong TimesDLCE Cong TimesCODE Cong TimesDLIUBBand Cong TimesULIUBBand Cong Times

111247822151128059400

Action 7: Analyzing Traffic ModelsCheck top cells and top periods:Identify top cells. Principles for identifying the top cells vary in different scenarios, as shown in the following:The DT fails during the swap or upgrade: Cells with a low service rate during the test are identified as top cells.The throughput in the test area (RNC-level areas) during the swap is lower than expected: Take the RLC weighted throughput as an example. Collect the traffic statistics of all cells in the test area during the test. Cells belonging to top 20% of cells with lower weighted throughput and top 20% of cells with larger RLC byte number are identified as top cells.The throughput in the test area (RNC-level areas) after the upgrade is lower than expected: Compare the cell throughput counters before and after upgrade. Cells whose throughput decreased dramatically are identified as top cells.In inventory networks, cells with minimum throughput are identified as top cells. Analyze traffic volume changes:Observe how the PS traffic volume in the same area changes within the latest two weeks before and after the swap or upgrade respectively. Use uplink/downlink total RLC PDU bytes and number of equivalent users to measure PS traffic volume.The figure below shows the check results:

After swapping, PS traffic volume in the downlink increases by 1.869 times.

Analyze the data distribution of online users by using the OMStar. The ratio of uplink 2 ms users to uplink 10 ms users is about 7: 3. Most terminals support the 2 ms policy. The HSUPA 2 ms policy configured on the live network does not comply with the baseline configuration and needs to be optimized.

Action 8: Analyzing CoverageIn swapping or upgrade scenarios, observe the CQI changes in the same area within the latest two weeks before and after the swap or upgrade respectively.On inventory networks, analyze the CQI distribution in a certain period.

Providing Backward Analysis ResultsDescribe what measures are taken and provide related implementation results.The following describes measures that are taken: For cells where uplink RTWP congestion occurs, change the cell uplink load threshold to 85%.For cells where downlink RTWP congestion occurs, change the transmit power from 30 W to 40 W.Results after measures are taken: throughput increases by 3% to 4%. For details, see Chapter 2.Analyzing Throughput Problems in Drive TestsRequired ActionCompletion StatusDateCheck ResultPerformed Action

Action 6: Analyzing resourcesCompletedMay 18Power congestion occurs in the uplink and downlink. 1. Changing the uplink load threshold of cells with a high RTWP to 85%. Changing the maximum transmit power of cells where congestion occurs in the downlink from 30 W to 40 W.

Action 7: Analyzing traffic modelsCompletedMay 18The traffic volume increases by 1.8 times compared with that before swapping. Optimizing the HSUPA 2 ms policy and expand dual carriers (long-term policy).

Action 8: Analyzing coverageCompletedMay 18OK

Action 9: Analyzing the traced data about the single user throughputCompletedMay 18The SCCH scheduling probability is low and the BLER is high. Enabling the TPE function. 2. Enabling dynamic BLER CQI correction.

Action 10: Analyzing the traced data about the single user delay N/AMay 18

Action 9: Analyzing L3 SignalingAnalyze the signaling:Problems in xxx office: HSDPA UE is of Category 6, supporting a maximum downlink rate of 3.6 Mbit/s.Action 9: Analyzing L1 SignalingThe analysis in this section covers scheduling probability (HS-SCCH success rate), CQI distribution, and BLER.Problems in xxx office: The Qvioce statistics based on comparison before and after swapping shows that the Huawei's scheduling probability is 15% lower than that of peer vendors.Before swapping (Ericsson), average user scheduling probability is 55% (DTX accounts for 45%).

After swapping (Huawei), average scheduling probability is 40% (DTX accounts for 60%).

Before swapping (Ericsson), the BLER is only 13%.

After swapping (Huawei), the BLER is 40%.

Action 9: Analyzing L2 SignalingThe analysis in this section covers RLC retransmission in the uplink and downlink and confirmed results (SufiACK or SufiList).There is no RLC retransmission.Action 9: Analyzing Application Layer SignalingAnalyze whether packet loss occurs on devices in the upstream or downstream of the RNC.Problems in xxx office: Corresponding to L1 signaling analysis, rates at the application layer are lower than those of peer vendors due to the low scheduling probability.Providing Backward Analysis ResultsDescribe what measures are taken and provide related implementation results.The following describes measures that are taken:Enable the TPE function to increase the scheduling probability.Enable the dynamic BLER CQI correction to decrease the BLER.Results after measures are taken: Rates increase to 776 kbit/s, higher than those of peer vendors. Analyzing ComplaintsAnalysis for complaints is same as that for throughput problems in traffic statistics and drive tests. Analyze traffic statistics. Then, analyze drive test data if drive tests are required.Analyzing Ping DelayRequired ActionCompletion StatusDateCheck ResultPerformed Action

Action 6: Analyzing resourcesCompletedMay 18Power congestion occurs in the uplink and downlink. 1. Changing the uplink load threshold of cells with a high RTWP to 85%. Changing the maximum transmit power of cells where congestion occurs in the downlink from 30 W to 40 W.

Action 7: Analyzing traffic modelsCompletedMay 18The traffic volume increases by 1.8 times compared with that before swapping. Optimizing the HSUPA 2 ms policy and expand dual carriers (long-term policy).

Action 8: Analyzing coverageCompletedMay 18OK

Action 9: Analyzing the traced data about the single user throughputN/AMay 18

Action 10: Analyzing the traced data about the single user delay CompletedMay 18In the test on the original network, ping packets are carried over the DCH and the delay is 191 ms. After swapping, delay changes to 247 ms and ping packets are carried over the FACH.Setting the state transition threshold to ensure that 32-byte ping packets can be carried over the DCH.

Action 10: Analyzing General DelayAnalyze whether abnormal delay and packet loss occur on devices in the upstream or downstream of the RNC.No packet loss occurs at the application layer.Action 10: Analyzing the Signaling FlowAnalyze the signaling flow:Nokia N95 supports only R99 services in the uplink and HSDPA services with a rate of 3.6 Mbit/s in the downlink. In the test on the original network, ping packets are carried over the DCH and the delay is 191 ms. After swapping, delay changes to 247 ms and ping packets are carried over the FACH.Action 10: Analyzing Delay over the Uu Interface The analysis in this section checks whether data is transmitted as expected over the Uu interface and whether BLER is high.Packets are assembled as expected and retransmission rates over the Uu interface are consistent with expected rates.Action 10: Analyzing the Iub InterfaceThe analysis in this section covers uplink/downlink RLC retransmission and transmission delay.Packet loss rate and delay over the Iub interface are normal.Providing Backward Analysis ResultsDescribe what measures are taken and provide related implementation results.Modifying the state transition threshold to ensure that 32-byte ping packets can be carried over the DCH by running the following command:SET UUESTATETRANS: D2F2PTVMTHD=D8, BeF2DTvmThd=D32, BeF2HTvmThd=D32, BeH2FTvmThd=D8, BeF2ETvmThd=32;After optimization, ping delay decreases from 271 ms to 158 ms.Checking Whether Problems are Solved Check whether problems are solved and complete analysis report.

2012-11-27Huawei confidential. No spreading without permission.Page 13 of 13

RNCHSDPA counterHSUPA counterCategoryVS.HSDPA.MeanChThroughputVS.HSUPA.MeanChThroughputProblem IdentificationVS.HSDPA.MeanChThroughput.TotalBytes VS.HSUPA.MeanChThroughput.TotalBytesProblem IdentificationVS.HSDPA.RAB.AttEstabVS.HSUPA.RAB.AttEstabProblem IdentificationVS.HSDPA.RAB.SuccEstabVS.HSUPA.RAB.SuccEstabProblem IdentificationVS.MeanRTWPSame as leftResource AnalysisVS.MaxRTWPSame as leftResource AnalysisVS.MinRTWPSame as leftResource AnalysisVS.MeanTCPSame as leftResource AnalysisVS.MaxTCPSame as leftResource AnalysisVS.MinTCPSame as leftResource AnalysisVS.MaxTCP.NonHSSame as leftResource AnalysisVS.MinTCP.NonHSSame as leftResource AnalysisVS.MeanTCP.NonHSSame as leftResource AnalysisVS.RAB.SFOccupy.MAXSame as leftResource AnalysisVS.RAB.SFOccupySame as leftResource AnalysisVS.HSDPA.RAB.FailEstab.DLIUBBand.CongVS.HSUPA.RAB.FailEstab.ULIUBBand.CongResource AnalysisVS.HSDPA.RAB.FailEstab.DLPower.CongVS.HSUPA.RAB.FailEstab.ULPower.CongResource AnalysisVS.HSUPA.RAB.FailEstab.ULCE.CongResource AnalysisVS.RRC.FailConnEstab.CongSame as leftResource AnalysisVS.RRC.Rej.ULIUBBand.CongSame as leftResource AnalysisVS.RRC.Rej.ULPower.CongSame as leftResource AnalysisVS.RRC.Rej.DLPower.CongSame as leftResource AnalysisVS.RRC.Rej.DLIUBBand.CongSame as leftResource AnalysisVS.RRC.Rej.ULCE.CongSame as leftResource AnalysisVS.RRC.Rej.DLCE.CongSame as leftResource AnalysisVS.RRC.Rej.Code.CongSame as leftResource AnalysisVS.RAB.FailEstabPS.CongSame as leftResource AnalysisVS.RAB.FailEstabPS.DLPower.CongSame as leftResource AnalysisVS.RAB.FailEstabPS.ULPower.CongSame as leftResource AnalysisVS.RAB.FailEstabPS.DLIUBBand.CongSame as leftResource AnalysisVS.RAB.FailEstabPS.ULIUBBand.CongSame as leftResource AnalysisVS.RAB.FailEstabPS.DLCE.CongSame as leftResource AnalysisVS.RAB.FailEstabPS.ULCE.CongSame as leftResource AnalysisVS.RAB.FailEstabPS.Code.CongSame as leftResource AnalysisVS.LCC.LDR.Time.ULPowerSame as leftResource AnalysisVS.LCC.LDR.Time.DLPowerSame as leftResource AnalysisVS.LCC.LDR.Time.DLCodeSame as leftResource AnalysisVS.LCC.LDR.Time.ULCESame as leftResource AnalysisVS.LCC.LDR.Time.DLCESame as leftResource AnalysisVS.LCC.LDR.Time.ULIubSame as leftResource AnalysisVS.LCC.LDR.Time.DLIubSame as leftResource AnalysisVS.RLC.AM.Tx.HsdpaTrf.PDU/Resource AnalysisVS.AM.RLC.Rtx.HsdpaTrf.PDU/Resource AnalysisVS.RLC.AM.Disc.HsdpaTrfPDU/Resource AnalysisVS.HSDPA.UE.Mean.CellVS.HSUPA.UE.Mean.CellTraffic ModelVS.HSDPA.UE.Max.CellVS.HSUPA.UE.Max.CellTraffic ModelVS.RB.AMR.DL.12.2Same as leftTraffic ModelVS.CellDCHUEsSame as leftTraffic ModelVS.CellFACHUEsSame as leftTraffic ModelVS.CellPCHUEsSame as leftTraffic ModelVS.PS.Int.Kbps.DL8VS.PS.Int.Kbps.UL8Traffic ModelVS.PS.Int.Kbps.DL16VS.PS.Int.Kbps.UL16Traffic ModelVS.PS.Int.Kbps.DL32VS.PS.Int.Kbps.UL32Traffic ModelVS.PS.Int.Kbps.DL64VS.PS.Int.Kbps.UL64Traffic ModelVS.PS.Int.Kbps.DL128VS.PS.Int.Kbps.UL128Traffic ModelVS.PS.Int.Kbps.DL144VS.PS.Int.Kbps.UL144Traffic ModelVS.PS.Int.Kbps.DL256VS.PS.Int.Kbps.UL256Traffic ModelVS.PS.Int.Kbps.DL384VS.PS.Int.Kbps.UL384Traffic ModelVS.PS.Bkg.Kbps.DL8VS.PS.Bkg.Kbps.UL8Traffic ModelVS.PS.Bkg.Kbps.DL16VS.PS.Bkg.Kbps.UL16Traffic ModelVS.PS.Bkg.Kbps.DL32VS.PS.Bkg.Kbps.UL32Traffic ModelVS.PS.Bkg.Kbps.DL64VS.PS.Bkg.Kbps.UL64Traffic ModelVS.PS.Bkg.Kbps.DL128VS.PS.Bkg.Kbps.UL128Traffic ModelVS.PS.Bkg.Kbps.DL144VS.PS.Bkg.Kbps.UL144Traffic ModelVS.PS.Bkg.Kbps.DL256VS.PS.Bkg.Kbps.UL256Traffic ModelVS.PS.Bkg.Kbps.DL384VS.PS.Bkg.Kbps.UL384Traffic ModelVS.AMR.DL.Traffic.BestCellVS.AMR.UL.Traffic.BestCellTraffic Model VS.GTPU.BytesPkt.TxVS.GTPU.BytesPkt.RxTraffic ModelVS.HSUPA.UE.Mean.TTI2msTraffic ModelVS.HSUPA.UE.Max.TTI2msTraffic ModelVS.HSUPA.UE.Mean.TTI10msTraffic ModelVS.HSUPA.UE.Max.TTI10msTraffic ModelVS.HSUPA.TTI2to10.AttTraffic ModelVS.HSUPA.TTI10to2.AttTraffic ModelVS.HSUPA.RABEstabTTI10ms.AdmCE.SuccTraffic ModelVS.HSUPA.RABEstabTTI10ms.ResRTWP.Succ Traffic Model VS.HSUPA.RABEstabTTI10ms.ResUsedCE.SuccTraffic ModelVS.HSUPA.RABEstabTTI10ms.ResIUB.SuccTraffic ModelVS.HSUPA.RABEstabTTI10ms.Cover.SuccTraffic ModelVS.BackGroundNoise.MeanResource AnalysisVS.BackGroundNoise.MaxResource AnalysisVS.BackGroundNoise.UpdateResource AnalysisVS.HSUPA.TgtRoTIncResource AnalysisVS.HSUPA.TgtRoTDecResource AnalysisVS.MeanULActualPowerLoadResource AnalysisVS.MaxULActualPowerLoadResource Analysis

&G&F

&D&P&N

NodeBHSDPA counterHSUPA counterCategoryVS.DataOutput.MeanVS.HSUPA.MeanBitRateProblem IdentificationVS.DataOutput.UserVS.HSUPA.MeanBitRate.WithDataProblem IdentificationVS.UsedCQI0~VS.UsedCQI39VS.HSUPA.MaxPwrLmtUserRatioResource AnalysisVS.AvaiHSDPAPwrRatio.MeanVS.HSUPA.LeftPwrLmtUserRatioResource AnalysisVS.AckTotalVS.HSUPA.ACKTotalResource AnalysisVS.NackTotalVS.HSUPA.NACKTotalResource AnalysisVS.DtxTotalVS.HSUPA.DTXTotalResource AnalysisVS.PdschCodeUtil.MeanVS.HSUPA.UnHappyUserNumRatioResource AnalysisVS.PdschCodeUtil.MaxResource AnalysisVS.ScchCodeUtil.MeanResource AnalysisVS.ScchCodeUtil.MaxResource AnalysisVS.ATMDlTotal.1VS.ATMUlTotal.1Resource AnalysisVS.ATMDlMaxUsed.1VS.ATMUlMaxUsed.1Resource AnalysisVS.ATMDlAvgUsed.1VS.ATMUlAvgUsed.1Resource AnalysisVS.IPDlTotal.1VS.IPUlTotal.1Resource AnalysisVS.IPDlMaxUsed.1VS.IPUlMaxUsed.1Resource AnalysisVS.IPDlAvgUsed.1VS.IPUlAvgUsed.1Resource Analysis

&G&F

&D,&P&N

DelayHSDPA counterHSUPA counterCategoryNEVS.IUB.FlowCtrol.DL.DelayVara.LgcPort1.MaxVS.IUB.FlowCtrol.UL.DelayVara.LgcPort1.MaxProblem IdentificationNodeBVS.IUB.FlowCtrol.DL.DelayVara.LgcPort1.AvgVS.IUB.FlowCtrol.UL.DelayVara.LgcPort1.AvgProblem IdentificationNodeBVS.IPPM.Rtt.MeansProblem IdentificationRNCVS.IPPM.MaxRttDelayProblem IdentificationRNCVS.IPPM.Forward.JitterStandardDeviationProblem IdentificationRNCVS.IPPM.Back.JitterStandardDeviationProblem IdentificationRNCVS.IPPATH.PING.MaxDELAYProblem IdentificationRNCVS.IPPATH.PING.MeanDELAYProblem IdentificationRNCVS.IPPATH.PING.MeanJITTERProblem IdentificationRNCVS.IPPATH.PING.MaxJITTERProblem IdentificationRNC

&G&F

&D,&P&N