Troubleshooting Case Collections for GSM Radio Network Optimization For Reference Only

Troubleshooting Case Collections for GSM Radio Network Optimization

Security Level

Contents
Faulty TRX in external neighbor cell caused poor outgoing HOSR............................................ 1 Wrong BSCSPC (signaling point code) in MSC caused poor HOSR .......................................... 3 New site overshoot caused access failure .................................................................................... 5 Coverage problem due to cross feeder ......................................................................................... 6 Incorrect LAC configure cause call steup failures ....................................................................... 7 Coverage change after swap cause interference.......................................................................... 8 Call drop problem due to wrong MAIO setting.............................................................................. 9 Bad Call Quality due to Swap sites Interference and Transimission Quality .......................... 10 Unupdated Configuration tables Causes Traffic Statistics Problem After BTS Rehoming.... 12 Incorrect MSC data configuration caused low incoming BSC handover successful rate...... 13

2009-07-15

HUAWEI Confidential

Troubleshooting Case Collections for GSM Radio Network Optimization

Security Level

Title: Product Family: Fault Type: Keywords: Phenomenon Description:

Faulty TRX in external neighbor cell caused poor outgoing HOSR Wireless Performance & RNP & RNO Handover Problem faulty TRX, handover, From daily OSS KPI monitoring, sector-2 cell 20458 daily HOSR (82%) is continuously much lower compare to its sector-1 cell 20457 (96%) and sector-3 cell 20459 (97%). Cell 20457, 20458, 20459 are Huawei DCS1800 cells co-located with vendor S GSM900 cell 20451, 20452, 20453. The GSM antenna height is 70m and the DCS antenna height is 50m. The GSM antenna and the DCS antenna of the same sector have the same azimuth. Product: GSM RNP & RNO

Alarm Information: Cause Analysis:

Null

1. All the other KPIs of cell 20458 are normal. 2. HOSR in this project is defined as Successful Outgoing Internal & External Inter-Cell Handover over Handover Commands. 3. From Outgoing Internal Inter-Cell Handover Measurement, Outgoing Internal Handover of cell 20458 has no problem. 4. From Outgoing External Inter-Cell Handover Measurement, cell 20458 has high percentage of Failed Outgoing External Inter-Cell Handover (Reconnection to Old Channels) (Abnormal Release, Timer Expired). 5. From Outgoing Handover Measurement, almost all of the Failed Outgoing Handover from cell 20458 (Huawei DCS cell sector-2) are to the target cell 20452 (vendor S GSM cell sector-2, of the same site).

Handling Process:

1. Checking on Frequency, Neighbor, Parameter Configuration confirmed that they are reasonable. 2. Checking on Antenna, Feeder, DCS hardware at site confirmed that there is no problem on Huawei cell 20458. 3. Statistics from customer showed that target cell 20452 (Vendor S) has no TCH congestion. 4. Next, troubleshooting (drive test) at site by performing long call + short call towards and outwards Huawei cell 20458 repeatedly. 5. The following 3 cells are main source cell and target cell in handover: Huawei DCS cell 20458 with BCCH 693, vendor S GSM cell 20452 with BCCH 65, vendor S GSM cell 20141 with BCCH 52. 6. While driving & performing long call + short call outwards cell 20458, outgoing handovers

2009-07-15

HUAWEI Confidential

Troubleshooting Case Collections for GSM Radio Network Optimization occured and BCCH changed from 693 to 65 then to 52.

Security Level

7. There were few handovers failed (reconnection to old channels) while handover from cell 20458 (BCCH 693) to cell 20452 (BCCH 65), before successful handover. 8. While driving & performing long call + short call towards cell 20458, incoming handovers occured and BCCH changed from 52 to 65 then to 693. 9. There were few handovers failed (reconnection to old channels) while handover from cell 20141 (BCCH 52) to cell 20452 (BCCH 65), before successful handover. 10. Drive Test showed that when the target cell for handover is cell 20452, both Inter-BSC Handover and Intra-BSC Handover are having poor HOSR. 11. We informed the customer about the findings and asked if there was hardware problem with cell 20452 (vendor S). 12. After checking, customer confirmed that 1 TRX of cell 20452 (Vendor S) was faulty. Customer locked the faulty TRX before replacing it. 13. In the following days OSS KPI, cell 20458 HOSR has improved to 96% from 82%.

Suggestions and Summary:

In this case, drive test findings had given hint to solve this poor outgoing HOSR problem.

