Maintenance Experience, Issue256 (GSM BSS Products) - 348966

Preface
In pursuit of the idea First-class service, Customer service,

and in order to make more profits and provide better services for
our customers, we have edited Maintenance Experience (Issue
256) for GSM radio products (BSC, BTS, OMCR) of ZTE, which
includes 6 articles about maintenance cases.
With the wide application of GSM products of ZTE, routine
maintenance, a major job of the technical maintenance personnel
of operators, has become more and more important. This issue,
which collects articles written by GSM technical personnel of ZTE,
describes practical cases and corresponding solutions that are
often met during the commissioning and maintenance procedure.
We hope it will be helpful to your routine maintenance work.
For more articles of maintenance experience and related
technical materials, please log in to ZTE technical support website
http://support.zte.com.cn.
If you have any requirement, question, or suggestion, please
feel free to contact us. Your attention and support are greatly
appreciated.
Maintenance Experience
Bimonthly for GSM Products
No.6 Issue 256, April 2011
Editorial Committee
Director: Qiu Weizhao
Deputy Director: Huang Dabin
Editors:
Fang Xi, Wang Zhaozheng, Xu Xinyong,
Zhang Jian, Zhang Jiebin, Zhao Cen,
Zhou Guifeng, Xiao Shuqing, Ge Jun,
Zhao Haitao, Huang Ying, Xu Zhijun,
Jiang Haijun, Dong Yemin, Dong Wenbin
Technical Senior Editors:
Gong Kai, Yang Yong, Xie Jie
Executive Editor:
Li Xianghui
Maintenance Experience Editorial Committee

ZTE Corporation
April 2011
Newsroom
Address: ZTE Plaza, No. 55, Hi-tech Road
South, ShenZhen, P.R.China
Postal code: 518057
Contact: Ning Jiating
Email: doc@zte.com.cn
Tel: +86-755-26776049
Fax: +86-755-26772236
Document support mail box: doc@zte.com.cn
Technical support website: http://ensupport.zte.
com.cn
Contents
Link Establishment Failure Between SDR and OMCB Caused by Self-Loop E1 in the Case of
Multiple Transmission Links................................................................................................................2
Control Plane Communication Failure of All Boards in an iBSC.........................................................4
Threshold Crossing of MINOS Disk Space Usage............................................................................14
Downlink Digital IF Pre-Distortion Alarm of RRU Caused by Too Thin Power Cable........................18
Failure of Adding BSCID During CBC Management Caused by Broadcast Message Support Not
Configured for a Cell.........................................................................................................................21
Failure of Paging Called Mobile Stations in an iBSC Caused by Limited-Capacity Paging Channel....
..........................................................................................................................................................28
April 2011
Issue 256
Link Establishment Failure Between

SDR and OMCB Caused by Self-Loop E1
in the Case of Multiple Transmission
Links
Zhao YangHao / ZTE Corporation
1 Fault Symptom
3 Troubleshooting
During the equipment swap in an SDR
(1) Check each 2M transmission link by
office, the link establishment between the
performing a self-loop test on the corresponding
OMCB and an SDR BS8800 (which uses
2M interface at the iBSC side on the DDF. It is
two transmission links) failed.
found that the 2M link is correctly connected, not
The SDR BS8800 (also called SDR
cross-connected to another BTS. Then connect the
for short) was configured with two E1/T1
2M interface again. The Loss of Trunk Link Signal
transmission links on field, that is, E1/T1
alarm reported by the DTB board in the iBSC
link 0 and E1/T1 link 1 to the BBU.
disappears. From the test, it can be concluded that

the physical link between iBSC and SDR is normal.
2 Fault Analysis
Figure 1 shows the flow for establishing
incorrect connection of 2M interface on the SA
a link between iBSC and SDR. The
board in another BBU was found. (The cable used
link between iBSC and SDR cannot be
to connect an SA board to a DDF is a 1/2 split
established in the following three situations.
cable supporting eight E1/T1 links (link 0 to 7). At
(1) Physical link failure.
the DDF side, two connectors are available, each
(2) Parameters wrongly-configured in
providing four E1/T1 links (link 0 to 3, and link 4 to
the EMS or OMCB.

(3) Special parameters or requirements.
Figure 1. iBSC-SDR Link Establishment Flow
(2) In the early phase of the swapping, an
7). If the 1/2 split 2M cable is wrongly connected

at the DDF side, the E1/T1 link 4 may be regarded
www.zte.com.cn
as E1/T1 link 0. To check whether the 2M interface
connection between the EUIP interface
of the SA board in this BBU is wrongly connected,
and the OMCR or OMCB server is normal.
perform a self-loop test on the 2M interface at
5) Ping the SDR base station from the
the BBU side on the DDF. A Self-Loop alarm
OMCR or OMCB server. The following
corresponding to E1/T1 link 0 indicates that the 2M
messages are returned, indicating the
cable is correctly connected.
network connection between the SDR
(3) Try to find the broken point by pinging the

nodes on the network from the OMCR server to the
SDR segment by segment as follows.
1) Ping the OMCB server from the OMCR
server. The returned messages indicate that the
network connection between the OMCR server and
the OMCB server is normal.
-bash-3.00$ ping 139.1.16.1
PING 139.1.16.1 (139.1.16.1) 56(84)
bytes of data.
64 bytes from 139.1.16.1: icmp_seq=0
ttl=64 time=0.047 ms
--- 139.1.16.1 ping statistics --5 packets transmitted, 5 received, 0%
packet loss, time 3999ms
rtt min/avg/max/mdev =
0.035/0.040/0.047/0.004 ms, pipe 2
base station and the OMCR or OMCB

server is broken.
-bash-3.00$ ping 118.3.20.16
PING 118.3.20.16
(118.3.20.16) 56(84) bytes of
data.
Time out
(1) It is doubted that the broken

connection is caused by wrong
configuration data. Check the configuration
of the iBSC and the SDR but no wrong
configuration is found.
(2) View the alarms reported by iBSC
on the network element management
system. It is found that an Unavailable
PPP Link alarm on the port No.
corresponding to the SDR base station
is reported by the EUIP board. The
Unavailable PPP Link alarm on the MP
port No. corresponding to the SDR based
disappears after persisting for three to five
seconds, and appears again after several
seconds.
(3) View the alarms reported by the SDR
2) Ping the interface connected to the OMCB

