cases of cdma issues and their soulutions

Product Name Confidentiality Level

CONFIDENTIAL

Product Version

Total 69 pages

Case Summary of CDMA RNP&RNO in 2007

Prepared by Technical Support Dept. of CDMA Network Planning Dept.

Date 2008-2-20

Reviewed by Date yyyy-mm-dd

Approved by Date yyyy-mm-dd

Huawei Technologies Co., Ltd. All rights reserved

1 Preface .............................................................................................................................................4

2 Call Drop Problems ......................................................................................................................5 2.1 Call drops caused by incorrect settings of the DIP switches on the BCIM board ............................................ 5 2.2 Call drop due to the fault of the BCKM board................................................................................................. 6 2.3 C0b Call drops and A2 interface call drop due to the fault of the FMR........................................................... 7 2.4 The C05 (a call drop indicator) rises after IP transmission is used on the A interface ..................................... 8 2.5 Call drops caused by the mismatch between the maximum transmit power of the CDMA TCH and the pilot power.................................................................................................................................................................... 11

3 Handoff Problems.......................................................................................................................13 3.1 Mobile-assisted hard handoff (MAHHO) failures caused by the excessively small candidate frequency search window...................................................................................................................................................... 13 3.2 The strong legs of the EV-DO network cannot join the active set when the FMR board is faulty ................. 15 3.3 The soft handoff success rate decreases due to insufficient CIDs of the PVCs from the BIE to the MUX.... 16 3.4 EVDO handoff failure because no inter-EVDO frame soft handoff is configured......................................... 18 3.5 A case of interconnection and hard handoff failure between Huawei BSC and the BSC of vendor Z in country P .............................................................................................................................................................. 19

4 Interference Problems ................................................................................................................24 4.1 The RSSI of a BTS is slightly high due to the interference from a repeater .................................................. 24 4.2 The difference between the main RSSI and the diversity RSSI is sometimes normal but abnormal at the other time of a day due to incorrect connection of the spatial diversity antennas of the sectors.......................... 25

5 Data Configuration Problems...................................................................................................28 5.1 The call setup success rate and the handoff success rate sharply decrease due to insufficient signaling link bandwidth............................................................................................................................................................. 28 5.2 MS access failures caused by the small value of MAX_CAP_SZ ................................................................. 29 5.3 Hard handoff failures caused by the small search window size set on the BSC of vendor M........................ 31 5.4 The data of the RFMT cannot be traced due to incorrect settings of signaling software parameters of the BTS ...................................................................................................................................................................... 33 5.5 Many A22 access failures after the BSC is upgraded..................................................................................... 34 5.6 Failure of all the subscribers in the network to make calls because the INIT_PWR parameter is set too large.............................................................................................................................................................................. 36 5.7 Call setup failures caused by poor cooperation between Huawei MSC and the HLR of other vendors during network swap ....................................................................................................................................................... 37 5.8 OTAPA operation failure of the CDMA fixed station terminal due to inconsistent A_KEY value ................ 38 5.9 Policies for solving the Walsh congestion of the carriers set with CDMA1x data service priority................ 41

6 Problems with Tools and Instruments....................................................................................43 6.1 A case of troubleshooting the dongle of Dingli .............................................................................................. 43 6.2 Failure of the Huawei C5300 to connect the PC for test due to the incorrect mobile phone port type set ..... 44

6.3 A case of troubleshooting the connection between Dingli software and Huawei 1900M fixed station ETS2257............................................................................................................................................................... 45

7 BSS Equipment Problems .........................................................................................................47 7.1 Congestion occurs to the blocked carriers after access macro diversity is enabled........................................ 47 7.2 Low call setup success ratio and no hardware alarm display due to the fault of the chip on the CCPM board.............................................................................................................................................................................. 48 7.3 The call setup success rate decreases due to a fault of the FMR board .......................................................... 50 7.4 The BTS is abnormal due to a hardware fault of the NOD board of the ETS450-BSC ................................. 51 7.5 The transmit power of all the BTSs in the network rises and the voice quality of the BTSs is poor due to the clock fault of the GCKP board after the frequencies of the BSC are modified .................................................... 52 7.6 The BAM server cannot synchronize with the EWS due to a virus of the MSN Messenger ......................... 54 7.7 The BTS alarms do not indicate the faulty BTS because data update and synchronization is not performed on the M2000 after the BTSs are upgraded.......................................................................................................... 55

8 EVDO Problems ..........................................................................................................................57 8.1 The real-time map of the CAIT disappears because the GPS does not work ................................................. 57 8.2 The map does not match the BTS longitude and latitude during the DO network drive test with the CAIT . 58 8.3 The PPP connection cannot be released when the subscriber is abnormally disconnected ............................ 59 8.4 The connection between the PCF and the PDSN fails due to the failure of NTP time synchronization ........ 61 8.5 How to differentiate DO-RA services from DO-R0 services? ....................................................................... 62 8.6 Low download rate of EVDO data services due to insufficient E1s and incorrect service link configuration.............................................................................................................................................................................. 63

9 Other Problems............................................................................................................................65 9.1 Several methods for setting in-car loss in the U-net....................................................................................... 65 9.2 The terminals of vendor Z automatically power off in a Huawei network..................................................... 66 9.3 A high FER caused by the demodulation of the FCH after the connection of the MS is released.................. 67

A Collection of Cases Related to CDMA Network Planning in 2007 INTERNAL

2008-7-11 Huawei Confidential Page 4 of 69

1 Preface This document presents some cases related to CDMA network planning in 2007.

The cases are classified into the following types:

z Call drop problems z Handoff problems z Interference problems z Data configuration problems z Problems with tools and instruments z BSS equipment problems z EVDO problems z Other problems



2 Call Drop Problems 2.1 Call drops caused by incorrect settings of the DIP switches on the BCIM board

Title Call drops caused by incorrect settings of the DIP switches on the BCIM board

SN SC0000346198

Update Time 2007-04-16

Author Zhu Baojiang

Keywords Call drop, DIP switch, transmission, BCIM

Symptom In a new office, the version of the BSC is the V2R2C04B016. After subscriber numbers are allocated, the call setup success rate is very high (99%) but the call drop rate is also high. The call drops are caused by excessive Erasure frames. The BSC connects only four BTSs. On the average, a call drop occurs every five calls of the four BTSs newly deployed for the BSC. This severely affects the conversation quality.

Alarm Information

E1 transmission alarm

Cause Analysis 1. The BTSs are newly deployed. Therefore, the high call drop rate most probably relates to PN and adjacent cell configuration. It is necessary to check whether the PNs are properly planned and whether some adjacent cells are not configured or incorrectly configured.

2. Many factors contribute to call drops. It is necessary to analyze and troubleshoot the call drop problem based on the cause values of the call drops, the runlog data, and the status of the network.

Troubleshooting 1. Check the PN reuse of the network. No error is found. Check the adjacent cell configuration. The adjacent cell configuration is complete and correct (because the network has only four BTSs, it is easy to check the adjacent cell configuration).

2. Check the alarm console. The alarm information shows that some BTSs are transiently interrupted but call drops also severely occur to the BTSs for which no alarm is produced. Therefore, something else must be wrong.

3. Check the GPS status and the satellite locking status of the BTSs. Nothing is wrong. 4. The settings of the DIP switches on the BCIM board affect the locking of the clock.



Query the BCIM board for the interface state. The matched impedance set by the DIP switches is 120 ohm. Consult the engineers at the BTS side. The matched impedance of the E1 should be 75 ohm. Reset the DIP switches to 75 ohm. The call drop rate becomes normal.

Suggestions and Summary

None

Attachment None

2.2 Call drop due to the fault of the BCKM board Title Call drop due to the fault of the BCKM board

SN SC0000346513


Author Gao Sen

Keywords BCKM, Call drop

Symptom On the CDMA800M network (BSCV100R003C03B118SP10BTS3606 V200R001B014SP10) of operator P in Country U, a new BTS, S, experiences many call drops. The call drop ratio is about 10%.

Alarm Information