2009-07-15

HUAWEI Confidential

Troubleshooting Case Collections for GSM Radio Network Optimization

Security Level

Title: Product Family: Fault Type: Keywords: Phenomenon Description:

Wrong BSCSPC (signaling point code) in MSC caused poor HOSR Wireless Performance & RNP & RNO Handover Problem BSCSPC, invalid cell, handover, From daily OSS KPI monitoring, sector-2 cell 20288 daily HOSR (86%) is continuously lower compare to its sector-1 cell 20207 (97%) and sector-3 cell 20289 (92%). Cell 20287, 20288, 20289 are huawei DCS1800 cells. They are co-located with vendor S GSM900 cells 20281, 20282, 20283. The GSM antenna and the DCS antenna of the same sector have the same azimuth, but at different height. Product: GSM RNP & RNO

Alarm Information: Cause Analysis:

Null

1. Other KPIs of cell 20287, 20288, 20289 are normal. 2. HOSR in this project is defined as Successful Outgoing Internal & External Inter-Cell Handover over Handover Commands. 3. From Outgoing Internal Inter-Cell Handover Measurement, Outgoing Internal Handover of cell 20287, 20288, 20289 has no problem. 4. From Outgoing External Inter-Cell Handover Measurement, the counts in Outgoing External Handover Requests and in Outgoing External Handover Commands differ significantly for all 3 cells 20287, 20288, 20289. There is also huge count (more than 50% of handover requests) of Failed Outgoing External Inter-Cell Handovers (Handover Request Rejected) (Invalid Cell) for these 3 cells. 5. From Outgoing External Measurement, most of the Failed Inter-Cell Outgoing Handovers are to the target cells of 20281, 20282, 20283 (vendor S GSM cells of the same site).

Handling Process:

1. Checked the CGI of cells 20281, 20282, 20283, 20287, 20288, 20289. They are correct. 2. Coordinated with customer to get the cell data in MSC which contains Huawei cells and vendor S cells. 3. From engineering parameters, LAC 579 has 2 BSC: vendor S BSC1 and Huawei BSC2. 4. From MSC data, for LAC 579, vendor S cells have BSCSPC of 5526, Huawei cells have BSCSPC of 5470, but there are 3 vendor S cells (20281, 20282, 20283) having BSCSPC of 5517. 5. We checked with customer if the BSCSPC of 5517 for cells 20281, 20282, 20283 is correct. 6. Customer confirmed that BSCSPC of 5517 is wrong for those 3 cells and he changed the BSCSPC of those 3 cells to 5526. 7. In the following days OSS statistics, Failed Outgoing External Inter-Cell Handovers (Handover Request Rejected) (Invalid Cell) has dropped from thousands to zero. HOSR

2009-07-15

HUAWEI Confidential

Troubleshooting Case Collections for GSM Radio Network Optimization

Security Level

for 20287, 20288, 20289 improve to 99%, 99%, 98% from 97%, 86%, 92% respectively

2009-07-15

HUAWEI Confidential

Troubleshooting Case Collections for GSM Radio Network Optimization

Security Level

Title: Product Family: Fault Type: Keywords: Phenomenon Description:

New site overshoot caused access failure Wireless Performance & RNP & RNO Other WLL overshoot location-update in A country in a WLL project, costumer complaind about the loosing the serveice of their subscriber after new site put on air. in this kind of network, each site has independent LAC and the subscribers SIM cards will only register in one LAC also they will restricted in HLR. Product: GSM RNP & RNO

Alarm Information: Cause Analysis:

no alarm

We perform DT in the special areas which They had complains. We found that the new site has more powerful signal level than the old site. Also in the MSC we did the signal trace and found that when the subscriber turns on his mobile phone the location update fails. Because it camped on a wrong site so that receives stronger signal level. When the mobile phone turns on it scans the strongest BCCH signal level in its network. When found the suitable BCCH check the LAC in HLR and if it restricted to access the location update will fail.

Handling Process: Suggestions and Summary:

We decreased the power level of the new site and check the signal trace again. The problem was solved. In these special scenarios the planner should consider about the best servers in the special areas where they want to cover. It means each village should have one best server to avoid location update fail. It can be done by right planning and considering on antenna height and antenna down tilt.

2009-07-15

HUAWEI Confidential

Troubleshooting Case Collections for GSM Radio Network Optimization

Security Level

Title: Product Family: Fault Type: Keywords: Phenomenon Description: Alarm Information: Cause Analysis:

Coverage problem due to cross feeder Wireless Performance & RNP & RNO Coverage Problem Cross Feeder. Y Country, S operator the subscribers complain in site X sector B no signal coverage Product: GSM RNP & RNO

Null

1. Check all cell parameters like LAC, TRX attributes (power, priority, receive mode,etc) 2. Check the performance (KPI) for all sectors and compare the result with before swap.The traffic in sector A is small decrease after swap (10 Erl.), and sector B same as before swap (11 Erl). 3. Check the feeders hardware connection, found cross feeder between sector A diversity feeder and sector B main feeder. Why no any signal in sector B places? Because the main feeders in sector A & B cover same places and the main BCCH its config. in those TRX, So, due to no main BCCH in sector B, therefore no signals in these places.

Handling Process: Suggestions and Summary:

Change the feeders to the correct order

In the swap project, engineers should collect more information of the existing network (as feeder orders) and obtain more suggestions from the network planning and optimization department to assure the swap quality and mitigate risks.

2009-07-15

HUAWEI Confidential

Troubleshooting Case Collections for GSM Radio Network Optimization

Security Level

Title: Product Family: Fault Type: Keywords: Phenomenon Description: Alarm Information: Cause Analysis:

Incorrect LAC configure cause call steup failures Wireless Performance & RNP & RNO Data Configuration Problem Wrong LAC configuration In Y country for S swap project launched a new site S2\2\2, but subscribers complain cant make call even near the sites. No alarms Product: GSM RNP & RNO

1- Check the traffic in the site, the sites have less traffic; 2- Monitor channel status by LMT for the sites, especially In sector C , the SDCCH channel is busy ,even no traffic In this sector 3- And also in sector A&B the same problem, why no traffic but high SDCCH occupy? 4- Check the cells parameter , found LAC of cell C is wrong 5-Because wrong LAC, they have 2 different LAC in same site and the mobile frequent location update which cause SDCCH high occupy. So the call setup high failures

Handling Process: Suggestions and Summary:

1- Change the wrong LAC of sector C. 2- Monitor the traffic and the performance is ok. LAC planning must be carefully done observing all the guidelines. LAC boundaries must not be in high population areas to avoid frequent registration

2009-07-15

HUAWEI Confidential

Troubleshooting Case Collections for GSM Radio Network Optimization

Security Level

Title: Product Family: Fault Type: Keywords: Phenomenon Description:

Coverage change after swap cause interference. Wireless Performance & RNP & RNO Call Drop Problem Interference problem In Y country for S swap project, After Swap for Marashi site, sectorA (4 TRX: 3 for PGSM/1 for EGSM, the hopping just in 3 PGSM) has problem in 1- High call drop rate reach 12% 2- Handover success rate less than 88% 3- Call setup rate less than 80% And this sector enables base band frequency hopping Product: GSM RNP & RNO

Alarm Information: Cause Analysis:

No alarms

1 - Check the all cell parameters (cell ID, LAC, TRX attributes), all parameters is OK 2 - Check the Neighbors for this cell, after check, there is no problems with the neighbors (Missing neighbors cause the H.O failure and call drop) 3- Disable the base band frequency hopping of the cell, after that check the performance all the 3 carriers The same problem as before. 4- Check the interference band in real time by LMT and statistics information from M2000, found high Interference in TRX 3, so using GENEX NASTAR to check, and the cell has Co-channel with Another cell.

Handling Process:

1- Change the frequency of TRX no3 2- Change the SDCCH channel to second TRX 3- After check the KPI for this cell, handover and call setup and call drop is normal Why the interference happen after swap, the frequency is the same before and after swap? Because the coverage after swap is Larger than before swap The interference just in TRX3, but why the effect in call setup of the cell (call setup less than 80%)? TRX3 has SDCCH, SDCCH channel responsible for call setup and handover

Suggestions and Summary:

1-Frequencies planning must be carefully done observing all the guidelines. Take into account the Huawei BTS has large coverage area 2- Choose proper graphics display tool such as U-Net, MapInfo, and Nastar Take into account the terrain and clutter information, such as mountains and rivers

2009-07-15

HUAWEI Confidential

Troubleshooting Case Collections for GSM Radio Network Optimization Title: Product Family: Fault Type: Keywords: Phenomenon Description: Call drop problem due to wrong MAIO setting Wireless Performance & RNP & RNO Call Drop Problem Call drop due to wrong Hopping parameter Product: GSM RNP & RNO