server on the IPBB board from the OMCR
or OMCB server. It is found that the network
connection between the OMCB server and the
IPBB board is normal.
3) Ping the IP Abis interface from the OMCR
via an LMT. It is found that the following

alarms are reported by the CC board.
S C TP A s s o c i a ti o n D i s c o n n e c te d
(SCTP ID: 0)
Broken PPP Link (HDLC ID: 0)
Broken PPP Link (HDLC ID: 1)
Unavailable PPP Link Group (PPP ID: 0)
connection between the OMCB server and the IP
Unavailable PPP Link Group (PPP ID: 1)
Abis interface is normal.
SNTP Time Synchronization Failure
4) Ping the EUIP board from the OMCR
(4) Use the LMT to check the E1/T1
link status of the BBU. It is found that E1/
GSM BSS Products
April 2011
Issue 256
T1 link 0 is normal but E1/T1 link 1 has

problem.
(5) Use the LMT to check the HDLC
status of the BBU. Both HDLC ID 0 and
HDLC ID1 are found failed.
or connecting E1/T1 link 1 to the iBSC.
4 Conclusion
From the previous analysis, it can be concluded
that the link to the OMCB cannot be established for
(6) Check the 2M cable connected to
an SDR configured with multiple transmission links
the SDR. It is found that E1/T1 link 0 is
when one or more of these links are self-looped at
connected to the DDF and then connected
iBSC side.
to the iBSC via the DDF. However, E1/T1

link 1 is connected to the DDF, but the
corresponding 2M interface is self-looped
at the iBSC side on the DDF.
5 Additional Information
If an SDR is configured with multiple
transmission links, a competition mechanism is
(7) Consult the related R&D enginner
introduced into the data protocol between the
whether this situation (that is, an SDR is
SDR and the OMCB after they are physically
configured with two transmission links,
connected. The mechanism chooses the physical
one connected to iBSC and the other
link supporting higher negotiation speed for the
self-looped at iBSC side) impacts the link
establishment of the link between SDR and OMCB.
establishment between SDR and OMCB.
If one of the transmission links is self-looped at the
The answer is Yes, the link between
iBSC side, on which the negotiation speed may
SDR and OMCB cannot be successfully
be the highest, the iBSC deems this self-looped
set up in this situation. The maintenance
link as the one connected to the SDR. And finally,
engineer cancels the self-loop at the iBSC
a normal link cannot be established between the
side on the DDF, that is, breaking the loop
SDR and the OMCB.
Control Plane Communication Failure

of All Boards in an iBSC
Wang ZhiChao / ZTE Corporation
1 Fault Symptom
In an office, all boards in an iBSC
module alarm, as listed in Table 1. During the
reported the Control plane communication
control plane communication failure, no call was
is abnormal between board and its
successfully set up.
www.zte.com.cn
Table 1. Alarm Statistics of Boards in iBSC
Board
Occurrence
Time
Clearing
Time
Duration
(Hour:Minute:
Second)
Alarm Code
LAPD
2010-07-15
18:07:23
2010-07-15
18:07:51
0:00:28
Control plane communication is abnormal between

board and its home module (198066003)
LAPD
2010-07-15
18:07:23
2010-07-15
18:07:44
0:00:21

LAPD
2010-07-15
18:07:23
2010-07-15
18:07:42
0:00:19

PSN
2010-07-15
18:07:23
2010-07-15
18:07:35
0:00:12

DTB
2010-07-15
18:07:23
2010-07-15
18:07:33
0:00:10

DRTB
2010-07-15
18:07:23
2010-07-15
18:07:32
0:00:09

LAPD
2010-07-15
18:07:24
2010-07-15
18:08:22
0:00:58

LAPD
2010-07-15
18:07:24
2010-07-15
18:07:43
0:00:19

LAPD
2010-07-15
18:07:24
2010-07-15
18:07:38
0:00:14

LAPD
2010-07-15
18:07:24
2010-07-15
18:07:38
0:00:14

SPB
2010-07-15
18:07:24
2010-07-15
18:07:38
0:00:14

CMP
2010-07-15
18:07:24
2010-07-15
18:07:30
0:00:06

LAPD
2010-07-15
18:07:25
2010-07-15
18:07:42
0:00:17

LAPD
2010-07-15
18:07:25
2010-07-15
18:07:38
0:00:13

LAPD
2010-07-15
18:07:25
2010-07-15
18:07:33
0:00:08

GLI
2010-07-15
18:07:25
2010-07-15
18:07:38
0:00:13

UIMC
2010-07-15
18:07:25
2010-07-15
18:07:38
0:00:13

UIMC
2010-07-15
18:07:25
2010-07-15
18:07:35
0:00:10

SDTB
2010-07-15
18:07:25
2010-07-15
18:07:33
0:00:08

SPB
2010-07-15
18:07:25
2010-07-15
18:07:33
0:00:08

GIPB
2010-07-15
18:07:27
2010-07-15
18:07:33
0:00:06

LAPD
2010-07-15
18:07:28
2010-07-15
18:07:33
0:00:05

GSM BSS Products
April 2011
Issue 256
2 Fault Details
including Abnormal FE routing and IP/MAC address
All boards in the iBSC reported the
conflict, as listed in Table 2. It was supposed that some
Control plane communication is abnormal
operation had been performed on field that resulted in
between board and its module alarm. And
an IP/MAC address confliction between boards. Then
the control plane communication failure
the maintenance engineer checked that:
persisted for 17 minutes, that is, these
No network cable was connected to the
alarms were cleared after 17 minutes.
UIMC board.
The new resource shelf added for expansion
3 Fault Analysis
was not powered on.
First the maintenance engineer queried

