Microsoft PowerPoint - 01 OEB404600 eNodeB V100R006 Troubleshooting ISSUE 1

eNodeB V100R005 Troubleshooting
www.huawei.com
Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved.
Objectives
Upon completion of this course, you will be able to:
Describe the fault types and influences Grasp eNodeB troubleshooting methods Perform the eNodeB troubleshooting
Page1
Confidential Information of Huawei. No Spreading Without Permission
Contents
1. Troubleshooting Overview 2. Troubleshooting Cell Unavailable Faults 3. Troubleshooting IP Transmission Faults 4. Troubleshooting Application Layer Faults 5. Troubleshooting Synchronization Faults 6. Troubleshooting Transmission Security Faults 7. Troubleshooting RF Unit Faults 8. Troubleshooting License Faults
Page2
General Troubleshooting Process

Start Back up data. Collecting fault information Can the fault scope and type be determined?
Yes No
Determining the fault scope and type Identify fault causes Rectify the fault
No
Contacting Huawei for Technical Support
Is the fault rectified?

Yes
End
Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved. Page3
Fault Information Collection

Information Item Fault symptom, as well as the time, location and frequency of the occurrence Equipment running status, fault symptom, operations performed before the fault occurs, and measures taken after the fault occurs and the effect of these measures. Software/hardware running state of the equipment Scope and impact of the fault Collection Method Consult the person reporting the fault, e.g, customer service center
Consult maintenance personnel
Observe the board indicators, the O&M system, and the alarm management system Perform service demonstration, performance measurement, and interface/signaling tracing
Page 4
LTE Fault Scope and Type

In this course, troubleshooting of equipment faults is discussed.
Access faults Handover faults Service faults Service drop faults Inter-RAT interoperability faults Rate faults eNodeB faults Cell faults OMCH faults Clock faults Equipment faults Security faults Radio frequency faults License faults
Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved. Page 5
Common Maintenance Function

Common maintenance functions that are used to analyze and handle faults are as follows:
User tracing Interface tracing Comparison/Interchange Switchover/Reset
Page6
Contact Huawei for Technical Support

For the problems difficult to be located or solved Huawei Contact Information
If you are in mainland China, dial 4008302118. If you are outside mainland China, contact the technical support personnel in E-mail: support@huawei.com Website: http://support.huawei.com the local Huawei office.
Page7
Contents
Page8
Cell Unavailable Faults

Affected Factors
Transmission Hardware Configuration RF
ALM-29240 Cell Unavailable alarm is reported.
Possible Causes
Incorrect data configuration Abnormal transport resources Abnormal RF resources Limited capacity or capability Faulty hardware
Troubleshooting Flowchart
Page10
Troubleshooting Flowchart (Cont.)
Page11
Incorrect 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.
Common incorrect data configuration causes

Incorrect cell power configuration Incorrect cell bandwidth configuration Incorrect cell network-related configuration
Page12
Abnormal Transport Resources

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.
Possible causes
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. Other transmission faults occur.
Page13
Case for Abnormal Transport Resources

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~19 73485632.
Fault Diagnosis
The active alarms were checked and no alarms related to the faulty cell were found. Run the DSP SCTPLNK MML command, check the SCTP link status and the link was normal. Run the DSP S1INTERFACE MML command, check the S1 interface status, found that S1 interfaces were not configured.
Abnormal RF Resources
The RF resource items to be checked include:
Whether CPRI links between RF units and LBBPs work properly. Whether the working status of RF units is normal. Whether RF unit versions match the main control board version. Whether the line rates of CPRI links are successfully negotiated. Whether RF networking is consistent with data configuration.
Possible Causes
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.
Page15
Case for Abnormal RF Resources

Fault Description
After a cell activation command was executed, the following output is displayed.
Fault Diagnose
Check RF-channel-related alarms (including VSWR alarms and RF unit maintenance link alarms) and found there were RF unit maintenance link alarms. OM personnel then determined that fiber connections were incorrect according to alarm help information.
Limited Capacity or Capability

Fault Description
A cell fails to be set up if the required capacity or capability is limited on software or hardware.
Possible Causes
the licensed capacity or capability is limited.
Page17
Case for Limited Capacity or Capability

Fault Description
The output after executing the command of DSP CELL,
Page18
Case for Limited Capacity or Capability (Cont.)

