Troubleshooting Case Collections for CDMA Radio Network Optimization 2009

Troubleshooting Case Collections for CDMA Radio Network

Optimization

2009-7-15 Confidential Information of Huawei 1/ 24

Troubleshooting Case Collections for

CDMA Radio Network Optimization (For Reference Only)


Optimization


Table of Contents Case1 CDMA-GSM co-site Interference .................................................................................3 Case2 Troubleshooting About Too Many Times of Resource Allocation Failure Exist in EVDO Network................................................................................................................................4 Case3 Mobile-assisted hard handoff (MAHHO) failures caused by the excessively small candidate frequency search window ...........................................................................................6 Case4 The number of C05 call drops rises after IP transmission is used on the A interface 8 Case5 The call setup success rate and the handoff success rate sharply decrease due to insufficient signaling link bandwidth ......................................................................................10 Case6 Call drop caused by Synchronizations problem.......................................................12 Case7 High FFER although we have good Ec/IO and RX .................................................13 Case8 Abnormal RSSI problem..............................................................................................14 Case9 Voice Quality Complaints About Clicks .....................................................................15 Case10 Call drops caused by the mismatch between the maximum transmit power of the CDMA TCH and the pilot power .................................................................................................17 Case11 LAC planning problem causing High RSSI ................................................................19 Case12 Faulty bandwidth sharing mechanism causing EVDO speed slow ........................20 Case13 SPU Loading Causes 'Subsystem Severe Overloaded' BSC Alarm .....................22 Case14 High call drop ratio due to synchronization problem of BTS ...................................23 Case15 Early paging causes low paging success ratio..........................................................24


Optimization


Title Case1 CDMA-GSM co-site Interference

Update Date 2009-01-01

Fault Type Interference Problem Product CDMA RNO

Phenomena Description

CDMA-GSM co-site Interference has been reported in the Orange GSM sites deployed by E company. Hw existing CDMA Bts TX operates at 870-875Mhz close to GSM RX 880-882.5Mhz. Antenna seperation of 1+metres but inteference still occurs

Alarm Info. None

Cause Analysis

Minimal guard separation of E_GSM and CDMA of 5Mhz introduces blocking interference to the GSM RX. Required [Antenna Isolation ] = [CDMA Transmit Power] - [Feeder Cable Loss] - [GSM receiver’s Blocking level] According to GSM specification requirement, [GSM receiver’s Blocking level] is -13dBm, [CDMA Transmit Power] is 46dBm(dual carriers), [Feeder Cable Loss] is considered to be 4dB, In Case of GSM receiver to be blocked , Required antenna isolation to be 46-(-13)-4=55dB. For CDMA signal, GSM blocking level will degrade at least 8dB, so required isolation should be 63dB. Since there is no horizontal platform on the tower for Telkom; we do suggest the vertical isolation to done. Considering 63dB isolation requirement, if antennas are face-to-face, required isolation distance is 16.1 meters；If two main beam have the same direction, it needs 2.5m to meet the requirements. Formula :Iv=28+40log(d/λ )-Gt - Gr .Iv is Vertical isolation, d is distance, λ is wave length. When antennas are opposite directly Gt + Gr=32dBi, two main beam have the same direction Gt +Gr=0dBi.

Handling Process

1. Higher value of Lv(antenna Isolation)i.e 63dB, After calculation we find the minimum required isolation distance is 2.5M between BAH and TAH of the two antennae. we should keep 2.5m vertical distance between GSM and CDMA antenna . 2. The distance (dv) between the bottom of Antenna1 and the top of Antenna2 is 2.5m. 3. The Azimuth of the GSM and CDMA antennas should be the same. 4. If the CDMA antenna is higher, keep the down tilt smaller or the same with the GSM antenna. If the CDMA antenna is lower, keep the down tilt the same of bigger than GSM antenna

Suggestions None


Optimization


Title Case2 Troubleshooting About Too Many Times of Resource Allocation Failure Exist in

EVDO Network


Fault Type Congestion Problem Product CDMA-RNO


Some telecom carrier operation EVDO network recently generate too many times of “AT-Initiated Connection Failures (Call resources allocation failure)[Times]”. We calculated and analyze operation data for one month and found that it is not a direct relationship between the fluctuations of Call resources allocation failure times and call setup attempt times. For detailed, please refer to the following figures. After checked the other related key performance index, none of abnormal situation had been found.

