114982939-3-OWC403500-BSC6900-WCDMA-Troubleshooting-3

BSC6900 WCDMA V900R012 Troubleshooting

Confidential Information of Huawei. No Spreading Without Permission





l Step 1 Run the command DSP OMU to check whether the active and standby OMUs

are normal (the blue part in the following information).

l Step 2 Check whether the internal and external networks are normal (the red part in

the following information).

p If the internal network is abnormal, check whether the OMU is correctly installed

and whether the SCU is working normally.

p If the external network is abnormal, check whether the external network cables are

correctly connected.



+++ MBSC_Huawei 2010-10-12 15:53:55

O&M #57526

%%DSP OMU:;%%

RETCODE = 0 Execution succeeded.

OMU server state

----------------

Subrack No. = 0

Slot No. = 21

Computer name = omu-1

Internal network fixed IP = 80.168.3.50

External network fixed IP = 10.161.105.209

Backup network IP = 192.168.3.50

Operational state = Active normal

Version = V900R012ENGC01SPC500

Subrack No. = 0

Slot No. = 23

Computer name = omu-2

Internal network fixed IP = 80.168.3.60

External network fixed IP = 10.161.105.210

Backup network IP = 192.168.3.60

Operational state = Standby normal

Version = V900R012ENGC01SPC500

(Number of results = 1)

Other state

-----------

Internal network virtual IP = 80.168.3.40

External network virtual IP = 10.161.105.208

Internal network virtual IP state = Normal

External network virtual IP state = Normal

Data-sync state = Data synchronization is successful

Internal network link state = Normal

External network link state = Normal

Backup network link state = Normal

(Number of results = 1)

--- END



l Step 3 Run the command DSP OMUMODULE to check whether the OMU services are

running normally. The normal state of each OMU service is as follows:

If the OMU is in UMTS Only (UO) mode, BTSOM service does not exist.

l Step 4 Run the command RST OMUMODULE to reset the abnormal modules.

l ----End









l Step 1 Run the command DSP OMU to query the status of the active and standby

OMUs. Check whether data synchronization is normal and whether the FE port connection

is normal.

p Check whether the standby OMU starts normally. If the standby OMU does not

start normally, start the standby OMU.

p For example, after a sudden switchover is performed between the active and

standby OMUs, if data synchronization fails, you can run the command DSP OMU

to find out the direct cause through the Data-sync state field in the result.

l Step 2 If the network is normal, check whether the ALM-20701 OMU Failure

Switchover alarm is generated. If the alarm is generated, do as follows:

p (1) Use the troubleshooting method of the ALM-20701 OMU Failure Switchover

alarm to clear the alarm.

p (2) If the standby OMU is faulty and cannot be switched back, the onsite personnel

must check whether the data is the latest, and whether the data on the OMU and

host is consistent. If the data is consistent, you must clear the alarm manually, run

the command STP DATASYNC to stop data synchronization, and run the

command STR DATASYNC to enable data synchronization again.

l ----End









l Incorrect Internal IP Address of the OMU

l Check whether the internal IP addresses of the onsite OMU are correct according to the IP

addresses listed in the OMU Administration Guide



l Incorrect Internal IP Address of the OMU

l Check whether the internal IP addresses of the onsite OMU are correct according to the IP

addresses listed in the OMU Administration Guide











l Run the command DSP UCELL to query the cause of the cell setup failure. The information

similar to the following is displayed. Take measures based on the specific cause.

l If the cell setup failure is due to NCP unavailability or CCP unavailability, the link bearing

NCP or CCP may be faulty. Check whether an alarm related to the corresponding SAAL or

SCTP link (SAAL: ATM; SCTP: IP transmission) is generated. If such an alarm is generated,

clear the alarm according to help of the alarms

l If the cell setup failure is due to FP synchronization failure or Common channel setup

failure, the user-plane transmission bearer may be faulty. Check whether a path alarm is

generated. If such an alarm is generated, rectify the fault according to the relevant

chapters in the Transmission Troubleshooting Guide (Chapter 4 “AAL2PATH”; Chapter 8

“IPPATH Unavailability”; Chapter 10 “FACH Packet Loss”).

l If the cell setup failure is due to Power mismatch, check whether the local cell on the

NodeB side is normal. If the local cell is unavailable, rectify the fault according to the

