Professional Documents
Culture Documents
Troubleshooting Guide
Issue
04
Date
2013-08-30
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
Issue 04 (2013-08-30)
eRAN3.0
Troubleshooting Guide
Sudden faults
Intended Audience
This document is intended for:
l
System engineers
Product Versions
The following table lists the product versions related to this document.
Issue 04 (2013-08-30)
Product Name
Product Version
DBS3900 LTE
V100R005C00
V100R005C00
BTS3900 LTE
V100R005C00
BTS3900A LTE
V100R005C00
BTS3900L LTE
V100R005C00
BTS3900AL LTE
V100R005C00
ii
eRAN3.0
Troubleshooting Guide
Change History
For details about the changes in this document, see 1 Changes in eRAN Troubleshooting
Guide.
Organization
1 Changes in eRAN Troubleshooting Guide
2 Troubleshooting Process and Methods
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.
Issue 04 (2013-08-30)
iii
eRAN3.0
Troubleshooting Guide
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.
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.
Issue 04 (2013-08-30)
iv
eRAN3.0
Troubleshooting Guide
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
The GUI conventions that may be found in this document are defined as follows.
Issue 04 (2013-08-30)
Convention
Description
Boldface
>
eRAN3.0
Troubleshooting Guide
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.
Issue 04 (2013-08-30)
Action
Description
Click
Double-click
Drag
Press and hold the primary mouse button and move the
pointer to a certain position.
vi
eRAN3.0
Troubleshooting Guide
Contents
Contents
About This Document.....................................................................................................................ii
1 Changes in eRAN Troubleshooting Guide..............................................................................1
2 Troubleshooting Process and Methods.....................................................................................3
2.1 General Troubleshooting Process...................................................................................................................................4
2.2 General Troubleshooting Steps......................................................................................................................................5
2.2.1 Backing Up Data.........................................................................................................................................................5
2.2.2 Collecting Fault Information.......................................................................................................................................5
2.2.3 Determining the Fault Scope and Type.......................................................................................................................7
2.2.4 Identifying Fault Causes..............................................................................................................................................9
2.2.5 Rectifying the Fault.....................................................................................................................................................9
2.2.6 Checking Whether Faults Have Been Rectified........................................................................................................10
2.2.7 Contacting Huawei Technical Support......................................................................................................................10
vii
eRAN3.0
Troubleshooting Guide
Contents
viii
eRAN3.0
Troubleshooting Guide
Contents
Issue 04 (2013-08-30)
ix
eRAN3.0
Troubleshooting Guide
04 (2013-08-30)
This is the fourth official release.
Compared with issue 03 (2012-12-29), this issue includes the following new information.
Topic
Change Description
Compared with issue 03 (2012-12-29), this issue includes the following changes.
Topic
Change Description
03 (2012-12-29)
This is the third official release.
Compared with issue 02 (2012-07-30), this issue does not include any new information.
Compared with issue 02 (2012-07-30), this issue includes the following changes.
Issue 04 (2013-08-30)
eRAN3.0
Troubleshooting Guide
Topic
Change Description
02 (2012-07-30)
This is the second official release.
Compared with issue 01 (2012-06-29), this issue does not include any new information.
Compared with issue 01 (2012-06-29), this issue includes the following changes.
Topic
Change Description
Whole document
Updated descriptions.
01 (2012-06-29)
This is the first official release.
Compared with draft A (2012-05-11), this issue does not include any new information.
Compared with draft A (11.05.12), this issue includes the following changes.
Topic
Change Description
Draft A (2012-05-11)
This is a draft.
Issue 04 (2013-08-30)
eRAN3.0
Troubleshooting Guide
Issue 04 (2013-08-30)
eRAN3.0
Troubleshooting Guide
Issue 04 (2013-08-30)
No.
Step
Remarks
eRAN3.0
Troubleshooting Guide
No.
Step
Remarks
2.2.6 Checking
Whether Faults Have
Been Rectified
2.2.7 Contacting
Huawei Technical
Support
Fault symptom
Issue 04 (2013-08-30)
eRAN3.0
Troubleshooting Guide
Operations performed on the equipment before the fault occurs, and the results of these
operations
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.
Issue 04 (2013-08-30)
Type
Attribute
Description
Original
information
Definition
Function
Reference
None
eRAN3.0
Troubleshooting Guide
Type
Attribute
Description
Alarm
information
Definition
Function
Reference
For details about how to use the alarm system, see M2000
Online Help. For detailed information about each alarm, see
eNodeB Alarm Reference.
Definition
Function
Reference
Definition
Function
Reference
Indicator
status
Performance
counter
eRAN3.0
Troubleshooting Guide
Service Faults
Service faults are further classified into the following types:
l
Access faults
User access fails.
The access success rate is low.
Handover faults
The intra-frequency handover success rate is low.
The inter-frequency handover success rate is low.
Rate faults
Data rates are low.
There is no data rate.
Data rates fluctuate.
Equipment Faults
Equipment faults are further classified into the following types:
l
Cell faults
Cell setup fails.
Cell activation fails.
Clock faults
The clock source is faulty.
The IP clock link is faulty.
The system clock is out of lock.
Security faults
The IPSec tunnel is abnormal.
SSL negotiation is abnormal.
Digital certificate processing is abnormal.
Issue 04 (2013-08-30)
eRAN3.0
Troubleshooting Guide
License faults
License installation fails.
License modification fails.
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.
Summarize measures of preventing or decreasing such faults. This helps to prevent similar
faults from occurring in the future.
Issue 04 (2013-08-30)
eRAN3.0
Troubleshooting Guide
Severity level of the fault and the time required for rectifying the fault
Alarm information
For details about how to collect fault information, see eNodeB LMT User Guide, eNodeB
Performance Monitoring Reference, eNodeB Routine Maintenance Guide, and M2000 Online
Help.
Issue 04 (2013-08-30)
10
eRAN3.0
Troubleshooting Guide
If you are outside mainland China, contact the technical support personnel in the local
Huawei office.
Email: support@huawei.com
Website: http://support.huawei.com
Issue 04 (2013-08-30)
11
eRAN3.0
Troubleshooting Guide
Issue 04 (2013-08-30)
12
eRAN3.0
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 04 (2013-08-30)
13
eRAN3.0
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.
Issue 04 (2013-08-30)
14
eRAN3.0
Troubleshooting Guide
Issue 04 (2013-08-30)
15
eRAN3.0
Troubleshooting Guide
Related Counters
l
Related Alarms
l
Hardware-related alarms
ALM-26104 Board Temperature Unacceptable
ALM-26106 Board Clock Input Unavailable
ALM-26107 Board Input Voltage Out of Range
ALM-26200 Board Hardware Fault
ALM-26202 Board Overload
ALM-26203 Board Software Program Error
ALM-26208 Board File System Damaged
Temperature-related alarms
ALM-25650 Ambient Temperature Unacceptable
ALM-25651 Ambient Humidity Unacceptable
ALM-25652 Cabinet Temperature Unacceptable
ALM-25653 Cabinet Humidity Unacceptable
ALM-25655 Cabinet Air Outlet Temperature Unacceptable
ALM-25656 Cabinet Air Inlet Temperature Unacceptable
l
Issue 04 (2013-08-30)
Link-related alarms
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
16
eRAN3.0
Troubleshooting Guide
RF-related alarms
ALM-26239 RX Channel RTWP/RSSI Unbalanced Between RF Units
ALM-26520 RF Unit TX Channel Gain Out of Range
ALM-26521 RF Unit RX Channel RTWP/RSSI Too Low
ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced
Configuration-related alarms
ALM-26245 Configuration Data Inconsistency
ALM-26243 Board Configuration Data Ineffective
ALM-26812 System Dynamic Traffic Exceeding Licensed Limit
ALM-26815 Licensed Feature Entering Keep-Alive Period
ALM-26818 No License Running in System
ALM-26819 Data Configuration Exceeding Licensed Limit
ALM-29243 Cell Capability Degraded
ALM-29247 Cell PCI Conflict
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
17
eRAN3.0
Troubleshooting Guide
In addition, after the Evolved Packet Core (EPC) obtains the international mobile subscriber
identity (IMSI) of the UE with the lowest success rate based on the UE's temporary mobile
subscriber identity (TMSI), you can start a task to trace the UE throughout the whole network.
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.
l Resources are
insufficient.
l A fault occurs in radio
interface processing.
l The EPC is abnormal.
l Top user problems occur.
l Parameters of the UE or
eNodeB are incorrectly
configured.
l The radio environment is
abnormal.
l Parameters of the Evolved
Packet Core (EPC) are
incorrectly configured.
l The UE is abnormal.
Troubleshooting Flowchart
Figure 4-1 show the troubleshooting flowcharts for handling low RRC connection setup rates
and low E-RAB setup rates, respectively.
Issue 04 (2013-08-30)
18
eRAN3.0
Troubleshooting Guide
Figure 4-1 Troubleshooting flowcharts for handling low RRC connection setup rates and low
E-RAB setup rates
Troubleshooting Procedure
1.
2.
3.
4.
5.
Issue 04 (2013-08-30)
19
eRAN3.0
Troubleshooting Guide
l Yes: End.
l No: Go to 6.
6.
7.
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.
An RRC connection is successfully set up for the UE according to standard interface tracing
results, but then the mobility management entity (MME) releases the UE because the
authentication procedure fails.
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 E-RABs
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.E-RAB.FailEst.RNL
contribute a large proportion.
Background Information
None
Possible Causes
l
Issue 04 (2013-08-30)
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.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
20
eRAN3.0
Troubleshooting Guide
The authentication and encryption algorithms are incorrectly configured on the Evolved
Packet Core (EPC).
Issue 04 (2013-08-30)
21
eRAN3.0
Troubleshooting Guide
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.
22
eRAN3.0
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
1.
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
2.
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 diameter-authorizationrejected(5003) message.
Figure 4-4 Tracing result of the signaling at the EPC side
3.
Issue 04 (2013-08-30)
23
eRAN3.0
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
1.
Issue 04 (2013-08-30)
24
eRAN3.0
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.
2.
3.
Issue 04 (2013-08-30)
25
eRAN3.0
Troubleshooting Guide
Fault Handling
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.
Background 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
Issue 04 (2013-08-30)
26
eRAN3.0
Troubleshooting Guide
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
Issue 04 (2013-08-30)
27
eRAN3.0
Troubleshooting Guide
Possible Causes
l
Fault Diagnosis
To effectively diagnose access faults due to radio environment abnormalities, you are advised
to firstly find out whether this fault is caused by radio interference or weak coverage. The
following procedure is recommended:
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.
Issue 04 (2013-08-30)
28
eRAN3.0
Troubleshooting Guide
9.
Typical Cases
Fault Description
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.
Issue 04 (2013-08-30)
29
eRAN3.0
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.
Issue 04 (2013-08-30)
30
eRAN3.0
Troubleshooting Guide
Issue 04 (2013-08-30)
31
eRAN3.0
Troubleshooting Guide
This section provides information required to troubleshoot intra-RAT handover faults due to
poor Uu quality. The information includes fault descriptions, background information, possible
causes, fault handling method and procedure, and typical cases.
Issue 04 (2013-08-30)
32
eRAN3.0
Troubleshooting Guide
Related Counters
l
Related Alarms
l
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.
Issue 04 (2013-08-30)
33
eRAN3.0
Troubleshooting Guide
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 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.
Fault Analysis
The following measures are effective in locating a handover fault:
l
Issue 04 (2013-08-30)
34
eRAN3.0
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.
Issue 04 (2013-08-30)
35
eRAN3.0
Troubleshooting Guide
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.
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:
Issue 04 (2013-08-30)
36
eRAN3.0
Troubleshooting Guide
Related alarms
Background Information
Related Alarms
l
Possible Causes
Possible hardware faults that will cause handover faults are listed as follows:
l
A board is overloaded.
An RF module is faulty.
37
eRAN3.0
Troubleshooting Guide
Figure 5-2 Fault handling flowchart for intra-RAT handover faults due to hardware faults
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-cell
handover success rate was restored.
Issue 04 (2013-08-30)
38
eRAN3.0
Troubleshooting Guide
Fault Description
l
Background Information
None
Possible Causes
l
39
eRAN3.0
Troubleshooting Guide
Figure 5-3 Fault handling flowchart for intra-RAT handover faults due to incorrect data
configurations
2.
3.
4.
5.
6.
Issue 04 (2013-08-30)
40
eRAN3.0
Troubleshooting Guide
No: Go to 7.
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 handedover 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 M2000.
Background Information
None
Possible Causes
l
A large number of UEs have been handed over to the target cell due to inappropriate
parameter configurations.
Issue 04 (2013-08-30)
41
eRAN3.0
Troubleshooting Guide
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.
Fault Handling
Issue 04 (2013-08-30)
42
eRAN3.0
Troubleshooting Guide
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.
Background 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.
Issue 04 (2013-08-30)
43
eRAN3.0
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
Issue 04 (2013-08-30)
44
eRAN3.0
Troubleshooting Guide
Figure 5-5 Fault Handling flowchart for intra-RAT handover faults due to poor Uu quality
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.
Issue 04 (2013-08-30)
Check whether there is imbalance between UL and DL quality. Specifically, check whether
the transmit power of the RRU and UE falls beyond link budgets.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
45
eRAN3.0
Troubleshooting Guide
7.
8.
9.
Typical Cases
None
Issue 04 (2013-08-30)
46
eRAN3.0
Troubleshooting Guide
Issue 04 (2013-08-30)
47
eRAN3.0
Troubleshooting Guide
This section provides information required to troubleshoot service drops due to handover faults.
The information includes fault descriptions, background information, possible causes, fault
handling method and procedure, and typical cases.
6.8 Troubleshooting Service Drops Due to MME Faults
This section provides information required to troubleshoot service drops due to MME faults.
The information includes fault descriptions, background information, possible causes, fault
handling method and procedure, and typical cases.
Issue 04 (2013-08-30)
48
eRAN3.0
Troubleshooting Guide
Related Counters
E-RAB Release Measurement (Cell) (E-RAB.Rel.Cell)
Counters related to service drops are classified as follows:
l
Release types
Normal releases
Abnormal releases
Normal releases for outgoing handovers
Abnormal releases for outgoing handovers
Issue 04 (2013-08-30)
49
eRAN3.0
Troubleshooting Guide
If the percentage of abnormal E-RAB releases due to congestion to all abnormal E-RAB
releases is greater than 30%, you need to check whether congestion occurs in the cell.
Handover failures (L.E-RAB.AbnormRel.HOFailure)
If the percentage of abnormal E-RAB releases due to handover failures to all abnormal
E-RAB releases is greater than 30%, you need to check whether parameters are properly
set for the neighboring cells.
MME faults (L.E-RAB.AbnormRel.MME)
If the percentage of abnormal E-RAB releases due to mobility management entity
(MME) faults to all abnormal E-RAB releases is greater than 30%, you need to check
whether parameters are properly set for the evolved packet core (EPC).
For details, see eNodeB 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)
Where,
l
The L.E-RAB.AbnormRel counter measures the total number of abnormal E-RAB releases
in a cell.
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
None
50
eRAN3.0
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.
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.
Issue 04 (2013-08-30)
51
eRAN3.0
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.
Issue 04 (2013-08-30)
52
eRAN3.0
Troubleshooting Guide
The traffic volume trend of the whole network can be determined based on the number of
E-RAB setup attempts and successful E-RAB setups. Check whether there are 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.E-RAB.AbnormRel.Radio
counter measures the number of abnormal E-RAB releases due to radio interface faults in nonhandover 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-of-synchronization,
or signaling procedure failures that are resulted from weak coverage, uplink interference, or UE
exceptions.
53
eRAN3.0
Troubleshooting Guide
2.
3.
4.
5.
Typical Cases
None
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.
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.
Issue 04 (2013-08-30)
54
eRAN3.0
Troubleshooting Guide
2.
3.
Typical Cases
None
Fault Description
According to the definitions of eNodeB performance counters, the L.E-RAB.AbnormRel.Cong
counter measures the number of abnormal E-RAB releases due to resource congestion.
Related Information
None
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.
55
eRAN3.0
Troubleshooting Guide
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
Possible Causes
Abnormal E-RAB releases due to handover failures are caused by failures of handovers from
the local cell to another cell.
56
eRAN3.0
Troubleshooting Guide
2.
3.
Typical Cases
None
Fault Description
According to the definitions of eNodeB performance counters, the L.E-RAB.AbnormRel.MME
counter measures the number of abnormal E-RAB releases that are initiated by the evolved
packet core (EPC). However, these abnormal releases are 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.
Obtain the S1 tracing messages related to the topN cell and analyze specific release causes.
Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
57
eRAN3.0
Troubleshooting Guide
2.
Collect the analysis result and information about the signaling procedure and then contact
EPC engineers.
3.
4.
Typical Cases
None
Issue 04 (2013-08-30)
58
eRAN3.0
Troubleshooting Guide
Issue 04 (2013-08-30)
59
eRAN3.0
Troubleshooting Guide
Related Counters
Inter-RAT Outgoing Handover Measurement (Cell) (HO.IRAT.Out.Cell)
For details, see eNodeB Performance Counter Reference.
Related Formulas
Handover Success Rate
Formula
Fault Description
The following are symptoms of inter-RAT handover faults:
l
Issue 04 (2013-08-30)
60
eRAN3.0
Troubleshooting Guide
Signaling message tracing results indicate that handover procedures are incomplete or fail.
Related Information
l
Event
Description
EUTRA
RRC_CONNECTED to
UTRA CELL_DCH PS
handover
EUTRA
RRC_CONNECTED to
GERAN GSM_Dedicated
handover
If the value of the eighth and ninth indicators is 0, the UE does not support PS handovers.
If the value of the eighth and ninth indicators is 1, the UE supports PS handovers.
l
Issue 04 (2013-08-30)
61
eRAN3.0
Troubleshooting Guide
Possible Causes
l
Inter-RAT handover parameters or evolved packet core (EPC) parameters are incorrectly
set, or there are missing neighbor relationships.
The signal quality is poor. For example, the coverage is poor or there is interference.
Fault Handling
Inter-RAT handover faults are complex and you need to determine whether an inter-RAT
handover fault occurs in the entire network or in a cell based on the fault scope and background.
If the fault occurs in the entire network, locate the fault by checking the signaling exchange and
parameter settings on the mobility management entity (MME) and serving GPRS support node
(SGSN). If the fault occurs in a cell, check the data configuration, frequency, and hardware of
the cell.
Figure 7-1 shows the troubleshooting flowchart for inter-RAT handover faults.
Issue 04 (2013-08-30)
62
eRAN3.0
Troubleshooting Guide
2.
3.
Issue 04 (2013-08-30)
63
eRAN3.0
Troubleshooting Guide
5.
6.
7.
8.
9.
Typical Cases
l
Case 1: In a PS handover from E-UTRAN to UTRAN, the eNodeB did not deliver a PS
handover command but delivered a redirection command to the UE.
Fault Description
In a test of PS handover from E-UTRAN to UTRAN in a laboratory at a site, after the UE
reported B1 measurement results to the eNodeB, the eNodeB did not deliver a PS handover
command but delivered a redirection command.
Fault Diagnosis
The result of tracing the network access procedure found that the UE did not support interRAT handover. If a UE does not support inter-RAT handover, the eNodeB will redirect the
UE to UTRAN.
Issue 04 (2013-08-30)
64
eRAN3.0
Troubleshooting Guide
Fault Handling
The problem was solved after a UE that supports inter-RAT handover was used.
l
Case 2: In a test of PS handover from E-UTRAN to UTRAN, the eNodeB did not deliver
a PS handover command.
Fault Description
In a test of PS handover from E-UTRAN to UTRAN in a laboratory at a site, after the UE
reported B1 measurement results to the eNodeB, the eNodeB did not deliver a PS handover
command.
Fault Diagnosis
The result of tracing the network access procedure found that the UE supported inter-RAT
handover. The PS handover switch was checked on the eNodeB. The check result indicated
that the switch was turned on. Then, the neighboring cell relationships were checked. The
check result shows that a RAC was not configured for the neighboring UTRAN cell.
Fault Handling
The problem was resolved after an RAC was added to the neighboring UTRAN cell.
Case 3: In a test of PS handover from E-UTRAN to UTRAN, the eNodeB sent the MME
a PSHO Required message. After two seconds, the eNodeB sent the MME a PSHO Cancel
message.
Fault Description
In a test of PS handover from E-UTRAN to UTRAN in a laboratory at a site, the 4G EPC
and eNodeB were provided by vendor Y and the 3G core network and radio network
controller (RNC) were provided by vendor Z. After handover conditions were met, the
eNodeB sent the MME a PSHO Required message. After two seconds, the eNodeB sent
the MME a PSHO Cancel message.
Fault Diagnosis
Uu and S1 signaling was traced. The tracing result shows that the eNodeB sent the MME
a HO Cancel command after the UE reported B1 measurement results to the MME and the
eNodeB sent the MME a HO Required command. The reason why the eNodeB sent the
HO Cancel command was that the MME did not respond to the HO Required command.
The length of WaitInterRATSysHoRspTimer configured on the eNodeB was 2 seconds.
The eNodeB did not receive a response from the MME when the timer expired. As a result,
the eNodeB sent the Handover Cancel command to cancel the handover. The MME log
was checked. The check result shows that the MME received the HO Required command
but did not forward the command to the SGSN. The reason why the MME did not forward
the command is that the Gn interface was not configured between the MME and the SGSN,
and as a result, the MME could not find the SGSN. When the timer expired, the eNodeB
sent the UE a PSHO Cancel command.
Fault Handling
The problem was solved after the Gn interface was reconfigured between the MME and
SGSN.
Issue 04 (2013-08-30)
65
eRAN3.0
Troubleshooting Guide
Issue 04 (2013-08-30)
66
eRAN3.0
Troubleshooting Guide
No transmission
User equipment (UE) that has accessed a network cannot perform data services.
No transmission
67
eRAN3.0
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.
Issue 04 (2013-08-30)
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 1
10296
10296
250368
Category 2
51024
51024
1237248
68
eRAN3.0
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
302752
151376
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.
Issue 04 (2013-08-30)
69
eRAN3.0
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 but does
Issue 04 (2013-08-30)
70
eRAN3.0
Troubleshooting Guide
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)
Fault Handling
None
Issue 04 (2013-08-30)
71
eRAN3.0
Troubleshooting Guide
the ping operation fails or the delay is excessively long, contact EPC or datacom technical
support.
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 link refers to the S1 interface from the server to the eNodeB.
4.
Issue 04 (2013-08-30)
72
eRAN3.0
Troubleshooting Guide
cell is unloaded. If the RSSI is 3 dBm to 5 dBm higher than the normal value, uplink
interference exists. Locate the interference source, and mitigate the interference.
5.
Check whether the basic information about the data services or the parameter settings are
incorrect.
This check is twofold:
l 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.
l 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.
9.
Issue 04 (2013-08-30)
73
eRAN3.0
Troubleshooting Guide
the single-thread rate, perform further TCP checks. If the rate is equal to or even lower
than the single-thread rate, go back to the previous steps to recheck for possible faults.
l Check basic TCP parameter settings.
Ensure that the basic TCP parameters are correctly set. The parameters include the
receive window, send window, and maximum transmission unit (MTU).
l Check the RTT.
Ping the server by using 32-byte packets and MSS-byte packets (MSS is short for
maximum segment size), and take the average RTT value for the two types as the
calculated RTT. Typically, the RTT value is required to be less than or equal to 50 ms.
Link optimization is required if the RTT value is greater than 50 ms.
l Check for packet loss and severe packet misordering.
On the PC side, trace packet headers or use the TCP fault diagnosis module to check
for packet loss and severe packet misordering. If packet loss or severe packet
misordering occurs, contact datacom personnel for handling.
10. If the fault persists, contact Huawei technical support.
Typical Cases
l
Case 2: UDP services were functional, but FTP services were unavailable.
Fault Description
Issue 04 (2013-08-30)
74
eRAN3.0
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 a 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
Issue 04 (2013-08-30)
75
eRAN3.0
Troubleshooting Guide
this algorithm was enabled. The reason for Samsung UE's 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.Time.DL
L.Thrp.bits.UL
L.Thrp.Time.UL
L.Traffic.User.DLData.Avg
L.Traffic.User.ULData.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 04 (2013-08-30)
76
eRAN3.0
Troubleshooting Guide
Fault Handling
None
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 lowrate 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 low-rate 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 04 (2013-08-30)
77
eRAN3.0
Troubleshooting Guide
Fault Handling
No handling was required. The rate decrease was caused by the provisioning of low-rate
subscription services.
Issue 04 (2013-08-30)
78
eRAN3.0
Troubleshooting Guide
Issue 04 (2013-08-30)
79
eRAN3.0
Troubleshooting Guide
This section provides information required to troubleshoot cell unavailability faults due to faulty
hardware. The information includes fault descriptions, background information, possible causes,
fault handling method and procedure, and typical cases.
Issue 04 (2013-08-30)
80
eRAN3.0
Troubleshooting Guide
Related Alarms
l
Cell alarms
ALM-29240 Cell Unavailable
Transmission alarms
ALM-25880 Ethernet Link Fault
ALM-25886 IP Path Fault
ALM-25888 SCTP Link Fault
Hardware alarms
ALM-26101 Inter-Board CANBUS Communication Failure
ALM-26200 Board Hardware Fault
ALM-26201 Board Memory Soft Failure
ALM-26205 BBU Board Maintenance Link Failure
License alarms
ALM-26817 License on Trial
Other alarms
ALM-29201 S1 Interface Fault
Issue 04 (2013-08-30)
81
eRAN3.0
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.
Issue 04 (2013-08-30)
82
eRAN3.0
Troubleshooting Guide
Troubleshooting Procedure
1.
2.
Issue 04 (2013-08-30)
83
eRAN3.0
Troubleshooting Guide
No: Go to 3.
3.
4.
5.
6.
7.
8.
Fault Description
A cell fails to be set up after data configuration.
Background 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.
Incorrect data configuration usually leads to a failure in the setup of a cell, not in the running of
a cell.
Issue 04 (2013-08-30)
84
eRAN3.0
Troubleshooting Guide
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
2.
3.
Rectify the cell fault based on the MML command outputs about cell activation failures.
For details, see eNodeB Alarm Reference.
4.
5.
Issue 04 (2013-08-30)
85
eRAN3.0
Troubleshooting Guide
Typical Cases
None
Fault Description
If the cell unavailability is caused by abnormal transport resources, a message will be displayed
after execution of the ACT CELL or DSP CELL command. The message is displayed as
Abnormal S1 link state for a cell.
Background Information
None
Possible Causes
The possible causes are:
l
In RAN sharing scenarios, the SCTP links of all operators in a cell are faulty or not
configured, or the S1 interfaces are all faulty or not configured.
In non-RAN sharing scenarios, the SCTP link or S1 interface is faulty or not configured.
2.
Issue 04 (2013-08-30)
86
eRAN3.0
Troubleshooting Guide
No: Go to 3.
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.
OM personnel checked the active alarms and found there were not alarms related to the
faulty cell.
2.
Run the DSP SCTPLNK MML command, check the SCTP link status and found that the
link was normal.
3.
Run the DSP S1INTERFACE MML command, check the S1 interface status, found that
S1 interfaces were not configured.
Fault Handling
After OM personnel configured S1 interfaces, the cell fault was rectified.
Fault Description
RF-related alarms are reported.
Issue 04 (2013-08-30)
87
eRAN3.0
Troubleshooting Guide
Background Information
RF Resource Item
The RF resource items to be checked include:
l
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.
Check whether there are alarms related to RF units or RF unit maintenance links.
Yes: Handle the alarms. For details, see eNodeB Alarm Reference. Go to 2.
No: Go to 3.
2.
3.
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.
Issue 04 (2013-08-30)
88
eRAN3.0
Troubleshooting Guide
Issue 04 (2013-08-30)
89
eRAN3.0
Troubleshooting Guide
Fault Description
A cell fails to be set up if the required capacity or capability is limited on software or hardware.
Background Information
None
Possible Causes
The hardware or software specification is limited (for example, the licensed capacity or
capability is limited), leading to cell unavailability.
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 04 (2013-08-30)
90
eRAN3.0
Troubleshooting Guide
Figure 9-4 Command output indicating a failure to obtain the licensed number of cells
Fault Description
Board fault alarms are reported. Alternatively, cell unavailability faults cannot be rectified after
resetting, powering off, or reinstalling faulty boards.
Issue 04 (2013-08-30)
91
eRAN3.0
Troubleshooting Guide
Background 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).
Check whether the board status is abnormal and whether the board versions are mismatched.
Run the DSP BRD or DSP BRDVER for query. Pay more attention to RF units.
Yes: Rectify the board faults. Go to 2.
No: Go to 3.
2.
3.
4.
Determine whether restoration operations such as eNodeB or board resets can be performed.
Yes: Go to 5.
No: Go to 9.
5.
6.
7.
8.
9.
Typical Cases
None
Issue 04 (2013-08-30)
92
eRAN3.0
Troubleshooting Guide
10
Issue 04 (2013-08-30)
93
eRAN3.0
Troubleshooting Guide
Related Alarms
The following alarms may be reported to indicate Internet Protocol (IP) transmission faults:
l
Issue 04 (2013-08-30)
94
eRAN3.0
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.
95
eRAN3.0
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.
Fault Handling
None
2.
Indicator Status
Check cables.
l Check the Ethernet cable.
Check whether the Ethernet cable is properly prepared and whether the cable is longer
than 100 m.
Issue 04 (2013-08-30)
96
eRAN3.0
Troubleshooting Guide
a.
Check and record the bandwidth (100 Mbit/s or 1000 Mbit/s) supported by the
personal computer (PC) used.
b.
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.
3.
a.
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.
b.
Check whether the optical cable is securely inserted. If it is not securely inserted,
reinsert it. Check whether the optical cable is broken due to excessive bending. If
it is broken, replace it.
c.
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.
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.
Issue 04 (2013-08-30)
Port Type
100M/FULL
100M/FULL
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
97
eRAN3.0
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.
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.
Related Information
None
Issue 04 (2013-08-30)
98
eRAN3.0
Troubleshooting Guide
Possible Causes
l
The Ethernet port negotiation mode is inconsistent between the eNodeB and the peer device.
Fault Handling
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.
2.
3.
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.
Issue 04 (2013-08-30)
99
eRAN3.0
Troubleshooting Guide
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 Handling
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.
2.
3.
4.
Typical Cases
None
Issue 04 (2013-08-30)
100
eRAN3.0
Troubleshooting Guide
11
Issue 04 (2013-08-30)
101
eRAN3.0
Troubleshooting Guide
Issue 04 (2013-08-30)
102
eRAN3.0
Troubleshooting Guide
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.
Issue 04 (2013-08-30)
103
eRAN3.0
Troubleshooting Guide
Fault Description
l
The Stream Control Transmission Protocol (SCTP) link is unavailable or available only in
one direction.
After sending data to the peer device, the sender does not receive a response from the peer
device. In addition, the sender does not receive data from the peer device.
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.
Issue 04 (2013-08-30)
104
eRAN3.0
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
Fault Handling
None
Typical Scenario
To find the cause for an SCTP fault, perform the following steps:
1.
Check configurations.
Check whether SCTP parameters are correctly configured on the MME and the
eNodeB.
2.
Issue 04 (2013-08-30)
105
eRAN3.0
Troubleshooting Guide
3.
4.
5.
l
2.
3.
4.
5.
6.
7.
Issue 04 (2013-08-30)
106
eRAN3.0
Troubleshooting Guide
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:
ALM-25886 IP Path Fault
Possible Causes
l
Fault Handling
None
2.
3.
Typical Cases
None
107
eRAN3.0
Troubleshooting Guide
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
Fault Handling
None
Typical Scenario
1.
Check configurations.
Check whether OM channel parameters are correctly configured on the M2000 client
and the eNodeB.
2.
If ping operations are prohibited in the operator network, do not ping the M2000 client.
3.
4.
l
Issue 04 (2013-08-30)
108
eRAN3.0
Troubleshooting Guide
3.
4.
5.
Typical Cases
None
Issue 04 (2013-08-30)
109
eRAN3.0
Troubleshooting Guide
12
Troubleshooting Transmission
Synchronization Faults
Issue 04 (2013-08-30)
110
eRAN3.0
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
Issue 04 (2013-08-30)
111
eRAN3.0
Troubleshooting Guide
The value of Current Clock Source State indicates that the reference clock is abnormal,
for example, the reference clock is lost.
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.
Background Information
l
2.
Several hours later, stop the clock quality check by running the STP CLKTST
command.
3.
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.
Issue 04 (2013-08-30)
112
eRAN3.0
Troubleshooting Guide
Check whether the external clock resources of the eNodeB work properly.
To check the status of an external clock source, run the DSP CLKSRC command. Pay
attention to the following two parameters:
l 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.
l Clock Source State
The link available status (Link Available State) of a reference clock can be checked
by running a command such as DSP IPCLKLINK, DSP SYNCETH, or DSP TOD.
The value of Clock Source State is Available when the external reference clock of the
eNodeB meets either of the following conditions:
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.
Check whether the physical connection and communication are normal between the
eNodeB and the clock source. For the GPS, the number of satellites must be greater
than or equal to 4; the related command is DSP GPS.
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 M2000 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.
3.
Issue 04 (2013-08-30)
113
eRAN3.0
Troubleshooting Guide
l 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.
l 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.
4.
5.
Typical Cases
None
Issue 04 (2013-08-30)
114
eRAN3.0
Troubleshooting Guide
13
Issue 04 (2013-08-30)
115
eRAN3.0
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.
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.
Issue 04 (2013-08-30)
116
eRAN3.0
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
M2000 to the eNodeB.
The eNodeB is under control, but transmission-related alarms are displayed on the Web
LMT.
Background Information
l
Related Alarms
ALM-26841 Certificate Invalid
ALM-25891 IKE Negotiation Failure
ALM-25880 Ethernet Link Fault
ALM-26223 Transmission Optical Interface Performance Degraded
ALM-26222 Transmission Optical Interface Error
ALM-26220 Transmission Optical Module Fault
ALM-25901 Remote Maintenance Link Failure
ALM-25888 SCTP Link Fault
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 04 (2013-08-30)
117
eRAN3.0
Troubleshooting Guide
Troubleshooting Procedure
1.
Issue 04 (2013-08-30)
118
eRAN3.0
Troubleshooting Guide
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.
2.
3.
Issue 04 (2013-08-30)
119
eRAN3.0
Troubleshooting Guide
4.
Check whether the IKE proposal configuration on the eNodeB is the same as that on the
SeGW.
Run the LST IKEPROPOSAL command to check whether the IKE proposal with the ID
indicated in 3 is consistent with the that used by the SeGW. Pay more attention to the
encryption algorithm, authentication algorithm, IKE version, and key. If the authentication
is based on digital certificates, go to 5. If the authentication is based on shared keys, go to
6.
5.
Run the DSP CERTMK command check the operator's device certificate. Pay more
attention to the information in the red frame. Check whether the issuer of the root certificate
is correct and whether the root certificate has expired. If the device certificate is incorrect,
apply for a new one. Then, run the DLD CERTFILE command to download the device
certificate, and run the ADD CERTMK command to add the device certificate to the
eNodeB.
Issue 04 (2013-08-30)
120
eRAN3.0
Troubleshooting Guide
Run the DSP APPCERT command to check whether the certificates used for IKE and SSL
are correct. 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
6.
7.
Issue 04 (2013-08-30)
121
eRAN3.0
Troubleshooting Guide
8.
Issue 04 (2013-08-30)
122
eRAN3.0
Troubleshooting Guide
9.
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.
2.
Issue 04 (2013-08-30)
123
eRAN3.0
Troubleshooting Guide
to send six IKE_AUTH messages before staring the next round of authentication
negotiation.
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.
Issue 04 (2013-08-30)
124
eRAN3.0
Troubleshooting Guide
14
Issue 04 (2013-08-30)
125
eRAN3.0
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 with
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 04 (2013-08-30)
126
eRAN3.0
Troubleshooting Guide
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, nonlinearity 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.
Issue 04 (2013-08-30)
127
eRAN3.0
Troubleshooting Guide
All passive components encounter intermodulation distortion that may be caused by unreliable
mechanical contacts, poor soldering, or oxidization.
Passive components such as combiners, duplexers, and filters require specific IM suppression
degrees. If the IM suppression degree of an IM order meets the requirements, the IM products
have no impact on the system performance. Generally, cables do not have requirements for PIM
suppression degrees. A cable requiring high PIM suppression degrees can reduce PIM
interference, but it is too expensive to be used widely.
Note that an improper connection is not definitely coupled with the PIM interference. If an RF
unit is properly connected with the antenna system, high-power IM components may also be
generated due to insufficient PIM suppression degrees of the cables.
If the IM components work on frequencies within the RX frequency band, this increases the
noise floor of the RX channels and decreases the sensitivity of the RF unit. For a frequency
division duplex (FDD) system, frequency bands such as 800MHz and 700MHz have small
duplex spacing (spacing between the DL frequency and the UL frequency). Meanwhile, the IM3
and IM5 products of the TX signals work on frequencies within the RX frequency band. In this
scenario, the impact of PIM interference must be paid special attention.
To sum up, the generating conditions for PIM interference are as follows:
The input is TX signals of the eNodeB, or occasionally external interference signals transmitted
through the antenna. The media is cables or passive components such duplexers and antennas.
The output is IM products. The power of the IM components depends on the IM suppression
degree of the passive components or cables.
PIM interference has the following typical characteristics:
l
Issue 04 (2013-08-30)
128
eRAN3.0
Troubleshooting Guide
Add downlink simulated load to increase the TX power. If the RTWP obviously multiplies,
PIM interference exists.
l
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.
Issue 04 (2013-08-30)
129
eRAN3.0
Troubleshooting Guide
Shut down downlink channels and then check whether the RTWP is excessively high.
Yes: Go to 2.
No: There is no PIM interference.
2.
Two interference signals received by a receiver are correlated but with different power.
They have the same impact on the RTWP.
External interference occupies a certain bandwidth. Monophony interference does not carry
any useful information, however, it seldom exists.
Issue 04 (2013-08-30)
130
eRAN3.0
Troubleshooting Guide
Figure 14-3 Structure and working principles of an RET antenna equipped with an RCU
Issue 04 (2013-08-30)
131
eRAN3.0
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.
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.
Issue 04 (2013-08-30)
132
eRAN3.0
Troubleshooting Guide
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.
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.
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.
Issue 04 (2013-08-30)
133
eRAN3.0
Troubleshooting Guide
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 two values are significantly different, run the STR VSWRTEST command to
perform VSWR tests on a frequency point at an interval of 1 MHz or smaller within the
bandwidth range to compare tested VSWR values.
l 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.
l 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 one-click log files of the main control board
and RF unit to Huawei technical support for further analysis.
5.
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.
Issue 04 (2013-08-30)
134
eRAN3.0
Troubleshooting Guide
Related Information
Related alarms are as follows:
l
Possible Causes
l
Issue 04 (2013-08-30)
135
eRAN3.0
Troubleshooting Guide
Run the LST ALMAF command to check whether alarms related to ALD or TDM
are reported. If such an alarm is reported, clear the alarm by referring to 14.6
Troubleshooting ALD Link Faults.
b.
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.
Issue 04 (2013-08-30)
136
eRAN3.0
Troubleshooting Guide
If the values on one RSSI curve are significantly greater than the values on other RSSI
curves, PIM interference exists. If values on all RSSI curves are basically the same,
there is no PIM interference and go to 3.
Figure 14-7 RSSI tracing result
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:
l 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.
l Breakpoint-based PIM detection:
By using breakpoints, divide the cable connecting the RF unit top to the antenna port
into several segments by using breakpoints. Disconnect the cable at the breakpoints one
by one along the direction from the RF unit top to the antenna port. Each time the cable
is disconnected at a breakpoint, connect the breakpoint to a matched load or a lowintermodulation attenuator, add a downlink simulated load, and check whether the
RTWP values increase. Ensure the inserted attenuator has low intermodulation
interference so that it will not add additional PIM interference to the cable. If the RTWP
values increase, PIM interference is introduced by the device or cable before this
breakpoint.
Issue 04 (2013-08-30)
137
eRAN3.0
Troubleshooting Guide
For example, set four breakpoints from the RF unit top to the antenna port, as shown in
Figure 14-8. At first, disconnect the cable at breakpoint 1, connect breakpoint 1 to a
low-intermodulation attenuator, and add a downlink simulation load. If RTWP values
do not change, PIM interference is not caused by the RF unit. If RTWP values increase,
PIM interference is caused by the RF unit. Perform the similar steps to the other
breakpoints.
Figure 14-8 Schematic diagram for breakpoint-based PIM detection
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.
Perform Broadband on-line frequency scan to check whether external interference exists.
Observe the scan result until the ALM-26239 RX Channel RTWP/RSSI Unbalanced
Between RF Units 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 eNodeB LMT User
Guide.
4.
Issue 04 (2013-08-30)
138
eRAN3.0
Troubleshooting Guide
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:
l The alarm is reported in at least two sectors under the same eNodeB.
l RTWP variations of different RF channels are uncorrelated.
l RTWP variations are similar in different sectors.
Troubleshooting Method
The cells with a crossed pair connection can be determined by using either of the following
two methods:
l 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.
l Run the STR CROSFEEDTST command to start the 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:
Issue 04 (2013-08-30)
139
eRAN3.0
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:
Issue 04 (2013-08-30)
140
eRAN3.0
Troubleshooting Guide
Possible Causes
Possible causes for ALD-related alarms are listed as follows:
l
2.
Typical Cases
None
Issue 04 (2013-08-30)
141
eRAN3.0
Troubleshooting Guide
15
Issue 04 (2013-08-30)
142
eRAN3.0
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.
Issue 04 (2013-08-30)
143
eRAN3.0
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 04 (2013-08-30)
144
eRAN3.0
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.
Issue 04 (2013-08-30)
145
eRAN3.0
Troubleshooting Guide
Possible Causes
l
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.
Fault Handling
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 M2000 displayed the following message:
The confitgred valued 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 LICENSE 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
Issue 04 (2013-08-30)
146
eRAN3.0
Troubleshooting Guide
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
2.
3.
4.
Fault Description
Related alarms and events are generated.
Related Information
l
Related alarms
ALM-26815 Licensed Feature Entering Keep-Alive Period
ALM-26816 Licensed Feature Unusable
ALM-26817 License on Trial
ALM-26818 No License Running in System
ALM-26819 Data Configuration Exceeding Licensed Limit
Related events
EVT-26820 License Emergency Status Activated
EVT-26821 License Emergency Status Ceased
Possible Causes
l
Issue 04 (2013-08-30)
147
eRAN3.0
Troubleshooting Guide
the keep-alive period, the expired feature operates in the current license settings. After the
keep-alive period, the expired feature operates in the default license settings.
l
License on Trial
This alarm is generated when a license file enters the keep-alive period. The possible causes
are as follows:
The license file exceeds the validity date.
The license file is revoked.
The ESN in the license file is inconsistent with the actual ESN of the eNodeB.
The eNodeB version in the license file is inconsistent with the running version of the
eNodeB.
The ESN and eNodeB version in the license file are inconsistent with the actual ESN
and the running version of the eNodeB.
Fault Diagnosis
Refer to the alarm reference documents to locate the alarm causes and clear the alarms.
Fault Handling
1.
2.
Issue 04 (2013-08-30)
148
eRAN3.0
Troubleshooting Guide
Typical Cases
None
Fault Description
After a command was run to enable a function, a configuration activation failure occurred due
to license restriction.
Figure 15-3 Example of a configuration activation failure due to license restriction
Related Information
l
Issue 04 (2013-08-30)
149
eRAN3.0
Troubleshooting Guide
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.
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.
l
Issue 04 (2013-08-30)
150
eRAN3.0
Troubleshooting Guide
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.
2.
If license-related alarms are generated, clear the alarms by referring to eNodeB Alarm
Reference.
3.
If there are no license-related alarms, run the DSP LICENSE 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.
Issue 04 (2013-08-30)
151
eRAN3.0
Troubleshooting Guide
Typical Cases
None
Issue 04 (2013-08-30)
152
eRAN3.0
Troubleshooting Guide
16
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.
Common fault information and collection methods are as follows.
Table 16-1 Common fault information and collection methods
Infor
matio
n Type
Collectio
n Item
Collection Method
Log file
eNodeB
software
version
Run the LST VER command to query the eNodeB software version.
Configurati
on file
Issue 04 (2013-08-30)
153
eRAN3.0
Troubleshooting Guide
Infor
matio
n Type
Collectio
n Item
Collection Method
3. Log in to the FTP server on the M2000 through the FTP client to
obtain the configuration file.
NOTE
The FTP client must transmit files in binary format.
BRD log
Issue 04 (2013-08-30)
154
eRAN3.0
Troubleshooting Guide
Infor
matio
n Type
Collectio
n Item
Collection Method
2. Log in to the FTP server on the M2000 through the FTP client to
obtain the configuration file.
NOTE
The FTP client must transmit files in binary format.
CHR log
2. Log in to the FTP server on the M2000 through the FTP client to
obtain the configuration file.
NOTE
The FTP client must transmit files in binary format.
Issue 04 (2013-08-30)
155
eRAN3.0
Troubleshooting Guide
Infor
matio
n Type
Collectio
n Item
Collection Method
DBG log
2. Log in to the FTP server on the M2000 through the FTP client to
obtain the configuration file.
NOTE
The FTP client must transmit files in binary format.
SIG log
Issue 04 (2013-08-30)
156
eRAN3.0
Troubleshooting Guide
Infor
matio
n Type
Collectio
n Item
Collection Method
2. Log in to the FTP server on the M2000 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 M2000 through the FTP client to
obtain the configuration file.
NOTE
The FTP client must transmit files in binary format.
Issue 04 (2013-08-30)
157
eRAN3.0
Troubleshooting Guide
Infor
matio
n Type
Collectio
n Item
Collection Method
Alarm log
2. Log in to the FTP server on the M2000 through the FTP client to
obtain the configuration file.
NOTE
The FTP client must transmit files in binary format.
Fault log
Issue 04 (2013-08-30)
158
eRAN3.0
Troubleshooting Guide
Infor
matio
n Type
Collectio
n Item
Collection Method
2. Log in to the FTP server on the M2000 through the FTP client to
obtain the configuration file.
NOTE
The FTP client must transmit files in binary format.
Statistics
log
Trace
file
M2000 log
M2000 logs include the current logs and archived historical logs.
Current logs are saved in /export/home/omc/var/logs of the M2000
server. Historical logs are archived in /export/home/omc/var/logs/
tracebak of the M2000 server. Log in to the FTP server on the
M2000 through the FTP client to obtain the required logs.
Signaling
tracing on
standard
interfaces
Issue 04 (2013-08-30)
159
eRAN3.0
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
Issue 04 (2013-08-30)
160
eRAN3.0
Troubleshooting Guide
Infor
matio
n Type
Collectio
n Item
Collection Method
Cell DT
tracing
The cell DT tracing can be performed only on the M2000 and you
can obtain the tracing file as follows:
1. Choose Monitor > Signaling Trace > Signaling Trace
Management from the main window of the M2000. The
Signaling Trace Management window is displayed.
2. In the navigation tree, double-click Cell DT Trace. The Create
Trace Task 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.
LTE/EPC
end-to-end
user tracing
LTE cell
tracing
The LTE cell tracing can be performed only on the M2000 and you
can obtain the tracing file as follows:
1. Choose Monitor > Signaling Trace > Signaling Trace
Management from the main window of the M2000. The
Signaling Trace Management window 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
Issue 04 (2013-08-30)
161
eRAN3.0
Troubleshooting Guide
Infor
matio
n Type
Collectio
n Item
Collection Method
The GTP-U tracing can be performed only on the M2000 and you
can obtain the tracing file as follows:
1. Choose Monitor > Signaling Trace > Signaling Trace
Management from the main window of the M2000. The
Signaling Trace Management window is displayed.
2. In the navigation tree, double-click GTPU Trace. The Create
Trace Task 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.
Perfor
mance
monito
ring
Spectrum
detection
Interferenc
e RSSI
statistic
detect
monitoring
Interferenc
e detection
monitoring
Issue 04 (2013-08-30)
162
eRAN3.0
Troubleshooting Guide
Infor
matio
n Type
Collectio
n Item
Collection Method
RRU/RFU
output
power
monitoring
CPU usage
monitoring
Issue 04 (2013-08-30)
163