The alarm console has no problems. In the BTSLOG, a great volume of the following error information is found: 2007-03-09 14:33:34 BCKM 0 MC:(abistimer.c, 854) Abis-BTS Release Timeout! ABIS_CB = 14992007-03-09 14:33:34 BCKM 0 MC:(abistimer.c, 854) Abis-BTS Release Timeout! ABIS_CB = 12252007-03-09 14:33:34 BCKM 0 MC:(abistimer.c, 854) Abis-BTS Release Timeout! ABIS_CB = 13632007-03-09 14:33:34 BCKM 0 MC:(abistimer.c, 854) Abis-BTS Release Timeout! ABIS_CB = 15322007-03-09 14:33:34 BCKM 0 MC:(abistimer.c, 854) Abis-BTS Release Timeout! ABIS_CB = 15382007-03-09 14:33:34 BCKM 0 MC:(abistimer.c, 854) Abis-BTS Release Timeout! ABIS_CB = 15332007-03-09 14:33:34 BCKM 0 MC:(abistimer.c, 854) Abis-BTS Release Timeout! ABIS_CB = 1528

Cause Analysis The fault of the BCKM board causes the transmission problem, so many C02 calls are dropped.

Troubleshooting 1. The new BTS, S, is put into service. The traffic statistics shows many C02 call drops (with no reverse frames received) at a ratio of about 10%. When BTS S is deployed, other BTSs connected to the same frame experience a few C02 call drops. Attachment. 2. Many alarms of the BCKM are found from the BTSLOG. Following the advice from the R&D Department at the Headquarter, the transmission is checked. 3. When the BTS is pinged from the Bam, a TimedOut occurs for nearly 30 minutes or the TimeDelay is greater than 300ms. The transmission is checked segment by segment. A meter is connected at the DDF on the BSC side. The loop-back test of the BTS shows no problem. However, Ping is still unsuccessful. It is suspected that the E1 line from the DDF to the BIE board has a problem. However, the problem remains after modification. 4. Now the attention is directed to any possible version problem. The version of the board at the BTS is checked, and it is found that the BCKM and BCIM have different logical versions. However, the technical support engineers confirm that this does not affect the function.



5. The RSSI is also found to be normal in check. The reverse power control parameters are checked and found to be normal. The drive test EcIo is also normal. 6. The alarms in the BTSLOG are mainly for the BCKM board, so another board is used to test. After the ck board is replaced, the problem is solved. 7. For the problem that why all other BTSs are affected when BTS S has the above fault: Possibly, when a soft handover occurs between BTS S and other BTS, the call drops of the C02 may be accounted to the branches of other BTSs. For the current version, the call drop statistics is: If the access branch is still in the activation set, the call drops are included in the statistics of the branch. Otherwise, the call drops are randomly included to other branches in the activation set.


In some cases, no alarms are produced when hardware faults occur. In the traffic statistics analysis, the CSL analysis can only direct the doubt to the air quality or transmission problems. In this case, you can check the records in the BTSLOG, and check the hardware by replacing the boards.

Attachment

At t achment -Traf f ic St at i st i cs and

2.3 C0b Call drops and A2 interface call drop due to the fault of the FMR

Title C0b call drop and A2 interface call drop due to the fault of the FMR

SN SC0000346617


Author Gao Sen

Keywords Call drop, FMR, C0B

Symptom On the CDMA800M network (BSCV100R003C03B118SP10, BTS3606 V200R001B014SP10) of operator P in Country U, a BTS under BSC_Ter in an area experiences many A2 interface call drops.

Alarm Information None

Cause Analysis The fault of the FMR causes the failure of the TRAU to receive frames, and this causes C0b call drops. In the traffic statistics, a great volume of call drops of the A2 interface is found.

Troubleshooting 1. Analysis the traffic statistics shows that the main cause is call drop of the A2 interface. The reasons of call drop of the A2 interface may be: (1) Abnormal release initiated by the MSC (2) Release initiated by the circuit of the A2 interface due to fault (3) CIE resource fault (4) A3A7 interface resource fault, TIE resource fault and LIM resource fault. If the cause is the transmission problem of the A interface, similar problems should occur at the BTSs in other areas. Therefore, internal causes of the equipment should be further analyzed. 2. Analysis of the CSL log shows that the reason of call drop is C0b



(SDU_TRAU_NO_RECV_FRAME). In other words, the TRAU does not receive any frames for the following possible reasons: (1) The link between the EVC and FMR fails or is of poor quality. (2) During resource verification, the ground links on the bottom layer are deleted by mistake, but the resources on the upper layer still exist. (3)The EVC board is abnormal. However, in this case, the CIE usually detects the fault of the EVC board before the TRAU. In other words, the CIE notifies the CCM to release the call before the TRAU. Analysis of the reason value shows that all C0B call drops are on one FMR, so the attention is directed to the fault of the FMR board of the BSC. 3. The problem is solved after the FMR board is replaced.


The problems other than air interface quality or transmission can be quickly located to internal reasons of the equipment from the CSL.

Attachment None

2.4 The C05 (a call drop indicator) rises after IP transmission is used on the A interface

Title The C05 (a call drop indicator) rises after IP transmission is used on the A interface

SN SC0000402024


Author Meng Qingdong

Keywords A interface, IP transmission, C05, DTMF

Symptom Today, mobile networks are developing toward all-IP networks. The all-IP network can save the investment in the network, especially the investment in transmission, and provides a more flexible networking solution for operators. In an office, the conventional TDM mode is changed to the IP mode on the A interface according to the operator's requirements. One BSC is added and one service frame is created for the MSC. The new BSC is connected through the IP interface with the MSC. Some of the existing BTSs are cut over to the IP transmission mode on the A interface to connect the BSC and get authenticated by the BSC. After three BTSs are cut over to the BSC, the other performance indicators are normal but the call drop rate rises. According to the cause values of the increasing call drops, the C05 (a call drop indicator) rises.



0

5

10

15

20

25

30

35

2007

-10-2

9

2007

-10-3

1

2007

-11-0

2

2007

-11-0

4

2007

-11-0

6

2007

-11-0

8

2007

-11-1

0

2007

-11-1

2

2007

-11-1

4

2007

-11-1

6

2007

-11-1

80

0.5

1

1.5

2

2.5

3

3.5

WALSH Traff ic Density-FCH[Erl] CS Call Drop Ratio[%]

Alarm Information

None

Cause Analysis The C05 rises because the system issues DTMF messages that carry an illegal value after the IP mode is used on the A interface. These DTMF messages cause some types of MSs to restart. As a result, the system cannot receive reverse traffic frames from the MSs and thus releases the calls due to the poor reverse air interface quality. The C05 rises accordingly. When the conventional TDM mode is used on the A interface, the ECV board of the BSC detects the DTMF signal tone. In this network, the switch for detecting the DTMF signal tone is off, that is, the system does not send any DTMF message to the MS. After the TDM mode is changed to the IP mode on the A interface, the UMG detects the DTMF signal tone and the switch for detecting the DTMF signal tone is enabled on the UMG. Therefore, when the UMG detects the DTMF signal tone, the UMG sends a DTMF message to the MS. If the DTMF message carries any illegal value, the MS may restart and the C05 rises.

Troubleshooting 1. Check the data configuration and related logs, and analyze the alarm information. The onsite engineer analyzes all the configuration data, related logs, and alarms with the help of experts in the corporate headquarters. Nothing wrong is found.

2. Cut over the BTSs back to the original BSC. Cut over the tested BTSs back to the original BSC that does not use the IP mode on the A interface. The call drop rate of the BTSs becomes normal. Therefore, the rise of the call drop rate is not caused by changes to the wireless environment, or BTS hardware faults, or transmission faults.

3. Perform a dialing test on site. The network planning engineers perform a dialing test. The test results show that Huawei MS automatically restarts during two outgoing calls and Samsung MS has the Blue Screen Of Death (BSOD) problem during two outgoing calls. The results of signaling analysis and tracing show that all the call drops occur when the system sends a DTMF message that carries a Value equal to 13 to the MS. Because the Value exceeds the range stipulated in the protocol, some MSs automatically restart. When an MS restarts, the system cannot obtain any information on the MS and thus the C05 is incremented by one. For details on the traced signaling messages, see the following figure.



4. Solve the problem.

Modify the value of bit 9 in CCM software parameter 16 of the BSC, so that the system does not send any DTMF message that carries an illegal value to the MS. In case the BSC receives a DTMF message that carries an illegal value from the system, the BSC does not send the DTMF message to the MS. Run the following script: MOD SOFTPARA: SRVMN=CCM, PRMNO=16, PRMV="0x00000200"; After the modification, the call drop rate becomes normal.


The application of the IP mode on the A interface is a systematic engineering project that involves both a change to the interface type and a migration of some functional modules. In this example, the DTMF detection function is performed by the ECV board of the BSC before the IP mode is used on the A interface but performed by the UMG of the MSC after the IP mode is used on the A interface. It is suggested that all the system functions, features, and parameter configuration data be comprehensively reviewed before the network is improved or upgraded.