relevant chapter in the NodeB troubleshooting guide (Chapter 8 "Cell Setup Failure"). If the

local cell is available, check whether the maximum downlink power on the NodeB side and

that on the RNC side. If the former is smaller than the latter, modify the maximum

downlink power on the RNC side or on the NodeB side to ensure that the maximum

downlink power on the NodeB side is greater than that on the RNC side.

l Run the command LST UCELL on the RNC LMT to query the maximum downlink power

on the RNC side. The result is as follows:



l Run the command LST LOCELL on the NodeB LMT to query the maximum downlink

power on the NodeB side. The result is as follows:

l If the cell setup failure is due to NodeB return cell setup failure and the Cause=NodeB

sends CELL SETUP FAILURE (Frequency acquisition not supported) information is

generated in the ALM-22206 Cell Setup Failure alarm, check whether the frequency

configurations on the RNC and the NodeB are consistent (run the command LST UCELL

on the RNC and the command LST LOCELL on the NodeB to query the frequency

configurations).

l l If the cell setup failure is due to Local cell not reported and the Cause=Data

configuration error or inconsistent with physical resources information is generated

in the ALM-22206 Cell Setup Failure alarm, check whether the NodeB is configured with a

local cell and whether the parameter configuration of the local cell is consistent with that

of the cell on the RNC side (run the command LST UCELL on the RNC and the command

LST LOCELL on the NodeB to query the parameter configuration).

l l If the cell setup failure is due to Common channel setup failed and the setup failure of

the common channel is due to the allocation failure of L2 resources (Reason of the latest

common channel setup failure = L2 resource allocation failed), check whether the service

subrack is inserted with DPUs. If DPUs are inserted, run the command DSP BRD to query

the status of DPUs. If all DPUs are barred, unbar the DPUs; if all DPUs are abnormal, insert

new DPUs or replace the DPUs.



l Run the command LST UNODEB or DSP LICUSAGE to check whether the license control

items unavailable for cells configured with ATM/IP dual stack or IPRAN. After running the

command DSP LICUSAGE, if the license control item is displayed with a value that is not 0,

this control item is available, as shown in the figure.

l After running the command DSP LICUSAGE, if the license control item is not displayed,

the license is unavailable, and you need to reapply the license. If the license control item is

displayed with a value of 0, run the command SET LICENSE to enable the license.

l If the cell is configured with IPRAN, the license control item IP Transportation in Iub

Interface must be ON; if the cell is configured with ATM/IP dual stack, the license control

items IP Transportation in Iub Interface and IUB ATM/IP Dual Stack Transportation

Function must be ON.







l Possible Fault Causes

p Emergency faults are as follows:

n Receive customer’s complaints that the call quality and access for many

users in a live network are affected.

n KPIs, such as the call drop rate and the access success rate,

deteriorate seriously, affecting the call quality and network accessing for a

large number of users in a live network.

n Services in one subsystem, one subrack, or the entire RNC are affected. All

services in one interface board are affected.

n In the case of emergency faults, see section "BSC6900 V900R012 Quick

Troubleshooting Guide" or section "BSC6900 Heavy Traffic Precaution and

Emergency Measure Guide" in the UMTS Maintenance Guide, and

troubleshoot the faults accordingly. 0}

p Possible causes for non-emergency faults are as follows:

n Cell activation failure

n Power congestion

n Code resource congestion

n Transmission congestion

n CE congestion

n DSP soft failure



l If the fault is not an emergency service problem, you can infer that only some users cannot

make calls or access the network. To rectify the fault, do as follows:

l Step 1 Check whether the cell status is normal, namely, whether cell setup is normal,

whether the cell is available, and whether the cell uplink or downlink traffic is congested.

Run the following commands to query the cell status:

p DSP UCELL

p DSP UCELLCHK

p If the cell is not activated, run the command ACT UCELL to activate the cell. If the

cell activation fails, run the command DSP UCELL to query the failure cause.

p For the specific cause analysis of the cell activation failure, see Chapter 4 .

p If the cell is successfully set up, run the command LST UCELLACCESSSTRICT to

check whether the cell or the user AC is barred. If the cell is barred, unbar the cell.



l Run the DSP UCELLCHK to check whether the cell is in congested state, including power

congestion, code resource congestion, transmission congestion, and CE congestion.