Fault diagnose
According to the command output, the cell activation failure is caused by license limitation. The result of DSP LICENSE command indicates that the licensed number of cells is 3. However, four cells are actually configured according to the result of the LST CELL command. The configured number of cells exceeds the licensed number, which leads to the cell activation failure.
Fault Handling
After a new license is applied for, downloaded, and activated, the cell is successfully activated.
10
Faulty Hardware
Fault Description
Board fault alarms are reported. Alternatively, cell unavailability faults cannot be rectified after resetting, powering off, or reinstalling faulty boards.
Possible Causes
a fault occurs in the main control board, LBBP, RF unit, or other hardware (for example, a subrack).
Page20
Hardware Fault Handling Procedure

START Collect the fault info through alarm browser and MML command
Observe the panel indicators Useful commands: DSP BRD DSP RRU DSP BRDVER DSP VSWR DSP CPRIPORT Determine the fault type and area
Handle the fault by alarm handling suggestion
Fault cleared?
No
Contact Huawei
Yes END
Page21
11
Observe Panel Indicators
Page22
Observe Panel Indicators See Remarks

BBU3900 Panel Indicators
Page23
12
Contents
Page24
IP Transmission Faults
Definition
If an IP transmission fault occurs, messages and service data cannot be transmitted between communication devices, and a peer device cannot be pinged.
Related alarms reported to indicate IP transmission faults:

ALM-25880 Ethernet Link Fault ALM-25885 IP Address Conflict ALM-25886 IP Path Fault ALM-25888 SCTP Link Fault ALM-29240 Cell Unavailable
Page25
13
Possible Causes of Transmission Faults

No communication in the physical layer (L1) No communication in the data link layer (L2) No communication in the IP layer (L3)
Lower layer faults will lead to higher layer faults
Page26
Troubleshooting IP Physical Layer Faults

Step 1. Monitor the Ethernet port indicator status.
LED
Color
Status ON
Description The negotiation succeeds between the Ethernet port and the peer port The negotiation fails between the Ethernet port and the peer port The port is receiving or transmitting data. The port does not receive or transmit data.
Green (LINK) Etherne t port Orange/ Yellow (ACT) OFF Blinks fast OFF
If the green indicator on either the local eNodeB or the peer switch is off, go to the next step.
14
Troubleshooting IP Physical Layer Faults (Cont.)

Step 2. Check cable
Check the Ethernet cable if transmission between eNodeB and switch is by electrical ports.
Make sure the cable is well prepared. Record the bandwidth negotiated with assistance of PC.
Check the optical cable and optical modules if transmission between eNodeB and switch is by optical ports.
Make sure the optical modules and cables are securely inserted. Check whether the optical module is damaged and whether the cable is broken. It is recommended that the eNodeB and peer device use optical modules provided by the same manufacturer and with the same rate.

Step 3. Check configurations.
Run the LST ETHPORT and DSP ETHPORT commands to check the Ethernet port configuration, especially the Port Attribute, Speed, and Duplex.
Negotiate with peer device, SET ETHPORT to modify
Page29
15

Step 4. Isolate the fault.
Take the right figure as an example of the ports used in eNodeB and switch.
Step 4.1 test switch port functionality
Step 4.2 test eNodeB port functionality
Page30

Step 4.3. Identify and isolate the fault.
If the ETH port is faulty, try to reset the ETH port and the corresponding board by MML commands of RST ETHPORT and RST BRD. Use RST ETHPORT to reset an Ethernet port and restart automatic port negotiation. The reset of a board causes interruption of services carried by the board. The reset of the active main control board causes reset of the eNodeB.
Rest by MML
Rest by GUI in M2000

Page31
16
Troubleshooting IP Link Layer Faults

Step 1. Check packet transmitting and receiving on the eNodeB.
Run the DSP ETHPORT command multiple times.
Repeat the query, observe the RX and TX statistics on the eNodeB port
If only the number of packets transmitted by the eNodeB increases, the peer device does not respond. Check whether the eNodeB has transmitted incorrect packets or the packets are correct but the peer device is faulty.
Troubleshooting IP Link Layer Faults (Cont.)

Step 2. Query the ARP table. Check whether the eNodeB has learned the ARP.
Run the DSP ARP command on the eNodeB. Check whether the ARP entry is available.
If the peer ARP entry is available on the eNodeB, you can infer that the fault is not caused by the ARP entry.
Page33
17

