Preface Maintenance Experience

Monthly for GSM Products

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

Fault Instance

Failed to Restrict International Outgoing Call......................................................................................2

MSC Performance Data was Lost.......................................................................................................4

Failed to Enter the Software Management Interface of VCS Dual Servers.........................................5

Frequent Call Drop in one Office.........................................................................................................6

OSB Service Failed.............................................................................................................................7

No Tone on either Side......................................................................................................................10

Wrong Calling Number Displayed in Subscribers Bill....................................................................... 11

Call Failed after Long-time Waiting...................................................................................................12

Failed to Query Bills in Batches........................................................................................................13

Communication Error Codes Appeared Among the Modules............................................................14

Indicators on MSC Alarm Plane Were ON.........................................................................................15

Special Document
How to Expand MSC Single Module to Multi-module........................................................................18
July 2008 Issue 117 Fault Instance

Failed to Restrict International

Outgoing Call
Chen Yu/ZTE Corporation

Symptom local subscriber of one office could also dial the

After the subscriber subscribed the
BIOC flag, the engineer found that the
international call with the format 0086, and only
the international call with the format 1230086 was
restricted.
When performing the interconnection operation
between the V1 MSC on the site A with the V1
HLR and V3 HLR on the site B, and testing the
international outgoing call restriction, the engineer
found that the result was the same.

Analysis and Solution

1. Subscribe the BIOC (Barring International
Outgoing Call) flag on the HLR agent for the tested
number, as shown in Figure 1.
2. C h e c k t h e M S f l a g m e s s a g e f o r t h e
subscriber who subscribed the flag on the VLR.
The message barOutgoCall=2 means that the
Figure 1. Agent-Basic Service subscription was successful, as shown in Figure 2.

 Maintenance Experience
 www.zte.com.cn

3. After the subscriber subscribed the BIOC

flag, the international call would be shifted to the
analyzer. At that time, MSC would query whether
the BIOC flag was subscribed from the VLR and
then decide whether the call was allowed.
On the site, the pre-analysis function was used
to convert the number and to differentiate the
charging rate. In the pre-analysis selector, analyze
the number 0086 and 1230086 as 000386
and 000986, and then enter the 101 originating Figure 2. MSflag Message
number analysis selector. 0003 and 0009 would
be sent to the No. 58 route link (the peer end
judges the charging rate).
When comparing the parameters setting of
these two numbers in each analyzer further, the
engineer found that area attribute of these two
numbers in the pre-analysis was different. The
number 1230086 was analyzed in the entry of
the special number analyzer of the pre-analysis
selector and the Area Attribute is Default
Attribute. The number 0086 was analyzed in the
entry of the long-distance analyzer and the Area
Attribute is International Number.
4. In the international analyzer entry of the
pre-analysis selector, modify the area attribute
of the number 0086 as Default Attribute. After
the modification, the engineer found that the
Figure 3. Analyzer EntryArea Attribute
subscriber under MSC could successfully restrict the
international call when performing the dialing test.

GSM Network Products 

July 2008 Issue 117 Fault Instance
MSC Performance Data was Lost
Sun Jingrun/ZTE Corporation
Symptom
The carrier reported that the
performance data of MSC between 7:40
am and 9:10 am, Sept 5th, was lost and
the number of the VLR subscribers was
also abnormal.
When querying the performance data
on 5th September, the engineer found
that there was no basic traffic data and
the SMS statistics data between 7:40 am
and 9:10 am. The number of the VLR
subscribers was abnormal, as shown in
Figure 1.
Figure 1. Abnormal VLR Numbers
Analysis and Solution
It was doubted that the abnormal
number of the VLR subscribers had
a relationship with the loss of the
performance data. When checking the
serrun.log file on 129, the engineer found
that the performance statistics process
restarted continuously between 5:44 and
6:40, and the last restart time was about
9:10.
Extract the log according to the
following methods:
1. Modify ShowAllLog=1 in the file
mop_pack.ini under the directory zxg10 of
 Maintenance Experience
129 and save the modification.
2. Restart the process smopsrv_col.exe on
the 129 server.
3. Run the file for twenty minutes and
copy the following logs under the directory
zxg10: mopsrv_error.log, mopsrv_info.log,
mopsrv_error.~log, mopsrv_info.~log, oerrlog.zev,
oErrMsg.~ze, SerRun.Log and SerRun.~lo.
4. Under the directory zxg10 of 129 server,
modify ShowAllLog=0 in the file mop_pack.ini ,
and save the modification.
5. Restart the process mopsrv_col.exe on the
129 server.
6. Extract the following data from the 129
database.
use mopdb
select * from mop_msccpudata
use mopdb
select * from mop_msccpudatax
where sdate<'2007-09-05 09:30' and
sdate>'2007-09-05 07:00'
use mopdb
select * from mop_msccpudataxx
where sdate<'2007-09-05 09:30' and
sdate>'2007-09-05 07:00'
use mopdb
select * from mop_msctrafdatax
where sdate<'2007-09-05 09:30' and
sdate>'2007-09-05 05:00' and ntype=0
use mopdb
select * from mop_msctrafdataxx
where sdate<'2007-09-05 09:30' and
sdate>'2007-09-05 05:00' and ntype=0

