BSC6900 WCDMA V900R012 Troubleshooting: Confidential Information of Huawei. No Spreading Without Permission
BSC6900 WCDMA V900R012 Troubleshooting: Confidential Information of Huawei. No Spreading Without Permission
BSC6900 WCDMA V900R012 Troubleshooting: Confidential Information of Huawei. No Spreading Without Permission
Step 1 Run the command DSP OMU to check whether the active and standby OMUs are normal (the blue part in the following information).
Step 2 Check whether the internal and external networks are normal (the red part in the following information).
If the internal network is abnormal, check whether the OMU is correctly installed and whether the SCU is working normally. If the external network is abnormal, check whether the external network cables are correctly connected.
BSC6900 WCDMA V900R012 Troubleshooting +++ O&M MBSC_Huawei #57526 2010-10-12 15:53:55
---------------Subrack No. = 0 Slot No. = 21 Computer name = omu-1 Internal network fixed IP = 80.168.3.50
Subrack No. = 0
Slot No. = 23
Computer name = omu-2
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.
z z
Step 4
----End
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.
Check whether the standby OMU starts normally. If the standby OMU does not start normally, start the standby OMU.
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.
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:
(1) Use the troubleshooting method of the ALM-20701 OMU Failure Switchover alarm to clear the alarm. (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.
----End
z z
Incorrect Internal IP Address of the OMU Check whether the internal IP addresses of the onsite OMU are correct according to the IP addresses listed in the OMU Administration Guide
z
z
Incorrect Internal IP Address of the OMU Check whether the internal IP addresses of the onsite OMU are correct according to the IP addresses listed in the OMU Administration Guide
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.
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
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). 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.
Run the command LST UCELL on the RNC LMT to query the maximum downlink power on the RNC side. The result is as follows:
Run the command LST LOCELL on the NodeB LMT to query the maximum downlink power on the NodeB side. The result is as follows:
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 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 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.
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. 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. 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.
Receive customers complaints that the call quality and access for many users in a live network are affected.
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.
Services in one subsystem, one subrack, or the entire RNC are affected. All services in one interface board are affected.
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} Cell activation failure
Power congestion
Code resource congestion Transmission congestion
CE congestion
DSP soft failure
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:
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:
DSP UCELL
DSP UCELLCHK 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. For the specific cause analysis of the cell activation failure, see Chapter 4 . 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.
Run the DSP UCELLCHK to check whether the cell is in congested state, including power congestion, code resource congestion, transmission congestion, and CE congestion.
Power congestion:
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.
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 autoadaptive background noise update switch is ON, deactivate the cell, and then re-activate the cell to check whether the RTWP is normal.
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: MOD UCELLALGOSWITCH: NBMUlCacAlgoSelSwitch=ALGORITHM_OFF;
Check the average RTWP value (vs-meanrtwp) in the traffic statistics, and set the background noise to the minimum vs-meanrtwp. The command is as follows: MOD UCELLCAC: BackgroundNoise=61;
z
z
z z
z
z
The parameter value depends on the site requirements. By default, it is set to 61.
Actually configured noise floor = 112 + BackgroundNoise x 0.1
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.
Code congestion:
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.
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.
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 reactivate the cell to view the test result.
Transmission congestion:
Run the command DSP UCELLCHK to check whether Iub interface of the cell is in congested state.
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.
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.
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. CE congestion:
Run the command DSP UCELLCHK to check whether the CEs of the cell are congested.
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.
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.
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.
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. 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.
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.
----End
No.
Item 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 ). Trace the SCCP over the Iu interface. Trace the QAAL2 over the Iub or Iur interface.
Method
Directory
P erform UE trace in if drive test UE is available. P erform 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. LMT tracings For example, if the CS services are faulty, select Originating Conversational For details, see the Guide to Collecting Call and Terminating Conversational Call. If a RAB access process fails or W RAN Information. 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. If the CS services are faulty, trace the SCCP of the Mobile Switching Center (MSC). If the P S services are faulty, trace the SCCP of the Serving GP RS Support Node (SGSN).
LMT tracings
LMT tracings. It is recommended that you submit the analysis report when required.
If faults related to the Iur interface occur, trace the QAAL2 of the Iur interface.
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 bam\common\fa m\fa mlogfmt\[CHR] 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 UP CHR logs. Onsite personnel must report all of them together. 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 bam\common\measResult 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\fa m\fa mlog 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. Back up logs when fault occurs. It is recommended that you submit the analysis report when required.
Collect operation logs Run the following command: and history alarm logs. COL LOG :LOG TYPE=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. bam\version_a(b)\ftp\export_cfgmml
Step 1
Check whether the licenses for the HSPA functions are valid. 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.
Step 2
Step 3
Step 1
Check whether the UE supports the HSPA services. 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
Step 2
Check whether the number of HSPA users is limited. 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. 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.
Run the command LST UCELLCAC and set the numbers of HSUPA users and HSDPA users in the cell CAC algorithm.
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.
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.
Step 3
Check the AAL2PATH and IPPATH configurations. 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: 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.
Step 4
Step 5
Check the MBR assigned by the CN. 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. As shown in the following figure, the MBR is assigned in the RANAP_RAB_ASSIGNMENT_REQUSET message.
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. 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.
Step 6
Step 7 If you cannot solve the HSPA service setup failure, collect logs according to the following fault information checklist. ----End