history alarms on field, and found that
The cables were firmly connected to the
rear board of CHUB.
additional alarms were reported besides the
From the check result, it was concluded that the
Control plane communication is abnormal
operations on field did not cause the control plane
between board and its module alarm,
communication failure.
Table 2. Additional Alarm Information
Alarm Information
CHUB
2010-07-15
18:07:05
2010-07-15
18:07:07
0:00:02
Abnormal
FE routing
(198066060)
Rear board
FE port
No.:3;(CPU:1)
SUBUBNET13,IBSC13,1/
UIMC
2/10,CPUNO1
2010-07-15
18:07:05
2010-07-15
18:07:09
0:00:04
Abnormal
FE routing
(198066060)
Rear board
FE port
No.:1;(CPU:1)
SBNET13,IBSC13,1/2/
16,CPUNO1
SUNET13,IBSC13,1/2/
7,CPUNO2
CMP
2010-07-15
18:07:37
2010-07-15
18:07:47
0:00:10
IP/MAC
address conflict
(198005651)
SUBNET13,IBSC13,1/2/
6,CPUNO1
CMP
2010-07-15
18:07:44
2010-07-15
18:10:23
0:02:39
IP/MAC
address conflict
(198005651)
CHUB
15,CPUNO1
2010-07-15
18:07:45
2010-07-15
18:07:55
0:00:10
IP/MAC
address conflict
(198005651)
7,CPUNO1
BIPB
2010-07-15
18:07:45
2010-07-15
18:07:55
0:00:10
IP/MAC
address conflict
(198005651)
7,CPUNO1
CMP
2010-07-15
18:08:11
2010-07-15
18:08:22
0:00:11
IP/MAC
address conflict
(198005651)
8,CPUNO1
BIPB
2010-07-15
18:08:11
2010-07-15
18:08:21
0:00:10
IP/MAC
address conflict
(198005651)
4,CPUNO4
LAPD
2010-07-15
18:08:11
2010-07-15
18:08:21
0:00:10
IP/MAC
address conflict
(198005651)
5,CPUNO1
CMP
2010-07-15
18:08:12
2010-07-15
18:08:27
0:00:15
IP/MAC
address conflict
(198005651)
www.zte.com.cn
The maintenance engineer analyzed the

notifications reported by the iBSC and the print
kept restarting. The print information of

CHUB is listed in Table 3.
information of CHUB. It was found that the CHUB

Table 3. Print Information of CHUB
Print Details
###:2010-07-15 18:07:07 02000 SCH9,SCSMCProc:
MCM Rcv EV_MATE_ERROR in state 4, msg 3.
###:2010-07-15 18:07:07 02000 SCH9,SCSMCProc: S2M Change over finished, reason is 8.

###:2010-07-15 18:07:13 02000 SCH9,SCS_FELinkMgt: FELinkMgt: Change over board due to pair:11 link
but comm down!.
###:2010-07-15 18:07:13 02000 SCH9,SCSMCProc: M2S change over finished, reason is 8.
###:2010-07-15 18:07:13 02000 SCH9,SCSMCProc:

###:2010-07-15 18:07:30 02000 SCH9,SCSMCProc:
but comm down!.
###:2010-07-15 18:07:38 02000 SCH9,SCSMCProc:

###:2010-07-15 18:07:43 02000 SCH9,SCSMCProc: MCM Rcv EV_MATE_ERROR in state 1, msg 3.
but comm down!.
###:2010-07-15 18:08:14 02000 SCH9,SCSMCProc:

###:2010-07-15 18:08:23 02000 SCH9,SCSMCProc:
but comm down!.
###:2010-07-15 18:08:28 02000 SCH9,SCSMCProc:

###:2010-07-15 18:08:43 02000 SCH9,SCSMCProc:
but comm down!.
link but comm down!.
GSM BSS Products
April 2011
Issue 256
The notifications reported by the iBSC are listed in Table 4.

Table 4. Notification Information
Notification Details
###:2010-07-15 18:25:57 02000 SCH9,SCSMCProc:
1 2 15
1
Notification of Active/Standby Changeover (5189) It is a hardware system
fault. The active/standby board changeover is caused by manual operation.(5189)
0
2010-7-15 18:07
Cause details: Abnormal FE routing; Changeover result: Changeover success
(CPU:1)
CHUB
1 2 16
1
0
2010-7-15 18:07
(CPU:1)
CHUB
1 2 15
1
0
2010-7-15 18:07
(CPU:1)
CHUB
1 2 16
1
0
2010-7-15 18:07
(CPU:1)
CHUB
1 1 10
1
0
2010-7-15 18:07
(CPU:1)
UIMU
1 2 15
1
0
2010-7-15 18:07
(CPU:1)
CHUB
1 2 16
1
0
2010-7-15 18:08
(CPU:1)
CHUB
1 2 15
1
0
2010-7-15 18:08
(CPU:1)
CHUB
1 2 16
1
0
2010-7-15 18:08
(CPU:1)
CHUB
2 1 10
1
0
2010-7-15 18:08
(CPU:1)
UIMU
1 2 15
1
0
2010-7-15 18:08
(CPU:1)
CHUB
www.zte.com.cn
2 1 9
1
0
2010-7-15 18:09
(CPU:1)
UIMU
1 2 16
1
0
2010-7-15 18:09
(CPU:1)
CHUB
1 1 9
1
0
2010-7-15 18:09
(CPU:1)
UIMU
1 2 15
1
0
2010-7-15 18:10
(CPU:1)
CHUB
1 2 9
1
0
2010-7-15 18:10
(CPU:1)
UIMC
1 2 16
1
0
2010-7-15 18:10
(CPU:1)
CHUB
1 1 10
1
0
2010-7-15 18:10
(CPU:1)
UIMU
1 2 15
1
0
2010-7-15 18:11
(CPU:1)
CHUB
1 2 16
1
0
2010-7-15 18:12
(CPU:1)
CHUB
1 2 15
1
0
2010-7-15 18:13
(CPU:1)
CHUB
2 1
10
Notification of Active/Standby Changeover (5189)
It is a hardware system