The analysis result was as follows:
The foreground buffer could only store 2000
packets. The buffer of the foreground was full,
so the data between 7:35 am and 9:10 am were
lost. After 9:10, the server began to receive the
data from the foreground, so these data were
recorded.
Failed to Enter the Software Management
Interface of VCS Dual Servers
Han Jinliang/ZTE Corporation
Symptom
Under the normal condition, the VCS would
start after the command hagui was inputted. At
that time, a new local connection was created. After
clicking the OK button, a dialog box appeared.
Input the user name and the password (admin/
password) to enter the system.
After creating a local connection and clicking
the OK button, the engineer found that a dialog box
appeared. The prompt message was as follows:
====================================
VCS ERROR V-16-10-4
Could not connect to a live system in the cluster
n2401:14141 closing all windows.
====================================
Analysis and Solution
When analyzing the LOG, the VCS engineer
found that the hostname interconnected to the
IP in the /etc/host was not consistent with that
www.zte.com.cn
Aiming at the BDE abnormality, the
engineer analyzed the operating system
log of the 129 server, located the patch
of SQL Server as SP3 and found that the
SP4 patch was not installed. After installing
the patch SP4 patch program, the problem
was solved.
configured in the VCS login interface.
In the host file, it was allowed to
set many hostnames. But at least one
hostname interconnected to the internal
network IP must be consistent with the
hostname inputted in the VCS login
interface.
Edit the /etc/host of two servers and
add the IP address and the hostname for
the peer server:
127.0.0.1 localhost
129.0.12.131 v440-1 loghost
129.0.12.132 v440-2
Experience Summary
When configuring the file /etc/host,
more attention should be paid to the
hostname. At least one hostname should
be consistent with the hostname inputted
in the VCS login interface.
GSM Network Products 
July 2008 Issue 117 Fault Instance
Frequent Call Drop in one Office
Hao Li/ZTE Corporation
Symptom
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 the REL message after the call was
connected for several seconds or dozens
of seconds, and the call was released
at the same time. The reason of the call
release was the network is unavailable or
the network is 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
handover information about MP was
recorded. The MP belongs to PIII, so it
was confirmed that the MP switch was not
caused by the INT13 interruption.
3. After plugging/unplugging and
replacing the SMEM board, the problem
 Maintenance Experience
still existed. In order to reduce the effect, 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 the address=DEFFE
message.
In the control shelf, MP communicated with
other boards in this shelf through different bus
addresses. The corresponding addresses of
different boards were as follows:
D0xxx: SMEM board
D1xxx: the first COMM board
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 meant
that the bus check was wrong. It was doubted that
there was 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.

OSB Service Failed
Wang Ke/ZTE Corporation
Symptom
At present, the subscriber under the local MSC
dialed 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 was only required to dial seven
digits directly, such as 2XXXXXXX, 3XXXXXXX,
4XXXXXXX and 8XXXXXXX.
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 subscribe the OSB service for the
subscriber. Under the Mobile Number Analysis
Configuration > ODB and OSB Service Call
Restriction Number of MSC, 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 were 3, 5, 7 and 9
were restricted.
Analysis
When checking the number analysis
configuration of the MSC, the engineer found that
both the pre-analysis selector and the MO analysis
selector 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 had deleted the digit 0,
so it does not match 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
www.zte.com.cn
the following schemes were given:
1. Under the ODB and OSB service
configuration of MSC, restrict the prefixes
03, 05, 07 and 09.
2. I n t h e p r e - a n a l y s i s , a d d a n
analyzer entry and then analyze the
numbers of which the prefixes 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 prefixes
are 03, 05, 07 and 09. Delete the first
two digits 00 and select Unknown for the
Attribute.
This scheme aimed 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 CC to 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 operations, the long-distance
function was restricted.
For the subscribers who did not
subscribe the OSB service, it was also
required to perform the above pre-
analysis flow when dialing these long-
distance prefixes. However, after VLRMAP
received the number format, such as
0003, sent from CC, it would analyze the
GSM Network Products 
July 2008 Issue 117 Fault Instance

outgoing format of the 0003 in the MT number analysis 3. Subscribe the OSB service for the subscriber in
selector according to the normal flow if the calling the HLR agent, as shown in Figure 3.
subscriber did not subscribe the OSB service. So, it was
required to 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.

Figure 3. OSB Subscription Service

4. Under the Mobile Digit Analysis > ODB&OSB

Service Configuration, configure the restricted digits, as
shown in Figure 4.

Figure 1. Service Configuration Supported by HLR

2. Under the Configuration Management > PLMN

Specific ODB Configuration of HLR, configure the self-
defined OSB service, as shown in Figure 2.

Figure 4. Mobile Number Analysis

5. Under Security Management > VLR Security

Variables, set 2 for Selecting of Call Barring Pattern.
6. In DAS101, select 1 from drop-down list in the
Called New Service Analyzer Entry, as shown in Figure
5. 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
Figure 2. ODB Configuration Diverted Area Attribute, as shown in Figure 6.

 Maintenance Experience
 www.zte.com.cn

