Gsm product training technical cases

GSM Product Training Technical Cases

HUAWEI Confidential

GSM Product Training

Technical Cases

2013


HUAWEI Confidential i

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 1

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;



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.



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


Update

Time 2013

Product



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.


MTP3 signal link fault alarms about A interface.



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.


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


Update

Time 2013

Product



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



message and cause value shows: equipment failure.


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.


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 Configuration&Commissioning

Case is


Update

Time

Product



The BSC unable to add SPU boards at slot 4



BSC Version: V900R013C00


None.

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


Whenever we are using MBSC in UO mode as a whole then we always need to change



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


Update

Time 2013

Product



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.


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.



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.


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


Update

Time 2013

Product



While intergrating 2nd TC subrack with BM, software was not getting uploaded and

cards were not getting activated.

MBSC version: V900R013C00SPH558 VER.


None.



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



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.


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


Update

Time 2013

Product



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:



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


Alarm ID: 20721 OMU IP Address Configuration Error



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 .


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


Update

Time 2013

Product



We activated direct tunneling between MBSC and GGSN by using following

command.

//ADD IPRT



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.


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


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



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.


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 is


Update

Time 2013

Product



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.


None.

3. Cause Analysis

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



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


Feature information

-------------------

Feature = LGMIBA


Running Deadline = PERMANENT

Number of Trial Days = 60

Feature = LGMIBA2


Running Deadline = PERMANENT

Number of Trial Days = 60


License Check

-------------

ESN = Check consistent

Version = Check consistent

Work Mode = Check consistent

Configuration Data = Check inconsistent


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



(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).


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.


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


Update

Time 2013

Product



The downlink TBF establishment successful rate degraded unstably everyday.

BSC software version: V900R013ENGC01SPH213




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.



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.


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 is


Update

Time 2013

Product



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.



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



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:



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.



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


Bad voice quality. User experienced often can’t hear voice clearly under site

Bantarbolang GSM under BSC Jatibarang (Telkomsel Central Java).


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.



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







Uplink frequency scan result show only several frequency has level interference



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.



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.


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 PDCH faulty,TCH Carrying no traffic,QOS

Case code BTS3900-002 Case type Data Configuration

Case is


Update

Time 2013

Product



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)




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.



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.


Null.

Case3. Low TCH availability when site shifted to batteries

Title Low TCH availability when site shifted to batteries

Keywords Low TCH, batteries,BCCH


Case is

from

Huawei Support

site

Update

Time 2013

Product

Family GSM BSS Product BTS 3012AE




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.


Null

3. Cause Analysis:

DC Power problem

On-site configuration and LMT configuration mismatch.


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.


TCH fluctuation on site resolved after changing the parameter Locking BCCH Trx When

Site Power Off Allowed to NO in BTS Attributes.



Case4. GSM extended Cell with 2 trx's congestion

Title GSM extended Cell with 2 trx's congestion

Keywords GSM extended Cell, congestion


Case is


Update

Time 2013

Product

Family GSM BSS Product BTS 3900


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.


Null

3. Cause Analysis:

Null


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;



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 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=7, chtype=tchfr, tspriority=0, gprschpri=egprsnorch.

To:




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


(number of results = 2)

When trying to set Concentric Circles HO Allowed to "yes", following occurs:

set gcellhobasic: idtype=byname, cellname="niekkh1", conhoen=yes;



%%/*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


608 overlaid subcell

(number of results = 2)

Fig.2 is the final configuration which appears in weblmt.


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 is


Update

Time 2013

Product



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。




Null

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.


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



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.


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 is


Update

Time 2013

Product



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.


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.



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


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.


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 is


Update

Time 2013

Product



when the traffic increases (specially in the busy hours), abnormally the CSSR became low

in some cases less than 10%.




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 .


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.


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 is


Update

Time 2013

Product





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.


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.


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.


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.



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 is


Update

Time 2013

Product



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.


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.


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.



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.


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 GSM Cell Transmission Delay Abnormal in Abis over IP

Keywords Transmission, delay, abis, ping

Case code BTS3900-0010 Case type Data

Configuration&Commissioning

Case is


Update

Time 2012

Product



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


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)



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






3 minutes later...




2 minutes later



...

When we observe for a long time, there can be sporadically packets with long delay

response time.


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.


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.



Case11. 2G to 3G cell reselection unsuccessful

Title 2G to 3G cell reselection unsuccessful

Keywords 2G, 3G, cell reselection


Case is


Update

Time 2012

Product



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.


Null

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


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,



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.


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


Update

Time 2013

Product



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.


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.



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.


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.


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


Update

Time 2013

Product



Customer X from country Y has reported bad uplink quality & uplink strength in the 3rd

sector of GSM site Z.


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,



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.



Fig.3.

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

.


Null


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 is


Update

Time 2013

Product





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:

:


Null

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




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"



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.




Please enable and check all the counter in M2000 before facilitate Nastar Analysis

Function "GSM Neighboring Cell Analysis Data"in IManager Nastar System.

Gsm product training technical cases

Technology

Transcript of Gsm product training technical cases