0
2010-7-15 18:13
(CPU:1)
UIMU
1 2 16
1
0
2010-7-15 18:13
(CPU:1)
CHUB
GSM BSS Products
April 2011
Issue 256
2 2 10
1
0
2010-7-15 18:13
(CPU:1)
UIMU
1 2 15
1
0
2010-7-15 18:13
(CPU:1)
CHUB
2 1 9
1
0
2010-7-15 18:13
(CPU:1)
UIMU
1 2 16
1
0
2010-7-15 18:15
(CPU:1)
CHUB
1 1 9
1
0
2010-7-15 18:15
Cause details: GE routing
As indicated in the print information of CHUB, the port pair 11 corresponding to the 2nd route
pair of the CHUB board had problem. The maiintenance engineer checked the cable connections
on the rear board of CHUB and found that:
The 1st route pair was connected to shelf 1 in rack 1.
The 2nd route pair was not connected.
The 3rd route pair was connected to shelf 3 in rack 1.
The 4th route pair was connected to shelf 4 in rack 1.
The 7th route pair was connected to shelf 4 in rack 2 (the shelf was not powered on)
The 8th route pair was connected to shelf 3 in rack 2 (the shelf was not powered on)
10
www.zte.com.cn
It was found that the cable for the 2nd route pair was not used. It was doubted that the 2nd
route pair was connected to UIMC. To confirm this suspicion, print the information of UIMC and
CHUB as follows:
CHUB->SlotPortMapInfo (Information collected by CHUB: Port 21 and 22 are ports of port pair
11, corresponding to the 2nd route pair.)
-----------------CHUB BCM5615 Port Info-------------------------------Show BCM5615 Unit0 Info-------------Received

Slot
Port
Link
Speed
Duplex
AutoNeg
packet
Transmit
RxDiscard
packet
packet
Down
0M
HD
AUTO
Down
0M
HD
AUTO
Down
0M
HD
AUTO
Down
0M
HD
AUTO
Down
0M
HD
AUTO
Down
0M
HD
AUTO
Down
0M
HD
AUTO
Down
0M
HD
AUTO
Down
0M
HD
AUTO
10
Down
0M
HD
AUTO
11
Down
0M
HD
AUTO
12
Down
0M
HD
AUTO
13
Up
100M
FD
NO
1421549369
1572811605
137
14
Up
100M
FD
NO
24407864
24409718
98
15
Up
100M
FD
NO
3221046470
3027882829
797
16
Up
100M
FD
NO
24417830
24439842
101
17
Up
100M
FD
NO
127531880
145249253
109
18
Up
100M
FD
NO
25359952
25483919
107
19
Up
100M
FD
NO
43946160
46506508
163
20
Up
100M
FD
NO
1403346567
1560800855
113
21
Down
0M
HD
AUTO
7129462
7393149
72
22
Down
0M
HD
AUTO
842394
974566
2863
23
Up
100M
FD
NO
3023909907
2852272867
1076
24
Up
100M
FD
NO
24418861
24513111
110
25
Up
1kM
FD
AUTO
129141202
278164803
6466
26
Down
1kM
FD
AUTO
-------------------------- Show
BCM5615
Unit1 Info-----------------------
GSM BSS Products
11
April 2011
Issue 256
UIM_2->SlotPortMapInfo (PORT 23 and 24 correspond to FE1 and FE2 of UIMC)
------------------------
BCTC(V1) BackBoard Port Info ---------------------
------------------------
Show BCM5615 Unit0 Info -------------------------Received
Slot
RxDiscard
Port
Link
Speed
AutoNeg
packet
packet
Down
0M
HD
AUTO
Down
0M
HD
AUTO
Down
0M
HD
AUTO
Down
0M
HD
AUTO
Down
0M
HD
AUTO
11
Down
0M
HD
AUTO
12
Up
100M
FD
NO
Down
0M
HD
AUTO
10
Down
0M
HD
AUTO
19
Down
0M
HD
AUTO
20
Down
0M
HD
AUTO
17
Down
0M
HD
AUTO
18
Down
0M
HD
AUTO
15
Up
100M
FD
NO
1806487188
1910708989
26
16
Up
100M
FD
NO
3182976016
3238510362
24
13
Up
100M
FD
NO
95850125
127108296
12
14
Up
100M
FD
NO
98815838
129917511
Up
100M
FD
NO
2280942208
2395425969
27
Up
100M
FD
NO
3233537806
3302308435
66
21
Down
0M
HD
AUTO
22
Down
0M
HD
AUTO
23
Down
0M
HD
AUTO
5077825
24
Down
0M
HD
AUTO
1236868
Up
100M
Duplex
Transmit
47950549
5024884
1255384
660
2255
1
26
Up
100M
FD
AUTO
69290433
84975990
25
Up
1kM
FD
AUTO
3844220971
3591881647
1337
BCM5615
NO
28451017
--------------------- Show
FD
packet
79287289
Unit1Info-------------------------
4 Conclusion
It was concluded from the alarm information in Table 5 that the 2nd route pair of the CHUB
board is connected to FE1 and FE2 of the UIMC board on the control shelf. This connection
formed a loop on the control plane, which finally resulted in the communication failure on the
control plane.
An Abnormal FE routing alarm is reported when one port of a route pair successfully
negotiates with its peer port but the other fails. This alarm is cleared when both ports succeed or
12
www.zte.com.cn
fail to negotiate with their peer ports. If a reported Abnormal FE routing alarm is cleared after
three seconds, the probable causes include:
(1) The other port successfully negotiates with its peer port after three seconds.
(2) The negotiation of the other port is looped. A large amount of messages caused by the
looped port impact the port used to negotiate with its peer port successfully. Finally, both ports fail
to negotiate with their peer ports.
In this case, the information collected by UIMC and CHUB indicated that large amounts of
packets were received and transmitted at corresponding ports. That demonstrated that the control
panel communication failure was caused by a loop on the control panel.
Table 5. Abnormal FE Routing Alarms
Alarm Information
SUBNET13,IBSC13,1/2/10,CPUNO1 UIMC
0:00:04 Abnormal FE routing (198066060)
2010-07-15 18:07:05
2010-07-15 18:07:09
Rear board FE port No.:1;(CPU:1)
SUBNET13,IBSC13,1/2/16,CPUNO1 CHUB
0:00:02 Abnormal FE routing (198066060)
2010-07-15 18:07:05
2010-07-15 18:07:07
Rear board FE port No.:3;(CPU:1)
GSM BSS Products
13
April 2011
Issue 256
Threshold Crossing of MINOS Disk

