Troubleshooting in GSM

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

i


Security Level

Title:

Faulty TRX in external neighbor cell caused poor outgoing HOSR

Product Family:

Wireless Performance & RNP & RNO

Fault Type:

Handover Problem

Keywords:

faulty TRX, handover,

Phenomenon

From daily OSS KPI monitoring, sector-2 cell 20458 daily HOSR (82%) is continuously

Description:

much lower compare to its sector-1 cell 20457 (96%) and sector-3 cell 20459 (97%).

Product:

GSM RNP & RNO

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

Null

Information: Cause

1. All the other KPIs of cell 20458 are normal.

Analysis:

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

1


Security Level

occured and BCCH changed from 693 to 65 then to 52. 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

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

and Summary:

2009-07-15

HUAWEI Confidential

2


Security Level

Title:

Wrong BSCSPC (signaling point code) in MSC caused poor HOSR

Product Family:


Fault Type:

Handover Problem

Keywords:

BSCSPC, invalid cell, handover,

Phenomenon

From daily OSS KPI monitoring, sector-2 cell 20288 daily HOSR (86%) is continuously

Description:

lower compare to its sector-1 cell 20207 (97%) and sector-3 cell 20289 (92%).

Product:

GSM RNP & RNO

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

Null

Information: Cause

1. Other KPIs of cell 20287, 20288, 20289 are normal.

Analysis:

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

3


Security Level

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

2009-07-15

HUAWEI Confidential

4


Security Level

Title:

New site overshoot caused access failure

Product Family:


Fault Type:

Other

Keywords:

WLL overshoot location-update

Phenomenon

in A country in a WLL project, costumer complaind about the loosing the serveice of their

Description:

subscriber after new site put on air. in this kind of network, each site has independent LAC

Product:

GSM RNP & RNO

and the subscribers SIM cards will only register in one LAC also they will restricted in HLR. Alarm

no alarm

Information: Cause

We perform DT in the special areas which They had complains. We found that the new site

Analysis:

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

5


Security Level

Title:

Coverage problem due to cross feeder

Product Family:


Fault Type:

Coverage Problem

Keywords:

Cross Feeder.

Phenomenon

Y Country, S operator the subscribers complain in site X sector B no signal coverage

Product:

GSM RNP & RNO

Description: Alarm

Null

Information: Cause

1. Check all cell parameters like LAC, TRX attributes (power, priority, receive mode,…etc)

Analysis:

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 feeder’s 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

Change the feeders to the correct order

Process: Suggestions and Summary:

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

6


Security Level

Title:

Incorrect LAC configure cause call steup failures

Product Family:


Fault Type:

Data Configuration Problem

Keywords:

Wrong LAC configuration

Phenomenon

In Y country for S swap project launched a new site S2\2\2, but subscribers complain can’t

Description:

make call even near the sites.

Alarm

Product:

GSM RNP & RNO

No alarms

Information: Cause

1- Check the traffic in the site, the sites have less traffic;

Analysis:

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

7


Security Level

Title:

Coverage change after swap cause interference.

Product Family:


Fault Type:

Call Drop Problem

Keywords:

Interference problem

Phenomenon

In Y country for S swap project, After Swap for Marashi site, sectorA (4 TRX: 3 for PGSM/1

Description:

for EGSM, the hopping just in 3 PGSM) has problem in

Product:

GSM RNP & RNO

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 Alarm

No alarms

Information: Cause

1 - Check the all cell parameters (cell ID, LAC, TRX attributes), all parameters is OK

Analysis:

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 statistic’s 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

1-Frequencies planning must be carefully done observing all the

and Summary:

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

8


Security Level

Title:

Call drop problem due to wrong MAIO setting

Product Family:


Fault Type:

Call Drop Problem

Keywords:

Call drop due to wrong Hopping parameter

Phenomenon

In country "B", "T" GSM operator complained that they are facing some cell high TCH call

Description:

drop problem from a certain date. The complained sites are BTS 3012 and in BSC-6000

Product:

GSM RNP & RNO

(BSC6000V900R008C01B051). Alarm

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

Information: Cause

According to customer description they are facing high call drop problem in some cells in

Analysis:

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

9


Security Level

Title:

Bad Call Quality due to Swap sites Interference and Transimission Quality

Product Family:


Fault Type:

Other

Keywords:

Bad Call Quality Swap Site Interference Transmission Quality of Optical Fiber

Phenomenon

In B country T operator, we got the feedback from the customer engineers that subscribers

Description:

complained that the call quality was bad in the coverage aera of most Huawei sites south

Product:

GSM RNP & RNO

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

1) LAPD OML Fault

Information:

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

Cause analysis for this problem:

Analysis:

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 DDPU、DTRU 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


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


Title:

Security Level

Unupdated Configuration tables Causes Traffic Statistics Problem After BTS Rehoming

Product Family:


Product:

Fault Type:

Handover Problem

Keywords:

traffic statistics, BTS rehoming

Phenomenon

J office GSM network is totally 1800M network, no 900M network. For normal case, in BSC

Description:

level traffic statistics, attempted incoming BSC handovers is equal to attempted incoming

GSM RNP & RNO

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

none

Information: Cause

Customer said that they added a new BM module in this BSC and move some sites from

Analysis:

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

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

and Summary:

2009-07-15

HUAWEI Confidential

12


Title:

Security Level

Incorrect MSC data configuration caused low incoming BSC handover successful rate

Product Family:


Product:

Fault Type:

Data Configuration Problem

Keywords:

Low incoming BSC handover successful rate

Phenomenon

The network is composed of one MSC(type MSC) and 3 BSC (BSC20, BSC21, BSC22). All

Description:

of these equipments are in one building.

GSM RNP & RNO

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

No alarms.

Information: Cause

1. Check statistic data (BSC and cell levels)

Analysis:

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

Main problem of this case is incorrect MSC data configuration and phisical connection lose.

and Summary:

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

Troubleshooting in GSM

Recommend Documents