Preface Maintenance Experience

Monthly for GSM Products

No.10 Issue 89, February 2008
In this issue of ZTE's "Maintenance Experience", we continue
to pass on various field reports and resolutions gathered by ZTE
Engineers and Technicians from around the world. Maintenance Experience
The content presented in this issue is as below: Editorial Committee
Twenty-four Fault Instances

One Experience Exchange

Director: Zhou Susu
Have you examined your service polices and procedures
Deputy Director: Chen Jianzhou
lately? Are you confident that your people are using all the tools
at their disposal? Are they trained to analyze each issue in a Editor-in-Chief: Wang Dianping
logical manner that provides for less downtime and maximum Editors:
customer service? A close look at the cases reveals how to Jiang Guobing, Zhang Shoukui, Wu Feng, Yuan
isolate suspected faulty or mis-configured equipment, and how to Yufeng, Tang Hongxuan, Chen Huachun, Li
solve a problem step by step, etc. As success in commissioning Gangyi, Gu Yu, Song Jianbo, Tian Jinhua, Du
and service is usually a mix of both discovery and analysis, Jianli, Qu Ruizheng, Zhang Zhongdong, Liu
consider using this type of approach as an example of successful
Xianmin, Wang Zhaozheng, Liu Wenjun, Lei Kun,
troubleshooting investigations.
Wang Tiancheng, Cai Hongming, Wang Yapping
While corporate leaders maintain and grow plans for
expansion, ZTE employees in all regions carry out with individual
efforts towards internationalization of the company. Momentum Technical Senior Editors:
continues to build, in all levels, from office interns to veteran Zhang Niantao, Wu Yongjun
engineers, who work together to bring global focus into their daily
work. Executive Editor:
If you would like to subscribe to this magazine (electronic Li Fenglian
version) or review additional articles and relevant technical
materials concerning ZTE products, please visit the technical
support website of ZTE Corporation (http://ensupport.zte.com.cn).
If you have any ideas and suggestions or want to offer your
Maintenance Experience
contributions, you can contact us at any time via the following
Newsroom
email: doc@zte.com.cn.
Thank you for making ZTE a part of your telecom experience!
Address: ZTE Plaza, Keji Road South, Hi-Tech
Industrial Park, Nanshan District,
Shenzhen, P.R.China
Maintenance Experience Editorial Committee
Postal code: 518057
ZTE Corporation
Contact: Song Chunping
March, 2008
Email: doc@zte.com.cn
Tel: +86-755-26770600,26771195
Fax: +86-755-26772236
Document support mail box: doc@zte.com.cn
Technical support website: http://ensupport.zte.
com.cn
Contents

Fault Instance
Some Pre-Paid Subscribers Could Not Receive Calls 2
Active/Standby Servers of the Database Could Not Connect to Disk Array Simultaneously 3
Trunks between MSCs Were Busy 4
Abnormal SMS of an International Roaming Subscriber 6
Full R_CUG Table Caused Location Update Failure 7
Data Backup Operation on MSC Client Failed 7
Charging Server Switched Off Automatically 8
New Added 156 Number Section Could Not Attach GPRS Network 9
SMS Interconnection Failure 10
SDTB Board Alarm 11
MSC CDR was Lost 11

Long Delay of Short Message 12

Subscribers Failed to Call Some International Subscribers 13
Overstock CDR of Backup MP Caused Fake Alarms 14
MSC Subscribers Could Not Send Short Messages 15
Client Could Not Log in CDR MANAGE 16
Signaling Link Was Disconnected 17
Communication between MSC Foreground and Background Interrupted Instantaneously 18
MO Short Message Success Ratio in Network Declined 19
MSC Could Not Play Tone after the Tone Loading 21
First Paging Duration of One Office Was Short 21
Circuit Blocking Caused Circuit Assignment Failure 22
Call of One Office Dropped Frequently 23
OSB Service under MSC Failed 24

Experience Exchange
MSC Sent Overload Alarm to BSC 27
March 2008 Issue 89 Fault Instance
Some Pre-Paid Subscribers
Could Not Receive Calls
Hao Li, ZTE Corporation
Symptom
One office reported that some pre-
paid subscribers could originate calls, but
these subscribers could not receive calls.
From the SCP side, the engineer found
that the call charging information of these
subscribers were normal.
Analysis
According to the numbers provided by
the carrier, the engineer found that these
numbers belong to the same number
segment. After asking the maintainers of
the carrier, the engineer knew that this
was a new assigned number segment.
Through the preliminary judgment, it was
concluded that the data of the subscriber
segment section was not configured.
 Maintenance Experience
When tracing the MAP signaling on the MSC
side, the engineer found that MSC normally sent
the SRI message to the HLR where the called
party located to get a roaming number. However,
on the HLR side, the engineer did not trace any
information sent from MSC. The signaling routing
of this office was MSC-> STP->HLR, so it is
doubted that the data of these subscribers number
segment is not configured in STP.
Solution
After informing the engineer on STP side
to check the GT data of these subscribers, the
engineer found that the GT data of this number
segment was not configured. After adding the
data of this number segment and performing the
test, the engineer found that the problem was
solved.
 www.zte.com.cn

Active/Standby Servers of the

Database Could Not Connect to
Disk Array Simultaneously
Xu Gaofeng, ZTE Corporation

Symptom state. After the engineer installed the fiber

The engineer found that the HLR173 database card driver on the 174 server again, the
was broken down, and the active/standby server problem still existed.
could not find the disk array (M disk). When 4. After replacing the fiber card on the
checking the servers, the engineer found that server, the problem still existed.
the optical fiber cards at the back of both servers 5. After exchanging the fiber pins on
were abnormal (the yellow alarm indicator was the active/standby servers that were at one
on), and all the services had been switched to end of the disk array, the engineer found
the STANDBY 129 server. The description of the that the communication of the 175 server
indicators is shown in Table 1. was still normal, but the communication of
174 server was still abnormal (the green
Analysis indicator was on and the yellow indicator
1. When opening the CLUSTER interface and was off).
checking the connection of the heartbeat cable, the
engineer found that the SOCKET and the RS232 Solution
connection were normal. The reason of the fault was that the
2. The engineer pulled out and plugged the internal circuit in the active fiber module
fiber pins connecting the active/standby server and
the disk array again. After pulling out the fiber pins Table 1. Indicator Description
connecting the 174 server, the engineer found that
LED Patterns on QLA234x HBA
the 175 server could find the hard disk. However,
Green LED Amber LED Activity
when plugging the fiber pin again, the engineer Off Off Power off
found that both servers were abnormal. On On Power
3. The indicator of the fiber card on the server Off Off Online
was abnormal (the green indicator was on and the On On Link
yellow indicator was off). This phenomenon meant Off Flashing Loss of synchronization
that the link from the server to the disk array was Alternate Flashing Firmware error
established, but it was not in the communication Flashing Off Beacon

GSM Network Products 

March 2008 Issue 89 Fault Instance
of the disk array was short, so that the
active/standby server could not connect
to the disk array at the same time. After
switching the active/standby fiber module
connecting to the back of the disk array,
the problem was solved.
Note: At the back of the EMC disk
Trunks between MSCs Were Busy
Sun Liukui, ZTE Corporation
Symptom
The trunk between MSC-A and
MSC-B was busy, which affected the call
completion ratio.
Analysis
1. After checking the data configuration
and the security variables between
these two MSCs, and comparing these
configurations with other MSCs, the
engineer did not find any problems.
2. When checking and analyzing the
performance data, the engineer found that
the busy ratio of the trunk from the MSC-A
outgoing to MSC-B incoming was very
high. However, the traffic between these
two MSCs was not heavy. It was doubted
that there was something wrong with the
trunk from the MSC-B to another MSC,
Figure 1. Failures (2034=No circuit work (NoCircuitWork))
 Maintenance Experience
array, there are two fiber interface modules. Each
fiber interface module provides two servers with
two sockets. In general, only one fiber module
on the EMC is configured, and the other module
is in the idle state. Before leaving the factory, the
configuration is that only one fiber module can
connect to the server.
so that the call from the MSC-A to the MSC-B was
rejected by the MSC-B.
According to the above judgment, it was
deduced that there was something wrong with
the MSC-B. Maybe the trunk between the MSC-B
and other MSCs was busy. When analyzing the
performance data for each trunk group of the
MSC-B, the engineer found that the busy ratio of
interoffice trunk among all the trunk groups (except
MSC-A (IN)) was normal.
i. Open the failure observation when the trunk
is busy and calculate the call loss data for
5 minutes. On the MSC-A, calculate the
performance data for five minutes and then
calculate the busy times of interoffice trunk to
MSC-B.
ii. Extract the failures (2034=No circuit work
(NoCircuitWork)) from all the call loss data, as
shown in Figure 1.

Figure 2. Failures (2144=No outgoing trunk available
When comparing the number segment
distribution of all office directions for the local
network, the engineer found that the 2034
failures occurred when the MSC-A subscriber
originating calls the MSC-C subscribers. However,
when MSC-A subscriber originated calls to the
subscribers in the MSC-C, the call needed to be
transferred by the MSC-B. Therefore, it was judged
that there was something wrong with the trunk from
the MSC-B to the MSC-C.
3. After checking, the engineer found that
there were only four trunks from the MSC-B to
the MSC-C, and the traffic of each trunk was very
heavy. However, in the performance statistics of the
MSC-B, the trunk busy ratio from the MSC-B to the
MSC-C was very low. After extracting the call loss
data for five minutes when the MSC-B was busy,
the engineer found that there were few failures
(2034=No circuit work (NoCircuitWork)) call losses,
but there were many failures (2144=No outgoing
trunk available (LocalNoCircuitWork)) call losses,
as shown in Figure 2. Almost all 2144 failures were
that the calling MSC-A subscriber failed to originate
calls to the subscribers in the MSC-C.
4. Analyze the calling flow
i. When the MSC-A sent IAM to the MSC-B,
the MSC-B prepared to select the outgoing
trunk when it found that the called number
belonged to the MSC-C. However, the MSC-B
found that there was no available circuit in the
MSC-C, so it sent the rejection message to the
forwarding MSC-A. At that time, the MSC-A and
the MSC-B would calculate the busy times of
the trunk between the exchanges separately
www.zte.com.cn
(LocalNoCircuitWork))
(MSC-A (out), MSC-B (in)).
ii. After the MSC-B found that there was
no available circuit to the backward
MSC-C, it would not send the IAM
message to the backward MSC-C.
Under this condition, the busy times
of the trunk between MSC-B and
the MSC-C would not increase.
At this time, the MSC-B would not
generate the failures (2034=No circuit
w o r k ( N o C i r c u i tWo r k ) ) c a l l l o s s ,
but it would generate the failures
(2144=No outgoing trunk available
(LocalNoCircuitWork)) call loss.
Solution
After adding the inter-office circuit from
the MSC-B to the MSC-C, the engineer
found that the trunk busy ratio was
decreased and the call completion ratio was
increased, that is, the problem was solved.
Summary
When analyzing this kind of problem,
it is required to check to the performance
data first. The engineer needs to extract
the performance data for five minutes and
then check the corresponding failure times.
After that, the engineer needs to export
and extract the call loss data (extract the
top-ten call loss in order to find the reason
from the side) for another five minutes and
then compare the call loss times under
these two conditions.
GSM Network Products 
March 2008 Issue 89 Fault Instance
Abnormal SMS of an International
Roaming Subscriber
Xu Gaofeng, ZTE Corporation
Symptom
One international roaming subscriber
(4200321421XXXXX) 9665411XXXXX
sent 50040 short messages in a day. The
carrier required us to check and confirm
whether there were a lot of Call Detail
Records (CDR).
Analysis
The versions of the on-site MSC1 and
the on-site MSC2 are V3.04.12.B3. When
checking the MSC1 and the MSC2, the
engineer found that the CDR was only
shown in the charging server of the MSC1.
When checking the CDR, the engineer
found that all short message CDRs
generated by this subscriber contained the
field shortMessageFailed(short message
failed!)=1. This field meant that the short
message was not sent successfully, so it
could not be charged.
 Maintenance Experience
===========CDR Field=============
servedFor1stCellIdentity={
MCC=413
MNC=080
Lac=H'000D
CI=H'04A8
}
shortMessageReference=67
shortMessageFailed(short message failed!)=1
shortMessageFailedResult=1
chargedParty=3
exchangedIdentity=ZTEMSC
subScriberCategory=10
transactionIdentification=3
======================================
The engineer tried to find this subscriber
from the VLR in order to check whether the short
message function of this subscriber was enabled,
but the engineer did not find any information about
this subscriber from the MSC1 and the MSC2.
Thereafter, it was confirmed that the subscriber had
left this area. Within a period of time, the engineer
found that this subscriber sent a short message
every 6~8 seconds, and the CDR displayed that the
subscriber was always in the 04A8 cell. Therefore,
it was confirmed that this was an illegal subscriber
who tried to use the unauthorized software to
send the short message, so the sending failure
generated.
Summary
In the CDR record, not all the CDR will be
charged, so it is required to check the detailed
fields in the CDR.
 www.zte.com.cn

Full R_CUG Table Caused

Location Update Failure
Chen Yunlong, ZTE Corporation

Symptom VLR, the engineer found that the table

After a new BSC was cut over, some subscribers
complained that they could not log in the network,
and the location update failed. When tracing the
signaling for all subscribes on the network side, the
engineer found the disconnect message. The failure
reason was 17, system failure.
R_iCUG and the table R_bCUG were full.
Therefore, the subscribers (subscribe
the CUG supplementary service) under
the new cutover BSC failed to update
the location, for the capacity of the table
R_iCUG and the table R_bCUG was full.

Analysis Solution
When analyzing the call loss, the engineer The problem was solved after the
found a lot of 15=Cug Rejected records. After engineer expanded the capacity of the
checking the capacity usage of each table in table related to CUG.

Data Backup Operation

on MSC Client Failed
Chen Yunlong, ZTE Corporation

Symptom
When backing up the basic configuration data
with the BCP method on the client, the warning
unable to open the file appears, as shown in
Figure 1. After clicking the OK, the prompt backup
fail,SQL communication may be interrupted or the
disc id full appears, as shown in Figure 2.

Analysis
1. On the 129 server, the data backup with the
BCP and SQL methods was normal. The above Figure 1. Warning

GSM Network Products 

March 2008 Issue 89 Fault Instance
Figure 2. Info
error prompt meant that the SQL database
failed to connect to the server. However,
the data backup with the method SQL
was normal, which meant that there was
something wrong with the client instead of
the program of the server.
2. After re-installing the version
program of the client on the client, the
engineer found that the problem still
Charging Server Switched Off
Automatically
Huang Wuxiang, ZTE Corporation
Symptom
The charging server of one MSC
switched off automatically.
Analysis
When checking the operating system
log, the dual-computer log, the database
log and the configuration information
about the dual-computer, the engineer
found that there was an unavailable User
resource configuration added in the HA
dual-computer configuration. This resource
configuration depended on the virtual IP
 Maintenance Experience
existed.
3. After checking the data configuration related
to BDE, the engineer did not find any abnormalities.
4. When checking the update about the anti-
virus software, the engineer found that the anti-
virus software had not been updated for three
months. It was doubted that the virus caused the
SQL database failed to connect to the server.
Solution
When updating the virus database on the client
and scanning the disk, the engineer found some
worm virus infections. After deleting this virus and
re-starting the client, the engineer found that the
data backup with the method BCP was normal, that
is, the problem was solved.
address and the disk array (K: \).
From the operating system log, the engineer
found that this resource may cause the disk
array error sometimes, and the dual-computer
server could not read the disk array data, so
the Cluster HA software switched off the server
automatically.
Solution
After deleting the unavailable User resource
configuration from the dual-computer resource and
observing the server for several days, the engineer
did not find this fault again.

New Added 156 Number Section
Could Not Attach GPRS Network
Ren Wei, ZTE Corporation
Symptom
The 156 number section of one office could
not attach the GPRS network, but the service of
the new added 156 number section in the CS was
normal. The subscriber could originate calls and
receive calls.
Analysis
According to the fault symptoms, it is judged
that the reasons are as follows:
1. The data configuration of SGSN is wrong,
including the number analysis and the GT routing.
After checking the analysis configuration data
of the mobile number and the GT configuration
data related to the 156 number section on SGSN,
the engineer did not find any problems.
2. The link between SGSN and the HLR where
the 156 number section belongs to is wrong.
After checking the link from SGSN to HLR, the
engineer found that the link was normal.
3. On the HLR, the configuration of the number
analysis data and the GT routing data are wrong.
When tracing the signaling of the test subscriber
and attaching the test, the engineer found that HLR
had sent the MAP ERROR message to SGSN,
www.zte.com.cn
which meant that the number analysis
data and the GT routing data configuration
of HLR were correct.
4. The GPRS service about 156
number section configured in HLR agent is
wrong.
After opening the failure observation
GSNMAP, the engineer observed the
failure record about the test subscriber.
The failure record is the current receiving
event is 33582=mmMAP_OpenCnfEvent.
After opening the failure observation
GMM, the engineer observed the failure
record Roaming restrict because of
unsupported character about the test
subscriber. From the above, it was judged
that HLR had restricted the roaming
function for the test subscriber, which
caused the attachment of test subscriber
under the local SGSN failed.
Solution
After modifying the subscription
template of 156 number section on the
HLR, the fault disappeared.
GSM Network Products 
March 2008 Issue 89 Fault Instance
SMS Interconnection Failure
Huang Wuxiang, ZTE Corporation
Symptom
The SMS interconnection service was
opened for one office. After configuring
the SMS interconnection service and
performing the sending and receiving test
for the SMS, the engineer found that the
SMS sending operation was normal, but
the receiving operation was abnormal.
Analysis
1. When tracing the signaling MSC
MAP and HLRMAP on the HLR, the
engineer found that when SMC sent the
message mmSendRouteInfoSMReq_M
to the HLR, the HLR sent back a
MAPERROR message. The cause was
17=Absent Subscriber. However, when
being called, the subscriber can receive
10 Maintenance Experience
the calls normally, which meant that this subscriber
was online.
2. When checking the subscriber subscription
information and the dynamic location information
from the agent, the engineer found that the
message Message waiting date flag in the GSM
flag query results of the location information was
located. After the analysis, the engineer found the
fault reason was that the HLR did not receive the
message Ready for SM from the MSC or SGSN
after the location of the handset was updated.
In the GPRS basic information of the
subscriber, the message Message waiting date
flag was deleted after the engineer selected
the MSC for when GRPS does not exist, Ready
for SM is sent by. When tracing the HLRMAP
signaling again, the engineer found that HLR could
return the correct routing information.
After the SMC sent the message
mmFordSMReq to the MSC where the called
subscriber located, MSC sent back the
MAPERROR message. The cause value was
21=Facility not Supported, which meant that
the system did not support the short message.
However, in the function supported by VLR, the
MO short message and MT short message function
were checked.
Solution
After checking and analyzing the configuration,
the engineer found that the option SC
Support under Basic Configuration Local
Configuration Mobile Data Configuration
MORE of MSC was unchecked. After selecting
this option and synchronizing the data, the SMS
function was normal.
 www.zte.com.cn

SDTB Board Alarm

Zhang Zhiping, ZTE Corporation

Symptom i. 1 byte mode: it can be an 8bit random

When the equipment interconnected with
the IBSC SDTB, the SDTB board generated the
following alarms, as shown in Figure 1.
Solution
1. As shown in Figure 1, use the probe to check
code. The default SDTB initialization is
0x01.
ii. G.831 mode: it is frame structure
with 16 bytes, including fifteen ASCII
characters that can be configured at
random.

the four fields in the table R_SDHOPTPARA.

These four fields should be consistent with that
of the wireless side. Otherwise, J0 and J1 will
Figure 1. Alarm Message
generate alarms.
2. In the MSC data configuration, check the
four parameters J0 MODE, Rebirth trace info, Table 1. Fields in R_SDHOPTPARA
J1 MODE and High rank channel trace info Filed Type Instruction
under the directory Module > Unit SDTB > SDH J0 configuration mode. This field is
J0Mode BYTE
consistent with the J0.
OPTPARAMETER. On the network side, the
J0 Char [64] Rebirth trace info
default J0 is 1 byte mode and the J1 is G.831 J1 configuration mode. This field is
J1Mode BYTE[3]
mode. After consisting with the parameters of the consistent with J1

wireless side, the alarm disappears. J1 Char [192] High rank channel trace information

MSC CDR was Lost

Wang Ke, ZTE Corporation

Networking
The charging system of the current network
adopts the call meter mode. The corresponding
principle figure is shown in Figure 1.
The foreground generates the CDRs according
to the following three methods:
i. Back up the CDR to the directory ZXGMPBAK Figure 1. Billing System

GSM Network Products 11

March 2008 Issue 89 Fault Instance
of the charging server in the form of
the original CDR. The extension name
of the file is .zzz.
ii. Back up the coding/decoding GCDR
file to the directory ZXGBILL.
iii. Output the foreground CDR to the
directory SRCBILL through the billout
program. The extension name of the
file under this directory is .jb.
Symptom
Under the directory M: \zxgbil
o f t h e M S C c h a r g i n g s e r v e r, t h e
maintainer found that there was a CDR
file UN200705301039372754GCDR
generated at 11:48, on May 30th. And the
following file was UN2007062317162521
05GCDR, which meant that about twenty-
two days of CDR files were lost.
After connecting the charging server of
ZXJ10 to the MSC system, the maintainer
found that the original CDR generated on
May 30th was 1.112M, and the original
CDR generated on June 23rd was 3.313M.
After the settlement, the maintainer still
Long Delay of Short Message
Wang Ke, ZTE Corporation
Symptom
One office complained that the delay
of the short message was too long.
Sometimes, the delay duration was about
two hours.
Analysis
After performing the corresponding
test, the on-site maintainer found this
12 Maintenance Experience
did not find the CDRs between May 31st and June
22nd.
Analysis
When checking the ZXGMPBAK directory
on the site, the engineer did not find the zzz file
between May 31st and June 22nd. However, under
this directory, the size of the zzz file generated on
June 23rd was bigger than the general size. It was
doubted that the accumulated original CDRs about
these twenty-three days were saved to the CDR
generated on June 23rd after both the foreground
and the background recovered normal.
After copying the zzz CDR file generated on
June 23rd to the directory SRCBILL, automatically
extracting it into the jb file, and distilling ZXJ10,
the engineer found the CDRs beginning from May
31st, which meant that the CDRs were not lost.
Solution
After copying the original CDR zzz file under
the directory ZXGMPBAK, automatically extracting
it into the jb file, and distilling the ZXJ10, the billing
center completed the settlement and the problem
was solved.
symptom, but the delay was about five minutes.
After tracing the message and the call loss, the
maintainer found that SMSC-MT had sent the
routing request, and HLR had also sent back a
message. However, SMSC received a MAPError
message (the message from SMSC to HLR was
transmitted by the MSC).
When opening the failure observation and
checking the call loss from SMSC, the engineer
 www.zte.com.cn

found many HLR session is overtime errors.
According to the performance statistics data of
SMSC, the engineer found that the HLR session
is overtime error was eight times more than before
from July 10.
After asking the maintainers on the short
message side, the engineer found that there was only
one foreground module before, and a new module
was added recently. The new added module was
not used, and was also not connected to the service
processor. However, there was some signaling links
configured between the new added module and the
HLR (four signaling links were added).
On July 9, the maintainer on the short message
side cooperated with the maintainer on
the MSC side and activated the four
new added signaling links. After that, the
signaling from the HLR was sent to the
new module of the short message through
the link. At that time, the communication
between the new module and the old
module was disabled, which caused that
the routing request from SMSC to HLR
failed and the failure times multiplied.
Solution
After blocking the four new added
signaling links, the problem was solved.

Subscribers Failed to Call Some

International Subscribers
Wang Ke, ZTE Corporation

Symptom
For an office with a single MSC, sometimes
the subscribers under the single MSC could get
through the international calls, but sometimes the
subscribers could not get through the international
calls.

Analysis
When the local subscriber dials the international
subscribers, it is required to add the long-distance
access code (2, 5, 7, and 9) before the international
number. However, when adding these four
prefixes, the problem appears. These four prefixes
are configured in the international analyzer entry 4
of the MSC. Except the outgoing routing link, the
configurations of these four prefixes are just the
same. The outgoing routing links are as follows:
1. 2 out route chain 1 our route set 1 Figure 1. Number Analysis Failure

GSM Network Products 13

March 2008 Issue 89 Fault Instance

2. 5 out route chain 1 our route set The local maintainer reported that MSC could
1, 2 not send the IAM message if the call failed, but
3. 7 out route chain 1 our route set MSC could send the IAM message if the call was
1, 2 successful. For the call loss, it was known that the
4. 9 out route chain 1 our route set number analysis failed, as shown in Figure 1.
1, 2 The engineer could pre-analyze the called
When checking the data configuration number through the Preview Digit Analysis
of the MSC (including the trunk group tool in the dynamic management, and then the
configuration and the trunk indicator engineer could find the correct outgoing routing
configuration), the engineer did not found link, as shown in Figure 2.Through the analysis,
any abnormalities. It was doubted that the the engineer found that the call failed if the called
international gateway exchange failed to number was 002160XXXXXXX. As shown in
analyze the called number. Figure 2, the value of Toll Prefix+Area Length is 5,
that is, the toll prefix and the area length is 5. The
following numbers are the SN. However, the sixth
bit of the called number 002160XXXXXXX is 0,
which causes the number analysis failure.

Solution
After modifying the value of Toll Prefix+Area
Length as 3, the engineer found that the problem
Figure 2. Digit Analysis Preview was solved when performing the on-site test.

Overstock CDR of Backup MP

Caused Fake Alarms
Wang Ke, ZTE Corporation

Symptom this module. When checking the alarm history, the

The alarm of the slave MP in the
module 9 of MSC was OVERSTOCK
CDR ALARM, but the engineer did not
find any overstock CDRs under the BILL
directory through the file manager.
Analysis
When checking the operating log, the
engineer did not find any operations on
engineer also did not find any link broken alarms
between the charging server and the foreground. It
was doubted that the abnormal running of the slave
MP caused this alarm.
Solution
After resetting the MP of the module 9 of MSC
for two times, the CDR alarm disappears and the
test of the service is normal.

14 Maintenance Experience
 www.zte.com.cn

MSC Subscribers Could

Not Send Short Messages
Wang Ke, ZTE Corporation

Symptom short message.

The on-site maintainer reported that some After checking, the engineer found that
subscribers could not send the short message for the Roamingflag value of the subscriber
these few days, and the handset displayed that this who cannot send the short message was 2.
service was restricted. However, these subscribers Under the normal condition, the Roamflag
could make calls and receive the short message. value of the local subscriber should be 1
(national roaming).
Analysis 5. When checking the Configuration
1. When tracing the BSSAP and the MSCMAP
message for the subscribers who had the abnormal
phenomena, the engineer found that MSCMAP
could not trace the message sent to SMSC. The
message traced from the A-interface was shown in
Figure 1.
From the message content, it was known that
MSC had sent a message mcaRPMT_ERROR_M
to the handset side, and the cause value was 10,
as shown in Figure 2. The cause value 10 of the
RP Error meant call barred (call restriction).
2. The engineer checked the call loss when
the short message was sent unsuccessfully. Then,
the engineer found that the call loss reported call
barred, Failure Cause=13=Call Barred, Failure
Figure 1. Message Traced From A-interface
Origin=MAP.
3. The engineer checked the field BAOC
(Barring of All Outgoing Calls) from the table
BasicSS with the VLR probe and found that the
value was 0, which meant that the service was not
restricted.
4. The engineer checked the value of Roamflag
from the table MSFLAG with the VLR probe and
found that the value was 2 (international roaming).
There was a switch inside the system, which was
used to set the international roaming. In general,
the international number is not allowed to send the Figure 2. mcaRPMT_ERROR_M Message

GSM Network Products 15

March 2008 Issue 89 Fault Instance
Management > Mobile Number Analysis
> Number Roaming Analysis of MSC,
the engineer found that the IMSI prefix
of the local subscriber was also set as 6
(international roaming).
Note: In the configuration of the
number roaming analysis, there are three
configuration options: no-roaming, national
roaming and international roaming. In
general, the option is set as no-roaming or
international roaming. If this option is not
configured, the default value is national
roaming.
6. When checking the operating log of
MSC, the engineer found that someone
had modified the configuration about the
roaming number analysis on September
14 and September 16. The operating log is
as follows:
==========Operating Log===========
2007-09-14 12:40:02 Configuration
Management NADINE The onsite maintainer should follow the
203 M o b i l e D i g i t A n a l y s i s : a d d
roaming default analysis record( file:C:\
Client Could Not Log
in CDR MANAGE
Xu Gaofeng, ZTE Corporation
Symptom
After the version update, the client
could not log in CDR MANAGE. The
prompt alarm was Can not find user from
server, please login again.
Analysis and Solution
1. Because of the version update, it is
16 Maintenance Experience
zxg10\MDNAL.ini)
2007-09-16 12:15:31 C o n f i g u r a t i o n
Management NADINE
203 Mobile Digit Analysis: add roaming default
analysis record( file:C:\zxg10\MDNAL.ini)
======================================
Solution
Modify the value 6 in the configuration of the
roaming number analysis as national roaming, and
delete the test subscriber from the VLR. When the
subscriber updates the location again, it is required
to check whether the value of Roamflag is 1. After
modifying the configuration, the subscriber could
send the short message.
For all other subscribes who cannot send the
short message, it is required to set the subscriber
in the VLR as Unreliable or reset the MP for two
times to solve the problem.
Summary
engineering operation criterion strictly in order to
avoid the artificial fault.
doubted that the OMC software installation of the
client is wrong. After installing the OMC software
again, the problem still existed.
2. After checking the connection between
the 129 server and the 130 charging server, the
engineer found that the ZTE communication
system displayed that the connection was normal.
And the engineer could successfully ping the

charging server.
3. After checking the subscriber authority and
logging in CDR MANAGE with the super user
ZXG10, the engineer found that it was also enable
to log in CDR MANAGE.
4. The engineer found that it was allowed to log
in CDR MANAGE on the 130 server, so it meant
that there was nothing wrong with the 130 server.
5. After restarting the server of which the node
number was 200, the engineer found that the
problem still existed.
Signaling Link Disconnected
Chen Yunlong, ZTE Corporation
Symptom
When ZTE MSC interconnects with the MSC
of other manufacturer, the E1 indicator on the
DTI board flashes after the physical hardware
connection, but the signaling link is disconnected.
Analysis and Solution
1. After checking the link code, the time
slot, the transmission system No. of the local
office and the peer end office, and the related
physical configuration, the engineer found that all
configurations were consistent.
2. After checking the interface impedance of
Russia, the engineer found that the impedance was
120 , which meant that there was nothing wrong
with the impedance.
3. The version of the DTI board was consistent
with the version of other offices.
4. When tracing the bottom signaling of MTP,
the engineer found that the peer end had sent
the SLTM message to ZTE MSC, and the ZTE
www.zte.com.cn
6. When checking the ini file under the
directory c:\zxg10\, the engineer found that
the line Normalpath= contained in the file
querycfg.ini. At this time, it was required to
input \\194.240.1.130\zxgbil.
Summary
Before the update, it is required to
record the equipment status (such as, the
client use, E1 and the circuit use) for the
further checking.
MSC had sent back the SLTA message.
However, the peer end did not send
back the SLTA message or the Discard
message after ZTE MSC sent the SLTM
message. It was judged that there was
something wrong with the peer MSC.
However, the interconnection between the
peer MSC and the current running MSC
was normal.
5. Through the analysis, it was doubted
that there was something wrong with
the physical connection (including the
hardware connection and the physical data
configuration of the background). When
observing the E1 indicator on the DTI
board, the engineer found that the flash
frequency of the indicator was wrong. The
indicator was off once in a while, which
meant that the physical connection was
disconnected.
In general, there are two reasons for the
GSM Network Products 17
March 2008 Issue 89 Fault Instance
disconnected physical interconnection: the
E1 connection is wrong or the physical data
configuration of the DTI board is wrong.
After eliminating the first reason,
the engineer checked the physical data
configuration about the interface board
with the peer end again. After coordinating
with the peer end office and changing the
option of the physical configuration CRC
Verification from CRC (only for ESF) to
NO CRC (only for ESF), the engineer
found that the E1 running indicator flashed
frequently and run normally. And the
Communication between MSC
Foreground and Background
Interrupted Instantaneously
Sun Liukui, ZTE Corporation
Symptom
One customer reported that the level-1
alarm indicator on the alarm box had
flashed frequently. After checking the
alarm, the engineer found that there were
some communication interruption alarms
between the foreground module and the
129 server two days before, and most
alarms recovered in one minute.
Analysis
1. After checking the alarm history, the
engineer found that the alarm frequency
increased day by day.
2. Check the connection of Lanswitch
18 Maintenance Experience
interconnection of the signaling link was normal.
Summary
1. When interconnecting with the equipment
of other manufacturers, it is not only required to
check whether the option CRC Verification of
the physical configuration is consistent, but also
required to select NO CRC (only for ESF) for this
option in order to match it.
2. After the physical connection, it is not only
required to check whether the E1 indicator on
the DTI board flashes, but also required to check
whether the flash frequency is equal.
network cable and insert the loose network cable
again.
3. The main board is changed after the 129
server is modified, so it is doubted that there is
some hardware problem.
4. After installing the main board driver and the
network card driver of the 129 server again, and
restarting the 129 server, the engineer found that
the alarm still existed.
5. When pinging the active/standby MP of each
foreground on the 129 server for a long time, the
engineer did not find any packet loss. It meant
that there was nothing wrong with the hardware
of the 129 server and the network between the
foreground and the background.
 www.zte.com.cn

6. When checking the watchdog log and the
system log on the 129 server, the engineer did not
find any abnormalities. However, there were many
SQL errors in the application program log of the
129 server.
7. When checking the SQL log, the engineer
found many Data table cannot be written
error logs. It was doubted that the table space
of some SQL data was full, which caused the
communication between the foreground and the
background interrupted.
8. When checking all the SQL databases, the
engineer found that the available space was low. After
deleting some alarms and prompts manually
and expanding another 300 M space for the
alarm database, the engineer found that this
alarm disappeared immediately.
Summary
During the daily maintenance, it is
required to check the databases of which
the space is lack or low. When the data
cannot be written into the database
because of low space, the communication
abnormal alarm of the 129 server and the
foreground will generate.

MO Short Message Success

Ratio in Network Declined
Sun Liukui, ZTE Corporation

Symptom Through the checking the MO flow,

In one office, the success ratio of MO short the engineer found that the cause value of
message declined obviously. One carrier reported many call loss was 32. When checking the
that the success ratio of MO short message was statistics data on the IN side, the engineer
90% in last August, and it was only 20% now. found that the MO flow failed when the
The success ratio of MT short message was high. 9233960XXXXX subscriber was the
When checking the performance statistic data for called party. The engineer also found the
the current month, the engineer found that success
ratio of MO short message was very low. Table 1. Performance Statistics Data
Time MO Success Ratio MT Success Ratio
Analysis and Solution 2007-9-3 19:00 59.62 95.56
1. Check the performance statistic data, as 2007-9-4 19:00 57.65 95.22
shown in Table 1. 2007-9-5 19:00 57.9 94.89
From the above table 1, through it only displays 2007-9-6 19:00 60.21 95.26
the statistics data of one month, it is clearly shown 2007-9-2919:00 47.34 95.75
that the success ratio of MO short message is very 2007-9-30 19:00 45.86 95.54
low, and the success ratio declines continuously. 2007-10-1 19:00 46.61 95.53

2. Trace the signaling and check the call loss. 2007-10-2 19:00 45.96 95.4

GSM Network Products 19

March 2008 Issue 89 Fault Instance
corresponding called numbers from the
signaling tracing.
Many subscribers send the short
message to this number (this number
NDC 339 does not belong to any carrier),
so the success ratio of MO declined. It is
doubted that this is an illegal behavior of
the subscribers.
3. According to the CDR of the current
two days in the short message center, sort
all the calling numbers (456 in total) that
send the short message to the subscriber
33960XXXXX, and then query and analyze
the calling numbers.
i. According to the number section
analysis, the engineer found that 305
numbers (67%) belong to the area-A.
And the engineer knew that there were
two BSCs in the area A : B92 and
B91, and a new BSC B90 was added
recently.
ii. When querying these numbers in the
VLR of area-A, the engineer found
the related information of these 304
subscribers (67%).
iii. After recording the location information
of the numbers that can be found from
the VLR of area-A, the engineer found
20 Maintenance Experience
that the location area was very concentrated,
but the cell ID was very dispersive, and there
was no regularity.
iv. A f t e r s o r t i n g 5 5 s u b s c r i b e r s f r o m 3 0 4
subscribers in the next day, the engineer
found that one subscriber was switched on,
the information of four subscribes was deleted
from the VLR, the LAC of three subscribes
were changed, and the GCI of twenty-two
subscribers were changed.
4. Through cracking the content of the short
message, it is doubted that there is some evil
virus in the handset terminal. After the analysis,
the engineer found that this was really a kind
of handset virus. The subscriber sent the short
message to the number 9233960XXXXX every five
minutes when they knew nothing about the virus.
5. The subscriber needs to delete the virus from
the handset terminal.
i. Install the file manager on the handset.
ii. Find the directory \system\apps\commwarrior
from the handset and then delete the files
commwarrior.exe and commrec.md.
iii. Enter the directory \system\updates\commwarrior
and then delete the files commwarrior.exe,
commrec.mdl and commw.sis.
iv. Enter the directory \system\recogs and then
delete the file \system\recogs.

MSC Could Not Play Tone after
the Tone Loading
Chen Yunlong, ZTE Corporation
Symptom
MSC could not play tones after the tone loading.
Analysis and Solution
1. After running the tone script, the engineer
synchronized the changed tables to the foreground.
At that time, there was a successful prompt.
When checking the tone table R_TONLST of the
foreground MSC with the probe, the engineer did
not find any data display. However, there was
some data in the table r_tonelist of the background
zdb_zxj10 database, which meant that the data
between the foreground and the background was
inconsistent or the data synchronization of the
foreground was wrong.
2. The version of the tone flash file and the
script was different from the version of other items.
The only difference was that the version of the on-
site running software was inconsistent.
First Paging Duration of One
Office Was Short
Chen Yu, ZTE Corporation
Symptom
One office had opened two pagings. The
duration of the 1st paging was 3 seconds, and
the duration of the 2nd paging was 7 seconds.
The carrier thought that the duration of the 1st
paging was too short, which would increase the
unreachable ratio of the paging. It was required
www.zte.com.cn
3. The play tone was normal after it
was recovered to the original tone.
4. After updating the MSC from the
V3.03.211.a to the V3.04.12.P3.B1,
loading the same tone flash file, and
running the same script, the engineer
found that the play tone became normal.
Summary
There are many differences between
the V3.03 and the V3.04 of MSC. Under
the V3.03, it is not allowed to use the flash
file and the tone script of the V3.04. The
engineer can make the corresponding
judgment through checking the data
consistent between the foreground MSC
tone table R_TONLST and the background
r_tonelist table.
to set the duration of the 1st paging as
6 seconds, and the duration of the 2nd
paging as 7 seconds.
Analysis
TFor the Waiting paging response,
the default total duration the is 10s.
GSM Network Products 21
March 2008 Issue 89 Fault Instance
This duration can be adjusted through
modifying the 15# timer and the 162#
timer.
Total duration of the paging response
waiting = min (T15, T162), which means
that the total duration is the minimum
value of these two timers. It is required to
modify the duration of these two timers as
13 seconds according to the requirement
of the carrier.
At that time, the on-site version was
MSC V3.04.12.P11.B1a. The fixed duration
of the 1st paging and the 2nd paging
was 3 seconds. The carrier required to
set the duration of the 1st paging as 6
seconds, so it was required to update the
foreground version to V3.04.12.P11.B1c.
Circuit Blocking Caused
Circuit Assignment Failure
Chen Yu, ZTE Corporation
Symptom
The MSC interconnected with the
BSC. When performing the call test after
the link was connected, the engineer
found that the peer end sent back the
BLOCK message after the MSC sent the
assignment request to the wireless side.
Analysis and Solution
1. When checking the circuit from the
BSC side, the engineer found that the
circuit was in the Dead status, and it
could not be activated. It was doubted that
the phenomenon was caused by the reset
message sent by MSC, so MSC needed to
send the reset message again.
22 Maintenance Experience
This version could be used to adjust the duration of
the paging. At that time, the timer was 169.
After updating the version, it is required to
modify the above three timers (15#, 162# and
169#) and then perform the corresponding test.
Solution
1. When adjusting the timer, it is required to
adjust the timers of all the modules. After the
adjustment, it is required to check whether this
adjustment operation takes effect.
2. It is not recommended to set a long duration
for the Waiting paging response duration timer.
For example, if it is set as 15 seconds, maybe the
MSC could not play tone to the calling party. A long
paging duration is also a waste of the resource, so
the duration should be within 13 seconds.
2. Under the Dynamic Data Management > A
Interface Circuit Management, block and unblock
the circuit.
After blocking and unblocking the circuit, the
signaling (select BSSMAP message) was displayed
on the A-interface tracing.
3. When checking the circuit status from the
BSC side, the engineer found that the dial test was
normal, and the problem was solved.
Summary
This problem cannot be solved by plugging/
unplugging the board. When plugging/unplugging
the board, MSC will not send the Block or the
Unblock message to the BSC side, so the peer end
will be on the Dead status all the time.
 www.zte.com.cn

Call of One Office Dropped

Frequently
Hao Li, ZTE Corporation

Symptom D1xxx: the first COMM board

In one MSC, the call drop phenomenon
was frequent. The call between the intra-office
subscribes and the outgoing calls of the local
subscribers had the call drop fault.
Analysis
1. When tracing the interoffice ISUP message,
the engineer found that MSC sent REL message
after the call was connected for server seconds or
dozens of seconds, and this call was released at
the same time. The reason of the call release was
the network is unavailable or abnormal and the
resource is unavailable.
2. When checking the level-1 to level-3 alarms,
the engineer found that the active/standby MP
switched frequently. When checking the error. log
of MP, the engineer found that only the continuous
DAxxx: the tenth COMM board
DBxxx: the eleventh COMM board
DCxxx: the twelfth COMM board
DDxxx: the thirteenth COMM board
DExxx: the fourteenth MONI board
The message Status check
notification means that the bus check
is wrong. It is doubted that there is
something wrong with the MONI board.
Solution
After plugging/unplugging the MONI
board, both MPs worked normally. When
performing the call tracing, the subscriber
did not find any call drop phenomenon and
the MP did not switch frequently again.
The problem was solved.

switch information about MP was recorded. The

MP belongs to PIII, so it is confirmed that the MP
switch was not caused by the INT13 interruption.
3. After plugging/unplugging and replacing the
SMEM board, the problem still existed. In order to
decrease the affect, it was required to power off
one of the MP for a while. After that, the call drop
phenomenon disappeared.
4. After analyzing the alarm log further, the
engineer found many Status check notification
notification messages and address=DEFFE.
In the control shelf, MP communicates with
other boards in this shelf through different bus
addresses. The corresponding addresses of
different boards are as follows:
D0xxx: SMEM board

GSM Network Products 23

March 2008 Issue 89 Fault Instance
OSB Service under MSC Failed
Wang Ke, ZTE Corporation
Symptom
At present, the subscriber under the
local MSC dials the long-distance mobile
subscriber or the PSTN subscriber with
the following format 0+ (3, 5, 7 or 9) +
area code + number. When dialing the
local subscriber, it is only required to dial
seven digits directly, such as 2XXXXXX,
3XXXXXX, 4XXXXXXX and 8XXXXXX.
The carrier should subscribe the
long-distance restriction service for the
subscriber. On the site, the OSB method
was adopted. On the HLR, it was required
to subscriber the OSB service for the
subscriber. Under the Mobile Number
Analysis Configuration > ODB and OSB
Service Call Restriction Number of MSC,
the four long-distance prefixes 03, 05, 07
and 09 are configured. In fact, the long-
distance calls were not restricted, but the
local call of which the prefixes are 3, 5 and
7 are restricted.
24 Maintenance Experience
Analysis
When checking the number analysis
configuration of the MSC, the engineer found that
both the pre-analysis selector and the MO analysis
selector had used the DAS101. In the DAS101,
the digit diversion (calling) operation was not
done for the prefixes 03, 05, 07 and 09. All these
indicated that the number format sent by CC to
VLRMAP was just the 03XXXXX format dialed by
the subscriber. Furthermore, VLRMAP has deleted
the digit 0, so it was not matched with the number
in the list of OSB service restriction.
According to the normal requirement of OSB
service, the format sent to VLRMAP by CC should
be CC+ area code + number. MSC needed to dial
these prefixes, so the following schemes were
given:
1. Under the ODB and OSB service
configuration of MSC, restrict the prefixes 03, 05,
07 and 09.
2. In the pre-analysis, add an analyzer entry
and then analyze the numbers of which the
 www.zte.com.cn

beginning numbers are 03, 05, 07 and 09. Add

00 before these prefixes. After that, the numbers
are changed to 0003, 0005, 0007 and 0009. The
attribute is Unknown.
3. Under the international analyzer entry of the
MO number analysis selector, analyze the number
of which the beginning numbers are 03, 05, 07
and 09. Delete the first two digits 00 and select
Unknown for the Attribute.
This scheme aims at the subscribers who
subscribed the OSB service. Perform the digit
diversion (calling) operation through the pre-
analysis. Before the format of the number sent by
Figure 1. Supported Service Option Configuration
CC t o VLRMAP, two digits 00 are added. After
VLRMPA deleted the prefix 00, the number will be
matched with the prefixes 03, 05, 07 and 09 in the
OSB restriction list. After the above operation, the
long-distance function is restricted.
For the subscribers who do not subscribe the
OSB service, it is also required to perform the
above pre-analysis flow when dialing these long-
distance prefixes. However, after VLRMAP receives
the number format, such as 0003, sent from CC,
it will analyze the outgoing of the 0003 format in
the MT number analysis selector according to
the normal flow if the calling subscriber does not
subscribe the OSB service. So, it is required to
Figure 2. PLMN Specific ODB Configuration
configure the prefixes 03, 05, 07 and 09 in the
international analyzer entry and specify them to the
corresponding outgoing route links.

Solution
1. Under the Configuration Management >
Supported Service Option Configuration of HLR,
check the checkbox Support OSB Service, as shown
in Figure 1.
2. Under the Configuration Management
> PLMN Specific ODB Configuration of HLR,
configure the self-defined OSB service, as shown
in Figure 2.
3. Subscribe the OSB service for the subscriber
in the HLR agent, as shown in Figure 3. Figure 3. ZXG10-MSS Agent System

GSM Network Products 25

March 2008 Issue 89 Fault Instance

4. Under the Mobile Digit Analysis >

ODB&OSB Service Configuration, configure the
restricted digits.
5. Under Security Management > VLR
Security Variables, set 2 for Selecting of Call
Barring Pattern.
6. In DAS101, add Called New Service Analyzer
Entry 1, as shown in Figure 4. In this analyzer,
add and configure 03, 05, 07 and 09, perform the
digit diversion operation for these prefixes, add
00 before the number, and select Unkonwn for
Diverted Area Attribute, as shown in Figure 5.
Figure 4. Digit Analysis Selector-DAS101 7. In the international analyzer entry 4 of
DAS101, add and configure 03, 05, 07 and 09,
perform the Digit Diversion ID (Called) for these
prefixes, delete the first two digits 00, and ensure
that the format of the number in the outgoing IAM
message is 03XXXXX, as shown in Figure 6.
After that, all the data modification is completed.
At this time, the long-distance restriction service is
normal.

Figure 5. Digit Diversion (Calling)

Figure 6. Digit Diversion of Called Party

26 Maintenance Experience
Experience Exchange www.zte.com.cn

MSC Sent Overload Alarm to BSC

Chen Yu, ZTE Corporation

On the site, MSC sent the Overload alarm to The information related to the data
BSC for many times. The reasons of the alarm are area is not shown in the performance
as follows: the CPU is overloaded, the value of UB s t a t i s t i c s . H o w e v e r, y o u c a n
increases in an instant, the occupation rate of the dynamically check the occupancy rate
data area is very high or the data area is overload. of the data area of each processing
1. When MSC sends Overload to BSC, layer (such as MM, MAP and CC)
it follows some rules. The flow control has a according to the service observation.
relationship with the CPU, the UB and the data ii. Set the flow control level of UB, as
area. The level setting of each kind of flow control shown in Figure 1.
is shown in Table 1. In general, the usage rate of the
2. Set the flow control in the MSC Security memory is not very high, but the value
Variable.
i. Set the level of the CPU and the data area. Table 1. Flow Control Index
The high CPU occupancy rate means that Flow Control\ Level 6 5 4 3 2 1
the events processing frequency is very high. CPU Load control 60 64 68 72 76 80
When the occupancy rate of the CPU reaches UB max rate control 60 64 68 72 76 100
100%, the MP will be in an endless-loop status, Used Index control - - 2670 2730 2790 2850

so the level-1 flow control should be within

85%. At this time, you can check the CPU load
alarm from the alarm management, and you
can check the detailed load threshold of the
CPU from the performance statistics.
The maximum of the data area is 3000. The
four default levels of the data area cannot be
modified. In the alarm, it may display that the
data area is short or the data area has alarms. Figure 1. Security Variable Flow Control Level of UB

GSM Network Products 27

March 2008 Issue 89 Experience Exchange

Table 2. Flow Control Index performance statistics. In general, the memory

Service\Level 6 5 4 3 2 1 usage rate can reach 80%, but it can recover in
Supplementary Service 3 0 0 0 0 0 a short time.
Calling Service 12 9 6 3 3 3 iii. Under the Security Variable> Service Control
Short Message Service 12 9 6 3 2 1 Variable of MSC, set the flow control for each
Location Update Service 12 12 9 8 6 3 service according to all the levels.
Handover Service 12 9 6 3 0 0 For the service with the level within
Note: the flow control is within 0~ 12. 0: All services are controlled,12:
2~6, you can adjust the flow control, but the
no service is controlled
adjustment range should be very narrow. It is
not recommended to modify the flow control
Table 3. System Alarm Level-Alarm Level Table of MM Data Area
parameter of the level 1 service.
Alarm level of MM
data area 0 1 2 3 4 3. MSC sends Overload to BSC
System alarm level
If the value is not 0, MSC will send the Overload
0 0 5 6 0 0
to BSC, as shown in Table 3.
1 1 1 1 1 1
The system alarm level is the maximum of the
2 2 1 1 1 1
3 3 1 1 2 2
CPU occupancy and the UB occupancy. (1

4 4 1 2 2 3 means the highest level, 6 means the lowest

5 5 4 4 4 5
6 6 5 5 6 6
of UB may increase in instantly. The
possible reason is that the partial
variable value is very high during the
message processing or the message is
piled up abnormally, so the temporary
memory increases consequentially. The
level setting of the corresponding flow
control also follows the default setting,
and the level cannot be modified.
The corresponding information can
be displayed in the alarm and the
level, and 0 means there is no alarm).
The alarm level of MM data area refers to the
restriction level of Index usage rate in the
variable of A-interface.
When MSC sends the Overload to BSC, you
can check the Overload alarm of the corresponding
level from MSC. For the detailed flow control, it also
depends on the flow control setting of the CPU, the
UB and the data area for different services under
different levels.
The purpose of MSC sending Overload is to
safeguard its system, and this mechanism meets
the protocol criterion of ITUT. It is helpful to the
maintenance work if the maintainer knows the
processing mechanism of MSC.

28 Maintenance Experience
March 2008 Issue 89 Fault Instance

30 Maintenance Experience