Step 2 (Cont.)
If the eNodeB has not learned the ARP, perform a ping test and check again.
If the eNodeB still has not learned the ARP, run the STR PORTREDIRECT command to start port redirection to trace the packet header.
Page34

Step 3. Check the VLAN configuration.
Run the LST VLANMAP and LST VLANCLASS commands to check whether the VLAN configuration is correct.
Run the STR PORTREDIRECT on the eNodeB to start port mirroring to trace the packet header. Compare the VLAN configuration with the VLAN information in the packet. If the VLAN information in the packet is incorrect, modify the VLAN configuration and check again.
18
VLAN Introduction See remarks
Page36
Troubleshooting IP Layer Faults

Step 1. Query the configured routes.
Run the LST IPRT and DSP IPRT commands to check whether routes are correctly configured on the eNodeB.
Page37
19
Troubleshooting IP Layer Faults (Cont.)

Step 2. Use the traceroute function to locate the fault.
Run the TRACERT command on the eNodeB to query the nodes that the transmitted packets pass and determine the gateway where the route becomes unavailable.
Page38
Troubleshooting IP Layer Faults (Cont.)

Step 3. Trace protocol data.
Run the STR PORTREDIRECT command on the eNodeB to start port mirroring to trace the protocol and packet header.
Step 4. If the fault persists, contact Huawei technical support.
Page39
20
Contents
Page40
Troubleshooting Application Layer Faults

Definition
Application layer faults include unavailability and intermittent disconnection of SCTP links, IP paths, and OM channels.
Page41
21
Troubleshooting Flowchart for Application Layer Faults
Page42
Troubleshooting SCTP Link Faults

Fault Description
Either of the following alarms is reported: ALM-25888 SCTP Link Fault
ALM-25889 SCTP Link Congestion
The SCTP link is unavailable or available only in one direction. The SCTP link is abnormal.
Possible Causes
The transmission network is faulty. The SCTP parameters are incorrectly configured on the eNodeB or MME. The NE has internal faults.
22
Troubleshooting SCTP Link Faults in Typical Scenario

Check whether SCTP parameters are correctly configured on the MME and the eNodeB. On eNodeB side, SCTP link configuration information can queried by LST SCTPLNK.
the parameters in red rectangles are eNodeB parameters and the parameters in the blue rectangles are EPC parameters
Page44
Troubleshooting SCTP Link Faults in Typical Scenario (Cont.)

Step 2. Check the transmission.
Ping the MME IP address. If the MME IP address cannot be pinged, check the route and transmission network, following what described in chapter 3.
Step 3. Start SCTP message tracing.

Start SCTP message tracing and compare the tracing result with normal SCTP message exchange.
Step 4. Start a tracing task using WireShark.

Run the STR PORTREDIRECT command on the eNodeB to start port redirection. If no desired data is traced, it is possible that the transmitting port did not send the data. If desired data is traced, the transmission network and EPC are normal.
23
Troubleshooting SCTP Link Faults of Intermittent SCTP Link Disconnection

Step 1. Check transmission alarms. Step 2. Check the QoS of signaling data.
If VLANs are configured for the eNodeB, check whether the VLAN for signaling data is correctly configured on the eNodeB. If no VLAN is configured for the eNodeB, check whether the DSCP value for signaling data is the same as that for the transmission network.
Run the LST DIFPRI command to query the DSCP value for signaling data.
Check whether the DSCP value is 46 in the QoS configuration for the transmission network.
Page46
Troubleshooting SCTP Link Faults of Intermittent SCTP Link Disconnection (Cont.)

Step 3. Start SCTP message tracing.
Start SCTP message tracing and analyze the messages to find the cause for the link failure.
Step 4. Check the network packet loss rate.

If the SCTP message tracing shows that packets are lost, check whether the port attribute of the GE or FE port is consistent with that on the peer device. If it is consistent, ping the peer device to check the packet loss rate on the transmission network.
Step 5. Start a WireShark tracing task. Step 6. Take preventive measures.

If configurations are correct and the peer device can be pinged, run the MOD SCTPLNK command or remove the SCTP link information and reconfigure the SCTP parameters so that the eNodeB and the peer device negotiate about the SCTP link again.
Page47
24
Troubleshooting IP Path Faults

Fault Description
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 QCIs.
Possible Causes
The IP route is incorrectly configured. The IP path parameters are incorrectly configured.
Page48
Troubleshooting IP Path Faults (Cont)