Space Usage
He ChaoYu / ZTE Corporation
1 Fault Symptom
The MINOS network element
performance data. The shortage of tablespace
management system in an office reports
can be relieved by adding tablespace files
the alarm, Application server MINOS hard
and enlarging tablespaces. With the continous
disk: the usage exceeds the monitoring
enlargement of tablespaces and addition of
threshold. (Threshold: 90%, Current value:
tablespace files, more and more disk space are
94.45%). Figure 1 shows the usage of the
occupied. When the usage rate of the disk space
hard disk.
exceeds 90%, a threshold crossing alarm is
The MINOS manages many sites.

When too may measrement tasks are
created, the MINOS collects large
reported.
2 Fault Analysis
amounts of performance data and stores
(1) Check the usage rate of each tablespace. It
the collected data in its database, which
is found that the usage rate of some tablespaces
results in the shortage of tablespace
reaches 100%, as shown in Figure 2.
Figure 1. MINOS Hard Disk Usage
14
and finally causes the failure of storing received
www.zte.com.cn
(2) Check the usage rate of files in each

tablespace. It is found that the usage rate of each
file reaches 100%, as shown in Figure 3.
by a disk damage. Therefore, this solution

cannot be used on field.
(5) Another solution is to move and
(3) A solution of enlarging the volume of the
rearrange tablespace files on all disks on
disk array is considered. However, it cannot be
average. However, the usage rate of most
immediately implemented on field because a time-
disks is very high, almost reaching 90%.
consuming business procedure is required for
The rearrangement of tablespace files
purchasing new disks.
can only temporarily solve the shortage
(4) Two disks in the disk array reserved for hot

backup can be used to store more data. However,
problem. Therefore, this solution is not

adopted on field.
the removal of hot backup risks data loss caused
Figure 2. Tablespace Usage Rate
Figure 3. Tablespace File Usage Rate
GSM BSS Products
15
April 2011
Issue 256
After the above analysis, the major

cause of disk shortage is too large
tablespace files, which waste much
client. Figure 5 shows the resizing result.
4 Conclusion
disk space due to their low usage rate.
(1) The shortage of tablespace is a critical
Therefore, a solution trying to release
problem that influences the report of performance
some disk space by decreasing the size of
and alarm data. Periodical check of tablespace
tablespace files is considered.
usage is recommended to ensure that enough
3 Troubleshooting
tablespace is available for data storage, preventing

the potential risk of data loss.
(1) The maintenance engineer
( 2 ) Av o i d u s i n g t h e s o l u t i o n o f a d d i n g
communicated with the operator and
tablespace files without analyzing the problem of
made an agreement that the MINOS only
tablespace shortage caused by quickly-increased
needed to store performance and alarm
tablespace usage. Find and analyze the cause
data within the latest 30 days. Then the
of the quick increase of tablespace usage, and
performance data backup and clearing
choose a proper solution according to the actual
cycle was modified to 30 days for reducing
cause.
the amount of data stored in the database.

(2) The maintenance engineer cleared
(3) Common methods for solving the tablespace

shortage problem include:
the performance and alarm data 30 days
Check the usage of tablespaces, and clear
before from the database to reduce the
unnecessary performance data to reduce
usage rate of tablespaces, and then

checked the usage of each tablespace
the usage of tablespaces.

Shorten the backup and clearing period of
and files in each tablespace. It was found
performance data to reduce the amount of
that the usage rate of each tablespace
performance and alarm data stored in the
was greatly reduced, as shown in Figure 4.

(3) Finally, the maintenance engineer
resized tablespace files via an Oracle
Figure 4. Tablesapce Usage Rate After Data Clearing
16
database.
Rearrange tablespace files to distribute
them on different disks on average.
www.zte.com.cn
Figure 5. Spacefile Usage Rate After Resizing
Decrease the size of tablespace files.
Enlarge the volume of hard disks.
in the threshold crossing of the usage rate.

(7) A short period is recommended for
(4) When the tablespaces in the database are
the backup and clearing of performance
full or the usage rate of the disk space reaches
data in the database, especially for
100%, the MINOS will fail to receive and store
performance data of a large-scale office.
performance data. Large amounts of performance
A proper short backup and clearing period
data will be lost if the space shortage problem
can improve the usage of the database.
persists for a long time. The SVR log will record
(8) Avoid creating too many measurement
a large amount of error messages, indicating the
tasks on the MINOS. Delete unused or stoped
occurrence of a critical failure. To prevent this
measurement tasks in time.
failure, it is recommended to periodically check the

usage of tablespaces and hard disk space.
(5) When a tablespace is full or the usage
rate of hard disk space exceeds the threshold,
Take the actual field situation into

consideration when choosing and
implementing a solution for the disk space
shortage problem.
first check whether the space shortage problem

already causes a report failure of performance and
alarm data. If yes, troubleshoot the performance
data report problem to prevent data loss before
processing the tablespace shortage problem.
(6) Do not frequently use the method of
adding tablespace files when a tablespace is full.
Continuous addition of tablespace files will cause
the increase of disk space usage and finally result
GSM BSS Products
17
April 2011
Issue 256
Downlink Digital IF Pre-Distortion Alarm

of RRU Caused by Too Thin Power Cable
Zhou Jun / ZTE Corporation
1 Fault Symptom
Two SDR base stations are connected
to an iBSC in an office. One SDR base
station is operating properly. The other
one adopts an S22 configuration in a star
DPD Error.
Bsp Init Op Succ when RF channel check.
Current State = 28 , Halting...
0x1447a88 (SCH3):
networking mode. Two RRUs configured
PA Operate: ON: SCH3
in this base station report the Downlink
Beging Static Power Adjust...
digital pre-distortion alarm.
Coarse delt -16.89,txatt = -80, TSSI
2 Fault Analysis and