7. In the international analyzer entry 4 of DAS101,

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

Figure 5. Digit Analysis SelectorDAS 101

Figure 7. Digit Diversion (Called)

After that, all the data modification is completed. At this

time, the long-distance restriction service is normal.

Figure 6. Digit Diversion (Calling)

GSM Network Products 

July 2008 Issue 117 Fault Instance
No Tone on either Side
Feng Dongwu/ZTE Corporation
Symptom
When using the specified trunk to test
the expanded circuit, the engineer found
that the circuit had bi-directional no tone
phenomenon.
Analysis and Solution
There were three new circuits that were
expanded to the MSC-A, but two of them
had no tone on either side. In general,
this phenomenon had a relationship with
the trunk. Maybe, the trunk circuit was
self-looped or the CIC of the data was
inconsistent.
1. When checking the trunk status in
the dynamic management, the engineer
found that the trunk was in the idle status.
2. W h e n t r a c i n g t h e s i g n a l i n g
message, the engineer found that the
calling and the called IAM message were
normal, and the charging message ANM
existed. Both directions of the call have
10 Maintenance Experience
no tone, so it was doubted that the problem had a
relationship with the CIC.
3. After adjusting the CICs of these two
abnormal circuits, the engineer found that neither
directions of the call had tone.
4. When eliminating the faults of the circuit,
the circuit on the site A had the cross-wiring
problem. After adjusting the circuits, the engineer
found that the test result was normal.
Experience Summary
This is a normal problem, and the possible
reasons are as follows:
1. In general, the no tone problem results
from the abnormal trunk, such as the self-loop
trunk or the cross-wiring.
2. Maybe, the data configuration of the peer
end is incomplete. It is allowed to check whether
the signaling has the charging message. If the
peer end receives the IAM message and sends
the REL message directly, it means that the data
configuration of the peer end may be wrong.

Wrong Calling Number Displayed in
Subscribers Bill
Xu Gaofeng/ZTE Corporation
Symptom
All the subscribers in the whole network of one
office were the prepaid subscribers and the bills
were sorted on the IN side. At present, the version
of MSC was V3.03.004.
At present, some subscribers wanted to
open the postpaid function, so it was required
to install the bill server to sort the postpaid bill.
After installing the charging server, the engineer
found that calling number in the bill coded from
the background had the digit 0. For example,
the normal number was 9235, but the number
displayed in the bill was 920355.
Analysis and Solution
1. First, it was doubted that there was
something wrong with the charging setting table.
After checking the parameter setting of that table,
no abnormality was found.
2. Then, it was doubted that there was
something wrong with the foreground module. The
number 920355XXXX may appear under the
following two conditions:
i. The ServedMSISDN number of MOC was
00920355XXXX.
ii. The ServedMSISDN number of MOC
was 920355XXXX. The number attribute was 1
(international).
3. When performing the query and analyzer
tool of the original bill, the engineer did not find any
TRACE result under the corresponding directory.
The format of the number in the original bill was
correct, which meant that the foreground module
did not have the number problem. The incorrect
codec program of the background resulted in the
incorrect format of the calling number in the bill.
www.zte.com.cn
4. After modifying the name of the file c:/
zxg10/bill/obtezte.dll under the original charging
server, covering this directory with the file
obtezte.dll in the version V3.03.005 (the current
MSC version is V3.03.004), and restarting the
process of the charging server, the engineer
found that the problem was solved.
Experience Summary
The original CDR view is shown in Figure 1.
Instructions:
Figure 1. Original CDR View
1. I t i s a l l o w e d t o c l i c k t h e b u t t o n
Directories to set the path of the original
path. The directory of both QueryResults and
Trace cannot be set through the interface.
QueryResults is used to save the query result.
Trace is used to save the result of the trace bill.
These two directories only can be set through
modifying the configuration file obcdrman.ini.
2. Save the query result to the directory
QueryResults. The file name includes the date
and the time.
GSM Network Products 11
July 2008 Issue 117
Call Failed after Long-time Waiting
Chen Yunlong/ZTE Corporation
Figure 1. Signaling Trace (calling)
Figure 2. Failure Reason Value
Figure 3. Security Variable Value
Figure 4. Signaling Trace (called)
Figure 5. mcaPAGING_M Message(1)
12 Maintenance Experience
Fault Instance
Symptom
The client reported that the call failed after a
long time waiting when the MSC was busy.
Analysis and Solution
1. When tracing the signaling of the calling
subscriber at the port A, the engineer found that
MSC sent back the DISCONNECT message to
BSC, as shown in Figure 1. The failure reason was
normal,unspecified, as shown in Figure 2.
2. The paging times set in MSC security
variable was 2. The value in Figure 3 minus 1 was
the times of re-paging.
3. W h e n t r a c i n g t h e s i g n a l i n g f o r t h e
called party, the engineer found that two paging
messages were sent by MSC (the second paging
was sent three seconds after the first paging), as
shown in Figure 4. The MSC did not receive the
paging response message after ten seconds, so it
sent the DISCONNECT message to BSC.
4. The MSC paging mainly aimed at LAC.
After clicking the mcaPAGING_M message, the
engineer could see that LAC was 3E9, as shown
in Figure 5 and Figure 6. This LAC was attached
with three BSCs, so three PAGING messages
could be seen.
 www.zte.com.cn

