Microsoft PowerPoint - 01 OEB404600 eNodeB V100R006 Troubleshooting ISSUE 1

eNodeB V100R005 Troubleshooting

Confidential Information of Huawei. No

Spreading Without Permission 1

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





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

Page3

Start

Determining the fault scope and type

Identify fault causes

Rectify the fault

Is the fault rectified?

End

Contacting Huawei for Technical Support

Yes

No

Back up data.

Can the fault scopeand type be determined?

Yes

No

Collecting fault information




Copyright © 2013 Huawei Technologies Co., Ltd. All rights reserved. Page 4

Fault Information Collection

Information Item Collection Method

Fault symptom, as well as the time, location

and frequency of the occurrence

Consult the person reporting the fault, e.g,

customer service center

Equipment running status, fault symptom,

operations performed before the fault occurs,

and measures taken after the fault occurs and

the effect of these measures.

Consult maintenance personnel

Software/hardware running state of the

equipment

Observe the board indicators, the O&M

system, and the alarm management system

Scope and impact of the faultPerform service demonstration, performance

measurement, and interface/signaling tracing

Copyright © 2013 Huawei Technologies Co., Ltd. All rights reserved. Page 5

LTE Fault Scope and Type

eNodeB faults

Access faults

Service faults Service drop faults

Inter-RAT interoperability faults

Rate faults

Handover faults

Equipment faults

Cell faults

OMCH faults

License faults

Clock faults

Security faults

Radio frequency faults

� In this course, troubleshooting of equipment faults is discussed.




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

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


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: [email protected]

� Website: http://support.huawei.com the local Huawei office.

Page7





Contents









Page8


Cell Unavailable Faults

� Affected Factors

Page9

ALM-29240 Cell Unavailable alarm is reported.

Transmission Hardware Configuration RF

� 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


� 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.

Page14


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


� After a cell activation command was executed, the following output is

displayed.

Page16

� 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


� 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.

Page19





Faulty Hardware


� 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

Page21

START

Collect the fault info

through alarm browser

and MML command

Observe the panel

indicators

Determine the fault

type and area

Handle the fault by alarm

handling suggestion

Fault cleared?

END

Yes

Contact HuaweiNo

Useful commands:

DSP BRD

DSP RRU

DSP BRDVER

DSP VSWR

DSP CPRIPORT





Observe Panel Indicators

Page22


Observe Panel Indicators – See Remarks� BBU3900 Panel Indicators

Page23





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





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)

Page26

Lower layer faults will lead to higher layer faults


Troubleshooting IP Physical Layer Faults

� Step 1. Monitor the Ethernet port indicator status.

Page27

LED Color Status Description

Ethernet port

Green (LINK)

ONThe negotiation succeeds between the Ethernet port and the peer port

OFFThe negotiation fails between the Ethernet port and the peer port

Orange/Yellow (ACT)

Blinks fast The port is receiving or transmitting data.

OFF The port does not receive or transmit data.

� If the green indicator on either the local eNodeB or the peer switch is off,

go to the next step.





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.

Page28


Troubleshooting IP Physical Layer Faults (Cont.)

� 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.

Page29

Negotiate with peer

device, SET ETHPORT

to modify





Troubleshooting IP Physical Layer Faults (Cont.)

Page30

� 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


Troubleshooting IP Physical Layer Faults (Cont.)� 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.

Page31

� 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 GUI in M2000Rest by MML





Troubleshooting IP Link Layer Faults

� Step 1. Check packet transmitting and receiving on the eNodeB.

Page32

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.

� Run the DSP ETHPORT command

multiple times.


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.

Page33

� If the peer ARP entry is available on the eNodeB, you can infer that the fault is not

caused by the ARP entry.





Troubleshooting IP Link Layer Faults (Cont.)� 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


Troubleshooting IP Link Layer Faults (Cont.)

� Step 3. Check the VLAN configuration.

� Run the LST VLANMAP and LST VLANCLASS commands to check whether

the VLAN configuration is correct.

Page35

� 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.

� Run the STR

PORTREDIRECT

on the eNodeB





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





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





Contents









Page40


Troubleshooting Application Layer Faults

� Definition

� Application layer faults include unavailability and intermittent

disconnection of SCTP links, IP paths, and OM channels.

Page41





Troubleshooting Flowchart for Application Layer Faults

Page42


Troubleshooting SCTP Link Faults


� 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.

Page43





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.

Page44

the parameters in red rectangles

are eNodeB parameters and the

parameters in the blue

rectangles are EPC parameters


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.

Page45





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.

Page46

Check whether the DSCP value

is 46 in the QoS configuration

for the transmission network.


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





Troubleshooting IP Path Faults


� 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





Troubleshooting OM Channel Faults