Alarm Information

When checking alarm, we found that there is alarm of “Bandwidth Occupation Rate Alarm of Abis Physical Port” exists in so many sites and the following attachment can show to you for detail. And from the attachment, we will find that it is only happened in busy hours. In additional, the other abnormal alarms are not found recently.

Cause Analysis

1. Comparison with 24 hours during one day, take 20090207 for example, the comparison fi

gure can refer to the following:

And we can found from the above figure that it is most serious situation exists in evening bu

sy hours and the times of resource allocation failure is not directly caused by times of call s

etup

2．Run log file analysis

Take 20090209 run log file for example, there are so many C03 abnormal times exist which

occupy 53.18% in total release times. For detailed, we can find out the below table

Note：the cause of C03 is described as the below text.

RelCause: c03

Macro name:

SDU_NO_REV_IDLE_FRAME

Detail Explain:

Does a certain branch not receive the first reverse idle frame

Cause:

1) The FMR fails to receive the idle frames possibly because intermittent blinking occurs at t

he Abis interface or the BTS is not running properly. When establishing the service channel,

the FAR needs to receive the idle frame from the BTS, or it will fail

2) The service bandwidth between the BSC and the BTS is insufficient.

From the above description, we can find out that C03 may caused by two main reasons:1)A

bis or BTS is not running properly;2)Abis bandwidth is insufficient.


Optimization


3．Result：

By comparison the analysis of alarm, KPI and runlog file, we can make such conclusion that

the root reason is caused by “Abis bandwidth is insufficient”.

Handling Process

1． Comparison between the throughput and Abis bandwidth According to the documentation of 《instructor of cdma2000 Abis transmission configuration

（version 6）》: Table 7 proposal for DO BTS bandwidth configuration E1 Quantities Operation and Maintenance link bandwidth Signaling bandwidth Traffic Link bandwidth Throughput of data service 1 110k 110k 1.68M 1.68M × 0.77 = 1.29M 2 110k 110k 3.58M 3.58M × 0.77 = 2.76M 3 110k 110k 5.48M 5.48M × 0.77 = 4.22M 4 110k 110k 7.38M 7.38M × 0.77 = 5.68M There are only 4 E1 configured for sites with alarms, this is to say, the total Abis bandwidth can support 5.68Mbps but the real throughput of data service for each site have exceeded 5.68Mbps.so the related alarms exist and affect KPI. 2． Abis bandwidth expansion After Abis bandwidth expansion, the related alarms eliminated and the times of resource allocation failure go back to zero.

Suggestions and Summary

During the first stage of network construction, some carriers trend to reduce the cost of transmission so as to result in the Abis bandwidth is not met the requirement of increasingly subscribers. In this case, the we must consider expand E1 bandwidth. As for the documentation of 《 instructor of cdma2000 Abis transmission configuration（version 6）》,we can download from the support website.


Optimization


Title Case3 Mobile-assisted hard handoff (MAHHO) failures caused by the excessively small

candidate frequency search window


Fault Type Handover Problem Product CDMA-RNO


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 meet


Optimization


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

Handling Process

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 t

he 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 qualit

y is subjectively normal.

Suggestions

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.


Optimization


Title Case4 The number of C05 call drops rises after IP transmission is used on the A

interface


Fault Type Call Drop Problem Product CDMA RNO


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 number of C05 (a call drop indicator) rises.

Alarm Information

None

Cause Analysis

The number of C05 call drop 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 number of C05 call drop rises.

Handling Process

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


Optimization


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.

Suggestions

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.


Optimization


Title Case5 The call setup success rate and the handoff success rate sharply

decrease due to insufficient signaling link bandwidth


Fault Type Data Configuration Problem Product CDMA RNO


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

None

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.

Handling Process

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%


Optimization


or above.

Suggestions

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


Optimization


Title Case6 Call drop caused by Synchronizations problem


Fault Type Call Drop Product CDMA RNO


1. During a drive test for CDMA 450 network, we found that while moving from BTS A to BTS B FFER increases abnormally which leads to call drop. When we monitored neighb