Step 1. Check whether ALM-25886 IP Path Fault is reported.
Clear the alarm if there was
Step 2. Check whether IP path parameters are correctly configured.

Run the LST IPPATH command. In the command output, if Path Type is QOS and DSCP is 0, only default bearers can be set up. In this case, change Path Type to ANY.
Page49
25
Troubleshooting OM Channel Faults

Fault Description
The ALM-25901 Remote Maintenance Link Failure alarm is reported. OM channel faults are classified into two categories:
OM channel unavailability: The OM channel is faulty. OM channel interruption: The OM channel is intermittently interrupted.
Possible Causes
The transmission network is faulty. The OM channel parameters are incorrectly configured on the eNodeB or M2000. Some ports are disabled in the transport network.
Page50
Procedure of Troubleshooting OM Channel Faults in Typical Scenario
Page51
26
Troubleshooting OM Channel Faults of in Typical Scenario
Step 1. Check the eNodeB Connectivity with M2000
The eNodeB disconnection can be found though Main Topology and Alarm Browser
Page52
Troubleshooting OM Channel Faults in Typical Scenario (Cont.)

Step 2: check the M2000 Routing Table
Run the following command on the M2000 server, check whether the M2000 has the route to the eNB: netstat rn
To add the route, run command: route add host/net destination gateway Example: add net 10.77.204.0: gateway 10.77.198.1
Page53
27
Troubleshooting OM Channel Faults of in Typical Scenario (Cont.)

Step 3: Ping the eNodeB on the M2000 Server
Check the physical connection between the M2000 server and eNodeB whose IP address is 10.77.198.177 on the Solaris operating system. Format
Ping IP address of a host
alive indicate the connection between the eNB and the M2000 is secure
Page54
Troubleshooting OM Channel Faults of in Typical Scenario (Cont.)

Step 4: trace the route on M2000
The target IP is traceable! The target IP is not traceable!

Page55
Example of traceroute IP address of a host

28
Perform Troubleshooting in eNodeB

Check whether OM channel parameters are correctly configured on the eNodeB.
Step 2. Check the transmission.

Ping the IP address of the M2000. If the IP address of the M2000 cannot be pinged, check the route and transport network, following what described in chapter 3.
Step 3. (Optional) Trace protocol data.
Page56
Troubleshooting OM Channel Faults of Intermittent OM Channel Interruption

Step 1. Check transmission alarms.
Clear the physical layer alarms first, then application layer alarms.
Step 2. Check the VLAN configuration.

If VLANs are differentiated by next-hop IP address, the check is not required.
Step 3. Check whether network loopbacks exist.

oversights in network design. temporary loopback links that were built during link tests but were not removed promptly.
Step 4. (Optional) Trace protocol data.

If allowed, the protocol data tracing tool can be used to analyze packet headers.
29
Contents
Page58
Synchronization Faults
Classification of synchronization faults
Clock reference problem. IP clock link fault. System clock unlocked fault. Base station synchronization frame number error. Time synchronization failure.
Possible Causes
The clock mode is incorrectly set. The clock source is incorrectly added. The clock working mode is incorrectly set for the eNodeB. 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.
30
Synchronization Faults Description

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.
Page60
Troubleshooting Synchronization Faults

Step 1. Check the clock configuration for the eNodeB by DSP CLKSTAT .
Check whether the clock synchronization mode is set to a specified mode. If not, set by SET CLKSYNCMODE.
Check whether the clock sources are correctly added. Check whether the work mode of the clock is correctly set. If not, set by SET CLKMODE.
If the eNodeB needs to lock an external clock source, set the clock working mode to AUTO or MANUAL.
31
Troubleshooting Synchronization Faults (Cont.)

Step 2. Check whether the external clock resources of the eNodeB work properly by DSP CLKSRC. Pay attention to the following 2 parameters.
License Authorized: Allow Run the DSP LICENSE command. If the Allocated, Config, and Actual Used fields of the Enhanced Synchronization control item are all 1, the eNodeB synchronization function is enabled. If not, apply license with this function. Clock Source State: available.
Page62

Step 2. continue
If the IPCLK is used, and the Clock Source State is Unavailable. Check the connectivity with the IP clock server.
Ping the IPCLK at the eNodeB LST IPCLKLINK to get the IP clock server IP address.
Login the IPCLK server to check the connectivity with eNodeB.

