GSM Product Training Technical Cases

GSM Product Training Technical Cases


2013

HUAWEI Confidential


Table of Contents BSC6900 Troubleshooting Cases ............................................................................................... 1 Case1. Cannot login weblmt in some office due to different IP proxy settings ......................... 1 Case2.

A interface main and standby boards frequently switch in one BSC caused by

other BSC in BM-TC separated when done A over IP ............................................................. 3 Case3.

Can register network but can't call due to GTC type set error ................................... 4

Case4.

Problem adding SPU boards in GU mode ................................................................ 5

Case5.

SPUb board unavailable in new subrack .................................................................. 7

Case6.

Problem in integrating TC subrack with BM .............................................................. 8

Case7.

OMU IP Address Configuration Error due to BSC6900 upgrading from V9R13 to

V9R15 ..................................................................................................................................10 Case8.

Direct tunneling between MBSC and GGSN is not working .....................................12

Case9.

Can't active cell due to Configuration & License inconsistent...................................14

Case10.

Low downlink TBF establishment successful rate due to paging congestion ..........16

Case11.

Rebalance XPU CPU Load ...................................................................................18

GBTS Troubleshooting Cases ...................................................................................................22 Case1. Tracing GSM Interference Problem ...........................................................................22 Case2. PDCH faulty & TCH Carrying no traffic in BTS ...........................................................26 Case3.

Low TCH availability when site shifted to batteries ..................................................28

Low TCH availability when site shifted to batteries.................................................................28 Case4.

GSM extended Cell with 2 trx's congestion .............................................................30

GSM extended Cell with 2 trx's congestion ............................................................................30 Case5.

The wrong IPPATH type to make PDTCH Fault ......................................................32

Case6.

Difference between the least frequency & the highest frequency is more than 15

MHz (75 ARFCNs) so these TRXs cannot be activated .........................................................34 Case7.

Low CSSR..............................................................................................................35

Case8.

BTS 3900 Antenna mode of S444 type configure is wrong result in VSWR alarm

.............................................................................................................................................36 Case9.

Tilt & Azimuth error cause TCH assignment successfully rate is low and

Handover failure ...................................................................................................................38 Case10.

GSM Cell Transmission Delay Abnormal in Abis over IP .......................................39

Case11.

2G to 3G cell reselection unsuccessful..................................................................41

Case12.

Technical Case Regarding HUAWEI GSM BTS ....................................................42

Case12.

GSM Cell UL Quality abnormal .............................................................................43

Case14. GSM Neighbouring Cell Analysis Data Does Not Show Some Measurement Report For Some Cell ...........................................................................................................45

HUAWEI Confidential

i


BSC6900 Troubleshooting Cases Case1. Cannot login weblmt in some office due to different IP proxy settings Title

Cannot login weblmt in some office due to different IP proxy settings

Keywords

webLMT, login, proxy

Case code

BSC6900-001

Case type

O&M tools

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BSC6910

1. Phenomenon Description We have new BSC6910 deployed. In Office A of Customer we can login weblmt in IE or Modzilla. But in Office B our customer cannot login weblmt.

2. Alarm Information Null.

3. Cause Analysis 1. Ping to external virtual IP of BSC6910 10.251.169.153 both in office A and office B is OK. But we still cannot login in Office B; 2. Try other laptop and computer, update java also same; 3. According to below snapshot this could be a cache error in IE;

HUAWEI Confidential

1


4. Clear Cache problem persist; 5. Use HTTP watcher and save the snapshot during login process. It is found that IE can only get 3333 bytes data from the RNC LMT Server. The http response is not complete, only get 3333 bytes data, that’s why the error happened.

6. Also from the Http response header, a proxy server is working between PC and the RNC LMT server in office B; HTTP/1.0 200 OK Date: Thu, 30 May 2013 08:33:47 GMT Server: Huawei VPP EWS Last-Modified: Fri, 03 May 2013 08:43:15 GMT Content-Type: application/x-javascript Cache-Control: max-age=2592000, public, no-check=2592000 Content-Length: 8036 Content-Encoding: gzip Age: 0 X-Cache: MISS from proxy2.local X-Cache-Lookup: MISS from proxy2.local:3128 Via: 1.0 proxy2.local (squid/3.1.15) Connection: close 7. In office A, it is found that we are using IP proxy set 10.1.89.231 in IE, meanwhile we are using IP proxy 10.2.154.202 in Office B. The login failed when we are using IP proxy 10.2.154.202 and it reject the HTTP request to RNC server, but when we use 10.1.89.231 we can login again in Office B. Customer decide to use IP 10.1.89.231 at all office.

4. Handling Process 1. Test ping at both office, if in specific office which has the problem, then there is no issue in RNC server; 2. Check using other laptop; 3. Try to clear cache in browser; 4. Check whether Java already updated; 5. Use HTTP watcher tools, this tool help to analyze the packet exchange during login process; 6. Check whether customer using different proxy ip setting in different office.

HUAWEI Confidential

2


5. Suggestions and Summary Login access problem in some office is not critical problem, what we have to make sure is that connection to external link in that office is still there. If ping is OK and in other office we still can login, then there is no problem in network or RNC server. We must check other setting related with client, in this case different proxy setting in customer Office B was the root cause.

Case2. A interface main and standby boards frequently switch in one BSC caused by other BSC in BM-TC separated when done A over IP Title

A interface main and standby boards frequently switch in one BSC caused by other BSC in BM-TC separated when done A over IP

Keywords

AoIP BM/TC separated frequently switch

Case code

BSC6900-002

Case type

Configuration&Commissionin g

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BSC6900

1. Phenomenon Description One BSC in BM/TC separated mode in one office, after A interface from TMD to IP mode, service mode also has been changed to be BM/TC combined. The TC subrack together with its data has been deleted. After modification, BSC2 works normally but a pair of main and standby GOUc boards in BSC8 frequently switch. Following illustration is before A interface modification.

2. Alarm Information MTP3 signal link fault alarms about A interface.

HUAWEI Confidential

3


3. Cause Analysis The BSC which BM/TC combined, after deleted A interface data, the related boards remained. That means the physical optical channel was still through. So on MGW side, the GOUc boards can detect the signal from the other side. But the BSC which BM/TC separated, after GOUc boards removed, physical channel was through, but the MGW side can’t receive the stable optical signal. But the MS2L boards open the protected group lead to main and standby MS2L boards frequently switch and the main and standby GOUc boards which on the other side frequently switch.

4. Handling Process 1. Plug out the fiber connected to GOUc boards which not configured on BSC side. 2. Delete the optical interface protected group which connected to GOUc boards on MGW side.

5. Suggestions and Summary 1. Check the board logical function on BSC device panel before A over IP (BSC in BM/TC separated mode) , plug out the fiber which not actually used. 2. Delete related optical interface protected group in MGW side.

Case3. Can register network but can't call due to GTC type set error Title

Can register network but can't call due to GTC type set error

Keywords

GTC, ITC, DPUc

Case code

BSC6900-003

Case type

Configuration &Commissioning

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BSC6900

1. Phenomenon Description One test bed office in country Y, using MBSC6900V900R013 (GU), the property of Subrack0 is UO and Subrack1 is GO. After debugging by local engineer, the mobile phone can register network but can’t call setup. It shows “network busy” after dialing numbers few seconds. We found that after MSC send assignment command, BSC replied assignment failure HUAWEI Confidential

4


message and cause value shows: equipment failure.

2. Alarm Information None.