or list during drive test we found that mobile cannot find PN of BTS B and mobile can fin

d PN of BTS B only after call drop Alarm Info. GPS clock abnormal alarm of A BTS

Cause Analysis

1. We have checked neighbor Lists for both BTSs , it was ok 2. Check alarm information on BSC . Queried BCKM board special status and found that A BTS is working in free-run status and A BTS don't work in GPS trace mode.

Handling Process

1. Solve synchronisation problem on A BTS. After solving synchronization problem handoff success ratio increased and call drops decreased. That's call drop problem disapeared.

Suggestions 1. None


Optimization


Title Case7 High FFER although we have good Ec/IO and RX


Fault Type Handover Problem Product CDMA-RNO


in our network and after drive test has been done by customer he send results to us ,we fo

und that in some area the Ec/Io and RX are very good but we found also high FFER (4.5 - 8

%) so we need to know the problem why its happned pls find attach files Alarm Information

None.

Cause Analysis

During DT we found that FFER was very high after we add second carrier with different freq

uency to some sites in network and activate MAHHO switch to ON in order to activate HHO

function between the two carriers with different frequency ,our network is CDMA 2000 1X ,

we use BSC 6680

Handling Process

we check the Neighbors and it was normal ,we check the Data Config of both carriers and it was oK , because customer disagree to disable the HHO function , we modify the threshold of TADDMAHHO to reduce the possibility of different frequency searching as below: MAHHO Stop Search Threshold(0,5db); current is -12 suggest change to : -20 MAHHO Start Search Threshold(0,5db); current is -16 suggest change to : -26

the FFER was reduced and problem solved


1. maybe the some sites' neighbor has a problem,or problem in Data Config or this problem caused by terminal different frequency searching procedure which can be reduced by either disable the different frequency search or modify the threshold of TADDMAHHO to reduce the possibility of different frequency searching


Optimization


Title Case8 Abnormal RSSI problem


Fault Type RSSI Problem Product CDMA-RNO


In CDMA 450 network , after cutover of some new BTSs there appeared problem of big diffe

rence between Main and Diversity RSSI . Also there appeared many complains from custo

mer that access to the network became worse Alarm Information

None.

Cause Analysis

Generally RSSI level of both main and diversity recievers should be in range from -90dBm to -110 dBm and difference between them shouldn't exceed 6dB. If RSSI level exceeds -90 dBm level generally it indicates existence of interference and if RSSI is less than -110 dBm the problem most probably lies on antenna and feeder part. Also if difference between Main and Diversity recievers RSSI is more than 6dB it indicates that there exists interference or antenna is faulty or faulty boards.

Handling Process

In order to define the reason of big difference of RSSIs we have implemented these tests:

1. Change jumpers from the top of BTS of problem sector to the normal sector. After chan

ging problem moved to the normal sector which means the problem is not in BTS part bu

t in antenna and feeder part or interference.

2. Roll back and change azimuth of problem sector to the direction of normal sector, noth

ing is changed . So there is no interference .

3. Roll back and change jumper connection at antenna side from problem sector to the no

rmal sector. Problem moved to the normal sector.

So the most probably antenna is faulty

Suggestions Change antenna. After changing the antenna of problem sector , the problem disapeared


Optimization


Title Case9 Voice Quality Complaints About Clicks

Update Date 2008- 11-07

Fault Type Voice Quality Problem Product CDMA RNO


In V project of country N, the customer

complains that the network being constructed and maintained by Huawei provides poor voic

e quality, and clicks are heard during conversation Alarm Information

None

Cause Analysis

1.Coverage problem: the network is put into commercial use at the same time when it is constructed,in some area where multiple pilots exist without a primary pilot, handoff are frequently performed during the call process, lead to the poor voice quality. 2.The different MS version result in different voice quality. 3.The parameter configuration is inconsequential.

Handling Process

Poor voice quality is a complex issue. Different people feel voice quality in different ways. A

ccording to a survey to many users of the network, the voice quality is acceptable.

1.The network is put into commercial use at the same time when it is constructed. Many pla

nned sites are not yet provisioned. Therefore, poor air interface quality may cause poor voic

e quality. In an area where multiple pilots exist without a primary pilot, handoff are frequently

performed during the call process. When the active set is added or deleted, plenty of inban

