Technical Guide To LTE Throughput DT Data-Based Accurate Network Optimization

NPI V200R007 Technical Guide to LTE Throughput DT Data-based Accurate Security Level:
Network Optimization INTERNAL
Product Name Security Level
INTERNAL
Product Version Total 66 pages
NPI V200R007 Technical Guide to LTE

Throughput DT Data-based Accurate Network
Optimization
Prepared By Yang Jing (employee ID: 00184099) Date 2015-07-01

Granted By Date
Huawei Technologies Co., Ltd.

All rights reserved
2019-8-22 Huawei confidential. No spreading without permission. Page 1 of 62

Change History
Data Issue Change Description Author
2014-12-22 V1.00 Completed the draft. Chen Qinlong (employee ID:

00239588)
2015-04-26 V1.02 Modified the description for RF analysis. Yang Jing (employee ID:
Modified the interpretation for reports. 00184099)
The modification involves the throughput
problem summary sheet and RF problem
sheet.
2015-07-01 V1.03 Updated the description for the OMStar. Yang Jing (employee ID:
00184099)
2015-07-22 V1.04 Added the description for SFN cells and Yang Jing (employee ID:
ACP. 00184099)

1 Overview
1.1 Background and Value
1.1.1 Background
On or LTE networks, a large number of DTs are conducted during the engineering and routine
optimization. DT data is manually analyzed by engineers, which results in low efficiency and poor
delivery in batches, and analysis results are constrained by engineers' capabilities. As a result, the results
of problem analysis and optimization effects vary. In addition, DT problem is caused by coverage and
interference but the root cause is not further located.
1.1.2 Value
Based on DT data, the accurate network optimization solution on LTE networks standardizes experts'
network optimization experience, narrows the scope for locating root causes, and locates problematic
areas and possible causes so that:
 RF engineers do not need to analyze large amount of duplicate data.
 Problem analysis efficiency is improved.
1.2 Introduction
The root cause analysis for LTE DT throughput focuses on two types of problems, sudden drop
throughput, and low throughput. The analysis is performed in multiple key dimensions, such as air
interfaces, handovers, and abnormal events.
The root cause analysis feature automatically analyzes the log files, CHR files, traffic statistics files, and
alarm files collected from the UEs used in a DT. This feature allows users to handle problems caused by
continuous low throughput by problem identification and assessment, isolation and demarcation, and
root cause analysis. After the analysis, optimization suggestions are provided, and an analysis report is
generated to help network optimization engineers to efficiently detect and resolve problems.

1.3 Constraints
1.3.1 Specification Constraints
1. Probe version: The current prototype tool is used with Probe V300R006C00SPC300 and
V300R014C00. Field names in DT data sources may vary depending on Probe versions. (In normal
cases, the name of a field is changed unless the field is incorrect. Otherwise, more fields are added
in later versions without changing the names of fields in earlier versions.) Before using other
versions, confirm what changes occur in the fields of configuration files. Replace the
corresponding field name in the configuration files and then use the files. Otherwise, the tool fails
to import the data.
2. Tool: This solution is based on the OMStar V500R010. Related OMStar specifications and
requirements are listed as follows:
− A single analysis supports 8-hour DT data and the analysis duration is less than or equal to one
hour.
− The PC memory is greater than or equal to 1 GB.
− The data listed in the following table is required.
Analysis Engineering MML Probe DT Traffic Alarm CHR File
Dimension Parameter Configuration Data Statistics
Coverage Mandatory N/A Mandatory N/A N/A N/A

analysis
Interference Mandatory N/A Mandatory N/A N/A N/A
analysis
Handover Mandatory Mandatory (used Mandatory N/A N/A N/A
analysis to analyze whether
delay handover is
caused by missing
configurations of
neighboring cells)
Abnormal Mandatory N/A Mandatory N/A N/A Optional
event analysis (used when
in-depth
analysis is
performed for
call drops and
handover
failures)
Capacity check Mandatory Mandatory Mandatory Mandatory N/A N/A
Parameter Mandatory Mandatory Mandatory N/A N/A N/A

check
Alarm check Mandatory N/A Mandatory N/A Manda N/A
tory
3. U-Net version: The U-Net is used to calibrate the propagation model and provide ACP. The
solution uses the COST Hata231 model, and only the U-Net V300R010 can calibrate this
propagation model. Therefore, the U-Net version must be V300R010.

1.3.2 Constraints on Application Scenarios

4. The analysis accuracy of cell ID, overshoot coverage, and incorrect coverage depends on the
engineering parameter accuracy: In the analysis report generated by the tool, cell names and
analysis results for overshoot coverage and incorrect coverage depend on the engineering
parameter accuracy. The engineering parameters must be accurate. Otherwise, analysis results may
contain errors. You are advised to calibrate the engineering parameters before using this solution.
5. Only the time factor is considered during frequent handovers and the geographical factor is
not considered: Multiple handovers in a certain distance are not considered as frequent handover
scenarios. The length of roads where frequent handovers occur is provided for reference. When the
vehicle runs at a lower speed, the frequent handover is restricted for use.
6. Incorrect coverage analysis is restricted in some scenarios and the incorrect coverage is
determined by the proportion of incorrect coverage, and therefore the analysis is not supported in
the following abnormal scenario:
A DT vehicle parks at a place with incorrect coverage and the DT is performed for a long period of
time, the speed of vehicles in areas with normal coverage is fast, and little statistics are collected.
The test scenario will be incorrectly considered as incorrect coverage.
7. DT terminals using Qualcomm or HiSilicon chips can be used only after related configuration files
are adjusted.
Scenario Constraints Preventive Measure
Qualcomm chip The Qualcomm chip used by DT terminals If the Qualcomm chip must be used,
used by DT cannot send neighboring cell level modify the configuration file as follows:
terminals information (the Detected Cell RSRP(dBm)
1. Find and open the
field is empty) to the Probe. As a result, the
following analysis is not supported: *\Huawei\GENEX\OMStarV500R
overlapping coverage, no primary serving 012\client\conf\LteP3KqiData\
cell, mod 3 interference, and missing LteThroughtCfg.ini file in the tool
neighboring cells.
installation directory.
2. Modify information in the following
three lines:
(a) Change
DETECTED_Cell=Detected
Cell PCI to
DETECTED_Cell=Listed
Cell PCI.
(b) Change
DETECTED_RSRP=Detected
Cell RSRP(dBm) to
DETECTED_RSRP=Listed
Cell RSRP(dBm).
(c) Change
DETECTED_EARFCN=Dete
cted Cell EARFCN to
DETECTED_EARFCN=Liste
d Cell EARFCN.

Scenario Constraints Preventive Measure
HiSilicon chip used The PCC PDSCH RB Number and PCC If the HiSilicon chip must be used,
by DT terminals PDSCH RB Number/Sub Frame fields in change the
the DT data exported from the Probe are the *\Huawei\GENEX\OMStarV500R012
same although their calculation methods are \client\conf\LteP3KqiData\
different. The PCC PDSCH RB Number LteThroughtCfg.ini file in the tool
field is used for the Qualcomm chip while the installation directory.
PCC PDSCH RB Number/Sub Frame field Modify the information in the following
is used for the HiSilicon chip. The uplink two lines:
indicators are also similar. The configuration
file of the tool uses the two files by default. If (a) Change PDSCH_RB_NUM=PCC
the HiSilicon chip is used, change the field PDSCH RB Number to
name in the configuration file by performing PDSCH_RB_NUM= PCC
the preventive measures. If you do not modify PDSCH RB Number/Sub Frame.
the file, the number of RBs cannot be (b) Change PUSCH_RB_NUM=PCC
collected. PUSCH RB Number to
PUSCH_RB_NUM= PCC
PUSCH RB Number/Sub Frame.
Version restrictions The Probe version must be V300R014C00. Use the correct version. You are advised
for LTE analysis The NE version must be eRAN7.0 or 8.0. to import the data of all sites where
when the CHR (The two versions have been verified and field abnormal events occur after 10 to 20
correlation analysis verification is required for other versions.) minutes.
is required The size of CHR data cannot exceed 1 GB.
1.4 Maturity
This solution can be used to analyze DT data and identify problem roads. Based on problem roads and
cells, RF optimization engineers can use other GIS observation tools to perform RF optimization. For
missing neighboring cells, prepare scripts after adding policies, and then deliver the scripts to resolve
the problem. Using this solution, RF optimization engineers do not need to analyze large amount of DT
data, which reduces time consumption.
The following tables describe maturity of each them.
RAT Theme Submodule Maturity
LTE Coverage Common weak coverage Perform RF optimization based on GIS observation.
analysis
Overlap coverage For reference only. Preferentially handle with
problematic roads of the submodule with overshoot
coverage in the interference analysis theme.
No primary serving cell For reference only. Preferentially handle with
problematic roads exported from the submodule
with no primary serving cell in the handover
analysis theme.
Restricted uplink This solution cannot determine whether restricted
uplink is caused by uplink interference. Manual
analysis is required.