l Power congestion:

l Power congestion is classified into uplink power congestion and downlink power congestion.

Usually, algorithm 1 is used as the downlink connection admission control (CAC) algorithm, whereas

the uplink CAC algorithm is turned off.

l If the access failure is due to uplink power congestion, run the command DSP UCELLCHK to check

whether the RTWP is within the valid range (–96.5 dB to –105.5 dB). Run the command LST

UCELLCAC to check whether the auto-adaptive background noise update switch is ON. If the auto-

adaptive background noise update switch is ON, deactivate the cell, and then re-activate the cell to

check whether the RTWP is normal.

l If the auto-adaptive background noise update switch is OFF, turn off the uplink CAC switch or reset

the background noise. You can use the following command to turn off the uplink CAC switch:

l MOD UCELLALGOSWITCH: NBMUlCacAlgoSelSwitch=ALGORITHM_OFF;

l Check the average RTWP value (vs-meanrtwp) in the traffic statistics, and set the background noise

to the minimum vs-meanrtwp.

l The command is as follows:

l MOD UCELLCAC: BackgroundNoise=61;

l The parameter value depends on the site requirements. By default, it is set to 61.

l Actually configured noise floor = 112 + BackgroundNoise x 0.1



l If the access failure is due to downlink power congestion, run the command DSP

UCELLCHK to check whether the latest TCP value is normal (<75%). To query the

admission threshold of a specific service, you can run the command LST UCELLCAC. If the

TCP value exceeds the threshold, the access fails. Check whether the admission threshold is

configured according to the baseline data or radio parameters for network planning, and

modify the obvious errors. For example, the admission threshold is configured to 30%. If

the threshold is configured according to the baseline data or radio parameters for network

planning, the network planners should negotiate with the customer on whether to adjust

the threshold to admit more users or expand the capacity.



l Code congestion:

p Run the command DSP UCELLCHK to check whether the cell used rate of code

resources is normal and trace the code tree to check whether the cell uses too

many code words. If the minimum available code words are more than the

reserved code words, the cell capacity is limited and needs expansion. The fewer

the code words, the greater the service rate. For example, the available minimum

code word is SF32 but the configured reserved code word is only SF16, the

admission fails.

p Alternatively, you can run the command LST UCELLCAC to check whether the

reserved code word of the cell is configured according to the baseline data or the

radio parameters for network planning. Newly admitted users cannot use reserved

code words. As a result, the more the reserved code words, the fewer code words

available for new users. If the configured value is too small (SF4), you can modify it

according to the baseline data. Otherwise, the network planners should negotiate

with the customer on whether to adjust the threshold to admit more users or to

expand capacity.

l If the cell's number of users is too small and available minimum code words are fewer than

reserved code words, no congestion occurs. You can deactivate the cell and then re-

activate the cell to view the test result.



l Transmission congestion:

p Run the command DSP UCELLCHK to check whether Iub interface of the cell is in

congested state.

p If the Iub interface is in congested state, check whether the reserved bandwidth for

the AAL2PATH is too high. By default, the reserved bandwidth is 0. That is, no

bandwidth is reserved.

l Run the command LST TRMFACTOR to check whether the values configured for service

activation factors are within the valid ranges. Usually, these parameters should be

configured with recommended values.



l For the PS services, you should also use LST UUSERGBR check whether the GBR is

configured according to the baseline data. If the GBR value is obviously inappropriate (such

as 384 KB), the network planners should negotiate with the operator on whether to

decrease the GBR to admit more users or adjust the bandwidth.

l CE congestion:

p Run the command DSP UCELLCHK to check whether the CEs of the cell are

congested.



l Step 2 Check whether the LAC/SAC/RAC data is configured and activated on the CN

side (MSC/SGSN). If this data is not configured, UEs cannot register to or attach themselves

to the network. You can trace the intelligent optimum sample (IOS) of the cell to check

whether a UE can register on or attach to the network normally.

p When the SAC data is not configured on the CN side, the RNC fails to send the

initial direct transfer message for setting up signaling connection control part

(SCCP) connection. As a result, the UE cannot access the network.



l Step 3 Check whether the AAL2Path or IPPATH is available and configured correctly.

For the specific method, see Chapter 5 "AALPATH" and Chapter 8 "IPPATH" in the RAN10