Attachment None



2.5 Call drops caused by the mismatch between the maximum transmit power of the CDMA TCH and the pilot power

Title Call drops caused by the mismatch between the maximum transmit power of the CDMA TCH and the pilot power

SN SC0000392376


Author Su Ke

Keywords CDMA, call drop, TCH, pilot channel, forward fast power control, code channel power

Symptom 1. Call drops severely occur to a carrier sector. 2. According to the results of the DT performed on the carrier sector, the Ec/Io is

good. Move the MS outward nearby the carrier sector. Although the Ec/Io does not severely degrade, the forward FER severely degrades. As a result, the MS shuts down the transmitter and the system releases the call.

Alarm Information

None

Cause Analysis Possible causes: z Forward interference exists. z The BTS is faulty. z The MS is faulty. z The adjacency is not configured. z The network optimization parameters are incorrectly configured. In particular, the

common channel power and the traffic channel power do not match.

Troubleshooting 1. Move the MS outward from the carrier sector. The Ec/Io does not change much. This indicates that the forward signal quality is good and no interference exists in the forward direction. Perform a frequency scanning test by using the YBT250. Forward interference does not exist.

2. Perform the same test with multiple MSs. The test results are the same, indicating that the problem does not relate to the MS.

3. Check for BTS alarms. No history or current alarm is found. 4. Trace the BTS transmit power and the RSSI. Both are normal. The pilot gain of the

BTS is set to 22 and the transmit power in the zero-load condition is about 41 dBm.

5. Check the parameter configuration of the BTS. The BTS is an isolated site and does not involve adjacency configuration.

6. Check the configuration of forward fast power control of the BTS. The maximum code channel power 1, maximum code channel power 2, and maximum code channel power 3 do not match the pilot power. All of the three are set to the default value 28.

7. Modify the maximum code channel power 1, maximum code channel power 2, and maximum code channel power 3, so that they are equal to the pilot power. Set the minimum code channel power 1 to "pilot power - 16 dB", the minimum code



channel power 2 to "pilot power - 15 dB", and the minimum code channel power 3 to "pilot power - 15 dB". The problem is solved.


1. To deal with the poor quality of forward signals, a network often raises the forward pilot power.

2. During the dialing test, usually the Ec/Io can be improved after you modify the forward pilot power.

3. If you do not synchronously modify the maximum code channel power 1, maximum code channel power 2, and maximum code channel power 3 in the configuration of forward fast power control, the TCH coverage will be far smaller than the common channel coverage. In areas far away from the BTS or areas where a repeater is connected to the BTS, the Ec/Io is good but the FER degrades.

4. Ensure that the common channel gain and the TCH gain are matched.

Attachment None



3 Handoff Problems 3.1 Mobile-assisted hard handoff (MAHHO) failures caused by the excessively small candidate frequency search window

Title Mobile-assisted hard handoff (MAHHO) failures caused by the excessively small candidate frequency search window

SN SC0000328818


Author Qu Ke

Keywords Candidate frequency, hard handoff, neighbor set search window

Symptom In country M, the MAHHO function is enabled for a test. Enable the MAHHO function of the MS on site and configure the basic carrier 260 as the unidirectional adjacent cell of the second carrier 210. The basic carrier 260 uses a frequency different from that of the second carrier 210. Adopt the default values for all the MAHHO trigger thresholds. The MAHHO trigger thresholds are the MAHHO service carrier threshold T_ADD, the MAHHO absolute threshold, the MAHHO relative threshold, the MAHHO search start threshold, and the MAHHO search stop threshold. Problem 1: The drive test data of December 5 shows that no message is found to relate with MAHHO and the hard handoff procedure is not triggered at all. Problem 2: The test is performed again at a new test location in December 8. The test results show that the hard handoff still failed but the signaling procedure related to hard handoff is triggered for multiple times. Refer to Attachment 1 for details.

Alarm Information

None

Cause Analysis Problem 1: Markov calls were used in the test in December 5 (the service option is 0x801f). According to the protocol, Markov calls do not trigger hard handoff. Problem 2: 1. Two MSs were used for the long-duration call test in December 8. According to the

signaling analysis, each time the BSC sends a Candidate Frequency Search Request Message (CFSRQM) (see Attachment 2) to the MS, the MS reports a Candidate Frequency Search Report Message (CFSRPM) (see Attachment 3). In the CFSRPM, the pilot number is 0.

2. According to the drive test results, the pilot strength of the MAHHO target



candidate frequency is very strong when the coverage of the second carrier 210 is very poor and the RX and TX levels are close to causing a call drop. The Ec/Io of the PN224 is about 3 dB (carrier 260) and the RX level is about 60 dBm. When the soft handoff leg is very weak and the signal of the target candidate frequency is very strong, the candidate frequency search results reported by the MS do not indicate any pilot signal that meets the condition, that is, the pilot number is 0 in the CFSRPM reported by the MS.

3. According to the signaling analysis, the BSC instructs the MS to search for the PN224 and the PN392, which are two adjacent cells using the candidate frequency (carrier 260). The results of tracing another MS from the Dingli tester show that the pilot strength of the PN224 is very strong. For details on the signal strength, see the previous subsection 2.

4. According to the CDMA2000 1X Wireless Network Planning and Optimization, the system checks whether the candidate frequency pilot number is 0 in the CFSRPM after receiving a CFSRPM from the MS. If the pilot number is 0, then: 1) the pilot strength of the candidate frequencies is smaller than CF_T_ADD. You can try improving the signal strength of the candidate frequencies; or 2) the clock may be faulty. Check the clock. The results of checking the hard handoff trigger thresholds show that the signal quality meets the threshold settings. Therefore, the possibility of case 1) does not exist. The possibility of case 2) does not exist, either. According to the analysis of the traffic statistics of the two BTSs configured with MAHHO in the test period, the hard handoff success rate (more than 30 times of hard handoff) is higher than 95%. If the clock is faulty, the hard handoff procedure cannot be triggered at all. Therefore, the clock is not faulty.

5. The results of further analysis show that overlapping coverage exists in the urban area. The propagation delay of the candidate frequency 210 is large in the hard handoff area. Before the BSC sends the CFSRQM, the propagation delay of the pilot in the serving cell is 37 chips (330 / 8 - 4 = 37 chips, which can be obtained from the Abis-Propagation Delay Report message). When the distance between the MS and the target pilot is 760 m, the propagation delay is about 3 chips, which can be obtained through the measurement using the Dingli tester. The neighbor set search window is set to 8 ( 60 chips; search window / 2 = 30 chips) on site. However, the path delay difference between two channels of candidate frequency signals is 34 chips (37 chips - 3 chips = 34 chips). Considering the complexity of the radio environment, the delay difference may be greater. Therefore, the valid pilot signals of the candidate frequencies fall outside the search window when the neighbor set search window is set to a small value and thus the MS cannot receive any candidate frequency pilot signal, although some candidate frequency pilot signals are strong enough.

Troubleshooting Change the neighbor set search window from 8 (60 chips) to 10 (100 chips) and change the remaining set search window to 11 (130 chips). Change the forward search windows of the carrier 210 of the BTSs involved in the overlapping coverage from 5 to 10, 8 to 10, and 9 to 11. Change the reserve TCH search window to 2. After modifying the parameters, perform a test again. The MAHHO is successful. Perform a call quality test (CQT) in the hard handoff area. No call drop occurs. The speech quality is subjectively normal.


1. Do not make Markov calls during a hard handoff test. 2. Properly set the size of the search windows for candidate frequency handoff. The

settings are important not only for soft handoff. The size of the search windows



must be properly set according to the actual conditions.

Attachment

At t achment . r ar

3.2 The strong legs of the EV-DO network cannot join the active set when the FMR board is faulty

Title The strong legs of the EV-DO network cannot join the active set when the FMR board is faulty

SN SC0000329223


Author Qu Ke

Keywords FMR, handoff, suspension

Symptom Perform an intra-AN soft handoff test on the EV-DO network in country P. The AT initiates soft handoff and reports a Route Update message. The system returns a Traffic Channel Assignment message. The AT, however, does not receive the Traffic Channel Assignment message. As a result, the strong legs cannot join the active set and strong interference is caused. The adjacency is already configured.

Alarm Information

None

Cause Analysis 1. Analyze the log data of the CAIT. When the PN472 is the serving sector, the AT sends a Route Update message to add the sector PN392 (see Attachment 1) but does not receive the Traffic Channel Assignment message from the AN.