Troubleshooting
(1) Collect the power-on print
information of each RRU (that is, the
= 47.86 , TCPW = 39.66

Coarse Adjust Error TSSI = 47.86 ,
TCPW = 39.66
Static Power Adjust Failed.0x1447a88
(SCH3):
output information collected from the
PA Operate: OFF: SCH3
base station via Telnet when the RRU is
DPD Error.
powered on). It is found that the actual
Bsp Init Op Succ when RF channel
transmitted power (TCPW=40.77) of the
check.
RRU is 7 dB lower than the preset power

(TSSI=47.86).
Current State = 28 , Halting...

0x1447a88 (SCH3):
CC->rlogin "200.254.0.2"
DTR->
Coarse delt -14.81,txatt = -70, TSSI
Current State = 28 ,
Halting... 0x1447a88 (SCH3):
Coarse delt -16.93,txatt =
-80, TSSI = 47.86 , TCPW =
39.64
Coarse Adjust Error TSSI =
47.86 , TCPW = 39.64
Static Power Adjust
Failed.0x1447a88 (SCH3):
18
= 47.86 , TCPW = 40.71Data must be

0~315 !
Delt TxAtt Coarse -14.81 ~ -70, TxAtt
= -10
Fine Adjust Val =
7.09, TSSI =
47.86, TCPW = 40.77

Fine Adjust Error TSSI = 47.86, TCPW
= 40.77
Static Power Adjust Failed.0x1447a88
(SCH3):
=======sizeof(BOOLEAN) = 1
www.zte.com.cn
(2) Run the showrun command. The returned
with a thicker cable (6 mm2), and then
information indicates that the power amplifier of the
power on the RRU. The alarm disappears
RRU is shutdown.
and the base station is operating properly.

Note: Because the operator changes
showrru
the installation positions of the RRUs, the
PA :off
power cables delivered by ZTE are not
staitc power level:0
long enough to connect the RRUs. The
work mode :GSM
operator purchases new power cables
board band :1800M
(3 mm2) and uses them to connect the
WCDMA carrier cfg:0
RRUs. The power cable connecting one
GSM carrier cfg:2
RRU is 60 m long, and that connecting the
BBU Data src
other RRU is 80 m long.
52M PLL lock:0
(5) After the base station is running
61M PLL lock:0
properly, collect the power-on information
RX RF PLL Freq:17462,lock:0
of each RRU. It is found that the
TX RF PLL Freq:18412, lock:0
transmitted power of the RRU is normal.
TCPW:0.00
And the result of showrru command
TSSI:0.00
indicates that the power amplifier of the
VSWR:0.00
RRU is turned on.
DFL:StartTxFreq:18050
DFL:EndTxFreq:18600
value = 21 = 0x15
(3) Wrong configuration or hardware failure is

supposed to be the cause of the RRU failure.
1) Check that the version of the base station is
Coarse delt 1.37,txatt = 5,

TSSI = 47.86 , TCPW = 48.29
Delt TxAtt Coarse 1.37 ~ 5,
TxAtt = 65tshow
Tx
ATT:6.500000 (dB)
Cp
ATT:2.500000 (dB)
SDR7.00.210.cp22 and the data configuration is
Rx1 ATT:0.0 (dB)
correct.
RX2 ATT:0.0 (dB)
2) The alarm persists after replacing the RRU

and then the BBU in the base station
3)It is doubted that the output voltage of the
RRU is low. Check the output voltage of the RRU
value = 0 = 0x0
DTR->
Fine Adjust Val =
0.15, TSSI
= 47.86, TCPW = 47.71
on field, and it is found that the output voltage is
Fine Adjust I = 85 Q = 85
normal.
TSSI = 47.86, TCPW = 47.74
(4) Check the power cable connected to the
TSSI = 47.86, TCPW = 47.72
RRU. It is found that a four-core power cable is
TSSI, TCPW Check OK.
used. The cross-section area of each core is 1.5
VSWR :
1.40
mm2. Two cores of the power cable are grounded;
VSWR :
1.39
while the other two connected to the RRU. The
VSWR Check OK.
total cross-section area of cores connected to the
Current State = 28 ,
RRU is 3 mm2, which does not comply with the

connection requirements. Replace the power cable
Continuing...
OP begin adapting, State =
GSM BSS Products
19
April 2011
Issue 256
3 Conclusion
116
OP DPD Begin Adapt.
0 Secs
DTR->
replacement of cables delivered by ZTE is not
PA :on
staitc power level:0
work mode :GSM
WCDMA carrier cfg:0
GSM carrier cfg:2
current is 7 A. The RRU transmits the maximum
61M PLL lock:0

RX RF PLL Freq:17462,lock:0
TX RF PLL Freq:18412, lock:0
TCPW:44.38
power during DPD processing, and the power

consumption on the power cable is close to 700 W.
If the power cable is too long and its cross-section
area is small, the voltage of the RRU will be too
TSSI:44.8
low, which results in low transmitted power of the
VSWR:1.10
DFL:StartTxFreq:18050
DFL:EndTxFreq:18600
value = 21 = 0x15
RRU and thus the failure of self-test. In this case,

the RRU does not work and therefore comsumes
litter power because of self-test failure. Due to litter
power consumption, the voltage of the RRU is
DTR->attshow
corresponding specification.
The rate voltage of RRU is -48 V, and the rate
52M PLL lock:0
20
If a replacement is necessary, check and make
4 Additional Information
BBU Data src
Tx
ATT:6.500000 (dB)
Cp
ATT:2.500000 (dB)
value = 0 = 0x0
allowed during the commissioning of base station.

sure that the material to be used meets the
board band :1800M
(dB)
procedure, it can be concluded that the RRU

failure is caused by too thin power cable. Radom
DTR->showrru
Rx1 ATT:0.0 (dB)
From the above analysis and troubleshooting
RX2 ATT:0.0
tested normal.
www.zte.com.cn
Failure of Adding BSCID During CBC