Transmission Troubleshooting Guide.

p Run the command LST TRMMAP to check whether the transmission mapping is

set correctly. For example, in the ATM transmission, 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); High Speed Packet Access (HSPA)

services map HSPA NRT paths. High Speed Downlink Packet Access (HSDPA)

services and High Speed Uplink Packet Access (HSUPA) services map with each

other. For details, see the Iu&Iur&Iub Configuration Recommendation. Run the

command LST AAL2PATH or LST IPPATH to check whether the mapped path in

the TRMMAP is actually configured.

p According to the preceding result, the AMR service can be set up only after an

RT_VRB type AAL2 path or an EF type IP path is configured.

l Step 4 If the service is not recovered, collect the information according to the following

fault information checklist. After the information collection, you must filter the

information and locate the fault. In this way, the transfer of useless information

can be avoided.

l ----End





No. Item Method Directory

1

Collect the IOS trace

information or UE

trace information,

including statistics on

L2 (set AL Collect

Period to 1s) and L2

Data Report (set

Report Interval to

100s).

Perform UE trace in if drive test UE is available. Perform IOS trace if drive test

UE is unavailable. When tracing the IOS if faults occur in a RRC access

process, select the correct causes in the RRC Est Cause drop-down list box.

For example, if the CS services are faulty, select Originating Conversational

Call and Terminating Conversational Call. If a RAB access process fails or

call drop occurs, select the corresponding service type. For example, select

AMR to trace the AMR service. Select top 5 cells to trace in the IOS trace. Top

5 cells can be selected according to the MeasureResult file.

LMT tracings

For details, see the Guide to Collecting

W RAN Information.

2 Trace the SCCP over

the Iu interface.

If the CS services are faulty, trace the SCCP of the Mobile Switching Center

(MSC). If the PS services are faulty, trace the SCCP of the Serving GPRS

Support Node (SGSN).

LMT tracings

3

Trace the QAAL2

over the Iub or Iur

interface.

If faults related to the Iur interface occur, trace the QAAL2 of the Iur interface.

LMT tracings. It is recommended that

you submit the analysis report when

required.

4 Collect binary logs.

Find out the UE or IOS fault time, and obtain the binary logs 20 minutes before

and after the fault time. The binary log file is large, so binary log in one day or

several days are not required. It is recommended, however, that the onsite

personnel try to back up the existing binary logs and all later binary logs for

later use. In the version of V900R012, binary logs are divided into CHR,

DEBUG, UCALLFAULT and UPCHR logs. Onsite personnel must report all of

them together.

bam\common\fam\famlogfmt\[CHR]

5 Collect the

MeasureResult file.

Collect the traffic statistics three hours before and after the fault time. The

MeasureResult file is large, so traffic statistics in one day or several days are

not required. It is recommended, however, that the onsite personnel try to back

up the existing traffic statistics and all later traffic statistics for later use.

bam\common\measResult

6 Collect logs in text

format.

Onsite personnel need to collect and report logs in text format within the day

when the fault occurs. It is recommended, however, that the onsite personnel

try to back up the existing logs in text format and all later logs in text format

for later use.

bam\common\fam\famlog

Back up logs when fault occurs. It is

recommended that you submit the

analysis report when required.

7

Collect operation logs

and history alarm

logs.

Run the following command:

COL LOG:LOGTYPE=HISTORY_ALARM-1&OPT_LOG;

The OperateLog.zip file is in the

bam\version_a(b)\ftp\COLLOGINFO\AC

TIVE-LOG directory.

The ALARM_INFO.zip file is in the

bam\version_a(b)\ftp\COLLOGINFO\ST

ANDBY-LOG directory.

8 Collect configuration

data. Run the command EXP CFGMML. bam\version_a(b)\ftp\export_cfgmml







l Step 1 Check whether the licenses for the HSPA functions are valid.

p Run the command DSP LICUSAGE to check whether the High Speed Downlink

Packet Access (HSDPA) and High Speed Uplink Packet Access (HSUPA) functions

are enabled. If the functions are not enabled, you must apply for licenses to

activate the HSPA functions.

l Step 2 Check data configuration.

p Run the command LST UNODEB to check whether the NodeB protocol version is

configured correctly. The REL-5 version supports the HSDPA, and the REL-6 version