2. According to the information tracing on the maintenance console (see Attachment 2), the BSC has received the Route Update message and sent three consecutive Traffic Channel Assignment messages. Obviously, the Traffic Channel Assignment messages are lost.

3. The alarm console keeps generating alarms about the Abis link. Possibly the Traffic Channel Assignment messages are lost on the Abis link. However, it is impossible that all the Traffic Channel Assignment messages are lost even if the Abis link is really faulty. The log data of the CAIT shows that the AN normally sends periodic messages except for the Traffic Channel Assignment message. Therefore, the Traffic Channel Assignment messages are not lost on the Abis link.

4. Further analyze the data of the CAIT. When the PN472 is the serving sector, plenty of RTC Ack messages (see Attachment 3) are sent on the forward TCH but the AT does not receive the other forward TCH messages. This does not occur to the PN392. According to the protocol, the RTC Ack message is sent only when the AN seizes a reverse TCH during the setup of a connection on the air interface. The RTC Ack message should not be sent in the other cases. Therefore, the problem lies in the AN.

5. Consult the onsite engineers. It is learned that memory suspension occurs to the FMR board in frame 13 of the BSC in country P. The memory suspension can cause



the failure to obtain the memory for receiving inband messages from the other modules. Therefore, the handoff failures are caused by a bug of the FMR board. This bug causes the failure to send Traffic Channel Assignment messages.

Troubleshooting 1. Forcibly load the FMR DSP and then check whether the handoff still fails. If the handoff is successful after the loading, the previous conclusion is verified.

2. Perform comprehensive tests including bidirectional handoff and further collect data for analysis. In this case, soft handoff is successful after the FMR DSP is forcibly loaded. Therefore, the memory suspension of the FMR board caused handoff failures. The forcible loading operation is a workaround only. To thoroughly solve the problem, upgrade the version to the V2R2.


None

Attachment

At t achment . r ar

3.3 The soft handoff success rate decreases due to insufficient CIDs of the PVCs from the BIE to the MUX

Title The soft handoff success rate decreases due to insufficient CIDs of the PVCs from the BIE to the MUX

SN C0000337837


Author Bing Hao

Keywords Soft handoff, log, LSL analysis, traffic statistics

Symptom In office Y, the BSC is upgraded to the V200R002C04B014. Thirteen IP frames are deployed in the Capital to provide CDMA1X services. Each IP frame is configured with three or four 3-carrier or 4-carrier BTSs. It is found during onsite routine maintenance that the soft handoff success rate tends to decrease from 99.799.8% to 9.099.2% in a period.

Alarm Information

None

Cause Analysis 1. Carefully analyze the traffic statistics. The soft handoff failures with the cause value Intra-BS Soft HO Failures (Requested Abis resources unavailable) obviously rise. This cause is the major contributor to the rise of the soft handoff failure rate.

2. Analyze the individual carriers. The traffic statistics of the carriers indicate the same handoff failure cause for multiple carrier sectors in dense-traffic areas. In addition, the failure cause value does not obviously correlate with the frequency or sector.

3. Analyze the time distribution of the problem. The analysis results show that the



problem occurs only in the busy hours (three to five hours) in the morning and at night each day and does not occur in the idle hours or on holidays. This indicates that the problem greatly relates to the allocation of the system resources.

4. Analyze the logs through the LSL. The analysis results show plenty of handoff failures with the failure cause value 702 (CID allocation failure) in the related time segments. The number of handoff failures with the failure cause value 702 is almost the same as the number of handoff failures with the failure cause value Intra-BS Soft HO Failures (Requested Abis resources unavailable).

5. Further analyze the BTSs that involve plenty of handoff failures with the failure cause value 702 through the LSL. The analysis results show that many handoff failures with the failure cause value 702 relate to the three BTSs in one IP frame.

6. Submit the logs and the analysis results to the GCRMS. Analyze the handoff data flow as follows: Source FMR --> Source CMUX --> Destination CMUX --> Destination CBIE (without passing the FMR). As can be seen, only one PVC from the CMUX to the CBIE processes the soft handoff leg at the destination side, that is, only 256 CIDs are available. For this reason, only 256 CIDs are available for the links from the CMUX to the CBIE. When plenty of soft handoff procedures occur between frames, the CIDs are all occupied and no CID is available for the PVC from the CMUX to the CBIE at the destination side. When frame 7 is the destination frame, the CIDs for the PVC from the BIE to the MUX in frame 7 are insufficient. This shortage causes handoff failures. Below is the printed information about frame 7: [.BIE.] TST$ WARNING: No enough CID.SrcCpuId=0x501c0f00,ulDestCpuId=0x501ce100

7. Analyze the geographical distribution of the BTSs and the distribution of the failure cause value 702 obtained through the LSL. The analysis results show that the BTSs in frame 7 are surrounded by many IP frames. For this reason, the BTSs in the other IP frames tend to hand off to the BTSs in frame 7 and thus the CIDs for the links from the CMUX to the CBIE in frame 7 are obviously insufficient. The geographical distribution is almost the same as the statistic results obtained through the LSL.

Troubleshooting 1. Run the LST ALPATH command to query the configuration information on the CIDs of the PVC from the BIE to the MUX in frame 7 and run the ADD ALPATH command to add a link to increase the bandwidth: ADD ALPATH: SRCFN=7, SRCSN=0, DESFN=7, DESSN=7,TRFINDEX=16, OWNERSHIP=SRCFRM, CTRLBTP=CSPU; (TRFINDEX=16 represents 2.8 Mbps)

2. Perform operations on site and confirm that the problem is temporarily fixed. Observe the traffic statistics. The soft handoff success rate becomes normal. For details, see the attachment.


The allocation of the system resources belongs to high-level maintainability design. You must comprehensively check whether similar problems exist and cause resource allocation failures but no maintenance means are provided. The system must also be able to: 1) allow users to query the occupation of the system resources; 2) provide warnings or alarms when the occupation rate of the system resources reaches the threshold; 3) use modular design and provide a convenient capacity expansion solution when the system resources are used up; 4) dynamically allocate the system resources based on the physical configuration of the system and avoid manual setting of the system bandwidth. Currently, 155 Mbps fiber resources are shared for the soft handoff between frames in the CDMA system but the link bandwidth for the soft handoff between frames must be manually configured.



Attachment

Query f or sof t handof f . r ar

3.4 EVDO handoff failure because no inter-EVDO frame soft handoff is configured

Title EVDO handoff failure because no inter-EVDO frame soft handoff is configured

SN SC0000344537


Author Tang Mingtong

Keywords EVDO handoff, Soft handoff link, Missed configuration of adjacent cell, CBSSSTAR

Symptom A CDMA450M EVDO office of Country B reports that: The EVDO soft handoff fails between the reverse 24chips BTS and 96chips BTS with the symptom that the rate falls sharply or the connection is interrupted. On site, the BSS version is V200R001C02B018, the S333 networking is used, and there are two 1X frequencies + one EVDO frequency.

Alarm Information

None

Cause Analysis The causes of EVDO handoff failure or sharp fall of rate include: 1. Missed configuration of the EVDO adjacent cell; 2. Missed configuration inter-BSC handoff area; 3. Pilot pollution. It is never heard that this could have something to do with the configuration of the BTS EVDO channel board chip. The current network has one BSC. Therefore, the cause is preliminarily located as the missed configuration of the EVDO adjacent cell.

Troubleshooting The analysis of the BAM data fed back from the site shows that the adjacent cells are not configured. Further, the EVDO adjacent cell missed configuration detection switch and the Runlog adjacent missed configuration record software parameters are turned on. By analyzing the Runlog file through the CBSSSTAR, it is detected that the adjacent cells are not configured. Therefore, the personnel on site are advertised to add them.

For this purpose, the following commands are used: 1. MOD DORRMMP: DETECMISSPILOTSWITCH=ON; This turns on the adjacent cell missed configuration detection switch, which is off for V1R3 and on for V2R1/V2R2 by default. 2. MOD SOFTPARA: SRVMN=RRM, PRMNO=50, PRMV="0x1"; This turns on the logging switch. The result of the adjacent cell missed configuration detection will be written into the SPU log. Then it is analyzed by using a tool to output the adjacent cell script (same as the 1X adjacent cell). (Note that the above 0x1 means that the value of the bit0 in the No 50 software



parameters of the RRM is changed to 1 from the default of 0. Please use the LST SOFTPARA command to first query the value of this software parameter and then set bit0 to 1) After the adjacent cells are added, some handoffs are successful, but many still fail; Ask the personnel on site to report the latest Bam data. The system parameter settings are restored and checked by using the engineering assistance system, and it is found that two EVDO frames are configured on site, but no soft handoff link is configured between them. It is further found that the BTS in the test area is distributed in the two EVDO frames. Therefore, the inter-EVDO frame link is configured on site. The test result shows the EVDO handoff is normal, and the problem is solved.