3. Cause Analysis 1. There are two DPUd for inner PCU for data process and two DPUc for inner TC; 2. A interface is in IP mode and Abis interface is in TDM mode; 3. Can register network but can’t call setup. So we focus on user panel rather than signaling panel; 4. We entered the “Device Maintenance” by WebLMT and selected “Display Logic Function”. We found as follows: DPUd boards work in GPCU mode in slot8 and slot9. DPUc boards work in GTC mode in slot10 and slot11.

4. Handling Process DPUc board works in three mode: GTC: TC resources that support normal voice coding/decoding and packet conversion.The TC resource support packet conversion In BM/TC separated mode, when abis interface transmission mode is abis over IP or HDLC.It's different from ITC. UTC: TC resources that support only the optimized handover on the Iur-g interface. ITC: TC resources that support only packet conversion.It is only used in A over IP. After changing it to ITC for DPUc in slot10, we solved this issue.

5. Suggestions and Summary DPUc works in these three modes but all shows GTC in logical type. We suggest developing one function to identify them.

Case4. Problem adding SPU boards in GU mode Title

Problem adding SPU boards in GU mode

Keywords

Subrack, GU, UO, GO MOD

Case code

BSC6900-004

Case type

Case is from

Huawei Support site

Update Time

Product Family

GSM BSS

Product

Configuration&Commissioning

BSC6900

1. Phenomenon Description The BSC unable to add SPU boards at slot 4 HUAWEI Confidential

5


BSC Version: V900R013C00


3. Cause Analysis Actually we were told to configure MBSC in GU mode but the boards were delivered as 2 subracks for RNC and 1 subrack for BSC. By default TNU boards were apearing on the slot 4 whereas we need to add SPU board on the same slot for RNC services Following steps were followed on site: 1. Reset the subrack 2. Checked the subrack mode 3. Tried to remove TNU boards

4. Handling Process When we followed the commissioning procedure one by one then we found that at one step we need to define MBSC mode which we selected as GU. This is correct as MBSC which shares the same OMU need to be defined the same way, but when we define it as GU mode then MBSC by default takes subrack-0 as GU mode which means it configures TNU board automatically for 2G services. So for MBSC's in which co-transmission is not being used we have to configure each subrack as per its desired mode, i.e if the subrack is for GSM we need to select GO mode and if the subrack is for WCDMA services we need to select UO mode. So we followed following steps: 1. while commissioning we put the mode as GU because we need to share same alarm and trace mangement platform 2. After commissioning we need to change the mode of each subrack from LMT as per desired design, even for subrack-0 also by MOD SUBRACK command. 3. when we changed the subrack-0 mode to UO then whole MBSC mode was GU but of subrack -0 was UO means now we can add SPU boards on slot-4

5. Suggestions and Summary Whenever we are using MBSC in UO mode as a whole then we always need to change

HUAWEI Confidential

6


the mode of subrack-0 as well as. Per desired design means as UO or GO , but by default it will be GU.

Case5. SPUb board unavailable in new subrack Title

SPUb board unavailable in new subrack

Keywords

SPU, SPUb, MPU board unavailable, backplane

Case code

BSC6900-005

Case type

Engineering&Installation

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BSC6900

1. Phenomenon Description Customer in country F added new UMTS subrack in MBSC. The SPUb in subrack 4 slot 0 (MPU) reports “Board Unavailable” after the new subrack was powered on. Rests of the boards are in status Normal.

2. Alarm Information Board Unavailable

3. Cause Analysis When only one board fails, possible causes are as follow: Board failure OMU failure (does not respond to BOOTP messages) Configuration issues Backplane slot faulty

4. Handling Process 1. Checking First the onsite engineer swapped board in slot 0 with the standby SPUb in slot 2 and restarted the subrack (no NodeB’s defined in the new subrack yet); after restart, SPUb slot 2 started up normally and slot 0 still unavailable. This was an abnormal behavior, so we performed the test again, with another SPU card but with the same result. A board issue was excluded so the subrack backplane could cause the problem.

2. Troubleshooting No MML command can be performed on the SPUb in slot 0; If we inhibit the card, the uninhibit command will timeout and the board will remain in blocked mode. HUAWEI Confidential

7


After checking the OMU log – Software module – we can check if there were any BOOTP requested from subrack 4 slot 0 (the first step of starting the board is to send a BOOTP request to OMU and download software). All boars from subrack 4 are sending BOOTP request but no request from slot 0; First the SCU starts in slot 6 then SPU slot 1, after that the rest of the boards from subrack 4. If we check the backplane ports on subrack 4 (DSP BACKPLANEPORT) we can see both ports are down (Link state = DOWN, Administrative state = Enable). We sent field service on site to remove the SPUb from slot 0 and 2, and make photos of the backplane; we saw that in slot 0, one pin is binded. We collected all the logs and together with photos we requested HQ expert to confirm for what the pin is used and is we should attempts to fix it. Hardware R&D confirmed the pin is used as 2ms connector. If the pin is faulty, the board will fail to get the number info about subrack and slot. Then the BOOTP process will fail.

5. Suggestions and Summary The broken pin in the backplane causes board unavailable. The solution is to replace the subrack.

Case6. Problem in integrating TC subrack with BM Title

Problem in integrating TC subrack with BM

Keywords Case code

BSC6900-006

Case type

Engineering&Installation

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BSC6900

1. Phenomenon Description While intergrating 2nd TC subrack with BM, software was not getting uploaded and cards were not getting activated. MBSC version: V900R013C00SPH558 VER.


HUAWEI Confidential

8


3. Cause Analysis We checked following information to handle this problem. 1. Whether TC subracks are in Effective mode. 2. Whether TC subracks are power on. 3. Whether physical connection between TC subracks and BM is proper. 4. Whether clock cables and TNU cables are properly conected. 5. Whether mapping between SCU board of TC subrack and that of BM subrack is Okay. these were the basic steps and we started analysing all these things becuase all the cards and whole subrack cannot be faulty.

4. Handling Process We started handling the problem as per our analysis, so we took following steps : 1. We checked TC subrack mode and found that it was in active mode. 2. We checked and found TC subracks were power on. 3. We checked physical connections between BM and TC subracks and found them that they were mapped properly. 4. Other cables like clock cable and TNU cable were also properly connected. 5. We run the command DSP PANELPORT to check the mapping of subracks and found the following result.

In the above picture we can see the mapping between 3rd subrack (i.e. TC subrack) is with the 2nd subrack (i.e BM subrack) and the 0 subrack (i.e BM subrack), while 2nd subrack is showing mapping with only 0 subrack and which is correct, Noramally the mapping of all other BM subrack should only be with 0 BM subrack and 1st TC subrack should be mapped with 0 BM subrack and then all other TC subracks should be connected to the main and first TC subrack. With this analysis we concluded one point that there is definetly some problem in commissioning related activity as phisical connection were proper. Then we started cheking the same for other BSC's and was correct in that and we found that, in all other BSC's the mapping of 3rd subrack (i.e 1st TC subrack) is with 0 BM HUAWEI Confidential

9


subrack and other TC subrack means subrack 4 and subrack 5, as shown in the figure below :

So we came to know that somehow 2nd TC subrack is not configured as subrack 4 instead it is configured as subrack 2. Then we checked and found software configuration was okay, so we cheked the DIP switch settings and found that they were like subrack 2 of BM subrack. We then power off the subrack and made the DIP switch settings as subrack-4 and again powered it on. Finally the communication between BM and TC subrack became okay and software loading also started.