RAT Theme Submodule Maturity
Interference Overshoot coverage Rectify engineering parameter problems and

analysis perform RF optimization based on GIS observation.
PCI mod 3 conflict Only cell pairs with conflict are identified. Analyze
root causes based on the PCI theme.
Overlapping coverage Adjust the antenna parameters or power of
neighboring cells.
Handover Frequent handover Instead of the geographical factor, the time factor is
analysis only considered during frequent handovers. The
length of roads where frequent handovers occur is
provided for reference. When a vehicle runs at a low
speed (< 20 km/h), the frequent handover
submodule is restricted for use.
Handover timeout 1. Match neighboring cells based on missing
configurations of neighboring cells, prepare
scripts after adding policies, and then directly
deliver the scripts to the network.
2. Other causes of the handover timeout problem
are processed with each submodule in the
coverage analysis and interference analysis
themes.
Abnormal Abnormal event 1. The abnormal event analysis is correlated with

event the coverage and interference analysis to analyze
E-RAB release
basic problems.
Intra-frequency/inter-
frequency handover failure 2. The abnormal event analysis is correlated with
CHRs to obtain the causes for abnormal events
Inter-RAT handover failure
recorded in the CHRs.
RRC reestablishment
failure
Capacity analysis When the number of RBs or grant does not reach the
threshold, check the PRB usage, CCE usage,
PUCCH usage, SRS usage, and average number of
subscribers in cells where problem roads with low
throughput exist.
The following table describes the maturity for the optimization suggestions.

Optimization Suggestion Maturity
Antenna and power adjustment optimization The locating results can be used as reference.
However, the antenna adjustment suggestions cannot
be implemented directly. Frontline engineers must
determine the adjusted angles based on live network
situations.
Troubleshooting of transmission and interference Optimization directions are provided only. The
problems suggestion implementation depends on frontline
equipment engineers.
Capacity expansion and site addition Approval needs to be obtained from frontline
engineers and customers.
2 Basic Principles
2.1 Technology Structure of the Solution
The following figure shows the process of the solution. The process involves the following operations:
Filter out top cells: filters out cells that greatly affect the throughput on the entire network.
Evaluate problem roads: using specific rules, identifies problem roads with sudden drop throughput or
low throughput (these problem roads are considered as analysis objects).
Demarcate faults and locate the root cause for problem roads: analyzes the root causes in each problem
point on the problem roads and obtains the main root cause of the road throughput.
Locate root causes in top cells: calculates the ratio of root causes of problems in all top cells, and
obtains the main causes for the throughput of the cells.
Provide optimization suggestions: provides optimization suggestions and directions for different cells.

2.2 Filtering Top Cells

The principles for filtering top cells are as follows:
8. Filter the problem DT points whose throughput is less than the threshold, and record the number of
points.
9. Calculate the number of problem DT points in each problem cell and sort the problem cells by the
number in descending order.
10. Accumulate the numbers of problem DT points. When the accumulated number is greater than or
equal to 80% of the number of problem DT points, the accumulation is complete. The cells where
the 80% problem DT points locate are the top cells.

2.3 Evaluating Problem Roads

The procedure for identifying the problem roads with sudden dropping throughput is as follows:
11. Verify that the throughput at a DT point does not reach the threshold.
12. Compare the average throughput at the DT point and its throughput in the earlier 3s (the
throughput in the 3s reaches the threshold). If the throughput deteriorates more than 50%, identify
later points of this point until three consecutive points whose throughput is greater than the
threshold (which indicates that the three points reach the threshold).
13. Calculate the number of DT points from the first identified point to the point that meets the
requirement. If the number is less than 7, the road encounters the sudden dropping throughput.

The procedure for identifying problem roads with low throughput is as follows:
Scan the DT points one by one to identify the point that has low throughput. Record the point. When the
subsequent three points meet the requirement (the DT point to be added and the previous DT point can
cross a maximum of two DT points, and the number of across DT points can be changed), the DT points
are added to the same road until no subsequent three points meet the requirement. If the number of DT
points in a road is greater than 7 (the value can be changed), the road is a problem road.
2.4 Demarcating Faults and Locating the Root Cause for Problem
Roads
During demarcation of faults and locating of the root cause for problem roads, basic problems are
checked (the check involves alarms and parameters) and then the throughput is analyzed.
Coverage analysis is performed on all the DT points on the roads that have sudden dropping throughput
or low throughput. After the analysis, the root causes for the problems in each DT point are located. The
method of locating the sudden drop throughput is different from that of locating the low throughput.
2.4.1 Checking Alarm

Based on the problem cells and times of an abnormal service, the alarms related to the cells and sites
where the throughput is abnormal are checked to identify whether an alarm that affects the throughput
of P3 counters exists in the cell or site when the service is normal. If such an alarm exists, the road and
alarm are correlated as the possible cause for the problem. In addition, the alarm impact and handling
suggestions are provided.
2.4.2 Checking Parameters

Based on the problem cells of an abnormal service, the feature parameters that affect the throughput are
checked. The parameter values are compared with recommended values. If they are different, the
comparison result is provided to facilitate problem locating.

2.4.3 Analyzing Coverage

Coverage analysis involves only the cells that are not contained in the neighboring cell table reported by
the serving cell. After the coverage analysis for each DT point is complete, calculate the percentage of
DT points with improper coverage on a road, as shown in the following figure.
2.4.4 Locating the Root Cause for Sudden Dropping Throughput

Sudden dropping throughput is caused by early handovers due to improper parameter settings or a
sudden change of the environment. The following figure shows the detailed analysis process.

2.4.5 Demarcating Low Throughput and Locating the Root Cause

Low throughput is analyzed as follows: Check whether an abnormal event occurs on the analyzed road.
If an abnormal event occurs, locate the event cause. If no abnormal event occurs, check whether a
handover problem occurs (frequency or delay handover). If such a problem occurs, locate the problem
cause. If no such problem occurs, analyze the air interface. The analysis involves coverage, interference,
and resources.
Air Interface Analysis

When no abnormal event or handover problem occurs on the road, perform air interface problem
analysis for the road. The following figure shows the analysis method (for insufficient scheduling,
coverage problems, and interference problems, further analysis is required).

1. Coverage analysis
When the SINR at the DT point is less than the threshold and the RSRP is less than the weak
coverage threshold for cells, the DT point is in weak coverage. The following figure shows the
process for locating the weak coverage. The locating involves analysis of missing neighboring
cells, delay handovers, isolated island areas due to coverage overlap, and handover prohibition in
neighboring cells.
2. Interference analysis
When the SINR at the DT point is less than the threshold but the RSRP is greater than the weak
coverage threshold for cells, the downlink interference exists. Analyze whether the downlink
interference is caused by the restricted uplink or interference among downlink neighboring cells.
The following figure shows the analysis process.

