Preface

In this issue of ZTE's "Maintenance Experience", we continue to pass

on various field reports and resolutions gathered by ZTE Engineers and Maintenance Experience
Technicians from around the world. Editorial Committee
The content presented in this issue is as below:
32 fault instances
Director: Zhou Susu
8 frequently asked questions (FAQs)
Have you examined your service polices and procedures lately? Are Deputy Director: Chen Jianzhou
you confident that your people are using all the tools at their disposal? Are
they trained to analyze each issue in a logical manner that provides for Editor-in-Chief: Yang Cheng

less downtime and maximum customer service? A close look at the cases
Editors:
reveals how to isolate suspected faulty or mis-configured equipment, and
Jiang Guobing, Wang Yaping, Ba Zexue,
how to solve a problem step by step, etc. As success in commissioning
Zhang Shoukui, Wu Feng, Yuan Yufeng, Tang
and service is usually a mix of both discovery and analysis, consider
Hongxuan, Chen Huachun, Ding Guixiang,
using this type of approach as an example of successful troubleshooting Gu Yu, Tian Jinhua, Zhu Wensheng, Ling
investigations. Changwen, Zhang Zhongdong, Liu Xianmin,
While corporate leaders maintain and grow plans for expansion, Wa n g Z h a o z h e n g , C h e n Ta i m i n g , Z h a n g
ZTE employees in all regions carry out with individual efforts towards Mingjing, Wang Haidong, Chen Le, Lei Kun,
internationalization of the company. Momentum continues to build, in Wang Tiancheng, Zheng Hongliang, Wang Tao
all levels, from office interns to veteran engineers, who work together to
Technical Senior Editors:
bring global focus into their daily work.
Zhang Niantao, Wu Yongjun
If you would like to subscribe to this magazine (electronic version) or
review additional articles and relevant technical materials concerning ZTE Executive Editors:
products, please visit the technical support website of ZTE Corporation Li Fenglian, Zhang Jinbao
(http://support.zte.com.cn).
If you have any ideas and suggestions or want to offer your
contributions, you can contact us at any time via the following email:
doc@zte.com.cn. Maintenance Experience
Thank you for making ZTE a part of your telecom experience! Newsroom

Maintenance Experience Editorial Committee

ZTE Corporation Address: ZTE Plaza, Keji Road South, Hi-Tech
August, 2007 Industrial Park, Nanshan District,

Shenzhen, P.R.China

Postal code: 518057

Contact: Song Chunping

Email: doc@zte.com.cn

Tel: +86-755-26770600,26771195

Fax: +86-755-26772236
Contents

Fault Instances

Service Interruption between One MSC and One BSC 3

Area Restriction Service Failure under One MSC 4
Signaling Link between MSC and HLR Intermittently Disconnected 5
Switching System Access Success Ratio in MSC Exceeded 100% 8
In the Performance Statistics, the Number of Call Attempts in Office Traffic Was Inconsistent
with that in Circuit Group Traffic 9
Failed to Set PDP Contexts on the HLR Agent in Batches 11
Lots of 166 Failure Causes Occurred in SMSC 12
Low System Access Success Ratio 15
Failure of Independent IP Tone Playing 17
Failed to Send Paged SM 18
Ineffective Special Number 19
Handling the Database Space Alarm from Performance Statistics 20
Handling the Fault of Having GateOut CDR without MO CDR 21
Handling the Fault of R2 Incoming Call after Call Number Upgrade 22
The number of current subscribers in HLR was inconsistent with the number of actual subscribers 23
Some of Intelligent Subscribers Failed to Roam within a Province, or in Another Province or country 24
Configuration of IMSI Number Analysis 26
Some Subscribers Couldnt be Registered in Network after the Cell Restriction Service Is added in HLR 27
Failure to Login Remote HLR Agent 28
HLR Agent Startup Error When Configuring Data 29
Failure in Backing up HLRDB onto Node 129 31
HLR MAP Process Repeatedly Restarting 32
Failure in HLR Setting PDP Contexts in Batches 33
CUG users Unable to Update Location under ZTE MSC 33
Subscriber Couldnt Access the Network After HLR Cutover 35
August 2007 Issue 52 Fault Instances

Contents

Illegible Codes Appears When the Network Management Client Runs HLR Configuration Management 36
Unsuccessful Cross Number Assignment on the two HLR Databases 36
Subscribers Could not Modify Access Mode in HLR 37
VPN Subscribers Could not be the Calling Party When Roaming 38
Echo Appearing for Outgoing Calls 39
Unsuccessful Location Update for Roaming 39
Difficulty in Making Calls at Busy Hours Under an HLR 40
HLR System Error Occurred in Service Subscription on Agent 40

FAQ

How to Analyze the Location Update Faults 42

How to Handle Unclear Blocked Signaling Links 42
How to Set the Dual Seizure Handling Mode 43
How to Transfer the Database 43
How to Recover the Database in the Suspect Status 44

 Maintenance Experience
Fault Instances www.zte.com.cn

Service Interruption between

One MSC and One BSC
Wang Ke, ZTE Corporation

Symptom
The HW BSC under one MSC2 suddenly
suffered from service failure. The MSC could
receive messages, but failed to send messages.

Analysis
After checking the configuration data at the
MSC side, the engineer found that the arrangement
modes of the SLS in the route chain configuration
from the MSC to other offices were all automatic
arrangement mode, while that configured in the
HW BSC office was manual arrangement mode.
When the fault occurred, the statuses of office
directions and links in the foreground tables
R_Office and R_N7link were normal. One of route
arrangement modes in R_DRout was 0. In normal
situation, no arrangement mode in R_DRout should it was known that the security variable
be 0. in the MSC was 1, and there were 0
If manual arrangement mode is adopted for links. Therefore, the MSC failed to send
the SLS arrangement mode, deleting one link messages.
will cause the 0 link with errors existing in the
dynamic route table. When the office-related or Solution
link-related data are synchronized, or all the tables The problem was solved after the
are transferred, MTP3 will refresh the dynamic engineer changed the SLS arrangement
route table again, and the DB of the module 2 will mode in the HW BSC office to automatic
be synchronized to other modules. arrangement mode, and synchronized the
In the MSC security variable configuration, the data.
default value of Local module preferred during NOTE: During the configuration in
IW/GMSC selecting signaling links is 0. If it is MSC office commissioning, the security
set to 1, the MSC will query the route table when variable Local module preferred during
sending messages. If it is detected that the 0 link IW/GMSC selecting signaling links is set
exists, the MSC cannot send messages. From the to 0 by default. In general cases, do not
feedback from the onsite maintenance personnel, set it to 1.

GSM Network Products 

August 2007 Issue 52 Fault Instances

Area Restriction Service

Failure under One MSC
Wang Ke, ZTE Corporation

Symptom
The area restriction service was enabled under
one MSC, but subscribers in cells subscribing the
service failed to access the network.

Analysis
1. The engineer checked whether security
variables of the MSC were set correctly, and found
that the switches of the following security variables
had been opened.
Cell roaming restriction control
Whether to perform cell restriction during the
Figure 1. Data Configuration In The Location Area location update
Whether to perform cell restriction during the
Mobile Terminated (MT) call
Whether to perform cell restriction during the
short message service
Whether to perform cell restriction during
handoff
Whether to perform cell restriction during the
supplementary service
2. The engineer checked whether the
ZoneCode (as shown in Figure 1) at the MSC side
was consistent with that (as shown in Figure 2) at
the HLR side, and found no problem.
Figure 2. Agent-Area Restriction 3. After checking the capacity of the table

 Maintenance Experience
 www.zte.com.cn

R_ZNCD, the engineer found it was big enough

(which was 10000).
4. After checking the foreground with the MSC
probe, the engineer found there were ZoneCodes.
5. The engineer found that Zonecode was not
checked on the VLR Configuration Services
Supported by VLR page, as shown in Figure 3.

Solution
After selecting all the options in the Other
area in Figure 3, the area restriction service was
implemented.

Figure 3. VLR Configuration

Signaling Link between

MSC and HLR Intermittently
Disconnected
Huang Wuxiang, ZTE Corporation

Symptom HLR to the fiber transmission. Then the

The two signaling links between the Miyanddab
MSC and the Orumieh HLR were intermittently
disconnected, so subscribers could update their
locations or server as the called party.
Analysis
Through inquiry, the engineer knew that this
fault occurred at about 9 a.m. To test whether the
new fiber transmission could be normally used,
the operator rerouted the microwave transmission
between the Miyanddab MSC and the Orumieh
fiber transmission was exceptional. The
engineer exchanged DTI boards (where
the two links suffering from intermittent
disconnection were located) of the
MSC, but the fiber transmission was still
exceptional. So the engineer exchanged
back the DTI boards, and changed
the transmission back to microwave
transmission. The two signaling links were
always intermittently disconnected.
The engineer connected to the

GSM Network Products 

August 2007 Issue 52 Fault Instances
Miyanddab MSC through Pcanywhere,
and observed these two links dynamically
in the No.7 link management of the MSC
dynamic management. The engineer found
that one signaling link in Slot 15-Subunit1
always alternated between the service
status and the non-service status, while
the signaling link in Slot 16-Subunit1 was
always in the non-service status. At
the same time, the engineer dynamically
observed the signaling link in Slot
15-Subunit2 to the Orumieh EIR, and
found it was always normal. The signaling
links to other offices or distributed to other
DTI boards were all normal too.
The engineer checked the MTP
management configuration and the trunk
configuration. The engineer found that
CIC 1 of Slot 16-Subunit 1 was allocated
to the signaling link to the HLR, while all
the other time slots and subunits of this
DTI board had been allocated to the BSC.
After deleting the time slots allocated to
 Maintenance Experience
the BSC and checking the connection of the trunk
line again, the signaling link still alternated between
the service status and the non-service status.
It was initially doubted that there was something
wrong with the trunk connection. The engineer
used the self-loop lines to self-loop these two
signaling links, and found that the same problem
occurred. Then the engineer tried many methods,
such as reconfiguring the two signaling links after
deleting them, replacing the subunit, replacing the
DTI board, replacing the physical slot, switching
and restarting the MP, restarting the two signaling
boards, and switching the SYCK board. However,
the problem still existed.
Among the MTP test messages in the No.7 link
tracing of the signaling tracing, several SLTM and
SLTA messages occasionally occurred, while MTP
discard error messages always occurred.
The engineer reconfigured a new HLR office
and a signaling link, performed self-loop on this
signaling link, and rerouted the E1 of one signaling
link of the old HLR office to this signaling link.
This signaling link was in the service status.

Among the MTP test messages in the No.7 link
tracing, SLTM and SLTA messages were normal.
However, once the signaling point code and the GT
analysis result of the old HLR office were rerouted
to the new HLR office, the new signaling link was
intermittently disconnected.
F i n a l l y, t h e e n g i n e e r d e l e t e d t h e G T
configuration, the signaling link configuration and
the adjacent office configuration of both the old
HLR office and the new one, retransferred all the
tables, reconfigured the old HLR office, and the
signaling link. The status of the signaling link was
normal. However, once the GT analysis result was
added, the problem occurred again.
After the GT analysis result was added, lots of
subscriber performed location update and served
as the called party. Therefore, it was doubted that
lots of subscriber failed to perform location update
or serve as the called party for a long time, for
the signaling link had been disconnected for a too
long time. Through the VLR probe, it was known
that about the number of online subscribers had
decreased to about 3000 subscribers at about 2
a.m. Once the signaling link was recovered, lots
of subscribers would perform location update and
serve as the called party at the same time. The
uprush of traffic was easy to cause the signaling
link congested and blocked. In the No.7 link
observation in the failure observation, congestion
failure messages were found.
Solution
The engineer adopted the method of adding
GT step by step. The engineer first added the
subscriber number section in E.214 format for
the GT analysis entrance 2 for location update of
new subscribers, but did not add the subscriber
number section in E.214 format for the GT analysis
entrance 1 for the time being. So the subscribers
were not allowed to serve as the called party.
The engineer temporarily cancelled
authentication on subscribers in the security
www.zte.com.cn
variables to reduce the load on the
signaling link. He/she dynamically
observed the status of the signaling link,
and found no intermittent disconnection
problem. The VLR signaling tracing
showed that the location update of the
subscriber was normal. Late at night when
the traffic was the lightest, it was observed
through the VLR probe that the number
of subscribers soared from 3000 to over
10,000 within one minute.
After observing from the VLR probe
that the speed of subscriber location
update decreased gradually, the engineer
added the subscriber number section
in E.214 format for the GT analysis
entrance 1 to allow the subscriber to
serve as the called party, and recovered
the authentication setting in the security
variables.
Because the number of subscribers
in this office increased quickly, the load
on the signaling link was very heavy,
and the quality of the transmission link
was unsteady, it was recommended that
the operator should add the number of
signaling links to the HLR.
GSM Network Products 
August 2007 Issue 52 Fault Instances
Switching System Access
Success Ratio in MSC
Exceeded 100%
Qin Ruirui, ZTE Corporation
Symptom
When collecting the network
management data in one MSC office, the
engineer found that the switching system
access success ratio exceeded 100%.
Analysis
It was initially thought that the switching
system access success ratio exceeding
100% was a false phenomenon. The
reason was that the calculation formula
was incorrect, or parameters in some
tables in the middle database affected the
performance statistics data.
Solution
1.The engineer added one record in
the table PM-TRIGGER in the middle
 Maintenance Experience
database MOPDB, setting P7 to -10, BEGIN time
to 0, and END time to 24.
The engineer executed in the query analyzer:
USE MOPDB
insert into PM_Trigger (MssId,begindatetime,en
ddatetime,P7)
values (' ',0,24,-10);
2.In the enterprise manager, the engineer
opened the table PM-TRIGGER in the middle
database MOPDB of the server 129, opened
the table by right-clicking it, and returned all the
lines to check whether the record in step 1 was
added.
3.After modifying the data, the engineer
checked the network management data within an
hour after 2 hours, and found that the switching
system access success ratio had decreased to
100% below.

In the Performance Statistics,
the Number of Call Attempts in
Office Traffic Was Inconsistent
with that in Circuit Group Traffic
Guo Yu, ZTE Corporation
Symptom
During the network maintenance for one office,
when performing performance statistics on some
BSC offices on the MSC, the engineer found
the number of call attempts counted based on
the office traffic was dramatically different from
that counted based on the circuit group traffic
sometimes.
Analysis
The reason was that the recording point of
counting the number of call attempts based on the
office traffic was different from that of counting the
number of call attempts based on the circuit group
traffic. In normal cases, difference is small. When
serious congestion occurs in the A interface in busy
hours, difference is big. For the specific difference,
refer to the signaling flow in Figure 1.
In the office traffic, when the MSC/VLR receives
the SETUP message from the A interface, one call
attempts will be added. While in the circuit group
traffic, when the MSC/VLR receives the assignment
completed message from the A interface, one call
attempts will be added.
Because there were differences in vacant
number, call origination restricted, BSS trunk
busy, wireless side congested and other aspects
www.zte.com.cn
between the office traffic and the circuit
group traffic in the signaling flow, the
statistics data based on these two factors
were inconsistent.
Solution
Combining the analysis on the onsite
condition, the engineer thought the main
reason why the difference occurred was
the trunk busy. There was no BSS trunk
busy item in the office traffic statistics
in the onsite version. The BSS trunk
busy item was added in the subsequent
V3.04.12.P11.B1 version. Therefore, the
number of call attempts could only be
counted based on the basic traffic.
The formula was A=B-C.
Where, the meanings of A, B and C
were as followings:
A: Times of BSS trunk busy in the
basic traffic statistics, which was
counted based on the six call types
(international toll automatic outgoing
call, international toll manual outgoing
call, national toll automatic outgoing
call, national toll manual outgoing call,
local outgoing call, local call).
GSM Network Products 
August 2007 Issue 52 Fault Instances

B: Sum of the number of incoming C: Sum of the number of incoming trunk call
trunk call attempts to each BSC in the attempts to each BSC in the circuit group traffic
office traffic statistics. statistics.

Figure 1. Signaling Flow of the Call

10 Maintenance Experience

Failed to Set PDP Contexts on
the HLR Agent in Batches
Chen Yunlong, ZTE Corporation
Symptom
When setting PDP contexts on the HLR
agent in batches by inputting the text file, the
system prompted error occurred when reading
subscription file, maybe the format is incorrect.
Analysis and Solution
The onsite HLR version was V3.04.15.P1.B1.
When modifying PDP contexts in batches, the
format of the input text file was composed of:
Subscriber identity (IMSI or MSISDN)
PDP address type (0 means dynamic
www.zte.com.cn
addresses, while 1 means static
addresses)
IP address (this field is valid when the
PDP address is static, and it is ignored
when the PDP address is dynamic)
One or more spaces or TABs are
needed to separate three fields above.
According to the format described
above, the engineer inputted subscribers
whose PDP context information was to be
set in the text file, and performed the batch
operation again.
GSM Network Products 11
August 2007 Issue 52 Fault Instances
Lots of 166 Failure Causes
Occurred in SMSC
Sun Liukui, ZTE Corporation
Symptom
The CMPAK SMSC maintenance
personnel found lots of 166 failure causes
occurred in the SMSC, which caused MT
short message failure.
Analysis
The signaling flow of the MT short
message is as follows:
1. SCGateway MSC
Short Message (GSM 03.40)
2. Gateway MSCHLR
MAP_SEND_ROUTING_INFO_FOR_SM
3. HLRGateway MSC
MAP_SEND_ROUTING_INFO_FOR_
SM_ACK
4. Gateway MSCServicing MSC or
SGSN
MAP_MT_FORWARD_SHORT_MESSAGE
5. Servicing MSC or SGSNVLR
MAP_SEND_INFO_FOR_MT_SMS (*)
6. VLRServicing MSC or SGSN
MAP_PAGE/MAP_SEARCH_FOR_M
OBILE_SUBSCRIBER (*)
7. Servicing MSC or SGSNMS
Page (GSM 04.08)
8. MSServicing MSC or SGSN
Page response (GSM 04.08)
9. Servicing MSC or SGSNVLR
MAP_PROCESS_ACCESS_REQUEST
_ACK and MAP_SEARCH_FOR_MOBILE
_SUBSCRIBER_ACK (*)
10. VLRServicing MSC or SGSN
MAP_SEND_INFO_FOR_MT_SMS_A
12 Maintenance Experience
CK (*)
11. Servicing MSC or SGSN MS
Short Message (GSM 04.11)
12. MSServicing MSC or SGSN
Short Message Acknowledgement (GSM 04.11)
13. Gateway MSC Servicing MSC or SGSN
MAP_MT_FORWARD_SHORT_MESSAGE_ACK
14. SCGateway MSC
Short Message Acknowledgment (GSM 03.40)
The MT short message needs to pass through
the MSC/HLR. According to the above signaling
flow, it is known that the following two cases will
cause MT short message failure.
Step 2 in the signaling flow
The SMSC asks the HLR for the route
information of the called subscriber. After
receiving the short message route request from
the SMSC, the HLR first checks the dynamic
information of the subscriber, checking whether
the subscriber is accessible (such as powering
off the MS), and whether the previous short
message receiving status of the subscriber
is accessible. If any of these two options has
inaccessible mark checked, the HLR will
directly return absent subscriber to the SMSC,
reporting that the MT short message failed. This
point is different from calls.
From step 4 to step 14 in the signaling flow, the
MSC may send the MapError message to the
SMSC, prompting that the MT short message
failed.
The MT subscribers whom the SMSC perform
statistics on include those from the local
network and non-local networks. For the

subscribers from non-local networks, the MSC
just performs GT forwarding of the SCCP layer,
but does not perform statistics on whether it is
successful or not. The SMSC is recommended
to perform statistics based on number sections,
so that MT short message failure in the local
network and non-local networks can be
counted.
After discussing and analyzing the problem with
the maintenance personnel at the SMSC side, the
engineer confirmed that the reason why the 166
failure cause occurred was that the MSC sent the
MapError message to the SMSC, whose content
was system failure. The failure cause code of the
corresponding VLR call loss was 161.
The call loss is described as follows:
The failure cause code 161 means that the
subscriber being busy is decided by the network
(NDUB).
Involved services: call, short message, and
USSD service.
Status: when the VLR receives the paging
response that carries subscriber error mNDUB_M
during paging the subscriber in the MT call, short
message, and USSD service.
Cause: the subscriber is in the unsteady
process during the paging course, such as location
update, and access.
When the subscriber is in the steady process
(such as LU, and USSD service), the VLR MAP
will report the call loss of NDUB, and the MSC
will return the MapError message to the SMSC at
Figure1. MSC Failure Observation
Figure 2. VLR Failure Observation
www.zte.com.cn
the same time, carrying the cause that is
system error.
After comparing the call loss with
the signaling on the site, the engineer
confirmed that system errors occurred
during the MT short message were caused
by NDUB. The MSC call loss and the
VLR call loss were shown in Figure 1 and
Figure 6 respectively.
During the course of MT short
message, in the case of no response
to the MSC paging, the MT subscriber
powering off the MS, or NDUB, the MT
short message cannot be completed. But
when the MSC successfully pages the
subscriber, or after the subscriber power
on the MS, the MT short message will be
completed. In this way, short message
receiving will be delayed.
The concept of unsteady status
covers the following cases of this problem
in the protocol:
No other services can be initiated
during the location update:
Between the network and the mobile
station. The end of the running MM
specific procedure or the release of all
MM connections have to be awaited
before a new MM specific procedure
can be started (GSM04.08 4.4).
If an MM specific procedure is running
at the time the request from the
GSM Network Products 13
August 2007 Issue 52 Fault Instances
CM sublayer is received, and the
LOCATION UPDATING REQUEST
message has been sent, the request
will either be rejected or delayed,
depending on implementation, until
the MM specific procedure is finished
and provided that the network has not
sent a "follow-on proceed" indication,
the RR connection is released. (GSM
04.08 4.5.1.1).
No other MM connections are allowed
to be established when the subscriber
is in the access phase:
When in MM CONNECTION ACTIVE
(GROUP TRANSMIT MODE) state,
the MM sublayer in the network shall
reject the request for the establishment
of another MM connection by any CM
layer (GSM 04.08 4.5.1.3.1).
Solution
The system errors occurring when
the MT subscriber is in unsteady status
are all caused by normal behaviors of the
subscriber. The high NDUB MSC is greatly
related to the quality of the whole network.
For example, poor coverage causes lots of
location updates. Therefore, the problem
can be thoroughly solved only through
14 Maintenance Experience
optimizing the quality of the whole network.
In the light of conditions of the onsite network,
the engineer provided other methods to adjust the
success ratio of receiving short messages:
It was recommended to clear the subscribers
who were in inactive status for a long time, so
that the ratio of absent subscribers in the HLR
and the related system load could be reduced.
Send group messages only to the activated
subscribers.
Reduce the resource waste to increase the MT
success ratio.
For the case of no response to the paging,
adjust the indoor coverage to increase short
message paging success ratio.
Summary
The three main factors affecting the success
ratio of receiving short messages are as follows:
The subscriber being busy is decided by the
network (NDUB).
The subscriber powers off the MS (Subscriber
Absent for MS turnoff).
There is no response to paging the subscriber
(Subscriber Absent for Page No response).
Therefore, to increase the success ratio of
receiving short messages, it is necessary to start
from these three factors, and analyze the related
call loss according to the above methods.

Low System Access
Success Ratio
Sun Liukui, ZTE Corporation
Symptom
The system access success ratio in one office
was very low.
Analysis
Taking the MSC performance statistics in busy
hours in one month as the reference to perform
analysis, the engineer concludes that the failure
causes greatly affecting the system access
success ratio are as follows:
1. Mobile Subscriber Unreachable
This cause is that the subscriber cannot be
successfully paged or the subscriber powers off the
MS.
2. inging Release Early
www.zte.com.cn
When the called MS rings, the calling
party releases the call before the called
party answered the call.
3. Equipment Keys Congestion
The REL message is received from the
opposite end during the local outgoing call.
The failure cause is that the opposite-end
switch is congested.
4. Subscriber Release Early
Before the called party is successfully
connected, the calling party actively
releases the call.
5. Failures due to Other Reasons
Other causes include the following
cases:
GSM Network Products 15
August 2007 Issue 52 Fault Instances

(1) After the called party ringing
message or backward ACM signaling is
received, the call fails; and the failure
cause is not Subscriber busy (17) or
Normal release (16). The call is released
due to any other causes than Subscriber
busy (17) and Normal release (16),
such as no response from the subscriber,
ringing release early, the called party
refusing to receive the call (depending on
the release cause inputted by the called
MS), and outgoing call.
(2) The incoming call fails to occupy
the called circuit.
(3) The call origination is restricted
in the local office; the release signaling
with failure cause value as 31 is received
before the called party in the local office
rings or the backward office returns the
ACM message when the called party is
outside the local office during the local
office originating a call (in general, this
case is less).
(4) Statistics of no statistical item can
be collected. This case can be ignored.
In general, the first two cases are the
Table1. Office Traffic Statistics
Incoming Outgoing
Line
Category Seizure Seizure
Time Traffic
description Traffic Traffic
(ERL) (ERL) (ERL)
majority of other causes, while the last two cases
are just supplementary to the completeness of the
statistics processing.
After analyzing the onsite traffic data, the
engineer found that the second case in the other
causes mainly affected the system access success
ratio in busy hours.
1. The engineer collected the call loss data in
one period of time, which proved this point.
The failure cause occupying the maximum
proportion was: 0122=Terrestrial circuit unavailable
because Application for the terrestrial circuit from
the A interface or assignment fails. Usually this
occurs in busy hours.
2. This point was proved from the office traffic
statistics at the same time, as shown in Table 1.
The congestion in the trunk of the onsite network
was very serious.
The traffic per line to N-ABT-B88, N-MDN-B95
and N-PSH-B92 in busy hours was over 1.0elr,
while that to N-PSH-B91 and N-MDN-B96 was over
0.9elr, which all exceeded the recommend value:
0.7elr. Therefore, the serious call loss in busy
hours was caused by the congestion in the trunk.
Recommended Solution
In the current network, the following two
problems mainly affect the system access ratio:
1. Unsteady transmission causes circuits and
links intermittently disconnected.
2. Serious congestion at the A interface and in
inter-office circuits causes the network busy.

2007-5-1 17:00 N-ISB-B81 620.69 596.58 0.66

Solving the problems above can greatly

2007-5-1 17:00 N-ISB-B82 422.85 358.89 0.42 improve the system access ratio.
2007-5-1 17:00 N-ISB-B83 486.05 465.45 0.52
2007-5-1 17:00 N-PSH-B91 584.59 552.71 0.99 Summary
2007-5-1 17:00 N-PSH-B92 361.81 341.42 1.03 When processing the system access success
2007-5-1 17:00 N-JHL-B87 260.3 245.95 0.49 ratio problem, first extract some representative
2007-5-1 17:00 N-ABT-B88 496.6 532.56 1 performance data and call loss data, collect
2007-5-1 17:00 N-MDN-B95 344.85 345.82 1.01 statistics on and analyze each kind of failure cause
2007-5-1 17:00 N-ISB-B84 578.37 517.64 0.68 value, find out exceptional cause values, and give
2007-5-1 17:00 N-MDN-B96 308.31 348.67 0.97 the related solution.

16 Maintenance Experience

Failure of Independent IP
Tone Playing
Chen Yunlong, ZTE Corporation
Symptom
The carrier complained that the subscriber with
insufficient or 0 balance could not hear the tone
playback during a call.
Analysis
In the onsite network, the tone playback was
independent IP tone playback. The normal flow
is that the SCP sends the ETC operation to the
MSC. After receiving the ETC operation, the MSC
originates a call to the IP. However, after tracing
the signaling, it was found that the MSC did not
originate a call to the IP.
1. The engineer opened the ETC message sent
by the SCP to check Assisting SSPIPoutingAddr,
finding that an independent IP address was
entered. The engineer checked the analysis of the
independent IP number, finding that this address
was directly analyzed as the outgoing service
[National toll inter-region automatic services].
2. The engineer checked the configuration of
the security variables.
i. The option of SPF Combines 3 parameters
www.zte.com.cn
was set as 1, which meant no assembly.
ii. The item of Whether to adjust the
independent IP address was set as 1,
which meant that the address format in the
AssistinSSIPRoutingSddr of the ETC would
be adjusted, with the country code removed
during the analysis. Setting this item as
0 meant that the number sent by the
ETC would not be adjusted, which would
be directly analyzed in the corresponding
call originating selector. Since the item
SPF Combines 3 parameters had been
set as 1, this item should be set as "0",
indicating that the number sent by the ETC
would be directly analyzed.
Solution
The fault reason was that the security
variable of Whether to adjust the
independent IP address was set as 1.
After this item was changed to 0, the
independent IP tone playback became
normal.
GSM Network Products 17
August 2007 Issue 52
Table1. Office Traffic Statistics
1 MSCMAP
2 MSCMAP
3 MSCMAP receive
18 Maintenance Experience
Fault Instances
Failed to Send Paged SM
Dai Yi, ZTE Corporation
Symptom
When the Short Message (SM) was
sent to a certain SMC, it was successful
to send one-page SM, but unsuccessful
to send two-page SM. The signaling was
shown in Table 1.
Analysis
The MSC processes the SM MO
based on the security variable of SM
Maximum packet size. If the SM length
is less than the security variable value,
the MSC will send the three messages
(Map_Open+FWD SM+delimiter) serially.
If the SM length exceeds the security
variable value, the MSC will send the
Map_Open+Delimeter messages first
without sending the contents of the SM.
After the SC returns the Open_Cnf
message, the MSC sends the FWD
SM+delimiter messages, sending the SM
to the SMC. For a SM with over 120 bytes,
send 8:42 MAP OPEN REQUEST
send 8:42 MAP DELIMITER REQUEST
8:43 MAP P_ABORT INDICATION
after being encapsulated on the bottom layer, the
length of two messages Open + FWD will exceed
the maximum length of the UDT message. As a
result, the SCCP will divide these two messages
into the XUDT. If the opposite-end NE does not
support the XUDT packet, the service will fail.
By sending the Open request and the FWD SM
message separately, the occurrence of the XUDT
will be reduced, which will improve the compatibility
and ensure the implementation of the service.
Sending a SM in the paging mode failed after
the Open request was received. The engineer
found that there was a Provider Malfunction
alarm in the Failure Observation window, that is,
the bottom layer considered the SM abnormal.
Therefore, it was confirmed that the SMC bottom
layer did not support sending SM in the paging
mode. The UDT that only contained the transaction
and the dialog content (Map_Open+delimiter)
without the component content would be
considered abnormal.
Solution
If the opposite-end SMC supports the XUDT,
increase the security variable SM Maximum
packet size, so that the MSC can send the three
messages of Map_Open+FWD SM+delimiter
serially.

Ineffective Special Number
Huang Wuxiang, ZTE Corporation
Symptom
The carrier complained that the special service
numbers configured were ineffective. Some
subscribers could not directly dial the special
service number, such as 110, and some calls could
not be transferred to different attendant consoles
based on different cell numbers.
Analysis
1. The engineer checked the configuration of
special number management in the configuration
management. Different special service numbers
and different cells had been configured with
different attendant console numbers. There were
more than 4000 records in total.
2. By querying the number analysis
corresponding to these numbers, the engineer
found that some special service numbers had
been analyzed as National Interregional Number,
and transferred to a specified attendant console
number for outgoing after converted at the called
side. And some special service numbers had been
correctly analyzed as MSC Special Service with
the Default Attribute as the number attribute.
Therefore, those outgoing numbers after being
converted could be successfully dialed, but could
not change different attendant console numbers
based on the cell number. However, those numbers
analyzed correctly could not be successfully
www.zte.com.cn
dialed. The engineer first analyzed all
special service numbers as MSC Special
Service", and then looked for the reason.
3. The engineer pre-analyzed the
special service numbers and the attendant
console numbers respectively, both getting
the correct analysis results. Therefore, the
number analysis was normal.
4. By tracing the messages from the
A interface, it was found that the network
returned the disconnect message
containing the failure cause of incorrect
number format (incomplete number) to
the MS. And the same failure message
was found in the Failure Observation.
The problem still existed, after changing
the values of the longest and the shortest
numbers in the number analysis.
5. The engineer copied the R_MSPEC
table from the MSC foreground to its
background. The engineer opened the
MSC probe, and double-clicked the x in
the top right corner. He/she opened the
downloaded R_MSPEC table in the pop-
up window, and found that there were only
512 records in this table. However, over
4000 records had been configured in the
special service management configuration
of this office in fact.
GSM Network Products 19
August 2007 Issue 52 Fault Instances
6. The engineer tried to execute
the dial-up test in the cells where the
R_MSPEC table had records, finding that
it was normal. The engineer confirmed
that this fault was due to the inconsistency
between the foreground R_MSPEC table
and the background configuration. He/she
repeatedly started the foreground MP and
then transferred all the tables for three
times. But the problem still existed.
Solution
After checking the Table Capacity
Check before send log of the transferred
Handling the Database Space
Alarm from Performance
Statistics
Guoyu, ZTE Corporation
Symptom
The performance statistics gave a
database space alarm, prompting that
the database size was less than the
configured upper limit.
Solution
After checking the property settings
of the SQL performance database, the
engineer found that the database size was
1000 M, and its auto-increasing upper limit
20 Maintenance Experience
table, the engineer found that the table contained
the failure message of Tables which sending
record count bigger than designed capacity.
Through check, it was found that the
value of Special Group Table Capacity in the
office capacity configuration had been set as
512. It caused lots of records in the Special
Service Group Management of the background
configuration could not be completely transferred
to the R_MSPEC table of the foreground MSC
module. The engineer changed the value of the
into 4096. After three times of starting the
foreground MP and transferring the tables, the fault
was eliminated.
was 1001 M.
After the database size was set consistent
with its auto-increasing upper limit, the alarm
disappeared. After some time, the alarm appeared
again for the database size was restored to 1000
M. After checking the property settings again,
the engineer found that the option of Automatic
Shrink was selected. After the engineer unchecked
this option and modified the database size to be
consistent with the increasing upper limit, the
problem was solved.
 www.zte.com.cn

Handling the Fault of Having

GateOut CDR without MO CDR
Hao Li, ZTE Corporation

Symptom Recommended Solution

During the inter-network settlement of the billing
center, the engineer found that a few records with
duration ranging from 1 s to 20 s had the GateOut
CDRs without the MO CDRs.
Analysis
This case for 1-s calls results from the early
It is recommended that the carrier
should discard the CDR whose duration
is less than 1 s without processing. As for
the CDR whose duration ranges from 1 s
to 20 s, it is also recommended that the
carrier discard it due to its few quantity
and inevitability.

release of the calling party. There are only a few

CDRs with the duration ranging from 20 s to 1 s.
The MSC generates the trunk CDRs after receiving
the ANM signaling from the opposite-end office.
The signaling flow is shown as Figure 1. At this
moment, the MSC will report the DP7 to the SCP,
and set 20-s timer to wait for the SCP sending
the continue message to confirm that the call is
put through. The MSC generates the MO CDR till
it receives the continue message. When such
things happens, including the continue message
loss, timer timeout or the subscriber releasing the
call before timeout, the trunk CDR less than 20 s
appears, without the MO CDR. Figure 1. SIGNALING FLOW

GSM Network Products 21

August 2007 Issue 52 Fault Instances
Handling the Fault of R2
Incoming Call after Call
Number Upgrade
Sun Jingrui, ZTE Corporation
Symptom
The mobile number of the local
network in an office was upgraded from
095 + SN (six digits) to 095 + SN (seven
digits). Where, 95 was the NDC upgrade
rule, that is, 5 was added in front of the
original SN. The new number and the old
number both existed after the number
Figure 1. Traced CAS Message 1
22 Maintenance Experience
upgrade. Both of them could be used by the
subscribers.
After the number was upgraded, the engineer
changed the number stream length of the prefix
0955X from 9-9 to 9-10, which was in the
analyzer entry 7 of the trunk selector 201 in the
R2 office. Two days later, the engineer found
that the new number could not be dialed in the
incoming call from the PSTN (R2). Therefore, the
carrier changed the length of the number stream to
10-10.
Analysis
During a dial-up test, the subscriber
021226526 of the PSTN (R2 office) dialed the
10-digit number (after the upgrade) 0955906834,
but the call was connected to the subscriber
0955590683 (the test number). Shown by the
traced CAS message, the MSC only requested the
9-digit called number 095590683. The system
added 5 behind the called number 095, so the
called number became 0955590683. Therefore,
the subscriber 0955590683 became the called
party. The CAS message traced was shown in
Figure 1 and Figure 2. The digits in the red square
represented the called number 0955590683 that
was received by the MSC.
Different from that of the ISUP, the associated
incoming call number is received one digit by one
digit. For an incoming call home to the local office,
whether to stop receiving the number is controlled
 www.zte.com.cn

by the minimum number stream length that is set in

the number analysis.

Solution
Since the problem occurred only in the R2
office, the engineer sub-divided the trunk selector.
The engineer created the trunk selector 205 in the
ISUP office, changed the length of the number
stream "0955X" to 910 digits, and kept length of
number stream 0955X in the trunk selector 201 of
the R2 office as 10-10 digits.
In this way, the incoming call from the R2
office could dial the new 10-digit number 09555X
upgraded from 0955X. And the old 9-digit number
0955X could not be dialed now. Because there
were less R2 subscribers in the local network, this
method could reduce the influence range to the
uttermost. Figure 2. Traced CAS Message 2

The number of current

subscribers in HLR was
inconsistent with the number
of actual subscribers
Yu Hongliang, ZTE Corporation

Symptom was confirmed after database was queried

The number of subscribers was found abnormal
when queried through Network Management
(NM) system. An office reported that the number
of current subscribers in ZTEs HLR, which was
collected by the upper NM system, differed greatly
from the number of actual subscribers. The fault
through SQL query analyzer.
Analysis
1. The upper NM system was able to
collect data, which accounted for normal
connection between area A and area B.

GSM Network Products 23

August 2007 Issue 52 Fault Instances
2. There is an NM system interface
machine in HLR system, which connects
to HLR through a switch inward and
connects to the upper NM system outward.
This interface machine collects HLR data
once every a period of time and stores the
data in its database. The data collected
by the upper NM system is exactly the
data stored in the NM system interface
machine. The data of current subscribers
are collected by OMM.
3. After entering the performance
statistics system of the client, and then
querying subscribers in HLR Agent
System, it was found the data of current
subscribers were exactly the incorrect data
Some of Intelligent
Subscribers Failed to Roam
within a Province, or in Another
Province or country
Duanmu Xiaoting, ZTE Corporation
Symptom
Some intelligent subscribers failed
to roam within a province, or in another
province or country. However, they could
access the network after their subscription
Figure 1. Signaling Flow
24 Maintenance Experience
collected by the upper NM system.
4. Analysis shows that this data statistic error
was caused by fault of operation and maintenance
system.
Solution
1. The following script on database was loaded:
declare @retcode int
begin
exec hp_sys_measure @retcode output
exec hp_sys_measurecc @retcode output
end
2. The script was set to run at wee hours every
day.
Problem was resolved after successful load of
scripts.
data for intelligent service were deleted on agent.
Analysis
1. The ZTE engineers performed analysis on
the failure of a VPMN subscriber, who roamed to
some places and could not access the network.
They viewed the location update process of this
subscriber through signaling tracking. The signaling
flow is shown in Figure 1.

2. It was found that when inserting subscriber
data in the process of location update, the peer-
end VLR returned a MAP_NOTICE to HLR, which
caused the subscriber information data unable to
be inserted into VLR and thus resulted in failure of
location update.
3. When the ZTE engineers deleted CAMEL
information of this subscriber on the agent, and
then viewed the location update flow, it was found
that the flow was normal and the subscriber was
able to access network.
4. The reason why this fault occurs is that the
peer-end VLR returns a rejection message to HLR
after it has received the request from HLR for
inserting subscriber data.
5. TM reports the abnormal structure and
components call loss resulting from cause 112
after it has received the message, and sends
MAP_NOTICE_IND (problem diagnosis value is
0) to MAP. Because the subscriber has subscribed
too much information, the HLR needs to divide
the subscriber data into packages when inserting
them. In the process of encoding, at the time of
TM encoding VPMN server information, it is found
that the length of the current code stream encoded
has reached boundary value of the package, so
some parameters like OCSI are not encoded in
this package, however, VLR CAMEL flag has
been encoded in this package. This causes, in the
subscriber data inserted in VLR, the first package
has CAMEL data flag but no CAMEL information,
while the CAMEL information is in the second
package.
6. It is totally normal when this kind of thing
happens during encoding, because VLR CAMEL
information is defined as Sequence type in
the protocol. The Sequence type may have no
detailed content during encoding, which is clearly
explained in MAP protocol, as shown in the
following information taken from Section 17.11 of
GSM0909-710 protocol:
There is no restriction to the use of empty
www.zte.com.cn
constructors (e.g. an empty SEQUENCE
type). That is, the encoding of the content
of any data value shall consist of zero, one
ore more octets.
7. However, some VLRs are not
compatible with this kind of condition
mentioned above. When receiving the
request for inserting the second package
of subscriber data, they would consider
the code stream of these subscriber data
illegal and return a rejection message to
HLR if they find VLR CAMEL flag only but
no such detailed CAMEL data as OCSI
in the code stream in the package, thus
resulting in location update failure.
Solution
1. Delete VPLMN information of
subscribers so that location update may
succeed.
2. Subscribe VPLMN information
again. When the agent subscribes VPLMN
information for the subscriber, HLR only
needs to insert VPLMN subscription
information to VLR, so the inserted
subscriber data is not so large that HLR
needs not to divide them into packages
when insert them. Therefore, VLR CAMEL
flag and OCSI information are in a same
package when they are inserted in VLR.
The VLR thus consider the code stream
correct and insert these data successfully.
Conclusion
The reason why the locations of
VPLMN subscribers fail to update when
they roam to some VLRs is that those
VLRs have imperfect compatibility in
code stream. Causes are the same for
other kinds of subscribers failures of in-
province roaming, inter-province roaming,
or international roaming.
GSM Network Products 25
August 2007 Issue 52 Fault Instances
Configuration of IMSI Number
Analysis
Wang Xiaosong, ZTE Corporation
Symptom
The GT number of HLR of the
subscribers locations could not be
acquired after the IMSI prefix was directly
analyzed as HLRGT.
Analysis
1. IMSI structure analysis
IMSI structure: MCC+MNC+H0H1H2H3+
XXXXXX, wherein H0H1H2H3 uniquely
identifies one HLR.
2. Analysis on E164 and E214 coding
methods
The E164 code is directly converted
into MSISDN number of HLR, or the
converted MSISDN number is properly
lessened according to the quantity of
the numbers digits.
E214 coding method: MCC+MNC (in
IMSI) CC + NDC, with the rest of
number copied.
In configuration of NM system, E164
coding is adopted for Result Indication
26 Maintenance Experience
is HLRGT; E214 coding is adopted for Result
Indication is ISDN.
Solution
1. Acquire ISDN number of HLR.
On the interface of adding or modifying mobile
digit analysis index, the analyzed result indication
is configured as Result indication is HLRGT, which
transforms the IMSI digit prefix to HLRGT.
2. In Translator dialog box, select ISDN/
telephone numbering plan for configuration of
Number Plan.
3. GT translation data
Select the above-mentioned GT translator to
work out GT translation data toward ISDN number
of HLR.
Because the ISDN number of HLR is unknown
and only CC+NDC is available, the configuration is
as following:
i. On the interface of adding or modifying mobile
digit analysis index, the analyzed result indication
is configured as Result Indication is ISDN. Only
replace MCC+MNC with CC+NDC, and leave other
configuration data as they are.
ii. On Translator dialog box, select ISDN/Mobile
numbering plan for configuration of Number Plan.
iii. GT translation data
Direct GT translation data that match
CC+NDC+ H0H1H2H3+XXXXXX to GMSC.
Note: The advantage of the second
configuration method is that the local MSC does
not need to know which HLR it is and needs only
to analyze CC+NDC to GMSC. Then GMSC
analyzes the CC+NDC+H1H2H3 to the destination
HLR GT according to destination CC+NDC+
H1H2H3+XXXXX.

Some Subscribers Couldnt be
Registered in Network after
the Cell Restriction Service Is
added in HLR
Duanmu Xiaoting, ZTE Corporation
Symptom
After cell restriction service is added in HLR,
some subscribers cannot be registered in the
network while some others can.
Analysis
1. By checking the HLR, it was found that two
subscribers had the same service subscription
information. Therefore, the problem is not caused
by the subscription information on HLR.
2. The problem may have something to do with
SIM card. However, this card could be registered
in the network normally after its number was
exchanged with another card which is normal. And
the other card was then unable to be registered
in the network. The registration in the network
became normal after the subscribed cell restriction
in HLR was removed.
3. It is certain that the fault has something to do
with the cell restriction service. Later the capacity
www.zte.com.cn
table of VLR was checked, and it was
found the value of table R_ZNCD is 100.
When checking it with the VLR probe,
it was found the number of the current
registered subscribers was 128.
4. The number of the cell roaming
subscribers allowed by the local office is
defined in the table R_ZNCD, so the extra
28 subscribers could not be registered in
the network because of capacity restriction.
Solution
The carrier demanded that all the
subscribers should be restricted in one
cell, that is, the cell restriction should be
valid for all the subscribers. So it was
required to change the capacity of the
table R_ZNCD. After that, when performing
the test, subscribers could be normally
registered in the network.
GSM Network Products 27
August 2007 Issue 52 Fault Instances
Failure to Login Remote HLR
Agent
Duanmu Xiaoting, ZTE Corporation
Symptom
The ZTE engineers installed a remote
HLR Client in another city through a router.
After the installation was completed,
basic configuration management could
be logged in but the agent could not be
logged in. The failure as prompted is
failure to connect the server.
Analysis
1. This remote client reaches the
area where server 129 is located through
a satellite. Server 129 connects to the
satellite through a router. The IP of server
129 is 219.192.2.129. The gateway uses
the IP of the router port that is connected
with 129, which is 219.192.2.254. The
remote client must use an IP in the same
network section from satellite, which is
192.168.20.210. The gateway uses the IP
from the satellite, which is 192.168.20.1.
28 Maintenance Experience
2. During the installation of background
maintenance software of remote client, the area
code and the office ID were respectively set as
21 and 20. Then the IP acquired automatically
was 192.168.20.210. Meanwhile, 219.192.2.129
was selected for IP of 129. After the installation
was completed, the ZTE engineers were able to
log in the client and open the interface of basic
configuration management but failed to log in the
agent with a prompt indicating failure to connect
to the server. The agent connected to DB through
DBIO, the area code and the office ID set on 129
were respectively 888/2 .They are inconsistent with
the area code and the office ID set on the remote
client, which led to the failure in connecting to the
server.
Solution
On this remote agent, the area code and office
ID in the file TCPSEEK.INI under C:\ZXG10 were
changed to 888/2, and the problem was resolved.
 www.zte.com.cn

HLR Agent Startup Error When

Configuring Data
Zhang Songlei, ZTE Corporation

Symptom
In the procedure of data configuration
during commissioning, the ZXG10-MSS Agent
Management process of HLR agent kept flickering.
The database can not be linked, and the agent can
not start up.

Analysis
1. It was checked and confirmed that the
HLRDB had been setup.
Figure 1. Error Alert
2. The configuration of HLRDB node which was
managed by HLR configuration was checked and
no configuration data were found.
3. When HLRDB node was being configured,
the system popped up error alert as shown in
Figure 1.
4. Based on the error alert, it was known that
Figure 2. No License Configuration Data
the number of subscribers on the database node
had exceeded the number of subscribers of the
whole system and no matter how small a value the
number of subscribers on the node was changed
to, the system kept giving this alert. It was that the
absence of license might be the reason.
5. Then the license file was loaded and the
system gave an alert as shown in Figure 2 and
Figure 3.
6. It was found that HLR number did not match
that in the License, and then HLR number was
modified. It may be modified in the following ways.
If possible, modify HLR number in HLR
parameter configuration, as shown in Figure 4.
If HLR number can not be modified in HLR Figure 3. Failure to Acquire License

GSM Network Products 29

August 2007 Issue 52 Fault Instances

parameter configuration, directly modify the

parameter in SQL database. Operate as shown
in Figure 5 and Figure 6.

Figure 4. Modifying HLR number in Parameter Configuration
Solution
1. The License could be loaded successfully
after modifying HLR number. The process of
loading License is shown in Figure 7.
2. The database node could be configured after
loading License, as shown in Figure 8.
3. After the configurations above were all done,
the ZXG10-MSS Agent Management process did
not flicker anymore. The agent could be opened
normally.

Figure 5. Modifying HLR Number in SQL Database-Step 1

Figure 6. Modifying HLR Number in SQL Database-Step 2

Figure 8. Configuring Database Node Figure7. Loading License Successfully

30 Maintenance Experience
 www.zte.com.cn

Failure in Backing up HLRDB

onto Node 129
Chen Yu, ZTE Corporation

Symptom 4. It was found that the file in the

The backup database of one HLR was at node
129. One day, the system failed to back up the
data automatically to node 129 from node 173.
Checking database showed that the backup MSDB
database file of node 173 saved at node 129 was
suspended. Rebuilding HLRDB and recovering
the data of the last day could solve the problem
temporarily.
However, one week later, the problem occurred
again and lasted for several weeks.
Analysis
1. The backup failure kept repeating, so
engineers started from analyzing the error logs of
backup directory was much smaller than
other files and its date was the time when
this failure happened the first time.
Solution
1. The file containing incorrect data
format was manually deleted.
2. Remote backup was performed
manually after 1:00 am on the day before
the next occurrence day of the failure (the
automatic remote backup starts at 1:30).
The manual backup was successful. Then
the automatic backup became normal. And
the failure did not occur again.

backup.
2. Check box Show step details at the top right
corner of the log interface, as shown in Figure 1,
was selected. The detailed causes of backup failure
were checked. As the highlighted part showed in
Figure 1, the corresponding data file of node 173
in the backup directory on 129 had incorrect data
format.
3. Through analysis, it was found that the
database format was destroyed in occurrence
of the first failure. Every week, after the problem
happened, HLRDB was rebuilt but the data in
incorrect format was also imported to the HLRDB
backup on node 129 (the data still can be imported
though its format is wrong). Because this file was
never updated by new backup successfully, only
auto-backup was affected. Figure 1. Database Log

GSM Network Products 31

August 2007 Issue 52 Fault Instances
HLR MAP Process Repeatedly
Restarting
Xu Gaofeng, ZTE Corporation
Symptom
The HLR service process kept
restarting after HLR server power down.
Analysis
1. It was doubted that it was caused by
the exceptional power down, so the engineer
restarted the MAP server. However, the
process kept restarting after that and the
problem remained unsolved no matter how
many times the server was restarted.
2. Error logs under C:\trace on the
server were checked and only SERVER
RESTART alarms were found.
3. OMC alarm subsystem was checked
and no alarm was found.
4. Re-installation of service handling
programs on the server could not solve the
problem either.
5. Engineers used PING command on
the MAP server to check the connection
to database server and OMC server but
failed. Pulling out and then inserting the
32 Maintenance Experience
network cable, disabling and then enabling NIC,
all proved useless. Engineers used command
ipconfig all in DOS mode and found there was no
IP address. It was doubted that the NIC might had
a problem.
6. Pinging 127.0.0.1 successfully proved that
the NIC was fine. Changing the network cable
between server and LAN Switch but the problem
kept the same.
7. There were network cables of other servers
and their networks were normal, so the LAN
SWITCH was fine.
8. By checking IP configuration it was found
that the server had dual-IP (the MAP processor has
two service processes).
Solution
Engineers deleted one of the two IPs and
waited for the NIC to activate. After one of the
service process started, engineers added the IP
address deleted before and then waited for the
start of the second service process. The problem
was solved.

Failure in HLR Setting PDP
Contexts in Batches
Chen Yunlong, ZTE Corporation
Symptom
When configuring PDP contexts in batches
by using a text file on HLR agent, the system
prompted: error occurred when reading
subscription file, maybe the format is incorrect.
Analysis
The version of HLR was V3.04.15.P1.B1. In this
version, when a text file is used to perform batch
operation, the input format will be changed and
formed by the following three parts:
IMSI or MSISDN
CUG users Unable to Update
Location under ZTE MSC
Duanmu Xiaoting, ZTE Corporation
Symptom
A CUG user of an HLR could not update
location when the user roamed to ZTE MSC1/
VLR. Signaling tracing showed that after HLR
sent insert subscriber data to VLR and VLR sent
back subscriber data insert Ack, HLR did not send
Update location Ack. The operator checked the
subscription information of this user but found no
exception. Switching this user to another MSC\VLR
system also proved useless.
www.zte.com.cn
PDP address type (0: dynamic, 1: static)
IP address (valid when PDP address is
static, ignore it when PDP address is
dynamic)
The three parts should be separated
with one or more spaces or tabs.
Solution
Engineers input the subscriber
information in correct format into a text file,
and then successfully set PDP contexts in
batches.
Analysis
1. CUG refers to Closed User
Group. Its purpose is to restrict network
communication in the group. Users mainly
contain multiple CUG members (the
maximum is 10). Normally, the members
can only communicate with each other
within this group, but can not communicate
with a user out of the group unless the
user has subscribed for extra functions,
GSM Network Products 33
August 2007 Issue 52 Fault Instances
for example OA and IA. Communication
restriction is also available for the
members of a group by subscribing for
OCB or ICB.
2. Concerning inserting user data,
protocol GSM0902 regulates:
In any dialogue, the first insert
Subscriber Data message which contains
CUG information shall include a non-
empty CUG-SubscriptionList.
Th i s i n stru cti o n i n d icates that if
user data ISD req in the first package
inserted contains CUG information, CUG-
SubscriptionList should not be null. There is
no much restriction on the second package.
3. By analyzing the signaling stream, it
was found that the peer end HLR sent two
ISD req messages, both containing CUG
information. That is to say, the detailed
CUG subscription information existed
and was inserted at the first package
and Siemens HLR inserted CUG label
in the second package. The point is,
due to the capacity of one package, the
content was divided into two packages
and the division point was in-between
34 Maintenance Experience
CUG information. So the first package contained
the detailed content of CUG SubscriptionList, while
the second package contained CUG FeatureList.
As CUG SubscriptionList is a necessity of CUG
information, the second package contained a
label of SubscriptionList. ZTE VLR did not support
signaling whose subscriptionList was 0 in the
second package. This resulted in the failure in
decoding and the failure in location update.
4. Now it can be concluded that it was a
compatibility problem on MAP processing in GSM
protocol. The failure was caused by the different
understandings to this protocol by ZTE MSC and
Siemens HLR.
Solution
1. If there are not too many users of this kind, a
temporary solution could be adopted. First do not
provide this user with CUG service or provide this
user with only a part of CUG service, then after
successful location update, add CUG service for
the user. In this way, one message, which contains
all the CUG information, is inserted into VLR by
HLR and the location can be updated successfully.
2. This problem will be solved in the next
version update by ZTE.
 www.zte.com.cn

Subscriber Couldnt Access the

Network After HLR Cutover
Duanmu Xiaoting, ZTE Corporation

Symptom length had some errors.

International roaming subscribers could not
access the network after the cutover of a new HLR.
And before the cutover, the network was normal.
Analysis
1. Subscription information was checked. It
was found the subscribers had the authority for
international roaming.
2. According to the roaming area information
provided, the engineer checked HLR configuration
and confirmed that country codes allowing roaming
and access numbers have no problem.
7. GT length was checked and it was
found that a GT was 3 digits to 19 digits
in length. So all the international numbers
of one digit length (numbered from 1 to 9)
had a problem.
Solution
The GT length was changed to 1 digits
to 19 digits. After synchronization, no
more SCCP notifications appeared and
the international roaming service became
normal.

3. Signaling trace on a single subscriber

showed that the process stopped when the
international office requested authentication at
first and then HLR returned three authentication
parameters. The HLR did not receive the location
update request.
4. It was doubted that the authentication
parameter signals were not sent to the switch at
the roaming area. So the engineer asked HSTP
office to check if the HLR successfully sent these
signals to the destination. Later, the engineer knew
HSTP had not received these signals.
5. After analysis, it was doubted that the HLR
had not sent out the authentication parameters
successfully, although they were generated.
6. Alarm observation showed many SCCP
notifications in the alarms and that the roaming
area GT41794908000 tracked was also in the
alarms. Analysis on SCCP notifications showed
that the problems all resulted from the international
numbers. So it was estimated that the setting of GT

GSM Network Products 35

August 2007 Issue 52 Fault Instances

Illegible Codes Appears When

the Network Management
Client Runs HLR Configuration
Management
Duanmu Xiaoting, ZTE Corporation

Symptom language of this computers operating system was

Illegible codes appeared when a client Cyrillic, which was not consistent with the language
was running HLR configuration management. applicable in ZTE software.

Analysis
1. The fault did not disappear after the
client software was reinstalled.
2. REGIONAL OPTIONS were
checked and it was found that the default
Solution
1. The default language was changed to West
Europe and United States.
2. Then the computer was restarted. The
problem was solved.

Unsuccessful Cross Number

Assignment on the two HLR
Databases
Duanmu Xiaoting, ZTE Corporation

Symptom configuration, it was found that the two database

The two database nodes 170 and 175
could not make cross number assignment
successfully.
Analysis
1. By checking the number segment
nodes were in the same number segment, which
was correct. And it was also found that the nodes
connected to each other successfully. But an
error occurred when the following commands
were executed on node 170 to update the system
variables on node 175, indicating that the MSDTC

36 Maintenance Experience

process was not running well.
set xact_abort ON
begin tran
update hdb175.hlrdb175.dbo.sysvar set
vinteger=0 where id=1
commit tran
2. MSDTC processes on the two nodes were
Subscribers Could not Modify
Access Mode in HLR
Su songme, ZTE Corporation
Symptom
An office complained that the agent could
not modify the network access mode of some
subscribers. DBIO returned a database execution
failure message when the access mode was
changed from the GSM only to both GSM and
GPRS. The engineer checked OMMSEE and found
conflicted primary keys. But the network access
mode of the subscribers whose numbers were re-
assigned on the local agent could be changed
successfully.
Analysis
1. After accessing the network by dialing up, the
engineer queried table GPRSINFO with the given
numbers and found that the subscribers IMSI and
ISDN already existed in the table.
2. In a normal condition, if the subscribers
have just subscribed for GSM network access
mode, tables GPRSINFO and PDPINFO contain
no records of these subscribers. The engineers
executed the following commands with a query
analyzer and found that tables GPRSINFO and
www.zte.com.cn
checked and it was found they were in
manual status and were not running.
Solution
The problem was solved after
running the MSDTC process on the two
computers.
PDPINFO had subscriber data and the
access mode was GSM only. That is to
say, subscription data of the subscribers
were not consistent:
select count(*) from baseinfo where
nam=1 and imsi in (select imsi from
gprsinfo)
select count(*) from baseinfo where
nam=1 and imsi in (select imsi from
pdpinfo)
nam=1 denotes querying subscribers
who access GSM only. And 2689 records
were found, which do not accord with the
data consistency.
3. The engineers did not find problems
of this type any more after modifying the
access mode and assigning numbers. So
they estimated that the problems resulted
from the wrong number assignment.
Solution
From the queried result, it was
necessary to clear up 2689 inconsistent
GSM Network Products 37
August 2007 Issue 52 Fault Instances
d a t a i n t a b l e G P R S I N FO and table
PDPINFO. Before doing so, the local
database need to be backed up, and then
the HDB data on node 150 need to be
copied to node 129. The procedure is as
follows:
1. Back up HDB on node 150 locally
and copy it to node 129.
2. Select the subscribers needed to
be deleted in table gprsinfo (please select
HLR subscriber database on node 150).
Select count (*) from gprsinfo where
imsi in (select imsi from baseinfo where
isdnnum<>0 and nam=1).
3. Check if there was a trigger for
deleting in table GPRSINFO by opening
the trigger in the table.
VPN Subscribers Could not be
the Calling Party When Roaming
Chen Yubin, ZTE Corporation
Symptom
VPN subscribers could not be the
calling party when roaming.
Analysis
For the VPN subscriber roaming,
HLR will insert CAMEL information during
location update if the VLR of the called
party supports CAMEL2. Then, HLR will
trigger the intelligent service according
to the subscribers OCSI information in
VLR. But, for the problems in operator
network, the signal triggered could not be
sent successfully from SSP to SCP, thus
38 Maintenance Experience
4. Delete the subscribers with inconsistent data
by executing the following sentence (select imsi
from baseinfo where isdnnum<>0 and nam=1).
After deleting every time, please check the returned
results. If some errors presented, note them down
and tell ZTE personals.
5. Execute the select sentence in step 2
to check if there were inconsistent data in table
GPRSINFO.
6. Execute the following sentences to check if
there were inconsistent data in table PDPINFO:
select count (*) from pdpinfo where imsi in (select
imsi from baseinfo where isdnnum<>0 and nam=1).
7. Delete the rest inconsistent data with the
same method. After clearing up the junk data in
GPRS and modifying the subscriber access mode,
the problem was solved.
resulting in call failure.
Solution
Since VPN subscribers are usually VIP users, it
is recommended to subscribe continue CALL instead
of release CALL. The advantages are as follows:
Calling could be continued in case of failure in
triggering services.
When the subscribers make a local call, it can
also prevent wrong charging by continuing the
CALL instead of answering the CALL when the
trigger service failed.
If SCP is down, allowing continue CALL will not
influence the VIP services.

Echo Appearing for Outgoing
Calls
Duanmu Xiaoting, ZTE Corporation
Symptom
Echo appeared when outgoing calls were
made.
Analysis
1. Echo appeared when some outgoing calls
were made, but no echo appeared for intra-office
calls. This symptom indicated that the problem was
associated with CN instead of RNC.
2. Echoes were found just recently. It was
doubled that the problem resulted from a 2M
outgoing line which was added recently.
Unsuccessful Location Update
for Roaming
Chang Tao, ZTE Corporation
Symptom
Mobile subscribers could not access the
network under the control of VLR of other
equipment when they were roaming. It became
normal after their data had been deleted.
Analysis
The signals were checked and it was found
that there were nine supplementary services in the
data inserted, but there were only six after deleting
their data and assigning numbers again. So, it was
doubted that HLR sent an XUDT message, but
the equipment of the called party did not support.
www.zte.com.cn
3. Although the newly added 2M
outgoing line was connected to DTEC, a
new PP program was loaded again. So
the problem must result from wrong DTEC
jumpers.
Solution:
The board is B0107; the right jumper
should be set at pins 1 and 2. But the
actual jumper pins were pins 2 and 3.
Echo disappeared after resetting the
jumpers.
As expected, by tracking SCCP of HLR,
the engineer confirmed that HLR had sent
XUDT message and the equipment of the
called party gave no response.
Solution
1. The TM PACKET size (under security
variablesTM variables) was changed to
140 for the first packet, and the size of the
second packet was set to 190.
2. The HLR did not send XUDT
message after the above modification, and
the location update was normal.
GSM Network Products 39
August 2007 Issue 52 Fault Instances
Difficulty in Making Calls at
Busy Hours Under an HLR
Zhou Quan, ZTE Corporation
Symptom
An HLR office reported that subscribers
under this office had difficulty in making
calls at busy hours, and the office failed to
modify data through BOSS.
Analysis
1. Alarms checking showed alarms of
overhigh UB occupancy and serious traffic
control while actual traffic was just a little
heavier and almost as usual.
2. It was guessed that the problem
HLR System Error Occurred in
Service Subscription on Agent
Yang Guang, ZTE Corporation
Symptom
During supplementary service testing,
an HLR system error occurred when
operations service subscription, service
activation through terminal (when
acknowledgement tone was heard),
service deactivation through terminal
(when acknowledgement tone was
heard), and service de-subscription
through agent were performed for
the third time. The assigned numbers
under test were then unable to be
40 Maintenance Experience
might have something to do with database
performances. Database logs were then checked
and it showed that a large amount of HLRDB170
size was full.
3. The operation failed when trying to apply for
space for tables CAMELINFO and SSDATA, which
explains the failure in BOSS inserting data.
Solution
The BOSS and the database calls became
normal when the size for HLRDB170 was enlarged,
resulting in normal calls.
deleted, some other operations also became
invalid, and signaling trace showed no
information.
Two numbers assigned on agent were found
by checking R_PCSSSDATA while only one
number was found by checking R_PCSSSINFO
and again two numbers were found by checking
physical r_pcsssinfo. All operations became
normal again after HSDB restart. But the
operations might be performed twice only and
then the HLR system error would appear again if
the operations were performed for the third time.

S10SEE showed:
Pno:104, Module:dbiosrv, LEVEL:3, Client
type:AGENT, Client node:151, Operator:
HLR, ErrCode:150103, ErrInfo:HSDB
operate failed(ErrCode:108). memory DB not
synchronized to physical DB, Operate failed,
MML: MOD PUSEREX: PSID=481243601118,
DynDataFg=1, ASS=0
Analysis
1. The following operations were performed:
Failure observation
Checking capacities of tables in network
management system configuration data.
Checking configuration of service server
node (DB/DBE nodes are configured separately if
DB_DBE separation is selected).
Checking DBIO configuration file (checking
HSDB connection also if HSDB module is
configured on foreground).
Checking DBE configuration file (similar to
checking DBIO).
Checking connection between DBE and
foreground and connection between DBE and
DBIO by running S10SEE on the micro computer.
It was finally found that DBE did not
communicate with the foreground and that S10SEE
showed all connections with the foreground were
www.zte.com.cn
CLOSED. The causes of Memory DB
not synchronized to physical DB were
hereby found.
2. According to S10SEE print
information it was obvious that the
physical database was not synchronous
with the memory database. Since the
foreground memory database reads
the physical database once the HSDB
restarts, the subscription operations
may be performed successfully within
a short period of time. But after several
times of subscription and de-subscription
operations the memory database changes
can not be synchronized to the physical
database, and hence no more subscription
operations may be performed.
Solution
1. Static route was modified and actual
office ID was added to the monitor script,
as shown below:
DEST=130.0.0.0
NETMASK=255.0.0.0
GATEWAY=129.0.2(Office ID).100
2. The problem was solved and
the DBE communicated well with the
foreground.
GSM Network Products 41
August 2007 Issue 52 FAQ
How to Analyze the Location
Update Faults
Wang Dankai, ZTE Corporation
A: If only concerning the faults occurring
at the switching side, analyze the fault
from the following aspects:
1. The link at the A interface is faulty,
resulting from the transmission or the
abnormal working status of the board;
2. No number analysis is performed on
the IMSI;
3. Through the signaling tracing, it
How to Handle Unclear Blocked
Signaling Links
Wang Dankai, ZTE Corporation
A: If the signaling link is unclear, the
engineer can handle it in the following ways:
Check whether there is any alarm in
the transmission system of the PCM
system where the signaling link is
located.
Check whether the link IDs, timeslots,
and transmission system IDs of the
local office and the opposite-end office
are consistent.
Check whether the transmission
42 Maintenance Experience
is found that the opposite-end does not return
the signaling, without configuring the data of the
local end or returning the authentication response
message;
4. Due to the problem of version compatibility, the
opposite end does process or discard the location-
update-related signaling sent from the local end;
5 . R e s t r i c t e d b y t h e V L R c a p a c i t y, t h e
subscriber location update fails.
system impedance matching of the PCM
system where the signaling link is located is
correct.
Check whether the local MTP data are correct
and whether the signaling route and the
signaling office direction are configured.
Check whether the links of the local office and
the opposite-end office are blocked.
Check whether inter-module communication is
interrupted.
Check the data of the opposite-end office.
 www.zte.com.cn

How to Set the Dual Seizure

Handling Mode
Wang Dankai, ZTE Corporation

A: The handling mode of the dual seizure should be
negotiated by both sides. The dual seizure handling
mode 1 and the dual seizure handling mode 2 are
provided in the indicator of the trunk management.
If the parity control is adopted by negotiation, select
the dual seizure handling mode 2. At this time, the
office with small SPC seizes the odd circuit first, and
the office with big SPC seizes the even circuit first.
If the sequence control is adopted, select the dual
seizure handling mode 1. In this case, the
office with small SPC seizes the circuit in
the ascending order in each PCM, and the
office with big SPC seizes the circuit in the
decreasing order in each PCM.
After the handling mode of dual seizure
is understood, the specific option is
selected from the Select Method of Trunk
in the trunk configuration.

How to Transfer the Database

Wang Dankai, ZTE Corporation

A: Due to some reasons, it is required to transfer the database to other directory. The path of the
database equipment is stored in the sysdevices table of the master database. Two lines in the
sysdevices table are shown as follows.

low high status cntrltype name phyname mirrorname stripeset

721420288 721440767 2 0 aaa D:\MSSQL\DATA\aaa.dat
721444767 721464590 2 0 aaalog D:\MSSQL\DATA\aaalog.dat

Therefore, to transfer the database, just modify the phyname in this table.
For example, to transfer the above-mentioned aaa database from D:\MSSQL\DATA to E:\
DATA, execute:
use master
go
sp_configure 'allow updates', 1 Allowing modifying the data in the system database
go

GSM Network Products 43

August 2007 Issue 52 FAQ

RECONFIGURE WITH OVERRIDE Configuration takes effect

go
UPDATE sysdevices set phyname = 'E:\DATA\aaa.dat' WHERE name = 'aaa'
UPDATE sysdevices set phyname = 'E:\DATA\aaalog.dat' WHERE name = 'aaalog'
Go If the log and DB exist on the same equipment, only one piece of equipment is needed to
be updated.
sp_configure 'allow updates', 0 Forbiding modifying the data in the system database
go
RECONFIGURE WITH OVERRIDE
Go
Stop the SQL server, copy the file aaa.dat and the file aaalog.dat to the new directory, and then
restart the SQL server.

How to Recover the Database in

the Suspect Status
Wang Dankai, ZTE Corporation

A: If the database is in the suspect status, recover it first through the following way:
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
update master..sysdatabases set status = status ^ 256
WHERE name = dbname
go
sp_configure 'allow updates',0
go
reconfigure with override
go
Restart the SQL. If the database still cannot be recovered, the database is already damaged,
or the database file does not exist. Delete the database first, and then recreate it, and recover it
from the backup file.

44 Maintenance Experience
www.zte.com.cn

GSM Network Products 45