The BSC is configured with multiple EVDO frames, between which the soft handoff link must be configured; The EVDO handoff failure is in many cases related to the missed adjacent cells, so the adjacent cell missing detection function of the CBSSSTAR should be fully exploited to discover missed adjacent cells.

Attachment None

3.5 A case of interconnection and hard handoff failure between Huawei BSC and the BSC of vendor Z in country P

Title A case of interconnection and hard handoff failure between Huawei BSC and the BSC of vendor Z in country P

SN SC0000370352


Author Wu Jun

Keywords Hard handoff, interconnection, message

Symptom In the MTR area in project P in country P, the interconnection and hard handoff between Huawei BSC and the BSC of vendor Z failed. The intra-frequency hard handoff mode is used between Huawei BSC and the BSC of vendor Z in voice services. Huawei BSC and the BSC of vendor Z are connected to different Huawei MSCs. During the handoff from Huawei BSC to the BSC of vendor Z, the signaling information at the network side shows that Huawei BSC does not receive the Handoff Request Acknowledge message from the BSC of vendor Z after Huawei BSC sends a Handoff Request message to the BSC of vendor Z, that is, the handoff failed when the 10s timer expires after the Handoff Request message is sent. The failure cause is Requested terrestrial resources unavailable. During the handoff from the BSC of vendor Z to Huawei BSC, the process is smooth till the source MSC sends an HDM message to the MS. The MS returns an ACK message but does not receive the Handoff Complete message sent by the BSC to the MSC. The failure cause is HO Execution Failed. BSC version: V100R003C03 C9MSC version of vendor Z: V100R002C02



Huawei C6MSC version: V610R003C06

Alarm Information

None

Cause Analysis 1. According to a signaling analysis, Huawei BSC receives a Handoff Request command from the MSC when Huawei BSC serves as the destination BSC. In the command, the Band Class is 0 (800 MHz). Huawei BSC sends a Handoff Request Acknowledge message to the MSC. In the Handoff Request Acknowledge message, the Band Class is 5 (450 MHz). Then the negotiation fails and subsequently the handoff fails.

Cause: In the handoff procedure, the MSC must transmit the Band Class carried in the



message received from the destination to the source. The source MSC transparently transmits the Band Class. If the MSC cannot obtain the Band Class, the MSC uses the preset values of bits 4 through 8 in A interface parameter 2. In this example, the Band Class uses the default value 0 (800 MHz). This parameter is mandatory for call migration during the handoff. Change the value of bit 9 in MSC software parameter 91 to 0. After the modification, the signaling information indicates that the Handoff Request message carries the correct Band Class (BandClass=0x5) but the handoff is still unsuccessful.

2. According to a further analysis, a hard handoff test was once performed and the hard handoff was successful, later the LACs were re-planned on the BSC of vendor Z, and the hard handoff was not successful after Huawei engineers modified the parameter values (it is not clear whether the BSC of vendor Z was upgraded or other operations were performed). Compare the handoff signaling before and after the LAC parameters of the area are modified. The signaling information on the left (see the diagram in the attachment) indicates the content of the UHDM message received by the MS when the hard handoff from the BSC of vendor Z to Huawei BSC fails. The signaling information on the right (see the diagram in the attachment) indicates the content of the UHDM message received by the MS when the hard handoff from the BSC of vendor Z to Huawei BSC succeeds. As can be seen from the content marked by the red circle, in the UHDM message received by the MS upon a hard handoff failure, the values of the handoff-related parameters of the target BTS (Huawei BTS) are obviously incorrect (see the diagram in following).

The system parameters should be carried in the Handoff Request Acknowledge message and sent by Huawei BSC to the MSC. Then the message should be sent by the MSC to the BSC of vendor Z, and finally sent by the BTS of vendor Z to the MS. In the Handoff Request Acknowledge message reported by Huawei BSC, the values of the handoff-related parameters are correct and do not change.



Possibly the mandatory fields are lost in the message transmission process. Check the fields in the E interface message and the Handoff Command message. For details, refer to the following:



In the E interface message from the C9 of vendor Z to Huawei C6, the handoff-related parameter fields carry the active set fields only. The other handoff-related fields, such as the neighbor set and the remaining set, are lost. For this reason, the handoff-related parameter fields in the Handoff Command message sent from the MSC at the side of vendor Z to the BSC of vendor Z are incorrectly set to the default value 0. Accordingly, the values of some fields in the UHDM message reported by the BSC are incorrect. This is caused by the message processing abnormality of the MSC at the network side.

Troubleshooting 1. Modify the value of MSC software parameter 91 from FC0F to DC0F so that all the parameters required for handoff are transparently transmitted in the E interface message (Huawei devices at the network side provide a means to modify software parameters to solve the problem).

2. Check the traffic statistics. The traffic statistics show that the problem does no longer exist.


None

Attachment None



4 Interference Problems 4.1 The RSSI of a BTS is slightly high due to the interference from a repeater

Title The RSSI of a BTS is slightly high due to the interference from a repeater

SN SC0000363071


Author Liu Jingxin

Keywords RSSI, frequency, repeater

Symptom After the capacity of a BTS is expanded from the S111 to the S112 (that is, from a single carrier to dual carriers), some subscribers in the coverage of the expanded sector cannot make calls. The area is within the coverage of a repeater. The onsite test results show that the signal quality is good.

Alarm Information

None

Cause Analysis Possible causes: z External interference exists. z The onsite radio environment is poor. z The BTS is faulty. z A repeater exists in the sector. The repeater is faulty.

Troubleshooting 1. Perform an onsite test. The air interface tracing results show that the Ec/Io ranges from 16 dB to 21 dB, the RX level ranges from 75 dBm to +89 dBm, and the subscribers at the site cannot originate or receive calls.

2. Trace the RSSI. The average main-set RSSI ranges from 90 dBm to 100 dBm, the average diversity RSSI ranges from 89 dBm to 99 dBm, and the difference between the main-set RSSI and the diversity RSSI is within 3 dB.

3. Check for alarms. No alarm occurs to the equipment in the network. 4. Check the configuration data. The data is configured according to the general

engineering parameter table. 5. Check the traffic statistics. The traffic statistics show that the call drop cause is poor

radio signal quality. 6. Trace the RSSI of the sector. The RSSI of the sector is about 88 dBm in the time



period complained by subscribers. Huawei equipment uses the RSSI as an indicator to indicate reverse interference. Normally, the RSSI should be below 95 dBm.

7. Trace the carrier output power of the sector. The output power is about 40 dBm, which falls within the normal range.

8. Perform an onsite test: Perform a dialing test along the route from the BTS to the repeater. The calls are normal until the MS arrives at the repeater. Nearby the repeater, subscribers can hardly make calls.

9. Shut off the repeater and trace the RSSI of the sector. The RSSI is about 105 dBm. Subscribers can normally make calls nearby the repeater.

10. Communicate with the provider of the repeater. The repeater is a frequency-shift wideband repeater. Before the capacity expansion, the BTS uses frequency 47. After the capacity expansion, the BTS uses frequencies 47 and 110. The wideband repeater shifts frequency 47 to a frequency close to the frequency range of frequency 110. As a result, the signal of the frequency after the shift and the main signal of frequency 110 of the BTS interference with each other, causing the failure of subscriber calls.

11. Replace the repeater with a narrowband frequency-shift repeater and change the frequencies of the network to frequencies 47 and 160. Frequency 160 does not interfere with the frequency of the repeater after the frequency shift. After the replacement and the change, no interference occurs between the used frequencies and thus subscribers can normally make calls nearby the repeater.


1. Adjust the system parameters especially the search windows as required when a repeater is used. The reverse access search windows are the major influencing factors to the access procedure.

2. Properly consider the signal cooperation and overlapping between the target coverage area and the surrounding BTSs during the planning to avoid interference.

3. Learn the state of the entire network before troubleshooting to help quickly discover and solve the problem.

4. Learn the type and operating principles of the repeater used in the network to help quickly discover and solve the problem if a repeater is used at the BTS site. Summary: In addition to resorting to data tracing and data analysis, learn the site conditions, perform tests, and investigate the problem on site to help quickly locate the problem cause.

Attachment None