Experience Summary
From the signaling tracing, it was known that
the wireless side did not give response to the
PAGING message sent by MSC, which resulted
in the call failure. The failure reason needed to
be checked by the wireless side and it had no
relationship with the MSC side.
In additional, the time interval between the first Figure 6. mcaPAGING_M Message(2)
paging message and the second paging message
was three seconds in the old version of MSC. A MSC V3.04.12.P21.B1, and it could be used to
new timer T169 was added in the new version modify the time interval of the paging.

Failed to Query Bills in Batches

Chen Yu/ZTE Corporation

Symptom
When querying the bill of a whole day from the
charging management system on the charging
client in batches, the carrier found that the capacity
of the bill query system was restricted (the default
value was 5M), as shown in Figure 1. At this
time, the bill of a whole day could only be queried
section by section according to the time. The
carrier required to expand the upper limit capacity
Figure 1. Warning
of the bill.

Analysis and Solution

The file c:\zxg10\bill\querycfg.ini on the client
had the related configuration options, and they
could be used to adjust the upper limit value. If the
upper limit value was too large, the query may take
a very long time. On the site, the engineer could
modify it to a proper value according to the real
conditions.
The field in the file was as follows:
//the max length of the decode files(KB)
[Que_MaxSizeDecodeFiles]
Value=5000
On the site, the capacity of the bill was only
35M, so the changed value 50000(50M) could
meet the requirement.

GSM Network Products 13

July 2008 Issue 117 Fault Instance

Communication Error Codes Displayed

Among the Modules
Chen Yu/ZTE Corporation

Symptom module 4 and module 1 had the error message

On the site, when the single module Modules communication message has error code
of MSC was expanded to more modules, continuously. The phenomenon resulted from
the engineer found that the peripheral the MPMP (the communication board among the
modules) board of these two modules.

Analysis and Solution

The alarm appeared with a certain frequency.
On each board, this alarm appeared every fifteen
minutes (few alarms appeared every twenty
minutes or thirty minutes). Module 3 had no alarm.
When checking the status of the MPMP board
according to the tool Moniproj.exe, the engineer
found that the alarm display had a relationship
with the received error record, as shown in Figure
1. When a new error record generated, an alarm
would appear after a period of time (such as fifteen
minutes).
Figure 1. MPMP Board Status When trying to adjust the software and

14 Maintenance Experience

exchange the communication port 1 and the
communication port 2 of the adjacent office
connected to module 3 and module 4, the problem
still existed. When replacing the MPMP boards for
module 1 and module 4 with that of module 3, the
problem still existed. All the above meant that the
problem had no relationship with module 1. When
checking the connection of the cable, the engineer
also did not find the problem.
In the physical configuration, when adjusting
the HW time delay on module 4, the engineer
found that the problem still existed. Note: it was
only required to adjust the HW occupied by the
related board, the 4~19 HW and the 68~83 HW
could be adjusted. It was not required to adjust the
HW corresponding to the DT; otherwise, the DT
board would not be started.
The DDSN/DSNI/FBI board also had a
relationship with the communication of the
Modules. module 4 was a new expanded module,
so it was doubted that there was something wrong
with the board on module 4.
Replace the DDSN/DSNI/FBI boards on module
Indicators on MSC Alarm Plate Were ON
Chen Yu/ZTE Corporation
Symptom
When expanding the MSC on the site, the
temporary 129 server was replaced. After the
expansion, the engineer found that all the services
were normal but all the indicators on the alarm
plate were ON.
www.zte.com.cn
4 with that of module 3, and check whether
any error code appears (within fifteen
minutes or more) with the tool Moniproj.
exe.
In the end, the engineer found that
two DDSN boards on module 4 resulted
in the alarm. If these two network boards
worked as the active board, the alarm
would generate on the corresponding
module. The error code received from the
MPMP board of the module could be seen
through the tool Moniproj.exe. When these
two network boards worked as the standby
board, this alarm would not appear.
The problem could be solved after the
fault network board was replaced.
Note: When replacing the network
board /SDNI/FBI at night, maybe E1
will lose synchronization, the link will
be broken, which will further have an
influence on the service.
Analysis and Solution
In general, if the background 129
server was not connected, all the
indicators on the alarm plate would be ON.
When the alarm plate was connected to
the switch, it would communicate with the
GSM Network Products 15
July 2008 Issue 117 Fault Instance
server.
When installing the background
program on the client, the prompt
message whether to control the alarm
plane appeared. If you select YES, the
server would establish the connection with
the alarm plate.
If the alarm plate was not installed
during the installation, but it was required
to install the alarm plate, you could modify
the information of the registry.
The steps are as follows:
1. Open the registry editor, and then
modify the option of the Alarm Plate under
the directory HKEY_LOCAL_MACHINE\
SOFTWARE\ZXJ10B\ALARM\. If the
value is 1, it means the alarm disk is
controlled. If the value is 0, it means the
alarm is not controlled.
2. After the registry is modified,
restart the alarm service process on the
server.
Experience Summary
1. The 129 server connects with
the alarm plate through the following two
methods:
i. Connect the 129 server with the
alarm plate through HUB. Under these
conditions, the alarm plate uses the default
IP address allocated by the program, and
it is not required to configure the alarm
plate.
ii. Connect the 129 server with the
alarm plate through double network cards.
That is to say, use the crossover network
cable to connect the alarm plate with
the second network card of the server.
At this time, it is required to allocate an
exchange number Y for the alarm plate.
The exchange number Y could be set after
the server is installed.
16 Maintenance Experience
When installing the fault management module,
the installation program will display the prompt
message Whether to configure multi-exchange
alarm plane after the prompt message whether
to control the alarm plane appears. At this time,
select YES.
When the installation program needs to input
the exchange number of the installation exchange,
please input Y. This is the number that is allocated
to the alarm plate.
If it is required to change the exchange number
Y after the background program is installed, you
can modify the file omccfg.ini under the directory
ZXG10:
[AlarmPlate]
Office=Y
Note: Y is the exchange number of the alarm
plate.
Note: After modifying the configuration file,
it is required to restart the alarm service process.
After installing the alarm plate, it is required
to allocate an IP address for the alarm plate. The
details are as follows:
If the IP address of the server is X1. X2. X3.
X4 (this IP address should be configured for the
first network card of the server), it is also required
to allocate an IP address X1. X2. Y. X4 for
the second network card that is connected with
the alarm plate directly. In which, X1. X2. X4
correspond to that of the server. Y is the exchange
number allocated to the alarm plate.
After the alarm plate is configured successfully,
you can open the background process oaSrv.exe
and check whether the connection with the alarm is
successful.
When double clicking the Alarm Plane Status,
you can see the status of the current alarm plane.
If the status is abnormal, you can check whether