32

Step 3. Check whether the eNodeB correctly selects a clock source.
When multiple external clock sources are added and work properly, the output of the DSP CLKSRC command indicates that the status of these clock sources is Available. The output of the corresponding link query command (DSP IPCLKLINK, DSP SYNCETH, DSP GPS, or DSP TOD) indicates that the status of the clock link is also Available.
Page64

Step 4. Check whether the eNodeB correctly locks an external clock source.
To check the lock status, run the DSP CLKSTAT command.
Current Clock Source: It indicates the clock source to be traced by the eNodeB. Current Clock Source State: The value should be Normal. PLL Status: The initial status should be Fast Tracking, and then Locked. Clock Synchronization Mode: It indicates the configured clock synchronization mode.
33
Contents
Page66
Definitions of Transmission Security Faults

A transmission security fault occurs when an IPSec tunnel between an eNodeB and an SeGW malfunctions. This fault leads to abnormal communication between the eNodeB and the EPC. Transmission security faults include:
IKE negotiation failure. IPSec tunnel setup failure. Certificate application failure.
Page67
34
Background Information See remarks
Page68
Troubleshooting Specific Transmission Security Faults

When a transmission security fault occurs:
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. Transmission detection commands such as ping cannot be successfully executed.
Possible causes:
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.
35
Troubleshooting Flowchart for Transmission Security Faults
Page70
Troubleshooting Procedure
Step 1. Check whether an IPSec policy group is bound to the port involved by LST IPSECBIND command.
If no binding relationship is found, bind an IPSec policy group to the port by ADD IPSECBIND.
Example of listing binding relationships
Page71
36
Troubleshooting Procedure (Cont.)

Step 2. Check whether the IKE proposal is correctly configured by DSP IKEPROPOSAL command.
If the values in the red frame are inconsistent with the network plan, run the MOD IKEPROPOSAL command to change them.
Example of listing IKE negotiation results
Page72

Step 3. Check whether the IKE peer is correctly configured by DSP IKEPEER command.
If the values in the red frame are inconsistent with the network plan, run the MOD IKEPEER command to change them.
Example of listing IKE peer information
Page73
37

Step 4. Check whether the IKE proposal configuration on the eNodeB is the same as that on the SeGW by the LST IKEPROPOSAL command
check whether the IKE proposal with the ID indicated in step 3 is consistent with what 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.
Page74

Step 5. Check whether the eNodeB's certificate chain is correct.
Run the DSP TRUSTCERT command to check the operator's root certificate.
Example of listing operator's root certificate information
Run the DSP CERTMK command to check the operator's device certificate.
Example of listing operator's device certificate information
Page75
38

Step 5. Continue
Run the DSP APPCERT command to check whether the certificates used for IKE and SSL are correct.
Example of listing certificates used for IKE and SSL
Page76

Step 6. Check whether the IPSec proposal is correctly configured by the DSP IPSECPROPOSAL command.
Example of listing IPSec proposal information
If the values in the red frame are inconsistent with the network plan, run the MOD IPSECPROPOSAL command to change them.
Page77
39

Step 7. Check whether the IPSec policy is correctly configured by the DSP IPSECPOLICY command.
Example of listing IPSec policy information
If the values in the red frame are inconsistent with the network plan, run the MOD IPSECPOLICY command to change them.
Page78

Step 8. Check whether the ACL rule is correctly configured by the LST ACLRULE command.
If the values in the red frame are inconsistent with the network plan, run the MOD ACLRULE command to change them.
Example of listing ACL rule information

40
Typical Case
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
Step 1. OM personnel checked whether the IPSec-related parameters were correctly configured.
The output of the DSP IKESA command indicated that the IKE SA status in phase 1 was Ready or Ready|StayAlive, but the status in phase 2 was None. IPSec-related parameter settings were checked and were found to be the same as those on the SeGW.
Page80
Typical Case (Cont.)

Fault Diagnosis
Step 2. OM personnel checked header information.
There were four IKE_AUTH exchanges between the eNodeB and the SeGW. After that, the SeGW did not respond to the IKE_AUTH message from the eNodeB. When an eNodeB has not received any responses from an SeGW for a long time, the eNodeB will continue to send six IKE_AUTH messages before staring the next round of authentication negotiation.
Step 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.
Page81
41
Contents
Page82
RF Unit Faults
Definition
If a RF unit is faulty, its sensitivity decreases, leading to deterioration of the cell demodulation performance and reduction of the uplink coverage, or even service interruption in the cell.
Background Information
voltage standing wave ratio (VSWR) tests. passive intermodulation (PIM) interference. External interference. remote electrical tilt (RET) antennas.
Page83
42
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.
Principle of a VSWR test