Management Caused by Broadcast
Message Support Not Configured for
a Cell
Meng QingSheng / ZTE Corporation
1 Fault Symptom
1.1 Symptom 1
In an office, the BSC ID of iBSC 501 is modified from 15 to 501. The value range of BSC ID
from 1 to 255 is prompted.
(1) Add the base station, whose basic parameters are displayed in Figure 1, to the list of cells
supporting broadcast messages.
Figure 1. Basic Parameters of Base Station
GSM BSS Products
21
April 2011
Issue 256
(2) The range ([1, 255]) of BSC ID is prompted when the information of the cell is typed, as
shown in Figure 2.
1.2 Symptom 2
Create a broadcast message in a cell as follows, and a failure message is returned.
(1) Refresh the link between the network element management system and the device. A
success message is returned, as shown in Figure 3.
(2) Perform the cell synchronization. A success message is returned, as shown in Figure 4.
(3) Modify the information of broadcast channel, as shown in Figure 5.
(4) Modify the broadcast area, as shown in Figure 6.
(5) Create a broadcast message, as shown in Figure 7.
(6) The message creation fails, as shown in Figure 8.
2 Fault Analysis and Troubleshooting

To create a short message, you need to type the information of the cells in the GS box as
shown in Figure 9 for broadcasting the short message in these cells. The system will synchronize
the information of cells supporting message broadcast and automatically configure a CBC.
To broadcast a short message in a cell, you need to enable the support of cell broadcast when
setting the attributes of the cell. After the configuration of the cell is sent to the BTS, the iBSC
automatically configures a CBC. It is unnecessary to configure a CBC manually.
Figure 2. Value Range of BSC ID
22
www.zte.com.cn
Figure 3. Link Refreshed
Figure 4. Cell Synchronization
GSM BSS Products
23
April 2011
Issue 256
Figure 5. Channel Management
Figure 6. Broadcast Area Management
24
www.zte.com.cn
Figure 7. Create a Message
Figure 8 Message Creation Failed
GSM BSS Products
25
April 2011
Issue 256
Figure 9. Cell Information
Open the CBC Management tab, right-click the Cell node in the resource management pane
and select cell synchronization. Then the system compares the information of selected cells that
support message broadcast with the cells with broadcast function enabled. If the information of a
cell is inconsistent, the message cannot be broadcasted in the cell.
In this case, four broadcast messages are created in CBC Management of the iBSC.
However, it is found that some cells in which the messages shall be broadcasted do not support
cell broadcast, as shown in Figure 10. It is concluded that these cells are improperly configured.
3 Conclusion
During the creation of a short message, it is required to add the information of cells where the
message will be broadcasted. Only when the cells whose information is added are configured to
support the message broadcast, can the created message be successfully broadcasted.
26
www.zte.com.cn
Figure 10. CBC Management
GSM BSS Products
27
April 2011
Issue 256
Failure of Paging Called Mobile Stations

in an iBSC Caused by Limited-Capacity
Paging Channel
Si QinYong / ZTE Corporation
1 Fault Symptom
At one oclock P.M. in an office, it is found that called mobile stations cannot be successfully
paged while the calling mobile stations can be successfully accessed.
2 Fault Analysis
Multiple cells of the iBSC report the CS CCCH overload (18905344) alarm, as listed in Table 1.
Table 1. CS CCCH Overload
28
CELL:3
CS CCCH overload (18905344)
Equipment alarm
IBSC managed element
CELL:3
Equipment alarm
CELL:3
Equipment alarm
CELL:3
Equipment alarm
CELL:3
Equipment alarm
CELL:3
Equipment alarm
CELL:3
Equipment alarm
CELL:3
Equipment alarm
CELL:3
Equipment alarm
CELL:3
Equipment alarm
www.zte.com.cn
Multiple Downlink CCCH Pag load 94 messages are found in the signaling, as shown in Figure 1.
Figure 1. CCCH Overload Signalling
Check the radio parameters, and it is found that the CCCHCONF fields of all cells are set to 1,
and the BSAGBLKRES fields are set to 2, as listed in Table 2.
Table 2. Radio Parameter Configuration
Emergency Call
Admission
EMERGENCYCALL
Access Class
Control
Assembly/
Disassembly
Allowed
ACCESSCONTROL IMSIADALLOWED
CCCH
Configuration
Number of Access
Grant Reserved
Blocks
CCCHCONF
BSAGBLKRES
void
void
void
void
Table 3 explains the meaning of the CCCH_CONF parameter.

Table 3. Meaning of CCCHCONF
CCCHCONF
0
Meaning
A physical channel used by CCCH, which is
not used with SDCCH together.
A physical channel used by CCCH, which is
used with SDCCH together.
Number of CCCH Message Blocks

in a BCCH Multiframe
9
GSM BSS Products
29
April 2011
Issue 256
The Common Control CHannel (CCCH) in a GSM system is shared by Access Grant Channel
(AGCH) and Paging Channel (PCH), which are used to send access grant messages (immediate
assignment messages) and paging messages.
BS_AG_BLK_RES indicates the number of blocks used for AGCH in a 51-frame multiframe.
Table 4 lists the number of CCCH message blocks in each BCCH multiframe (containing 51
frames) in the case of different CCCH configurations. Because the CCCH is shared by AGCH
and PCH, it is required to set how many blocks on the CCCH are reserved for the AGCH. To
inform mobile stations of this configuration information, the system message of each cell contains
a configuration parameter, that is, the number of blocks used for PCH, which is calculated from
CCCH_CONF and BS_AG_BLK_RES.
Table 4. Different CCCH Configurations
CCCH_CONF BS_AG_BLK_RES
Number of Blocks
Reserved for AGCH in
Each BCCH Multifame
Number of Blocks Reserved