d signaling messages are sent. In addition, too many neighboring cells are configured and t

hus the neighboring cell list message is excessively long and seizes a big proportion of the

voice link bandwidth. Consequently, the voice quality deteriorates in the area. If inband sign

aling messages use the blank voice burst mode, intermittent voice is caused and thus the v

oice quality further deteriorates.

Analyze the CEO’s CDRs. Of the 224 calls from May 29 to June 2, 2008, 221 calls are norm

ally released and only three calls are abnormally released. Of the three calls abnormally rel

eased, the abnormal release cause of one call is C05 call drop and that of the other two call

s is access failure.

Analyze the calls whose call duration is greater than 20 seconds and whose soft handover i

nterval is shorter than six seconds. Ten calls have a soft handover interval shorter than six s

econds, accounting for 4.48% of the total calls. In these calls, soft handovers are frequently

performed and thus the voice quality is affected to some extent.

Optimize the carrier adjacency configuration of the entire network and delete the unnecessa

ry carrier adjacency. The customer, however, still complains about the voice quality. The pro

blem is not essentially solved.

2.Is the MS version incorrect? Perform a voice test in an equipment room 400 meters away

from the BTS (there is only one strong primary pilot area) using the CEO’s high-end MS pro

vided by vendor N and a Huawei low-end MS. The test results indicate that vendor N’s high-

end MS produces gentler voice than the Huawei low-end MS (harsh voice is heard at the ea

rphone of the Huawei MS). Dial calls between the two MSs. The voice quality is good when

one party speaks and the other party listens. When the speaker stops speaking and then re

sumes speaking or when others are speaking near the MS, however, the listener obviously


Optimization


hears clicks. The voice of the other people near the MS is intermittent and results in poor vo

ice quality. When a GSM MS is used during the test, the voice quality is good and the voice

of the other people near the MS can be clearly heard. Perform a loopback test on the FMR,

and then perform a dialing test. The speaker’s own voice is heard after a certain delay. It is

hard to determine whether the voice quality is improved or deteriorates.

3.Currently, the EVC is located at the N side. Experimentally change some parameters at th

e N side.

Three parameters at the N side are related to voice: TC parameter, EC parameter, and voic

e enhancement parameter. Run the following commands to query these parameters:

A) To query the TC parameter: LST TCPARA

B) To query the EC parameter: LST ECPARA

C) To query the voice enhancement parameter: LST VQEPARA

Change the three parameters one by one, and then perform a dialing test again. The voice

quality does not obviously change.

If others are speaking nearby the MS during the conversation, their voice is not clear but the

listener hears noise. Maybe the MS regards the others’ voice frames as comfort noise durin

g the decoding (because the voice is low). In this case, try disabling comfort noise by runnin

g the following command:

SET ECPARA:

Comfort noise generation mode = Noise [CNG mode] Comfort noise mode. Set this paramet

er to QUIET.

Perform a dialing test again. The voice of the other people near the MS can be clearly hear

d by the listener. No obvious clicks are heard. After the optimization, the CEO no longer co

mplains about poor voice quality

Suggestions

Voice quality is affected by many factors. Sometimes poor voice quality relates to both the a

ccess network system and the core network. Customer complaints, however, are always th

e RF. Therefore, you need to locate and clarify the problem, and narrow the problem range

step by step.

1.Analyze the BTS distribution to determine whether all BTSs in the network or only some B

TS sectors have poor voice quality. You need to analyze the geographical distribution of the

complaining subscribers.

2.If only some sectors have poor voice quality, check whether the poor voice quality is caus

ed by improper installation, transmission faults, or BTS equipment faults by analyzing traffic

statistics and alarms.

3.Check the air interface quality. Use the RFMT, CDR, or other tools to further locate the pr

oblem cause.

4.Try testing different MSs. Check whether the problem relates to the service options, versi

on, type, or manufacturer of the MS.

5.The EVC is located at the N side. Experimentally change some parameters at the N side t

o attain satisfactory results


Optimization


Title Case10 Call drops caused by the mismatch between the maximum transmit power of the

CDMA TCH and the pilot power