3. Insufficient scheduling
If the ratio of the DT points with insufficient scheduling is greater than the lower threshold (20%)
in the problem road, check whether resource restriction occurs in the problem cells on the road
during the DT. If the resource restriction occurs, the problem is caused by the insufficient
scheduling. If the resource restriction does not occur, the problem is caused by other factors, such
as a TCP/IP factor.

Abnormal Event Analysis

After the problem roads with an abnormal throughput are evaluated, check whether abnormal events
occur on the roads. If abnormal events occur, analyze the events. The analysis involves the following
two parts:
1. For abnormal events, such as call drops, intra-RAT handover failures, and inter-RAT handover
failures, correlate the data of a single subscriber in the DT with the CHR data at the site. Identify
the subscriber's event in the CHR and extract the recorded key information about the event based
on the event type and related CHR fields. Then, locate the root cause for the event. The root cause
may be no available resources or cells.
2. Check whether the road with the abnormal event has coverage or interference problems. If
the problems occur, the abnormal event may be caused by the problems. The analysis method
is the same as that for the coverage and interference analysis.
The following figure shows abnormal events for which the analysis is supported in the solution.
Handover Analysis
The handover analysis theme is used to identify handover-related problems. The problem types that can
be identified are shown in the following figure. After the analysis, problematic roads with handover
timeouts, frequent handovers, and ping-pong handovers are isolated and optimization suggestions are
provided.
1. Handover timeout
A serving cell has poor level or quality and a neighboring cell has better level and the handover
thresholds are met, but no handover occurs in a timely manner. As a result, coverage-related or
quality-related problems occur on the road. Service quality is affected and call drop may occur.
When a UE reports A3/A4, no inter-frequency or intra-frequency occurs after the entered handover
timeout duration expires (the default duration is 300 ms). A handover timeout occurs.
If a handover timeout occurs due to PCI confusion, you are advised to adjust confusing PCIs.
If a handover timeout occurs due to missing configuration of neighboring cells, you are advised to
add corresponding neighboring cells.

When a UE reports A3, the RSRP of neighboring cells is checked. If the RSRP of the strongest
neighboring cell is lower than the weak coverage threshold, the handover timeout is caused by the
weak coverage of neighboring cells. In this situation, you are advised to enhance the coverage.
If the handover timeout is not caused by missing configuration of neighboring cells, PCI
confusion, or weak coverage of neighboring cells, you are advised to check handover-related
parameters or check whether air interface signaling is missing.
2. Frequent handover
If frequent handovers of a UE occur multiple times in a short period, subscribers' service quality is
affected and call drop may occur.
The frequent handover duration threshold (the default value is 10s) and the frequent handover
number (the default value is 2) can be configured. During the frequent handover duration, if the
number of times that a UE handover among cells is greater than or equal to the threshold, a
frequent handover occurs.
3. Ping-pong handover
If a UE meets the condition for the frequent handover and repeatedly hands over between the
source cell and the target cell, a ping-pong handover occurs. The source and the target cells need to
be specified.
If a frequent handover or a ping-pong handover occurs, check whether no primary serving cells
exist in the problematic road with frequent handover. By performing the antenna adjustment, you
can locate the primary serving cell and adjust antenna in unnecessary neighboring cells. In this
way, the negative impact on the handover zone can be reduced. Parameters related to ping-pong
handover can be adjusted based on actual requirements.
Major Root Cause Locating for Problem Roads

After the root causes for each DT point on a road are located, analyze the major root causes for the road.
The following figure shows the analysis process.

2.5 Locating Causes for Top Cells

The preceding analysis obtains the root causes for each DT point and main causes for the roads. Obtain
the roads where top cells exist and root causes for cell in each road based on the DT points. Then,
analyze the root causes as follows:
If the root causes for the cell are the same on different road sections, the problems on these road
sections are caused by the root cause.
If the root causes for the cell are different on different road sections, the problem is analyzed using the
process listed in the following figure.

2.6 Providing Optimization Suggestions

Optimization suggestions are provided by root cause.
3 Application Guidance
3.1 Application Overview
The delivery process of this solution includes the following actions: data collection, tool preparation,
report generation, report interpretation, and optimization implementation.
The following table describes the purpose of each action. For details about the guidance, see the
subsequent chapters.
Action Purpose
Action 1: data Collect the input data, including engineering parameters, RNC
collection configuration, Probe test data of this solution.
Action 2: tool Obtain the OMStar and U-net, apply for the license, and start the tool.
preparation
Action 3: report Use the U-Net to calibrate the coefficients of the propagation model.

Action Purpose
generation Use the OMStar to perform theme analysis.

Action 4: report Filter out key problems based on each theme analysis report generated
interpretation by the OMStar, and formulate optimization measures based on some
solutions provided by these reports.
Action 5: Implement the optimization measures based on the output of action 4.
optimization
implementation
3.2 Action 1: Data Collection

3.2.1 Overview
This action collects data required by the solution to prepare data for subsequent analysis.
3.2.2 Tools
M2000, Probe V300R0014C00, and BM_Master
3.2.3 Input
DT area
3.2.4 Process
Data Collection
1. Engineering parameter collection (mandatory)
Only one file exists for engineering parameters, and all fields in the file are mandatory. The
engineering parameter template for normal scenarios is different from that for the SFN scenarios.
For the templates, see the following attachments, Engineering Parameter-Normal.xls, and
Engineering Parameter-SFN.xls.
Engineering Engineering
Parameter-Normal.xlsx
Parameter-SFN.xlsx
All the table headings must be the same as the parameter names in the template (including the
capitalization style). You are advised to copy the network data to the template (to select all data in
one column, press Ctrl+Shift and press the Down key). Use the same method to copy data in other
columns to the template.
The table headings do not need to follow specific requirements. Engineering parameters cannot
contain special characters, such as space, # (number sign), and N/A.
To improve import efficiency, you are advised to use the engineering parameters
of the DT area or surrounding areas (the parameters for the entire network can

also be used). The engineering parameters of the DT area must be imported. For
details, see the following table.
Parameter Description Mandatory or Not
eNodeBName Indicates the name of an eNodeB. Mandatory

eNodeBID Indicates the ID of an eNodeB. Mandatory
CELLID Indicates the ID of a cell. Mandatory
CellName Indicates the name of a cell. Mandatory
LONGITUDE Indicates the longitude of a site. Mandatory
LATITUDE Indicates the latitude of a site. Mandatory
AZIMUTH Indicates the azimuth of a cell. Mandatory
Height Indicates the height of a site. Mandatory
PCI Indicates the PCI of a cell. Mandatory
TAC Indicates the TAC of a cell. Mandatory
uarfcnDl Indicates the downlink frequency. Mandatory
Outdoor Indicates whether it is a macro base Mandatory
station.
sfngroup Indicates whether it is an SFN cell. Mandatory in SFN scenarios
antennatype Indicates the type of the antenna. Mandatory in SFN scenarios
gain Indicates the gain of the antenna. Mandatory in SFN scenarios
tilt Indicates the mechanical downtilt. Mandatory in SFN scenarios
etilt Indicates the electrical downtilt. Mandatory in SFN scenarios
omnistation Indicates the omnistation flag. Mandatory in SFN scenarios
1. Outdoor: Enter no or yes. Set this parameter to a correct value. Otherwise, the overshoot coverage
determining result is incorrect.
2. yes: indicates a macro base station.
3. no: indicates an indoor distributed base station.
4. Sfngroup: The value for a common cell is Normal, and the value for an SFN cell is the group ID of the SFN.
5. omnistation: indicates whether it is an omnistational site. yes indicates an omnistational site, and no indicates
a directional site.
2. MML configuration data collection (mandatory)
Export XML files using the M2000. Save the exported files in the same directory (select the
directory when exporting files.) The following figure shows the files exported using the M2000,
and the files are named based on the site names.

