Gsmproducttrainingtechnicalcases 150421113040 Conversion Gate01 PDF

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 Update
Huawei Support site 2013
from Time
Product
GSM BSS Product BSC6910
Family
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, thats 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
A interface main and standby boards frequently switch in one BSC caused
Title
by other BSC in BM-TC separated when done A over IP
Keywords AoIP BM/TC separated frequently switch
Configuration&Commissionin
Case code BSC6900-002 Case type
g
Case is Update
from Time
Product
Family
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 cant 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
Configuration
Case code BSC6900-003 Case type
&Commissioning
Case is Update
from Time
Product
Family
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 cant 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 cant 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
Huawei Support site
from Time
Product
Family
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
from Time
Product
Family
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 NodeBs 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
from Time
Product
Family
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
OMU IP Address Configuration Error due to BSC6900 upgrading from

Title
V9R13 to V9R15
Keywords Ater interface protection BSC6900
Case code BSC6900-007 Case type software upgrading
Case is Update
from Time
Product
Family
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
from Time
Product
Family
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, Its 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
from Time
Product
Family
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
Low downlink TBF establishment successful rate due to paging

Title
congestion
Keywords dowlink TBF establishment successful rate, paging channel congestion
Case code BSC6900-010 Case type Performance KPI
Case is Update
from Time
Product
Family
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
from Time
Product
Family
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

BTS3900-0 Configuration&Commi
Case code Case type
01 ssioning
Case is Huawei Update
2013
from Support site Time
Product
GSM BSS Product BTS3900
Family
Bad voice quality. User experienced often cant hear voice clearly under site
Bantarbolang GSM under BSC Jatibarang (Telkomsel Central Java).
None
3. Cause Analysis
Because of theres 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
from Time
Product
Family
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 Huawei Support Update
2013
from site Time
Product
GSM BSS Product BTS 3012AE
Family
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
from Time
Product
GSM BSS Product BTS 3900
Family
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
from Time
Product
Family
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
Difference between the least frequency & the highest frequency is more
Title
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
from Time
Product
Family
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
from Time
Product
Family
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
BTS 3900 Antenna mode of S444 type configure is wrong result in

Title
VSWR alarm
Keywords VSWR, DRFU, Antenna

Case is Update
from Time
Product
Family
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
Tilt & Azimuth error cause TCH assignment successfully rate is low
Title
and Handover failure
Keywords TCH assignment successfully rate,Handover failure, antennas tilt

Case is Update
from Time
Product
Family
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
Data
Case code BTS3900-0010 Case type
Configuration&Commissioning
Case is Update
from Time
Product
Family
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
from Time
Product
Family
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
from Time
Product
Family
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
from Time
Product
Family
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 theres 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
GSM Neighbouring Cell Analysis Data Does Not Show Some

Title
Measurement Report For Some Cell
Keywords Neighbouring Cell, TMSI

Case is Update
from Time
Product
Family
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.

Gsmproducttrainingtechnicalcases 150421113040 Conversion Gate01 PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Gsmproducttrainingtechnicalcases 150421113040 Conversion Gate01 PDF

Caricato da

Copyright:

Formati disponibili

GSM Product Training Technical Cases

GSM Product Training

BSC6900 Troubleshooting Cases ............................................................................................... 1

GBTS Troubleshooting Cases ...................................................................................................22

BSC6900 Troubleshooting Cases

Case1. Cannot login weblmt in some office due to different IP

Keywords webLMT, login, proxy

Case code BSC6900-001 Case type O&M tools

We have new BSC6910 deployed. In Office A of Customer we can login weblmt in IE

1. Ping to external virtual IP of BSC6910 10.251.169.153 both in office A and office B is

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

MTP3 signal link fault alarms about A interface.

5. Suggestions and Summary

DPUc board works in three mode:

5. Suggestions and Summary

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

The BSC unable to add SPU boards at slot 4

Following steps were followed on site:

So we followed following steps:

5. Suggestions and Summary

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

When only one board fails, possible causes are as follow:

If we check the backplane ports on subrack 4 (DSP BACKPLANEPORT) we can see

5. Suggestions and Summary

Case6. Problem in integrating TC subrack with BM

Title Problem in integrating TC subrack with BM

Case code BSC6900-006 Case type Engineering&Installation

We checked following information to handle this problem.

So we came to know that somehow 2nd TC subrack is not configured as subrack 4

5. Suggestions and Summary

Whenever we are integrating TC with BM subrack we should always remember that

Case7. OMU IP Address Configuration Error due to

BSC6900 upgrading from V9R13 to V9R15

OMU IP Address Configuration Error due to BSC6900 upgrading from

1. NCRVLNZLABSC1 BSC6900 upgrade from V9R13 to V9R15, before upgrading

OMU server state

Alarm ID: 20721 OMU IP Address Configuration Error

5. Suggestions and Summary

Case8. Direct tunneling between MBSC and GGSN is not

Title Direct tunneling between MBSC and GGSN is not working

We activated direct tunneling between MBSC and GGSN by using following

By doing ping from GGSN to MBSC, ping was not OK as following:

5. Suggestions and Summary

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

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

Keywords license inconsistent

Case code BSC6900-009 Case type Configuration&Commissioning

Configuration Data Check Result

5. Suggestions and Summary

For this type of issue, we have two ways to deal it:

Case10. Low downlink TBF establishment successful rate

due to paging congestion

Low downlink TBF establishment successful rate due to paging

The downlink TBF establishment successful rate degraded unstably everyday.

1. Some abnormal terminals.