the corresponding configuration was normal.
2. Configuring the remote alarm plate.
In the latest version of the background, the
system provides the function of the remote alarm
plate. That is to say, the alarm plate could be
configured on the client or the remote O&M agent
in order to facilitate the maintainers.
During the remote alarm plate configuration,
the connection mode between the alarm plate
and the client or the remote O&M agent is just the
same as that described in the above context. But it
is required to allocate an IP address for the alarm
plate on the O&M agent no matter whether the
alarm plate is connected to the O&M agent through
the HUB or the dual network cards.
In the main interface of the fault management
system, after selecting the menu Setting > Other
settings, the corresponding dialog appears.
When configuring the remote alarm plate, it is
required to check Remote client attaches alarm
plate first, and then allocate an IP address for the
alarm plate.
If the remote alarm plate is connected to the alarm
plate through HUB, the IP address configuration of
this alarm plate is very flexible. This IP address only
needs to be in the network section of any IP address
configured in the PC of the alarm client.
If the remote alarm plate is connected to the
alarm plate through dual network cards, the first
www.zte.com.cn
three sections of the IP to be configured
should be consistent with that of the
second network card (the network card
connecting to the alarm plate) in the O&M
agent, and the fourth section could be
configured at random.
After the remote alarm plate is
configured, the server also could control its
own alarm plate. These two alarm plates
have no influence on each other when
they run.
3. Normal Problems.
During the usage of the alarm plate,
the alarm plate often had the reset
phenomenon, which caused that five
indicators on the alarm plate were ON.
This phenomenon resulted from the
abnormal alarm process on the server.
The abnormal process of the alarm
service was caused by many reasons.
In general, the bad performance of the
database could result in this phenomenon.
This phenomenon was improved greatly
after the alarm program was optimized. In
additional, the abnormal modules, such as
the performance statistics and the network
management of OMC could damage BDE,
which may further result in the abnormality
of the alarm server.
GSM Network Products 17
July 2008 Issue 117 Special Document

How to Expand MSC Single Module to

Multi-module
Chen Yu / ZTE Corporation

1 General Planning check, data backup, installation and debugging of

The reconstruction from a single
module to multi-module includes three
phases:
i. The preparations before the
reconstruction include the hardware
the hardware and the data configuration.
ii. Cutover before the reconstruction and
during the normal reconstruction.
iii. Adjustment after the cutover.
The architectures before and after the
reconstruction are shown in Figure 1.

2 Preparations before
Reconstruction
2.1 Checking running status before the
reconstruction
(1) MSC/VLR system check
1) Check the historical alarm records to see
whether there are some serious faults in the recent
two weeks.
Figure 1. Architecture Instance 2) Check the performance statistics to see

18 Maintenance Experience