3. Traffic statistics collection (optional)

The tool supports processing of traffic statistics of eRAN7.0 and eRAN8.0. For normal
scenarios, collect the traffic statistics in the DT period. For SFN scenarios, you are advised to
collect the traffic statistics in six busy hours on three days for data splitting and combination. The
data must contain the traffic statistics in the DT period.
You are advised to use the NIC to collect traffic statistics.
4. Alarm data collection (optional)
Export the alarm logs generated before the DT is complete from the M2000. Copy the required
fields to the Alarm Log Check Template. Different versions have different fields. To keep data
consistency and reduce maintenance workload, you are advised to the template.
Alarm Log Check

Template.xlsx
5. CHR data collection (optional)

The CHR data for eRAN7.0 and later versions are supported. The data in the DT period must be
collected. You are advised to collect the data using the NIC and subscribe to the following events:
PRIVATE_HO_IN
PUBLIC_INFORMATION
PRIVATE_INTRA_RAT_HO_OUT
PRIVATE_INTER_RAT_HO_OUT
PRIVATE_UE_CONTEXT_RELEASE
PRIVATE_INNER_REL_EVENT
PRIVATE_RRC_REEST
RRC_CONNECTION_REESTABLISHMENT_REQUEST (standard event for RRC collection re-
setup)
The following figures show how to subscribe to the CHR events using the NIC. The preceding
events are contained in the access events, release events, and other events. For details about how to
obtain the collection result, see the related guide.


DT Data File
DT data file generation:
The DT data source file supported by the OMStar is in the CSV format. The file collected by the Probe
is in the GEN file. Use the Probe to convert the file to the CSV format. The detailed procedure is as
follows:
Step 1 Open the Probe. Choose Logfile > Export Data from the main menu, as shown in the following
figure.
Step 2 Select the file format as CSV, and click Next, as shown in the following figure.

Step 3 Click Add to import the DT data file in the GEN format, select the path for saving the file, and click
Next, as shown in the following figure.
Step 4 Select a test terminal, click Load, and select the export template, as shown in the following figure.

Select the export template (for details, see section 4.1"LTE DT Data Source Export Template"). Select
the file in the XML format, export the file twice, and save the files in two different folders (Throughput
and Events).
Open the export template, and you can see some fields are selected.
Step 5 Click Start to export the data (retain the default values of parameters).
After the exporting, find the file in the directory configured in Step 3. If you do not set the directory in
Step 3, the file is saved in the directory of the GEN data file by default.

The following figure shows the file queried in the directory selected in Step 3.
----End
3.2.5 Output
Engineering parameters, MML configurations, and DT data file
3.3 Action 2: Tool Preparation

3.3.1 Overview
This action obtains the OMStar and plug-in for theme analysis.
3.3.2 Tool
None
3.3.3 Input
None