PIM (Passive Inter-Modulation) Interference

What is PIM interference?
an example of a PIM result

43
Characteristics of PIM Interference

The RTWP multiplies while the TX power increases.
Add downlink simulated load to increase the TX power. If the RTWP obviously multiplies, PIM interference exists.
The RTWP is sensitive to the positions of cables and connectors.

Observe the RTWP while shaking the cable near a connector or hitting a connector. If the RTWP changes greatly, PIM interference exists.
The impact of PIM interference increases with the bandwidth.

The impact of PIM interference must be taken into account for frequency bands with the duplex spacing within 30 MHz.
The generating mechanism of PIM interference is complicated.
Page86
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. Interference signals can also be classified based on the polarization:
Linear polarized interference signals. Circular polarized interference signals.
In some cases, external interference may also lead to RTWP imbalance alarms.
Page87
44
External Interference Characteristics

Stable external interference has the following typical characteristics:
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. External interference is received only by antennas, which simplifies the troubleshooting procedure.
Page88
Procedure to Determine External Interference

To determine whether external Interference exists,
Step 1. Check whether PIM interference exists.
Shut down downlink channels and then check whether the RTWP is excessively high. If RTWP is normal, it means there is PIM interference.
Step 2. If RTWP is excessively high after step 1, check whether external interference exists. Perform the following steps:
Disconnect an RRU or RFU from the jumper, and then connect the RRU or RFU to a matched load or direct open-circuit to check whether the RTWP falls within the normal range. If the RTWP is normal, external interference exists.
Page89
45
Remote Electrical Tilt Antenna

An RET antenna can be remotely controlled because it is equipped with a drive called the RCU. The RCU is installed closely to the RET antenna. The right figure shows the structure and working principles of an RET antenna equipped with an RCU.
Page90
Troubleshooting Flowchart for RF Unit Faults

An RF unit is faulty. Is the fault caused by VSWR faults? No Is the fault caused by RTWP faults? No Is the fault caused by ALD link faults? No Contact Huawei technical support. Yes Troubleshoot ALD link faults. Yes Troubleshoot RTWP faults. Yes Troubleshoot VSWR faults. Does the RF unit work properly? No Does the RF unit work properly? No Does the RF unit work properly? No Yes Yes Yes
End
Page91
46
Troubleshooting VSWR Faults

Fault Description
An alarm ALM-26529 RF Unit VSWR Threshold Crossed is reported if there are VSWR faults in the RF channels of an RF unit.
Possible Causes
The VSWR alarm threshold is set to a low value. Hardware installation is improper. 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.
Page92
Troubleshooting VSWR Faults

Step 1. Check the detected VSWR value when the alarm is reported. Step 2. Check the VSWR alarm threshold of the RF unit.
Run the LST RRU command to query the VSWR alarm threshold of the RF unit.
If the threshold is improper, change it by running the MOD RRU command.

47
Troubleshooting VSWR Faults (Cont.)

Step 3. Check the current VSWR value.
a. Run the DSP VSWR command to query the current VSWR value.
b. Run the STR VSWRTEST command to query the offline VSWR value.
Page94

Step 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 step 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.
If the values are the same, go to step 5. If some of the values are large, collect necessary information and contact Huawei technical support for further analysis.
Page95
48

Step 5. Check the feeder connection at the local end.
Check whether the frequency band supported by the RF unit is consistent with that supported by the components of the antenna system according to the network plan. It is recommended that a Sitemaster be used to measure the distance between the point with a large VSWR value and the test point during a VSWR test. If no Sitemaster is available, locate the fault by using isolation methods. Add load to different parts of the feeder at the local end. Then, run the STR VSWRTEST to start a VSWR test on each isolation part of the feeder to locate the fault.
Page96
Troubleshooting RTWP Faults