Security Level

In country "B", "T" GSM operator complained that they are facing some cell high TCH call drop problem from a certain date. The complained sites are BTS 3012 and in BSC-6000 (BSC6000V900R008C01B051).

Alarm Information: Cause Analysis:

After getting this complain, we checked all BTS alarm and found no alarm

According to customer description they are facing high call drop problem in some cells in one BSC from a certain date or time period. As call drop rate increased from a certain date so there might be some operations happened so that this call drop increased. 1. Call drop increase if TRX faulty or Hardware faulty. 2. If uplink downlink unbalanced then call drop rate might be increase. 3. Due to interference call drop might be increase. 4. Wrong frequency plan one of the cause of call drop. 5. Due to wrong hopping parameter call drop might be increase.

Handling Process:

1. We checked TRX hardware alarm and found no problem. 2. Uplink downlink was balanced. 3. Cell interference increased little bit but not so severe in band 4 or 5 level. 4. We checked frequency plan and found ok. 5. We checked hopping parameter (MA, MAIO, HSN) and found wrong MAIO setting in affected cell (Same MAIO in two cell in same site (same HSN)). Before affected date this cell configuration was S5/5/5 and they increased TRX in this cell (present configuration S5/5/6). During this operation they configured wrong MAIO in one cell and after that call drop increased. After fixing correct MAIO in affected cell Call drop decreased. (Please see the attached document for more detail)

Suggestions and Summary:

During any operation need to take more precaution regarding any kind of data configuration.

2009-07-15

HUAWEI Confidential

Troubleshooting Case Collections for GSM Radio Network Optimization

Security Level

Title: Product Family: Fault Type: Keywords: Phenomenon Description:

Bad Call Quality due to Swap sites Interference and Transimission Quality Wireless Performance & RNP & RNO Other Bad Call Quality Swap Site Interference Transmission Quality of Optical Fiber In B country T operator, we got the feedback from the customer engineers that subscribers complained that the call quality was bad in the coverage aera of most Huawei sites south of its second largeat city B1, sometimes when they were near the site, they heard noise when they made the call and it seems they were in the area far from the site, and sometimes they had to try several times before they can made call. But in the coverage area of Alcatel sites in that area,there was no such problem. So the customer even doubted that whether Huawei BTS had any problem or not.In that area there are some Alcatel sites distributed among Huawei sites which are planned to be swapped by Huawei but not yet due to the customer's plan. Product: GSM RNP & RNO

Alarm Information:

1) LAPD OML Fault 2) E1/T1 Excessive Peer End Alarms Per Hour 3) Remote E1/T1 Alarm (RAI) 4) E1 Local Alarm 5) Cell Out of Service

Cause Analysis:

Cause analysis for this problem: 1) Transmission Microwave is the most important transmission equipment here, but it's not stable, and has brought us a lot of such problem.So the transmission is the most possible cause for this problem; 2) Hardware malfunction If the hardware of the BTS such as DDPUDTRU or DTMU has problem,it would probably cause those phenomenon described above.But hardware malfunction at the same time for 7 sites, equipments from two batches, while the equipments of other areas are all normal,seems impossbile; 3) Cell parameters configuration mistake Data in BSS and NSS need to be checked to ensure cell parameters,such as Rxlev_Access_Min,RACH Min Access Level,etc.,are correct; 4) Interference Frequency interference from improper frequency planning or equipments of another provider could also lead to such problems.

Handling Process:

1) First we checked the KPI and the alarms for sites in this area,and found that the congestion on SDCCH for some cells was high sometimes,and there were many LAPD alarms and cell out of service alarms. 2) Then we checked the configuration in BSS and NSS, and we found that our data was

2009-07-15

HUAWEI Confidential

10

Troubleshooting Case Collections for GSM Radio Network Optimization

Security Level