5. Suggestions and Summary Whenever we are integrating TC with BM subrack we should always remember that the numbering of subracks and thier DIP switch settings will be counted as all the subracks of BM first and then all the subracks of TC, they should not be treated as separate even in case of separate cabinet.

Case7. OMU IP Address Configuration Error due to BSC6900 upgrading from V9R13 to V9R15 Title

OMU IP Address Configuration Error due to BSC6900 upgrading from V9R13 to V9R15

Keywords

Ater interface protection BSC6900

Case code

BSC6900-007

Case type

software upgrading

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BSC6900

1. Phenomenon Description 1. NCRVLNZLABSC1 BSC6900 upgrade from V9R13 to V9R15, before upgrading there are no alarm, but after upgrading there is OMU IP Address Configuration Error, alarm ID--20721. there are 2 pcs OMUc board on slot 24 and slot 25 on this BSC. 2. Run the MML command DSP OMU: HUAWEI Confidential

10


%%DSP OMU:;%% RETCODE = 0 Execution succeeded. OMU server state ---------------Subrack No. = 0 Slot No. = 24 Computer name = OMU_NCRVLNZLABSC1_S24 Internal network fixed IP = 80.168.3.50 External network fixed IP = 10.157.63.51 Backup network IP = 192.168.9.50 Operational state = Active normal Version = V900R013ENGC00SPH532 Subrack No. = 0 Slot No. = 25 Computer name = OMU_NCRVLNZLABSC1_S25 Internal network fixed IP = 80.168.3.60 External network fixed IP = 10.157.63.50 Backup network IP = 192.168.9.60 Operational state = Standby normal Version = V900R013ENGC00SPH532 (Number of results = 2) Other state ----------Internal network virtual IP = 80.168.3.40 Internal network virtual IP mask = 255.0.0.0 External network virtual IP = 10.157.63.49 External network virtual IP mask = 255.255.255.240 Internal network virtual IP state = Normal External network virtual IP state = Normal Data-sync state = Data synchronization is successful Internal network link state = Normal External network link state = Normal Backup network link state = Normal (Number of results = 1)scenatio.

2. Alarm Information Alarm ID: 20721 OMU IP Address Configuration Error

HUAWEI Confidential

11


3. Cause Analysis Use putty to login in OMU , check the IP and find ：the MASK of 10.157.63.50 is 255.255.255.192, but the MASK of 10.157.63.49 and 10.157.63.51 are 255.255.255.240. Due to diffierent MASK launch this alarm. During commision this BSC, they made error configuration.

4. Handling Process 1. Look for one line cable which can ping 10.157.63.50 in the NOC room; 2. Use putty to login in OMUc board, choose the IP as 10.157.63.50; 3. Command "ifconfig", and check the mask of bond1 is 255.255.255.192; 4. Command "/etc/rc.d/omud status" , check the running status of OMU, if running, command "/etc/rc.d/omud stop", stop OMUd firstly; 5. Command " cd /mbsc/bam/version_b/bin/bam" , handover to file omutool; 6. Command "./omutool extercard 10.157.63.50 255.255.255.240", correct the mask; 7. Command "/etc/rc.d/omud start" , start OMU .

5. Suggestions and Summary 1. Before upgrading we need check the mask of OMU IP, make sure they are the same; 2. Inform the customer in advance that maybe there are some new alarms due to upgrading, if the alarm doesn't affect service, tell them do not worry; 3. Check the root cause of alarm after upgrading ASAP, and solve the issue especially the major alarm.

Case8. Direct tunneling between MBSC and GGSN is not working Title

Direct tunneling between MBSC and GGSN is not working

Keywords

direct tunneling OSPF routing GGSN MBSC

Case code

BSC6900-008

Case type

Configuration &Commissioning

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BSC6900

1. Phenomenon Description We activated direct tunneling between MBSC and GGSN by using following command. //ADD IPRT

HUAWEI Confidential

12


ADD IPRT: SRN=4, SN=26, DSTIP="81.192.60.168", DSTMASK="255.255.255.248", NEXTHOP="10.231.70.67", PRIORITY=HIGH, REMARK="IPRT2_TAF_MBSC CASA GARE2 to RC_GGSN2"; But the direct tunneling was not working properly.

2. Alarm Information By doing ping from GGSN to MBSC, ping was not OK as following: TRC IPADDR:SRN=4,SN=26,DESTIP="81.192.60.168",NEXTHOP="10.231.70.67"; MBSC_Hay_Nahda 1 10.231.70.68 3 ms 3 ms 1 ms 2 10.231.71.110 7 ms 7 ms 7 ms 3 192.168.180.65 3 ms 19 ms 9 ms 4 192.168.180.66 3 ms 7 ms 5 ms 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 reports in total (Number of results = 1)

3. Cause Analysis By checking the routing table of GGSN, the GGSN receive the wrong IP from OSPF side, It’s not the user plan of MBSC Means that problem was a wrong configuration on OSPF side. OSPF should configure the routing table using BSC user plan (but the configuration was wrong) 10.231.30.36/32 O_ASE 150 1 D 192.168.187.46 Eth-Trunk6.116 O_ASE 150 1 D 192.168.187.38 Eth-Trunk0.114 O_ASE 150 1 D 192.168.187.174 Eth-Trunk7.216 O_ASE 150 1 D 192.168.187.166 Eth-Trunk1.214 10.231.70.36/32 O_ASE 150 1 D 192.168.187.46 Eth-Trunk6.116 O_ASE 150 1 D 192.168.187.38 Eth-Trunk0.114 O_ASE 150 1 D 192.168.187.174 Eth-Trunk7.216 HUAWEI Confidential

13


O_ASE 150 1

D

192.168.187.166 Eth-Trunk1.214

4. Handling Process OSPF engineer corrected the configuration by correcting the routing tables and adding user plan IP of BSC and problem was solved.

5. Suggestions and Summary While doing OSPF routing table configuration, it should be done using the user plane IP of BSC.

Case9. Can't active cell due to Configuration & License inconsistent Title

Can't active cell due to Configuration & License inconsistent

Keywords

license inconsistent

Case code

BSC6900-009

Case type


Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BSC6900

1. Phenomenon Description When implement the command ACT GCELL by LMT, it shows faulty, and the error code is: the system is in system-level configuration restricted mode.


3. Cause Analysis For this error code, it means the cell configuration & license inconsistent.

HUAWEI Confidential

14


4. Handling Process 1, Implement the command CHK DATA2LIC to check the license. The result as below: License File Attributes ----------------------LicenseSerialNo = LIC2012122602DC00 CreatedTime = 2012-12-26 17:04:12 Product = BSC6900 Version = V900R014 Authorization Type = COMM ESN = B218E2582B9106184E889BD647A8A1842AACD9FF (Number of results = 1) Feature information ------------------Feature Authorization Type Running Deadline Number of Trial Days

= LGMIBA = COMM = PERMANENT = 60

Feature = LGMIBA2 Authorization Type = COMM Running Deadline = PERMANENT Number of Trial Days = 60 (Number of results = 2) License Check ------------ESN = Check consistent Version = Check consistent Work Mode = Check consistent Configuration Data = Check inconsistent (Number of results = 1) Configuration Data Check Result ------------------------------Result = Configuration data exceeding license capacity info: = Cell [0,0], "SD Quick Ho" or "SI 6 Filling Random Bits After Cipher" is set to Yes, which is inconsistent with the setting "A5/1 Encryption Flow Optimization (per TRX)" in the license (or the default setting without the license). = "Info Exchange Content" of the neighboring RNC index (0) is set to "NACC Info", which is inconsistent with the setting of the license