supports both the HSDPA and the HSUPA.

l Step 3 Check the occupation of the code tree in the cell.

p Check the occupation of code tree resources in the cell. Usually, the HSDPA service

uses the last five SF16 code tree resources. If the resources are distributed to R99

users, the HSDPA service cannot be set up.





l Step 1 Check whether the UE supports the HSPA services.

p The setup of the HSPA services requires the support of the UE. Send the RRC

CONNECTION SETUP REQ message to check whether the UE attempting to

access the network supports the HSPA functions. If the UE supports the HSDPA,

the REL-5 version is displayed. If the message contains the ueCapabilityIndication

IE and the value contains e-dch, the UE supports the HSUPA function, as shown in

the following figure



the following figure


l Step 2 Check whether the number of HSPA users is limited.

p The number of HSUPA users and the number of HSDPA users are independent

from each other. Therefore, you need to set admission thresholds at both the cell

level and the NodeB level.

p The maximum number of HSPA users supported by a cell is MIN (value specified in

the RNC license, value set in the cell CAC algorithm). The RNC license controls the

maximum number of HSPA users a single cell, which can be queried through the

command DSP LICUSAGE. This number is subject to the maximum number of

HSPA users that are supported. For example, the 64HSDPA Users per Cell switch

is ON, indicating that the cell supports up to 64 HSDPA users.



l Run the command LST UCELLCAC and set the numbers of HSUPA users and HSDPA users

in the cell CAC algorithm.



l Run the command LST UNODEBLGOPARA to query the maximum number of HSPA users

supported by the NodeB. By default, this number is 3840. Access failure rarely occurs.



l Run the command DSP UCELLCHK to query the number of HSPA users supported by the

serving cell. If the result is equal or close to the number of users permitted in the license or

configured in the CAC algorithm, the access fails due to the admission threshold for HSPA

users. You need to re-apply for the relevant license or modify admission threshold for users.



l Step 3 Check the AAL2PATH and IPPATH configurations.

p Check whether the AAL2PATH (ATM) or IPPATH (IP) are configured on the RNC

and NodeB. You must view the corresponding transmission resource mapping table.

Run the command LST TRMMAP, and the following information is displayed:

p Run the command LST AAL2PATH to check whether the AAL2PATH with the

corresponding properties is configured. For example, according to the preceding

result, the HSDPA service can be set up only when the AAL2PATH configured with

the ATMHD UBR is available. Check the HSUPA service in the same method.

l Step 4 Check whether the AAL2PATH and IPPATH are available

p If the AAL2PATH and IPPATH are configured, check whether these paths are

available.



l Step 5 Check the MBR assigned by the CN.

p The RNC determines whether to use the HS-DSCH or E-DCH to bear the service

based on the MBR assigned by the CN and the preset threshold. If the MBR

assigned by the CN exceeds the threshold for setting up the HSPA service, the

service can be set up on the HS-DSCH/E-DCH. Otherwise, the service is borne on

the E-DCH. The thresholds for the BE service and streaming service are set

independently.

p As shown in the following figure, the MBR is assigned in the

RANAP_RAB_ASSIGNMENT_REQUSET message.



p You can run the command LST UFRCCHLTYPEPARA to query the threshold for

setting up the HSPA service. If the uplink rate assigned by the CN is lower than the

threshold for setting up the HSUPA service, you should negotiate with the operator

on whether to modify the threshold to set up the HSPA service.

p Alternatively, you can modify the subscription information on the HLR. Check the

consistency between the IMSI information and the CN-assigned information before

the modification. The subscription information on the HLR may be correct, but an

AT command is used to limit the rate during the dial-up. Instead of providing a

solution to the problem, the modification of the threshold for setting up the HSPA

service can only ensure the setting-up of the service on the HS-DSCH. The service

rate for users is still under the control of the MBR. Therefore, it is necessary to

modify the subscription information on the HLR or cancel the AT command for

limiting the service rate.

l Step 6 Check the health of a cell.

p Run the command DSP UCELLCHK to check the health of a cell and whether the

cell is in congested state. For the specific method, see Chapter 6 .

l Step 7 If you cannot solve the HSPA service setup failure, collect logs according to the

following fault information checklist.

l ----End















Documents

114982939-3-OWC403500-BSC6900-WCDMA-Troubleshooting-3