Fault Type CDMA RNP & RNO Product CDMA RNO


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: 1. Forward interference exists. 2. The BTS is faulty. 3. The MS is faulty. 4. The adjacency is not configured. 5. The network optimization parameters are incorrectly configured. In particular, the common channel power and the traffic channel power do not match.

Handling Process

1.Move the MS outward from the carrier sector. The Ec/Io does not change much. This indic

ates that the forward signal quality is good and no interference exists in the forward directio

n. Perform a frequency scanning test by using the YBT250. Forward interference does not e

xist.

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 i

nvolve adjacency configuration.

6.Check the configuration of forward fast power control of the BTS. The maximum code cha

nnel 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 maxim

um 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 powe

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

solved

Suggestions

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

wer.

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

t 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 p

ower control, the TCH coverage will be far smaller than the common channel coverage. In a


Optimization


reas 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


Optimization


Title Case11 LAC planning problem causing High RSSI


Fault Type Congestion Problem Product CDMA RNO


It was observed that the RSSI of some BTSs were abnormal. The maximum of the RSSI is higher than -70dBm. This makes it very difficult for subscribers to access network. Also all KPI of the network including CS Call Setup Success Ratio, Call Drop, Traffic and so on were also affected. The bad RSSI was not regular.

Alarm Info. None

Cause Analysis

Reasons for High RSSI could be any of the following: Antenna feedback installation or equipment hardware fault and so on. Configuration problem Interference from other sources

Handling Process

After several days of analysis, there was no hardware issues or configuration faults. It was also observed that the Sites with high RSSI were sites at LAC boundary. After analysis with NASTAR, it was observed that the registration request was high. First the Access channel was increased which reduced the problem temporarily. Finally the LAC was replan and the RSSI problem was resolved.

Suggestions LAC planning must be carefully done observing all the guidelines. LAC boundaries must not be in high population areas to avoid frequent registration.


Optimization


Title Case12 Faulty bandwidth sharing mechanism causing EVDO speed slow


Fault Type Data Configuration Problem Product CDMA-RNO


N country have finished cutover from MUSA BSC to PARC BSC,

it has been noticed that there has been a lot of data subscribers complaint data card speed

slow . Alarm Information

None.

Cause Analysis

1.Air link interference 2.Bandwidth not enough for internet gate 3.PCF to PDSN limited 4.BSC to PCF limited. 5.Congestion 6.Coverage is not continuous 7.Hardware problem

Handling Process

1.From KPI analysis, the performance is stable. But for data service speed is subjective. So it should judge few subscriber complaints or the entire network problem. From the customer feedback information, it is mostly likely whole network problem. 2.The only operation is cutover from MUSA to PARC, all the EVDO sites configuration and coverage keep the same as before, so it was not caused by coverage or parameter problem. 3.Find the worst sites to do drive test to make sure if the limited element belongs to the part from MS to FTP server , which can prove the link from wireless part to PDSN is no problem. From the drive test result reflects that this part is normal. 4.so we have enough reason to suspect the key problem is the internet output.The following tests conducted indicate that the speed problem is caused by the bandwidth Manager introduced by Cyberspace ISP over the weekend. Test A: From the wireless data card, the ping test to the FTP SERVER (192.168.15.179) showed 0% packet-loss. Also, 10MB Data was downloaded from the FTP SERVER with an average download speed of 434kbps (8*54.27KB) This proves that the internal equipments is OK.. Test B: From the wireless data card, the ping test to the GATEWAY (10.64.250.1) also showed 0% packet-loss. This also shows that the internal equipments is OK. Test C: (a). From CYBERSPACE GATEWAY (10.64.250.1), the download test from www.speedtest.com produced these results: Downlink: 28kbps Uplink: 128kbps Cyberspace public ip: 212.100.69.11 This shows that the download speed for this IP 212.100.69.11 is been affected by the Bandwidth Manager. (b) A similar test from the Office LAN with IP 212.100.69.40 which does not pass through the Bandwidth Manager showed better result:


Optimization


Downlink: 135kbps Uplink: 112kbps Cyberspace public ip: 212.100.69.40 These results show the effect of the bandwidth manager on the IP:212.100.69.11 that is allocated to N Data Subscribers. The different ping return times highlighted by Simon, were only due to the prevailing RF condition on the wireless link at that time. Recall there is no soft handoff for EV-DO.