4.2 The difference between the main RSSI and the diversity RSSI is sometimes normal but abnormal at the other time of a day due to incorrect connection of the spatial diversity antennas of the sectors

Title The difference between the main RSSI and the diversity RSSI is sometimes normal but abnormal at the other time of a day due to incorrect connection of the spatial diversity antennas of the sectors

SN SC0000336840




Author Na Weiqi

Keywords Diversity antenna, call drop, traffic balancing, abnormal RSSI

Symptom In a relocation project, the equipment of vendor L is relocated, the old antenna feeder system is reused, and the BTSxx (Model 3606, configuration: 1X S4/4/4) is cut over to the network (an isolated site). According to the tracing performed after the cutover, the VSWR, RSSI, dialing test data, and drive test data are all normal. The results of a routine performance analysis performed on the next day, however, show that the call drop rate of the carriers of sectors 2 and 3 is slightly higher. Check the RSSI in real time. The difference between the main-set RSSI and the diversity RSSI of the carriers is great (more than 10 dBm in the severest case), but the absolute value of the RSSI is within the normal range (110 dBm < RSSI < 95 dBm). Further observe the RSSI statistics of all the time segments (by hour) since the commissioning. The results show that the difference slowly increases.

Alarm Information

None

Cause Analysis 1. The BTS uses a single-polarized spatial diversity antenna. External interference may cause great difference between the main-set RSSI and the diversity RSSI.

2. Improper equipment installation. Everything is normal at the night when the cutover is performed. The RSSI difference gradually increases and the increase seems to follow a certain rule. Since many departments need to be involved to solve the problem (in particular, cooperation from the customer is required), the problem is temporarily laid aside. View the busy-hour traffic. The traffic is severely unbalanced between the fourth carrier of sectors 2 and 3 and the other three carriers. View the traffic of the whole day. The degree of traffic unbalance tends to gradually sharpen. Now, the BTS has another problem, that is, the traffic load is unbalanced. The BTS uses the HASH frequency selection policy and does not enable hard assignment. Therefore, the traffic unbalance between the carriers is caused by inconsistent coverage. The inconsistent coverage may be attributable to the transmit power of the carriers. Check the transmit power and the power-related parameter configuration. The carriers have the same transmit power and power-related parameter configuration. Check the admission control parameter (actually the default value is used). Nothing wrong is found. The inconsistent coverage is not likely to be caused by forward interference, because the transmit power of the fourth carrier of sector 2 is low, the transmit power of the fourth carrier of sector 3 is high, and it is the same with the other three carriers. Carefully view the related traffic data. The traffic is almost balanced if the traffic of the fourth carrier of sector 2 is interchanged with the traffic of the fourth carrier of sector 3. Therefore, the diversity antenna of sector 2 and that of sector 3 may be reversely connected to cause the reverse connection of the fourth carrier (on TRX boards 2 and 4), that is, the fourth carrier of sector 2 is transmitted from sector 3 and that of sector 3 is transmitted from sector 2. Because the coverage of the fourth carrier of sectors 2 and 3 is different from that of the other three carriers of the sectors, the traffic is unbalanced. The main-set antenna and the diversity antenna of the sectors are distributed to different sectors, so the RSSIs are different. In addition, the subscribers in each sector have only one receive antenna and thus the call drop rate increases. Why is the symptom (abnormal RSSI and unbalanced traffic) more and more obvious? The answer is simple. The traffic in the coverage area of sector 2



is different from that of sector 3 and so the symptom is not obvious in the early morning when the traffic is light. The drive test involves only the first carrier (384) but the fourth carrier is located on another TRX board. The conclusion previously drawn is thus possible.

Troubleshooting The drive test resources are scarce at the site. Temporarily, a drive test cannot be performed on the fourth carrier (507). Therefore, check the hardware connections to locate the problem cause. 1. Check the diversity antennas of sectors 2 and 3. The connection is correct at one end

of the CDDU, but the diversity antennas are reversely connected at the tower end. 2. Correct the connections of the diversity antennas. The problem is thoroughly solved.


1. The drive test in single-site verification must cover at least one frequency of each TRX board to eradicate the problem. It is lucky that the BTS site in this case is an isolated site. If the BTS site is not an isolated site, other problems such as improper adjacency configuration may also result in worse performance.

2. Network optimization engineers need to gain sufficient product knowledge to help locate the problem cause and solve the problem together with the other departments.

Attachment None



5 Data Configuration Problems 5.1 The call setup success rate and the handoff success rate sharply decrease due to insufficient signaling link bandwidth

Title The call setup success rate and the handoff success rate sharply decrease due to insufficient signaling link bandwidth

SN SC0000335260


Author Tan Zhiwei

Keywords Signaling link bandwidth, call setup success rate, handoff success rate

Symptom In an office in country S, the call setup success rate of a BTS is only 20% to 40% in busy hours but more than 95% in idle hours. In addition, the soft handoff success rate of the BTS and the surrounding BTSs ranges from 80% to 95%. Normally, the value should be greater than 98%. The soft handoff success rate is far lower than the normal value.

Alarm Information

Check the BTS log files. Plenty of Abis-Connect/Release Ack Timeout records relate to the BTS.

Cause Analysis 1. Check the traffic statistics: All the carriers have this problem. The call failure cause indicates resource allocation failures, which do not relate to TCH assignment failures but are attributable to Abis resource allocation failures. The SHO failure cause indicates Abis resource allocation failures. The problem occurs in busy hours on the whole day but does not occur in idle hours. Therefore, the problem relates to traffic to some extent. However, the traffic of the highest-traffic carrier is only about 12 Erl (the traffic of the whole BTS is 80 Erl).

2. Check the logs: View the BSC Runlog. The failure cause is 0x0f1f, that is, the timer for the BSC LCB to wait for the Abis-Setup-Ack message expires (the default value 3 s is used for the network). View the BTS log. Plenty of Abis Timeout messages (Abis-BTS Release Timeout! and Abis-Connect Ack Timeout!) are generated in busy hours. )

3. Check the message tracing results:



About one second after the BSC sends an Abis-Setup message, the BTS sends an Abis-Connect Request message. The BSC immediately responds with an Abis-Connect-Ack message and then waits for the Abis-Setup-Ack message. If the Abis-Setup-Ack message is not received within three seconds, the BSC sends an Abis-Release message to release the link and returns an assignment failure message (with the cause value being equipment failure) to the MSC. About three seconds (or five to nine seconds) later, the BTS returns an Abis-Setup-Ack message. As can be seen from the analysis, the problem cause is Abis link message transmission timeout (in fact, the message is sent). Further check for alarms of the BTS. No transmission alarm is found. Perform a ping test. The ping delay ranges from 15 ms to 30 ms. Run MML commands to check the state of the E1 links and IMA groups. Everything is normal. Therefore, the problem lies in the configuration of the Abis links.

Troubleshooting 1. Originally, the BTS used the S111 configuration. The operator upgraded the BTS to the S222. Run the LST BTSLNK command. The results show that two E1 links are configured (the service bandwidth is 3200 kbps) and the link configuration of the BSC is completely consistent with that of the BTS. No problem is found.

2. The signaling link bandwidth of the BTS is 110 kbps. After the BTS was upgraded to the S222, the operator did not change the configuration of the signaling link bandwidth. Modify the signaling link bandwidth to 210 kbps. The call setup success rate of the BTS is restored to about 99%, and the soft handoff success rate of the BTS and the surrounding BTSs is restored to 99% or above.


Careful and correct logical reasoning is the key to solving network problems. Configure Abis link bandwidth strictly in accordance with the Wireless CBSS Maintenance Dept. Technical Notice [2004] No. 006 Technical Notice on the Configuration of the Channel Boards and Bandwidth for Common Site Types of the CBSS.

Attachment None

5.2 MS access failures caused by the small value of MAX_CAP_SZ

Title MS access failures caused by the small value of MAX_CAP_SZ

SN SC0000399929


Author l44958

Keywords MAX_CAP_SZ, RACH

Symptom The results of a service test performed on a site show that it is hard to call some numbers. Perform multiple tests. The call fails if the dialed number consists of more than 14 digits.

Alarm Information

None

Cause Analysis The access failure occurs only when some special numbers are dialed. In general, the problem cause can be located through signaling tracing. Therefore, use both the CAIT



and the LMT to trace the signaling during the test. The signaling analysis results show that the Origination Message initiated by the MS does not carry the complete called number and thus the call fails when a long number is dialed.