HUAWEI Confidential

15


(or the default setting without the license). = The total number of configured TRUs that support WB_AMR is [2], which exceeds the value [0] allowed by the license (or the default value without the license). = The number of Radio resource reserved handover between GSM and TD-SCDMA based on Iur-g (per TRX) is [2], which exceeds the value [0] allowed by the license (or the default value without the license). (Number of results = 1) The part which mark in red, Configuration Data Check Result, it shows the configuration data exceeding license capacity info. 2, Change the configuration of cell to obey the license, then issue solved.

5. Suggestions and Summary For this type of issue, we have two ways to deal it: 1, The resource or function is not necessary in the configruation, modify the configuration to obey the license. 2, The resource or function is necessary in the configruation, apply the new license.

Case10. Low downlink TBF establishment successful rate due to paging congestion Title

Low downlink TBF establishment successful rate due to paging congestion

Keywords

dowlink TBF establishment successful rate, paging channel congestion

Case code

BSC6900-010

Case type

Performance KPI

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BSC6900

1. Phenomenon Description The downlink TBF establishment successful rate degraded unstably everyday. BSC software version: V900R013ENGC01SPH213

HUAWEI Confidential

16


2. Alarm Information None

3. Cause Analysis 1. Some abnormal terminals. 2. The Packet Downlink Assignment message is with some error, which can not be accepted by MS. 3. LAPD congestion. 4. Paging channel congestion.

4. Handling Process 1. From the GPSR logs, we can see that not only one TLLI or IMSI fails, so there is not abnormal terminal. 2. To compare two pieces of the Packet Downlink Assignment messages, one is OK and the other one is not OK. There is no difference betwen the two messages. 3. There is no congestion on LAPD by checking the counter class "PAGE.DiscForOverload.LAPDLINK". 4. There is congestion and message discarding in PCH channel when the downlink immediate assignment successful rate and the downlink TBF establishment successful rate is low.

HUAWEI Confidential

17


Because the PS downlink immediate assignment message is sent through the PCH channel and the PS message discarding priority is higher than the CS one, if there is congestion in PCH channel, the PS downlink immediate assignment message will be discarded firstly, which makes the downlink TBF establishment successful rate is low. Checking the configuration, we find that there is a very large LAC, which has almost 600 cells. It will makes a lot of paging message in every cell under this LAC, and it will make the paging channel congestion. After dividing the LAC, the number of paging message decreases, and the problem is solved.

5. Suggestions and Summary PS and CS use the same channel to send the downlink immediate assignment message. If the paging channel is congested, the PS downlink immediate assignment message will be discarded firstly, which will affect the downlink TBF establishement successful rate. If the paging channel is congested, there are two methods to solve the problem: 1. To divide the LAC to two or more smaller one. 2. To configure BCH to add paging channel.

Case11. Rebalance XPU CPU Load Title

Rebalance XPU CPU Load

Keywords

XPUa, XPUb, CPU Load

Case code

BSC6900-011

Case type


Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BSC6900

1. Phenomenon Description CPU process the signaling of the BTS. If the load of the CPU is overload, then some signaling will be not be proceeded by CPU and the KPI will be degraded. So we have to move some sites that connected to the high CPU Load to the low CPU Load. Amount of sites that have to move can be calculated use the BHCA value of the sites.

HUAWEI Confidential

18


On the picture below, some CPU Load already reach 70%, to keep the network is stable we have to maintain the CPU load under 70%.

2. Alarm Information: ALM-20256 CPU Overload.

3. Cause Analysis: Inside XPU board there is CPU subsystem (XPUa have 4 CPU subsystem, XPUb have 8 subsystem). If the BTS is unblocked, the site will be automatically connected to the specific CPU. The system will distribute the site on the CPU subsystem and the distribution system is based on the TRX Quantity. The TRX Quantity of each CPU is almost same. For example: 1 XPUa process 100 TRX, then the site will be automatically distribute: CPU 0 : 26 TRX CPU 1 : 23 TRX CPU 2 : 24 TRX CPU 3 : 27 TRX In fact, every site have different. It make the BHCA of every site is different even the TRX Qty of the site if the same. So every CPU can have big different BHCA value that made the CPU load of every subsystem also different. Then we need to rebalance manually to make the CPU load of every subsystem is balance.

4.

Handling Process:

Take the BHCA Data for all the site on the BSC. BHCA =∑ Num of Service Category* BHCA Weight BHCA of a site = ∑ BHCA of the cell Take the data for BHCA and CPU Load on Busy Hour on the same time. Service Category BHCA Weight Counter Description HUAWEI Confidential

19


Location Updating(Times) 0.3 A3030F:Call Setup Indications (Location Updating) (SDCCH) IMSI detach(Times) 0.3 A3030G:Call Setup Indications (IMSI Detach) (SDCCH) CS calls to CS call 1 CA313:Successful Assignments MR Reports to CS call 0.008 S3013:MRs of Serving Cells CS SMS to CS call 0.5 A3030B:Call Setup Indications (MOC SMS) (SDCCH)+A3340B:Downlink Point-to-Point Short Messages on SDCCH Intra-HOs to CS call 0.3 CH311:Number of Outgoing Internal Inter-Cell Handover Commands+CH303:Successful Internal Intra-Cell Handovers Inter-HOs to CS call 0.4 CH343:Successful Incoming External Inter-Cell Handovers CS Paging to CS call 0.5 A0300:Number of MSC-initiated CS paging requests+A0301:Number of SGSN-initiated CS paging requests Uplink TBF Est & Rel to CS call 0.049 A9002:Number of Successful Uplink GPRS TBF Establishments+A9202:Number of Successful Uplink EGPRS TBF Establishments Downlink TBD Est & Rel to CS call 0.049 A9102:Number of Successful Downlink GPRS TBF Establishments+A9302:Number of Successful Downlink EGPRS TBF Establishments PS Paging/Second to CS call 0.283 A031:Number of SGSN-Initiated PS Paging Requests The CPU Load for each CPU: HR9780:Maximum CPU Usage of the XPU Especially for the CPU that processing for MTP3 and RGCP, suggested not use as a destination for CPU rebalance. To check the site connection to the CPU, we can use command: LST BTS, then we get the data:

HUAWEI Confidential

20


Then we compile the data like below table, we analyze the BHCA value and the CPU Load. We can make correlation for the value of BHCA and CPU Load. For example if the BHCA is 90000 the CPU Load will be 70%. Then we move site that connected to the CPU that have Load more than 70% until the CPU BHCA is less than 90000. For the destination CPU, after we move the site we calculate that on the destination CPU the BHCA not more than 90000. Then make the script. The script execution is DEACTIVATE SCRIPT --> REBALANCING SCRIPT --> ACTIVATE SCRIPT

5. Suggestions and Summary: After Rebalancing we can get the highest CPU Load is decrease. We can keep maintain this activity to the BSC if find CPU have high utilization.

Note: 1. If we have high CPU load on the CPU as RGCP then we can add more XPU configure as RGCP 2. If we have high CPU load on the CPU that process SS7, we can add more HSL and assign the ther CPU to process the new HSL.

HUAWEI Confidential

21


GBTS Troubleshooting Cases Case1. Tracing GSM Interference Problem Title

Tracing GSM Interference Problem

Keywords

Tracing, GSM Interference, Interference Band, bursting

Case code

BTS3900-0 01

Case type

Configuration&Commi ssioning

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BTS3900