3.3.4 Process
Obtaining the Tool and Plug-in and Applying for the License
1. Obtain the OMStar V005R12 from the following URL: Support > Product Support > Wireless
Network > FDD > LTE FDD RAN > LTE FDD Services > OMStar
2. Obtain the OMStar plug-in from the following URL (before obtaining the plug-in, log in to the
http://w3.huawei.com):Open http://support.huawei.com/carrier/navi#col=product&path=PBI1-
7851894/PBI1-21433538/PBI1-7854329/PBI1-21465981/PBI1-59728 and then find “LTE
Throughput DT Data-based Accurate Network Optimization.rar”
Installing the Plug-in

1. Open the OMStar, click “File”, select “Import Patches”:
2. Then click the button, select the path of the patch, then select the file with the fomat of zip,
install the patch.

3. After install, there is a message for success installation.
If install the old pathc version before, the message will be apper, then click “OK”, and
restar the OMSTAR. It can be used with new patch.
Note:
1. To install the patch, the version of omstar must be the same with the patch. The database
must be unintall with the software together when necessary.
2. After the patch installation, create a new poject in LTE subject, the “LTE DT THP Root
Cause Analysis” topic can be selected.

3.3.5 Reference Document

None
3.4 Action 3: Report Generation

3.4.1 Creating a Project and Importing the Data
Step 1 Click File > New Project, or click the icon in the red box shown in the following figure.
Step 2 In the window for creating a project, set the project name and save path, and click Next.
Step 3 Select the LTE DT THP Root Cause Analysis, and click OK.

Step 4 In the window for importing data sources, right-click the name of each data source, and select a path to
import a file.
When you import data sources, pay attention to the following points:
1. Before importing traffic statistics, import configuration data.
2. In SFN scenarios, expand the engineering parameter fields.

Before importing engineering parameters, right-click Engineering Parameter Data, and choose
Engineering Parameter Extend Field Management from the shortcut menu. The window
for expanding the engineering parameter fields is displayed. Select the path for the engineering
parameter fields, and click OK.
3. The engineering parameter field file is saved in the plug-in installation directory
(:\Huawei\GENEX\OMStarV500R010\LTE3pkqi). The file format is as follows:
Engineering Parameter Expansion Files.rar
4. Antenna data must be imported in SFN scenarios and is not required in non-SFN scenarios.
5. The KQI data is the input for KQI optimization in P3 scenarios and is not required in throughput
optimization.

3.4.2 Creating a Task

Click Analysis Task Managment. The task creation window is displayed. Click New task. The
dialog box for creating a task is created. Enter the task name, and click Next. The window for setting
parameters is displayed.
3.4.3 Setting Parameters
Calibrating Propagation Model Coefficients (Applies Only to SFN Scenarios)

In SFN scenarios, calibrate the propagation model coefficients. For details, see section 3.5.12"Radio
Propagation Model Calibration (Applies Only to SFN Scenarios)." After the calibration, update the
coefficients in path
*\Huawei\GENEX\OMStarV500R010\LTE3pkqi\config\LteP3KqiData\PLCoefficient.
The following figure shows the formula for parameter settings and the propagation model. The four
coefficients following [MSCOEFF] are used in a ( hms ) , and the five coefficients following
[PLCOEFF] are used in PL (dB ) .

PL(dB) = 46.3 + 33.9log10 ( f ) - 13.82log10 ( hbs ) - a( hms ) + (44.9 - 6.55log10 ( hbs )) log10 (d )
a(hms ) = (1.1log10 ( f ) - 0.7) hms - (1.56 log10 ( f ) - 0.8)
Setting Parameters in the Window for Root Cause Analysis

The following figure shows the parameter setting window. In the window, select a report path, scenario,
and parameters for root cause analysis.

When setting the parameters, pay attention to the following points:

1. When you select a path for the report, the generated report will be saved in the path. Click the icon
shown in the red box in the following figure, select a path, and click Save
2. Select a scenario. The default scenario is Normal (refers to a normal cell). If SFN cells exist on a
network, select SFN.
3. Set parameters. All the parameters displayed in the window use default values. Change the values
based on site requirements.
− SFN scenario parameters: are configured only when SFN cells exist.
 SFN Setting: Select a value based on the scenario of the cell on the network. By default, it
is City.

 Serving RRU THD: used to identify the serving RRU. It is the ratio of the accumulated
value for equivalent RSRPs of RRUs in different groups to the accumulated value for
equivalent RSRPs of remaining RRUs. By default, it is 5 dB.
 Interference RRU THD: used to identify whether an RRU is an inference RRU. It is the
difference of level RSRPs between the interference RRU and serving RRU. By default, it
is 3 dB.
− Throughput parameters

 PDCP Throughput DL（kbps）: indicates the downlink throughput threshold. If the

throughput of a DT point is less than the threshold, it is a problem DT point. By default,
the value is 10 Mbit/s. The unit in the window is kbps.
 Max Dl Grant Value: indicates the number of Grants assigned based on the theoretical
downlink full scheduling principles. The default value is 600. The theoretical peak value is
calculated based on live network configurations and can be changed. The default value is
the theoretical peak value of SA2/SSP5. The theoretical peak value of SA2/SSP7 is 800. It
is calculated based on site configurations. This parameter is set to 1000 based on the FDD
full scheduling principles.
 RB Num in overall band witdth: The number of RBs varies depending on
frequency bands. The following table lists their relationship.
Frequency Band Number of RBs
5 MHz 25
10 MHz 50
15 MHz 75
20 MHz 100

 Schedule insufficient factor: If the number of Grants scheduled by a collection point is

less than Grant number or RB number max theory value X%, insufficient scheduling
problems may exist in the collection point. The scheduling service coefficient for single-
user tests on a load-free network is set to 90%. The scheduling service coefficient on a
medium load network is set based on actual situations and the recommended value is 70%.
 THP deteriorate ratio THD: If the deterioration value of the average throughput for a DT
point with that of multiple previous DT points (set these DT points in the Sample numbers
before deteriorate) is greater than the threshold, the DT point has dramatically dropping
throughput. By default, the threshold is 50%.
 Sample numbers before deteriorate: refers to the description for THP deteriorate ratio
THD.
 Continuous Samples Num THD: indicates the minimum value of problem points on a
problem road. By default, it is 7.
 Interval Samples Num THD : When the number of problem points that do not meet
conditions is greater than the threshold, the problem road ends. By default, it is 3.
− Air interface parameters
 RSRP THD of Weak Coverage: When the RSRP of the primary serving cell is less than
the threshold, weak coverage occurs. By default, it is –100 dBm.

 RSRP THD for better neighbor cell: When the RSRP of neighboring cells is greater than
the threshold, strong coverage occurs. By default, it is –90 dBm.
 RSRP THD for Depth: When the RSRP is less than the threshold, in-depth weak coverage
occurs. By default, it is –120 dBm.
 PUSCH Power THD: If the terminal transmit power is greater than the threshold on a road,
the road is determined as a road with restricted uplink. By default, it is 10 dBm.
 Interference SINR THD(Condition1): When the SINR is less than the threshold and the
RSRP is greater than the RSRP THD for better neighbor cell, interference exists. By
default, it is 3 dBm.
 Interference SINR THD(Condition2): When the SINR is less than the threshold and the
RSRP is greater than the RSRP THD of Weak Coverage, interference exists. By default, it
is 0 dBm.
 Overlapping RSRP THD: Indicates the threshold for poor RSRPs of cells with overlapping
coverage. By default, it is 6 dB.
 Overlapping Ncell Num THD: indicates the number of neighboring cells of cells with
overlapping coverage. By default, it is 2.
 No main Serving Cell RSRP THD: Indicates the threshold for poor RSRPs of cells without
a primary serving cell. By default, it is 3.
 No main Serving Cell Ncell Nell THD: indicates the number of neighboring cells of cells
without a primary serving cell. By default, it is 2.
 MCS THD: indicates the MCS threshold. By default, it is 3.
− Handover parameters

 Frequently Handover Time Region: If the number of handovers within the threshold is
greater than or equal to Handover Count Threshold, frequent handovers occur. By default,
it is 10s.
 Handover Count Threshold: indicates the number of handovers within the handover time
range. By default, it is 3.
 Handover Delayed Time Threshold: indicates the duration during which no handover
occurs when handover conditions are met. By default, it is 300 ms.
 Handover Delayed Level Threshold: If no handover occurs in a specified time period when
handover conditions are met and the RSRP is lower than the threshold due to no handover,
handover delay occurs. By default, it is –100 dbm.
− Capacity parameters

 UL/DL PRB Avail Threshold: By default, it is 75%. After the counter of a cell on the
problem road is greater than the threshold, the PRB usage is high and is displayed in red.
 CCE Avail Threshold: By default, it is 45%. After the counter of a cell on the problem road
is greater than the threshold, the CCE usage is high and is displayed in red.
 CFI3 Avail DL Threshold: When the proportion of CFI 3 is 90% higher than the threshold
and CCE usage is greater than 45%, the two counters are displayed in red.
 PUCCH Avail DL Threshold: By default, it is 60%. After the counter of a cell on the
problem road is greater than the threshold, the PUCCH usage is high and is displayed in
red.
 SRS Avail DL Threshold: By default, it is 60%. After the counter of a cell on the problem
road is greater than the threshold, the SRS usage is high and is displayed in red.

3.4.4 Output
The task running window is displayed:
 You can create multiple tasks at a time. The tasks are running one by one by time sequence.
 You can double-click a task and choose “Delete Project” from the shortcut menu to delete the task.
 You can view the task running progress. The task start time and end time are recorded.
After a task running is complete, the following dialog box is displayed asking you whether to open a
result file.

Analysis reports of various themes

None
3.5 Action 4: Report Interpretation

The optimization result report contains four parts, summary, top cell info analysis results, sudden
dropping throughput and low road level analysis results, and summary of various root causes details.
The report supports two analysis policies: top N cell optimization and top N road optimization. The
following figure shows the procedure using the two analysis policies.

3.5.1 Description of the Summary Sheet

The sheet Summary provides statistics of overall situation and problem distribution for a DT area. The
sheet contains three parts.
The first part provides statistics of the RF Measurement in the DT area, Modulation Scheme,
Throughput, Schedule Information, MIMO Mode Percentage, Rank Percentage, and BLER &
Power. The table lists the average values of these counters.
Figure 3.1 Example of the first part
The second part provides statistics of the throughput distribution of all the DT points, including The
Range, Sample Num, CDF, and PDF. The CDF and PDF curves can be drawn based on the statistics.

Figure 3.2 Example of the second part
The third part provides statistics of network problems and the number of various problem points. All the
parts in blue indicate the problems that occurred in the network. These parts can be linked to the
corresponding sheet for users to check detailed information. All the parts in black indicate that the
problem does not occur in the network. No sheet with detailed information is linked to the black parts.
Figure 3.3 Example of the third part
3.5.2 Sheet Top cell Info

The sheet Top cell Info provides statistics of various key counters for each top cell. The different
counter requirements can help engineers filter out cells with high priority for optimization.
For example, sort the cells based on Cell Average THP. Then select and optimize the cell with low
throughput and multiple problems (such as the red boxes in the following figure) based on the top cell
entry policy.

 Num of DT point: indicates the total number of the DT points in the cell.
 Num of Problem DT point: indicates the number of problem road points of the cell (the
throughput is lower than the threshold).
 Low Point Ratio: indicates the proportion of problem DT points, such as Num of Problem DT
point/Num of DT point.
 Cell Average THP, Average RSRP, Average SINR, DL Grant, PDSCH RB Num, AVG MCS
DL, and TM3 RANK2 ratio: indicate the average values for counters of all the DT points in the
cell.
 Proportion of Problem: indicates the root causes for the cell and provides statistics of each root
cause proportion.
 Optimization Suggestion: provide optimization suggestions based on the problem root causes. If a
cell problem is caused by several factors, multiple suggestions will be provided using emails. Then
engineers need to choose proper optimization suggestions based on their experience.
3.5.3 Road-level Analysis Sheet for Sudden Dropping Throughput and Low
Throughput
Description for the Sudden Dropping Throughput Analysis Sheet

The sheet shows all sudden dropping points and counters before and after the sudden dropping and
provides the problem causes and troubleshooting methods.
 Index: indicates the sudden dropping point number. The DT points with a same number are
associated with the sudden dropping points which are displayed in red. The DT points with the
same SN are provided in time sequence.
 Problem Analysis: indicates possible causes for the sudden dropping throughput and
troubleshooting methods. For detailed principles, see section 2.4.4"Locating the Root Cause for
Sudden Dropping Throughput."

Road-level Analysis Result Sheet for Low Throughput

Sheet Road-level Analysis Result Sheet for Low Throughput shows the various counters of problem
roads with unfulfilled rates and possible causes affecting the rate, and each cause proportion, as shown
in the following figure. If multiple problems exist on a road, the problems are sorted by SN.
Select top problem roads based on the number of the problem points or the road average throughput
provided by the sheet Road-level Analysis Result Sheet for Low Throughput. Then perform the
optimization according to the policies in Top N Road Optimization.
 Num of Problem DT point: indicates the number of collection points with consecutive low rates on
problem roads.
 Average THR of cell: indicates the average throughput value of collection points with low rates on
problem roads.
 Proportion of Problem: indicates problems and the proportion of each type problem on the road.
Other problem indicates that the tool cannot identify the causes based on the DT data. The possible
cause may involve the CN and UE factors. Engineers are required to analyze the causes by
combining other data sources.
 Detailed information: indicates the detailed causes for the road. Click the characters in blue to link
to the column in the corresponding sheet. If major problems of the road are abnormal events or
handovers, click the sheets Abnormal Event and Handover to identify the major problems.
 Optimization Suggestion: provide optimization suggestions for major root causes of the road. For
optimization suggestions for various problems, see section 2.6"Providing Optimization
Suggestions."
3.5.4 Interpretation of the Coverage Problem Sheet
Introduction
Coverage problem analysis covers missing neighboring cell relationship, overlap coverage, no primary
serving cell, weak coverage, and restricted uplink.
The root cause for each problem is displayed in a separate sheet. The key information for each root
cause is displayed in the sheet. If a problem does not occur on the network, no sheet is provided for the
problem.

Description of output enhancement for SFN scenarios: In SFN scenarios, apart from output in common
scenarios, the values for SFN Group of the cell, and eNodeBId, LocalCellId, and SectorEqmid of the
RRU are also provided. If the cell in SFN scenarios is in the normal state, SectorEqmid is displayed as
an en dash (-); if it is an SFN cell, the level value of the RRU under the SFN cell will also be provided.
This part provides coverage problem points that affect only the low throughput. If only coverage optimization is
required, see the table Coverage and Interference Analysis Results that is provided with the table Throughput
Optimization Analysis Results. The two tables show the road level analysis results of all coverage and interference
problems. For detailed descriptions, see section 5.6 "Action 4 Report Interpretation-LTE" in NOKT V1R1 Technical
Guide to UL DT Data-based Accurate Network Optimization.
Weak Coverage
The sheet Weak Coverage provides the information about all weak coverage points that leads
unfulfilled throughput. The following figure shows an example of Weak Coverage sheet which
provides detailed information about weak coverage judgment.
Figure 1.1 Output example of weak coverage in normal scenarios
Figure 1.2 Output example of weak coverage in SFN scenarios
In this sheet, one row indicates one weak coverage DT point. The DT points with the same number are
on the same throughput problem road.
 PDCP Throughput DL(Kbit/s), RSRP, and SINR: indicate the throughput, RSRP, and SINR in
the serving cell.
 Detected PCI: indicates the PCI of a neighboring cell (one or multiple neighboring cells may
exist). The same fields in other sheets have the same meaning and will not be described later.
 Detected Cell RSRP(dBm): indicates the neighboring cell RSRP. The more neighboring cells
exist, the more RSRP values are provided. The same fields in other sheets have the same meaning
and will not be described later.
 Is Ratonalisty: indicates whether the DT point serving cell is properly planned. For judgment
criteria, see section 2.4.3"Analyzing Coverage." The same fields in other sheet have the same
meaning and will not be described later.

 SFN Group: indicates the group ID of an SFN cell. If the fields of different RRUs are same, the
RRUs are under the same SFN cell.
 RRU Power: indicates the RSRP of the serving RRU for this DT point.
Missing Neighboring Cell Relationship

The following figure shows an example of Missing Neighboring Cell Relationship sheet.
Figure 1.1 Output example of missing neighboring cell relationship in normal scenarios
Figure 1.2 Output example of missing neighboring cell relationship in SFN scenarios
In this sheet, one row indicates one DT point that meets the condition of missing neighboring cell
relationship. The DT points with the same number are on the same throughput problem road.
Intra-frequency missing cell relationship PCI, intra-frequency missing cell relationship name, inter-
frequency missing cell relationship PCI, and inter-frequency missing cell relationship name refers to the
missing cells.
Overlap Coverage
The following figure shows an example of Overlap Coverage sheet.
Figure 1.1 Output example of overlap coverage in normal scenarios
Figure 1.2 Output example of overlap coverage in SFN scenarios
In this sheet, one row indicates one DT point that meets the condition of overlap coverage. The DT
points with the same number are on the same throughput problem road.

1. Overlap coverage may be incorrectly identified due to engineering parameter errors:

If the latitude and longitude in engineering parameters are incorrect, the calculated distance from a collection
point to a serving cell is large.
2. Apart from the event of super-distance coverage for ultra high sites, if the following condition is meet, the
overlap coverage may be incorrectly identified due to engineering parameter errors: Distance from the
collection point (m)/Average inter-site distance ≥ 5.
No Primary Serving Cell

The following figure shows an example of No Primary Serving Cell sheet.
Figure 1.1 Output example of no primary serving cell in normal scenarios
Figure 1.2 Output example of no primary serving cell in SFN scenarios
In this sheet, one row indicates one DT point that meets the condition of no primary serving cell. The
DT points with the same number are on the same throughput problem road.
Restricted Uplink
The following figure shows an example of Restricted Uplink sheet.
Figure 1.1 Output example of restricted uplink in normal scenarios
Figure 1.2 Output example of restricted uplink in SFN scenarios

In this sheet, one row indicates one DT point that meets the condition of restricted uplink. The DT
points with the same number are on the same throughput problem road.
Type: indicates that the restricted uplink is caused by the downlink overshoot coverage, uplink
interference (only the PUCCH path loss is considered, and the uplink interference needs to be
determined using interference theme), and other problems.
Only the PUCCH path loss is considered to determine uplink interference. If the downlink overshoot coverage does
not exist (the output table indicates whether the overshoot coverage exists in the serving cell), engineers need to
analyze whether the problem is caused by the uplink interference. If the downlink overshoot coverage (or overlap)
exists, adjust the downtilt or power of the serving cell to narrow the coverage area so that a proper neighboring cell
is used as the primary serving cell to cover the road.
Inappropriate Handover Parameters

The following figure shows an example of Inappropriate Handover Parameters sheet.
Figure 1.1 Output example of inappropriate handover parameters
In this sheet, one row indicates one DT point that meets the requirement of inappropriate handover
parameters. The DT points with the same number are on the same throughput problem road. The output
is the same in normal scenarios and SFN scenarios.
3.5.5 Interpretation of the Downlink Interference Problem Detail Report
Introduction
The downlink interference includes the overshoot interference, PCI Mod 3 conflict, overlapping
coverage, and other interferences.
The interference problem road information contains the information about SINR and RSRP of DT
points and neighboring cells.
Description of output enhancement for SFN scenarios:
1. If the serving cell is an SFN cell, eNodeBId, LocalCellId, and SectorEqmid of the RRU are
provided. If the serving cell is a normal cell, SectorEqmid is displayed as an en dash (-).
2. If the interference cell is an SFN cell, eNodeBId, LocalCellId, and SectorEqmid that affect the
RRU are also provided.
Overshoot Interference of Neighboring Cells

In this sheet, one row indicates one DT point that meets the condition of overshoot interference of
neighboring cells. The DT points with the same number are on the same throughput problem road. One
road probably has multiple serving cells and the road information contains the information about all

overlapped neighboring cells. The information contains the RSRP and the distance between overlapped
neighboring cells and DT points.
Figure 1.1 Output example of overshoot interference of neighboring cells in normal scenarios
Figure 1.2 Output example of overshoot interference of neighboring cells in SFN scenarios
PCI Mod 3 Conflict

In this sheet, one row indicates one DT point that meets the condition of PCI Mod 3 conflict. The DT
points with the same number are on the same throughput problem road. One road probably has multiple
serving cells and the road information contains the information about all neighboring cells with conflict.
The information contains the PCI and RSRP.
For Mod 3 conflicts, the serving cell is the interfered cells and the neighboring cell is the interference
source. You are advised to adjust the antenna or power of neighboring cells or to optimize the PCI.
For PCI optimization, please following the OMSTR V5R12 PCI optimization topic:
http://3ms.huawei.com/hi/group/2028955/file_8846999.html?for_statistic_from=my_group_file
Overlapping Coverage
The following figure shows an example of Overlapping Coverage sheet. In this sheet, one row indicates
one DT point that meets the condition of overlapping coverage. The DT points with the same number
are on the same throughput problem road. One road probably has multiple serving cells and the road
information contains the information about all neighboring cells with overlapping coverage. The
information contains the PCI and RSRP.

Figure 1.1 Output example of overlapping coverage in normal scenarios
Figure 1.2 Output example of overlapping coverage in SFN scenarios
Method: Adjust the antenna downtilt in overlapping cells to reduce the overlapping coverage area. RF
optimization engineers need to determine which downtilt to be adjusted to resolve the overlapping
coverage problem based on GIS and experience.
Other Interferences
The following figure shows an example of Other Interferences sheet. In this sheet, one row indicates
one DT point that meets the condition of other interferences but does not fulfill the requirement of
overshoot interference, overlapping coverage, and PCI Mod 3 conflicts. The DT points with the same
number are on the same throughput problem road. One road probably has multiple serving cells and the
road information contains the information about all neighboring cells. The information contains the PCI
and RSRP.
Figure 1.1 Output example of other interferences in normal scenarios
Figure 1.2 Output example of other interferences in SFN scenarios

3.5.6 Interpretation of the Handover Problem Detail Report
Introduction
The handover analysis report contains two parts: frequent handover and handover timeout, as shown in
two sheets.
Frequent Handover
The following figure shows an example of Frequent Handover sheet.
The sheet provides frequent handover roads that influence throughput, the start and end time, start and
end latitudes and longitudes of cells with frequent handovers, the information about the involved
serving cells, times that frequent handovers occur within ten seconds (the value must be same with the
parameter values configured in the window), and whether ping-pong handovers occur in the frequent
handover process. If ping-pong handovers occur, cell pairs related to ping-pong handovers are provided.
For a road where frequent handovers occur, sheet provides the information to indicate whether the road
has a primary serving cell. If the road has a primary serving cell, check whether the settings of
parameters handover CIO and timeout are correct.
Handover Timeout
The following figure shows an example of Handover Timeout sheet.

If a handover is timed out and the timeout causes the level of the primary serving cell to be less than the
weak coverage threshold, the handover is defined as handover timeout. The following four adjustment
suggestions are provided to process handover timeout.
Enhance the coverage to resolve the weak coverage problem indicates that the coverage of neighboring
cells is poor when handover timeout occurs. Therefore, the handover is not performed in a timely
manner because of the weak coverage of neighboring cells. As a result, resolve the coverage problem of
the neighboring cell in the handover zone.
Missing neighboring cell relationship indicates that the missing neighboring cells of a site or different
sites must be added based on the information about the missing neighboring cells.
Adjust PCI confusion indicates that the neighboring cell of PCI confusion in the neighboring cell
configuration for the primary serving cell must be modified based on the provided PCI confusion
information. The confusion of the neighboring cell configuration results in the failure to issue handover
commands when the handover occurs in the target cell.
If the preceding three problems do not occur, this sheet provides the adjustment suggestion
Inappropriate handover parameters. Check whether the handover zone is properly planned and whether
the handover parameter configurations are correct.
3.5.7 Interpretation of the Abnormal Event Details
Introduction
The abnormal events are as follows: data transmission completion, task completion, task exception,
access failure, call drop, handover failure, inter-RAT handover success/failure (used in the P3 scenario
of UMTS and LTE hybrid networking), RRC re-establishment failure, and idle mode. A single sheet is
provided for each abnormal event.
The CDRs with abnormal throughput or abnormal P3 KQIs can be associated with the abnormal event
for analysis. The abnormal event module can also be used for separate analysis. Relevant causes and
adjustment suggestions are provided for some abnormal events.
Task Exception
The following figure shows an example of Task Exception sheet.
When a task exception occurs, other analysis themes are associated to analyze the possible cause. In the
optimization suggestion, the sequence number of the detailed problem road is provided. For example, if
the exception is caused by weak coverage, the optimization suggestion is See the corresponding
optimization suggestion in weak coverage (+ Number) analysis.
Access Failure
The following figure shows an example of Access Failure sheet.

Access failures are classified into RRC access failures and E-RAB access failures. When an access
failure occurs, the causes for each problem point that exists on the road with abnormal throughput are
analyzed. In addition, each cause and its proportion are provided in column Proportion of Problem. (The
analysis of abnormal events only covers coverage and interference problems.) Different causes are
sorted in ascending number. Detailed information can be linked to the corresponding sheet Detailed
Problem for you to query information.
E-RAB Abnormal Release

The following figure shows an example of E-RAB Abnormal Release sheet.
The cause ratio, details, and other information about E-RAB abnormal release are similar to those of the
access failure. Therefore, they are not described here.
The following fields contain values only when the CHR data is entered: Internal Release Cause Value,
UE Context Protocol Release Cause, UE Context Release Trigger Source, Uplink RSRP, and
Uplink SINR. For details, see sections about the CHR correlation analysis for abnormal events.
Handover Failure
The following figure shows an example of Handover Failure sheet.
The field information about this sheet is similar to that of E-RAB Abnormal Release sheet. Therefore, it
is not described here.
The fields in red in the preceding figure provide relevant analysis results only when the CHR data is
entered. For details, see section about CHR correlation analysis.
RRC Re-establishment Failure

The following figure shows an example of RRC Re-establishment Failure sheet.

The field information about this sheet is similar to that of Access Failure sheet. Therefore, it is not
described here.
3.5.8 Interpretation of the Resource Capacity Check Report

The sheet Capacity in the report provides the results of resource capacity check.
The following figure shows an example of Resource Capacity Check sheet.
If any service becomes abnormal on a DT road and a resource capacity counter is abnormal in the
problem cell, the sheet Capacity provides the cell and counter information. The abnormal counter is
displayed in red. For the resource capacity-related problems, clarify and explain the problem to
operators and delete the relevant road or expand capacity to resolve the problem.
The sheet Road-level Summary for consistent low throughput displays the capacity problem. Click the
hyper link in column Detailed Information to link to the corresponding sequence number of the sheet
Capacity.

3.5.9 Interpretation of the Parameter Check Report

The sheet Parameter in the report provides the results of parameter check.
The following figure shows an example of Parameter Check sheet.
This sheet checks the baseline parameters that affect data service rates and delay on problem roads
evaluated in the service summary module. If any parameter is inconsistent with that in the baseline, the
relevant parameter information, current value, baseline, and impact of the parameter are provided. You
are advised to set the parameter to be consistent with the baseline.
Each cell has multiple sequence numbers in the parameter check results and most parameters are set to the same
values on the entire network. If any parameter is inconsistent with the baseline, all cells of the problem road are
provided. Therefore, the parameter check results are not correlated with causes of problem roads in the Problem
Roads of Throughput Summary and are provided only for reference. Later versions can be further improved based
on the experience and cases.
3.5.10 Interpretation of the Alarm Check Report

The Alarm sheet in the alarm report shows alarm check results.
The alarm check theme checks the alarms of service KQIs that may affect throughput, checks the alarms
for the cells or sites on roads with service exceptions, and provides the results and the causes for roads
with service exceptions, as shown in the following figure.
The following figure shows an example of Alarm Check sheet.
The results contain the alarm names, alarm impacts, and alarm clearing suggestions.

3.5.11 Interpretation of the CHR Correlated Analysis Report

This section describes the correlated analysis on CHRs of a single UE in a DT and the network for call
drops, handover failures, inter-RAT handover failures. The correlated analysis aims to quickly identify
the root causes for the abnormal CHRs of UEs in a DT based on a large number of CHRs.
Application scenario:
The CHR correlated analysis is used if CHRs are required to facilitate the analysis of various problems
when abnormal events cannot be identified during routine DTs.
Application suggestions:
The CHR data amount is large, and therefore you are advised to import the data of all sites where
abnormal events occur after 10 to 20 minutes.
Filter method:
The CHR file is named by time. In normal cases, a CHR file is generated by 5 minutes, as shown in the
following figure. You can view all the files generated within a specified period of time by searching for
the file names in the search bar in the Windows OS.
If an abnormal event occurs on a site at 16:25, you can search for all the files 20141126_1620,
20141126_1625, and 20141126_1630 in the CHR data directory to obtain the CHR data within 10
minutes, and then import the data into the tool.
Call Drop
The following figure shows an example of Call Drop sheet.
The report contains the CHR information about the uplink signal, quality, and context release causes for
call drops. In the preceding figure, call drops are caused by synchronization failures in the uplink. This
cause cannot be identified only using DT data.
The internal cause release values can be generated if PRIVATE_INNER_REL_EVENT is subscribed to. This event
may fail to be subscribed to using some NIC versions on the live network because a bug is being modified. In this
case, use the Nastar to subscribe to the event.

Handover Failure
The following figure shows an example of Handover Failure sheet.
In the red area in the preceding figure, the CHRs during handover failures indicate the resources
prepared for the target cell where handover failures occur, the handovers canceled between the source
cell and target cell, and the causes for cancellation.
The first failure is handover cancellation. The reason is that the target cell cannot be accessed and weak
coverage occurs in this cell based on the analysis results of air interface data in DT data. Therefore, the
cell with weak coverage must be handled preferentially.
3.5.12 Radio Propagation Model Calibration (Applies Only to SFN

Scenarios)
For radio propagation model calibration methods, see the U-Net guide.
3.5.13 Suggestions for RF Optimization When the ACP Is Used

Detailed optimization suggestions must be provided using the ACP for problem cells that require
adjustment of antenna parameters and power. The procedure is as follows:
Step 1 Determine the problem cell list based on the optimization report provided by the OMStar, as shown in
the following figure. The sheet Top cell Info provides causes and optimization suggestions for all
problem cells. Select the cells with coverage and interference problems as the problem cells to be
optimized.
Step 2 Determine optimization areas based on problem cells.

For cells with coverage problems (weak coverage, restricted uplink, overlap coverage, and no primary
serving cell), the optimization areas are as follows:
− Problem serving cells
− First-layer neighboring cells of problem serving cells
For cells with interference problems (overlapping coverage and overshoot interference), the
optimization areas are as follows:
− Problem serving cells
− Interference cells of serving cells
− First-layer neighboring cells of serving cells and interference cells
Step 3 Draw polygons for optimization areas identified in Step 2 on the U-Net as ACP optimization areas.
Step 4 Create an ACP project to set parameters and provide optimization results.
----End
For details about ACP operations, see the ACP guide.
3.6 Action 5: Optimization Suggestion Implementation

3.6.1 Overview
Implement the optimization suggestions for the problem cells using the network management platform
or by engineers.
3.6.2 Tool
M2000 and WebLMT
3.6.3 Input
Optimization suggestions
3.6.4 Process
Issue the optimization suggestions.
3.6.5 Output
Implementation results of optimization suggestions

None

4 Reference Document
4.1 LTE DT Data Source Export Template
LTE DT Data
Source Export Template.rar

Technical Guide To LTE Throughput DT Data-Based Accurate Network Optimization

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Technical Guide To LTE Throughput DT Data-Based Accurate Network Optimization

Hochgeladen von

Copyright:

Verfügbare Formate

NPI V200R007 Technical Guide to LTE Throughput DT Data-based Accurate Security Level:

Network Optimization INTERNAL

Product Name Security Level

Product Version Total 66 pages

NPI V200R007 Technical Guide to LTE

Prepared By Yang Jing (employee ID: 00184099) Date 2015-07-01

Huawei Technologies Co., Ltd.

2019-8-22 Huawei confidential. No spreading without permission. Page 1 of 62

Data Issue Change Description Author

2014-12-22 V1.00 Completed the draft. Chen Qinlong (employee ID:

2019-8-22 Huawei confidential. No spreading without permission. Page 2 of 62

2019-8-22 Huawei confidential. No spreading without permission. Page 3 of 62

Coverage Mandatory N/A Mandatory N/A N/A N/A

Parameter Mandatory Mandatory Mandatory N/A N/A N/A

2019-8-22 Huawei confidential. No spreading without permission. Page 4 of 62

1.3.2 Constraints on Application Scenarios

2019-8-22 Huawei confidential. No spreading without permission. Page 5 of 62

Scenario Constraints Preventive Measure

RAT Theme Submodule Maturity

2019-8-22 Huawei confidential. No spreading without permission. Page 6 of 62

RAT Theme Submodule Maturity

Interference Overshoot coverage Rectify engineering parameter problems and

Abnormal Abnormal event 1. The abnormal event analysis is correlated with

2019-8-22 Huawei confidential. No spreading without permission. Page 7 of 62

Optimization Suggestion Maturity

2019-8-22 Huawei confidential. No spreading without permission. Page 8 of 62

2.2 Filtering Top Cells

2019-8-22 Huawei confidential. No spreading without permission. Page 9 of 62

2.3 Evaluating Problem Roads

2019-8-22 Huawei confidential. No spreading without permission. Page 10 of 62

2.4.1 Checking Alarm

2.4.2 Checking Parameters

2019-8-22 Huawei confidential. No spreading without permission. Page 11 of 62

2.4.3 Analyzing Coverage

2.4.4 Locating the Root Cause for Sudden Dropping Throughput

2019-8-22 Huawei confidential. No spreading without permission. Page 12 of 62

2.4.5 Demarcating Low Throughput and Locating the Root Cause

Air Interface Analysis

2019-8-22 Huawei confidential. No spreading without permission. Page 13 of 62

2019-8-22 Huawei confidential. No spreading without permission. Page 14 of 62

2019-8-22 Huawei confidential. No spreading without permission. Page 15 of 62

Abnormal Event Analysis

2019-8-22 Huawei confidential. No spreading without permission. Page 16 of 62

Major Root Cause Locating for Problem Roads

2019-8-22 Huawei confidential. No spreading without permission. Page 17 of 62

2.5 Locating Causes for Top Cells

2019-8-22 Huawei confidential. No spreading without permission. Page 18 of 62

2.6 Providing Optimization Suggestions

2019-8-22 Huawei confidential. No spreading without permission. Page 19 of 62

generation Use the OMStar to perform theme analysis.

3.2 Action 1: Data Collection

2019-8-22 Huawei confidential. No spreading without permission. Page 20 of 62

eNodeBName Indicates the name of an eNodeB. Mandatory

2019-8-22 Huawei confidential. No spreading without permission. Page 21 of 62

3. Traffic statistics collection (optional)

Alarm Log Check

5. CHR data collection (optional)

2019-8-22 Huawei confidential. No spreading without permission. Page 22 of 62

2019-8-22 Huawei confidential. No spreading without permission. Page 23 of 62

2019-8-22 Huawei confidential. No spreading without permission. Page 24 of 62

2019-8-22 Huawei confidential. No spreading without permission. Page 25 of 62

2019-8-22 Huawei confidential. No spreading without permission. Page 26 of 62

3.3 Action 2: Tool Preparation