� 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





Troubleshooting OM Channel Faults of in Typical Scenario

Page52

The eNodeBdisconnection can be found though Main Topology and Alarm Browser

• Step 1. Check the eNodeB Connectivity with M2000


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





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

Page54

“alive” indicate the connection between the eNB and the M2000 is secure


Troubleshooting OM Channel Faults of in Typical Scenario (Cont.)� Step 4: trace the route on M2000

Page55

The target IP is traceable!

The target IP is not traceable!

Example of traceroute IP address of a host





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.

Page57





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.

Page59





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

Page61

� If the eNodeB needs to lock an external clock source, set the clock working

mode to AUTO or MANUAL.





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.

Page62

� 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”.


Troubleshooting Synchronization Faults (Cont.)

� 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

� Login the IPCLK server to check the connectivity with eNodeB.

Page63

– LST IPCLKLINK to get

the IP clock server IP

address.





Troubleshooting Synchronization Faults (Cont.)� 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


Troubleshooting Synchronization Faults (Cont.)� 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.

Page65





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





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.

Page69





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.

Page71

Example of listing binding relationships





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.

Page72

Example of listing IKE negotiation results


Troubleshooting Procedure (Cont.)� Step 3. Check whether the IKE peer is correctly configured by

DSP IKEPEER command.

Page73

Example of listing IKE peer information

� If the values in the red frame are inconsistent with the network plan, run

the MOD IKEPEER command to change them.





Troubleshooting Procedure (Cont.)

� 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.

Page75

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






� Step 5. Continue

� Run the DSP APPCERT command to check whether the certificates

used for IKE and SSL are correct.

Page76

Example of listing certificates used for IKE and SSL



� Step 6. Check whether the IPSec proposal is correctly configured

by the DSP IPSECPROPOSAL command.

Page77

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.






� Step 7. Check whether the IPSec policy is correctly configured by

the DSP IPSECPOLICY command.

Page78

Example of listing IPSec policy information


frame are inconsistent with

the network plan, run the

MOD IPSECPOLICY

command to change them.



� Step 8. Check whether the ACL rule is correctly configured

by the LST ACLRULE command.

Page79

Example of listing ACL rule information


frame are inconsistent with

the network plan, run the

MOD ACLRULE command

to change them.





Typical Case


� 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





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





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.

Page84

Principle of a VSWR test


PIM (Passive Inter-Modulation) Interference

� What is PIM interference?

Page85

an example of a PIM result





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





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





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

Page91

An RF unit is faulty.

Is the fault caused by

VSWR faults?

No

Does the RF unit

work properly?

No

Is the fault

caused by ALD

link faults?

No

Is the fault

caused by RTWP

faults?

No

Contact Huawei technical

support.

End

Troubleshoot VSWR

faults.

Yes

Troubleshoot RTWP

faults.

Yes

Troubleshoot ALD link

faults.

Yes

Does the RF unit

work properly?

No

Does the RF unit

work properly?

No

Yes

Yes

Yes





Troubleshooting VSWR Faults


� 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.

Page93

� If the threshold is

improper, change

it by running the

MOD RRU

command.

� Run the LST RRU command

to query the VSWR alarm

threshold of the RF unit.





Troubleshooting VSWR Faults (Cont.)

� Step 3. Check the current VSWR value.

� a. Run the DSP VSWR command to query the current VSWR value.

Page94

� b. Run the STR VSWRTEST command to query the offline VSWR

value.



� 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






� 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.

Page97





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.

� 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.

Page99

� If it is not configured as planned,

run the MOD RXBRANCH

command to modify the

configuration.

� If yes, go to step 1.3.





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.

Page100

Example of RSSI tracing result

�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.


Troubleshooting RTWP Faults (Cont.)� 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

Page101

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.






� 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


Troubleshooting RTWP Faults (Cont.)� 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






� 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 diversity-

diversity), 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


� 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.

Page105





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





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.

Page109





Typical Cases


� 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





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





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





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.

Page116

Example of a configuration activation failure due to license restriction


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





Fault Handling Flowchart

Page118

Start

Is there any license-

related alarm?

No

Is the license

configuration fault

rectified?

No

Do the configured

values on the eNodeB

match the allocated values

in the license file?

Contact Huawei technical support.

End

Clear the alarmYes

Perform the procedure

for troubleshooting

license faults that occur

during network running

No Is the license

configuration fault

rectified?

No

Yes

Yes

Yes


Summary









Page119




Thank youwww.huawei.com

Date post:	21-Oct-2015
Category:	Documents
Upload:	javadiaz
View:	176 times
Download:	16 times

Microsoft PowerPoint - 01 OEB404600 eNodeB V100R006 Troubleshooting ISSUE 1

Documents