1. Phenomenon Description Bad voice quality. User experienced often can’t hear voice clearly under site Bantarbolang GSM under BSC Jatibarang (Telkomsel Central Java).

2. Alarm Information None

3. Cause Analysis Because of there’s no alarm information related to BTS hardware and E1 Abis transmission. Further check is investigate interference problem. 1. Check the measurement of “Interference Band Measurement per TRX” from M2000. Found that cell Bantarbolang-2 has interference band 3 and band 4.

HUAWEI Confidential

22


2. Perform uplink frequency scanning to the suspect cell, if found average signal several frequencies are greater than -95 dBm, it indicates uplink interference exist. Interference Band Default Power Level Range Interference band 1

–110 dBm to –105 dBm

Interference band 2


Interference band 3


Interference band 4


Interference band 5


HUAWEI Confidential

23


Uplink frequency scan result show only several frequency has level interference HUAWEI Confidential

24


band 3 and band 4, we can eliminated the probability interference is caused by co-channel interference. 3. Next step is checking interference is caused by CDMA network using LMT, but for getting the valid and precision test result we have to use Spectrum Analyzer. Perform CDMA interference test for all non BCCH TRX, result CDMA interference is not exist.

4. Further step is check intermodulation interference which caused by bad RF board, loose feeder connector or bad antenna. Perform burst idle TRX at low traffic, if interference band change increase from interference band 1 or 2 to interference 3 , 4 or 5 we can infer that intermodulation has exist. Perform real time monitoring channel interference band. Step 1 : Capture BEFORE bursting

Step 2 : do Test Idle Slot / bursting

Step 3 : Capture AFTER bursting

From these result, we indicate that interference is caused by intermodulation. HUAWEI Confidential

25


5. Perform the other test to make sure that interference is caused by intermodulation.

4. Handling Process From analysis above we infer that interference is caused by intermodulation, and perform the following steps : 1. Check connector of jumper feeder installation and antenna port. 2. Check and replace RF board if any fault is found. 3. Check and replace existing antenna if any fault if found. 4. Check filter installation or replace if the existing is using bad filter.

5. Suggestions and Summary For getting valid and precision measurement test of interference, highly recommend to use Spectrum Analyzer.

Case2. PDCH faulty & TCH Carrying no traffic in BTS Title

PDCH faulty & TCH Carrying no traffic in BTS

Keywords Case code

PDCH faulty,TCH Carrying no traffic,QOS Case type

BTS3900-002

Data Configuration

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BTS3900

1. Phenomenon Description This case study help to familiarise and understand when all settings and para meters as per DSD and cell planning are Ok but no traffic on TCH and PDCH showing faulty. BTS PDCH channels are showing faulty & no TCH activites in all three cells and t hey are not able to access any services resulting high revenue loss for customer. BSC Version:BSC 6900( V900R013ENGC00SPH529) BTS version :BTS 3900A (BTS3000V100R013C00SP31) HUAWEI Confidential

26


2. Alarm Information In alarm window only RLF in warning impacted QOS at site.

3. Cause Analysis Resulting KPI degraded randomly for this site and impacted neighbours cell HO and QOS. Only SD assignment successfully as showing in Figure above. We check all Cell status enabled and setup and also all TRX operational state in working condition. Apart from this Ping test from BSC to BTS ok.

HUAWEI Confidential

27


4. Handling Process Step-1 Check all parameters RF and Cell as per Cell Planning and Data Base. Step-2 Check BTS software version and current release. Step-3 Check BSC licence for PDTCH and TCH and if any dynamic assignment or not at site. Step-4 Check IP path for particular site. In this case previously IP path added and all conditions call and data are working but randomly due to faulty timeslots all services hampered and no call voice and data. We see IP path not showing at this site and no data found regarding assignment of IP to this BTS/ANI and QoS setting. Now from IP plan check the BW for this site and re add the IP path again.Now check again call status and data every thing will be OK.

As I conclude in this case study if site status normal and no hardware fault at site except voice and data traffic, check IP path settings and bandwidth configurations as per plan.

5. Suggestions and Summary Null.

Case3. Low TCH availability when site shifted to batteries Title

Low TCH availability when site shifted to batteries

Keywords Case code

Low TCH, batteries,BCCH BTS3900-003

Case type

Data Configuration

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BTS 3012AE

HUAWEI Confidential

28


1. Phenomenon Description when the site is shifted to batteries all the channels are converted to Blocked stat and we have to manually unblock them or we have to wait for commercial power to be restored. No service effecting alarm reported during this time.BTS Type 3012AE and Software Version is V100R008C11SPC026.

2. Alarm Information: Null

3. Cause Analysis: DC Power problem On-site configuration and LMT configuration mismatch.

4. Handling Process: In the initial analysis it was found that TCH availability is low on all the sectors of the site. After checking the stats and alarms it was confirmed that whenever site is shifted to batteries TCH availability goes down without any alarm. After detail analysis it was found out that there is one option BTS POWEROFFLOCKBCCH in BTS attributes which was set to yes. Description is below. BTS POWEROFFLOCKBCCH Explanation: This parameter specifies that when the site is powered off, the BCCH TRX is locked. When the BSC receives the call drop report from the BTS and this function is disabled, only the TRXs (configured as Shut Down Enable) rather than main BCCH TRXs are disabled; if this function is set to yes, all TRXs under the site including the main BCCH TRXs are disabled so as to fulfill energy efficiency.

5. Suggestions and Summary: TCH fluctuation on site resolved after changing the parameter Locking BCCH Trx When Site Power Off Allowed to NO in BTS Attributes.

HUAWEI Confidential

29


Case4. GSM extended Cell with 2 trx's congestion Title

GSM extended Cell with 2 trx's congestion

Keywords

GSM extended Cell, congestion

Case code

BTS3900-004

Case type

Data Configuration

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BTS 3900

1. Phenomenon Description Operator x from conuntry y complained that on a gsm extended cell with 2 TRX's, there were enough timeslot for traffic but cell was suffering from congestion. It seemed that second TRX is not involved with cells traffic.


3. Cause Analysis: Null

4. Handling Process: Checking the bsc CFG MML for this cell it looked like it was something wrong with the configuration for the second TRX. It can bee seen from the fig 1 that the second TRX was not configured as an extended cell TRX.

The MML configuration for those TRX's was: add gtrx:trxid=466, freq=21, trxno=0, cellid=307, idtype=byid, ismainbcch=yes; add trxbind2phybrd:trxid=466, trxtp=mrru, trxpn=0, cn=0, srn=60, sn=0, antpassno=a, rxuidtype=srnsn; set gtrxchan:trxid=466, chno=2, chtype=sdcch8, tspriority=0; set gtrxchan:trxid=466, chno=4, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; HUAWEI Confidential

30