1.Cyberspace should revert back to the original design, and fix the faulty bandwidth sharing mechanism. 2.Increase the bandwidth and monitor the number of subscriber closely.


Optimization


Title Case13 SPU Loading Causes 'Subsystem Severe Overloaded' BSC Alarm


Fault Type Congestion Problem Product CDMA-RNO


In Bangladesh, one of the pioneer WLL PSTN private operators National Phone. Maximum

subscriber of this operator is Data Service user. Recently this operator has experienced BS

C alarm Subsystem Severe Overloaded. BSC Version is BSC6600 V200R002C04B016SP0

4 Alarm Information

Alarm Name: Subsystem Server Overloaded

Cause Analysis

NULL

Handling Process

For this alarm we have collected BSC BAM data, m2000, runlog. Alarm Log also collected f

or analysis. From alarm log file we have found that this alarm randomly comes and mainly i

n busy hour.

As 1st step, we have analyzed m2000 data and see traffic statistics. We have matched the t

ime with alarm log file. We have seen that at those particular times, lots of PS attempts and

as well as huge traffic. Also we have observed that some of the frames SPU loading is near

about 70% where as some of the below 40%.

We have re-distributed the BTS among subracks as per balancing traffic loading. After imple

menting new subrack planning, SPU loading is now under optimized level. Alarm has not se

en after that change.

Suggestions To avoid excessive SPU loading need to optimize BTS distribution among subrack according to traffic wise. When SPU loading exceeds 60%, need to push customer for the expansion of subscriber.


Optimization


Title Case14 High call drop ratio due to synchronization problem of BTS


Fault Type Call Drop Problem Product CDMA RNO


During drive test for CDMA 2000 1X project we found that in handoff area of BTS1 and BT

S 2 call drop hanppens frequently. In the problem area we have done drive tests several tim

es and each time call drop happened . Before call drop the FFER increased and after call dr

op MS connected to the other BTS.BTS 2 is a new BTS Alarm Information

None

Cause Analysis

This call drop problem could be mainly caused by these reasons: 1.Missing neighbor in neighbor list 2.BTS clock synchronization 3.Bad coverage We have checked neighbor list for the BTSs and it was ok. After analysing drive test results found that when signal from neighbor BTS2 is added to the candidate lists FFER increases very much . So the problem is caused by the BTS 2. After checking the parameters of BTS2, it's been found that the synchronization of the BTS is faulty,that is number of locked GPS is 1.

Handling Process

During checking installation quality of BTS 2 , it's been found that antenna of GPS is installe

d near Macrowave equipment , and the direction of Macrovawe is set in the direction of GP

S reciever.

After changing installation place of antenna of GPS reciever, the problem disapeared

Suggestions Null


Optimization


Title Case15 Early paging causes low paging success ratio


Fault Type Paging Problem Product CDMA RNO


N country paging success ratio drops 20% than yesterday. And A1 failure reasons covers 40% percent

Alarm Information

None

Cause Analysis

many new sites not on air abis link too long transmission link not stable network congestion Check BSC alarm, no alarm information NSS configure LAC not correct. RF and BSS IP frame and regzone, zonetimer setting not correct. Check history operation log, QPCH open whole network and early paging open in the same time. Omstar analysis many 2704 reasons increase a lot.

Handling Process

1.from the failure reason changes ,A1 failure increase a lot. So check transmission alarm an

d BSC to MSC link status, no alarm found.

2.From the weekly analysis, the paging success ration drops suddenly from last night, so it

most because of related operation.

RF: QPCH open in two MSC, only one MSC Paging performance drops, so QPCH is not th

e main reason.

NSS: early paging open, it has some difference between normally paging,

MSC receives after BSC paging response, should send assignment request, but opens the

early paging parameter, MSC first arrive HLR to take the terminal roaming number, which wi

ll spend some time, causing BSC waiting for assignment of request news overtime, theref

ore BSC make record of 2704 reason values: waiting assignment overtime. After close MS

C early paging parameter, then the call setup success ratio restores normally

Suggestions None.

Date post:	14-Jul-2016
Category:	Documents
Upload:	bishry
View:	14 times
Download:	0 times

Troubleshooting Case Collections for CDMA Radio Network Optimization 2009

Documents