Fault Description
An RTWP-related alarm is reported.
ALM-26522 RF Unit RX Channel RTWP/RSSI Unbalanced ALM-26521 RF Unit RX Channel RTWP/RSSI Too Low
Possible Causes
The setting of attenuation on the RX channel of the RF unit is incorrect. The feeder connected to the RF unit is faulty. Passive intermodulation (PIM) exists. External interference exists. The feeder is improperly connected with the antenna. The hardware in an RF module is faulty.
49
Fault Handling Flowchart for RTWP Faults
Page98
Troubleshooting RTWP Faults

Step 1. Rectify the faults and modify the improper settings.
1.1. Check whether alarms related to ALD or TDM are reported. If yes, clear the alarm by referring to Troubleshooting ALD Link Faults. 1.2. Run the LST RXBRANCH command to check whether attenuation of the RX channel of the RRU is configured as planned.
If it is not configured as planned, run the MOD RXBRANCH command to modify the configuration. If yes, go to step 1.3.
1.3. Check whether the ALM-26522 or ALM-26521 alarm is reported.

If either of the alarms is reported, clear the alarm by referring to the alarm help. If the ALM-26522 alarm cannot be cleared perform 2 to 6.
50
Troubleshooting RTWP Faults (Cont.)

Step 2. Check whether PIM interference exists
Step 2.1. Run the ADD CELLSIMULOAD command to add a simulated load. For example, ADD CELLSIMULOAD: LocalCellId=x, SimLoadCfgIndex=9; Step 2.2. Start RSSI tracing.
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 step 3.
Example of RSSI tracing result


Step 2.3. If PIM interference exists, use either of the following methods to determine the location or device where PIM is introduced:
Add a simulated load and shake the cable segments by segments from the RF unit top to the antenna port. If RSSI values change dramatically when shaking a segment, PIM interference is introduced by this segment. Breakpoint-based PIM detection
For example, set 4 breakpoints from the RF unit top to the antenna port, as shown in right figure. 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.
51

Step 3. Perform Broadband on-line frequency scan to check whether external interference exists.
Observe the scan result until the ALM-26239 is reported. Then, send the local tracing results, running logs of RF units, and investigation results to Huawei technical support for fault diagnosis.
Page102

Step 4. Check whether a crossed pair connection exists. The alarm caused by a crossed pair connection has following characteristics:
The alarm is reported in at least two sectors under the same eNodeB. RTWP variations of different RF channels are uncorrelated. RTWP variations are similar in different sectors.
Two methods for troubleshooting cells with a crossed pair connection

Perform drive tests and trace signaling without interrupting the services. Run the STR CROSFEEDTST command to start the a crossed pair connection test.
Page103
52

Handling Suggestion for a crossed pair connection
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, main-diversity, and diversitydiversity), several rounds of antenna adjustment may be required before the test result verifies no crossed pair connection.
Step 5. Check whether random electromagnetic interference exists.

If the fault is not caused by the preceding factors, it may be caused by random electromagnetic interference.
Page104
Troubleshooting ALD Link Faults

Fault Description
An ALD-related alarm is reported if there are ALD link faults in the RF
channels of an RF unit. Possible Causes

The setting of the ALD power supply switch is improper. The settings of the ALD current alarm thresholds are incorrect. The ALD connections are abnormal. The ALDs are faulty.
Fault Handling Procedure

Step 1. Rectify the faults and modify the improper settings. Step 2. If the fault persists, contact Huawei technical support.
53
Contents
Page106
License Faults
License faults are license-related alarms and faults that occur during eNodeB license installation or during network running. Possible Causes
Incorrect operations. Misunderstanding over the license mechanism. Errors in license files. Product defects.
Page107
54
Troubleshooting Flowchart
Page108
Troubleshooting License Faults That Occur During License Installation

Fault Description
The following error messages displayed in the MML command output means license installation fails:
License check failed; license serial number became invalid; the license file does not match the product; the license versions do not match. The license file has expired; the file type is DEMO. 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.
Possible Causes
The ESNs, VR versions, or product types do not match. The license file has expired or the license file type is incorrect. The system configuration items do not match the license control items.
55
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
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.
Page110
Typical Cases (Cont.)

Fault Handling
Step 1. Query the configured values on the eNodeB with the authorized values in the license file by DSP LICENSE command.
When the configured value on the eNodeB exceeds the allocated value in the license file, Data Configuration Exceeding Licensed Limit is displayed:
Page111
56
Typical Cases (Cont.)

