Professional Documents
Culture Documents
Issue 01
Date 2011-08-11
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
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 the warranty of any kind, express or implied.
Change History
This chapter describes the changes in the RAN Troubleshooting Guide.
01 (2011-08-11)
This is the first commercial release of RAN12.0.
Contents
1 Overview
1.1 Purpose
This document provides information on how to identify and repair common faults on RAN
devices that are working in a live network. Operation and maintenance (OM) personnel
should use this guide in the following scenarios:
z User complaints are received.
z Faults are detected in the routine maintenance processes.
z Emergency faults are detected in the equipment.
1.3 Organization
This guide consists of the following chapters:
z Chapter 1 Overview
z Chapter 2 Troubleshooting Process and Methods
z Chapter 3 Guide to Collecting Fault Information
z Chapter 4 RNC Troubleshooting
z Chapter 5 NodeB Troubleshooting
z Chapter 6 Troubleshooting Transmission Faults
2.2.4 Troubleshooting
To repair faults and restore the system, troubleshoot different faults using proper measures
and procedures. Troubleshooting consists of checking cables, replacing boards, modifying
data configuration, switching over boards, and resetting boards.
Ensure notes are recorded in a logbook or other method that OM personnel will have future access to.
http://support.huawei.com contains contact information for the local office in your region.
NOTE
If the services in one NodeB are affected, it is not an emergency fault.
Process Description
When emergency situations occur, follow these three steps:
1. Check associated alarms and operation logs.
Check associated alarms to identify, isolate, and roll back the services rapidly and efficiently.
Application Scenarios
Original information provides an important reference for determining the scope and type of
the faults. In the initial phase of troubleshooting, original information provides a reference for
determining the fault scope and determining possible locations of the faults. Senior OM
personnel are able to locate faults using original information.
Instructions
Original information can be applied to troubleshooting both network element faults and other
faults such as E1T1 faults. In the trunk troubleshooting process, you must connect to the
transport system and map the signaling. Therefore, original information such as whether the
transport system works properly, whether the peer end parameters are modified, and the
definitions of some signaling parameters is vital to the troubleshooting and repair of the faults.
Application Scenarios
Alarms can help in handling equipment faults and service faults.
Instructions
See the local maintenance terminal (LMT) online help for instructions on the alarm system.
See the related online help in the alarm management system for detailed troubleshooting
methods of each alarm.
Application Scenarios
LED status is used to locate the general area of the fault. LEDs can indicate a specific fault or
can be used to locate other faulty equipment. All information gathered from LEDs can be used
to facilitate later operations. After observing the LED status of a board, circuit, link, or node,
check any associated alarms.
Instructions
For details about the board LED status, see the related online help section in the related
hardware description.
Application Scenarios
User tracing can locate recurring faults in call services.
Instructions
For instructions on user tracing, see the OM online help.
Application Scenarios
Interface tracing can locate faults in calls, for example, low put-through rate of calls in a
commercial network.
Instructions
For instructions on interface tracing, see the LMT online help.
Application Scenarios
Traffic statistics are applied to KPI analysis and performance analysis.
Instructions
Traffic statistics can be obtained through the M2000 or Nastar.
Application Scenarios
Comparison and interchange are used when faults occur after NE hardware, software or a new
feature is introduced that may have caused a service outage.
Instructions
Use this method to compare the performances and KPIs before and after hardware or software
is changed, or a new feature is introduced.
Application Scenarios
An upgrade is recommended when the current version has bugs that are fixed in later versions.
A rollback is required when the updated version causes KPIs to deteriorate or services to be
interrupted.
Instructions
For details, see the relevant upgrade guide.
Type a valid backup file pathname, and press Enter to begin the backup. If the message
"Backup OMU database succeed!" is displayed, then the database has been successfully
backed up on the OMU, as shown in the following figure.
---End
The LST LOGRSTINFO command will query and display the specific path of the saved
logs.
---End
---End
---End
On the Other tab, finish the tracing and recording configuration, as shown in the following
figure.
For data transmission faults, ensure that faults that occur in the first 100 seconds are traced. If no fault
appears in the first 100 seconds, restart tracing.
---End
2. Choose a log file and then click Download. The file is saved in the default directory
Root\bam\common\MeasResult or a designated directory.
---End
---End
User Tracing
1. Log in to the LMT, double-click User to start user tracing.
2. Set Trace Method. If no drive test UE is available, select Chain Time, and the system will
randomly trace less than four UEs. If drive test UE is available, select IMSI.
a. Set Chain Time for user tracing, as shown in the following figure.
Note that the Begin Time must be the same or earlier than the current time, and the End
Time should be around 24 hours later.
3. On the IUB and UU tabs, select the CDT items to be traced, and enter the parameters, as
shown in the following two figures.
4. Select Autosave on the Basic tab page, enter a saved path in File Name, and click OK to start
tracing.
The following figure shows the report of the traced CDT messages.
---End
a. Collect the NodeB CHR using computer onsite. Use this method only if you can log in to
the NodeB directly through the LMT.
Run the following commands:
SET CHRSW: CHRSW=ON, CHRTYPE=ALL, IP=XX.XXX.XXX.XXX,
DSTF=X:\CHRDATA\, USR=admin, PWD=admin;
SET CHRLEVEL: CHRLEVEL=DETAIL; CHRUSERTYPE=ALL USERTYPE;
Ensure that the IP is the IP address of the computer, and the user name and password are
correct. When using the FTP software provided with the NodeB LMT, the user name and
password are admin. The path X:\ CHRDATA must be set up in advance.
b. Do as follows to collect the NodeB CHR through the FTP client of the M2000. Use this
method only if you can log in to the NodeB LMT using the M2000 client.
Run the following command:
SET CHRSW: CHRSW=ON, IP=XX.XXX.XXX.XXX, DSTF="/export/home/sysm",
USR="ftpuser", PWD="ftpuser";
c. Do as follows to collect the NodeB CHR through the RNC BAM FTP server. Use this
method only if you can upload data through the RNC BAM FTP server:
Run the following command:
SET CHRSW: CHRSW=ON, IP=XX.XXX.XXX.XXX, DSTF=/ftp/, USR=FtpUsr,
PWD=XXXXXXXX;
Note that the path of the BAM FTP server must be one of the following two:
D:\WCDMA RNC\BAM\VersionA\FTP
D:\WCDMA RNC\BAM\VersionB\FTP
4. Six minutes after the command is executed, check whether any logs are uploaded to the path
D:\CHRDATA before the test.
5. After the NodeB CHR is completely uploaded, run the following command to turn off the
CHR function:
SET CHRSW: CHRSW=OFF; SET CHRLEVEL: CHRLEVEL=NONE;
Note that the NodeB CHR collected through the second or third method can be retrieved from
the FTP server.
---End
2. Click Open, and double-click the XXX.pyc file on the desktop, as shown in the following
figure.
The following figure shows an example of the preceding operations being successful.
3. Right-click the blank area and choose to save the exported results.
Collecting the DSP memory will be used as an example to describe this process.
a. Double-click the BdamDumpOneDspMemory.pyc file provided by the Research and
Development personnel. Enter the parameters as shown in the pink circled area in the
following figure:
b. Upload the board logs for the baseband processing board after running the script. See
section 3.6.3 "Collecting NodeB Main Board and Board Logs" for more details.
---End
Choices are available for the alarm types, event types, and sites.
3. Enter the name of the file to be uploaded in the displayed dialog box. Click to select
Compress Upload which reduces upload time. Name the file in the site name + date format
to make it different from previously downloaded files.
Click OK to begin the upload of NodeB WMPT log to the M2000 server.
4. Click NM Server, and choose the corresponding NodeB in the left pane.
6. Choose Transfer > From NM to Client, specify a path. When the process starts, the selected
file will be uploaded to the local computer.
---End
3. Choose the NodeB and configuration file in the displayed window. When the process starts, a
configuration file is downloaded to the M2000 server.
Select the downloaded file in the file list under Data. Choose Transfer > From NM to NE,
and the configuration file is sent to the NodeB through the M2000.
---End
z Check whether the upgrade-related software has been uploaded to the M2000 server.
z Contact Huawei for technical support before a batch upgrade.
To upgrade the NodeBs in batches, do as follows:
1. Choose Software > NE Upgrade Task > NE Upgrade Task, as shown in the following
figure.
Click the > icon in the dialog box, as shown in the following figure.
Click Next to select the software version and operation settings. Click Finish to start the
upgrade.
---End
and downloading files. In this situation, change the FTP server address of a NodeB to the IP
address of the M2000 OMC.
1. Choose Software > File Server Setting to open the File Server Setting window.
2. Select the NodeB in the left pane. If you select RNC, information of all the NodeBs under the
RNC is displayed.
3. Set the file server in the File Server Name column. If the files cannot be uploaded or
downloaded when the file server is configured in the RNC BAM, change the file server
setting to that of the M2000. The M2000 is the OMC, and appears in the File Server Name
column in the following figure.
---End
Method 1: Log in to the NodeB directly through the M2000 if your computer is running the
corresponding LMT.
Right-click the selected NodeB, and choose Maintenance Client from the drop-down menu.
The M2000 automatically logs in to the NodeB using the LMT, as shown in the following
figure.
Method 2: Log in to the NodeB through the configured M2000 proxy server.
1. Set the NodeB information on the LMT, as shown in the following figure.
2. Select Proxy Server, and ensure that the Proxy Server IP address is set to that of the M2000.
3. Enter the user name and password for the M2000, and then click Login, as shown in the
following figure.
---End
2. Enter the user name and password for the M2000 and click Login.
3. Select the NodeB in the displayed dialog box and click OK.
---End
4 RNC Troubleshooting
z If Reason of the latest cell setup failure is NCP unavailable or CCP unavailable, the
link that carries the NCP or CCP may be faulty. Check whether an alarm related to the
corresponding SAAL (for ATM transmission) or SCTP (for IP transmission) link is
reported. If such an alarm is reported, clear the alarm according to the instructions in the
alarm reference.
z If Reason of the latest cell setup failure is FP synchronization failure or Common
channel setup failure, the user-plane transmission bearer may be faulty. Check whether
a path alarm is reported. If such an alarm is reported, clear the alarm according to the
instructions in the alarm reference. If no path alarm is reported, check whether the path
negotiation parameters on both the RNC and NodeB are configured correctly and
whether the transmission over the Iub interface is normal.
z If Reason of the latest cell setup failure is Power mismatch, check whether the local
cell on the NodeB side is available. If the local cell is unavailable and the alarm
ALM-4033 Local Cell Unusable is reported, clear the alarm according to the instructions
in the NodeB alarm reference. If the local cell is available, check the maximum downlink
power configured on the NodeB and RNC. If the power configured on the NodeB is
smaller than that on the RNC, change the maximum downlink power on either the
NodeB or RNC so that that the power configured on the NodeB is greater than or equal
to that on the RNC.
Run the LST UCELL command on the RNC LMT to query the maximum downlink
power on the RNC side. The following is shown as an example:
Run the LST LOCELL command on the NodeB LMT to query the maximum downlink
power on the NodeB side. The following is shown as an example:
z If Reason of the latest cell setup failure is NodeB return cell setup failure and cause
is "NodeB sends CELL SETUP FAILURE (Frequency acquisition not supported)" in the
location information about the alarm ALM-22206 Cell Setup Failure, check whether the
frequency configurations on the RNC and NodeB are consistent.
Run the LST UCELL command on the RNC LMT and the LST LOCELL command on
the NodeB LMT to query the frequency configurations.
z If Reason of the latest cell setup failure is Local cell not reported and cause is "Data
configuration error or inconsistent with physical resources" in the location information
about the alarm ALM-22206 Cell Setup Failure, check whether the NodeB is configured
with a corresponding local cell and whether the local cell ID on the RNC and NodeB is
consistent. Run the LST UCELL command on the RNC and the LST LOCELL command
on the NodeB to query the local cell ID.
z If Reason of the latest cell setup failure is Common channel setup failed and reason
of the latest common channel setup failure is "L2 resource allocation failed", log in to the
RNC LMT. View the BSC Device Panel window and check whether DPUs can be
detected. If no DPUs can be detected, insert new DPUs. If DPUs can be detected but are
unavailable, replace them with new ones.
Log in to the RNC LMT. Run the LST LICENSE command and set FN to the file name of
the current license to check the license items. If IP transmission is used over the Iub interface,
IP Transportation in Iub Interface should be ON; if IP/ATM dual-stack transmission is
used over the Iub interface, IUB ATM/IP Dual Stack Transportation Function should be
ON, as shown in the following figure:
+++ WCDMA-RNC 2011-08-09 19:53:28
O&M #138901
%%LST LICENSE:;%%
RETCODE = 0 Execution succeeded.
List License File Information
-----------------------------
File LicenseFileName IsCurrentLicense
1 Demo_BSC6900_V900R013_UO_20110727.dat Y
2 license.dat N
(Number of results = 2)
= Enhanced Iu Flex=ON
= Streaming Traffic Class on HSUPA=ON
= IUB ATM/IP Dual Stack Transportation Function=ON
If you still cannot locate the cause of the problem after performing the preceding procedure,
collect information using the following table and contact Huawei technical support:
z Iu-related configurations, set by running the ADD TRMMAP, ADD ADJMAP, and ADD
UCNNODE commands, are incorrect or deleted.
z The SPU boards or interface boards are faulty.
z The Service Area Codes (SACs), Routing area codes (RACs), and Location Area Codes
(LACs) of some cells are not configured on the CN side.
z Resources of certain cells, such as power, code, transmission, and channel element (CE)
resources, are congested.
7. Locate and check the SPU subsystem and interface board that serves the faulty cells. If most
of these cells are served by the same board, perform an active/standby switchover on the
board.
8. Run the DSP UCELL command to check the cell status. If the Operation state of the cell is
Unavailable, check the fault reason.
If the cell is not activated, run the ACT UCELL command to activate the cell. If the cell
setup fails, refer to section 4.1 for troubleshooting.
If the Operation state is Available, run the LST UCELLACCESSSTRICT command to
check whether the cell or user Access Class (AC) is barred, as shown in the following figure.
If Access class x barred indicator or Cell barred indicator for SIB3 is BARRED, change
it to NOT_BARRED.
Run the DSP UCELLCHK command to check whether the power, code, transmission, or CE
resources of the cell are congested, as shown in the following figure.
z Power congestion
Power congestion may be on the uplink or downlink. Run the LST UCELLALGOSWITCH
command to query the call admission control (CAC) algorithm in use.
If the access failure is caused by uplink power congestion, check whether the RTWP is within
the valid range (–96.5 dB to –105.5 dB).
Check whether Auto-Adaptive Background Noise Update Switch is ON. If so, deactivate
the cell, and then re-activate the cell to check whether the RTWP becomes normal.
If Auto-Adaptive Background Noise Update Switch is OFF, turn off the uplink CAC
switch or reset the background noise value.
To turn off the uplink CAC switch, run the following command:
MOD UCELLALGOSWITCH: NBMUlCacAlgoSelSwitch=ALGORITHM_OFF
To reset the background noise value, check the average RTWP value (indicated by
VS.MeanRTWP) in the performance statistics, and set the background noise value to the
minimum VS.MeanRTWP. An example command is as follows:
MOD UCELLCAC: BackgroundNoise=61;
The default value of BackgroundNoise is 61. The parameter value depends on the onsite conditions and
is calculated with this formula: Background noise = 112 + BackgroundNoise x 0.1.
If the access failure is caused by downlink power congestion, check the latest Transmit
Carrier Power (TCP) value and run the LST UCELLCAC command to query the service
admission threshold. If the TCP value exceeds the threshold, the access fails. Check whether
the admission threshold is configured according to the baseline data or network planning data.
If not, change the admission threshold to the correct value. Otherwise, consult Huawei
network planning engineers about whether to adjust the threshold or expand the capacity.
z Code congestion
Check whether the Cell code used rate is normal, and trace the code tree to check whether the
cell uses too many code resources. If the minimum available codes are more than the DL
handover reserved spreading factor (SF), the cell capacity is limited and needs to be expanded.
The smaller the SF, the higher the service rate. For example, if the available minimum SF is
SF32 but the configured reserved SF is only SF16, the admission
fails.
Alternatively, you can run the LST UCELLCAC command to check whether the reserved
code of the cell is configured according to the baseline data or the network planning data. If
the reserved SF is too small (for example, SF4), change it according to the baseline data.
Otherwise, consult Huawei network planning engineers about whether to adjust the SF or to
expand capacity.
Newly admitted users cannot use reserved SFs. As a result, the smaller the SF, the fewer code resources
available for newly admitted users.
z Transmission congestion
Run the DSP UCELLCHK command to check whether the Iub interface of the cell is
congested.
If the Iub interface is congested, check whether the reserved bandwidth for the AAL2 path is
within the valid range. By default, the reserved bandwidth is 0, indicating that no bandwidth
is reserved.
Run the LST TRMFACTOR command to check whether the values configured for service
activation factors are within the valid ranges. For best results, these parameters should be set
to their recommended values.
For PS services, run the LST UUSERGBR command to check whether the guaranteed bit
rate (GBR) is configured according to the baseline data. If the GBR value is too large (such as
384 kbit/s), consult the network planning engineers about whether to decrease the GBR or
adjust the bandwidth. The GBR and bandwidth adjustment is subject to the approval of the
operator.
z CE congestion
Run the DSP UCELLCHK command to check whether CE resources of the cell are
congested. CE congestion can be eliminated by purchasing more CE licenses or deploying
more sites for traffic sharing.
9. Check whether the LAC/SAC/RAC data is configured on the CN side (MSC/SGSN). If the
data is not configured, UEs cannot register or attach themselves to the network. You can trace
the intelligent optimum sample (IOS) of the cell to check whether a UE can register or attach
to the network.
When the LAC/SAC/RAC data is not configured on the CN side, the initial direct transfer messages sent
by the RNC are not responded or are rejected and the signaling connection control part (SCCP)
connection setup fails. As a result, the UE cannot access the network.
10. Check whether the AAL2Path or IPPATH is available and configured correctly.
Run the LST TRMMAP command to check whether the transmission mapping is set
correctly. For example, CS services map RT paths (primary paths) and NRT paths (secondary
paths); R99 PS services map NRT paths (primary paths) and RT paths (secondary paths);
HSPA services map HSPA NRT paths. High Speed Downlink Packet Access (HSDPA)
services and High Speed Uplink Packet Access (HSUPA) services can share the same
TRMMAP. Run the LST AAL2PATH or LST IPPATH command to check whether the
mapped path in the TRMMAP is configured.
According to the preceding results, the CS services can be set up only after an ATMRT path or
HQ_IPRT path is configured.
11. If you still cannot locate the cause of the problem after performing the preceding procedure,
collect information using the following table and contact Huawei technical support:
Iu interface tracing result file Trace the signaling (RANAP and LMT tracing files
SCCP) over the Iu interface for 5
minutes. If the CS services are
interrupted, the destination
signaling point (DSP) is the MSC;
if the PS services are interrupted,
the DSP is the SGSN.
5 NodeB Troubleshooting
Note that there are two types of TMAs: 12-dB TMA and 24-dB TMA. The value for TMA Gain is fixed
and can be found in the TMA product document.
Feeder loss needs to be calculated based on the length and type of feeder; this information can
be found in the feeder product document.
3. Check whether there is passive intermodulation.
Run the SET TXSW command to shut down the transmit channel. If the RTWP value then
returns to normal, the RTWP abnormality may be caused by the passive intermodulation.
Check the main feeder connection.
If the RTWP value does not return to normal after the shutdown, go to step 4.
4. Check the number of HSUPA subscribers.
Log in to the RNC LMT, and choose Monitor > UMTS Monitoring > Cell Performance
Monitoring. Check whether the number of HSUPA users exceeds 10. If so, ignore this
problem because a large number of HSUPA users usually lead to a high RTWP value.
If the number of HSUPA users is less than 10, go to step 5.
6. If you still cannot locate the cause of the problem after performing the preceding procedure,
collect information using the following table and contact Huawei technical support:
The value for Desensitization Run the DSP RFDESPARAM and DSP DESENS MML reports
Intensity commands.
The value for Attenuation of Run the LST RXATTEN command. MML reports
RX Channel
TMA Gain Run the LST TMAGAIN command. MML reports
Whether the RTWP values of Run the STR RTWPRTTST command or choose Tracing logs or
the local cell and its Maintenance > Realtime Specific Monitoring > Board RTWP data
neighboring cells are RTWP.
abnormally high
Traffic Check the counters related to the cell traffic. The counter data or
report
Whether there is passive Run the SET TXSW command to shut down the The RTWP value
intermodulation transmit channel. Check whether the RTWP value
returns to normal.
WMPT logs of three On the M2000, choose Software > Software Browser > NE. NodeB WMPT
NodeBs for which the Select the corresponding NodeB and click Other on the right side logs
license delivery fails of the window. Right-click the log to be uploaded and choose
From NE to OMC Server from the shortcut menu.
On the left side of the window, click OMC Server. Select the
corresponding NodeB and click Other on the right side of the
window. Right-click the log to be downloaded to the local PC and
choose Transfer > From NE to OMC Client.
A screen capture for the When the license delivery fails, save the screen capture of the A screen
license delivery failure current window in .jpg format. capture for the
license delivery
failure
A screen capture for the Double-click the NodeB with delivery failure and save the screen A screen
detailed cause of the capture of the displayed window in .jpg format. capture for the
license delivery failure detailed cause
of the license
delivery failure
License file to be Obtain the license file to be delivered in .dat format. License file to
delivered be delivered
The alarm ALM-21581 Path Fault is reported if an IP path is under a ping test.
Possible Causes
z Ethernet cables or optical cables may be incorrectly connected or faulty.
z The negotiation mode of the Ethernet ports on the NodeB or RNC is inconsistent with
that of the Ethernet ports on devices interconnected with the NodeB or RNC.
z Virtual local area network (VLAN) configurations and Address Resolution Protocol
(ARP) security-related configurations are incorrect.
z Route configurations are incorrect or exceptions occur on the devices involved.
z The Quality of service (QoS) policy for the transport network is inappropriate.
Troubleshooting Methods
If IP transmission on an FE port is interrupted, analyze reported alarms and events, conduct
ping tests, trace IP packets, query the ARP tables by running the DSP ARP command, or
query the routing tables by running the DSP IPRT command.
The section Troubleshooting Procedure provides guidelines for checking whether faults occur
at the physical, data link, or IP layer.
For details on how to conduct a ping test and how to trace IP packets, see section 6.1.3 "Verification
Methods."
Troubleshooting Procedure
1. Troubleshoot the physical layer.
Check whether the duplex mode for Ethernet ports on the NodeB is consistent with that on the
RNC, whether Maximum Transfer Unit (MTU) configurations are appropriate, and whether
there are errors in the IP packets received by the RNC and NodeB. For details, see section
6.1.3 "Verification Methods."
Check whether optical cables are connected correctly. Remove one optical cable from the
transmit end and check whether a relevant alarm is generated on the receive end. If a relevant
alarm is generated, the cable is properly connected.
2. Troubleshoot the data link layer.
Check whether VLAN configurations are correct. For two interconnected devices, VLAN IDs
between interconnected ports on the two devices must be consistent. Otherwise, the two
devices cannot communicate with each other. Further, note the following:
z If load sharing and VLAN are applied to ports on the active and standby boards of the
RNC, VLAN IDs between these ports must be the same. You can add a VLAN ID to a
specific port by running the ADD VLANID command.
z If a VLAN is applied to the NodeB, a VLAN must be also applied to Stream Control
Transmission Protocol (SCTP) links, IP paths carrying user data, common channels
carrying user data, and O&M channels. If an IP clock is configured, a VLAN must be
applied to IP clock links, and the VLAN IDs of these links must be consistent with the
network plan. If the NodeB is configured with multiple next hops, you must distinguish
them according to the network plan when applying the VLAN to the NodeB. You can run
the LST VLANMAP and LST VLANCLASS commands to query VLAN
configurations for the NodeB.
Check whether there are ARP tables corresponding to the RNC, NodeB, and router.
3. Troubleshoot the IP layer.
Check whether IP route configurations are correct and whether these configurations have
taken effect. Devices whose IP addresses belong to different network segments must be
configured with routers.
Check whether the local end is correctly connected to the peer end, and whether the two ends
are correctly connected to the gateway by conducting IP tests. When conducting an IP test,
you are advised to use IP packets with different packet sizes and different differentiated
services code point (DSCP) values. For details, see section 6.1.3 "Verification Methods."
Locate faults by tracing IP packets. For details, see section 6.1.3 "Verification Methods."
If you are not sure whether faults occur on universal terrestrial radio access network (UTRAN) devices
or in the transport network even though you have ensured that configurations are correct and appropriate,
connect a PC to the NodeB or RNC to narrow down areas where the faults may occur.
4. If you still cannot locate the cause of the problem after performing the preceding procedure,
collect information using the following table and contact Huawei technical support:
RNC and NodeB Run the RNC MML command EXP CFGMML to WMPT logs, RNC
configuration files obtain RNC configurations, and obtain the NodeB configuration file, and
configuration file using the LMT or M2000. alarms reported on the RNC
Networking and cable Check cable connections and the security and Detailed networking
connections reliability of the networking.
Ethernet port status Run the LST ETHPORT and DSP ETHPORT Execution results
commands on the RNC or NodeB LMT to check
the Ethernet port status.
ARP tables Run the DSP ARP command on the RNC or Execution results
NodeB LMT to check ARP tables.
Routing tables Run the LST IPRT and DSP IPRT commands on Execution results
the RNC or NodeB LMT to check routing tables.
Pinged IP packets Ping the RNC or NodeB IP address using IP Execution results
packets with different packet sizes and different
DSCP values.
Traced IP packets Run the RNC MML command TRC IPADDR to Execution results
trace IP packets, and run the NodeB MML
command TRACERT to trace IP packets.
Configurations and QoS Check configurations, QoS policy, bandwidth Operation results
policy of the transport utilization, and congestion condition of the
network transport network.
Possible Causes
z There is strong interference due to poor cable quality.
z The negotiation mode of Ethernet ports on the NodeB or RNC is inconsistent with that of
Ethernet ports on the interconnected device.
z QoS policy for the transport network is inappropriate.
z Bandwidth or data rate is limited.
z Faults occur on the transport network or on the devices involved.
Troubleshooting Methods
If some IP packets are lost, analyze the reported alarms and events, conduct ping tests, or
trace IP packets.
The section Troubleshooting Procedure provides guidelines for checking whether faults occur
at the physical, data link, or IP layer.
For details on how to conduct a ping test and how to trace IP packets, see section 6.1.3 "Verification
Methods."
Troubleshooting Procedure
1. Troubleshoot the physical layer.
Check whether parameter settings for Ethernet ports on the NodeB or RNC are consistent
with those for Ethernet ports on the interconnected device, whether MTU configurations are
appropriate, and whether there are errors in the IP packets received by the RNC and NodeB.
For details, see section 6.1.3 "Verification Methods."
Check whether Ethernet cables are functioning correctly. Replace one Ethernet cable with a
new one and check whether IP packets are received correctly. If no IP packets are lost, the
replaced Ethernet cable was the cause of the problem. If some IP packets are still lost, the
replaced Ethernet cable is not faulty.
Check whether optical cables are correctly connected to receive ports, transmit ports, active
ports, or standby ports on devices. Ensure that cables do not cross. If you still cannot locate
the fault, connect a PC to the NodeB or RNC to narrow down areas where faults may occur.
2. Ping all the involved routers, the RNC, and the NodeB in sequence.
If some packets are lost when you ping the NodeB from the RNC, ping all the involved
routers and the NodeB in sequence to locate the device where these packets are lost. You can
also perform these operations on the NodeB if some packets are lost when you ping the RNC
from the NodeB.
Conduct IP tests to check whether the local end is connected correctly to the peer end and
whether the two ends are connected correctly to the gateway. When conducting an IP test, use
IP packets with different packet sizes and different DSCP values. For details, see section 6.1.3
"Verification Methods."
3. If you still cannot locate the cause of the problem after performing the preceding procedure,
collect information using the following table and contact Huawei technical support:
RNC and NodeB configuration Run the RNC MML command WMPT logs, RNC
files EXP CFGMML to obtain RNC configuration file,
configurations and obtain the and alarms reported
NodeB configuration file using on the RNC
the LMT or M2000.
Networking and cable connections Check cable connections and Detailed networking
the security and reliability of
the networking.
Ethernet port status Run the LST ETHPORT and Execution results
DSP ETHPORT commands on
both the RNC LMT and
NodeB LMT to check the
Ethernet port status.
Pinged IP packets Ping the RNC or NodeB IP Execution results
address using IP packets with
different packet sizes and
different DSCP values.
Traced IP packets Run the RNC MML TRC Execution results
IPADDR command to trace IP
packets and run the NodeB
MML TRACERT command to
trace IP packets.
Configurations and QoS policy of Check configurations, QoS Operation results
the transport network policy, bandwidth utilization,
and congestion condition of
the transport network.
Port No. must be set to the port number of the Ethernet port.
Run the DSP ETHPORT command on the NodeB LMT to query the properties of an
Ethernet port, as shown in the following figure:
Port No. must be set to the port number of the Ethernet port.
Clear Statistic specifies whether to clear statistic values from the execution results after the command is
executed.
Max transmit unit indicates the maximum size of data that can be transmitted over the
Ethernet port. Currently, this parameter is consistently set to 1500 on all UTRAN devices. For
devices in the transport network, this parameter must be set to a value greater than 1500.
Speed and Duplex indicate the working mode of the Ethernet port. If the RNC is
interconnected with another device, the duplex mode of this port must be consistent with that
of the corresponding port on the interconnected device. Otherwise, some packets may be lost,
errors may occur in received IP packets, or services may be interrupted.
Link Availability Status indicates the current link status. If the value is Unavailable, the IP
transmission is interrupted.
Rx correct bytes indicates the size of correct packets received by this port and Tx correct
bytes the size of correct packets transmitted from this port. By comparing the execution
results of the DSP ETHPORT command from each time, you can determine whether this port
is transmitting and receiving packets correctly.
Rx bad bytes indicates the size of incorrect packets received by this port and Tx bad bytes
the size of incorrect packets transmitted from this port. If values of these two parameters are
not 0, this port has received or transmitted incorrect packets.
Ping
You can ping the NodeB on the RNC or ping the RNC on the NodeB.
1) Theory
When you ping the peer end from the local end, an Internet Control Message Protocol (ICMP)
echo request packet is automatically sent to the peer end. Upon receiving the packet, the peer
end responds with an ICMP packet.
With the Ping function, O&M personnel can check whether a device is connected correctly to
the transport network, whether transmission is stable, whether transmission delay or variation
occurs, and whether packets are correctly transmitted and received. In addition, by pinging all
the involved devices one by one, O&M personnel can locate faults accurately and efficiently.
If you ping another device on the RNC, set the size of ICMP packets, TTL value, DSCP value,
number of ping tests, test frequency, and response expiration threshold. If you ping another
device on the NodeB, set the size of ICMP packets, DSCP value, number of ping tests, and
response expiration threshold.
Set Size of packet to 20, 500, or 1500 and use the DSCP value of 48, 46, 38, 22, 14, or 0 to
perform a ping test. If possible, try all of these values.
2) Example
The following operations are performed on the RNC LMT.
Run the RNC MML command PING IP with Source IP address, Destination IP address,
Subrack No., and Slot No. set to appropriate values. Set Differentiated services code point
to an appropriate value if you want to check whether a specific ICMP packet with a certain
DSCP value is transmitted or received correctly.
The following figure shows the interface where you can set the preceding parameters:
Parameter Meaning
Parameter Meaning
As shown in the preceding figure, the delay is shorter than 80 ms, and no packets are lost
because the number of transmitted packets equals the number of received packets.
The following figure shows the execution results of the command when exceptions occur in
the transport network:
As shown in the following figure, the message "Request time out" is displayed, which
indicates that some packets are lost:
As shown in the preceding figure, if the value of time is greater than 80 ms, the transmission
delay is long. If the value fluctuates with a large difference (for example, over 30 ms), delay
variation occurs. If the message "Request time out" is displayed multiple times, transmission
is interrupted.
Ping test results not only expose faults in the network but also provide the type and severity of
the problem. For example, if some packets are lost, you can figure out a packet loss rate based
on the number of transmitted ICMP packets and the number of received ICMP packets. This
loss rate tells you the severity of the problem.
4) Notes
If you want to check whether IP transmission is interrupted, set Packet Number to a value
greater than 1000 to ensure accurate test results.
Traceroute
1) Theory
Traceroute enables users to obtain next hops on an IP path between the transmit end and
receive end by using ICMP expired packets, ICMP unreachable packets, and the TTL field in
headers of IP packets. If the transmit end sends a router an IP packet with a TTL value of 0,
the router discards the packet and responds with an ICMP expired packet. The transmit end
can then obtain the IP address of this router. By sending ICMP unreachable packets, the
transmit end determines whether packets have reached the destination router. If the receive
end cannot receive IP packets, you can specify the maximum TTL value and then trace IP
packets to locate faults accurately and efficiently.
2) Operation
The following operations are performed on the RNC LMT.
Run the RNC MML command TRC IPADDR, as shown in the following figure:
Parameter Meaning
Parameter Meaning
Then, increase the TTL value next time you trace IP packets. If tracing results are displayed as
asterisks when a specific TTL value is used, the corresponding next hop is faulty.
The alarm ALM-21581 Path Fault is reported if a continuity check (CC) test is conducted on permanent
virtual circuits (PVCs).
Possible Causes
E1/T1 cables or optical cables are improperly connected or become faulty.
PVC layer configurations are incorrect.
QoS policy is incorrect.
Exceptions occur on all the devices involved.
Troubleshooting Methods
If ATM transmission is interrupted, conduct a CC test on a PVC or run the RNC MML
command DSP AALVCCPFM or LOP VCL to check whether a disconnected PVC is
causing the ATM transmission interruption. For details, see section 6.2.3 "Verification
Methods."
The section Troubleshooting Procedure provides guidelines for checking whether faults occur
at the physical, data link, or transport layer.
Troubleshooting Procedure
1. Check whether E1/T1 port configurations are correct, including the frame format, coding
scheme, scrambling mode, resistance capability, and grounding. To query these
configurations, run the RNC MML commands LST E1T1 and DSP E1T1 or the NodeB
MML command DSP E1T1WORKMODE.
Note the following when checking E1/T1 port configurations:
z The configured resistance capability of an E1/T1 cable must be consistent with its actual
capability. In addition, its resistance capability on the local end must be consistent with
that on the peer end. 75-Ohm E1/T1 cables require grounding while 120 Ohm E1/T1
cables do not.
z Frame format, scrambling mode, and coding scheme of an E1/T1 port on the local end
must be consistent with those of the corresponding E1/T1 port on the peer end.
Otherwise, the status of upper-layer links may become abnormal, the alarm ALM-21221
IMA Link Loss of Frame may be reported on the RNC, and the alarm ALM-25823 IMA
Link Loss of Frame may be reported on the NodeB.
z If the coding scheme HDB3 is used, no scrambling mode needs to be activated. If the
coding scheme AMI is used, a scrambling mode must be activated; otherwise, the
IMAGRP negotiation will fail.
2. Check whether E1/T1 cable connections are correct, whether E1/T1 cables are correctly
connected and these cables do not cross, and whether inverse multiplexing over ATM (IMA)
links belong to the same IMA group on both the local end and the peer end.
1) Incorrect E1/T1 cable connections
According to the network plan, ports 0 and 1 must be connected to B1 and ports 2 and 3 to B2.
The E1/T1 cables, however, are incorrectly connected, as shown in the following figure. In
this case, E1/T1 cables can operate properly but the carried links fail.
Adding new links, deleting existing links, or resetting carried links cannot solve the problem.
To check whether an E1/T1 cable is properly connected, disconnect the cable on the local end
and check the port on the peer end that reports an E1/T1 loss of signal alarm. If the port is the
one specified by the network plan, the cable is correctly connected. Otherwise, the cable is
incorrectly connected.
2) Crossed pair E1/T1 cable connections
As shown in the following figure, three E1/T1 cables cross each other. In this case, no alarms
are reported but the carried IMA or MP links fail. To check whether E1/T1 cables cross each
other, perform the operations described in the preceding section Incorrect E1/T1 cable
connections.
3) IMA links that belong to the same IMA group on the local end but belong to different IMA
groups on the peer end
As shown in the following figure, device A is connected to device B using two E1/T1 cables
and to device C using another two E1/T1 cables. These four IMA links belong to the same
IMA group on device A, but belong to two different IMA groups on device B and device C.
− MCR of the corresponding PVC carrying O&M channels with an ATM service type
of UBR+
− PCR of the PVC carrying signaling data with an ATM service type of CBR or
RTVBR
− SCR of the PVC carrying speech data with an ATM service type of CBR or RTVBR
If this condition is not met, some cells may be lost.
4. Troubleshoot the transport network and locate the PVC breakpoints.
Query the configurations of all the transmission devices involved, and check performance
counter values and generated alarms of these transmission devices, especially at each PVC
breakpoint.
Analyze the distribution of the PVC breakpoints and highlight all convergence points.
5. If you still cannot locate the cause of the problem after performing this procedure, collect
information using the following table and contact Huawei technical support:
RNC and NodeB Run the RNC MML command EXP WMPT logs, RNC
configuration files CFGMML to obtain RNC configurations configuration file,
and obtain the NodeB configuration file and alarms reported
using the LMT or M2000. on the RNC
Networking and cable Check cable connections and the security Detailed networking
connections and reliability of the networking. and cable
connection
verification records
Optical port status and Run the DSP E1T1, DSP IMAGRP, DSP Execution results
E1/T1 port status IMALNK, and DSP OPT commands on
both the RNC LMT and NodeB LMT to
check the optical port status and E1/T1
port status.
E1/T1 online test Run the STR E1T1ONLTST and STP Execution results
E1T1ONLTST commands on both the
RNC LMT and NodeB LMT to start and
stop an E1/T1 online test.
CC test on a PVC Run the ACT VCLCC and DSP VCLCC Execution results
commands to start a CC test on a PVC and
query the test results.
Transport network Check configurations, QoS policy, Operation results
configurations and bandwidth utilization, and congestion
QoS policy condition of the transport network.
Users experience poor speech quality or even call drops, and the HSPA data rate is low. IP
over ATM (IPoA) O&M channels transfer MML commands slowly, and the results of the ping
test conducted on these O&M channels show that some packets are lost.
Possible Causes
z E1/T1 cables or optical cables are improperly connected or become faulty.
z There is strong interference on E1/T1 cables or optical cables.
z E1/T1 port configurations are incorrect such as the frame format, coding scheme,
scrambling mode, resistance capability, and slots.
z Types of services carried on PVCs on the local end are inconsistent with those of PVCs
on the peer end.
z Bandwidth configurations on the local end are inconsistent with those on the peer end.
z QoS policy for the transport network is incorrect.
z Transport network is congested.
z Exceptions occur on all the involved devices.
Troubleshooting Methods
If some ATM cells are lost, conduct a CC test on a PVC, enable the performance monitoring
(PM) function on a PVC, run the RNC MML command DSP AALVCCPFM or LOP VCL,
or ping IPoA O&M channels. For details, see section 6.2.3 "Verification Methods."
The section Troubleshooting Procedure provides guidelines for checking whether faults occur
at the physical, data link, or transport layer.
Troubleshooting Procedure
1. Check whether E1/T1 port configurations are correct, including the frame format, coding
scheme, scrambling mode, resistance capability, and grounding. To query these
configurations, run the RNC MML commands LST E1T1 and DSP E1T1 or the NodeB
MML command DSP E1T1WORKMODE.
Note the following when checking E1/T1 port configurations:
z The configured resistance capability of an E1/T1 cable must be consistent with its actual
capability. In addition, its resistance capability on the local end must be consistent with
that on the peer end. 75-Ohm E1/T1 cables require grounding while 120 Ohm E1/T1
cables do not.
z Frame format, scrambling mode, and coding scheme of an E1/T1 port on the local end
must be consistent with those of the corresponding E1/T1 port on the peer end.
Otherwise, the status of upper-layer links may become abnormal, the alarm ALM-21221
IMA Link Loss of Frame may be reported on the RNC, and the alarm ALM-25823 IMA
Link Loss of Frame may be reported on the NodeB.
z If the coding scheme HDB3 is used, no scrambling mode needs to be activated. If the
coding scheme AMI is used, a scrambling mode must be activated; otherwise, the
IMAGRP negotiation will fail.
2. Check whether E1/T1 cable connections are correct, whether E1/T1 cables are correctly
connected and these cables do not cross, and whether inverse multiplexing over ATM (IMA)
links belong to the same IMA group on both the local end and the peer end.
1) Incorrect E1/T1 cable connections
According to the network plan, ports 0 and 1 must be connected to B1 and ports 2 and 3 to B2.
The E1/T1 cables, however, are incorrectly connected, as shown in the following figure. In
this case, E1/T1 cables can operate properly but the carried links fail.
Adding new links, deleting existing links, or resetting carried links cannot solve the problem.
To check whether an E1/T1 cable is properly connected, disconnect the cable on the local end
and check the port on the peer end that reports an E1/T1 loss of signal alarm. If the port is the
one specified by the network plan, the cable is correctly connected. Otherwise, the cable is
incorrectly connected.
2) Crossed pair E1/T1 cable connections
As shown in the following figure, three E1/T1 cables cross each other. In this case, no alarms
are reported but the carried IMA or MP links fail. To check whether E1/T1 cables cross each
other, perform the operations described in the preceding section Incorrect E1/T1 cable
connections.
3) IMA links that belong to the same IMA group on the local end but belong to different IMA
groups on the peer end
As shown in the following figure, device A is connected to device B using two E1/T1 cables
and to device C using another two E1/T1 cables. These four IMA links belong to the same
IMA group on device A, but belong to two different IMA groups on device B and device C.
− PCR of the PVC carrying signaling data with an ATM service type of CBR or
RTVBR
− SCR of the PVC carrying speech data with an ATM service type of CBR or RTVBR
If this condition is not met, some cells may be lost.
4. Troubleshoot the transport network and locate spots where some cells are lost.
Troubleshoot the transport network, locate the spots where some cells are lost, query
configurations of all the involved transmission devices, and check performance counter values
and generated alarms on these transmission devices.
Analyze the distribution of the spots where some cells are lost and highlight all convergence
spots.
5. If you still cannot locate the cause of the problem after performing this procedure, collect
information using the following table and contact Huawei technical support:
RNC and NodeB Run the RNC MML command EXP WMPT logs, RNC
configuration files CFGMML to obtain RNC configurations configuration file,
and obtain the NodeB configuration file and alarms reported
using the LMT or M2000. on the RNC
Networking and cable Check cable connections and the security Detailed networking
connections and reliability of the networking. and cable
connection
verification records
Optical port status and Run the DSP E1T1, DSP IMAGRP, DSP Execution results
E1/T1 port status IMALNK, and DSP OPT commands on
both the RNC LMT and NodeB LMT to
check the optical port status and E1/T1
port status.
E1/T1 online test Run the STR E1T1ONLTST and STP Execution results
E1T1ONLTST commands on both the
RNC LMT and NodeB LMT to start and
stop an E1/T1 online test.
PVC performance Run the ACT VCLPM command on the Execution results
RNC or NodeB LMT to enable the PM
function for a PVC and run the DSP
VCLPM command on the RNC or NodeB
LMT to display the performance
measurement results for the PVC.
Run the DSP AALVCCPFM command
on the RNC or NodeB LMT to query the
performance measurement results for a
PVC and run the LOP VCL command on
the RNC or NodeB LMT to start a loop
back test on a PVC.
Parameter Meaning
Link type Type of the test PVC. SAAL links, IPoA PVCs, and AAL2 paths support CC tests.
VCL act type Type of CC test. CC tests include continuity check tests and loopback tests.
Activation mode Activation mode for a CC test.
When this parameter is set to AUTO, the local end sends an activation cell to the
peer end. Upon receiving an activation response from the peer end, the local end
starts a CC test by sending CC cells.
When this parameter is set to MANUAL, the local end sends an activation cell to
the peer end and then starts a CC test by sending CC cells without waiting for an
activation response. Set this parameter to MANUAL for devices where the CC
function cannot be enabled automatically.
Parameter Meaning
Activation direction Mode for the local end to determine the quality of a PVC.
When this parameter is set to SINK, the local end determines PVC quality based on
CC cells transmitted from the peer end.
When this parameter is set to SOURCE, the local end does not check PVC quality
and only sends CC cells to the peer end.
When this parameter is set to BOTH, the local end periodically sends CC cells to
the peer end, which then responds to these CC cells. Based on the received CC
cells, the local end checks PVC quality.
The following figure shows that the test PVC is functioning properly:
5) Notes
Before conducting a CC test on a PVC, ensure that both the local end and peer end support
the test. Otherwise, the test cannot be started.
Parameter Meaning
Link type Type of the test PVC. SAAL links, IPoA PVCs, and AAL2 paths support the PM
function.
Activation mode Activation mode for a performance monitoring task.
When this parameter is set to AUTO, the local end sends an activation cell to the
peer end. Upon receiving an activation response, the local end starts monitoring the
performance of the test PVC by sending PM cells.
When this parameter is set to MANUAL, the local end sends an activation cell to
the peer end and starts sending PM cells without waiting for an activation response.
Activation direction Mode for the local end to determine the quality of a PVC.
When this parameter is set to SINK, the local end does not send FPM cells and only
responds to FPM cells sent from the peer end with BR cells.
When this parameter is set to SOURCE, the local end sends the peer end FPM cells
and calculates QoS-related counters based on BR cells sent from the peer end.
When this parameter is set to BOTH, the local end sends the peer end FPM cells,
processes FPM cells sent from the peer end, and responds with BR cells.
To enable the PM function for a PVC (Adjacent node ID = 150; AAL2 path ID = 1;
Activation direction = BOTH), run the following command:
ACT VCLPM: LNKT=AAL2PATH, ANI=150, PATHID=1, DR=BOTH, BSIZE=D1024,
PMMODE=AUTO;
Run the RNC MML command DEA VCLPM to disable the PM function for a PVC.
To obtain statistic parameter values within a specific period of time, run the RNC MML
command ACT VCLPM five times at an interval of 3 minutes, and save and compare the
execution results.
5) Querying the performance of the test PVC
To query the performance of the test PVC, run the RNC MML command DSP VCLPM, as
shown in the following figure:
To obtain statistic parameter values within a specific period of time, run the DSP VCLPM
command five times at an interval of 3 minutes, and save and compare the execution results.
Parameter Meaning
Type of the test PVC. You can query the performance of SAAL
Link type
links, IPoA PVCs, and AAL2 paths.
Run the command multiple times at a fixed interval, and save and compare the execution
results. By doing this, you can obtain the number of transmitted, received, and erroneous cells
over the test PVC.
Run the RNC MML command LST IPOAPVC to locate the PVC that carries the IPoA O&M
channel for the NodeB, as shown in the following figure:
Run the RNC MML command PING IP with parameters set to appropriate values:
As shown in the following figure, the packet loss rate and delay information are displayed in
the execution result:
Parameter Meaning
Link type Type of the test PVC. SAAL links, IPoA PVCs, and AAL2 paths support loopback tests.
To accurately analyze the PVC quality, run the LOP VCL command multiple times, and save
and compare the execution results.
AC Access Class
AMR Adaptive multirate
ARP Address Resolution Protocol
BER Bit error rate
CAC Call admission control
CC Connectivity check
CDT Call detailed trace
CE Channel element
CHR Call history record
CN Core network
DSCP Differentiated services code point
DSP Digital signal processor
DSP Destination signaling point
FAM Front administration module
GBR Guaranteed bit rate
HSDPA High Speed Downlink Packet Access
HSPA High speed packet access
HSUPA High Speed Uplink Packet Access
ICMP Internet Control Message Protocol
IMA Inverse multiplexing over ATM
IOS Intelligent optimum sample
IPoA IP Over ATM
KPI Key performance indicator
LAC Location Area Code
Layer 2 L2