set gtrxchan:trxid=466, chno=6, chtype=pdtch, tspriority=0, gprschpri=egprsnorch; add gtrx:trxid=608, freq=60, trxno=3, cellid=307, idtype=byid, ismainbcch=no; add trxbind2phybrd:trxid=608, trxtp=mrru, trxpn=1, cn=0, srn=60, sn=0, antpassno=a, rxuidtype=srnsn; set gtrxchan:trxid=608, chno=0, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=1, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=2, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=3, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=4, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=5, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=6, chtype=pdtch, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=7, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxiuo:trxid=608, iuo=overlaid; to set gtrxiuo:trxid=608, iuo=underlaid. And the issue was that on the second TRX the time slot configuration has to be changed from: set gtrxchan:trxid=608, chno=0, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=1, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=2, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=3, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=4, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=5, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=6, chtype=pdtch, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=7, chtype=tchfr, tspriority=0, gprschpri=egprsnorch. To: set gtrxchan:trxid=608, chno=0, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=2, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=4, chtype=tchfr, tspriority=0, gprschpri=egprsnorch; set gtrxchan:trxid=608, chno=6, chtype=pdtch, tspriority=0, gprschpri=egprsnorch. Also a change has been perfomed to set the cell to extended configuration. add gcell: cellid=307, cellname="niekkh1", type=gsm900, mcc="244", mnc="91", lac=6291, ci=11755, exttp=dualts_extcell, iuotp=concentric_cell, eniuo=on, flexmaio=off; Both TRX's were set to underlaind configuration, and here appeared a problem. lst gtrxiuo: idtype=byname, cellname="niekkh1"; %%/*3599099*/lst gtrxiuo: idtype=byname, cellname="niekkh1";%% retcode = 0 execution succeeded. list concentric attributes of trx --------------------------------trx id concentric attribute 466 underlaid subcell 608 underlaid subcell (number of results = 2) When trying to set Concentric Circles HO Allowed to "yes", following occurs: set gcellhobasic: idtype=byname, cellname="niekkh1", conhoen=yes; HUAWEI Confidential

31


%%/*445778*/set gcellhobasic: idtype=byname, cellname="niekkh1", conhoen=yes;%% retcode = 235233480 cell [linseh4] is not a concentric cell or does not have trxs in either the underlaid subcell or the overlaid subcell. concentric circles ho allowed must be set to NO. To solve this one of the TRX's was set back to overlaid. lst gtrxiuo: idtype=byname, cellname="niekkh1"; list concentric attributes of trx --------------------------------trx id concentric attribute 466 underlaid subcell 608 overlaid subcell (number of results = 2) Fig.2 is the final configuration which appears in weblmt.

5. Suggestions and Summary: Null

Case5. The wrong IPPATH type to make PDTCH Fault Title

The wrong IPPATH type to make PDTCH Fault

Keywords

PDTCH fault, IPPATH TYPE, AF43,IP

Case code

BTS3900-005

Case type

Data Configuration

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BTS3000

6. Phenomenon Description M operator uses BSC6900 (V900R011C00SPC732) with GBSS9.0 GO type. The MBTS version is BTS3000V100R009C00SP75. When we tested voice service , it worked normally. When we tested GPRS service, it was failed. But there were no any alarms in Monitor Channel status. Then we found PDTCH fault, and the reason was ABIS failed。

HUAWEI Confidential

32



8. Cause Analysis: For GPRS service failed issue, the possible reasons in the list: 1. The transmission quality is not good, so the GPRS does not work. 2. We use inner PCU. Maybe the GDPUd board and DSP system have problem. 3. Gb interface has problem. 4. PDTCH and cell configuration has problem. 5. GRFU hardware has problem. 6. Software has bug.

9.

Handling Process:

1. Because voice traffic worked normally and the transmission worked for old site had not this problem. So it was not transmission quality problem. 2. We tried to change the GRFU board, it is not useful. The fault still appeared in PDTCH channel, so it was not hardware problem. 3. Check the DSP which the cell used, and reset the DSP (Digital Signal Processing), It was not useful. 4. Check the GB interface, the PTPBVC and NSVL worked normally. 5. Compared configuration with old BTS, old BTS used Abis over E1, the new BTS used Abis over IP, and the fault type was showed as: Abis fault,So we thought Abis interface configuration had problem . We checked the command one by one. IPPATH Seemed had problem, because we have so many IPPATH types can be chosen, but in our configuration, we just used EF and AF43. After we

HUAWEI Confidential

33


checked Abis&Iub ConfigurationRecommendation_IP, We found the service type of Abis interface like Picture2,and For PS Low Pri need AF43. and we do not confige the type of AF43. After we configured one more IPPATH, The type of AF33, GPRS worked normally.

10. Suggestions and Summary: Compared with Abis over TDM, We should understand very well about ALL IP network.

Case6. Difference between the least frequency & the highest frequency is more than 15 MHz (75 ARFCNs) so these TRXs cannot be activated Title

Difference between the least frequency & the highest frequency is more than 15 MHz (75 ARFCNs) so these TRXs cannot be activated

Keywords

TRXs cannot be activated due to ARFCNs out of default range

Case code

BTS3900-006

Case type

Data Configuration

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BTS3900

1. Phenomenon Description BSC6900 OMU SW version: BSC6900V900R011C00SPH734. BTS3900 SW version: BTS3000V100R009C00SP79. Abis over TDM (GOIUB). Phenomenon: when assigning cell TRXs (bound to send pass of MRFU board): if the difference between the least frequency & the highest frequency is more than 15 MHz (75 ARFCNs) so these TRXs cannot be activated.

2. Alarm Information: Null.pop up message:when trying to activate the site a pop up message will appear stating that the assigned frequencies (ARFCNs) related to the corresponding RFU exceeds the default send BW range which is 15 MHz.

HUAWEI Confidential

34


3. Cause Analysis: From the pop up message, it is noticed that The upper threshold of the total send bandwidth of all the TRXs bound to send pass of RFU board is out of default range. realted parameter is the: FORWARD BANDWIDTH parameter(BRDTXBW) in the ADD BTSRXUBRD command. this parameter default value is 150 which means that the total send bandwidth should not exceed 15MHz (bound to send pass of MRFU board).

4. Handling Process: a. we have to modify the above mentioned parameter FORWARD BANDWIDTH but we have to ensure that the HardWare support the modified send BW. b. ensure the delivered MRFU is V2 (support 20MHz) not V1. c. apply the command to be BRDTXBW = 200:eg: ADD BTSRXUBRD: IDTYPE=BYID, BTSID=54, BT=GRFU, CN=0, SRN=4, SN=3, RXUNAME="RXU_3", RXUCHAINNO=3, RXUPOS=1, ISCONFIGTHD = YES, BRDTXBW = 200, BRDRXBW = 600, PWRMODE = CLASS2, TrxNum = 6.

5. Suggestions and Summary: a. confirm the range of frequencies used in the project for 900M & 1800M b. confirm the type of RFU board delivered on site. c. for DCS1800: firstly ensure the GRFU1800 type: L60(from 1805M to 1865M) or H60(from 1820 to 1880) to be matched with the planned frequencies. d. modify the FORWARD BANDWIDTH parameter (as above) to be 20MHz if needed.

Case7. Low CSSR Title

Low CSSR

Keywords

low CSSR,KPI, Flex abis mode

Case code

BTS3900-007

Case type

Data Configuration

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BTS3900

1. Phenomenon Description when the traffic increases (specially in the busy hours), abnormally the CSSR became low in some cases less than 10%.

HUAWEI Confidential

35


2. Alarm Information: there is no alarms on the boards just the KPI has been affected (Low CSSR).

3. Cause Analysis: 1- check the current and history alarms of BTS . 2- check the KPI for finding where is the problem. 3- check the relevant configuration according the KPI. 4- change the configuration .

4. Handling Process: 1- we checked the hardware for any alarms in the boards, there was no alarm. 2- we checked the configuration for any misconfiguration just find more than 15 TRX configured on one E1 and have been used Flex abis mode. 3- then, we checked the KPI and find, when the traffic increases and TCH assignments increases we have low CSSR and other hours CSSR is near to normal. 4- we resulted in the resources aren't enough because of many TRX on one E1. 5- we decreased the number of Idle TS and change the multiplexing mode to 4:1 6- we monitored the KPI recovered.