for PCH in Each BCCH
Multiframe
9-a
Check the amount of paging in the basic measurement on CS. It is found that the paging
amount increases several times since eleven oclock A.M in Dec. 16.
Table 5. Paging Amount in Basic Measurement on CS
30
C100030137
C100030152 (Number of
(Times of access
Granularity
ABIS_INTER_PAGING_CMD
at paging
message s)
response)
No.
Start Time
End Time
13
2008-12-15
12:00:00
2008-12-15
13:00:00
1 hour
12636
2437605
14
2008-12-15
13:00:00
2008-12-15
14:00:00
1 hour
14245
2760990
15
2008-12-15
14:00:00
2008-12-15
15:00:00
1 hour
15371
2989563
16
2008-12-15
15:00:00
2008-12-15
16:00:00
1 hour
17026
3491855
17
2008-12-15
16:00:00
2008-12-15
17:00:00
1 hour
16174
3113830
www.zte.com.cn
C100030137
(Times of access
Granularity
at paging
message s)
response)
No.
Start Time
End Time
18
2008-12-15
17:00:00
2008-12-15
18:00:00
1 hour
14279
3104946
19
2008-12-15
18:00:00
2008-12-15
19:00:00
1 hour
13511
2853247
20
2008-12-15
19:00:00
2008-12-15
20:00:00
1 hour
9923
1947283
21
2008-12-15
20:00:00
2008-12-15
21:00:00
1 hour
8462
1669305
22
2008-12-15
21:00:00
2008-12-15
22:00:00
1 hour
7440
1467517
23
2008-12-15
22:00:00
2008-12-15
23:00:00
1 hour
5195
1027771
24
2008-12-15
23:00:00
2008-12-16
00:00:00
1 hour
2914
585284
2008-12-16
00:00:00
2008-12-16
01:00:00
1 hour
1705
354864
2008-12-16
01:00:00
2008-12-16
02:00:00
1 hour
856
175599
2008-12-16
02:00:00
2008-12-16
03:00:00
1 hour
574
119308
2008-12-16
03:00:00
2008-12-16
04:00:00
1 hour
484
99398
2008-12-16
2008-12-16
04:00:00
05:00:00
1 hour
417
87144
2008-12-16
05:00:00
2008-12-16
06:00:00
1 hour
660
137161
2008-12-16
06:00:00
2008-12-16
07:00:00
1 hour
2136
414106
2008-12-16
07:00:00
2008-12-16
08:00:00
1 hour
6668
1277515
2008-12-16
08:00:00
2008-12-16
09:00:00
1 hour
13093
2501858
10
2008-12-16
09:00:00
2008-12-16
10:00:00
1 hour
16183
3133126
GSM BSS Products
31
April 2011
Issue 256
C100030137
(Times of access
Granularity
at paging
message s)
response)
No.
Start Time
End Time
11
2008-12-16
10:00:00
2008-12-16
11:00:00
1 hour
16620
3271976
12
2008-12-16
11:00:00
2008-12-16
12:00:00
1 hour
21545
6860060
13
2008-12-16
12:00:00
2008-12-16
13:00:00
1 hour
24882
9818108
14
2008-12-16
13:00:00
2008-12-16
14:00:00
1 hour
25381
11630073
15
2008-12-16
14:00:00
2008-12-16
15:00:00
1 hour
15605
7089722
3 Conclusion
The paging amount quickly increases since the noon in Dec. 16. However, the capacity
configured for PCH in the network is not enough. When the increased paging amount exceeds
the threshold, the CCCH is overloaded, which results in the flow control of paging messages. A
vicious circle is formed due to repeated calling and secondary paging on the switch side. Finally,
the called mobile stations, failing to receive paging messages, cannot be accessed to the network.
To solve this problem, modify the CCCHCONF from 1 to 0, and modify the number of Access
Grant Reserved Blocks to increase the number of blocks for paging messages on the CCCH.
32

Maintenance Experience, Issue256 (GSM BSS Products) - 348966

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Maintenance Experience, Issue256 (GSM BSS Products) - 348966

Transféré par

Droits d'auteur :

Formats disponibles

Preface

In pursuit of the idea First-class service, Customer service,

Maintenance Experience Editorial Committee

Link Establishment Failure Between

During the equipment swap in an SDR

(1) Check each 2M transmission link by

office, the link establishment between the

performing a self-loop test on the corresponding

OMCB and an SDR BS8800 (which uses

2M interface at the iBSC side on the DDF. It is

two transmission links) failed.

found that the 2M link is correctly connected, not

The SDR BS8800 (also called SDR

cross-connected to another BTS. Then connect the

for short) was configured with two E1/T1

2M interface again. The Loss of Trunk Link Signal

transmission links on field, that is, E1/T1

alarm reported by the DTB board in the iBSC

link 0 and E1/T1 link 1 to the BBU.

disappears. From the test, it can be concluded that

incorrect connection of 2M interface on the SA

a link between iBSC and SDR. The

board in another BBU was found. (The cable used

link between iBSC and SDR cannot be

to connect an SA board to a DDF is a 1/2 split

established in the following three situations.

cable supporting eight E1/T1 links (link 0 to 7). At

(1) Physical link failure.

the DDF side, two connectors are available, each

(2) Parameters wrongly-configured in

providing four E1/T1 links (link 0 to 3, and link 4 to

the EMS or OMCB.

Figure 1. iBSC-SDR Link Establishment Flow

(2) In the early phase of the swapping, an

7). If the 1/2 split 2M cable is wrongly connected

as E1/T1 link 0. To check whether the 2M interface

connection between the EUIP interface

of the SA board in this BBU is wrongly connected,

and the OMCR or OMCB server is normal.

perform a self-loop test on the 2M interface at

5) Ping the SDR base station from the

the BBU side on the DDF. A Self-Loop alarm

OMCR or OMCB server. The following

corresponding to E1/T1 link 0 indicates that the 2M

messages are returned, indicating the

cable is correctly connected.

network connection between the SDR

(3) Try to find the broken point by pinging the

base station and the OMCR or OMCB

(1) It is doubted that the broken

2) Ping the interface connected to the OMCB

via an LMT. It is found that the following

or OMCB server. It is found that the network

Unavailable PPP Link Group (PPP ID: 0)

connection between the OMCB server and the IP

Unavailable PPP Link Group (PPP ID: 1)

Abis interface is normal.

SNTP Time Synchronization Failure

4) Ping the EUIP board from the OMCR

(4) Use the LMT to check the E1/T1

or OMCB server. It is found that the network

link status of the BBU. It is found that E1/

GSM BSS Products