correct as we planned. And we analyzed the latest BCCH and BSIC data and the drive test data before swap for those swap sites in that area,and found that the BCCH for two cells of Alcatel two sites had been optimized and their new BCCH brought serious interference to Huawei new sites nearby. So we modified the frequency planning for our sites in that area to avoid the interference and informed customer engineers to check it again. Their feedback after contacting the guards and local people there was that for the two sites voice became much better while calling but they still had the call quality problem sometimes. 3) Meanwhile,our engineer went to that area to check the problems on sites.Before they arrived there, the customer engineers checked the Microwave there again and informed us that transmission was good.When our engineers got to that area,we had modified the frequency planning,however,they found the problem described by customer engineers again.But not only for Huawei Sites, Alcatel sites in this area had the same problem. So we doubted that may be that's the transmission problem.When they made a loop at one site and we tested the BER on LMT, the BER was high.So we told customer engineers to check the Microwave in this area again. When they checked the Microwave from city B2 to two Huawei sites, they found that the Microwave was ok. Then we told them to check the optical fiber from city B1 where the BSC locates to city B2, and the fiber was found not stable between B1 and B2, so the problem was located. And the customer engineers admitted the fact that Alcatel sites in that area had the same problem during the test. After three weeks, the optical fiber problem was solved and we go to that area to test again and find that the call quality is ok now. Suggestions and Summary: 1) Do pay attention to the optimization plan of our customer's other provider, if we have sites near the sites they plan to optimize. 2) While checking the transmission problem, do remember to check from Abis interface of BSC to BTS.

2009-07-15

HUAWEI Confidential

11

Troubleshooting Case Collections for GSM Radio Network Optimization

Security Level

Title:

Unupdated Configuration tables Causes Traffic Statistics Problem After BTS Rehoming

Product Family: Fault Type: Keywords: Phenomenon Description:

Wireless Performance & RNP & RNO Handover Problem traffic statistics, BTS rehoming

Product:

GSM RNP & RNO

J office GSM network is totally 1800M network, no 900M network. For normal case, in BSC level traffic statistics, attempted incoming BSC handovers is equal to attempted incoming BSC handovers (to 1800/1900). But one day customer found that attempted incoming BSC handovers is greater or less than attempted incoming BSC handovers (to 1800/1900) for one BSC.

Alarm Information: Cause Analysis:

none

Customer said that they added a new BM module in this BSC and move some sites from other modules of this BSC to this new BM. We checked the BSC level traffic statistics and found there was a big difference between Attempted incoming BSC handovers and Incoming BSC handovers, but there are no TCH congestion and no data configuration problem. And somtimes Attempted incoming BSC handovers (to 1800/1900) is greater than Attempted incoming BSC handovers. This is unreasonable. We checked the cell leve statistics. It is normal and no cells missed in the statistics task. And there is no big difference between Attempted incoming BSC handovers and Incoming BSC handovers for all of the cells. From above analysis, we doubt that custom didn't refresh all the tables related to the handover process for this BSC after sites movement.

Handling Process: Suggestions and Summary:

We refreshed all the tables related to the handover process for this BSC through dynamic configuration and the problem was resolved. ok

2009-07-15

HUAWEI Confidential

12

Troubleshooting Case Collections for GSM Radio Network Optimization

Security Level

Title:

Incorrect MSC data configuration caused low incoming BSC handover successful rate

Product Family: Fault Type: Keywords: Phenomenon Description:

Wireless Performance & RNP & RNO Data Configuration Problem

Product:

GSM RNP & RNO

Low incoming BSC handover successful rate The network is composed of one MSC(type MSC) and 3 BSC (BSC20, BSC21, BSC22). All of these equipments are in one building. After checking statistic data of BSC22, low incoming BSC handover successful rate was found, with the average value of 40-60%. Another type of HO is normal (>=92%).

Alarm Information: Cause Analysis:

No alarms.

1. Check statistic data (BSC and cell levels) 2. Check BSC data configuration 3. Check Um interface 4. Check Abis interface 5. Check A interface 6. Check MSC data configuration

Handling Process:

1. After checking statistic data of BSC22, low incoming BSC handover successful rate was found , with the average value of 40-60%. Another type of HO is normal (>=92%). Call drop, quality and congestion rate is normal. The statistic data of other BSC (BSC 20&21) is normal. 2. BSC configuration data is normal. 3. Um interface is normal. Inter (intra) BSC HO is normal, but only incoming BSC HO is faulty sometimes. 4. Abis interface is normal. 5. A interface, found one no correct E1 (have in MSC data configuration, but not physical connect). Trace in this interface, we found some request to this E1, but all request is not successful. After pysical connect this E1, problem disappear.

Suggestions and Summary:

Main problem of this case is incorrect MSC data configuration and phisical connection lose. After correcting data and phisically connecting E1, problem disappeared, and the incoming BSC handover successful rate is >92%. In this case have two way to disappear this problem.

1. Delete, not physical connected E1 in A interface, MSC part. 2. Physical connect, configured E1 in system

2009-07-15

HUAWEI Confidential

13