Troubleshooting During the access of an MS, each access probe consists of the RACH PREAMBLE and the RACH MESSAGE CAPSULE, as shown in the following figure.

The Origination Message is carried in the RACH MESSAGE CAPSULE. According to onsite signaling tracing, in the Origination Message initiated by the MS, the num_fields can be set to a value no greater than 14. In this example, the num_fields is set to 14 and the more_fields is set to 1, indicating that the dialed number consists of more than 14 digits. In this case, the Origination Message cannot carry all the dialed digits. As a result, the called number is incomplete and the call fails.

Probably the RACH MESSAGE CAPSULE is too small to hold all the dialed digits in the Origination Message. Analyze the Access Parameter Message. The value of



MAX_CAP_SZ sent by the system is set to 2 (the recommended value is 3 or 4).

The length of the RACH MESSAGE CAPSULE is 3+MAX_CAP_SZ in frames. The rate of the RACH is fixed as 4800 bps and the length of the access channel frames is 20 ms. Therefore, the length of a frame is 96 bits. Each access channel frame consists of 88 information bits and 8 coded tail bits.

In this example, MAX_CAP_SZ is set to 2. Therefore, the length of the information in the RACH MESSAGE is (3+MAX_CAP_SZ) 88 bits = 55 octets. In the Origination Message, the num_fields can carry only seven octets totaling 14 digits. Run the MOD ACH: MAXLEN=3; command to change the value of MAX_CAP_SZ to 3. Then the length of the RACH MESSAGE CAPSULE increases to six frames and the maximum length of the num_fields is about 18 octets (36 digits) to support the Data Burst Messages that carry a large amount of information. After the modification, the problem is solved.


None

Attachment None

5.3 Hard handoff failures caused by the small search window size set on the BSC of vendor M

Title Hard handoff failures caused by the small search window size set on the BSC of vendor M

SN SC0000401870


Author l44958

Keywords Hard handoff, search window

Symptom In an office, the hard handoff test results show that the hard handoff from Huawei BSC to the BSC of vendor M fails. The signal of the cells of vendor M can be normally detected in Huawei network. Huawei BSC sends a Handoff Required message to the MSC. After receiving a Handoff Command message, Huawei BSC sends a UHDM message. Huawei BSC does not receive the MS Ack Order Message from the MS. The handoff fails.

Alarm Information

None

Cause Analysis The BSC does not receive the MS Ack Order Message from the MS after sending the



UHDM message. This indicates that the handoff on the air interface fails. The failure may be related to the following causes: z The forward and reverse coverage effect of vendor Z is poor. Accordingly, the setup

of a connection on the air interface fails. z The frequency, PN, and/or Walsh code in the sent UHDM message are wrong. z The neighbor set search window in the Handoff Command message sent by the BSC of

vendor M is too small and thus no neighboring cell is found.

Troubleshooting 1. Check the pilot strength in the PSMM message. During the handoff, the forward Ec/Io of the sector of vendor M is 5 dB and that of Huawei is 9 dB. The air interface signal quality is good.

2. Check the frequency, PN, and Walsh code carried in the UHDM message. Nothing wrong is found. Probably the neighbor set search window set on the BSC of vendor Z is too small.

3. As can be seen from the PSMM message, the shift of the neighboring cell PN30 (the BTS of vendor M) is up to 60 chips, that is, the neighbor set search window must be set to a value greater than 60. Below are the fields in the PSMM message: ref pn: 0x180(384) pilot strength: 0x12(18) keep: 0x1(1) pilot pn phase:0x7BC(1980) pilot strength: 0x0a(10) keep: 0x1(1) In the Handoff Command message that carries the peer search window from the BSC of vendor M, the search window of the active set and that of the neighbor set are set to 40 chips.

The UHDM message sent by Huawei BSC also carries the information on the peer search window. Before the MS receives the UHDM message, the MS searches for



valid signals based on the search window set by Huawei BSC (source). After receiving the UHDM message, the MS searches for valid signals based on the search window set on the peer BSC. Therefore, after the MS receives the UHDM message, the MS searches for the pilot signal of the PN30 in the range of the 40 chips only but fails to detect the pilot signal. The setup of a connection on the air interface thus fails.

4. Increase the value of the neighbor set search window set on the BSC of vendor M and then perform a hard handoff test again. The hard handoff is successful.


None

Attachment None

5.4 The data of the RFMT cannot be traced due to incorrect settings of signaling software parameters of the BTS

Title The data of the RFMT cannot be traced due to incorrect settings of signaling software parameters of the BTS

SN SC0000398451


Author Li Shichuang

Keywords RFMT set cbtssigsoftpara

Symptom To locate the cause of subscriber call drops, FRMT tracing is enabled. However, the RFMT data of the BTS cannot be traced. The onsite BTS version is the V3R2C01B020CP002.

Alarm Information

None

Cause Analysis During routine maintenance, the RFMT is used to locate the problem cause and trace the related information. It can be used to trace the following information: z Carrier power information (such as BTS transmit power and RSSI) z Call information (such as the forward/reverse FER, the forward power received by the

MS, the forward Ec/Io, and the Eb/Nt) z Neighboring cell information (such as the pilot set to which the target pilot belongs and

the neighbor cell ID). Run the SET RFMT1X command to enable 1X tracing and run the SET RFMTDO command to enable DO service tracing. Many items can be traced in 1X tracing through the RFMT. You can select tracing the call information of an entire sector carrier, the specified IMSI, unspecified IMSIs, or neighboring cell optimization information. Currently, the DO service tracing through the RFMT supports IMSI tracing only.

Troubleshooting 1. Run the SET RFMT1X command to enable RFMT tracing of the BTS. The command is normally run and no error message is displayed.

2. Check the data configuration of the BTS. The cbtssigsoftpara settings are wrong. Both max1xrfmttracenum and maxdorfmttracenum are set to 0. In the current version, the two parameters are set to 5 by default. Run the following commands to restore the



settings of the two parameters to 5. set cbtssigsoftpara:btsid=350,max1xrfmttracenum=5,maxdorfmttracenum=5,confirm=y; set cbtssigsoftpara:btsid=360,max1xrfmttracenum=5,maxdorfmttracenum=5,confirm=y; Enable RFMT tracing.


Pay attention to the following points when enabling RFMT tracing: 1. Do not simultaneously enable carrier tracing and IMSI tracing. Different types of

RFMT tracing are mutually exclusive. Therefore, only one type of 1X RFMT tracing can be enabled at one moment. You can select only IMSI tracing or carrier tracing but not both. To query RFMT tracing, run the DSP RFMT command.

2. Before enabling a new RFMT tracing task, disable the same type of tracing previously enabled (except for tracing the specified IMSI; you can run the SET RFMT1X: OPT=CLOSE_ALL_RFMT_TRACE command to disable the RFMT tracing previously enabled.)

3. Before enabling an RFMT tracing task, clear the directory for saving the tracing result files, that is, clear the files in the F:\cdma2000\TRACE\RFMT1XIMSI or F:\cdma2000\TRACE\RFMT1X\ directory on the BAM server.

4. Before enabling RFMT tracing, correctly configure the BTS data. When setting the signaling software parameters during the configuration of the BTS data, the values of max1xrfmttracenum and maxdorfmttracenum must not be 0. If they are set to 0, the RFMT data of the BTS cannot be traced even if you run the relevant command to enable the RFMT tracing function of the BTS. Instead, you must run the set cbtssigsoftpara command to correctly set the values of max1xrfmttracenum and maxdorfmttracenum. The two parameters are used to control the number of subscribers that can be traced through RFMT tracing of the BTS. By default, the two parameters are set to 5. Unless otherwise stated, do not change the default settings of the parameters in the command lines during the data configuration.

Attachment None

5.5 Many A22 access failures after the BSC is upgraded Title Many A22 access failures after the BSC is upgraded

SN SC0000347997


Author Qu Ke

Keywords A22, Concurrent assignment

Symptom In December, after the version of the BSC in a U office in a foreign country was upgraded from V1R3C03 to V2R2C04, many A22 access failure reason values are found when the Runlog data is analyzed in the Cbsstar. Before the upgrade, the A22 reason value is nearly 0 in the reason value statistics of the access failure. Could this be caused by hte version upgrade of the BSC? Will the access failure reason values in the statistics



affect the access of the users?

Alarm Information

None