whether the traffic statistics in the recent week is
normal.
3) Check whether the parameter setting of the
SQL Server on the O&M server and the charging
server meets the requirement.
4) Check the running status of the charging
server. Check whether the charging bills of the
current day received from the foreground and
sent to the charging center are normal. Check the
file oblog.log and the file obaecur.log under the
directory C:\ZXG10\TRACE on the charging server
131 and 132 to see whether they have some
abnormalities.
5) Check the running log of each module MP
from the foreground to see whether there are some
abnormal running records in the recent two weeks.
If the device has no essential problems, it is
allowed to arrange the reconstruction. Otherwise, it
is required to handle the hidden troubles before the
reconstruction.
(2) Check the hardware of the reconstructed
device
1) Check hardware device
First, confirm whether the hardware required
by the reconstruction is completely prepared. The
hardware includes: all boards of the new rack, the
added FBI board of the old rack, COMM board,
the optic fiber used to connect the center rack and
the original single module, the HUB for debugging,
one PC for debugging, the version software of the
current network and the software system to be
installed.
On the site, if the MP model is inconsistent (for
example, the original 2# module is PII MP, but the
new module is PIII MP), it is required to unify the
MP model to ensure that the MP model of each
module is consistent.
2) Check hardware connection configuration
i. For the fiber connection between the
periphery module and the center module, the fiber
from each periphery module to the center module
should be on a pair of CFBI board separately.
www.zte.com.cn
ii. For the original module 2, put
the reconstructed FBI board and the
COMM (MP level) board to the slot of the
corresponding shelf, but do not insert them
(that is to say, do not power on them).
Connect the fiber to the correct location
and label it clearly.
iii. During the reconstruction, the new
HUB should be close to the old HUB
in order to facilitate the network cable
modification. After the reconstruction,
the adjustment operation is easy and the
processing flow meets the requirement.
3) Prepare the clock plan
For the clock adjustment, it is required
to prepare the plan before the expansion
and the reconstruction, such as, the
board adjustment, the cable layout. If this
operation is neglected, the expansion and
the reconstruction time will be delayed, the
clock adjustment will fail or the expansion
and the cutover will fail.
i. For the BITS clock used by the
original single module, it is required to
adjust the CKI board from the original
single module to the center module during
the expansion and the cutover, and it
is also required to lay the cables to the
center module in advance. At this time, it
is required to extract the clock from BITS.
It should be noted that the imported BITS
clock should have 2-channel input at
least. It is allowed to select 2Mb and 2Mhz
according to the details of the carrier. It
is required to pay more attention to the
impedance match of CKI board. The
unmatched impedance will degrade the
BITS clock of the system and will further
affect the steady running of the system.
ii. For the E8k clock used by the
original single module, the clock
of the original module 2 is the E8k
GSM Network Products 19
July 2008 Issue 117 Special Document
clock extracted from E1 by the SYCK
board. During the expansion and the
reconstruction, it is required to perform
the following adjustment in that evening.
The adjustment steps are as follows: the
SYCK board of the center module (the
new module 2) extracts the clock from E1,
and then module 2 distributes the clock
through the CFBI board, the FBI board of
each MPM module and the SYCK board of
each MPM.
4) MSC system backup
Back up the original ZXG10 directory
of the O&M server to the disk D.
Back up the directory C:\ZXG10 of
the active/standby charging server to
the directory D:\ of the active /standby
charging server.
Back up the important database on the
129 server
Basic configuration database
ZDB_ZXJ10
Performance statistics database
MOPDB
Alarm database MOAMSSDB
Back up the charging database
MOBMSCVLRDB and record the
parameter values in the table SETTING
Figure 2. Circuit Group Statistics
20 Maintenance Experience
(save it as the text file). You can check the file
through the tool OBDBTOOL.
In the basic configuration management system,
back up the configuration data (note: adopts the
BCP method and the SQL normal method).
Record the value of the variables in the variable
management system (you can save all the values
or the changed values, and check whether the
value in the generated file is consistent with that in
the variable management system).
Record the parameters of the timer. You can
save all the values or the changed values.
Record the data configuration of the link and
the trunk group from MSC system to each office
direction.
It is required to install the 129 server again
because of the capacity expansion. At this time,
the engineer should check whether there is
the tone script file msctone.sql used during the
commissioning on the site.
If the performance statistic has the congestion
setting, it is required to record the statistics
items that need to be enabled or disabled by the
performance statistics. The engineer should pay
more attention to the collection items that need to
be enabled by the carrier, such as, each circuit in
the circuit group statistics and the office direction in
the office direction data, as shown in Figure 2.
Record the setting of the stream control
(execute c:\zxg10\loadctl.exe on OMM server).
2.2 Installing and debugging the
reconstruction device
(1) Debug Process
1) Debug MP.
2) Check the board.
3) Check and update the MP board and the
PP board.
(2) Install the new expanded system
1) Install the new 129 O&M server.
Use one PC as the temporary 129 server of
MSC. The data, such as, the office number, should

