Professional Documents
Culture Documents
Draft A
Date
2016-03-07
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Website:
http://www.huawei.com
Email:
support@huawei.com
eRAN11.1
eRAN Troubleshooting Guide
Sudden faults
Product Versions
The following table lists the product versions related to this document.
Product Name
Solution Version
Product Version
BTS3900
l SRAN11.1
V100R011C10
BTS3900A
l eRAN11.1
BTS3900L
BTS3900AL
BTS3202E
BTS3911E
DBS3900
l SRAN11.1
DBS3900 LampSite
l eRAN11.1
l eRAN TDD 11.1
Intended Audience
This document is intended for:
l
System engineers
ii
eRAN11.1
eRAN Troubleshooting Guide
Organization
1 Change Description
This chapter describes the changes in eRAN Troubleshooting Guide.
2 Troubleshooting Process
This chapter describes the general troubleshooting process and methods.
3 Common Maintenance Functions
This chapter describes common maintenance functions that are used to analyze and handle
faults. It also explains or provides references on how to use the functions.
4 Troubleshooting Access Faults
This chapter describes how to diagnose and handle access faults.
5 Troubleshooting Intra-RAT Handover Faults
This chapter describes how to diagnose and handle intra-RAT handover faults. RAT is short
for radio access technology.
6 Troubleshooting Service Drops
This chapter describes the method and procedure for troubleshooting service drops in the
Long Term Evolution (LTE) system. It also provides the definitions of service drops and
related key performance indicator (KPI) formulas.
7 Troubleshooting Inter-RAT Handover Faults
This section defines inter-RAT handover faults, describes handover principles, and provides
the fault handling method and procedure.
8 Troubleshooting Rate Faults
This chapter provides definitions of faults related to traffic rates and describes how to
troubleshoot low uplink/downlink UDP/TCP rates and rate fluctuations. UDP is short for User
Datagram Protocol, and TCP is short for Transmission Control Protocol.
9 Troubleshooting Cell Unavailability Faults
This chapter defines cell unavailability faults and provides a troubleshooting method.
10 Troubleshooting IP Transmission Faults
This section defines IP transmission faults and describes how to troubleshoot IP transmission
faults.
11 Troubleshooting Application Layer Faults
This chapter describes the definitions of application layer faults and the troubleshooting
method.
12 Troubleshooting Transmission Synchronization Faults
Issue Draft A (2016-03-07)
iii
eRAN11.1
eRAN Troubleshooting Guide
This chapter describes how to troubleshoot transmission synchronization faults. The faults of
this type include the clock reference problem, IP clock link fault, system clock unlocked fault,
base station synchronization frame number error, or time synchronization failure.
13 Troubleshooting Transmission Security Faults
This chapter describes how to troubleshoot transmission security faults.
14 Troubleshooting RF Unit Faults
This chapter describes the method and procedure for troubleshooting radio frequency (RF)
unit faults in the Long Term Evolution (LTE) system.
15 Troubleshooting License Faults
This chapter describes how to diagnose and handle license faults.
16 Wireless Fault Management
Generally, when a radio performance fault or network-level performance fault occurs, OM
engineers cannot quickly delimit the fault range and recover the service by resetting,
powering off, or replacing corresponding boards. To address this issue, the FMA provides a
radio performance fault analysis function, helping OM engineers quickly find the method of
recovering services. Using this function, the troubleshooting efficiency is improved.
17 Collecting the Information Required for Fault Location
When faults cannot be rectified by referring to this document, collect fault information for
Huawei technical support to quickly troubleshoot the faults. This section describes how to
collect fault information.
Conventions
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol
Description
Indicates an imminently hazardous situation which, if not
avoided, will result in death or serious injury.
Indicates a potentially hazardous situation which, if not
avoided, could result in death or serious injury.
Indicates a potentially hazardous situation which, if not
avoided, may result in minor or moderate injury.
Indicates a potentially hazardous situation which, if not
avoided, could result in equipment damage, data loss,
performance deterioration, or unanticipated results.
NOTICE is used to address practices not related to personal
injury.
iv
eRAN11.1
eRAN Troubleshooting Guide
Symbol
Description
Calls attention to important information, best practices and
tips.
NOTE is used to address information not related to
personal injury, equipment damage, and environment
deterioration.
General Conventions
The general conventions that may be found in this document are defined as follows.
Convention
Description
Boldface
Italic
Courier New
Command Conventions
The command conventions that may be found in this document are defined as follows.
Convention
Description
Boldface
Italic
[]
{ x | y | ... }
[ x | y | ... ]
{ x | y | ... }*
[ x | y | ... ]*
GUI Conventions
Issue Draft A (2016-03-07)
eRAN11.1
eRAN Troubleshooting Guide
The GUI conventions that may be found in this document are defined as follows.
Convention
Description
Boldface
>
Keyboard Operations
The keyboard operations that may be found in this document are defined as follows.
Format
Description
Key
Press the key. For example, press Enter and press Tab.
Key 1+Key 2
Key 1, Key 2
Mouse Operations
The mouse operations that may be found in this document are defined as follows.
Action
Description
Click
Double-click
Drag
Press and hold the primary mouse button and move the
pointer to a certain position.
vi
eRAN11.1
eRAN Troubleshooting Guide
Contents
Contents
About This Document.....................................................................................................................ii
1 Change Description.......................................................................................................................1
2 Troubleshooting Process.............................................................................................................. 2
2.1 General Troubleshooting Process................................................................................................................................... 3
2.2 Troubleshooting Methods............................................................................................................................................... 4
2.2.1 Data Backup................................................................................................................................................................ 4
2.2.2 Fault Information Collection....................................................................................................................................... 4
2.2.3 Determining the Fault Scope and Type....................................................................................................................... 6
2.2.4 Identifying Fault Causes.............................................................................................................................................. 8
2.2.5 Rectifying the Fault..................................................................................................................................................... 8
2.2.6 Checking Whether Faults Have Been Rectified.......................................................................................................... 8
2.2.7 Contacting Huawei Technical Support........................................................................................................................ 9
vii
eRAN11.1
eRAN Troubleshooting Guide
Contents
viii
eRAN11.1
eRAN Troubleshooting Guide
Contents
ix
eRAN11.1
eRAN Troubleshooting Guide
Contents
eRAN11.1
eRAN Troubleshooting Guide
1 Change Description
Change Description
Draft A (2016-03-7)
This is a draft.
Compared with 01 (2015-12-31) of V100R010C10, this issue includes the following new
information.
Topic
Change History
Compared with 01 (2015-12-31) of V100R010C10, this issue includes the following changes.
Topic
Change History
eRAN11.1
eRAN Troubleshooting Guide
2 Troubleshooting Process
Troubleshooting Process
eRAN11.1
eRAN Troubleshooting Guide
2 Troubleshooting Process
Step
Remarks
eRAN11.1
eRAN Troubleshooting Guide
2 Troubleshooting Process
No.
Step
Remarks
2.2.2 Fault
Information Collection
2.2.6 Checking
Whether Faults Have
Been Rectified
2.2.7 Contacting
Huawei Technical
Support
Fault symptom
Operations performed on the equipment before the fault occurs, and the results of these
operations
eRAN11.1
eRAN Troubleshooting Guide
2 Troubleshooting Process
Consult the person who reports the fault about the symptom, time, location, and
frequency of the fault.
Consult maintenance personnel about the equipment running status, fault symptom,
operations performed before the fault occurs, and measures taken after the fault occurs
and the effect of these measures.
Observe the board indicator, operation and maintenance (OM) system, and alarm
management system to obtain the software and hardware running status.
Estimate the scope and impact of the fault by means of service demonstration,
performance measurement, and interface or signaling tracing.
Do not handle a fault hastily. Collect as much information as possible before rectifying
the fault.
Keep good liaison with maintenance personnel of other sites. Resort to them for
technical support if necessary.
Attrib
ute
Description
Original
information
Definiti
on
Functio
n
Referen
ce
None
eRAN11.1
eRAN Troubleshooting Guide
2 Troubleshooting Process
Type
Attrib
ute
Description
Alarm
information
Definiti
on
Functio
n
Referen
ce
For details about how to use the alarm system, see U2000 Online
Help. For detailed information about each alarm, see eNodeB
Alarm Reference.
Definiti
on
Functio
n
Referen
ce
Definiti
on
Functio
n
Referen
ce
Indicator
status
Performance
counter
eRAN11.1
eRAN Troubleshooting Guide
2 Troubleshooting Process
Service Faults
Service faults are further classified into the following types:
l
Access faults
Handover faults
Rate faults
Equipment Faults
Equipment faults are further classified into the following types:
l
Cell faults
IP transport is abnormal.
Clock faults
Security faults
eRAN11.1
eRAN Troubleshooting Guide
2 Troubleshooting Process
The antenna line device (ALD) link does not work properly.
License faults
Access faults: Check the S1 interface and Uu interface. Locate transmission faults
segment by segment. Then, determine whether faults occur in the eRAN based on the
interface conditions. If so, proceed to locate specific faults.
Rate faults: Check whether there are access faults. If there are access faults, locate
specific faults by using the previous methods. Then, check the traffic on the IP path to
determine fault points.
Handover faults: Start signaling tracing and determine fault points according to the
signaling flow.
For instructions on fault locating and analysis, see 3 Common Maintenance Functions.
eRAN11.1
eRAN Troubleshooting Guide
2 Troubleshooting Process
Severity of the fault and the time required for rectifying the fault
One-click logs of the main control board (Applicable to 3900 series base stations only)
One-click logs of baseband boards (Applicable to 3900 series base stations only)
Alarm information
For details about how to collect fault information, see 3900 Series Base Station LMT User
Guide, eNodeB Performance Monitoring Reference, eRAN Routine Maintenance Guide, and
U2000 Online Help.
eRAN11.1
eRAN Troubleshooting Guide
2 Troubleshooting Process
Email: support@huawei.com
Website: http://support.huawei.com
10
eRAN11.1
eRAN Troubleshooting Guide
11
eRAN11.1
eRAN Troubleshooting Guide
Real-time
Applicable in various scenarios, for example, call procedure analysis and VIP user
tracing
User tracing is usually used to diagnose call faults that can be reproduced. For details about
how to perform user tracing, see the online help for the operation and maintenance system.
Real-time
Interface tracing applies in scenarios where user equipment (UEs) involved are uncertain. For
example, this function can be used to diagnose the cause for a low success rate of radio
resource control (RRC) connection setup at a site. For details about how to perform interface
tracing, see the online help for the operation and maintenance system.
3.3 Comparison/Interchange
Comparison and interchange are used to locate faults in a piece or pieces of equipment.
Comparison is a function used to locate a fault by comparing the faulty component or fault
symptom with a functional component or normal condition, respectively. Interchange is a
function used to locate a fault by interchanging a possibly faulty component with a functional
component and comparing the running status before and after the interchange.
Comparison usually applies in scenarios with a single fault. Interchange usually applies in
scenarios with complicated faults.
3.4 Switchover/Reset
Switchover helps identify whether the originally active equipment is faulty or whether the
active/standby relationship is normal. Reset is used to identify whether software running
errors exist.
Issue Draft A (2016-03-07)
12
eRAN11.1
eRAN Troubleshooting Guide
Switchover switching of the active and standby roles of equipment so that the standby
equipment takes over services. Comparing the running status before and after the switchover
helps identify whether the originally active equipment is faulty or whether the active/standby
relationship is normal. Reset is a means to manually restart part of or the entire equipment. It
is used to identify whether software running errors exist.
Switchover and reset can only be emergency resorts. Exercise caution when using them,
because:
l
Compared with other functions, switchover and reset can only be auxiliary means for
fault locating.
Because software runs randomly, a fault is usually not reproduced in a short period after
a switchover or reset. This hides the fault, which causes risks in secure and stable
running of the equipment.
Resets might interrupt services. Improper operations may even cause collapse. The
interruption and collapse have a severe impact on the operation of the system.
3.5.1 Overview
If the OM channel of one mode in a separate-MPT MBTS fails, the available OM channels of
other modes can be used for remote troubleshooting on the LMT for the base station whose
OM channel is faulty. In this way, unnecessary site visit is avoided and fault location becomes
efficient and cost-effective.
Function Introduction
An emergency OM channel can be established between a GBTS and an eGBTS/NodeB/
eNodeB, or among the eGBTS, NodeB, and eNodeB, as shown in Figure 3-1 and Figure 3-2.
A GBTS can only serve as the proxy base station instead of the target base station. A base
station whose OM channel is normal can serve as the proxy base station; while a base station
whose OM channel is faulty is the target base station.
Figure 3-1 Emergency OM channel between a GBTS and an eGBTS/NodeB/eNodeB
13
eRAN11.1
eRAN Troubleshooting Guide
With an emergency OM channel, the Proxy MML and Proxy PNP Trace functions can be used
on the proxy base station. For details about the functions, see 3.5.4 Function Description.
The proxy base station and the target base station support different transport protocol
stacks. Table 3-1 shows the transport protocol stacks supported by the proxy base station
and the target base station.
Table 3-1 Transport protocol stacks supported by the proxy and target base stations
Transport Protocol
Stack
Is Supported by Proxy
Base Station?
Is Supported by Target
Base Station?
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Either separate transmission or co-transmission can be used by the proxy and target base
stations. In the co-transmission scenario, both panel and backplane interconnections can
be used.
The proxy and target base stations can be configured with either one or multiple BBUs.
At present, a maximum of two BBUs are supported.
Table 3-2 describes the MPT types and modes of the proxy and target base stations,
which can be combined to support the emergency OM channel establishment.
14
eRAN11.1
eRAN Troubleshooting Guide
Table 3-2 Combination of MPT types and modes of the proxy and target base stations
MPT Type and Mode of Proxy Base
Station
GTMU
l WMPT
l LMPT
l UMPT_U
l UMPT_L
l UMPT_UL
l LMPT
WMPT
l UMPT_L
l UMPT_GL
l WMPT
LMPT
l UMPT_U
l UMPT_GU
UMPT_G
l WMPT
l LMPT
l UMPT_UL
l UMPT_U
l UMPT_L
UMPT_U
l LMPT
l UMPT_GL
l UMPT_G
l UMPT_L
UMPT_L
l WMPT
l UMPT_GU
l UMPT_G
l UMPT_U
UMPT_GU
l LMPT
l UMPT_L
UMPT_GL
l WMPT
l UMPT_U
UMPT_UL
UMPT_G
When the emergency OM channel is enabled, the OM data is transmitted to the target base
station through the OM channel of the proxy base station. The data rate on the OM channel of
the GBTS is less than 64 kbit/s. Therefore, before enabling the emergency OM channel,
ensure that the no congestion occurs on the OM channel of the proxy base station. Otherwise,
15
eRAN11.1
eRAN Troubleshooting Guide
the emergency OM channel cannot work or services of the proxy base station will not be
affected.
Establishment Method
To establish an emergency OM channel, the proxy base station must be selected first and then
the information of the target base station must be correctly configured.
1.
If the base stations of all modes in a multi-mode base station are configured with
the same DID, the U2000 automatically matches the proxy base station to the target
base station. For example, MBTS-GUMUX+L3 separate-MPT base stations are in
the same frame in the Main Topology window.
Figure 3-3 Automatically matching the proxy base station to target base station
You can select the proxy base station according to the site planning of the operator,
for example, by identifying the base stations with the same site name.
If the GBTS serves as the proxy base station, you need to establish the emergency
OM channel on the GBSC LMT. If the eGBTS/NodeB/eNodeB serves as the proxy
16
eRAN11.1
eRAN Troubleshooting Guide
base station, you need to establish the emergency OM channel on the LMT of the
corresponding base station.
Take the GBTS as an example. Start the GBSC LMT on the U2000 by rightclicking the GBTS serving as the proxy base station and then choosing
Maintenance Client from the shortcut menu, as shown in Figure 3-4.
Figure 3-4 Selecting the proxy base station
2.
17
eRAN11.1
eRAN Troubleshooting Guide
SN
Configuration Scenario
Single-BBU
In single-BBU scenario, the following information of the target base station must be
configured.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
18
eRAN11.1
eRAN Troubleshooting Guide
User Name and Password: These two parameters specify the user name and
password for logging in to the LMT. Note that the user name and password
must have been granted administrator permissions. By default, the user name
is admin and the password is hwbs@com. Both are case-sensitive.
NOTE
If they have been changed, set the parameters to the new ones.
Main Control Board Subrack No.: This parameter specifies the number of
the BBU housing the main control board of the target base station. This
parameter is set to 0 and 1 if the main control board is configured in the root
BBU and leaf BBU, respectively.
CTPLLNK Parent Node Slot No.: This parameter is set to the number
of the slot where the parent-node UMPT locates in UMPT
interconnection scenario, and is set to the number of the slot where the
parent-node UCIU locates in UCIU-UMPT interconnection scenario.
NOTICE
If the parameter setting is inconsistent with the actual configuration, the OM
channel may be connected to an incorrect board, therefore failing to establish
the emergency OM channel.
19
eRAN11.1
eRAN Troubleshooting Guide
If the establishment fails, check and handle faults according to the following causes:
l
The connection of the remote OM channel or local LMT of the target base station is
normal. If the OM channel between the target base station and the U2000 is normal or
the target base station is locally logged in to using the Web LMT, the emergency OM
channel cannot be established.
NOTICE
An emergency OM channel is an emergent troubleshooting method for fault scenarios.
Its priority is lower than that of normal maintenance methods. In normal maintenance
modes, do not establish emergency OM channels.
l
An emergency OM channel has been established on the target or proxy base station.
During the establishment of an emergency OM channel, a single main control board can
serve as or is served by the proxy of only one main control board within the MBTS.
The emergency OM channel is immediately enabled after they automatically disable due
to exceptions on the target or proxy base station. For example, the target or proxy base
station resets, or the transmission on the emergency OM channel is interrupted for a
period and then recovers. If an emergency OM channel disables abnormally, it retains
between the target and proxy base stations within five minutes after the disabling and
deletes automatically after five minutes.
The target base station does not support the establishment of the emergency OM channel.
Emergency OM channel is unavailable if the GBTS serves as the target base station.
Ensure that the location information of the target base station is correctly
configured.
b.
Ensure that the main control board of the target base station works in the active
mode.
c.
Check whether the OM link is congested if the GBTS serves as the proxy base
station. If yes, establish the emergency OM channel when the OM link is not
congested.
20
eRAN11.1
eRAN Troubleshooting Guide
To start a proxy PNP tracing task on the GBSC LMT, information of the proxy base station must be
specified.
The proxy PNP tracing task provides the same functions as a common PNP tracing task. Both
can be started and stopped, and the tracing results can be automatically or manually saved.
NOTICE
PNP tracing applies only to the IP protocol stack.
Figure 3-10 and Figure 3-11 show the dialog box for setting parameters and the main
window for showing tracing results of a proxy PNP tracing task on the GBSC LMT,
respectively.
Figure 3-10 Dialog box for setting parameter on the GBSC LMT
21
eRAN11.1
eRAN Troubleshooting Guide
Figure 3-11 Main window for showing tracing results on the GBSC LMT
Figure 3-12 shows the main window for showing tracing results of a proxy PNP tracing task
on the LMT of eGBTS/NodeB/eNodeB (taking the eGBTS as an example below).
Figure 3-12 Main window for showing tracing results on the LMT of eGBTS/NodeB/eNodeB
Proxy MML
After the emergency OM channel is established, MML commands can be delivered to the
target base station. If the GBTS serves as the proxy base station, choose BTS Maintenance >
MML By Proxy on the GBSC LMT, and then input the commands.
l
Figure 3-13 shows the main window for using the Proxy MML function on the GBSC
LMT.
22
eRAN11.1
eRAN Troubleshooting Guide
Figure 3-13 Main window for using Proxy MML on the GBSC LMT
The details about the Proxy MML function on the GBSC LMT are as follows:
Commands can only be manually input or copied to the MML command input area.
Batch execution of MML commands is supported. The user can input a maximum
of 20 commands at a time and the LMT executes the commands one by one.
Format check can be performed for commands. However, semantic check and
parameter check are not supported.
The command expiration complies with the expiration mechanism set for all
commands on the LMT.
Figure 3-14 shows the main window for using the Proxy MML function on the LMT of
eGBTS/NodeB/eNodeB (taking the eGBTS as an example below).
23
eRAN11.1
eRAN Troubleshooting Guide
Figure 3-14 Main window for using Proxy MML on the LMT of eGBTS/NodeB/
eNodeB
The details about the Proxy MML function on the LMT of eGBTS/NodeB/eNodeB are
as follows:
To deliver commands to the target base station, select the Use MML By Proxy
check box. To execute commands on the proxy base station, clear the Use MML By
Proxy check box.
Both the command outputs for the proxy and target base stations will be printed in
the Common Maintenance tab page.
Command auto-displaying, parameter check, and semantic check are supported for
commands of the target base station based on the Macro.ini of the proxy base
station. The navigation tree, search, operation record, online help, historical
command help, and execution function are the same as those of normal MML.
Performing the preceding checks based on the Macro.ini of the proxy base station
may result in mismatch in MML command sets, parameters, and descriptions with
those of the target base station. The differences are as follows:
Online help and attribute information in notes: Only the online help and
attribute information in notes of the proxy base station can displayed.
When the Use MML By Proxy check box is selected, only format check rather than
semantic check can be performed for the commands entered or copied in the MML
command input area. The commands are directly delivered to the target base
station. These commands cannot be displayed in the Command History text box,
which ensure that the commands having differences in two RATs can be normally
input.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
24
eRAN11.1
eRAN Troubleshooting Guide
3.5.5 Troubleshooting
This chapter provides methods of troubleshooting Proxy status and MML command execution
exceptions.
The connection of the remote OM channel or local LMT of the target base station
restores.
The communication among the Web LMT, proxy base station, and target base station is
abnormal, or the proxy base station is busy.
For the first cause, the Web LMT displays a message and the target base station automatically
switches to the normal OM channel for maintenance.
For the second cause, whether the connection between the Web LMT and the proxy base
station is normal must be checked first. If the connection is abnormal, restore the connection.
If the connection is normal and the GBTS serves as the proxy base station, check whether the
OM link is congested using an Abis interface tracing task.
NOTE
If the connection is normal and the eGBTS/NodeB/eNodeB serves as the proxy base station, the
bandwidth is large and OM link congestion seldom occurs. In this case, no message tracing is required
for checking the congestion.
When the GBTS serves as the proxy base station, commands for querying logs, such as
alarm logs and operation logs, generates a large number of messages to be reported. In
this case, the commands may be discarded by the GBTS due to capability limitation.
Therefore, it is not recommended such commands be executed on the emergency OM
channel, especially when GTMUa is used as the main control board of the GBTS as its
data processing capability is limited. n the preceding case, the command execution
expiration is displayed.
Commands related to FTP file transfer fail to be executed due to the following reason:
File transfer is based on FTP and the FTP server is on the LMT. An emergency OM
channel only enables commands related to FTP file transfer to be delivered to the target
base station and to be executed. However, the FTP server is unreachable, and therefore
file transfer fails. If the multimode base station properly connects to the FTP server,
commands related to FTP file transfer can be executed.
25
eRAN11.1
eRAN Troubleshooting Guide
Assume that the OM channel of the eNodeB is faulty and the GBTS/eGBTS serves as the
proxy base station. Establish the emergency OM channel for the eNodeB as follows:
1.
b.
c.
d.
e.
f.
Add the interface IP address for the OM channel. The following is a command
example:
ADD DEVIP: CN=0, SRN=0, SN=7, SBT=BASE_BOARD, PT=ETH, PN=0,
IP="192.168.20.188", MASK="255.255.255.0":;
g.
Add the route for the OM channel. The following is a command example:
ADD IPRT: RTIDX=0, CN=0, SRN=0, SN=7, SBT=BASE_BOARD,
DSTIP="192.168.60.60", DSTMASK="255.255.255.0", RTTYPE=NEXTHOP,
NEXTHOP="192.168.20.1";
ADD IPRT: RTIDX=1, CN=0, SRN=0, SN=7, SBT=BASE_BOARD,
DSTIP="192.168.90.90", DSTMASK="255.255.255.0", RTTYPE=NEXTHOP,
NEXTHOP="192.168.20.1";
h.
2.
26
eRAN11.1
eRAN Troubleshooting Guide
b.
c.
d.
e.
f.
g.
h.
Bind the IPSec security policy and the outgoing port. The following is a command
example:
ADD IPSECBIND: CN=0, SRN=0, SN=7, SBT=BASE_BOARD, PT=ETH, PN=0,
SPGN="Policy";
3.
If the base station has obtained the device certificate of the operator, perform the
following operation to enable it to take effect.
a.
The base station automatically obtains the device certificate from the CA during
PnP deployment or shares the device certificate with the main control board of
another board.
4.
If the base station has not obtained the device certificate of the operator, manually obtain
the certificate. The PKI process is as follows:
a.
Specify the main control board for loading the device certificate on the eNodeB.
The following is a command example:
SET CERTDEPLOY: DEPLOYTYPE=SPECIFIC, CN=0, SRN=0, SN=7;
b.
c.
Set the parameters related to the CA server of the operator. The following is a
command example:
ADD CA: CANAME="C = AU, S = Some-State, O = Internet Widgits Pty Ltd, CN
= eca1", URL="http://88.88.88.88:80/pkix/";
d.
Set the parameters required for device certificate application for the eNodeB. The
following is a command example:
REQ DEVCERT: CANAME="C=AU, S=Some-State, O=Internet Widgits Pty Ltd,
CN=eca1", APPCERT="OPKIDevCert.cer";
27
eRAN11.1
eRAN Troubleshooting Guide
e.
Load the root certificate of the operator. The following is a command example:
ADD TRUSTCERT: CERTNAME="OperationCA.cer";
f.
g.
Set the tasks for periodically checking the certificate validity. The following is a
command example:
SET CERTCHKTSK: ISENABLE=ENABLE, PERIOD=7, ALMRNG=30, UPDATEMETHOD=CMP;
h.
i.
j.
(Optional) Set the parameters related to periodical CRL download task. The
following is a command example:
ADD CRLTSK: IP="192.168.86.86", USR="admin", PWD="*****",
FILENAME="NodeB.crl", ISCRLTIME=DISABLE, TSKID=0, CRLGETMETHOD=FTP;
k.
(Optional) Set the CRL application policy. The following is a command example:
SET CRLPOLICY: CRLPOLICY= NOVERIFY;
5.
Observe the OM Channel State and check whether the OM channel state is normal. The
following is a command example:
DSP OMCH: FLAG=MASTER;
6.
Check the status of the IKE SA. Run the following command and check whether the
SA FLAG is Ready in the command output:
DSP IKESA: CN=0, SRN=0, SN=7, IKEVSN=IKE_V1, DSPMODE=VERBOSE,
IKEPNM="peer", PHASE=PHASE1;
Check the status of the IPSec SA. Run the following command and check whether
IPSec SA data is displayed in the command output:
DSP IPSECSA: CN=0, SRN=0, SN=7, SPGN="policy", SPSN=1;
Check whether services are properly protected by the IPSec tunnel. Run the
following command to check the ACL rules and determine whether services are
properly protected by the IPSec tunnel:
LST ACLRULE:;
7.
Check the status of the device certificate. Run the following command and check
whether the certificate loading state is normal in the command output:
DSP APPCERT:;
Check the status of the trust certificate. Run the following command and check
whether the certificate loading state is normal in the command output:
DSP TRUSTCERT:;
(Optional) Check the CRL status. Run the following command and check whether
the certificate loading state is normal in the command output:
DSP CRL:;
28
eRAN11.1
eRAN Troubleshooting Guide
b.
c.
d.
e.
f.
Add the interface IP address for the OM channel. The following is a command
example:
ADD DEVIP: CN=0, SRN=0, SN=7, SBT=BASE_BOARD, PT=ETH, PN=0,
IP="192.168.20.188", MASK="255.255.255.0":;
g.
Add the route for the OM channel. The following is a command example:
ADD IPRT: RTIDX=0, CN=0, SRN=0, SN=7, SBT=BASE_BOARD,
DSTIP="192.168.60.60", DSTMASK="255.255.255.0", RTTYPE=NEXTHOP,
NEXTHOP="192.168.20.1";
ADD IPRT: RTIDX=1, CN=0, SRN=0, SN=7, SBT=BASE_BOARD,
DSTIP="192.168.90.90", DSTMASK="255.255.255.0", RTTYPE=NEXTHOP,
NEXTHOP="192.168.20.1";
h.
2.
Observe the OM channel state and check whether the OM channel state is normal. The
following is a command example:
DSP OMCH: FLAG=MASTER;
Co-Transmission Networking
Figure 3-17 shows the co-transmission networking.
Issue Draft A (2016-03-07)
29
eRAN11.1
eRAN Troubleshooting Guide
b.
c.
d.
e.
Add the route for the OM channel. The following is a command example:
ADD IPRT: RTIDX=0, CN=0, SRN=0, SN=6, SBT=BACK_BOARD,
DSTIP="192.168.60.60", DSTMASK="255.255.255.0", RTTYPE=IF, IFT=TUNNEL;
f.
2.
Check whether the OM channel state is normal. The following is a command example:
DSP OMCH: FLAG=MASTER;
Query the ESN of the Main Control Board in the Target Base Station
To obtain the ESN of the main control board, run the following command:
LST ESN:;
30
eRAN11.1
eRAN Troubleshooting Guide
3.6.1 Overview
Function Introduction
This function supports the query of resources and services on neighboring eNodeBs based on
X2 interface tracing when neighboring eNodeBs are disconnected from the OSS.
Figure 3-18 Remote query of services on disconnected eNodeBs
31
eRAN11.1
eRAN Troubleshooting Guide
NOTE
2.
Create an X2 interface tracing task by choosing Monitor > Signaling Trace >
Signaling Trace Management > LTE > Application Layer > X2 Interface Trace.
b.
c.
3.
32
eRAN11.1
eRAN Troubleshooting Guide
NOTE
This command is used to query response messages from neighboring eNodeBs, which facilitates service
query on neighboring eNodeBs.
4.
b.
Among the messages traced over the X2 interface, the local eNodeB sends the peer
eNodeB a RESOURCE STATUS REQUEST message, instructing the peer eNodeB
to report service status, as shown in Figure 3-23.
Figure 3-23 Instructing the peer eNodeB to report service status
c.
Check service status on the peer eNodeB sending the RESOURCE STATUS
UPDATE message, as shown in Figure 3-24.
33
eRAN11.1
eRAN Troubleshooting Guide
d.
After receiving the first RESOURCE STATUS UPDATE message sent from the
peer eNodeB, the local eNodeB sends the peer eNodeB another RESOURCE
STATUS REQUEST message, instructing the peer eNodeB to stop reporting service
status, as shown in Figure 3-25.
Figure 3-25 Instructing the peer eNodeB to stop reporting service status
3.6.4 Troubleshooting
If no messages sent from the disconnected peer eNodeB can be found in the X2 interface
tracing results, repeatedly execute the CHK NBRENODEB command and then check whether
messages sent from the peer eNodeB are received.
34
eRAN11.1
eRAN Troubleshooting Guide
35
eRAN11.1
eRAN Troubleshooting Guide
Related Counters
l
For 3900 series base stations, see eNodeB Performance Counter Reference. For the
BTS3202E, see BTS3202E Performance Counter Reference. For the BTS3911E, see
BTS3911E Performance Counter Reference
Related Alarms
l
Hardware-related alarms
ALM-26107 Board Input Voltage Out of Range (Applicable to 3900 series base
stations only)
36
eRAN11.1
eRAN Troubleshooting Guide
Link-related alarms
ALM-26234 BBU CPRI Interface Error (Applicable to 3900 series base stations
only)
RF-related alarms
Configuration-related alarms
Cell-related alarms
37
eRAN11.1
eRAN Troubleshooting Guide
Top3 cells with the largest amounts of failed RRC connection setups
(L.RRC.ConnReq.Att - L.RRC.ConnReq.Succ) and lowest RRC connection setup
success rates
Top3 cells with the largest amounts of failed E-RAB setups and lowest E-RAB setup
success rates
To check DL interference, use a spectral scanner. If both neighboring cells and external
systems may cause DL interference to the cell, locate the exact source of the DL
interference.
To check UL interference, start a cell interference detection task and analyze the result.
Possible Causes
Scenario
Fault Description
Possible Causes
l Parameters of the UE or
eNodeB are incorrectly
configured.
38
eRAN11.1
eRAN Troubleshooting Guide
Scenario
Fault Description
Possible Causes
l Resources are
insufficient.
l Parameters of the UE or
eNodeB are incorrectly
configured.
Troubleshooting Flowchart
Figure 4-1 shows the troubleshooting flowchart for handling low RRC connection setup rate
and low E-RAB setup rate.
39
eRAN11.1
eRAN Troubleshooting Guide
Figure 4-1 Troubleshooting flowchart for handling low RRC connection setup rate and low
E-RAB setup rate
Troubleshooting Procedure
1.
2.
3.
4.
5.
No: Go to 4.
Yes: End.
No: Go to 4.
No: Go to 6.
40
eRAN11.1
eRAN Troubleshooting Guide
6.
7.
8.
Yes: End.
No: Go to 6.
No: Go to 8.
Yes: End.
No: Go to 8.
Fault Description
l
The end user complains about an access failure, and the value of the performance
counter L.RRC.ConnReq.Att is 0.
The end user complains that the UE can receive signals from the cell but is unable to
access the cell.
According to the values of the performance counters on the eNodeB side, the number of
RRC connections that are successfully set up is much greater than the number of ERABs that are successfully set up.
According to the KPIs, the E-RAB setup success rate is relatively low, and among all
cause values, the cause values indicated by L.E-RAB.FailEst.TNL and L.ERAB.FailEst.RNL contribute a large proportion.
Related Information
None
Possible Causes
l
Cell parameters are incorrectly configured. For example, the E-UTRA absolute radio
frequency number (EARFCN), public land mobile network (PLMN) ID, threshold used
in the evaluation of cell camping, pilot strength, and access class.
41
eRAN11.1
eRAN Troubleshooting Guide
The authentication and encryption algorithms are incorrectly configured on the Evolved
Packet Core (EPC).
Troubleshooting Flowchart
Figure 4-2 Troubleshooting flowchart for access faults due to incorrect parameter
configurations
42
eRAN11.1
eRAN Troubleshooting Guide
Troubleshooting Procedure
1.
Check whether cell parameters are incorrectly configured. Pay special attention to the
following parameter settings as they are often incorrectly configured: the EARFCN,
PLMN ID, threshold used in the evaluation of cell camping, pilot strength, and access
class.
Yes: Correct the cell parameter configurations. Go to 2.
No: Go to 3.
2.
3.
Check the type and version of the UE and determine whether the authentication and
encryption functions are required.
Yes: Enable the authentication and encryption functions. Go to 4.
No: Go to 5.
4.
5.
Check whether parameters of the SIM card or registration-related parameters on the HSS
are incorrectly configured. The parameters of the SIM card include the K value,
originating point code (OPC), international mobile subscriber identity (IMSI), and
whether this SIM card is a UMTS SIM (USIM) card.
Yes: Correct the parameter configurations. Go to 6.
No: Go to 7.
6.
7.
Check whether the authentication and encryption algorithms are incorrectly configured
on the EPC. For example, check whether the switches for the algorithms are turned off.
Yes: Modify the parameter configuration on the EPC. Go to 8.
No: Go to 9.
8.
9.
43
eRAN11.1
eRAN Troubleshooting Guide
Typical Cases
l
Case 1: An E398 UE failed to access the network despite the fact that the authentication
and encryption functions were enabled on the EPC.
Fault Description
During a site test, an E398 UE failed to access a network where the authentication and
encryption functions were enabled on the EPC.
Fault Diagnosis
a.
The S1 interface was traced. According to the tracing result shown in Figure 4-3,
the access attempt was rejected due to no-Sultable-Cells-In-tracking-area(15).
Figure 4-3 S1 tracing result
b.
The signaling at the EPC side was traced. According to the tracing result shown in
Figure 4-4, the access attempt was rejected by the HSS in the diameterauthorization-rejected(5003) message.
Figure 4-4 Tracing result of the signaling at the EPC side
c.
44
eRAN11.1
eRAN Troubleshooting Guide
In conclusion, the E398 UE was unable to access the network because the UE used
a SIM card. To access an LTE network, the UE must use a USIM card.
Fault Handling
The SIM card in the E398 UE was replaced by a USIM card. Then, the authentication
procedure was successful and the UE successfully accessed the network.
l
Case 2: The E-RAB setup success rate at a site deteriorated due to incorrect transport
resource configurations.
Fault Description
According to the KPIs for a site, the E-RAB setup success rate deteriorated
intermittently.
Fault Diagnosis
a.
45
eRAN11.1
eRAN Troubleshooting Guide
This cause value indicates that the E-RAB failed to be set up due to faults related to
transport resources, rather than faults related to radio resources.
b.
c.
Fault Handling
Issue Draft A (2016-03-07)
46
eRAN11.1
eRAN Troubleshooting Guide
New IPPATH MOs were configured on the eNodeB based on the network plan. Then, the
E-RAB setup success rate was observed for a while, during which the E-RAB setup
success rate was normal all along.
Fault Description
l
During a random access procedure, the UE cannot receive any random access responses.
During an RRC connection setup process, the eNodeB has not received any RRC
connection setup complete messages within the related timeout duration.
During an E-RAB setup process, the response in security mode times out.
The eNodeB has not received any RRC connection reconfiguration complete messages
within the related timeout duration.
At the eNodeB side, both the RRC connection setup success rate and the E-RAB setup
success rate are low.
Related Information
Radio environment abnormalities include radio interference, imbalance between the uplink
(UL) and downlink (DL) quality, weak coverage, and eNodeB hardware faults (such as
distinct antenna configurations). The items to be investigated as well as the methods of
investigating these items are described as follows:
l
47
eRAN11.1
eRAN Troubleshooting Guide
The jumper connection needs to be investigated by analyzing drive test results. If the
jumper is reversely connected, the UL signal level will be much lower than the DL signal
level in the cell, in which case UEs remote from the eNodeB will easily encounter access
failures. Therefore, if the jumper is reversely connected, rectify the jumper connection.
The physical conditions of feeders need to be investigated. If a feeder is damaged, water
immersed, bending, or not securely connected, a large number of call drops will occur. If
a voltage standing wave ratio (VSWR) alarm is reported, such problems exist and you
need to replace the faulty feeder.
Figure 4-8 and Figure 4-9 show common causes of random access failures and E-RAB setup
failures, respectively.
Figure 4-8 Common causes of random access failures
Possible Causes
l
48
eRAN11.1
eRAN Troubleshooting Guide
Fault Diagnosis
To effectively diagnose access faults due to radio environment abnormalities, you are advised
to first find out whether this fault is caused by radio interference or weak coverage. The
following procedure is recommended:
Troubleshooting Procedure
1.
2.
3.
Check whether interference exists. By using a spectral scanner, check whether there is
DL interference from neighboring cells or external systems. By analyzing the cell
interference detection result, check whether there is UL interference.
Yes: Minimize the interference. Go to 4.
No: Go to 5.
4.
5.
Check whether the transmit power of the RRU and UE falls beyond link budgets.
Yes: Adjust the UL and DL transmit power. Go to 6.
No: Go to 7.
6.
7.
8.
9.
Typical Cases
Fault Description
Issue Draft A (2016-03-07)
49
eRAN11.1
eRAN Troubleshooting Guide
According to the KPIs for an eNodeB at a site, the RRC connection setup success rate
fluctuated significantly within a period.
Fault Diagnosis
1.
The KPIs were checked. For local cell 1, the daily RRC connection success rate was only
52%.
Figure 4-10 PRS KPI about RRC connection setups
2.
The signaling over the Uu interface was traced. The result indicated that all RRC
connection setup failures occurred because UEs do not respond. The following figure
shows a snapshot of the signaling traced over the Uu interface.
Figure 4-11 Signaling traced over the Uu interface
3.
Simulated load was added to the LTE side. The impact of the DL LTE signals on the DL
GSM signals was tested, during which the call drop rate at the GSM side raised
significantly. As a result, it was highly probable that inter-modulation interference
existed.
4.
Online spectral scan was applied to the LTE side. Interference with a magnitude of 10 dB
was found within the high-frequency resource blocks (RBs), which affected signaling
transmission.
50
eRAN11.1
eRAN Troubleshooting Guide
5.
The site was investigated and the cause of the fault was located. The LTE and GSM sides
shared the same antennas. The antennas aged and induced inter-modulation interference.
Fault Handling
The antennas were replaced. Then, the access success rate was restored.
51
eRAN11.1
eRAN Troubleshooting Guide
52
eRAN11.1
eRAN Troubleshooting Guide
Related Counters
l
For 3900 series base stations, see eNodeB Performance Counter Reference. For the
BTS3202E, see BTS3202E Performance Counter Reference. For the BTS3911E, see
BTS3911E Performance Counter Reference
Related Alarms
l
Alarms related to CPRI links (Applicable to 3900 series base stations only)
53
eRAN11.1
eRAN Troubleshooting Guide
Handover Procedures
Handovers are classified as coverage-based, load-based, frequency-priority-based, servicebased, and UL-quality-based. For details, see eRAN Mobility Management in Connected
Mode Feature Parameter Description.
Possible Causes
There are various causes of handover faults, such as incorrect data configuration, hardware
faults, interference, and poor Uu quality. Therefore, to effectively diagnose a handover fault,
you need to carry out a pertinent analysis based on the actual situation.
Table 5-1 shows possible causes of handover faults.
Table 5-1 Possible causes of handover faults
Scenario
Fault Description
Possible Causes
l The performance
counters throughout the
whole network are
abnormal.
l The performance
counters for the serving
cell are abnormal.
l Hardware is faulty.
l Parameters are set to
inappropriate values.
l Handovers to
neighboring cells are
seldom initiated.
l Handovers to
neighboring cells are
frequently initiated.
l The UE cannot receive
handover commands
from the network.
Troubleshooting Flowchart
The following measures are effective in locating a handover fault:
Issue Draft A (2016-03-07)
54
eRAN11.1
eRAN Troubleshooting Guide
To locate an intra-RAT handover fault, you are advised to select topN cells with handover
faults and then follow the troubleshooting procedure shown in Figure 5-1.
Figure 5-1 Troubleshooting flowchart for intra-RAT handover faults
Troubleshooting Procedure
1.
55
eRAN11.1
eRAN Troubleshooting Guide
Yes: Hardware faults are often accompanied by alarms. You are advised to handle the
fault by following the instructions on how to troubleshoot handover faults due to
hardware faults. Go to 2.
No: Go to 3.
2.
3.
4.
5.
Check whether the service channel of the target cell is severely congested.
Check the service satisfaction rates to determine whether the service channel of the
target cell is severely congested.
Yes: Follow the instructions on how to troubleshoot handover faults due to target cell
congestion. Go to 6.
No: Go to 7.
6.
7.
8.
9.
56
eRAN11.1
eRAN Troubleshooting Guide
Fault Description
Typical hardware faults include faulty or overloaded boards, as well as abnormal radio
frequency (RF) module or clock sources. If a hardware fault occurs, the cell will degrade in
capability or even become out of service, in addition to the following symptoms:
l
Related alarms
Related Information
Related Alarms
l
Alarms related to CPRI links (Applicable to 3900 series base stations only)
Possible Causes
Possible hardware faults that will cause handover faults are listed as follows:
l
A board is overloaded.
57
eRAN11.1
eRAN Troubleshooting Guide
An RF module is faulty.
A common public radio interface (CPRI) link is faulty. (Applicable to 3900 series base
stations only)
Troubleshooting Flowchart
Figure 5-2 shows the troubleshooting flowchart for intra-RAT handover faults due to
hardware faults.
Figure 5-2 Troubleshooting flowchart for intra-RAT handover faults due to hardware faults
Troubleshooting Procedure
1.
2.
3.
Typical Cases
Fault Description
Handovers between cell 0 and cell 2 under an eNodeB were normal with a high success rate,
but the handovers from cell 1 under the eNodeB to its neighboring cells were abnormal with a
relatively low success rate (7%) during busy hours.
Fault Diagnosis
1.
Alarms about the eNodeB were checked. Cell 1 had reported ALM-26529 RF Unit
VSWR Threshold Crossed.
2.
As engineers of the customer confirmed, the eNodeB had been reconstructed recently.
Therefore, it was highly probable that the RF connections became abnormal during the
site reconstruction.
58
eRAN11.1
eRAN Troubleshooting Guide
3.
At the site, it was found that the jumper was not securely connected to the feeder, which
had caused the cell malfunction.
Fault Handling
The jumper was securely connected to the feeder. According to the KPI log, the inter-cell
handover success rate was restored.
Fault Description
l
Related Information
None
Possible Causes
l
59
eRAN11.1
eRAN Troubleshooting Guide
Troubleshooting Flowchart
Figure 5-3 shows the troubleshooting flowchart for intra-RAT handover faults due to
incorrect data configurations.
Figure 5-3 Troubleshooting flowchart for intra-RAT handover faults due to incorrect data
configurations
Troubleshooting Procedure
1.
2.
3.
4.
5.
60
eRAN11.1
eRAN Troubleshooting Guide
No: Go to 7.
6.
7.
Typical Cases
Fault Description
During a drive test, a UE did not receive any handover commands after sending A3
measurement reports to the eNodeB. Ultimately, the service is dropped.
Fault Diagnosis
1.
2.
The signaling over the X2 interface was traced and was found to be normal.
3.
The configuration of the IPPATH MO for the X2 interface was checked and an
inconsistency was found. The adjacent node ID specified in the IPPATH MO was
different from the X2 interface ID, which caused a resource request failure and
ultimately a handover failure.
Fault Handling
The configuration of the IPPATH MO was corrected. Then, the test was conducted again and
the UE was successfully handed over to the target cell.
Fault Description
The service satisfaction rate in the target cell is lower than the admission threshold for
handed-over services, due to which the target eNodeB rejects the requests of handovers to the
target cell. The service satisfaction rate in a cell can be viewed on the U2000.
Related Information
None
Possible Causes
l
61
eRAN11.1
eRAN Troubleshooting Guide
A large number of UEs have been handed over to the target cell due to inappropriate
parameter configurations.
Troubleshooting Flowchart
Figure 5-4 shows the troubleshooting flowchart for intra-RAT handover faults due to target
cell congestion.
Figure 5-4 Troubleshooting flowchart for intra-RAT handover faults due to target cell
congestion
Troubleshooting Procedure
1.
2.
3.
Typical Cases
Fault Description
During a period, all handovers to a cell failed.
Fault Diagnosis
1.
2.
The RF module serving the cell was checked. No fault was found.
3.
As signaling tracing for a single UE indicated, the service satisfaction rate in the cell was
always low (lower than the admission thresholds for handed-over services with QCIs
ranging from 1 to 4) when a handover failure message appeared. Therefore, these
handovers failed because the traffic channel was so congested in the cell that there were
no resources available for new handed-over services.
62
eRAN11.1
eRAN Troubleshooting Guide
Fault Handling
Engineers of the customer were advised to expand the cell capacity or reduce UEs in the cell
by modifying handover parameter configurations. After the correspond measure was taken,
the success rate of handovers to the cell became normal.
Fault Description
Two symptoms may occur when the Uu quality is poor. One is that the UE cannot receive any
handover commands from the eNodeB, the other is that the UE cannot access the target cell
and cannot report the handover complete message.
Related Information
Checking interference
1.
Start a cell interference detection task and check the performance counter indicating the
uplink (UL) signal quality. If high UL modulation and coding scheme (MCS) orders
seldom appear, it is highly probable that interference to the cell exists.
2.
Start the UE spectral scanning function and further determine whether the interference
originates from neighboring cells or external systems.
Check whether the transmit power of the RRU and UE falls within link budgets.
63
eRAN11.1
eRAN Troubleshooting Guide
Check whether the tilts and azimuths of two antennas are the same.
Possible Causes
The following Uu problems may cause handover faults:
l
Interference
Unsatisfactory coverage
Troubleshooting Flowchart
To effectively diagnose handover faults due to poor Uu quality, you are advised to first find
out whether this fault is caused by interference or unsatisfactory coverage. Figure 5-5 shows
the troubleshooting flowchart for intra-RAT handover faults due to poor Uu quality.
64
eRAN11.1
eRAN Troubleshooting Guide
Figure 5-5 Troubleshooting flowchart for intra-RAT handover faults due to poor Uu quality
Troubleshooting Procedure
1.
Check whether interference exists. By using a UE spectral scanner, check whether there
is DL interference from neighboring cells or external systems. By analyzing the cell
interference detection result, check whether there is UL interference.
Yes: Remove the interference. Go to 2.
No: Go to 3.
2.
3.
4.
5.
65
eRAN11.1
eRAN Troubleshooting Guide
7.
8.
9.
Typical Cases
None
66
eRAN11.1
eRAN Troubleshooting Guide
67
eRAN11.1
eRAN Troubleshooting Guide
68
eRAN11.1
eRAN Troubleshooting Guide
Related Counters
Measurement related to E-RAB release (E-RAB.Rel.Cell)
Counters related to service drops are classified as follows:
l
Release types
Normal releases
Abnormal releases
QCIs of 1 to 9
Congestion (L.E-RAB.AbnormRel.Cong)
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
69
eRAN11.1
eRAN Troubleshooting Guide
If the percentage of abnormal E-RAB releases due to congestion to all abnormal ERAB releases is greater than 30%, you need to check whether congestion occurs in
the cell.
For 3900 series base stations, see eNodeB Performance Counter Reference. For the
BTS3202E, see BTS3202E Performance Counter Reference. For the BTS3911E, see
BTS3911E Performance Counter Reference
Formula
The service drop rate is calculated based on services but not on UEs. For example, services
are set up on multiple data radio bearers (DRBs) for a UE. Then, if all these services
experience drops, multiple service drops are counted.
The formula for calculating the service drop rate is as follows:
Service drop rate = L.E-RAB.AbnormRel / (L.E-RAB.AbnormRel + L.E-RAB.NormRel) *
100%
Where,
l
The L.E-RAB.NormRel counter measures the total number of normal E-RAB releases in
a cell.
Drive Test
To identify service drops in drive tests, you need to check logs and signaling procedures on
the UE side.
For details, see the related UE user guide.
The service drop rate of each of topN cells must be higher than the average service drop
rate of the whole network.
Cells are sequenced in descending order based on the number of abnormal E-RAB
releases.
Related Alarms
l
Hardware-related alarms
70
eRAN11.1
eRAN Troubleshooting Guide
ALM-26107 Board Input Voltage Out of Range (Applicable to 3900 series base
stations only)
Link-related alarms
ALM-26234 BBU CPRI Interface Error (Applicable to 3900 series base stations
only)
RF-related alarms
Configuration-related alarms
71
eRAN11.1
eRAN Troubleshooting Guide
Possible Causes
If the service drop rate increases or greatly fluctuates, you must first locate the faults and then
handle the faults accordingly. Table 6-1 describes possible causes of service drops.
Table 6-1 Possible causes of service drops
Type
Fault Description
Possible Causes
l Data transmission is
abnormal.
A single eNodeB
experiences abnormalities.
l Network planning is
improper.
l The evolved packet core
(EPC) works abnormally.
l Data transmission is
abnormal.
l Network planning is
improper.
l Resources are
insufficient.
l Weak coverage or
interference exists.
l The EPC works
abnormally.
Troubleshooting Flowchart
To troubleshoot service drops, you are advised to select topN cells with service drops and then
follow the troubleshooting procedure shown in Figure 6-1.
72
eRAN11.1
eRAN Troubleshooting Guide
Troubleshooting Procedure
Troubleshooting service drops of the whole network
1.
Check whether the whole network has experienced operations such as cutover,
replacement, upgrade, or patch installation.
2.
Check whether the eNodeB parameters, such as timers or algorithm switches, have been
modified.
3.
73
eRAN11.1
eRAN Troubleshooting Guide
activities such as number allocation or important holidays that may lead to a traffic
volume increase.
4.
Check whether the versions or parameters of the EPC network elements (NEs) have been
modified.
Check whether the topN cells have experienced operations such as cutover or relocation.
2.
Check whether the topN cells have experienced operation and maintenance (OM)
operations such as cell deactivation or board restart.
3.
4.
Check whether the cell parameters have been modified, such as the maximum number of
acknowledged mode (AM) protocol data unit (PDU) retransmissions by the UE or
eNodeB, or the UE inactivity timer length.
5.
Check whether the versions or parameters of the EPC NEs corresponding to the topN
cells have been modified.
Fault Description
According to the definitions of eNodeB performance counters, the L.ERAB.AbnormRel.Radio counter measures the number of abnormal E-RAB releases due to
radio interface faults in non-handover scenarios.
Related Information
None
Possible Causes
Abnormal E-RAB releases due to radio faults are caused by faults such as the number of
Radio Link Control (RLC) retransmissions reaching the maximum, UE uplink out-ofsynchronization, or signaling procedure failures that are resulted from weak coverage, uplink
interference, or UE exceptions.
Troubleshooting Flowchart
None
Troubleshooting Procedure
1.
74
eRAN11.1
eRAN Troubleshooting Guide
Check the values of the counters related to different channel quality indicator (CQI)
levels and modulation and coding scheme (MCS) orders to determine whether low-level
CQIs and low-order MCSs are mostly used, the uplink reference signal received power
(RSRP) is poor, and the uplink signal to interference plus noise ratio (SINR) is low.
Yes: Confirm the cell coverage by using drive tests, and then adjust the weak coverage
accordingly. Go to 2.
No: Go to 3.
2.
3.
4.
5.
Typical Cases
Fault Description
According to the routine KPI monitoring result, the service drop rate of cell A is 16%.
Fault Diagnosis
1.
2.
According to the CHR logs, the E-RAB release is initiated with the release cause of
UE_RESYNC_DATA_IND_REL_CAUSE. (UE_RESYNC_DATA_IND_REL_CAUSE
indicates that the abnormal E-RAB release is caused by resynchronization that is
triggered by L2 data reporting after the UE experiences an out-of-synchronization.)
3.
According to the CHR logs, the uplink RSRP is less than -135 dBm and the average
SINR is less than -3 dB before the service drop occurs.
Fault Handling
Improve LTE network coverage.
Fault Description
According to the definitions of eNodeB performance counters, the L.E-RAB.AbnormRel.TNL
counter measures the number of abnormal E-RAB releases due to faults at the transport
network layer.
Issue Draft A (2016-03-07)
75
eRAN11.1
eRAN Troubleshooting Guide
Related Information
None
Possible Causes
Abnormal E-RAB releases due to transmission faults are caused by transmission exceptions
between the eNodeB and the MME. For example, the transmission link over the S1
interference experiences intermittent disconnections. The BTS3202E/BTS3911E does not
support SCTPLINK6.
Troubleshooting Flowchart
None
Troubleshooting Procedure
Check whether transmission-related alarms are reported. If any, clear the reported alarms.
Then, check whether the corresponding counter has a proper value.
1.
2.
3.
Typical Cases
None
Fault Description
According to the definitions of eNodeB performance counters, the L.ERAB.AbnormRel.Cong counter measures the number of abnormal E-RAB releases due to
resource congestion.
Related Information
None
Issue Draft A (2016-03-07)
76
eRAN11.1
eRAN Troubleshooting Guide
Possible Causes
Abnormal E-RAB releases due to congestion are caused by congestion of radio resources on
the eNodeB side. For example, the radio sources are insufficient if the number of UEs reaches
the upper limit.
Troubleshooting Flowchart
None
Troubleshooting Procedure
If service drops due to congestion occurs in a topN cell for a long time, mobility load
balancing (MLB) can be enabled to temporarily reduce the cell load. In the long term, the cell
requires capacity expansion. After rectifying the congestion fault, check whether the
corresponding counter has a proper value.
1.
Turn on the switch for the MLB algorithm, and then check whether the congestion fault
is rectified.
Yes: End.
No: Go to 2.
2.
Typical Cases
None
Fault Description
According to the definitions of eNodeB performance counters, the L.ERAB.AbnormRel.HOFailure counter measures the number of abnormal E-RAB releases due
to outgoing handover failures.
Related Information
Counters related to outgoing handovers to a specific cell
l
L.HHO.NCell.PrepAttOut
L.HHO.NCell.ExecAttOut
L.HHO.NCell.ExecSuccOut
L.HHO.Ncell.PingPongHo
L.HHO.NCell.HoToolate
L.HHO.NCell.HoTooearly
L.HHO.NCell.MMEAbnormRsp
77
eRAN11.1
eRAN Troubleshooting Guide
L.HHO.NCell.Succ.ReEst2Src
Possible Causes
Abnormal E-RAB releases due to handover failures are caused by failures of handovers from
the local cell to another cell.
2.
3.
Typical Cases
Fault Description
After the X2 relationship is manually configured, handovers fail in the site, increasing the
service drop rate.
Fault Diagnosis
1.
2.
Check message exchanges over the standard interface. The UE does not receive any
handover instructions.
3.
Check the CHR of the source site. The uplink RSRP is about -140 dBm before the
handover failure occurs, which means coverage is poor.
Fault Handling
Reconfigure the neighboring relationship.
78
eRAN11.1
eRAN Troubleshooting Guide
Fault Description
According to the definitions of eNodeB performance counters, the L.ERAB.AbnormRel.MMETot (applicable only to 3900 series base stations) and L.ERAB.AbnormRel.MME counters measure the number of E-RAB releases that are initiated by
the MME when the corresponding E-RABs do not have and have data transmission,
respectively, and the L.E-RAB.AbnormRel counter measures the number of E-RAB releases
that are initiated by the eNodeB. If an E-RAB having data transmission is abnormally released
and the release is included in the value of the L.E-RAB.AbnormRel.MME counter, it can be
determined that the release is an abnormal E-RAB release initiated by the evolved packet core
(EPC). However, the abnormal release is not included in the value of the L.ERAB.AbnormRel counter.
Related Information
None
Possible Causes
Abnormal E-RAB releases due to MME faults are initiated by the EPC when UEs are
performing services.
Troubleshooting Flowchart
None
Troubleshooting Procedure
MME faults must be identified on the EPC side.
1.
Obtain the S1 tracing messages related to the topN cell and analyze specific release
causes.
2.
Collect the analysis result and information about the signaling procedure and then
contact EPC engineers.
3.
4.
Typical Cases
Fault Description
At the early stage of network deployment, the outgoing handover success rate is 94.7% on the
entire network, and therefore, the service drop rate is high.
Fault Diagnosis
1.
Analyze the CHRs of the source site and target site to check for problems, such as weak
coverage, topN UEs, capacity, and interference.
2.
Analyze the CHR of the source site. The UE obtains the handover instruction but the
source site does not receive any context release instruction from the target site.
79
eRAN11.1
eRAN Troubleshooting Guide
3.
Analyze the message exchanges over the standard interface of the target site. The MME
does not send the PATH_SWITCH_ACK message to the target site.
Fault Handling
Identify faults on the EPC side.
80
eRAN11.1
eRAN Troubleshooting Guide
81
eRAN11.1
eRAN Troubleshooting Guide
82
eRAN11.1
eRAN Troubleshooting Guide
Related Counters
l
For 3900 series base stations, see eNodeB Performance Counter Reference. For the
BTS3202E, see BTS3202E Performance Counter Reference. For the BTS3911E, see
BTS3911E Performance Counter Reference
Possible Causes
When the KPIs related to inter-RAT handovers deteriorate or fluctuate dramatically, determine
whether the deterioration or fluctuation is caused by TopN cells/sites, or the entire network. 4
describes possible causes of inter-RAT handover faults.
Table 7-1 Possible causes of inter-RAT handover faults
Scenario
Fault Description
Possible Causes
The TopN
cells or sites
experience
abnormaliti
es.
l Performance counters
related to inter-RAT
handovers in a cell are
abnormal.
l Hardware is faulty.
l Parameters are inappropriately set.
83
eRAN11.1
eRAN Troubleshooting Guide
Scenario
Fault Description
Possible Causes
The whole
network
experiences
abnormaliti
es.
l Performance counters
related to inter-RAT
handovers throughout the
whole network are
abnormal.
Troubleshooting Flowchart
The following measures are effective in locating an inter-RAT handover fault:
l
Checking UE capabilities
Select TopN cells with inter-RAT handover faults and then troubleshoot the faults
according to Figure 7-1.
84
eRAN11.1
eRAN Troubleshooting Guide
85
eRAN11.1
eRAN Troubleshooting Guide
Troubleshooting Procedure
1.
Locate TopN sites with inter-RAT handover faults by viewing performance counters.
2.
Hardware faults are the most likely causes if performance counters related to inter-RAT handovers
suddenly deteriorate without recent modifications to the configurations of the abnormal cell and its
neighboring cells.
3.
4.
Inter-RAT handovers require high UE capabilities and you are advised to check UE capabilities
first.
5.
6.
Check whether the switch, threshold, and neighboring cells for inter-RAT handovers are
incorrectly configured on the eRAN side.
Yes: Follow the instructions on how to troubleshoot handover faults due to incorrect data
configurations. Then go to 7.
No: Go to 8.
7.
8.
Check whether the service channel of the target cell is severely congested.
Yes: Follow the instructions on how to troubleshoot handover faults due to target cell
congestion. Then go to 9.
No: Go to 10.
9.
10. Check whether the EPC is incorrectly configured. That is, check whether abnormal
signaling messages are delivered by the EPC.
Yes: Ask EPC personnel to reconfigure the EPC. Then go to 11.
No: Go to 12.
Issue Draft A (2016-03-07)
86
eRAN11.1
eRAN Troubleshooting Guide
Fault Description
Typical hardware faults include faulty or overloaded boards, as well as abnormal radio
frequency (RF) module or clock sources. If a hardware fault occurs, the cell will degrade in
capability or even become out of service, in addition to the following symptoms:
l
Related alarms
Related Information
Related Alarms
l
87
eRAN11.1
eRAN Troubleshooting Guide
Alarms related to CPRI links (Applicable to 3900 series base stations only)
Possible Causes
Possible hardware faults that will cause handover faults are listed as follows:
l
A board is overloaded.
An RF module is faulty.
A common public radio interface (CPRI) link is faulty. (Applicable to 3900 series base
stations only)
Troubleshooting Flowchart
Figure 7-2 shows the flowchart for troubleshooting inter-RAT handover faults due to
hardware faults.
88
eRAN11.1
eRAN Troubleshooting Guide
Figure 7-2 Troubleshooting flowchart for inter-RAT handover faults due to hardware faults
Troubleshooting Procedure
1.
2.
3.
Typical Cases
Fault Description
Handovers between cell 0 and cell 2 under an eNodeB were normal with a high success rate,
but the handovers from cell 1 under the eNodeB to its neighboring cells were abnormal with a
relatively low success rate (7%) during busy hours.
Fault Diagnosis
1.
Alarms about the eNodeB were checked. Cell 1 had reported ALM-26529 RF Unit
VSWR Threshold Crossed.
2.
As engineers of the customer confirmed, the eNodeB had been reconstructed recently.
Therefore, it was highly probable that the RF connections became abnormal during the
site reconstruction.
3.
At the site, it was found that the jumper was not securely connected to the feeder, which
had caused the cell malfunction.
Fault Handling
The jumper was securely connected to the feeder. According to the KPI log, the inter-RAT
handover success rate becomes normal.
89
eRAN11.1
eRAN Troubleshooting Guide
Fault Description
l
Handovers to inter-RAT neighboring cells cannot be triggered. The eNodeB does not
deliver inter-RAT handover commands in either of the following conditions:
Drive test results and signaling tracing results over standard interfaces on the
eNodeB side show that the UE experiences poor signal quality in its serving cell
and the threshold for inter-RAT handovers is met.
Related Information
l
Inter-RAT frequency band supported by the UE: For detailed information, see the
interRAT-Parameters IE carried in the UE CAPABILITY INFORMATION message.
UE's capability of supporting inter-RAT handovers: For detailed information, see B.1
"Feature group indicators" in 3GPP TS 36.331.
UE's capability of supporting PS handovers to GERAN: interRAT-PS-HOToGERAN indicates whether the UE supports PS handovers to GERAN. false: not
supported; true: supported.
Inter-RAT frequency bands supported by the UE and UE's capability of supporting inter-RAT
handovers can be viewed in the Uu interface tracing results on the eNodeB side, as shown in
Figure 7-3. Bit 8 in featureGroupIndicators indicates whether the UE supports PS
handovers to UTRAN and interRAT-PS-HO-ToGERAN indicates whether the UE supports
PS handovers to GERAN. Information in the blue rectangle indicates the UTRAN and
GERAN frequency bands supported by the UE.
90
eRAN11.1
eRAN Troubleshooting Guide
Possible Causes
The UE does not support inter-RAT frequency bands or inter-RAT PS handovers.
Troubleshooting Flowchart
Figure 7-4 shows the flowchart for troubleshooting inter-RAT handover faults due to poor UE
capabilities.
91
eRAN11.1
eRAN Troubleshooting Guide
Figure 7-4 Troubleshooting flowchart for inter-RAT handover faults due to poor UE
capabilities
Typical Cases
Fault Description
During an LTE to UMTS PS handover test at a site, Uu interface tracing results show that the
eNodeB did not deliver a PS handover command after receiving the B1 measurement report
from the UE.
Fault Locating
1.
The UMTS frequency band configured for this site is band7 and the UE access signaling
procedure shows that the UE supports band0, band2, and band7. Therefore, the fault is
not caused by not supporting inter-RAT frequency bands. Figure 7-5 shows an example
of Uu interface tracing results.
92
eRAN11.1
eRAN Troubleshooting Guide
2.
Check whether the UE supports PS handovers to UTRAN. As shown in Figure 7-5, bit 8
in featureGroupIndicators is 0, which indicates that the UE does not support PS
handovers to UTRAN. According to 3GPP TS 36.331, the eNodeB does not deliver PS
handover commands when the UE does not support PS handovers.
Troubleshooting
This fault is rectified after a UE that supports PS handovers to UTRAN is used or after the
inter-RAT handover policy is changed to redirection.
Fault Description
Handovers to inter-RAT neighboring cells cannot be triggered.
l
Drive test results or signaling tracing results over standard interfaces show that the UE
experiences poor signal quality in its serving cell. The signal level in an inter-RAT
neighboring cell meets the threshold for inter-RAT handovers but the handover cannot be
triggered.
93
eRAN11.1
eRAN Troubleshooting Guide
The value of counters that measure the number of outgoing handover attempts from EUTRAN to inter-RAT networks (L.IRATHO.E2XXX.PrepAttOut) is 0. XXX refers to
inter-RAT networks.
Related Information
None
Possible Causes
l
Parameters such as the inter-RAT handover threshold, hysteresis, and time-to-trigger are
inappropriately configured.
Inter-RAT handovers are triggered only when the signal level of the target inter-RAT
neighboring cell is higher than that of the serving cell by the amount specified by the
inter-RAT handover threshold. If parameters (such as the inter-RAT handover threshold,
hysteresis, and time-to-trigger) are inappropriately set, handovers may be difficult to
trigger or may be frequently triggered.
Troubleshooting Flowchart
Figure 7-6 shows the flowchart for troubleshooting inter-RAT handover faults due to
incorrect parameter configurations.
94
eRAN11.1
eRAN Troubleshooting Guide
Figure 7-6 Troubleshooting flowchart for inter-RAT handover faults due to incorrect
parameter configurations
Typical Cases
Fault Description
During an LTE to UMTS PS handover test at a site, the eNodeB did not deliver a PS handover
command after the UE sent the B1 measurement report.
Fault Locating
1.
The output of the LST ENODEBALGOSWITCH command shows that the UTRAN
PS handover switch on the eNodeB side is turned on.
2.
eNodeB neighbor relationships show that the routing area code (RAC) was not
configured during the neighboring UTRAN cell configuration. The RAC is not
configured by default. As a result, the eNodeB will not deliver PS handover commands.
In this case, parameters for neighboring cells are incompletely configured, leading to
inter-RAT handover faults.
Troubleshooting
Issue Draft A (2016-03-07)
95
eRAN11.1
eRAN Troubleshooting Guide
Run the MOD UTRANEXTERNALCELL command to change the value of the Routing
area code indicator parameter for external UTRAN cells to CFG and configure Routing
area code based on the RAC of external UTRAN cells.
Fault Description
l
Traffic statistics for inter-RAT handover failures include the counters that measure the
number of outgoing handover preparation failures due to handover preparation failures in
inter-RAT networks (L.IRATHO.E2XXX.Prep.FailOut.PrepFailure).
Traffic statistics for inter-RAT handover failures include the counters that measure the
number of outgoing handover preparation failures due to no responses from inter-RAT
networks (L.IRATHO.E2XXX.Prep.FailOut.NoReply).
Related Information
None
Possible Causes
l
The number of UEs in the target cell surges due to celebrations or gatherings.
A large number of UEs have been handed over to the target cell due to inappropriate
parameter settings.
Troubleshooting Flowchart
Figure 7-7 shows the flowchart for troubleshooting inter-RAT handover faults due to target
cell congestion.
Figure 7-7 Troubleshooting flowchart for inter-RAT handover faults due to target cell
congestion
96
eRAN11.1
eRAN Troubleshooting Guide
Typical Cases
Fault Description
During an LTE to UMTS PS handover test at a site, the handover keeps failing. Traffic
statistics for inter-RAT handover failures include the counter that measures the number of
outgoing handover preparation failures due to handover preparation failures in WCDMA
network (L.IRATHO.E2W.Prep.FailOut.PrepFailure).
Fault Locating
1.
2.
Investigation results from the EPC side show that this cause value is sent by UMTS.
3.
Confirmation results with UMTS network personnel show that the UMTS frequency is
blocked, leading to handover preparation failures.
Troubleshooting
This fault is rectified after the frequency is unblocked on the UMTS side.
Fault Description
l
Traffic statistics for inter-RAT handover failures include the counters that measure the
number of outgoing handover preparation failures from E-UTRAN to inter-RAT
networks due to faults in the EPC (L.IRATHO.E2XXX.Prep.FailOut.MME).
The signaling procedure contains failure messages delivered by the EPC or no reply on
the EPC side, such as RAU failures or TAU failures.
Related Information
None
Possible Causes
Interfaces in the EPC are incorrectly configured or become faulty.
Troubleshooting Procedure
MME faults must be identified on the EPC side.
1.
Obtain the S1 tracing messages related to the topN cell and analyze specific release
causes.
2.
Collect the analysis result and information about the signaling procedure and then
contact EPC engineers.
97
eRAN11.1
eRAN Troubleshooting Guide
3.
4.
Typical Cases
Fault Description
During an LTE to UMTS PS handover test at a site, traffic statistics for outgoing inter-RAT
handover failures include the counter that measures the number of outgoing handover
preparation failures due to no responses from WCDMA network
(L.IRATHO.E2W.Prep.FailOut.NoReply).
Fault Locating
1.
Uu interface tracing results show that the UE has sent the B1 measurement report to the
eNodeB. S1 interface tracing results show that the eNodeB has sent the HO Required
command to the MME.
2.
After a while, the eNodeB sent a HO Cancel command to the MME with the cause value
"radioNetwork: tS1relocprep-expiry", which indicates that the timer for the eNodeB to
wait for a response from the EPC expires.
3.
The confirmation results with EPC personnel show that the MME has received the HO
Required command but failed to forward this message to the SGSN. The reason is that
the Gn interface between the MME and SGSN had been inappropriately set and the
MME cannot find the corresponding SGSN. The MME sent the UE a PSHO Cancel
message after the S1 message waiting timer expires.
Troubleshooting
The fault was rectified after the EPC personnel reconfigured the Gn interface between the
MME and the SGSN.
Fault Description
Two symptoms may occur when the Uu quality is poor. One is that the UE cannot receive any
handover commands from the eNodeB, the other is that the UE cannot access the target cell
and cannot report the handover complete message.
Related Information
Checking interference
1.
Start a cell interference detection task and check the performance counter indicating the
uplink (UL) signal quality. If high UL modulation and coding scheme (MCS) orders
seldom appear, it is highly probable that interference to the cell exists.
98
eRAN11.1
eRAN Troubleshooting Guide
2.
Start the UE spectral scanning function and further determine whether the interference
originates from neighboring cells or external systems.
3.
Check whether the transmit power of the RRU and UE falls within link budgets.
Check whether the tilts and azimuths of two antennas are the same.
Possible Causes
The following Uu problems may cause handover faults:
l
Interference
Unsatisfactory coverage
Troubleshooting Flowchart
Figure 7-8 shows the flowchart for troubleshooting inter-RAT handover faults due to radio
environment abnormalities.
99
eRAN11.1
eRAN Troubleshooting Guide
Figure 7-8 Troubleshooting flowchart for inter-RAT handover faults due to radio environment
abnormalities
Troubleshooting Procedure
1.
Check whether interference exists. By using a UE spectral scanner, check whether there
is DL interference from neighboring cells or external systems. By analyzing the cell
interference detection result, check whether there is UL interference.
Yes: Remove the interference. Go to 2.
No: Go to 3.
2.
3.
4.
100
eRAN11.1
eRAN Troubleshooting Guide
5.
6.
7.
8.
9.
Typical Cases
None
Related Information
None
Possible Causes
The UE is faulty or the UE is incompatible with the network.
Fault Locating
None
Fault Handling
Personnel on the UE and eRAN sides must work together to handle this fault.
1.
Obtain Uu and S1 interface tracing messages for TopN cells and then analyze the
distribution of inter-RAT handover failures caused by abnormal UEs.
2.
Collect the analysis results and information about the signaling procedures, and handle
the fault with personnel on the UE side.
101
eRAN11.1
eRAN Troubleshooting Guide
3.
4.
Typical Cases
Fault Description
A large number of LTE to UMTS PS handovers fail at a site and the value of the
L.IRATHO.E2W.ExecAttOu counter is far greater than that of the
L.IRATHO.E2W.ExecSuccOut counter.
Fault Locating
1.
View the Uu and S1 interface tracing results. The eNodeB has delivered a handover
command to the UMTS network over the Uu interface but the UE did not access the
UMTS network. Instead, the UE initiates cell reestablishment in the source LTE cell with
the cause value "handoverFailure."
2.
Inter-RAT handovers using the abnormal UE occasionally fail when the network remains
unchanged.
NOTE
3.
Contact personnel on the UE side to locate and then troubleshoot the fault.
Troubleshooting
This fault is rectified by personnel on the UE side.
102
eRAN11.1
eRAN Troubleshooting Guide
103
eRAN11.1
eRAN Troubleshooting Guide
No transmission
User equipment (UE) that has accessed a network cannot perform data services.
No transmission
104
eRAN11.1
eRAN Troubleshooting Guide
The traffic rates of data services can be measured in the following ways:
l
The Ethernet-layer rate can be measured by using DU Meter at the server and client.
The rates at the RLC and MAC layers can be measured at the eNodeB.
The rates at layers such as RLC and MAC for Huawei user equipment (UE) can be
measured by using the Probe.
Maximum
Number of
DL-SCH
Transport
Block Bits
Received
Within a TTI
Maximum
Number of
Bits of a DLSCH
Transport
Block
Received
Within a TTI
Total Number
of Soft
Channel Bits
Maximum
Number of
Supported
Layers for
Spatial
Multiplexing
in DL
Category 1
10296
10296
250368
Category 2
51024
51024
1237248
105
eRAN11.1
eRAN Troubleshooting Guide
UE Category
Maximum
Number of
DL-SCH
Transport
Block Bits
Received
Within a TTI
Maximum
Number of
Bits of a DLSCH
Transport
Block
Received
Within a TTI
Total Number
of Soft
Channel Bits
Maximum
Number of
Supported
Layers for
Spatial
Multiplexing
in DL
Category 3
102048
75376
1237248
Category 4
150752
75376
1827072
Category 5
299552
149776
3667200
Maximum Number of
Bits of a UL-SCH
Transport Block
Transmitted Within a
TTI
Category 1
5160
No
Category 2
25456
No
Category 3
51024
No
Category 4
51024
No
Category 5
75376
Yes
The theoretical rate calculated is the protocol-stipulated MAC-layer rate, not the application-layer rate
for eNodeBs.
106
eRAN11.1
eRAN Troubleshooting Guide
Fault Description
The observed rate is stable but at least 10% lower than the baseline value.
Figure 8-2 Rate fault 1 - stable but lower than the baseline value
The observed rate fluctuates by more than 50%, as shown in the following figures.
Figure 8-3 Rate fault 2 - fluctuation type 1
Related Information
The User Datagram Protocol (UDP) is a simple datagram-oriented transport-layer protocol.
UDP provides an unreliable service. It sends datagrams from the application to the IP layer
Issue Draft A (2016-03-07)
107
eRAN11.1
eRAN Troubleshooting Guide
but does not ensure that the datagrams can arrive at their destinations. However, UDP features
a high transmission speed, because a connection does not need to be set up before UDP-based
transmission between a client and a server and retransmission upon timeout is not applied.
The Transmission Control Protocol (TCP) provides connection-oriented reliable delivery of a
stream of bytes. A client and a server can transmit data between each other only after a TCP
connection is set up between them. TCP provides functions such as retransmission upon
timeout, discarding of duplicate data, data checking, and flow control for data delivery from
one end to the other end.
TCP uses a more complicated control mechanism than UDP. In most cases, a link with a
normal TCP rate has a normal UDP rate, but a link with a normal UDP rate does not
necessarily have a normal TCP rate. When diagnosing rate faults, ensure normal UDP rates
before handling TCP services.
3GPP specifications impose uplink capability constraints on user equipment (UE) categories.
Only UEs of category 5 support 64 quadrature amplitude modulation (64QAM) in the uplink.
Possible Causes
A common way to find a cause is as follows: First, check whether the service involved is a
UDP service or a TCP service. If it is a TCP service, inject uplink and downlink UDP packets
on a single thread and check whether the uplink and downlink UDP rates can reach their peak
values. The purpose is to "clear the way" for TCP rate fault diagnosis. For example, eliminate
rate limiting at the network adapter and rectify radio parameter setting errors before handling
TCP rate faults. If the service involved is a UDP service, locate the fault by investigating link
from the server to the UE in an end-to-end manner. Second, if the UDP rate can reach its peak
value but the TCP rate cannot, the fault exists in the TCP transmission mechanism.
Abnormal rates have the following possible causes:
l
Radio interface faults, such as eNodeB alarms related to the radio interface, signal
quality problems, parameter setting errors, problems caused by multiple UEs online,
license issues, and uplink interference (required to be checked for abnormal uplink rates)
Troubleshooting Flowchart
None
Troubleshooting Procedure
1.
108
eRAN11.1
eRAN Troubleshooting Guide
2.
On the server, run the following command to set the UDP packet injection volume:
iperf c x.x.x.x u i 1 t 99999 b yyym
NOTE
b.
c.
(Optional) If the actual output traffic volume from the server does not reach the
specified "yyym", run the following command with "-l" added to adjust the UDP
packet size:
iperf c x.x.x.x u i 1 t 99999 b yyym -l 1000
d.
3.
(Optional) If the actual output traffic volume from the server still fails to reach the
specified "yyym", replace the server.
The transmission bandwidth on the transmission link is greater than the peak value.
If microwave is used for transmission, ensure that the transmission bandwidth is
greater than the peak value.
NOTE
The transmission link refers to the S1 interface from the server to the eNodeB.
4.
Check whether the block error rate (BLER) is excessively high on the radio
interface.
Monitor the BLER on the U2000 client. If the BLER is higher than 10%, the
channel condition is poor. Improve the channel condition for better downlink signal
quality.
109
eRAN11.1
eRAN Troubleshooting Guide
the interference strength is higher than 115 dBm, uplink interference exists and
interference sources need to be checked.
5.
Check whether the basic information about the data services or the parameter settings are
incorrect.
This check is twofold:
Check whether the basic information about the data services is incorrect.
In this step, check the user's subscription information and UE's capability.
Specifically, check whether the user is subscribed to the correct QCI, whether the
MBR and AMBR of the UE are set as expected, and whether the UE is empowered
with expected capabilities.
Check whether the basic information about the parameter settings is incorrect.
The parameter settings refer to the settings for the eNodeB. Algorithm setting
changes cause severe drops in the traffic rate. Export eNodeB parameter settings,
and compare them with the baseline values. If the values are inconsistent, confirm
whether the settings are customized for the operator or have been changed to
incorrect values. If the settings have been changed to incorrect values, inform the
operator immediately.
6.
7.
8.
The license has expired, or limitation is imposed on functions related to the data
services.
9.
110
eRAN11.1
eRAN Troubleshooting Guide
Typical Cases
l
Case 2: UDP services were functional, but FTP services were unavailable.
Fault Description
111
eRAN11.1
eRAN Troubleshooting Guide
Operator T in country D stated that no FTP service was available on eNodeBs operating
in the 1800 MHz band but all cells operated properly with UEs normally accessing the
cells, being released, and performing UDP services.
Fault Diagnosis
Based on the feedback from the operator, a check for TCP errors was performed directly,
only to find that the FTP transfer rate dropped to zero and the server could not be pinged.
Because UDP services ran normally in the downlink, it was almost ascertained that the
fault was down link disconnection.
The check on an 800 MHz eNodeB connected to the same transport network found that
FTP services ran normally. Therefore, it was highly possible that the eNodeBs had faults.
Due to the severe impact of the fault, data configurations were immediately restored for
the 1800 MHz eNodeBs by using the backup data configuration files. The fault was
rectified.
The faulty configuration files were compared with baseline data configurations. The
comparison result indicated that a key radio parameter for downlink and uplink
transmission was set to a value different from the baseline value. The fault was caused
by the incorrect parameter setting.
Fault Handling
Parameter settings were changed to baseline values for all faulty eNodeBs.
l
Case 3: The traffic rate occasionally reached the peak value using the E398 but never
reached the peak value using Samsung UEs.
Fault Description
In a single cell under an eNodeB on network Y in country P, a single Samsung UE could
reach only 80 Mbit/s unexpectedly in both single-thread and multi-thread (using
FileZilla) TCP download. Huawei E398 could occasionally reach 100 Mbit/s in both
single-thread and multi-thread TCP download. Both the Samsung UE and Huawei E398
experienced rate drops.
Fault Diagnosis
A UDP packet injection test was performed, only to find that Huawei E398 and Samsung
UE could both reach the peak values. Therefore, the fault should exist in the TCP
transmission mechanism. In this fault case, rate drops occurred, which was an evidence
of packet loss. The fault symptoms on Huawei E398 and Samsung UE were different, so
there must be causes other than packet loss.
The analysis of TCP/IP headers using a third-party tool indicated that packet loss
occurred on the radio interface. It was found from the configuration file for the eNodeB
that the QoS class identifier (QCI) was 7 and the unacknowledged mode (UM) was used.
UM is insensitive to packet loss, so the frontline personnel tried QCI 9 upon request in a
further test. In the test, rate drops disappeared, but Samsung UE still failed to reach the
peak value in neither single-thread nor multi-thread TCP download while Huawei E398
could reach the peak value in both single-thread and multi-thread TCP download. A
further test was performed on RTT using Samsung UE and Huawei E398. The test result
indicated that the RTT value for Samsung UE was longer and less stable than the RTT
value for Huawei E398. A comparison between the configuration file for the eNodeB on
network Y and the baseline configuration file found a difference in the radio-interface
encryption setting. The Advanced Encryption Standard (AES) encryption algorithm was
enabled for the radio interface on network Y, but this algorithm was disabled in the lab.
The frontline personnel disabled the AES encryption algorithm as requested. Then, the
traffic rate on Samsung UE could reach 100 Mbit/s. The fault could be reproduced: The
rate dropped to 80 Mbit/s after this algorithm was enabled. The reason for Samsung UE's
112
eRAN11.1
eRAN Troubleshooting Guide
failure to reach the peak value was the setting of the AES encryption algorithm on the
radio interface.
Fault Handling
The problem in network Y was caused by more than one fault, which was further
induced by incorrect parameter settings. The problem was resolved after the parameter
settings were corrected.
Fault Description
A key performance indicator (KPI) indicates an abnormal rate according to the routine KPI
monitoring result, or a large number of users complain about their traffic rates.
Related Information
Related Counters
l
L.Thrp.bits.DL
L.Thrp.bits.DL.LastTTI
L.Thrp.Time.DL.RmvLastTTI
L.Thrp.bits.UL
L.Thrp.bits.UE.UL.LastTTI
L.Thrp.Time.UE.UL.RmvLastTTI
L.Traffic.ActiveUser.DL.Avg
L.Traffic.ActiveUser.UL.Avg
Possible Causes
If a large number of users complain about their traffic rates, find the cause by following the
procedure for troubleshooting abnormal single-UE rates. Pay more attention to faults that may
cause large-scope failures, for example, eNodeB faults, transmission failures, large-size
reconfiguration, and radio frequency (RF) faults.
If a KPI indicates an abnormal rate, check whether the KPI calculation formula is correct,
investigate topN cells, analyze the changes of the KPI with other KPIs, review recent key
actions on the network, and if necessary collect and provide KPI logs.
Issue Draft A (2016-03-07)
113
eRAN11.1
eRAN Troubleshooting Guide
Troubleshooting Flowchart
None
Troubleshooting Procedure
1.
2.
3.
4.
5.
Typical Cases
Fault Description
On network T in a country, the routine KPI monitoring result indicated that the average traffic
rate had been decreasing across the network since a day while the number of users remained
almost unchanged.
Fault Diagnosis
The check on the rate calculation formula, counter measurement, and statistics changes found
that network T never changed the formula or measurement method. Therefore, it was not the
formula that caused the fault. The investigation of topN cells found that the entire network
had almost the same trend, so the fault was not caused by abnormal individual cells. The
analysis of other KPIs indicated that the number of users remained almost unchanged. In
addition, network reconfiguration should not cause a gradual decrease. Finally, the review on
recent key actions found two actions: rollback of the evolved packet core (EPC) version and
provisioning of low-rate subscription services. Further analysis was performed on the two
actions.
The analysis found that the EPC version rollback did not affect the traffic rate. In an aggregate
maximum bit rate (AMBR) test in a lab, Transmission Control Protocol (TCP) services were
performed on UEs with AMBRs of 20 Mbit/s and 100 Mbit/s. The KPI monitoring result
indicated that the rate on a UE with an AMBR of 100 Mbit/s was about four times as high as
the rate on a UE with an AMBR of 20 Mbit/s. The investigation of AMBR distribution at
more than ten sites in recent days found that the number of UEs with a subscribed rate of 256
Mbit/s had dropped by more than 70%. A majority of subscribers on the network were lowrate ones. The confirmation with the operator proved that some UEs newly subscribed to low
AMBRs, and some with a subscribed rate of 256 Mbit/s switched to low AMBRs. That was
the cause of the rate decrease.
Issue Draft A (2016-03-07)
114
eRAN11.1
eRAN Troubleshooting Guide
Fault Handling
No handling was required. The rate decrease was caused by the provisioning of low-rate
subscription services.
115
eRAN11.1
eRAN Troubleshooting Guide
116
eRAN11.1
eRAN Troubleshooting Guide
Related Alarms
l
Cell alarms
Transmission alarms
Hardware alarms
ALM-26205 BBU Board Maintenance Link Failure (Applicable to 3900 series base
stations only)
Optical module and CPRI alarms related to the faulty cell (Applicable to 3900 series
base stations only)
RF module alarms related to the faulty cell (Applicable to 3900 series base stations only)
License alarms
Other alarms
117
eRAN11.1
eRAN Troubleshooting Guide
Possible Causes
Cell unavailability may be caused by:
l
Abnormal RF resources
Faulty hardware
Troubleshooting Flowchart
Cell unavailability faults are generally indicated by alarms, MML command outputs, and
logs. Based on the information, you can know which factor leads to a failure in the setup or
running of a cell. The fault handling method provided in this section is used before log
analysis, which is shown in Figure 9-1.
118
eRAN11.1
eRAN Troubleshooting Guide
Troubleshooting Procedure
1.
119
eRAN11.1
eRAN Troubleshooting Guide
2.
3.
4.
If the cell fault occurs during the deployment of an eNodeB or the setup of a cell,
run the ACT CELL command.
If the cell fault occurs in another scenario, run the DSP CELL command.
5.
6.
7.
8.
Fault Description
A cell fails to be set up after data configuration.
Related Information
A cell cannot be set up successfully if the cell parameter settings do not match the actual RF/
baseband processing capability or other parameters.
Issue Draft A (2016-03-07)
120
eRAN11.1
eRAN Troubleshooting Guide
Incorrect data configuration usually leads to a failure in the setup of a cell, not in the running
of a cell.
Related Alarms
l
Possible Causes
A resource item is set to a value inconsistent with the hardware or software configuration,
leading to cell setup failures. Possible causes are listed as follows:
l
Incorrect UL/DL subframe ratio or incorrect special subframe radio in TDD mode
Incorrect CPRI line rate configuration (Applicable to 3900 series base stations only)
Troubleshooting Flowchart
None
Troubleshooting Procedure
1.
2.
3.
Rectify the cell fault based on the MML command outputs about cell activation failures.
For details, see eNodeB Alarm Reference.
4.
121
eRAN11.1
eRAN Troubleshooting Guide
Yes: End.
No: Go to 5.
5.
Typical Cases
None
Fault Description
If the cell unavailability is caused by abnormal transport resources, a message will be
displayed after the ACT CELL or DSP CELL command is executed. The message indicates
that the S1 interface used by the cell or an IP path on the S1 interface is abnormal.
Related Information
None
Possible Causes
The possible causes are:
l
Troubleshooting Flowchart
None
Troubleshooting Procedure
1.
In the output of the DSP CELL command, the value of Cell latest avail state is
Unavailable S1 link.
In the output of the ACT CELL command, the following information is provided:
[0]Configuration data activating failed: (1973485632) Cell S1 link (include S1
interface and IP path) is abnormal.
122
eRAN11.1
eRAN Troubleshooting Guide
2.
3.
4.
5.
6.
7.
Typical Cases
Fault Description
A cell failed to be activated. In the command output, the value of Reason For Latest State
Change was
CCEM_CELLBASIC_ERR_CELL_SETUP_FAIL_S1LINK_DOWN~1973485632.
Fault Diagnosis
1.
Check for active alarms of the site. It was found that there was no alarms related to this
cell.
2.
Run the DSP SCTPLNK command to query the status of the desired SCTP link. The
result showed that the link status was normal.
3.
Run the DSP S1INTERFACE command to query the status of the desired S1 interface.
No result was displayed, indicating that the S1 interface was not configured.
Fault Handling
After OM personnel configured IP paths, the cell fault was rectified.
123
eRAN11.1
eRAN Troubleshooting Guide
Fault Description
RF-related alarms are reported.
Related Information
RF Resource Item
The RF resource items to be checked include:
l
Whether CPRI links between RF units and LBBPs work properly (Applicable to 3900
series base stations only)
Whether RF unit versions match the main control board version (Applicable to 3900
series base stations only)
When the line rates of CPRI links are successfully negotiated (Applicable to 3900 series
base stations only)
Possible Causes
A cell is unavailable if data configuration or hardware configuration of RF resources is
incorrect.
The possible causes are abnormal CPRI links, abnormal RF units, version mismatch between
the main control board and RF units, unsuccessful negotiation of CPRI line rates, and
mismatch between RF networking and data configuration.
Troubleshooting Flowchart
None
Troubleshooting Procedure
1.
Check whether there are alarms related to RF units or RF unit maintenance links.
Yes: Handle the alarms. For 3900 series base stations, see eNodeB Alarm Reference. For
the BTS3202E, see BTS3202E Alarm Reference. For the BTS3911E, see BTS3911E
Alarm Reference.Go to 2.
No: Go to 3.
2.
3.
124
eRAN11.1
eRAN Troubleshooting Guide
4.
5.
Typical Cases
Fault Description
After a cell activation command was executed, Figure 9-2 was displayed. In another case,
after a cell query command was executed, Figure 9-3 was displayed.
Figure 9-2 RRU TX branch is not usable (1)
125
eRAN11.1
eRAN Troubleshooting Guide
Fault Description
A cell fails to be set up if the required capacity or capability is limited on software or
hardware.
Related Information
None
Possible Causes
The hardware or software specification is limited (for example, the licensed capacity or
capability is limited), leading to cell unavailability.
Troubleshooting Flowchart
None
Troubleshooting Procedure
1.
2.
Rectify the cell fault according to the command output. For details about the command
output, check MML help information or related eNodeB documents.
3.
4.
Typical Cases
Fault Description
After the DSP CELL command was executed, Figure 9-4 was displayed.
Issue Draft A (2016-03-07)
126
eRAN11.1
eRAN Troubleshooting Guide
Figure 9-4 Command output indicating a failure to obtain the licensed number of cells
127
eRAN11.1
eRAN Troubleshooting Guide
Fault Description
Board fault alarms are reported. Alternatively, cell unavailability faults cannot be rectified
after resetting, powering off, or reinstalling faulty boards.
Related Information
None
Possible Causes
A cell may not be set up if a fault occurs in the main control board, LBBP, RF unit, other
hardware (for example, a subrack).
Troubleshooting Flowchart
None
Troubleshooting Procedure
1.
Check whether the board status is abnormal and whether the board versions are
mismatched.
For 3900 series base stations, run the DSP BRD or DSP BRDVER command for query.
Pay more attention to RF units.
For the BTS3202E/BTS3911E, run the DSP BRU or DSP BRDVER command for
query. Pay more attention to RF units.
Yes: Rectify the board faults. Go to 2.
No: Go to 3.
2.
3.
4.
5.
(Optional) Reset the RF unit, and boards, such as the LBBP, or main control board.
For 3900 series base stations, run the RST BRD or RST ENODEB command.
For the BTS3202E/BTS3911E, run the RST BRD or RST BTSNODEB command.
6.
7.
(Optional) Power off the RF unit and LBBP. (Applicable to 3900 series base stations
only)
Run the OPR BRDPWR command.
128
eRAN11.1
eRAN Troubleshooting Guide
8.
9.
Typical Cases
None
129
eRAN11.1
eRAN Troubleshooting Guide
10
Troubleshooting IP Transmission
Faults
130
eRAN11.1
eRAN Troubleshooting Guide
Related Alarms
The following alarms may be reported to indicate Internet Protocol (IP) transmission faults:
l
131
eRAN11.1
eRAN Troubleshooting Guide
Troubleshooting Flowchart
Figure 10-1 Troubleshooting flowchart for IP transmission faults
Troubleshooting Procedure
1.
Check whether an alarm indicating the Ethernet link fault is reported in the active alarms
on the eNodeB. If an alarm indicating the Ethernet link fault is reported, rectify the fault.
If no alarm indicating the Ethernet link fault is reported, go to 2.
2.
Ping the IP address nearest to the local end or the network segment IP address. If the IP
address nearest to the local end or the network segment IP address cannot be pinged,
there is an IP data link layer fault. Rectify the fault. If the IP address nearest to the local
end or the network segment IP address can be pinged, go to 3.
3.
Ping an IP address that is in the same network segment as the local IP address and ping
the destination IP address. If the IP address in the same network segment can be pinged
but the destination IP address cannot be pinged, there is an IP layer link fault. Rectify the
fault. If both IP addresses can be pinged, go to 4.
4.
132
eRAN11.1
eRAN Troubleshooting Guide
Fault Description
An alarm indicating an Ethernet link fault can be monitored among active alarms on the
eNodeB.
Related Information
None
Possible Causes
The Ethernet cable or optical module has faults.
Troubleshooting Flowchart
None
Troubleshooting Procedure
1.
2.
Indicator Status
Check cables.
133
eRAN11.1
eRAN Troubleshooting Guide
i.
Check and record the bandwidth (100 Mbit/s or 1000 Mbit/s) supported by the
personal computer (PC) used.
ii.
Disconnect the Ethernet cable from the eNodeB and connect it to the PC and
check whether the ports used to connect the PC and the switch are up. If the
ports are up, check and record the bandwidth (100 Mbit/s or 1000 Mbit/s)
negotiated between the PC and the switch.
Check whether the optical modules are securely inserted. If they are not
securely inserted, reinsert them. Check information about the optical module
manufacturer, rate, mode (single-mode or multi-mode), wavelength, and
communication distance. It is recommended that the eNodeB and peer device
use optical modules provided by the same manufacturer and with the same
rate.
ii.
iii. Check whether the optical module is damaged by inserting two ends of one
optical cable to the optical module. Check whether an alarm indicating an
optical module fault is reported on the LMT. If no alarm indicating an optical
module fault is reported, the optical module is normal. If an alarm indicating
optical module fault is reported, replace the optical module.
3.
Check configurations.
Log in to the eNodeB and run the LST ETHPORT and DSP ETHPORT commands to
check the Ethernet port configuration, especially the Port Attribute, Speed, and
Duplex.
The Port Attribute indicates whether an Ethernet port is an electrical port or optical
port. The port attribute can be set to AUTO. If the Port Attribute is set to Fiber, but an
electrical port is used, the port status should be down. Other parameters can be checked
in a similar way.
The rate and duplex mode must be configured the same on the eNodeB and the switch. If
they are not configured the same on the eNodeB and the switch, the port negotiation fails
or the port negotiation succeeds but packets are lost. The Gigabit Ethernet (GE) electrical
port on the eNodeB can be set to AUTO only. If the GE electrical port on the eNodeB is
used to connect to the switch, the port attribute must be set to AUTO on both the
eNodeB and the switch.
The following parameter settings are recommended.
Port Type
100M/FULL
100M/FULL
FE electrical or optical
port
AUTO/AUTO
AUTO/AUTO
GE electrical port
AUTO/AUTO
AUTO/AUTO
GE optical port
100M/FULL
100M/FULL
GE optical port
AUTO/AUTO
AUTO/AUTO
134
eRAN11.1
eRAN Troubleshooting Guide
Change the parameter settings on the eNodeB to check the configurations on the switch.
Change both the rate and duplex mode to AUTO. If port negotiation succeeds after the
change and the DSP ETHPORT command output is the same as expected, the rate and
duplex mode are both set to AUTO on the switch. If the port negotiation fails, the rate
and duplex mode are not set to AUTO on the switch. Analyze the possible configuration
on the switch based on the DSP ETHPORT command output and change the
configuration on the eNodeB accordingly.
4.
Connect a PC to the Ethernet port on the eNodeB and check whether the alarm is
cleared.
b.
Connect a PC to the Ethernet port on the switch and check whether the PC indicator
is on.
c.
If the alarm is cleared and the PC indicator is off, the Ethernet port on the
switch is faulty. Go to 4.d.
If the alarm persists and the PC indicator is on, the Ethernet port on the
eNodeB is faulty. Go to 4.e.
If the alarm is cleared and the PC indicator is on, the Ethernet ports on the peer
device and the eNodeB are not fully electrically compatible. Go to 4.f.
d.
e.
Run the RST ETHPORT and RST BRD commands to reset the Ethernet port and
the board, respectively.
Check whether an alarm indicating a board chip fault is reported. If an alarm
indicating a board chip fault is reported, replace the board on which the Ethernet
port is located.
f.
5.
Check the parameters negotiated between the Ethernet ports on the switch and the
eNodeB.
Typical Cases
None
Fault Description
Signaling messages and service data cannot be transmitted between communication devices.
The peer device cannot be pinged.
135
eRAN11.1
eRAN Troubleshooting Guide
Related Information
None
Possible Causes
l
The Ethernet port negotiation mode is inconsistent between the eNodeB and the peer
device.
Fault Diagnosis
Check whether the ARP and VLAN mechanisms work properly. Before transmitting an
Internet Control Message Protocol (ICMP), Stream Control Transmission Protocol (SCTP), or
User Datagram Protocol (UDP) packet, the eNodeB queries the next-hop media access control
(MAC) address in the ARP table based on the IP route. The eNodeB transmits the packet only
if an ARP table is configured on the eNodeB. If no ARP table is configured, the eNodeB
broadcasts an ARP request for the next-hop MAC address.
Troubleshooting Procedure
1.
2.
3.
136
eRAN11.1
eRAN Troubleshooting Guide
configurations are inconsistent, modify the VLAN configuration on the eNodeB and
perform the check again.
NOTE
If the VLAN information in the ARP message is correct, the eNodeB is normal. Confirm
with the customer the VLAN configuration and port type of the peer device and the
reason why the peer device does not respond.
4.
Typical Cases
None
Fault Description
The peer device cannot be pinged and an IP address in the same network segment as the
eNodeB can be pinged. Alarms indicating an SCTP link fault, cell unavailability, and a path
fault are reported by the upper layer.
Related Information
None
Possible Causes
l
Fault Diagnosis
In most cases, the cause is that routes are unavailable. If the ARP table and VLAN are
normal, troubleshoot the fault as described in the next section.
Troubleshooting Procedure
1.
2.
3.
137
eRAN11.1
eRAN Troubleshooting Guide
Run the STR PORTREDIRECT command on the eNodeB to start port mirroring to
trace the protocol and packet header.
4.
Typical Cases
None
138
eRAN11.1
eRAN Troubleshooting Guide
11
139
eRAN11.1
eRAN Troubleshooting Guide
Troubleshooting Flowchart
Figure 11-1 shows the troubleshooting flowchart for IP transport and application layer faults.
140
eRAN11.1
eRAN Troubleshooting Guide
Figure 11-1 Troubleshooting flowchart for IP transport and application layer faults
Troubleshooting Procedure
1.
Check whether an alarm indicating a Stream Control Transmission Protocol (SCTP) link
fault is reported or whether the SCTP link status is abnormal.
Yes: Troubleshoot the SCTP link fault.
No: Go to 2.
2.
Check whether an alarm indicating an Internet Protocol (IP) path fault is reported or
whether the IP path status is abnormal.
Yes: Troubleshoot the IP path fault.
No: Go to 3.
3.
Check whether an alarm indicating an operation and maintenance (OM) channel fault is
reported or whether the OM channel status is abnormal.
Yes: Troubleshoot the OM channel fault.
No: Go to 4.
4.
141
eRAN11.1
eRAN Troubleshooting Guide
Fault Description
l
Related Information
To rectify SCTP link faults, you need to trace SCTP messages.
SCTP message blocks include 13 types of messages such as INIT, INIT ACK, DATA, SACK,
ABORT, SHUTDOWN, ERROR, COOKIEECHO, and HEARTBEAT.
Parameters such as the first peer IP address, the second peer IP address (used in SCTP dual
homing), and peer port number configured on the eNodeB must be consistent with those
configured on the mobility management entity (MME). Run the LST SCTPLNK command.
In the command output, the parameters in red rectangles are eNodeB parameters and the
parameters in the blue rectangles are evolved packet core (EPC) parameters. Ensure that the
MME parameters configured on the eNodeB are consistent with the SCTP parameters of the
MME and that eNodeB parameters configured on the EPC are consistent with the SCTP
parameters of the eNodeB.
142
eRAN11.1
eRAN Troubleshooting Guide
On the MME, check whether the peer port number configured on the MME is the same as the
local port number configured on the eNodeB and whether a correct network segment is
configured.
Possible Causes
l
Troubleshooting Flowchart
None
Issue Draft A (2016-03-07)
143
eRAN11.1
eRAN Troubleshooting Guide
Troubleshooting Procedure
l
Typical Scenario
To find the cause for an SCTP fault, perform the following steps:
a.
Check configurations.
Check whether SCTP parameters are correctly configured on the MME and the
eNodeB.
b.
c.
d.
e.
l
b.
c.
d.
144
eRAN11.1
eRAN Troubleshooting Guide
that on the peer device. If it is consistent, ping the peer device to check the packet
loss rate on the transmission network.
e.
f.
g.
Typical Cases
None
Fault Description
l
The S1 interface is normal and cells are successfully activated, but UEs cannot attach to
the network.
UEs can attach to the network but cannot set up bearers of some QoS class identifiers
(QCIs). QoS is short for quality of service.
Related Information
The related alarm is as follows:
l
Possible Causes
l
No packet filtering criteria for IP paths is included in access control list (ACL) rules.
The user-plane bearer link detection fails because the packet filtering function is enabled
on the eNodeB.
The user-plane bearer link detection fails because network or peer device configurations
are incomplete.
145
eRAN11.1
eRAN Troubleshooting Guide
Troubleshooting Flowchart
None
Troubleshooting Procedure
1.
Check whether ALM-25886 IP Path Fault or ALM-25952 User Plane Path Fault is
reported.
Yes: Clear the alarm by referring to eNodeB Alarm Reference.
2.
3.
4.
Contact EPC engineers and check whether the P-GW supports GTP-U detection. If the
P-GW supports the detection, check whether the P-GW is incorrectly configured. If the
P-GW does not support the detection, the detection must be disabled on the eNodeB.
5.
Typical Cases
None
Fault Description
The ALM-25901 Remote Maintenance Link Failure alarm is reported.
Operation and maintenance (OM) channel faults are classified into two categories:
l
Related Information
None
Possible Causes
l
146
eRAN11.1
eRAN Troubleshooting Guide
Troubleshooting Flowchart
None
Troubleshooting Procedure
This section describes how to handle an OM channel fault in various scenarios.
l
Typical Scenario
a.
Check configurations.
Check whether OM channel parameters are correctly configured on the U2000
client and the eNodeB.
b.
If ping operations are prohibited in the operator network, do not ping the U2000 client.
c.
d.
l
b.
c.
d.
147
eRAN11.1
eRAN Troubleshooting Guide
link tests but were not removed promptly. As a result, loopbacks require careful
investigation.
e.
f.
Typical Cases
None
148
eRAN11.1
eRAN Troubleshooting Guide
12
Troubleshooting Transmission
Synchronization Faults
149
eRAN11.1
eRAN Troubleshooting Guide
Fault Description
External reference clocks for eNodeBs include GPS, synchronous Ethernet, clock over IP,
BITS, E1/T1, and TOD clocks. Any abnormality in a reference clock will cause the eNodeB
incapable of locking the reference clock. The clock status can be checked by running the DSP
CLKSTAT command.
l
The value of Current Clock Source State indicates that the reference clock is abnormal,
for example, the reference clock is lost.
150
eRAN11.1
eRAN Troubleshooting Guide
The value of PLL Status indicates that the PLL status is abnormal, for example, the
reference clock is in free-run mode or there is excessive frequency deviation.
The value of Clock Synchronization Mode indicates that the clock synchronization
mode is not set to a specified mode.
Related Information
l
b.
Several hours later, stop the clock quality check by running the STP CLKTST
command.
c.
Check the clock quality test result by running the DSP CLKTST command.
Possible Causes
l
The external reference clock is abnormal, for example, there is excessive frequency
deviation.
The clock source is incorrectly selected, which leads to a clock lock failure.
Troubleshooting Flowchart
None
Troubleshooting Procedure
1.
b.
c.
AUTO indicates that the eNodeB automatically selects a reference clock based
on the status, priorities, and link available status of reference clocks.
Check whether the external clock resources of the eNodeB work properly.
151
eRAN11.1
eRAN Troubleshooting Guide
To check the status of an external clock source, run the DSP CLKSRC command. Pay
attention to the following two parameters:
License Authorized
Generally, the value of this parameter indicates that the clock source can be used. If
the value indicates that the clock source cannot be used, enable the eNodeB
synchronization function.
To check whether the eNodeB synchronization function is enabled, run the DSP
LICENSE command. If the Allocated, Config, and Actual Used fields of the
Enhanced Synchronization control item are all 1, the function is enabled.
Non-IP clock
The physical connection between the reference clock and the eNodeB is
normal, and the eNodeB can properly receive clock signals sent by the
reference clock.
IP clock
The route from the eNodeB to the IP clock server is correct, and the eNodeB
can properly receive clock signals sent by the IP clock server.
If the clock source state or the link available state is unavailable, investigate the
reason.
3.
Check whether the eNodeB can properly receive clock signals. For a non-IP
clock, clock signals are generated at the physical layer, and therefore you can
check only on the equipment that sends the clock signals whether they are
correctly sent. For an IP clock, you can check whether clock packets are
correctly received by performing a trace task on the U2000 or by analyzing
packet headers on the nearest transmission equipment. The clock source state
and link available state of an IP clock can be determined based on the
characteristics of received clock packets. For details about the analysis, see the
PTP clock packet analysis procedure in the next step.
If the clock working mode is set to MANUAL using the SET CLKMODE
command, the reference clock is the manually selected clock source.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
152
eRAN11.1
eRAN Troubleshooting Guide
4.
If the clock working mode is set to AUTO using the SET CLKMODE command,
the reference clock is the one automatically selected. The query command is DSP
CLKSTAT.
If the link availability status of the selected clock source is Available but the link
activation status is Unactivated, the reference clock is the one manually selected
after the clock working mode is set to MANUAL using the SET CLKMODE
command.
Current Clock Source: It indicates the clock source to be traced by the eNodeB.
PLL Status: The initial status should be Fast Tracking, and then Locked.
Non-IP clock
For a non-IP clock source, if the link available state is available and the link
active state is activated in step 3, the states queried by running DSP CLKSTAT
must be normal.
The only risk is that the eNodeB enters free-run mode (instead of locked
mode) after a period of fast tracking. The eNodeB adjusts the local oscillator
during fast tracking, but the difference between the local oscillator and
external clock sources is still above the locking threshold. Therefore, the
eNodeB cannot lock an external clock source and enters free-run mode.
In this case, perform a clock quality test to check the frequency deviation
values, and report them to Huawei technical support.
IP clock
For an IP clock, even if the clock link is available and activated, it cannot be
guaranteed that all check items are normal. The query command is DSP
CLKSTAT. The reason is that whether the eNodeB can lock an external clock
source depends on two packets (Sync and Delay_Resp) as well as the clock
information the packets carry.
In this situation, take two actions: (1) Collect clock packets received by the
eNodeB on the U2000 or collect headers of the packets on the nearest
transmission equipment; (2) Perform a clock quality test on the IP clock in the
same way as that for a non-IP clock. Then, send the packets (or packet
headers) and quality test result to Huawei technical support.
5.
Typical Cases
None
153
eRAN11.1
eRAN Troubleshooting Guide
13
154
eRAN11.1
eRAN Troubleshooting Guide
Internet key exchange (IKE) negotiation failure: An IKE security association (SA) fails
to be set up between the eNodeB and the SeGW.
IPSec tunnel setup failure: The IKE SA between the eNodeB and the SeGW is normal,
but the IPSec SA carried by the IKE SA fails to be set up.
Certificate application failure: An IKE negotiation fails because the eNodeB fails to
obtain a digital certificate.
Encapsulation between two eNodeBs: Data streams between two eNodeBs are
encapsulated in transport mode.
Encapsulation between an eNodeB and an SeGW: Data streams (except those between
the SeGW and the EPC) are encapsulated in tunnel mode.
Encapsulation between an eNodeB and the EPC: Data streams over the S1 interface are
encapsulated in transport mode.
155
eRAN11.1
eRAN Troubleshooting Guide
Transmission security faults occur in most cases where security link negotiation between the
eNodeB and the security gateway fails. Parameters affecting the negotiation include IKE
parameters and IPSec parameters. IKE parameters include the ciphering algorithm,
verification algorithm, IKE version, identity authentication mode, and shared key. IPSec
parameters include the ciphering mode, ciphering algorithm, authentication algorithm, and
authorization mode. For details, see eRAN Transmission Security Feature Parameter
Description.
Fault Description
When a transmission security fault occurs:
l
The eNodeB is out of control, and all operation commands cannot be delivered from the
U2000 to the eNodeB.
The eNodeB is under control, but transmission-related alarms are displayed on the Web
LMT.
Related Information
l
Related Alarms
Possible Causes
Possible causes are:
l
Transmission security parameters are mismatched between the local and peer ends,
which leads to IPSec tunnel negotiation failures.
Security tunnel update fails due to certificate update failures or certificate expiry.
Troubleshooting Flowchart
Transmission security faults are generally due to data configuration. Therefore, data
consistency check between the eNodeB and the SeGW is crucial to troubleshooting.
Issue Draft A (2016-03-07)
156
eRAN11.1
eRAN Troubleshooting Guide
Troubleshooting Procedure
1.
157
eRAN11.1
eRAN Troubleshooting Guide
NOTE
This section uses the 3900 series base station as an example. The value of Slot No. is 0 for the
BTS3202E/BTS3911E in the example.
2.
If no binding relationship is found, bind an IPSec policy group to the port. Run the
ADD IPSECBIND command, and specify values for the mandatory parameters
such as the slot No., subboard type, port type, port No., and IPSec policy group
name. To learn about the IPSec policy group name, run the LST IPSECPOLICY
command.
158
eRAN11.1
eRAN Troubleshooting Guide
Whether the settings of the Version and Exchange Mode parameters on the
eNodeB are consistent with those on the gateway.
159
eRAN11.1
eRAN Troubleshooting Guide
3.
160
eRAN11.1
eRAN Troubleshooting Guide
b.
c.
Check whether the certificates used for IKE and SSL are correct.
Run the DSP APPCERT command. Pay more attention to the information in the
red frame. If a used certificate is incorrect, run the MOD APPCERT command to
change it.
Figure 13-8 List certificates used for IKE and SSL
4.
161
eRAN11.1
eRAN Troubleshooting Guide
5.
6.
162
eRAN11.1
eRAN Troubleshooting Guide
7.
Typical Cases
The following describes how to troubleshoot an IKE negotiation failure.
Fault Description
An IPSec policy group was bound to a port, but an IPSec tunnel failed to be set up between
the eNodeB and the SeGW.
Fault Diagnosis
1.
163
eRAN11.1
eRAN Troubleshooting Guide
The output of the DSP IKESA command indicated that the IKE SA status in phase 1
was Ready or Ready|StayAlive, but the status in phase 2 was None. IPSec-related
parameter settings were checked and were found to be the same as those on the SeGW.
2.
3.
OM personnel checked the IKE_AUTH messages sent from the SeGW to the eNodeB.
The notification payload in the messages was NO_PROPOSAL_CHOSEN. This
indicated that the SeGW failed to obtain the required IPSec proposal and therefore this
round of IKE authentication negotiation failed. The SeGW sent these messages to notify
the eNodeB of this failure.
NOTE
The eNodeB considered the encrypted notification messages invalid and therefore discarded these
messages.
Fault Handling
This fault was due to the configuration on the peer equipment. After the message transmission
rule on the peer equipment was modified, the fault was rectified.
164
eRAN11.1
eRAN Troubleshooting Guide
14
165
eRAN11.1
eRAN Troubleshooting Guide
VSWR Test
During a VSWR test on a radio frequency (RF) unit, power of the RF unit is first coupled as
forward power and backward power by using directional couplers, and then they are measured
by using standing-wave detectors. The difference between the measured forward power and
backward power is the return loss, which can be converted to a VSWR value by using related
formulas. The VSWR value is used to determine whether a VSWR alarm is reported.
Figure 14-1 Principle of a VSWR test
The VSWR test result indicates the connection condition between the RF unit and the antenna
system. If a large VSWR value is obtained, the antenna system is improperly connected to the
RF unit. The output power of the RF unit is not transmitted through the antenna but reflected
back. A high reflected power damages the RF unit, and the total reflection may break down
the unit. To avoid the preceding faults, the VSWR alarm post-processing switch must be
turned on for a remote radio unit (RRU) to be added. In this way, if a major VSWR alarm is
generated, the RRU automatically shuts down the faulty transmit (TX) channels and then does
not provide output power. In this scenario, the cell served by the RRU degrades the capacity
or becomes unavailable. The cell coverage and performance also deteriorate.
Issue Draft A (2016-03-07)
166
eRAN11.1
eRAN Troubleshooting Guide
NOTE
If a major VSWR alarm is generated, the faulty TX channels are automatically shut down. If you have
rectified the related faults, you can run the STR VSWRTEST command or manually modify the TX
channel configuration to open the TX channels. However, the VSWR alarm still exists. It will be cleared
only after the RRU is reset.
PIM Interference
PIM interference is induced by non-linearity of the passive components in the TX system.
The antenna non-linearity is indicated by the intermodulation (IM) suppression degree. For a
linear system, if the input is two signals, the output is also two signals without any additional
frequency component. For a non-linear system, if the input is two signals, new frequency
components are generated in the system and added to the output, and then the output is more
than two signals. The added frequency components are known as the IM products. The
process of generating frequency components is called IM. If the IM products work on
frequencies within the receive (RX) frequency band and accordingly increase the uplink
interference or received total wideband power (RTWP), IM interference is generated. In a
high-power and multi-channel system, non-linearity of the passive components generates
high-order IM products. These IM products and the operating frequency are mixed to from a
group of new frequencies, and accordingly a group of useless spectra is generated and affects
the normal communication.
In a linear system, assume that the two input signals work on the frequencies of f1 and f2.
Then, IM components are generated, such as two IM3 components operating on the
frequencies of (2 x f1 - f2) and (2 x f2 - f1), and two IM5 components operating on the
frequencies of (3 x f1 - 2 x f2) and (3 x f2 - 2 x f1). As shown in the following figure, the
input signals and IM components are marked in green and red, respectively. The IM order of
an IM component (m x f2 - n x f1) is the sum of m and n. These IM components are generated
symmetrically on the left and right of the wanted signals. Their intervals depend on the IM
orders and the maximum frequency spacing (or bandwidth) of the input signals. A higher IM
order leads to a lower amplitude for the IM components and a further distance from the
wanted signals, and therefore a smaller impact.
The following figure shows an example of a PIM result.
167
eRAN11.1
eRAN Troubleshooting Guide
168
eRAN11.1
eRAN Troubleshooting Guide
External Interference
Electromagnetic waves are propagated through space in certain directions in the electric field.
Based on the directions (also known as polarization), the electromagnetic waves are classified
into linear polarized waves and circular polarized waves. Antennas with different polarization
can obtain various gains from linear polarized waves.
eNodeBs use orthogonal 45 dual-polarized antennas. Therefore, linear polarized waves
received by these antennas have main and diversity gain differences.
Interference signals can also be classified based on the polarization:
l
In some cases, external interference may also lead to RTWP imbalance alarms.
For example, linear polarized radio signals from a radar or navigation satellite high up in the
air are propagated without multiple reflections. When the eNodeB receives such interference
signals, the orthogonal dual-polarized antennas can obtain various gains based on the angle
between the interference signals and the antenna polarization. If the interference signals exist
for a long time, an RTWP imbalance alarm can be generated.
To determine whether external interference exists, perform the following steps:
1.
169
eRAN11.1
eRAN Troubleshooting Guide
2.
Two interference signals received by a receiver are correlated but with different power.
They have the same impact on the RTWP.
170
eRAN11.1
eRAN Troubleshooting Guide
Figure 14-3 Structure and working principles of an RET antenna equipped with an RCU
171
eRAN11.1
eRAN Troubleshooting Guide
Troubleshooting Flowchart
Figure 14-4 Troubleshooting flowchart for RF unit faults
Troubleshooting Procedure
1.
Check whether there is any alarm related to voltage standing wave ratio (VSWR) faults
in the active alarms on the eNodeB or there is any abnormal VSWR test result. If yes,
troubleshoot the VSWR faults. If no, go to 2.
2.
Check whether there is any alarm related to RTWP faults in the active alarms on the
eNodeB. If yes, troubleshoot the RTWP faults. If no, go to 3.
3.
(Applicable to 3900 series base stations only) Check whether there is any alarm related
to ALD link faults in the active alarms on the eNodeB or there are any abnormal ALD
links. If yes, troubleshoot the ALD link faults. If no, go to 4
4.
Fault Description
An alarm ALM-26529 RF Unit VSWR Threshold Crossed is reported if there are VSWR
faults in the radio frequency (RF) channels of an RF unit.
Issue Draft A (2016-03-07)
172
eRAN11.1
eRAN Troubleshooting Guide
Related Information
None
Possible Causes
l
The frequency band supported by the RF unit is inconsistent with that supported by the
components of the antenna system.
A VSWR-related circuit fault occurs in the RF unit, or other hardware faults occur in the
RF unit.
Troubleshooting Flowchart
None
Troubleshooting Procedure
1.
2.
3.
Run the DSP VSWR command to query the current VSWR value.
NOTE
The execution of the STR VSWRTEST command interrupts services carried by the RF unit.
Run the STR VSWRTEST command to query the offline VSWR value.
NOTE
It is recommended that multiple frequencies within the operating frequency range supported
by the cell be used as the test frequencies.
4.
Compare the VSWR values queried by running the STR VSWRTEST and DSP VSWR
commands.
If the two values are the same and are greater than the threshold for reporting VSWR
alarms, onsite investigation is required. Go to 5.
If the values differ greatly, run the STR VSWRTEST command with the Test Mode
parameter set to MULTI_ARFCN and compare the VSWR values.
173
eRAN11.1
eRAN Troubleshooting Guide
5.
If the values are the same, the feeder between the RF unit and the antenna system
may be insecurely connected and accordingly the queried VSWR values are not
stable. In this case, check the feeder connection at the local end. Then, go to step 4.
For 3900 series base stations, if some of the values are large, a hardware fault may
occur in the RF unit. Save the test results and submit the results together with oneclick log files of the main control board and RF unit to Huawei technical support for
further analysis.
For the BTS3202E/BTS3911E, if some of the values are large, a hardware fault may
occur in the BTS3202E/BTS3911E. Save the test results and submit the results
together with one-click log files to Huawei technical support for further analysis.
6.
Typical Cases
None
Fault Description
An RTWP-related alarm is reported if there are received total wideband power (RTWP) faults
in the radio frequency (RF) channels of an RF unit.
Related Information
Related alarms are as follows:
l
Possible Causes
l
174
eRAN11.1
eRAN Troubleshooting Guide
Troubleshooting Flowchart
Figure 14-5 Troubleshooting flowchart for RTWP faults
Troubleshooting Procedure
1.
Run the LST ALMAF command to check whether alarms related to ALD or TDM
are reported (applicable only to 3900 series base stations). If such an alarm is
reported, clear the alarm by referring to Troubleshooting ALD Link Faults.
b.
175
eRAN11.1
eRAN Troubleshooting Guide
Command output for 3900 series base stations (The values of Cabinet No.,
Subrack No., and Slot No. are 0 for the BTS3202E/BTS3911E.)
List RxBranch Configure Information ----------------------------------Cabinet No. = 0 Subrack No. = 62 Slot No. = 0 RX Channel No. = 0
Logical Switch of RX Channel = ON Attenuation(0.5dB) = 0 RTWP
Initial0(0.1dB) = 0 RTWP Initial1(0.1dB) = 0 RTWP Initial2(0.1dB)
= 0 RTWP Initial3(0.1dB) = 0 RTWP Initial4(0.1dB) = 0 RTWP
Initial5(0.1dB) = 0 RTWP Initial6(0.1dB) = 0 RTWP Initial7(0.1dB)
= 0 (Number of results = 1)
c.
2.
Run the ADD CELLSIMULOAD command to add a simulated load. For example,
ADD CELLSIMULOAD: LocalCellId=x, SimLoadCfgIndex=9;
The simulated load and transmit power have a positive correlation with the value of
the SimLoadCfgIndex parameter.
NOTE
Note that load simulation is mainly used in interference tests. You are advised not to use load
simulation for a cell with more than six active UEs. Otherwise, the scheduling performance
cannot be ensured.
b.
176
eRAN11.1
eRAN Troubleshooting Guide
If PIM interference exists according to the preceding investigation, use either of the
following methods to determine the location or device where PIM is introduced:
Add a simulated load and shake the cable segments by segments from the RF unit
top to the antenna port. If RSSI values change dramatically when shaking a
segment, PIM interference is introduced by this segment.
177
eRAN11.1
eRAN Troubleshooting Guide
If the interference is caused by the RF unit, replace the RF unit. If the interference is
caused by the cable, replace the cable and then check whether the interference still exists.
If the interference is removed, no further action is required.
If the interference persists, check whether the interference exists in the antenna.
3.
Monitor the results in Broadband on-line frequency scan for at least 30 minutes or
until the 26522 RF Unit RX Channel RTWP/RSSI Unbalanced alarm is reported.
Then, send the local tracing results, running logs of RF units, and investigation results to
Huawei technical support for fault diagnosis.
For the procedure for performing Broadband on-line frequency scan, see Monitoring
eNodeB Performance in Real Time > Spectrum Detection in 3900 Series Base Station
LMT User Guide.
4.
Check whether a crossed pair connection exists (applicable only to 3900 series base
stations).
Description
RF channels in an RF unit must be used by the same sector except in MIMO mutual-aid
scenarios. The purpose is to ensure the consistency between the direction and coverage
of an antenna so that balanced RTWP values are obtained. If the RF channels of an RF
unit are used by different sectors, the RF unit will have different RTWP values. Note that
the ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced alarm is reported
only when the number of UEs is significantly different between two cells with a crossed
pair connection.
The ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced alarm caused by a
crossed pair connection has the following characteristics:
178
eRAN11.1
eRAN Troubleshooting Guide
The alarm is reported in at least two sectors under the same eNodeB.
Troubleshooting Method
The cells with a crossed pair connection can be determined by using either of the
following two methods:
Perform drive tests and trace signaling without interrupting the services.
Make a phone call in a cell (for example, cell 1). Check whether the UE accesses
cell 1, where the UE is located. If the UE accesses another cell (for example, cell 3),
the antennas of cells 1 and 3 are cross-connected.
Run the STR CROSFEEDTST command to start a crossed pair connection test.
If the antenna system is not equipped with an external filter, the Start Test
Frequency and End Test Frequency parameters do not need to be specified. The
test will be performed in the test frequency band supported by the RF unit. If the
antenna system is equipped with an external filter, specify the Start Test
Frequency and End Test Frequency parameters to the start frequency and end
frequency, respectively, for the external filter.
NOTE
The Crossed value of RESULT appears in pairs. If RESULT is Crossed for two
sectors, a cross pair connection exists between the two sectors. Detailed information
about the sectors with a crossed pair connection is displayed in the detection result.
The result is similar to the following:
To start a cross feeder test, run the following command: STR
CROSFEEDTST:; The result is shown as follows: +++
HUAWEI
2012-02-02 10:54:58 O&M
#453 %%STR CROSFEEDTST:;%% RETCODE = 0
Operation succeeded. Session ID = 65537 (Number of results = 1) --END +++
HUAWEI
2012-02-02 10:55:15 O&M
#452 %%STR
CROSFEEDTST:;%% RETCODE = 0 Progress report, Operation succeeded.
Report Type = Cross Feeder Test Progress Status = Success Session
179
eRAN11.1
eRAN Troubleshooting Guide
Handling Suggestion
After the sectors with a crossed pair connection are determined, adjust their antenna
connection. Since there are three types of crossed pair connections (main-main, maindiversity, and diversity-diversity), several rounds of antenna adjustment may be required
before the test result verifies no crossed pair connection.
5.
6.
Typical Cases
None
Fault Description
An ALD-related alarm is reported if there are antenna line device (ALD) link faults in the
radio frequency (RF) channels of an RF unit.
Related Information
Related alarms are as follows:
l
Possible Causes
Possible causes for ALD-related alarms are listed as follows:
l
180
eRAN11.1
eRAN Troubleshooting Guide
Troubleshooting Flowchart
None
Troubleshooting Procedure
1.
Check for related alarms and configuration issues. If ALM-26541 ALD Maintenance
Link Failure, ALM-26751 RET Antenna Motor Fault, or ALM-26753 RET Antenna Not
Calibrated is generated, you can use the IUANT trace function on the web LMT of the
eNodeB to collect the interaction information between antenna line devices (ALDs) and
RF modules for root cause locating and classification.
2.
Typical Cases
None
181
eRAN11.1
eRAN Troubleshooting Guide
15
182
eRAN11.1
eRAN Troubleshooting Guide
Problems that may be encountered during license application are not described in this document. For
details, see eRAN License Management Feature Parameter Description.
Possible Causes
The possible causes of license faults are as follows:
l
Incorrect operations
Product defects
Troubleshooting Flowchart
The following figure shows the troubleshooting flowchart for license faults that occur in
different scenarios.
183
eRAN11.1
eRAN Troubleshooting Guide
Troubleshooting Procedure
1.
Determine whether license faults occur during license installation. If so, perform the
procedure for troubleshooting license faults that occur during license Installation. If not,
go to 2.
2.
Determine whether license faults occur during network running. If so, perform the
procedure for troubleshooting license faults that occur during network running. If not, go
to 3.
3.
Determine whether license faults occur during network adjustment. If so, perform the
procedure for troubleshooting license faults that occur during network adjustment. If not,
go to 4.
4.
Fault Description
If license installation fails, the following error messages will be displayed in the MML
command output:
Issue Draft A (2016-03-07)
184
eRAN11.1
eRAN Troubleshooting Guide
License check failed; license serial number became invalid; the license file does not
match the product; the license versions do not match.
The license control items do not match; the configured value exceeds the value in the
license file or the validity date of the control item is earlier than that in the license file.
Related Information
During license installation, the eNodeB checks the license. The check items are as follows:
l
Integrity check: Whether the product name in the license file matches the software name;
whether the checks on full-text signature, Service field signature, and feature signature
are successful.
Accuracy check: Whether the equipment serial number (ESN) in the Service field
matches the ESN of the equipment; whether the VR version number in the Service field
matches the VR version of the software.
Validity period check: Whether the license for the feature exceeds the validity date;
whether the license for the feature exceeds the validity date and protection period.
Difference check: Differences between new and old license files, including whether any
function items in the new license files are lost, whether any resource items are reduced or
lost, and whether the validity period for the feature becomes short.
If the accuracy check fails (the ESNs or the VR versions do not match), users need to
confirm whether to continue with the installation. If users choose to continue with the
installation, the feature defined in the license file can run in trial mode for 60 days. After
60 days, the feature enters the default mode. The license file with the same errors cannot
be installed repeatedly.
NOTE
l If the ESNs or VR versions do not match, the system runs based on the function items and resource
configuration defined in the license file. If the system does not read correct function items or
resource items from the license file, the system runs with the minimum configuration.
l If the ESNs or VR versions do not match and the license for the feature exceeds the validity date and
protection period, the feature runs in default mode. Otherwise, the feature runs in trial mode.
l If there is a license file in which the ESNs or VR versions do not match on the system, a license file
with the same error as the existing license file cannot be installed. If a correct license file exists, a
license file in which the ESNs or VR versions do not match can also be installed.
l If the license file to be installed expires, that is, the license for all features exceeds the validity date,
the license file installation fails. If only the license for some features exceeds the validity date, the
license file can be installed and a message prompting that the license for some features exceeds the
validity date is displayed.
l During license installation, if the function items, resource items, and validity period in the license
file are different from those in the previous license file, the installation result indicates the
differences and the user can choose to forcibly install the new license file.
l If the value of a license control item in the license file is smaller than the corresponding configured
value (for example, the number of cells), the license file fails to be installed.
Possible Causes
l
185
eRAN11.1
eRAN Troubleshooting Guide
The license file has expired or the license file type is incorrect.
The system configuration items do not match the license control items.
Fault Diagnosis
If the license installation fails, an error message will be displayed in the MML command
output. You can diagnose the fault based on the error message. For details, see eRAN License
Management Feature Parameter Description.
Troubleshooting Procedure
1.
Rectify the fault based on the error message by referring to eRAN License Management
Feature Parameter Description.
2.
Typical Cases
Fault Description
After eNodeBs at a site were upgraded from eRAN2.0 to eRAN2.1, the eNodeBs experienced
failures to install commercial licenses. The following error message was displayed:
The configured value of the control item is greater than the value in the license
file
Fault Diagnosis
During commercial license installation, the U2000 displayed the following message:
The configured value of the control item is greater than the value in the license
file
This message shows that the configured values on the current eNodeB exceeded the limits of
the license file. Compare the license control items in the license file with the configuration
that has taken effect on the eNodeB to find the configuration items that have been activated
on the eNodeB but were not authorized by the license file.
Fault Handling
1.
Query the configured values on the eNodeB with the authorized values in the license file.
Run the DSP LICINFO command to query the configured values on the eNodeB, and
compare the configured values with the allocated values in the license file. The
command output is as follows:
Figure 15-2 Querying license information
As shown in the figure, Allocated, Config, and Actual Used are the allocated value in the
license file, the configured value on the eNodeB, and the actual value.
When the configured value on the eNodeB exceeds the allocated value in the license file,
the following error message is displayed:
Data Configuration Exceeding Licensed Limit
186
eRAN11.1
eRAN Troubleshooting Guide
2.
3.
4.
Fault Description
Related alarms and events are generated.
Related Information
l
Related alarms
Related events
187
eRAN11.1
eRAN Troubleshooting Guide
Possible Causes
Table 15-1
Alarm
Possible Causes
License on Trial
188
eRAN11.1
eRAN Troubleshooting Guide
Alarm
Possible Causes
Fault Diagnosis
Refer to the alarm reference documents to locate the alarm causes and clear the alarms.
Troubleshooting Procedure
1.
2.
Typical Cases
None
Fault Description
After a command was run to enable a function, a configuration activation failure occurred due
to license restriction.
Issue Draft A (2016-03-07)
189
eRAN11.1
eRAN Troubleshooting Guide
Related Information
l
The allocated value for a resource item generally exceeds 1. Operators determine
the number of resource items in the commercial license they purchase based on the
site requirements. Typical resource items include the cell bandwidth, number of
accessed users, and number of cells.
The function items are assigned values of 0 or 1 to indicate whether the functions
are purchased. The typical function items include enhanced synchronization (clock
synchronization), IPSec, and IEEE 802.1X-based access control.
License control items can be further classified into the following five categories based on
the configured value and usage:
Dynamic counting items (resource items): These items are passive control items
without requiring manual configuration. The configured value is NULL. These
items dynamically occupy session resources. When a session starts, the occupied
resources are counted and are subtracted from the total number of resources. When
the session stops, the occupied resources are released.
Performance items (resource items): These items are passive control items without
requiring manual configuration. The configured value is NULL. When the eNodeB
starts up, the eNodeB learns about the allocated values of these items by queries.
During eNodeB operation, the quantity of occupied resources is ensured to be less
than the allocated values.
Static counting items (resource items): These items are active control items and
require manual configuration. The corresponding resources are statically configured
resources. When the eNodeB starts up, the eNodeB obtains the configured values of
these items from the configuration file and uses these configured values to apply for
the corresponding types of resource. When the eNodeB stops providing services,
the resources are released.
Boolean counting items (resource items): These items are active control items and
require manual configuration. The corresponding resources are Boolean resources
at the NE's submodule level. When the eNodeB starts up, the eNodeB decides
whether to apply for the corresponding resources based on the configured values (0
or 1). When a submodule stops providing services, its resources are released.
190
eRAN11.1
eRAN Troubleshooting Guide
Boolean items (function items): These items are passive control items without
requiring manual configuration. The configured value is NULL, and the
corresponding resources are NE-level Boolean resources. When the eNodeB starts
up, the eNodeB checks the values of these items to see whether the corresponding
functions are enabled.
Possible Causes
l
The license for the eNodeB has expired, and the keep-alive period has expired.
The license for the eNodeB does not have the permission to apply for license control
items.
Troubleshooting Flowchart
When this type of fault occurs, the message "Failed to activate the configuration because of
license control" is displayed on the maintenance console. The following figure shows the
troubleshooting flowchart.
191
eRAN11.1
eRAN Troubleshooting Guide
Troubleshooting Procedure
1.
2.
If license-related alarms are generated, clear the alarms by referring to Alarm Reference.
3.
If there are no license-related alarms, run the DSP LICINFO command to view the
allocated values and configured values for the current control items.
4.
Check whether the functions to be enabled on the eNodeB are authorized by control
items or whether the configured values exceed the allocated values in the license file.
5.
If the configured values exceed the allocated values, apply for a new license that meets
requirements and reinstall the license.
6.
Typical Cases
None
192
eRAN11.1
eRAN Troubleshooting Guide
16
193
eRAN11.1
eRAN Troubleshooting Guide
Fault Overview: This function provides KPI status information related to one or
multiple NEs. It helps OM engineers completely learn and decide the current fault status.
Fault Delimitation: This function provides a detailed analysis on an abnormal KPI that
is found by the Fault Overview function or decided by OM engineers to find out the
cause and help OM engineers formulate the service recovery scheme.
Confirm Recovery: This function helps OM engineers monitor the effect and decide
whether a service is recovered after a service recovery scheme is implemented.
NOTE
To perform Confirm Recovery, use the performance monitoring function of the U2000 client or use the
PRS to monitor performance counters.
Collect Information: This function collects information about a fault when the cause of
the fault cannot be decided and the fault cannot be rectified using the preceding
functions. Then, the fault information can be provided to Huawei technical support for
analysis and troubleshooting.
Parameter Settings: This function sets values for the parameters required by fault
analysis, such as the threshold of each KPI.
Context
The following table describes the Parameter Settings window.
Table 16-1 Window description
Function
Description
Parameter table
194
eRAN11.1
eRAN Troubleshooting Guide
Function
Description
Saving parameter
settings
Restoring
parameter values
NOTE
The parameter default value configuration file of each base station version is released with the U2000
mediation of the version. If the U2000 is reinstalled with the mediation of a certain base station version, the
parameter setting function needs to be used to save the parameter settings of the version again, so that the
parameter settings are consistent.
Procedure
Step 1 After logging in to the FMA system, choose Wireless > Parameter Settings.
Step 2 Select the target version for performance fault analysis from the Parameter Settings dropdown list box. Then, change the parameter values in the Current Threshold column to
appropriate ones.
Step 3 Click Save in the lower left corner of the page.
----End
Context
The following table describes the Fault Overview window.
Table 16-2 Window description
Function
Description
View
Historical
Data
The fault overview function automatically saves analysis results of the latest
10 tasks. You can click View Historical Data to view historical analysis
reports.
Export
Detailed
Analysis
195
eRAN11.1
eRAN Troubleshooting Guide
Function
Description
Topology
Tree
Subzone
Settings
Import/
Export
Import: Imports the NE list, which is in .csv format and exported from the
NE topology view of the U2000 client, into a self-defined NE group.
Export: Selects an NE list you want to export and click Export to save it on
the local PC in .csv format.
NOTE
l If the Internet Explorer (IE) cannot export the result data, choose Tool > Manage
Add-ons on the menu bar of IE. In the Manage Add-ons dialog box, select
Toolbars and Extensions in the Add-on Types area. In the right pane, right-click
ChromeFrame BHO and choose Disable from the shortcut menu. Then, restart the
IE.
l If you click a displayed Download Analysis dialog box on Internet Explorer
during report export but the result is invisible, you need to configure the following
settings on Internet Explorer. On the menu bar, choose Tools. In the displayed
Internet Options dialog box, click the Security tab.
l If the current website is not added to trusted sites, click Local intranet and set
the security level to Medium-low.
l If the current website has been added to trusted sites, click Trusted sites and
set the security level to Medium-low.
KPI Failure
Cause
Statistics
Displays the statistics of all KPI failure causes in the current NE group
within the performance measurement period started by T0.
196
eRAN11.1
eRAN Troubleshooting Guide
Function
Description
Site List
KPI Change
Trend Chart
Displays the KPI trends from the past 24 hours to the current time, from the
past 48 hours to the past 24 hours, and in the same period on the same day
of the last week.
NOTE
The start time of the first week from when the KPI changes from stable to dramatic is
marked T0.
Current
KPIs
Procedure
Step 1 After you log in to the FMA system, choose FMA > Fault Overview to open the Fault
Overview window.
Step 2 In the Topology node in the left navigation tree, select one or multiple subnets you want to
analyze. Then, the grouping information of the NEs included in the subnets is displayed in the
lower part of the navigation tree, as shown in the following figure.
197
eRAN11.1
eRAN Troubleshooting Guide
NOTE
The FMA automatically groups NEs in a subnet by TAC by default, but you can group NEs yourself.
Step 3 Optional: You can add desired eNodeBs to a subzone by using the Subzone Settings
function, as shown in the following figure.
1.
2.
In the displayed dialog box, select eNodeBs, add them to a subzone, set the subzone
name, and then save the subzone information, as shown in the following figure.
198
eRAN11.1
eRAN Troubleshooting Guide
Step 4 Select one NE group you want to analyze and click Analyse. After the operation is completed,
the analysis result will be displayed on the Fault Overview window.
Step 5 Click a desired KPI in the table for further analysis. Then, the trend analysis, its deterioration
time points, failure cause distribution, and the KPI failure contribution rate of each eNodeB in
the eNodeB list can be obtained, as shown in the following figure.
Figure 16-3 Selecting KPI to Be Analyzed
Step 6 Optional: When need look historical analysis report, perform this step. Click View Historical
Data in the Fault Overview page and choose a historical analysis report in the displayed
dialog box, historical analysis reports are arranged based on the time when the analysis was
conducted.
Issue Draft A (2016-03-07)
199
eRAN11.1
eRAN Troubleshooting Guide
Step 7 Select the sites you want to perform a detailed analysis from the Site List, as shown in the
following figure.
Figure 16-4 Selecting NEs to Be Analyzed
Step 8 Optional: Specify the analysis period, and the default value is the latest 24 hours, as shown in
the following figure.
NOTE
You can set Analysis Period on the Fault Overview page only to the time within today.
NOTE
Step 9 Click Next. Then, the Fault Delimitation function is started and the selected sites are
analyzed one by one.
----End
Context
The Fault Delimitation window has a Site tab page and a Cell tab page.
Issue Draft A (2016-03-07)
200
eRAN11.1
eRAN Troubleshooting Guide
The Site tab page consists of basic information of sites, the transmission diagnosis
information, a list of active alarms, and site-level fault diagnosis reports, the following table
describes the Site tab page.
Table 16-3 Site tab page description
Function
Description
Basic Site
Information Table
Transmission
Diagnosis Info
Active Alarms
Site-level Fault
Diagnosis Reports
The Cell tab page consists of the basic information of cells, the cell dashboard, the board
diagnosis information, cell-level key counter analysis information, and cell-level fault
diagnosis reports, the following table describes the Cell tab page.
201
eRAN11.1
eRAN Troubleshooting Guide
Description
Basic Cell
Information Table
Cell Dashboard
Provides correlation analyses on the KPIs and alarms of a cell and the
operation log. After you click a time point when a KPI changes, the
alarms and operation log at the time will be queried. This helps users
quickly find the possible fault cause.
Board Diagnosis
Info
Displays the CPU usage trends of the main control board and
baseband processing unit (BBP) serving a cell and the trend of the
number of connected users in the cell. This helps users observe the
relationship between the KPI changes in the cell and the CPU usage
of the boards.
Fault Diagnosis
Results of Cells
Procedure
l
If you cannot decide the NE having a fault, you are advised to perform a KPI analysis in
the Fault Overview window and then perform the Fault Delimitation function for a
certain KPI.
a.
b.
On the Site tab page, click Analyze in front of each site name in the table, as shown
in the following figure.
202
eRAN11.1
eRAN Troubleshooting Guide
c.
On the Cell tab page, click Analyze in front of a cell ID in the table, as shown in
the following figure.
Figure 16-7 Detailed cell analysis
NOTE
l Board Diagnosis Info, Cell KPI Analysis, and Fault Diagnosis Result of Cells of the cell
will be displayed after you click Analyze.
l Click a time in the Cell Dashboard KPI trend chart. Then, operation logs and alarm logs
around this time will be highlighted in the operation and alarm log lists. Such information
helps you to decide whether the operation records or alarm records have relationships with the
KPI changes. See the following figure.
If you can decide the top failure sites, you can directly perform the Fault Delimitation
function.
a.
After you log in to the FMA system, choose FMA > Fault Delimitation to open
the Fault Delimitation window.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
203
eRAN11.1
eRAN Troubleshooting Guide
b.
In the NE Root node in the left navigation tree, select one or multiple subnets you
want to analyze. Then, the grouping information of the NEs included in the subnets
is displayed in the lower part of the navigation tree.
NOTE
The FMA automatically groups NEs in a subnet by TAC by default, but you can group NEs
yourself.
c.
d.
In the KPI list on the right, select the KPIs you want to analyze.
e.
Set the start time and time range for analysis in Fault Occurrence Time and
Analysis Period.
f.
----End
Context
WebNIC is an information collection tool provided by U2000. For detailed operations and
GUIs, see the iManager U2000 Online Help.
Procedure
Step 1 After you log in to the FMA system, choose FMA > Collect Information to open the Collect
Information window.
Step 2 Click Collect Information. Then, the WebNIC window for information collection is
displayed.
----End
16.3 Appendix
This section lists KPIs that wireless fault management supports and their calculation
formulas.
Function
204
eRAN11.1
eRAN Troubleshooting Guide
No.
Function
L.E-RAB.AbnormRel / (L.E-RAB.NormRel +
L.ERAB.AbnormRel) * 100%
UL User
Throughput(Kbit/s)
Delta
(L.Thrp.bits.UL - L.Thrp.bits.UE.UL.SmallPkt) /
L.Thrp.Time.UE.UL.RmvSmallPkt
UL Cell
Throughput(Kbit/s)
Delta
L.Thrp.bits.UL / L.Thrp.Time.Cell.UL.HighPrecision
UL Cell Traffic
Volume(bit) Delta
L.Thrp.bits.UL
DL User
Throughput(Kbit/s)
Delta
(L.Thrp.bits.DL - L.Thrp.bits.DL.LastTTI) /
L.Thrp.Time.DL.RmvLastTTI
DL Cell
Throughput(Kbit/s)
Delta
L.Thrp.bits.DL / L.Thrp.Time.Cell.DL.HighPrecision
DL Cell Traffic
Volume(bit) Delta
L.Thrp.bits.DL
CSFB Execution
Success Rate
CSFB Preparation
Success Rate
Inter-Frequency HO
Success Rate
(L.HHO.IntraeNB.InterFreq.ExecSuccOut +
L.HHO.IntereNB.InterFreq.ExecSuccOut) /
(L.HHO.IntraeNB.InterFreq.ExecAttOut +
L.HHO.IntereNB.InterFreq.ExecAttOut) * 100%
Intra-Frequency HO
Success Rate
(L.HHO.IntraeNB.IntraFreq.ExecSuccOut +
L.HHO.IntereNB.IntraFreq.ExecSuccOut) /
(L.HHO.IntraeNB.IntraFreq.ExecAttOut +
L.HHO.IntereNB.IntraFreq.ExecAttOut) * 100%
Handover In Success
Rate
(L.HHO.IntraeNB.ExecSuccIn + L.HHO.IntereNB.ExecSuccIn) /
(L.HHO.IntraeNB.ExecAttIn + L.HHO.IntereNB.ExecAttIn) *
100%
X2 HO Out Success
Rate
(L.HHO.X2.IntraFreq.ExecSuccOut +
L.HHO.X2.InterFreq.ExecSuccOut) /
(L.HHO.X2.IntraFreq.ExecAttOut +
L.HHO.X2.InterFreq.ExecAttOut) * 100%
205
eRAN11.1
eRAN Troubleshooting Guide
No.
Function
S1 HO Out Success
Rate
(L.HHO.IntereNB.IntraFreq.ExecSuccOut +
L.HHO.IntereNB.InterFreq.ExecSuccOut L.HHO.X2.IntraFreq.ExecSuccOut L.HHO.X2.InterFreq.ExecSuccOut) /
(L.HHO.IntereNB.IntraFreq.ExecAttOut +
L.HHO.IntereNB.InterFreq.ExecAttOut L.HHO.X2.IntraFreq.ExecAttOut L.HHO.X2.InterFreq.ExecAttOut) * 100%
FDD TDD HO In
Success Rate
(L.HHO.IntraeNB.InterFddTdd.ExecSuccOut +
L.HHO.IntereNB.InterFddTdd.ExecSuccOut) /
(L.HHO.IntraeNB.InterFddTdd.ExecAttOut +
L.HHO.IntereNB.InterFddTdd.ExecAttOut) * 100%
(L.HHO.IntraeNB.InterFddTdd.ExecAttOut +
L.HHO.IntereNB.InterFddTdd.ExecAttOut) /
(L.HHO.IntraeNB.InterFddTdd.PrepAttOut +
L.HHO.IntereNB.InterFddTdd.PrepAttOut) * 100%
(L.HHO.InterFddTdd.IntraeNB.ExecAttIn +
L.HHO.InterFddTdd.IntereNB.ExecAttIn) /
(L.HHO.InterFddTdd.IntraeNB.PrepAttIn +
L.HHO.InterFddTdd.IntereNB.PrepAttIn) * 100%
(L.HHO.InterFddTdd.IntraeNB.ExecAttIn +
L.HHO.InterFddTdd.IntereNB.ExecAttIn) /
(L.HHO.InterFddTdd.IntraeNB.PrepAttIn +
L.HHO.InterFddTdd.IntereNB.PrepAttIn) * 100%
(L.RA.Dedicate.HO.Msg3Rcv + L.RA.GrpA.ContResolution +
L.RA.GrpB.ContResolution) / (L.RA.Dedicate.HO.Att +
L.RA.GrpA.Att+L.RA.GrpB.Att) * 100%
206
eRAN11.1
eRAN Troubleshooting Guide
17
Collectio
n Item
Collection Method
Log
file
eNodeB
software
version
207
eRAN11.1
eRAN Troubleshooting Guide
Infor
matio
n
Type
Collectio
n Item
Collection Method
Configurati
on file
208
eRAN11.1
eRAN Troubleshooting Guide
Infor
matio
n
Type
Collectio
n Item
Collection Method
3. Log in to the FTP server on the U2000 through the FTP client
to obtain the configuration file.
NOTE
l The FTP client must transmit files in binary format.
l The Encrypted Mode parameter (the parameter ID is
ENCRYPTMODE) specifies the encryption mode of the
configuration file. UNENCRYPTED indicates that the
configuration file is no encrypted. PWD_ENCRYPTED indicates
that the configuration file is encrypted using the password specified
by the user.
BRD log
209
eRAN11.1
eRAN Troubleshooting Guide
Infor
matio
n
Type
Collectio
n Item
Collection Method
2. Log in to the FTP server on the U2000 through the FTP client
to obtain the configuration file.
NOTE
The FTP client must transmit files in binary format.
CHR log
210
eRAN11.1
eRAN Troubleshooting Guide
Infor
matio
n
Type
Collectio
n Item
Collection Method
2. Log in to the FTP server on the U2000 through the FTP client
to obtain the configuration file.
NOTE
The FTP client must transmit files in binary format.
DBG log
211
eRAN11.1
eRAN Troubleshooting Guide
Infor
matio
n
Type
Collectio
n Item
Collection Method
2. Log in to the FTP server on the U2000 through the FTP client
to obtain the configuration file.
NOTE
The FTP client must transmit files in binary format.
SIG log
212
eRAN11.1
eRAN Troubleshooting Guide
Infor
matio
n
Type
Collectio
n Item
Collection Method
2. Log in to the FTP server on the U2000 through the FTP client
to obtain the configuration file.
NOTE
The FTP client must transmit files in binary format.
OPR log
2. Log in to the FTP server on the U2000 through the FTP client
to obtain the configuration file.
NOTE
The FTP client must transmit files in binary format.
213
eRAN11.1
eRAN Troubleshooting Guide
Infor
matio
n
Type
Collectio
n Item
Collection Method
Alarm log
2. Log in to the FTP server on the U2000 through the FTP client
to obtain the configuration file.
NOTE
The FTP client must transmit files in binary format.
Fault log
214
eRAN11.1
eRAN Troubleshooting Guide
Infor
matio
n
Type
Collectio
n Item
Collection Method
2. Log in to the FTP server on the U2000 through the FTP client
to obtain the configuration file.
NOTE
The FTP client must transmit files in binary format.
Radio
interferenc
e detection
log
215
eRAN11.1
eRAN Troubleshooting Guide
Infor
matio
n
Type
Collectio
n Item
Collection Method
2. Log in to the FTP server on the U2000 through the FTP client
to obtain the configuration file.
NOTE
The FTP client must transmit files in binary format.
Statistics
log
Trace
file
U2000 log
U2000 logs include the current logs and archived historical logs.
Current logs are saved in /export/home/omc/var/logs of the
U2000 server. Historical logs are archived in /export/
home/omc/var/logs/tracebak of the U2000 server. Log in to the
FTP server on the U2000 through the FTP client to obtain the
required logs.
Signaling
tracing on
standard
interfaces
216
eRAN11.1
eRAN Troubleshooting Guide
Infor
matio
n
Type
Collectio
n Item
Collection Method
NOTE
Standard
interface
signaling
tracing
includes
the tracing
on S1, X2,
and Uu
interfaces.
Obtaining
S1
interface
tracing
files is
used as an
example.
IFTS
tracing
217
eRAN11.1
eRAN Troubleshooting Guide
Infor
matio
n
Type
Collectio
n Item
Collection Method
Cell DT
tracing
LTE/EPC
end-to-end
user
tracing
218
eRAN11.1
eRAN Troubleshooting Guide
Infor
matio
n
Type
Collectio
n Item
Collection Method
LTE cell
tracing
The LTE cell tracing can be performed only on the U2000 and you
can obtain the tracing file as follows:
1. Choose Monitor > Signaling Trace > Signaling Trace
Management from the main window of the U2000. The
Signaling Trace Management tab page is displayed.
2. In the navigation tree, choose Trace Type > LTE > Cell Trace.
Double click Cell Trace. The Cell Trace dialog box is
displayed.
3. Set parameters and then click OK to start the tracing task.
4. After the tracing task is completed, click Export to export the
tracing file to the specified directory.
SCTP
tracing
219
eRAN11.1
eRAN Troubleshooting Guide
Infor
matio
n
Type
Collectio
n Item
Collection Method
GTP-U
tracing
The GTP-U tracing can be performed only on the U2000 and you
can obtain the tracing file as follows:
1. Choose Monitor > Signaling Trace > Signaling Trace
Management from the main window of the U2000. The
Signaling Trace Management tab page is displayed.
2. In the navigation tree, double-click Trace Type > Base Station
Device and Transport > Transport Trace > GTPU Trace.
The GTPU Trace dialog box is displayed.
3. Set parameters and then click Finish to start the tracing task.
4. After the tracing task is completed, click Export to export the
tracing file to the specified directory.
Antenna
feeder
informatio
n tracing
Perfor
mance
monito
ring
Spectrum
detection
220
eRAN11.1
eRAN Troubleshooting Guide
Infor
matio
n
Type
Collectio
n Item
Collection Method
Interferenc
e RSSI
statistic
detect
monitoring
Interferenc
e detection
monitoring
Output
power
monitoring
221
eRAN11.1
eRAN Troubleshooting Guide
Infor
matio
n
Type
Collectio
n Item
Collection Method
222
eRAN11.1
eRAN Troubleshooting Guide
Index
Index
223