Step 2. Check the functions not authorized by the license file.
Find the configuration items that are activated (the Config value is set to 1) on the eNodeB but not included in the license file.
Step 3. Reinstall the license.

Modify the eNodeB configuration, disable the functions not authorized by the license file. Or apply for a new license file that includes these function items and in which the allocated values are equal to or greater than the configured values on the eNodeB. Then, reinstall the license.
Page112
Troubleshooting License Faults that Occur during Network Running

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
Page113
57
Troubleshooting License Faults that Occur during Network Running (Cont.)

Possible Causes
Licensed Feature Entering Keep-Alive Period. Licensed Feature Unusable. License on Trial. No License Running in System. Data Configuration Exceeding Licensed Limit. License Emergency Status Activated. License Emergency Status Ceased.
Page114
Troubleshooting License Faults that Occur during Network Running See Remarks
Possible Causes
Licensed Feature Entering Keep-Alive Period. Licensed Feature Unusable. License on Trial. No License Running in System. Data Configuration Exceeding Licensed Limit. License Emergency Status Activated. License Emergency Status Ceased.
Page115
58
Troubleshooting License Faults that Occur during Network Adjustment

Fault Description
After a command was run to enable a function, a configuration activation failure occurred due to license restriction.
Example of a configuration activation failure due to license restriction
Page116
Troubleshooting License Faults that Occur during Network Adjustment

Possible Causes
No license is running on the eNodeB. 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.
Page117
59
Fault Handling Flowchart

Start Yes Clear the alarm Is the license configuration fault rectified? No Yes
Is there any licenserelated alarm? No
Do the configured values on the eNodeB match the allocated values in the license file? Yes Contact Huawei technical support.
No
Perform the procedure for troubleshooting license faults that occur during network running
Is the license configuration fault rectified? No
Yes
End
Page118
Summary
Page119
60
Thank you
www.huawei.com
61

Microsoft PowerPoint - 01 OEB404600 eNodeB V100R006 Troubleshooting ISSUE 1

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Microsoft PowerPoint - 01 OEB404600 eNodeB V100R006 Troubleshooting ISSUE 1

Hochgeladen von

Copyright:

Verfügbare Formate

eNodeB V100R005 Troubleshooting

eNodeB V100R006 Troubleshooting

Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved.

Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved.

Confidential Information of Huawei. No Spreading Without Permission

eNodeB V100R005 Troubleshooting

Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved.

General Troubleshooting Process

Contacting Huawei for Technical Support

Is the fault rectified?

Confidential Information of Huawei. No Spreading Without Permission

eNodeB V100R005 Troubleshooting

Fault Information Collection

Consult maintenance personnel

Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved.

LTE Fault Scope and Type

Confidential Information of Huawei. No Spreading Without Permission

eNodeB V100R005 Troubleshooting

Common Maintenance Function

Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved.

Contact Huawei for Technical Support

Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved.

Confidential Information of Huawei. No Spreading Without Permission

eNodeB V100R005 Troubleshooting

Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved.

Cell Unavailable Faults

ALM-29240 Cell Unavailable alarm is reported.

Confidential Information of Huawei. No Spreading Without Permission

eNodeB V100R005 Troubleshooting

Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved.

Troubleshooting Flowchart (Cont.)

Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved.

Confidential Information of Huawei. No Spreading Without Permission

eNodeB V100R005 Troubleshooting

Incorrect Data Configuration

Common incorrect data configuration causes

Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved.

Abnormal Transport Resources

Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved.

Confidential Information of Huawei. No Spreading Without Permission

eNodeB V100R005 Troubleshooting

Case for Abnormal Transport Resources

Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved.

Confidential Information of Huawei. No Spreading Without Permission

eNodeB V100R005 Troubleshooting

Case for Abnormal RF Resources

Limited Capacity or Capability

Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved.

Confidential Information of Huawei. No Spreading Without Permission

eNodeB V100R005 Troubleshooting

Case for Limited Capacity or Capability

Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved.

Case for Limited Capacity or Capability (Cont.)

Confidential Information of Huawei. No Spreading Without Permission

eNodeB V100R005 Troubleshooting

Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved.

Hardware Fault Handling Procedure

Handle the fault by alarm handling suggestion

Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved.

Confidential Information of Huawei. No Spreading Without Permission

eNodeB V100R005 Troubleshooting

Observe Panel Indicators

Copyright 2013 Huawei Technologies Co., Ltd. All rights reserved.