5. Suggestions and Summary: in the places that has more traffic fluctuations, we shouldn't use the Flex abis mode because in high traffic we won't have enough resources.it is better to expand.

Case8. BTS 3900 Antenna mode of S444 type configure is wrong result in VSWR alarm Title

BTS 3900 Antenna mode of S444 type configure is wrong result in VSWR alarm

Keywords

VSWR, DRFU, Antenna

Case code

BTS3900-008

Case type

Data Configuration

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BTS3900

HUAWEI Confidential

36


1. Phenomenon Description G country BSS project need to complete old BTS swap, old tower BTS installation and on air in XX important area. Old tower site TRX configure is S222 for the area. Swap site all TRX expansion to S444. using new BTS3900 of huawei, old tower site need to install antenna system, swap sites requirement swap antenna system. We test VSWR for each site each cable in during swap. Test result is normal, no appear VSWR alarm. But about 2 hour later, S444 site each cell is appear VSWR alarm.

2. Alarm Information: VSWR alarm of DRFU.

3. Cause Analysis: 1. Antenna cable tie-in is no good 2. Cable connective is wrong. 3. DRFU is snag. 4. Antenna Mode configure is wrong.

4. Handling Process: 1.Restar DRFU, the VSWR alarm is disappear, one moment, the VSWR is appear at once. 2.Change the DRFU board, the VSWR is disappear when change finished, but 30 minute later, the VSWR alarm is appear. Check DRFU cable connect, the connection is right. 3.Touch DRFU board, discover the DRFU board temperature is very high. Maybe because of DRFU transmit too high. So we check data configure in BSC , discover S222 site Send Receive Mode is Double Antenna in TRX configure site Board attributes. But S444 site Send Receive Mode is Double Antenna in TRX configure site Board attributes also. Result in DRFU board temperature is very high. Modification S444 site Send Receive Mode to Single Antenna Double Receive. Retouch DRFU board, the DRFU temperature depressed, about 10 minute later, the VSWR alarm is disappear. The problem is resolved.

5. Suggestions and Summary: As the skill reuse at present, one staff with responsibility for sites swap and network optimization is possibility. So for new BTS we need to know the performance, but also need to know difference of data configure with old BTS.

HUAWEI Confidential

37


And we must to check the rationality of data configure in before cut over. In older to reduce risk of swap, and to improve success rate of swap

Case9. Tilt & Azimuth error cause TCH assignment successfully rate is low and Handover failure Title

Tilt & Azimuth error cause TCH assignment successfully rate is low and Handover failure

Keywords

TCH assignment successfully rate,Handover failure, antennas tilt

Case code

BTS3900-009

Case type

Data Configuration

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BTS3900

1. Phenomenon Description There was no Physical Alarm on the site, but according to the stats there was TCH assignment successful rate was very low and also site was experiencing handover failures.

2. Alarm Information: there was no hardware or software alarm on the site.

3. Cause Analysis: There can be many reasons of this case. The calls are not being handed over to the neighboring cells. Traffic congestion is very high. Some channels of the TRX are fault. TRX transmitting power is very low or other following cases. 1) check the internal RF connections, they all were Ok. 2) check and traced the Feeder cables from the Antenna side to the BTS side. 3) Check DTRU's and DDPU's of the effected sector.

4. Handling Process: Step1: Checkedthe internal RF cables and configuration with that of the BSC's Step 2: Trace the Feeder cables so that there would be no partial or full swap between serving sectors. Step 3: Check whether DDPU or DTRU is faulty or not.

HUAWEI Confidential

38


Step 4: When checked the Azimuth and mechanical & Electrical Tilt of the effected Antenna it was found totally changed when compared to the RF plan, where mechanical tilt have to be Zero '0' but that antennas tilt was 4 and also azimuth was not ok. after making changes TCH assignment successful rate become normal and handover failure issue was also resolved.

5. Suggestions and Summary: In TCH assingment successful rate/Handover failure/call droping issues first get the accurate record of azimuths, Mechanical Tilts & Electrical Tilts from the project team or from the operator and check it. if find inaccurate than make changes according to the plan .

Case10. GSM Cell Transmission Delay Abnormal in Abis over IP Title Keywords

GSM Cell Transmission Delay Abnormal in Abis over IP Transmission, delay, abis, ping

Case code

BTS3900-0010

Case type

Data Configuration&Commissioning

Case is from

Huawei Support site

Update Time

2012

Product Family

GSM BSS

Product

BTS3900

1. Phenomenon Description The event "GSM Cell Transmission Delay Abnormal " is intermittently generated indicating a high transmission delay between BSC and BTS. The value showed in the event content is about 180ms, which is lower than the threshold for this event to be generated.(240ms for terrestrial transmission type / 800ms for satellite transmission type).

2. Alarm Information: Event: GSM Cell Transmission Delay Abnormal.

3. Cause Analysis: When ping from BSC interface board to the BTS is performed, the response time seems to be low. (lower than 50ms) HUAWEI Confidential

39


However, if a continuous ping is performed, the result has some particularity, like: Reply from 10.223.86.66: bytes=56 Sequence=1 ttl=255 time=23 ms Reply from 10.223.86.66: bytes=56 Sequence=2 ttl=255 time=24 ms Reply from 10.223.86.66: bytes=56 Sequence=3 ttl=255 time=37 ms Reply from 10.223.86.66: bytes=56 Sequence=4 ttl=255 time=71 ms Reply from 10.223.86.66: bytes=56 Sequence=5 ttl=255 time=29 ms Reply from 10.223.86.66: bytes=56 Sequence=6 ttl=255 time=36 ms 3 minutes later... Reply from 10.223.86.66: bytes=56 Sequence=15 ttl=255 time=838 ms Reply from 10.223.86.66: bytes=56 Sequence=16 ttl=255 time=37 ms Reply from 10.223.86.66: bytes=56 Sequence=17 ttl=255 time=32 ms 2 minutes later Reply from 10.223.86.66: bytes=56 Sequence=15 ttl=255 time=1638 ms Reply from 10.223.86.66: bytes=56 Sequence=18 ttl=255 time=39 ms ... When we observe for a long time, there can be sporadically packets with long delay response time.

4. Handling Process: Although the average response time is low, there are many sporadic packets with response time above the thresholds. This is in fact responsible for the alarm to be generated, even with a delay indication, inside the event, lower than the threshold. This is how this analysis can be developed from product point of view when transmission does not indicate any problem looking just at average response time and loss of packets.

5. Suggestions and Summary: It is good to evaluate the delay and decide if it worths to maintain the transmission state in such conditions. If the conditions are not so bad (not so big delays and not so often), a reconfiguration of some parameters* can be done and the network can operate without serious impact. * transmission type, BTS clock, T200 timer, MS Max Retrans.

HUAWEI Confidential

40


Case11. 2G to 3G cell reselection unsuccessful Title

2G to 3G cell reselection unsuccessful

Keywords

2G, 3G, cell reselection

Case code

BTS3900-0011

Case type

Data Configuration

Case is from

Huawei Support site

Update Time

2012

Product Family

GSM BSS

Product

BTS3900

1. Phenomenon Description GSM BSC 6900 V900R013C00SPC500 While testing for 2G to 3G cell reselection, we were not able to perform it successfully, and it was geeting failed for both ways i.e from 2G to 3G and from 3G to 2G, and also there was not much information in the Trace as well.