be the same as that of the current 129 server.
Install the version of the current office. If there is no
new PC and no other PC to replace the temporary
129 server, the MSC O&M agent could be used.
2) Network connection.
Module 1, module 2, module 4 of the
foreground and the new background 129 server
comprise a new MSC through a new HUB. Both
the network cables and the HUB should be close to
the rack of the server in order to facilitate the wiring
after the normal reconstruction.
3) Make the MP for module 2, module 2,
module 3 and module 4.
During the real reconstruction, module 1,
module 2 and module 4 of the foreground are new,
and module 3 is reconstructed from the original
module 2. The configuration file omc.cfg under the
directory CONFIG used by module 1, module 2 and
module 4 should be consistent with that in module 2.
But, the option Version= in the file Version.cfg is
configured according to the module.
Module 1: Version=MSC&&VLR
Module 2: Version=MSC
Module 4: Version=MSC
Whether the file tcpip.cfg adopts the Ethernet to
communicate depends on the setting of the site.
The version of the MP under the directory
VERSION of each new module is the same as that
of the original module 2. In general, the PP version
of module 4 is the same as that of the original
module 2, but it is also required to check whether
the PP boards of these two modules are the same.
It is required to check the PP version of module 2
according to the real board.
Use one MP of the module 4 as one MP of
module 3. During the reconstruction, the single
MP of both module 3 and module 4 run normally.
After the successful reconstruction, use one MP of
module 2 as the standby MP of module 3, and use
the other MP of module 2 as the standby MP of
module 4.
The following must be paid attention to during
www.zte.com.cn
making the MP:
After the MP is made, put a clear label
on MP in order to facilitate the later
debugging.
The running mode of MP meets the
requirement.
4) Configuring data on the new O&M
server.
The engineer could configure all data
again or restore the data to the new O&M
server and then modify the corresponding
data. Perform the following steps to modify
the restored data.
Reserve the exchange configuration,
the number analysis, the mobile
number analysis, SCCP configuration
and LAI configuration.
Delete all trunk configurations and the
MTP configuration. It is required to
record all original configurations before
the deletion.
Delete all physical configurations
and then perform the corresponding
configuration according to the board
slot of the real rack, such as slot 1, slot
2, slot 3 and slot 4.
Because a center module and a
peripheral module are added, so the
attribute of the original module 2 is
changed. At this time, it is required to
delete the original physical configuration
and perform the physical configuration
again. It is required to delete all trunk
circuits and the signaling links in all
configurations before deleting the physical
configuration; otherwise, it is not allowed
to delete the physical configuration.
Configure the physical data again
and connect the networking. During the
communication configuration among the
modules, the number of the communication
module used by the peripheral module is
GSM Network Products 21
July 2008 Issue 117 Special Document
2. The HW time slot on the board of the new
module 3 should be consistent with that of
the current network.
Configure the capacity of the office again.
Configure the capacity for VLR again
(apply for the password to modify the
capacity of VLR), and put VLR on
module 1.
Configuring the signaling link and the
trunk data again.
This configuration should be consistent
with that of module 2. That is to say, change
the number of the module from 2 to 3, but
the other data should be consistent.
In the basic data configuration, the
number of the module that belongs to
the BSC configuration is 2. After the
adjustment, it is required to modify the
number as 3.
5) Debugging.
It is required to debug the data after the
data configuration. Use the three racks of
module 1, module 2 and module 3 to perform
the debugging.
Put the MP of module 3 and module 4
on module 4. At the same time, adjust the
location and the fiber connection of the
corresponding CFBI board. Adjust other
boards according to the conditions on the
site. Try to simulate the environment of
module 3 and module 4 according to the
rack of module 4. Synchronize the data of all
tables and perform the test.
Use the tool to check whether the
resource in each module or among the
modules is normal. Use the tool MONIPROJ
and the diagnostic and test program to
check whether the communication among
module 1, module 2, module 3 and module 4
is normal. In the fault management system,
observe whether the board of module 1,
module 2, module 3 and module 4 is normal.
22 Maintenance Experience
After the debugging, connect the fiber of both
the original module 2 and the new module 2. At this
time, it is not required to power on the FBI board
on the original module 2. Connect the fiber of both
module 4 and the new module 2.
6) Tone adjustment.
The temporary 129 server is new, so it is
required to re-load and adjust the tone script
msctone.sql. After performing this script in the
script analyzer, it is required to check whether the
service tone edit item and each KB edit item are
consistent with that in the tone table maintenance
service of the original 129 server; otherwise, the
tone play after the cutover will fail.
In the tone table management, it is also
required to re-select or add the service tone type
for the tone board unit; otherwise, the tone cannot
be played after the cutover.
7) Modify the security variables and the timer
according to the backup security variables and
the timer. After the modification, it is required to
synchronize them with the foreground (When using
one MP of module 4 as one MP of the module 3, it
is also required to synchronize the security variable
and the timer on the rack 4).
8) Adjust the performance statistics items
and the alarm filtering items on the temporary 129
server and keep them consistent with the original
129 server.
9) Adjust the stream control parameters and
keep them consistent with that on the original 129
server (with the tool loadctl.exe).
3 Reconstruction process
3.1 Reconstruction steps
1) Generate the bill from the foreground by
manual, and start the 130 charging program from
dual servers (viz, power off the charging process of
the background).
2) Power off the active/standby MP of the
original module 2, and unplug the active/standby
MP. Replace them with the debugged module 3.