Cause Analysis The A22 interface failure is a kind of failure of the A1 interface. This happens like this: In the earlier stage when the call is set up, the BSC sends the CM SERVICE REQUEST message, and the application layer of the MSC sends the release of a certain reason to the SCCP layer of SS7. Such early release is control by the software parameter of the BSC (software parameter of 26 the CCM). According to the software query result returned from on site, this software parameter has been turned off. In this case, such release is taken as a premature release and is thus excluded from the traffic statistics. This is what happens on site. According to the signaling on the B side from the site, there are two reasons for such call setup failure: 1. After the BSC sends the CM SERVICE REQUEST message, the MSC directly returns the N_DISCONNECT_IND message. This accounts for 1/3 strong of the release messages from the M side. The signaling is shown in Figure 1; 2. After the BSC sends the CM SERVICE REQUEST message, it initiates the release before the MSC sends the Assignment Request message. The signaling is shown in Figure 2; For the versions before V2R2C04, the many access failure reason values of A13 result from the authentication failure, as the invalid user. After upgrade, due to the version, these reason values of A13 are converted into A22. However, as the concurrent assignment switch is turned on, the generated A22 includes not only A13, but also the premature release part; For the version before upgrade, the BSC does not start allocating the internal resources until the MSC delivers the Assignment Requst message. Currently, the BSC version is V2R2C04. In the software parameters of our system, the concurrent assignment switch is turned on (software parameter CCM30). After concurrent assignment is enabled, the following processes are performed concurrently: 1) The process of waiting for the assignment request; 2) The process of allocating the internal resources; When this switch is turned on, the call setup period is reduced. If the BSC internal resource allocation fails before the MSC finishes assignment, the BSC will directly send the release order to release the call (as shown in Figure 2); The later call attempt will cause the MSC to release the call since it believes that the call block status is inconsistent. In this case, the MSC will send the N_DISCONNECT message (as shown in Figure 1). This may cause the reason value of A22. In other words, the N_DISCONNECT occurs when another call attempt is initiated while the internal resource allocation is unsuccessful.

Troubleshooting Currently, the concurrent assignment switch can be first turned off to reduce the number of A22 access failures, by using the following command: MOD SOFTPARA: SRVMN=CCM, PRMNO=30, PRMV="0x00000031"; (0x31 can be converted into 00110001 in the binary system, that is, bit 4 is changed to 1). This command can be modified on line, without affecting the services. However, it may become low in connection, and the traffic statistics will show the real failure causes; The old A13 part is caused by the invalid users, so it does not affect the traffic statistics indexes.


None



Attachment

pi ct ure. r ar

5.6 Failure of all the subscribers in the network to make calls because the INIT_PWR parameter is set too large

Title Failure of all the subscribers in the network to make calls because the INIT_PWR parameter is set too large

SN SC0000357454


Author Zhang Tingji

Keywords INIT_PWR set too large, Subscriber access failure, Failure to make calls

Symptom For the CDMA450 network in a city, on the day when the optical port office is demployed, the CDMA subscribers cannot make calls.

Alarm Information None

Cause Analysis The network in the city is subjected to some stable external interference, which cannot be eliminated in the short period (the interference comes from the adjacent country). Despite the interference, the subscribers could be connected to the network before May 30, except that the call drop ratio is slightly higher (about 2.5%); When the optical port office deployment ceremony was held, the number of CDMA subscribers increased sharply. In the morning, the subscribers of the network in the entire city could not make phone calls;

Troubleshooting For the external interference (which is stable), the reverse filtering anti-interference function and reverse RSSI hard assignment function have already been enabled. The most probable reason of this symptom is the increased internal interference of the CDMA system. The increased internal interference may result from: 1. The number of subscribers increases, and so the network load increases, causing higher internal system interference. For the increased number of subscribers on May 30 (about 10% increase on the old network load), the network-wide load was about 30%. Subscriber access failure should not occur at such a network load;

2. The network parameters are set improperly, causing severely increased interference in the system.


Check all the related access parameters of the APM. It is found that the INIT_PWR is set to 6dB (while the system default is 0dB);



After the INIT_PWR is modified to 0dB, the fault is eliminated, and subscribers can make calls normally; Because the INIT_PWR is increased by 6 times, the Tx power of the first probe for MS access becomes four times of the original. This causes a sharp rise in the interference in the system with a low load, and subscribers cannot make calls as a result; The network planning and optimization parameters should be designed to be appropriate, which is the best. The greater or smaller is not necessarily the better.

Attachment None

5.7 Call setup failures caused by poor cooperation between Huawei MSC and the HLR of other vendors during network swap

Title Call setup failures caused by poor cooperation between Huawei MSC and the HLR of other vendors during network swap

SN SC0000358467


Author Tang Chao

Keywords HLR cooperation, call setup

Symptom In a CDMA network migration project of operator T in country I, Huawei MSC and BSC and the HLR of vendor S are used. One area is cut over on a night. The traffic statistics on the second day show that call exceptions occur. The call setup success rate is 90% only. In busy hours, the call setup success rate of terminating subscribers is 50% only. A drive test is performed in the afternoon. The test results show that it is very difficult to make calls and the caller always hears the prompt tone "the network is busy". The same problem occurs after another area is cut over next day.

Alarm Information

None

Cause Analysis The traffic statistics show that 85% of the call setup failures are caused by the failure of the A1 interface. A dialing test is performed on site. The results of tracing subscriber interfaces of the BSC and the MSC reveal two problems as follows: 1. After sending the CM Request message, the BSC does not receive the Assignment

Request message from the MSC. 2. After the Assignment Complete message is sent to the caller, the Paging Request

message cannot be sent to the called subscriber. The location request timed out on the MSC. Check the location update information in the traffic statistics of the MSC. Plenty of location update failure messages are found. It is preliminarily judged that something is wrong with the cooperation between Huawei MSC and the HLR of vendor S.



Troubleshooting 1. Notify the operator to check HLR-related operations. The check results show that system patches were installed for the HLR last night.

2. Ask vendor S to perform HLR-related operations. The problem is solved.


1. Performance monitoring is very important during network migration. Pay attention to the network quality, timely locate the equipment faults in the case of abnormal performance indicators, analyze the traffic statistics, and combine onsite dialing tests with signaling tracing.

2. When network problems occur, arrange onsite tests as much as possible, handle the problems at the earliest possible time, timely notify the equipment faults to all the related people, guarantee that no subscriber complaint is raised during problem handling, and actively discover and solve problems with customer satisfaction guaranteed.

Attachment None

5.8 OTAPA operation failure of the CDMA fixed station terminal due to inconsistent A_KEY value

Title OTAPA operation failure of the CDMA fixed station terminal due to inconsistent A_KEY value

SN SC0000375900


Author hubing

Keywords OTAPA, A_KEY value

Symptom Project I in Country M uses the 450M WLL system of Huawei. Phase 1 is completed and the sites of phase 2 is under way, totally 14 RACs. A total number of 85 BTSs are deployed in phase 1 and phase 2. The version of the RAC is RAC6610V200R001ENGC03B013SP04. The subscribers use the Huawei CDMA wireless fixed stations 2000 and 2006 as the terminals. The old roaming restriction method required by the customer caused many problems. Now it must be changed, and the existing terminals must be written with numbers again as a result. To avoid call back such terminals, we plan to write the numbers through the air interface by using the OTAPA. However, after the operations specified in the guide manual are performed, the SET SUBSCRPRL command is not successfully executed, so the OTAPA number writing fails.

Alarm Information

None

Cause Analysis When the terminals can make calls, the SET SUBSCRPRL authentication failure may be caused by the following reasons: 1. The system authentication switch is not turned on (using the MOD VCNSYSINFO command); 2. The HDB authentication switch is not turned on (using the MOD HDBCFG command);



3. The sector/carrier authentication switch is not turned on (using the MOD AUTH command); 4. The subscriber authentication capability is not enabled (using the MOD SUBSCR command); 5. The A_KEY values are not set consistently.

Troubleshooting 1. Verify that the authentication switch, HDB authentication switch, and sector/carrier authentication switch of the system are all turned on according to the guide manual. 2. When the subscriber authentication capability is checked, the following strange symptom occurs: When the Authentication Capability is set to Yes by using the MOD SUBSCR command, the test subscriber cannot make calls or receive calls. However, if the Authentication Capability is set to No, the test subscriber can make calls. Next when the SET SUBSCRPRL command is executed, the system prompts that this command cannot be executed successfully (because the Authentication Capability must be enabled in order to execute it). Therefore, the preliminary conclusion is that this switch must be turned on. However, after it is turned on, the subscriber cannot make calls. This seems to indicate that the problem does not lie in the authentication switch, while some inconsistency occurs during the authentication proce

cases of cdma issues and their soulutions

Documents