3. Cause Analysis: We started cheking the cause one by one in the following step. 1. Check the configuration of 2G cell. For eg: Routing Area and other information 2. Check the configuration of 3G external cell. 3. check the defined relation between 2G and 3G cells 4. Check the reselection parameters with commands LST GCELLHOBASIC and LST GCELLCCUTRANSYS

4. Handling Process: As per our analysis, we started with one by one step as follows 1. we checked the configuration of 2G cell and found it okay. the configuration including routing area was as per given parameters 2. After this we checked the parameters of 3G external cell by command LST GEXT3GCELL and LST G3NCELL and found they were also as per given parameters. 3.After this we checked the reselection parameters with commands LST GCELLHOBASIC and LST GCELLCCUTRANSYS and these parameters were also okay and were as per Hedex. 4. Then we looked again on the details of these two commands and while looking into the details of these commands,

HUAWEI Confidential

41


we found that there was one parameter named as "MSC Version Indication" in SET GCELLCCUTRANSYS command and in this parameter it was given that if our BSC is connected to the MSC that is taking only 2G signalling then MSC version should be set as R98_or_below. And if the MSC is taking 2G and 3G both signalling then MSC version should be set as R99_or_above. So on inquiring about the MSC we came to know that the MSC was handling only 2G signalling so we set the MSC version as R98_or_below. After this we performed the testing again and it was successfull this time.

5. Suggestions and Summary: While configuring for 2G/3G reselection we must not only pay attention to Routing area parametrs but also to MSC version,and we should always get the details of MSC to which the BSC is getting connected.

Case12. Technical Case Regarding HUAWEI GSM BTS Title

Technical Case Regarding HUAWEI GSM BTS

Keywords

DCTB, DTRU, DDPU

Case code

BTS3900-0012

Case type

Commissioning

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BTS3900

1. Phenomenon Description Dealt with HUAWEI GSM BTS. It's reported that the two sectors are continously fluctuating with escalated alarm of DTRU Communication Abnormal & the sectors are brought back to the working state after two minutes.

2. Alarm Information: Alarm generated as per the report is " DTRU Communication Abnormal" for 1ST & 2nd Sector of Huawei GSM BTS.

3.

Cause Analysis:

Aaccording to the Alarm generated,it can be infer intially that DTRU or DDPU can cause the issue. HUAWEI Confidential

42


It can also be assumed that Back plane should also be a reason for the fluctuation as the Upper subrack of sectors are only fluctuating for the time being.

4. Handling Process: Each DTRU from fluctuating sectors has added to 3rd sector & Created & checked for consistency. It's came to found that those DTRU has not got down at 3rd sector.So DTMU,DDPU & Back plane changed accordingly. But the site status remain unchanged & started fluctuating again for the 1ST & 2nd sectors indefinitely. Finally changed DCTB of BTS & Issue successfully shown to be cleared.

5. Suggestions and Summary: No alarms are generated /found corresponding to DCTB board.So find difficult to analyse at first stage. So as to resolve the issue,particular alarms should be analysed or tracked out for the root clearance of BTS sector down.

Case12. GSM Cell UL Quality abnormal Title

GSM Cell UL Quality abnormal

Keywords

GSM bad uplink quality, TMSI

Case code

BTS3900-0013

Case type

O&M

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BTS3900

1. Phenomenon Description Customer X from country Y has reported bad uplink quality & uplink strength in the 3rd sector of GSM site Z.

2.

Alarm Information:

Null

3.

Cause Analysis:

From part of the messages feedback it shows the SDCCH drop rate is 11.76%. The reasons are error indication messages,

HUAWEI Confidential

43


with message T200 expired. TCH drop is zero. Figure 1 shows the service of the cell is not affected. T200 expiration should indicate that the MS has no information of system location updating request. Take one of the process the MR shows during the location updating for example . The MR has a lot of 7/-110dB records because there’s no response from MS. At the same time the downlink is normal.

Fig.1. But it causes the cell uplink quality abnormal as in figure 2.

Fig.2. Location updating successful rate of the cell is only 28.5%. Part of the reason is the MS no response, other causes are location updating reject with reason is PLMN not allowed.

HUAWEI Confidential

44


Fig.3. For the trace it can be used TMSI( fig 4), the IMSI of the MS is unavailable. .

4.

Handling Process:

Null

5.

Suggestions and Summary:

The issue caused by abnormal location updating process. MS is not responding to the location update request. The service of the cell is not affected. Only the UL quality of the cell is abnormal. Faulty terminal issue.

Case14. GSM Neighbouring Cell Analysis Data Does Not Show Some Measurement Report For Some Cell Title

GSM Neighbouring Cell Analysis Data Does Not Show Some Measurement Report For Some Cell

Keywords

Neighbouring Cell, TMSI

Case code

BTS3900-0014

Case type

Data Configuration

Case is from

Huawei Support site

Update Time

2013

Product Family

GSM BSS

Product

BTS3900

HUAWEI Confidential

45


1. Phenomenon Description Problem Description: User complaint Nastar Analysis Function "GSM Neighboring Cell Analysis Data" does not show some measurement report for some cell In IManager Nastar V600R008C01SPC200. Please refer to below screenshot:

:


3. Cause Analysis: 1. From the screenshot provided by user, we found out some of the "GSM Neighbouring Cell Analysis Data Does Not Show Some Measurement Report For Some Cell". 2. Suspect customer didnt enable the counter on M2000, advice customer check the counter setting on M2000 and found out customer didnt enable some of the counter. 3. Advice customer to enable all the counter in order to facilitate GSM Neighboring Cell Analysis in IManager Nastar V600R008C01SPC200. Cause : Customer didn't enable some of the counter in M2000, hence some of the "GSM Neighbouring Cell Analysis Data Does Not Show Some Measurement Report For Some Cell".

HUAWEI Confidential

46


4. Handling Process: 1. Request screenshot and raw data file from user. 2. We suspect user didnt enable below counter in M2000 to facilitate GSM Neighboring Cell Analysis in IManager Nastar V600R008C01SPC200. 3. In order to to facilitate GSM Neighboring Cell Analysis, all the counters of the subsets need to be activated in M2000. A. MR Measurement -> Number of MRs per Cell B. MR Measurement -> Neighbor Cell Level Measurement per Cell C. MR Measurement -> Uplink-and-Downlink Balance Measurement per TRX D. MR Measurement -> Number of MRs based on TA per TRX E. MR Measurement -> TCHF Receive Level Measurement per TRX F. MR Measurement -> TCHH Receive Level Measurement per TRX G. MR Measurement -> Receive Quality Measurement per TRX H. Call Measurement -> GSM Cell to GSM Cell Outgoing Handover Measurement. 4. After confirm with user, we found that user didn't enable counter of the subset when perform GSM Neighboring Cell Analysis. 5. We provide the steps to customer to activate the 8 function subsets. A. Log in the M2000 client and make sure the username has got the privilege to finish the following steps. B. Open the page: M2000 -> Performance -> Measurement Management.

C. Activate all the 8 subsets one by one according to the following picture and click “Apply"

HUAWEI Confidential

47


7. After activate the counter, the problem has been solved, user is able to facilitate Nastar Analysis Function "GSM Neighboring Cell Analysis Data"

please refer to below screenshot. Note: Method above to activate counter in M2000 is applicable to all version of M2000.

HUAWEI Confidential

48


5. Suggestions and Summary: Please enable and check all the counter in M2000 before facilitate Nastar Analysis Function "GSM Neighboring Cell Analysis Data"in IManager Nastar System.

HUAWEI Confidential

49

GSM Product Training Technical Cases

Recommend Documents