Do not power on them.
3) Unplug the network cables of the original
129 server (all the cables of the dual network cards
should be unplugged), unplug the network cables
of the temporary 129 server from the new HUB and
plug them into the HUB of the original 129 server.
4) Unplug the MP dual network cables from
the new HUB of module 1, module 2 and module
3 and plug them into the original HUB according to
the former planning.
5) Move the CKI board of the original module
2 to the new module 2. Module 3 and module 4
extract the clock from FBI board.
6) Power on the FBI board and the COMM
board (MPMP) of the original module 2 (the new
module 3).
7) Module 3 starts the MP and synchronizes
all tables again. It restarts the MP and re-
synchronizes all the tables. Each restart operation
is done after the MP starts the alarm. When it is
required to restart the VLR module and there is a
PPS subscriber, it is allowed to restart the active
MP after the synchronization alarm of the active/
standby module disappears (VLR subscriber data
synchronization).
8) Synchronize the security variables of all
the modules and verify them. Check whether the
timer is set just the same as before.
9) Use the test tool to check whether the
resource of module 3 is normal. Use the tool
MONOPROJ and the routine test program among
the modules to check whether the communication
among module 3 is normal. In the fault
management system, observe whether the board
of module 1 to module 4 is normal.
10) Perform each kind of service test and
record the result (check whether the voice plays
normally).
11) After the call test is confirmed, back up the
file omccfg.ini under the directory C:\ZXG10 of the
active/standby charging server, and then copy the
file omccfg.ini under the directory C:\ZXG10 of the
www.zte.com.cn
new 129 server to the directory C:\ZXG10 of
the active/standby charging server. Start the
charging server progress of from the dual
servers and check the generation of the bill.
12) Switch the dual charging servers
and check whether they run normally and
the connection of them is normal after the
configuration is modified.
13) Use one MP of the original module
2 as the standby MP of module 3 (reserve
another MP of the original module 2). When
testing module 3, the engineer found that the
active/standby MP runs normally after the
switching.
14) Check the charging bill with the
charging center.
3.2 Changeback steps
If it is required to change back the
operation for some unsolved reasons,
perform the following steps:
1) Start the charging server progress of
the 130 server from the dual servers.
2) Power off the active/standby MP of
module 3 and unplug the MP. Replace it with
the active MP of the original module 2. Do
not power on it.
3) Unplug the network cable of the
temporary 129 server and plug the network
cable of the original 129 server into the
original interface. Unplug the dual-network
cables of module 1, module 2 and module
4 from the HUB. Unplug the CKI board
inserted in module 2 and plug it into module
3. Adjust the clock to recovery the clock
extraction of module 3.
4) Unplug the FBI board and the
MPMP board from module 3.
5) Restart the MP of the original
module 2.
6) Resynchronize all the tables and
restart the MP; and then resynchronize all
GSM Network Products 23
July 2008 Issue 117 Special Document
the tables again.
7) R e s y n c h r o n i z e t h e s e c u r i t y
variables.
8) Perform the dialing test and record
the result.
9) Restore the file omccfg.ini under
the directory C:\ZXG10 of the original
active/standby charging server. Start the
process of the 130 charging server from
the resource of the dual servers and check
the generation of the bill.
4 Adjustment after cutover
After the formal reconstruction, it is
required to observe the system for one
week in order to check whether the data
configuration is correct and whether the
device runs normally. If the device runs
steadily, cooperate with the carrier to
perform the following adjustment in order
to complete this expansion reconstruction.
Adjust the ON/OFF switch on the
reserved MP of the original module 2 and
use the MP as the MP of module 4.
Delete the data under the directory
\DATA of MP, delete the file TIMER.CFG
under the directory \CONFIG, and modify
the setting of the file \CONFIG\VERSION.
CFG. Synchronize all the tables and re-
synchronize them after the system restart.
Test the active/standby switching after the
active/standby MP runs normally.
Set the other MP of the original module
2 as the standby MP of module 3.
Back up some important databases
of the original 129 server, such as the
performance statistics database, the alarm
database, and the authority database. Back
up all files under the directory C:\ZXG10.
When the original 129 network card
performs the self-loop operation, it is
required to install the background software
24 Maintenance Experience
for the original 129 server again. It is also required
to create the performance statistic database again
because of the change of the module number.
Otherwise, the database will run abnormally. It is
only required to reserve the original databases
for other systems instead of creating them again.
After the installation, restart the system and
check whether each system runs normally (check
whether the tone Flash file used on the site exists
under the directory C:\ZXG10). Adjust the value of
the performance statistics database as the original
value, create the CSM module, and open the
collection items and the congestion parameters of
the performance statistics.
Back up the data on the new 129 server as
the SQL file and restore the data on the original
129 server. The original 129 stream control
parameters (loadctl.exe) should only includes the
configuration of module 2. It is required to delete
the configuration of this module and then re-
configure the stream control parameters of the
periphery module 3 and module 4.
After verifying the configuration data, unplug
the network cable from the HUB of the new 129
server. Connect the network cable of the original
129 server to the current HUB.
It is required to adjust the traffic load of the
outgoing trunk and the signaling link among
each module according to the planning and the
requirement of the carrier. After the single module
is expanded to multi-module of the center rack,
all the traffic is also on the module 3 (the original
module 2). At this time, it is required to allocate
the traffic of module 3 to module 3 and module 4
regularly.
Note: The trunk wire of the backplane on
module 3 should be long enough in order to be
connected to module 3 or module 4. Try to distribute
the signaling link and the traffic of each office to
module 3 and module 4 regularly.
www.zte.com.cn

GSM Network Products 25