Sjzl20060176-ZXG10-MSC VLR (V3[1].04) Maintenance Manual Troubleshooting)

8/3/2019 Sjzl20060176-ZXG10-MSC VLR (V3[1].04) Maintenance Manual Troubleshooting)

1/51

ZXG10-MSC/VLRMobile Switching Center/ Visitor Location

RegisterMaintenance Manual (Troubleshooting)

Version 3.04

ZTE CORPORATIONZTE Plaza, Keji Road South,Hi-Tech Industrial Park,Nanshan District, Shenzhen,P. R. China

518057Tel: (86) 755 26771900 800-9830-9830Fax: (86) 755 26772236

URL: http://support.zte.com.cnE-mail: [email protected]


2/51

LEGAL INFORMATION

Copyright 2005 ZTE CORPORATION.

The contents of this document are protected by copyright laws and international treaties. Any reproduction or distribution of

this document or any portion of this document, in any form by any means, without the prior written consent of ZTECORPORATION is prohibited. Additionally, the contents of this document are protected by contractual confidentialityobligations.

All company, brand and product names are trade or service marks, or registered trade or service marks, of ZTECORPORATION or of their respective owners.

This document is provided as is, and all express, implied, or statutory warranties, representations or conditions are

disclaimed, including without limitation any implied warranty of merchantability, fitness for a particular purpose, title or non-infringement. ZTE CORPORATION and its licensors shall not be liable for damages resulting from the use of or reliance onthe information contained herein.

ZTE CORPORATION or its licensors may have current or pending intellectual property rights or applications covering the

subject matter of this document. Except as expressly provided in any written license between ZTE CORPORATION and itslicensee, the user of this document shall not acquire any license to the subject matter herein.

The contents of this document and all policies of ZTE CORPORATION, including without limitation policies related to supportor training are subject to change without notice.

Revision History

Date Revision No. Serial No. Description

04/01/2006 R1.0 sjzl20060176


3/51

ZTE CORPORATIONValues Your Comments & Suggestions!Your opinion is of great value and will help us improve the quality of our productdocumentation and offer better services to our customers.

Please fax to: (86) 755-26772236; or mail to Publications R&D Department, ZTECORPORATION, ZTE Plaza, A Wing, Keji Road South, Hi-Tech Industrial Park,Shenzhen, P. R. China 518057.

Thank you for your cooperation!

DocumentName

ZXG10-MSC/VLR (V3.04) Mobile Switching Center/Visitor Location Register MaintenanceManual (Troubleshooting)

Product

Version

V3.04Document

Revision Number

R1.0

Equipment Installation Date

Presentation:

(Introductions, Procedures, Illustrations, Completeness, Level of Detail, Organization,Appearance)

Good Fair Average Poor Bad N/A

Accessibility:

(Contents, Index, Headings, Numbering, Glossary)


Yourevaluation ofthisdocumentation

Intelligibility:

(Language, Vocabulary, Readability & Clarity, Technical Accuracy, Content)


Yoursuggestions forimprovementof thisdocumentation

Please check the suggestions which you feel can improve this documentation:

Improve the overview/introduction Make it more concise/brief

Improve the Contents Add more step-by-step procedures/tutorials

Improve the organization Add more troubleshooting information

Include more figures Make it less technical

Add more examples Add more/better quick reference aids

Add more detail Improve the index

Other suggestions

__________________________________________________________________________

__________________________________________________________________________

__________________________________________________________________________

__________________________________________________________________________

__________________________________________________________________________

# Please feel free to write any comments on an attached sheet.

If you wish to be contacted regarding your comments, please complete the following:

Name Company

Postcode Address

Telephone E-mail


4/51

This page is intentionally blank.


5/51

Contents

About this Maintenance Manual ..............................................................vii

Purpose of this Maintenance Manual........................................................................vii

Typographical Conventions....................................................................................viii

Mouse Operation Conventions................................................................................viii

Safety Signs.......................................................................................................... ix

How to Get in Touch ...............................................................................................x

Customer Support...................................................................................................................x

Documentation Support...........................................................................................................x

Chapter1...................................................................................11Procedure of Handling Major Accidents................................................. 11

Definition of Major Accidents..................................................................................11

Classification of Major Accidents.............................................................................11

Procedure of Handling ZXG10-MSC/VLR Major Accidents..........................................12

Chapter2...................................................................................15Troubleshooting to Teleservice Faults.................................................... 15

Call Service Fault Overview....................................................................................15

Case 1: Calls to Some Offices Not Smooth..............................................................................17

Case 2: Calls to Some Number Segments Not Smooth............................................................17

Case 3: Clock Reference Fault Handling..................................................................................17

Case 4: MSC Inter-module Communication Blocked Handling..................................................18Case 5: Overload Handling ....................................................................................................19

Case 6: Interruption between MSC and BSC...........................................................................20

Case 7: Emergency Recovery for MSC Services All Blocked.....................................................21

Chapter3...................................................................................27Troubleshooting to Billing Faults............................................................ 27

Failure of Charging Dual-System to Enter Normal Working Status.............................27

Bill File Transfer Fault............................................................................................28


6/51

Accumulated Bill Handling .....................................................................................29

Normal Bill Accumulation Handling .........................................................................................29

Abnormal Bill Accumulation Handling......................................................................................30

Instance 2 of Billing Fault ......................................................................................31

Chapter4...................................................................................35

Chapter5...................................................................................37

AppendixA................................................................................39Working/Standy Boards Switch............................................................. 39

Switch Method......................................................................................................39

Notice..................................................................................................................39

AppendixB................................................................................41Abbreviations .......................................................................................... 41

Figures..........................................................................................49

Tables ...........................................................................................51


7/51

Confidential and Proprietary Information of ZTE CORPORATION vii

About this MaintenanceManual

Purpose of this Maintenance

ManualThis manual is intended for the maintenance personnel and the attendants,engaged in maintenance of ZXG10-MSC/VLR equipment room. Theyshould have fair technical background knowledge for the effectivetroubleshooting and smooth functioning of the equipment.


8/51

ZXG10-MSC/VLR (V3.04) Mobile Switching Center/Visitor Location Register Maintenance Manual (Troubleshooting)

viii Confidential and Proprietary Information of ZTE CORPORATION

Typographical ConventionsZTE documents employ the following typographical conventions.

TABL E1 TYPOGRAPHICAL CO NVENT I O NS

Typeface Meaning

Italics References to other guides and documents.

Quotes Links on screens.

Bold Menus, menu options, input fields, radio button names, checkboxes, drop-down lists, dialog box names, window names

Bold, with first lettercapitalized

Keys on the keyboard and buttons on screens

Constant width Text that you type, program code, files and directory names,and function names

[ ] Optional parameters

{ } Mandatory parameters| Select one of the parameters that are delimited by it

Note: Provides additional information about a certain topic.

Checkpoint: Indicates that a particular step needs to be checkedbefore proceeding further.

Tip: Indicates a suggestion or hint to make things easier ormore productive for the reader.

Mouse Operation Conventions

TABL E2 MO USE OPERAT I O N CO NVENT I O NS

Typeface Meaning

Click Refers to clicking the primary mouse button (usually the leftmouse button) once.

Double-click Refers to quickly clicking the primary mouse button (usually theleft mouse button) twice.

Right-click Refers to clicking the secondary mouse button (usually the rightmouse button) once.

Drag Refers to pressing and holding a mouse button and moving themouse.


9/51

About this Maintenance Manual

Confidential and Proprietary Information of ZTE CORPORATION ix

Safety Signs

TABL E3 SAF ET Y S I G NS

Safety Signs Meaning

Danger: Indicates an imminently hazardous situation, which ifnot avoided, will result in death or serious injury. This signalword should be limited to only extreme situations.

Warning: Indicates a potentially hazardous situation, which ifnot avoided, could result in death or serious injury.

Caution: Indicates a potentially hazardous situation, which if not

avoided, could result in minor or moderate injury. It may alsobe used to alert against unsafe practices.

Note: Indicates a potentially hazardous situation, which if notavoided, could result in injuries, equipment damage orinterruption of services.

Erosion: Beware of erosion.

Electric shock: There is a risk of electric shock.

Electrostatic: The device may be sensitive to static electricity.

Microwave: Beware of strong electromagnetic field.

Laser: Beware of strong laser beam.

No flammables: No flammables can be stored.

No touching: Do not touch.

No smoking: Smoking is forbidden.


10/51


x Confidential and Proprietary Information of ZTE CORPORATION

How to Get in TouchThe following sections provide information on how to obtain support for

the documentation and the software.

Customer SupportIf you have problems, questions, comments, or suggestions regardingyour product, contact us by e-mail at [email protected]. You can also

call our customer support center at (86) 755 26771900 and (86) 800-9830-9830.

Documentation SupportZTE welcomes your comments and suggestions on the quality andusefulness of this document. For further questions, comments, orsuggestions on the documentation, you can contact us by e-mail at

[email protected]; or you can fax your comments and suggestions to (86)755 26772236. You can also explore our website athttp://support.zte.com.cn, which contains various interesting subjects likedocumentation, knowledge base, forum and service request.


11/51

Confidential and Proprietary Information of ZTE CORPORATION 11

C h a p t e r 1

Procedure of Handling MajorAccidents

In this chapter, you will learn about:

Definition of major accidents

The corresponding handling procedure

Definition of Major AccidentsMajor accidents refer to the alarms, faults or failures that cannot belocated or settled via alarm or notification messages, which affect systems

normal running and its services.

Classification of Major AccidentsMajor faults of MSC: there is service failure to Most of users or the billingrecord cannot be sent to billing center. The types of major Accidents ofZXG10 MSC/VLR are shown in Table4.

TABL E4 L I ST O F MAJ O R ACCI DENT S O F ZXG10 MSC/VLR

SN Types of major accidents Reference

1 Call service fault Refer to chapter 2

2 Billing fault Refer to chapter 3

3 Background fault Refer to chapter 4

4 IP network security fault Refer to chapter 5


12/51


12 Confidential and Proprietary Information of ZTE CORPORATION

Procedure of Handling ZXG10-MSC/VLR Major AccidentsOnce major faults (Level 1 fault) in the equipment are reported or found,it is required to restore system, clear faults in the earliest time so thatdamage or loss caused by the fault is the least. Try the best to protectcustomers interest.


13/51

Chapter 1 - Procedure of Handling Major Accidents


Procedure of handling major accidents is shown in Figure 1.

F I G URE 1 P RO CEDURES O F H ANDL I NG M AJOR ACCI DENT S

Accident Starts

User reports to ZTE

Customer Support Center

User reports to ZTE

engineer

Report to ZTE Customer Support Center

ZTEEngineer

Fill i n Level 1 Fault Form, notify local

ZTE office or sub-center of ZTECustomer Support Center

Assign engineer of local office to

go to accident site

Manager of ZTE Local Office

Assign engineer of Customer Care

Center (of product division) to

provide remote technical support

On-duty Managerof Major

Accidents

Assign a dedicated engineer to

guide user and follow up theaccidenthandling

Manager of ZTE Local Office

Co-handli ng the accident

Local Offi ce/Engineer of Customer

Care Center (of product division)

Solved i n 30 minutes?

Notify Emergency Team and Team

Leader

ZTE Customer Support Center

Handle and settle the accident

EmergencyTeam

Fill in Emergency Handling Formand summarize

Fault handl ing departments

Visit the customer

ZTE LocalOffice

End

Yes

No


14/51



Firstly, once major accident happens, notify the ZTE customer supportcenter or ZTE engineer immediately. If ZTE engineer receives customersnotice, he must report to ZTE customer support center immediately, andbegin to guide user operation of locale through telephone or other ways.

Secondly, when ZTE customer support center or ZTE engineer receive themajor accident report from users, they must save the accident report tothe system and assign engineer of local office to go to accident site. At the

same time, they should assign engineer to provide remote technicalsupport, and assign a dedicated engineer guide user and follow up

accident handling.

Thirdly, engineer of local office ,engineer of customer care center and userco-handle the accident. If the accident cannot be solved in half an hour,emergency accident process will be started: group header and groupmember discuss and analyze the accident and solve the accident in 2hours.


15/51


C h a p t e r 2

Troubleshooting toTeleservice Faults

In this chapter, you will learn about handling methods of call service faults.

Note: The maintenance personnel must intervene to handle whenever the servicesare interrupted or abnormal, the equipment does not run normally or the softwaresystem has any problem. This chapter analyzes some common faults and providesthe general procedures for handling them.

Call Service Fault Overview

Warning: When a critical service fault occurs, notify the ZTE engineers at theearliest possible time. If the ZTE engineers are not able to arrive at site in time tohandle the problem, they will log into the system remotely to conduct themaintenance or give instructions over the phone.

When many subscribers report that outgoing or incoming calls cannot bemade easily, you must analyze, locate, and handle the fault basing on therelated information, to recover the services as soon as possible. Thefollowing information is usually valuable: Information reported by

subscribers (called numbers, locations, etc.), dialing test result, the alarmmessages (current and history) of the ZXG10-MSC/VLR, the performancestatistics (basic traffic data and real-time or history MSC_MAP statistics,etc.) of the ZXG10-MSC/VLR, and the failure information displayed byZXG10-MSC/VLR. In addition, you should also pay attention to the alarmmessages of the ZXG10-HLR, the performance statistics of the HLR, andthe failures in the HLR Service Observation. You can conduct your check inthe following order:

1. You can quickly find out whether some of the number segments havethis problem or some offices have this problem basing on the gatheredinformation and by dialing test. If only the calls to some offices have

this problem, see Case 1: Calls to Some Offices Not Smooth. If some


16/51



number segments have this problem, see Case 2: Calls to SomeNumber Segments Not Smooth.

2. If this problem is not related to offices or number segments (that is, allthe subscribers have this problem), you can check the alarm in the

Fault Management System of the ZXG10-MSC/VLR:

i. If there is CKI reference degradation alarm, you must check tofind out which reference degrades. If the currently used referencehas an alarm, the cause may be disorder in clock system, and insuch cases, you should check whether this is accompanied withmany trunk out-of-frame alarms and optical board link alarms(for offices with multiple modules). If the situation is severe, theremay be inter-module communication blocked alarm. Refer toCase 3: Clock Reference Fault Handling to switch the clockreference.

If CKI reference degradation alarm is found in the recent alarms,

accompanied by many trunk out of frame alarms, optical boardlink alarms (for office with multiple modules) or inter-modulecommunication interrupted alarm, the cause may be the CKIreference degradation, which causes the disordered ZXG10-MSC/VLR clock system.

ii. If there is inter-module communication blocked alarm, withoutany severe alarms, such as CKI reference degradation, youshould handle the inter-module communication blocked problem.See Case 4: MSC Inter-module Communication Blocked Handling.

iii. In case of signaling point unreachable alarm from the HLRdestination office, the No. 7 front PC of the HLR might have fail, insuch circumstances you should check the fault on HLR side.

iv. If there is an overload alarm, for example, MAP overload, VLRoverload, CPU overload, or memory exhausted, see Case 5:

Overload Handling.

v. If there are any other type of alarms, determine whether they arerelated to this fault. If yes, analyze the cause and handle it

accordingly.

3. If the alarms in the ZXG10-MSC/VLR do not allow you to locate thefault, perform the following test and analysis:

i. Mobile phone incoming/outgoing call test

Some mobile phones can receive incoming calls but cannot makeoutgoing calls, and some cannot perform both functions: It is notthe fact that a mobile phone cannot be used intermittently. While, agood mobile phone can neither make outgoing calls nor receiveincoming calls once it is deleted from the VLR.

If such is the case, the fault is basically on the HLR side. SeeZXG10-HLR/AUC Home Location Register/Authentication CenterMaintenance Manual.

Some mobile phones can make and receive calls, while otherscannot:. In addition, the mobile phones that cannot dial andreceive calls, belongs to one or two BSC. If this is the case, youmust check whether the signaling links and trunks of related BSChave any problem and whether there is any BSC office signaling


17/51

Chapter 2 - Troubleshooting to Teleservice Faults


point not reachable alarm. If such symptoms are found, see Case 6:Interruption between MSC and BSC.

If there are no such problems described above between the MSCand the BSC, than the fault might be on the BSC side. You can

further locate the fault by using tools like the ones used in signalingtracing of the BSC.

All the mobile phones face difficulty in dialing/receiving calls.

The fault is basically on the MSC side. If the fault cannot bepinpointed, temporarily you should make emergency treatment.

See Case 7: Emergency Recovery for MSC Services All Blocked.

ii. Analysis of performance statistics

If the call completion ratio decreases sharply within very shortperiod, usually the fault is not on the HLR.

If the call completion ratio decreases gradually, further check the

success ratio that the VLR requests the authentication parametersfrom the HLR.

If the success ratio is very low, the fault must be on the HLR side.See ZXG10-HLR Home Location Register Maintenance Manual.

If the success ratio if very high, the fault must be on the MSC side.If the fault cannot be pinpointed temporarily, you should makeemergency treatment. See Case 7: Emergency Recovery for MSCServices All Blocked.

Case 1: Calls to Some Offices Not Smooth1. Check whether the signaling link between this office and that office is

normal. If not, activate the link or self loop it for checking. If still it isabnormal, add a new signaling link.

2. Check whether the trunk between this office and other office is normal.

If not, handle it accordingly. If the fault cannot be removed, thantransfer the traffic through any other office.

Case 2: Calls to Some Number SegmentsNot Smooth

If number segment of this office cannot be called, than check the GT ofthe number segment for its correct configuration. .

If calls to the number segment of another office are not smooth, check the

number analysis for its correctness. If the number analysis is correct,trace the signal to see whether this office correctly sends the initialaddress. If yes, ask the other end to perform appropriate check.

Case 3: Clock Reference Fault HandlingIf the alarm of the currently used clock reference is not cleared, youshould immediately switch the current reference to another stable

reference. Check for any normal BITS reference. If yes, switch to that


18/51



normal BITS reference; if none of the BITS references is normal, switch tothe backup E8K reference.

Case 4: MSC Inter-moduleCommunication Blocked Handling1. Find out by viewing the information in Fault Management that the

communication between which modules is blocked. .

2. There are many causes that lead to blocked inter-modulecommunication. They are mentioned in the subsequent lines:

i. Clock problem

Usually, the 2Mbits clock is connected from the CKI board of thecentral module, and is converted into the clock needed by theswitch after processed by the SYCK. The SYCK of the peripheral

module extracts the clock of the central module through the FBIboard, for use by the local module. If the inputted clock referenceor the clock board fails, the clock may become unstable, causinginter-module communication interruption.

If the clock reference fails, first check to the backup reference

before you handle the fault. If there is no clock reference fault, youcan switch the SYCK board, to eliminate the fault of the SYCK board.

ii. Connection problem

If the timeslots for inter-module communication are released or

connected incorrectly, the inter-module communication maybecome abnormal. Usually, 16 timeslots are used for inter-module

communication. Among them, 15 timeslots are for data timeslots,and one is response timeslot. One inter-module communicationboard has 32 timeslots, in two channels.

If some timeslots among the 16 timeslots for inter-modulecommunication are released by mistake, you will see many link biterrors when you use Moniproj to observe the line status of theinter-module BOARD data. The reception/transmission record hasmany re-transmission and link disconnection counts. If this is thecase, you can reset the network board.

iii. Board fault

Faults of boards such as COMM, DSNI, FBI, and CFBI may causeinterruption of inter-module communication. Since all these boardswork in mutual-aid mode or active/standby backup mode, you canswitch over them.

Control layer bus fault

All the boards on the control layer communicate with the MP

through the backplane bus. The two MPs have two sets of buses,and all the boards on the control layer also have two sets of businterfaces. If one board on the control layer has any problem withits bus interface, the working of other boards will be affected. Thesymptom will be interruption of inter-module communication, intra-module communication, and sometimes flashing of the red inter-

module communication indicator. If the bus interface of one COMM


19/51



board fails, you can unplug all the COMM boards one after anotherto locate the failed COMM board. Since the system has two sets of

buses, you can switch over the MP to clear the fault.

DSNI board fault

If the inter-module communication is affected by the MP-level DSNIboard, the problem may be loose contact or hardware failure of theDSNI board. In this case, you can unplug/plug the two MP-levelDSNI board in mutual-aid configuration, and see whether the faultclears.

FBI or CFBI board fault

Severe bit errors or the interruption of the optical link containinginter-module communication timeslots may cause interruption ofinter-module communication. If this is the case, you can switchover the appropriate CFBI board (this will also switch over the FBI

board of the corresponding peripheral module).

3. Based on the causes described above, you can handle this fault by thefollowing steps:

i. Switch over the SYCK board of the failed module. Proceed to thenext step if the fault remains.

ii. Unplug/plug the two MPMP boards of the failed module. Proceed tothe next step if the fault continues.

iii. Unplug/plug the two MP-level DSNI boards of the failed module.Proceed to the next step if the fault continues.

iv. Switch over the switching network board of the failed module.Proceed to the next step if the fault stays.

v. Switch over the MP of the failed module. Proceed to the next step ifthe fault continues.

vi. Switch over the CFBI board on module 2 connected to the failedmodule. Proceed to the next step if the fault continues.

vii. Switch over the SYCK board of module 2. Proceed to the next stepif the fault still exists.

viii. Switch over the switching network board of module 2. Proceed tothe next step if the fault remains.

ix. Unplug/plug the MPMPs of module 1 in sequence. Observe whether

the fault clears once a board is unplugged/plugged. Proceed to thenext step, if the fault continues.

x. Switch over to the MP of module 1, and switch over that of module2.

Case 5: Overload HandlingGiven below are the two causes of overload:

1. The processing capability bottleneck of the service program, that is,service program load, which will usually cause MAP load alarm or VLRload alarm.


20/51



2. The processing capability bottleneck of the MP, that is, MP overload, isusually reflected as high CPU utilization and memory utilization.

The overload of a MP running normally may be due to the following tworeasons:

1. Network storm generates enormous junk messages on the network,which could cause service program overload and MP resourceexhaustion, thus affecting the normal service processing.

i. Emergency handling: Unplug the network cable from theforeground MP to the HUB temporarily. If the service recovers afterthat, the problem must have been caused by network storm.

ii. Add a firewall between the MSC and the peripheral network, to

isolate junk message packets and illegal access, and eliminateadverse influence by the peripheral network on the MSC.

2. The traffic of the MSC is far above the systems processing capability.

High traffic also cause service program overload and MP resourceexhaustion.

3. If the network cable between the foreground MP and the backgroundnetwork is disconnected. Do the following:

i. Emergency handling: If the MP overload causes the serviceinterruption of complete MSC or a module, you should firstdisconnect the connections of some BSCs to ensure some normalservices. If the call completion ratio does not improve even afterthat, restart the MP.

ii. Check the configuration of the MP, to see whether the configurationof the CPU and memory is too low. If so, you must reconfigure ahigher MP to meet the needs in the long run.

iii. If the number of subscribers connected to this module is very highand the situation continues for longer duration for longer duration,you may have to move some LAIs of this module to another

module with fewer subscribers, or should expand this module.

Case 6: Interruption between MSC andBSC1. Find out how many BSCs are disconnected from the MSC

i. If there is only one, focus your attention on the BSC side. Performreception/transmission self-loop on the trunk configured withsignaling links. Perform self-loop in Dynamic Management, send thechange table to the foreground, and view the self-loop status. Ifthe self-loop fails, check the trunk board and STB board. If thetrunk board has any alarm, replace it. If the STB has any alarm,

you can switch the signaling timeslot to another STB board. If theself-loop succeeds, please perform self-loop test on the BSC side.

ii. If multiple BSCs have signaling blocked, check the SYCK board,DDSN (Double Digital Trunk Network) board, MPPP board, and MPof the MSC module. Perform active/standby switchover to any


21/51



board with any alarm, if still it is faulty than reset the board thatalarms. In case of MP, restart it and re-send the whole table.

2. The signaling link between the MSC and BSC should be checked forblockage, which could be done via Dynamic Management of the

Configuration Management System. The trunk (signaling link) shouldnot be blocked and if so unblock it, otherwise check the trunk on BSCside.

Case 7: Emergency Recovery for MSCServices All Blocked1. View the alarms about MP, MPMP, MPPP, DDSN, and clock board of

module 2 in Fault Management. Perform active/standby switchover tothe MP or other boards with alarms. If the switchover cannot be

performed on the background, unplug the active MP or appropriate

boards to trigger a forced switchover.

2. In case of no alarm, perform switchover in following order. SYCK DDSN CKCD MPPP MP, for central rack networking mode.

Follow the SYCK DDSN MPPP MP order for single-modulenetworking mode. If the fault persists after switchover, restart the MPand resend the whole table.

Instance 1 of Call Service FaultPhenomenon Description

It is reported by some office saying that user calling other is success. butuser cannot be called.

Fault Analysis and Locating

When user act as a callee, home MSC of caller send routing information

request to callees home HLR. HLR ask home VLR of callee for MSRN, andreturn MSRN to home MSC of caller. MSC analyze MSRN in roamingnumber analysis. If user is in local office, MSRN is local offices roamingnumber. So roaming number analysis must have local offices roaming

number and point them to local office. If user is not in local office, roamingnumber analysis should have other offices roaming number.

If there is no MSRN in roaming number analysis, MSC system cannot findconnecting entry and called procedure is caused failure.

Through fault observation of MSC service observation, the fault of roamingnumber analysis is found. After checking roaming number analysis, it isfound that there is no roaming number configuration. After checking logsystem, much modification to number analysis has been done.

Solution


22/51



Found the backup data of the system and restore the backup data. Thenservice begins to recover to the normal status.


It is reported by some office saying that some user cannot be called.


Through performance statistics, circuit group traffic date is shown the faultis in a BSC of the MSC, and service in other BSC is normal. One MPM ofMSC connecting to the BSC has switched MP automatically before the fault

happen.

Solution

1. Switch the MP of the MPM manually. The fault is solved.

2. Check the working MP when the fault is happening. There is hardwarefault in the MP. When the MP acts as working board, service fault iscaused.

Summary

A MP board of a MPM causes the failure. Maintenance person should do

routine maintenance working to do hardware-switching test. They can findabnormity in time.


It is reported by some office saying that communication between module 3and other modules of MSC has an instantaneous block, and the local usercannot be the calling party easily as usual.


The mobile outgoing and incoming call MAP signalling are centralized onmodule 3. This instantaneous overload occurs at the traffic peak, andmeanwhile it makes the communication between module 3 and other

modules interrupted. The on-site technicians therefore modified inter-office signaling and traffic.


23/51



From moniproj, you can see that the communication between module 1(MSM) and module 3 is seriously overloaded, as shown in Figure 2.

F I G URE 2 C O M M UNI CAT I O N B ET WEEN M O DUL E 1 AND MO DUL E 3

Solution

1. Adjust the signaling links to H1 and H2 to make them balance the load.

According to the current load of modules 4, 5 and 6, adjust thesignaling links of H1 and H2 to modules 5 and 6 to share the load.Adjust the connection relationship of local SDH and reconfigure theMTP data. In actual operation, adjust the two signaling links to H1 onmodule 3 to module 7.

2. Modify the value of Maxspd and Maxint in TCPIP.INI according to theactual situation. Or, delete the setting of defending network storm inTCPIP.INI. Observe it.

3. Adjust the speech channel: At present, modules 3, 4, 5 and 6 havespeech channels to A1, A2, B1 and B2. Apply for more signaling links

to exchanges, which mainly refer to the signalling links to B1 and B2because signalling links to A1 and A2 are transferred through exchange

H. Try to avoid intermodule communication transfer.

4. Adjust the call of own exchange: Allocate trunks of the four BSCs on

modules of MSC in a balanced mode.


24/51




A crosstalk problem is reported by an office describing phenomenon asfollowing: MS A calls fixed user B and user B hooks off, however, both

party cannot hear the other. If both hold the call, user A can hear a thirdparty, for instance user C, is talking with himself/herself (user A).Curiously, user A and C and communicate. If user C hooks on, user A stillcan hear other person talking with him/her.


Conduct dialing test on the site. When crosstalk problem occurs again,trace and observe GMSC thoroughly. It is found that connection betweenGMSC circuits and T net is proper.

Troubleshooting

When the crosstalk involves many NEs, it is difficult to locate it. The voicemonitor (like LITE3000) can locate the NE causing crosstalk convenientlyand quickly.

Suppose own exchange is exchange A, the adjacent exchanges areexchanges B and C. Subscriber b of exchange B originates a call to

subscriber c of exchange C. The crosstalk occurs in the B-A-C conversation.

1. Listen conversation between A and B. If what is listened is the same as

that listened by c, the crosstalk occurs in exchange B.

2. If they are different, listen the conversation between A and C. If what

is listened is the same as that listened by b, the crosstalk occurs inexchange C.

3. If they are different also, it indicates the problem is in own exchange.

Enable the signaling trace before dialing test to identify the trunk circuitbeing occupied at the crosstalk.

If the problem is in own exchange, it is necessary to locate the module,

service type, signaling type, and occurrence before or after ring back toneinvolved in the crosstalk problem, for the sake of analysis.

Application Case:

Some gateway exchange reports the crosstalk problem for many times.The crosstalk phenomenon captured is as follows: Mobile subscriber Aoriginates a call to subscriber B of PSTN. B rings and hooks off. Both A andB cannot hear from each other. Hold the call. Other users C and D talkwith A and B respectively. A can talk with C in a bidirectional way and B

and talk with D in a bidirectional way. After C and D hook on, other newusers C and D have a crosstalk with A and B incessantly. Perform dialingtest, trace the gateway exchange at crosstalk, check the circuit and


25/51



observe the connection in the dynamic management and find on problemin the gateway exchange.

According to the above method, locate the NE with crosstalk. What islistened by the monitor between the mobile exchange and gateway

exchange is the same as that listened by the user of PSTN. Afterwards,some mobile subscribers complain that there is a crosstalk between themobile subscribers of own exchange. So, the problem causing crosstalk isin the mobile exchange.

Summary

For mobile communication network, if the crosstalk only occurs for thelocal calls between subscribers of an end office, the problem must lie inthe end office. When the crosstalk problem involves many NetworkElements (NEs), it is difficult to locate the problem. Wiretapping is acommonly used method to locate the problem.


26/51


27/51


C h a p t e r 3

Troubleshooting to BillingFaults

In this chapter, you will learn about handling methods of billing faults.

Billing Fault OverviewBilling faults refer to the phenomenon that charging bills cannot betransmitted to billing center on time. For instance, cluster being abnormal

and thus causes CDR cannot be generated on time. Or, CDR accumulateson foreground MP until overstock, etc.

Failure of Charging Dual-Systemto Enter Normal Working StatusThe charging dual-system restarts after the server rack is powered off. In

normal cases, after the dual-system restarts, the Cluster server will startautomatically, and the resources will load automatically. However, none ofthe resources of the dual-computer cluster is loaded. The cause may beone of the following:

1. The Cluster service is not automatically started.

2. The heartbeat cable fails during the detection process, and the dual-computer cluster system cannot determine whether this computer is

active or standby, so that none of the resources can be loaded.

3. The first resource is not loaded successfully, and the load process ofother resources stops, so that none of the resources is loaded

successfully. When a dual-computer cluster system with disk arraypowered on, the disk array and the server are started at the same time.

Usually, before the disk array is at its normal running status, theCluster starts loading the disk array resources, which causes loadfailure.


28/51



If both the computers are at the standby status, you can do the following:

1. Check whether the heartbeat cable connection is normal, after the

cluster service starts. If the heartbeat cable connection is displayed asa red line, it means that the connection fails. In this case, you must

check the physical connection and the data configuration of theheartbeat line. After the heartbeat line connection becomes normal(displayed as green), proceed to the next step.

2. "Bring In" resources manually, and change the Cluster service toautomatic startup in Cluster configuration.

3. If the shared disk (disk array) is not successfully brought in (Bring Infailure), shut down the dual-computer cluster and the disk array, andthen start the disk array. After the disk array is normally working, startthe dual-computer cluster.

If the subsequent resources are not successfully brought in, perform a

Takeover Server on the server, and then perform Bring In again.

Bill File Transfer FaultCurrently, bills are usually transferred through FTP (File Transfer Protocol),

from directory FTAM on the charging server the charging center. Bills can

be transmitted in two ways: One is that the charging server sends them tothe charging server; the other is that the charging center fetches them atthe charging server. If the charging server fails to receive or collect anybill files, you can check the following to find out the cause:

1. Check whether the TCP/IP link between the charging server and the billcollector of the charging center is interrupted. If it is interrupted, the

charging server cannot successfully ping the charging server. Checkwhether the network cable connection is reliable, and whether therouting configuration is correct. If either party can successfully pingthe other, proceed to the next step.

2. Check whether the FTP service is started on FTP servers end, and

whether the client connection settings (IP of remote node, user name,password, and port ID) are correct. If they are all correct, proceed to

the next step.

3. Check whether the charging server has correctly generated bills. Thereshould be bills under directory Zxgbil and Ftam. If there is no, check

the charging system for any fault. Perform the following checks:

i. If the bill reception directory is damaged than you should create

zxgtemp and zxgbil directories again.

ii. The parameters for bill generation are not set correctly, for

example, the disk letter is incorrect. In this case, you can see thereception of bills at the charges monitoring center, but there are nobills generated under the original bill directory. You should changethe old bill file directory to the original disk letter through

obdbtool.


29/51

Chapter 3 - Troubleshooting to Billing Faults


iii. Bills are accumulated at the foreground. See whether there is any

accumulated bill file, PmscGenV.bil, under c:\bill of the MP

through File Management. If there is any, you can try restarting thebill reception process.

Accumulated Bill Handling

Normal Bill Accumulation HandlingWhen any bill get accumulated at the foreground, usually an appropriatealarm is indicated. Normally, the name of the accumulated bill file is

PmscGenV.bil , under C:\bill o the MP. You can see it through the File

Management System. The bills get accumulated on the following events:

1. Communication interruption, between the charging server and theforeground, mostly takes place , due to the loose contact of networkcable.

2. The charging server is running abnormally, for example, the chargingdual-computer cluster system is not started, the dual-computer

resources are all at bring out status, the bill reception process is notstarted, the bill reception process is in a deadlock, etc.

3. The traffic large. The temporary traffic peak may cause accumulationof bills, usually such accumulation is not in greater numbers and thesystem can recover automatically. No manual handling is required.

4. The incorrect configuration. For example, the charging server is 130,while at charging foreground it is configured as 129. This often takesplace at the early stages of its deployment. If the related data isconfigured correctly, this will not occur while it is running.

Normal bills accumulated can be handled by following the procedure givenin subsequent lines:

1. Check the size of bills accumulated at the foreground and the freespace on disk C through the File Management System. If the freespace is too small, switch over the MP.

2. Notify the ZTE engineer, and perform subsequent handling under

his/her guidance over the phone or wait for him/her to handle the faulton site.

3. Back up the accumulated bills. If in case of few accumulated bills, copythem to background through the File Management System. If there aremany, it will take a long time to copy them through the File

Management System. In this case, display card can be plugged in theMP along with a monitor and a keyboard to start the Microsoft Network

Client for MS-DOS, and copy the accumulated bill files to thebackground server.

4. Eliminate the fault and restore the normal transfer of bills between the

foreground and the background. If the communication is interrupted,restore the communication. If the dual-computer cluster system does

not work normally, you should restore the cluster system to normal


30/51



running. If the bill reception process is in a deadlock, you can first killit and then restart it.

5. Transfer the accumulated bills. Once the transmission/reception of billsbetween foreground and background is normal, accumulated bills are

transferred to the background. It can be observed that how bills aretransferred to the charge monitoring system.

6. Check the bills. After all the accumulated bills are transferred to thecharging server from the foreground, the bill accumulation alarm willbe cleared. It depends on the duration for which bills accumulated, thenew bill files created (in bytes) should be the same as those createdduring the same period. Open the Charging Management System tocheck the format of new files created. The format should be similar toprevious.

Abnormal Bill Accumulation HandlingIf the extension of the bill file accumulated at the foreground is *.pid,

where * is the time when the PID file is created, it means that the MP isnot running normally. The cause may be one of the following:

1. The charging foreground has no free disk space (Too many junk files oraccumulated bills occupy the whole disk).

2. The damaged charging disk or other reasons cause disk writing failure.

The *.pid accumulated bill file can be handled by the following steps:

1. Check the size of bills accumulated at the foreground and free space

available on disk C through the File Management System. Switch theMP with accumulated bills to the standby status.

2. Notify the ZTE engineer, and perform subsequent handling under

his/her guidance over the phone or wait for him/her to handle the faulthimself on site.

3. Back up the accumulated bills. If there are only a few accumulated bills,you can copy them to the background through the File ManagementSystem. If there are many, it will take a long time to copy themthrough the File Management System. In this case, you can plug adisplay card in the MP, and connect a monitor and keyboard to it. Then,start the Microsoft Network Client for MS-DOS, and copy the

accumulated bill files to the background server.

4. If the charging server has any fault, first eliminate it, and restore thenormal transfer of bills between the foreground and the background. Ifthe communication is interrupted, restore the communication. If thedual-computer cluster system does not work normally, you should

restore the cluster system to normal running. If the bill receptionprocess is in a deadlock, it can be removed first and than restarted.

5. Transfer the accumulated bills. Rename the *.pid file on the MP to

PmscGenV.bil, start the MP, and the accumulated bills will be

transferred to the background. If the PmscGenV.bil will disappear, it

means that the transfer is completed, when you can open the ChargingManagement System to check the format of the new bills created, it

should be same like before.


31/51



If there are multiple PID files, handle them all in the same way.

6. If the foreground disk does not have sufficient space, check the freedisk again after all the bills are transferred. If the disk space becomessufficient, ignore it. If the disk space is still insufficient, check the disk

for any junk files.

If the hard disk fails, replace the hardware and re-build the MP orreplace the MP.

Instance 1 of Billing FaultPhenomenon Description

Alarm of bill overstock occurs to modules 5 and 6 (in some office).


First check the bill receiving link status of modules 5 and 6 on the chargingmonitor. The status of the two modules is waiting for the running of the

charging server.

Solution

In the OMCCFG.INI file on 130, MSCModuleTotal is 2, MSCModule1 is 3

and MSCModule2 is 4. On 129 are configured four modules. Modify the

configuration file OMCCFG.INI on server 130 and restart the charging

receiving process.

Check the foreground configuration file TCPIP.CFG of module 5 and find

JFSERVER is 129. Modify it into 130, restart the standby MP of module 5,switch over the active/standby MPs and restart the MP switched over as

standby one. The alarm of bill overstock disappears.

Summary

If CDR overstock (within reasonable range) occurs on some specific

module, it is recommended to check if configurations ofomccfg.ini (on

billing server) and tcpip.cfg (on foreground MP module) are correct.

Instance 2 of Billing FaultPhenomenon Description

Charging center unable to collect bill files

Phenomenon Description

The charging center feeds back that it cannot collect bill files. Bills areoverstocked in the FTAM directory of the charging server. The alarm of link


32/51



with the charging center interrupted occurs. The bill files are transferredthrough the FTAM protocol to the charging center.


1. Make sure the network is normal by checking the network cable and

HUB connected with the charging center.

2. Check whether the FTAM service is started normally.

Select Control PanelService to check whether OSI-LAN Protocol

and Vertel FTAM Server run normally.

3. Check whether the CLUSTER service is started normally.

Select Control Panel Service to check whether the CLUSTER

service (the CLUSTER service name varies with the manufacturers) is

normal.

Execute Cluster Administrator to check whether the CLUSTER softwareruns normally, the status of resources is normal and CLUSTER has FAIl

record.

4. Check the running state of the charging application.

Click the server management process SerAppMa.exe and activate allserver application processes with . Check whether

the bill receiving process obserr.exe is normal.

5. Check whether the numbers of bill files in the FTAM directory areinconsecutive.

If all the above are normal, it is possible that the serial numbers of thefiles are inconsecutive. The cause may be the protection measureadopted by the bill receiving process to prevent the bill files from beingoverwritten because the bill receiving process ever exits abnormally.

The collection machine of the charging center collects files by serialnumber. Once the numbers are inconsecutive, the collections machinestops collecting the subsequent files, and in result the bill files are

overstocked on the charging server. Because some files are collected

by the collection machine, it is impossible to discover that the numbersof files are inconsecutive by observing the charging service process.

Processing Steps

Inquire the relevant technical personnel of the charging center for theserial number of the bill file collected last and compare it with the numbers

of files in the FTAM directory on the charging server to identify whetherthe numbers are inconsecutive.


33/51



Solution

Rename the bill files one by one to make the numbers consecutive with

the numbers in charging center and meanwhile modify the value ofFTAM_SEQNUM in the Setting table of the database.

Provide the charging center with the smallest serial number of file on theserver to recover the collection.

Summary

The failure of charging center collecting bills may be caused by the error inany link of the above steps, so make sure whether the bills are generatednormally and whether the filename of the bill is correct (check the Settingtable) and check and exclude the fault according to the above steps.


34/51


35/51


C h a p t e r 4

Troubleshooting toBackground Faults

In this chapter, you will learn about handling methods of backgroundcritical faults

O&M Fault OverviewBackground fault (O&M fault) refers to such failures as O&M console

malfunction, data configuration function fault, performance statisticsfunction fault, alarm management fault, communication failure betweensuperior NM interface so that performance, alarm and so on data cannotbe reported to superior NM on time.

To clear background fault, basically check Windows 200 and SQL Server2000 and make sure they are installed properly. Check O&M software aswell and make sure communication between background server Ethernetis proper. Analyze and locate problem resorting to various system logs.

Instance of Background FaultPhenomenon Description

It is reported that performance statistic data are missing after upgrade (bysome office)


View contents of OERRLOG.ZEV file under C:\zxg10 directory, it is foundthat LOCK TIME OUT occurs when deleting data. Resorting to SQL SERVERTRACE file, we find that when executing

select minsdate from xxdatax where not nmodule=0,it takes much time (around 4 minutes). It may be conflicting with data

refreshing and therefore causes LOCK TIME OUT.


36/51



Solution

Enhance executing speed and solve the problem by adding index,

Create index idx_nmodule_sdate on xxdatax nmodulesdate

Summary

For huge tables (with large amount of data), it is recommended to createindex, which can greatly enhance retrieve speed.


37/51


C h a p t e r 5

Troubleshooting to IP NetworkSecurity Faults

In this chapter, you will learn about handling methods of network securityfaults

Overview of IP Network SecurityFaultIP network security faults refer to malevolent attack, virus invasion, andnetwork storm upon MSC LAN from external equipment caused by networkdefects.

To avoid IP network security faults, it is recommended to plan and

configure MSC LAN as per engineering specifications.

Instance of Background FaultPhenomenon Description

MP reset fault due to network storm.

The active and standby MPs of modules 3, 4 and 5 of MSC are resetautomatically and the active and standby MPs of module 2 are still running.The modules of BSC are reset automatically. After the above modules arereset automatically, they cannot be started normally.

Troubleshooting

At 16:38, disconnect the connection with the charging center. After MSC isreset, the MSCVLR side is almost normal but the system reports the callcannot be connected at present when a local user originates a call to alocal user. Check the signaling and find that after HLRMAP receives SRIreq

and PRNreq, VLRMAP returns PRNACK but HLRMAP receives it after 6 or 7

seconds. At this time, the call failed due to timeout. After deleting the user


38/51



from VLR, the user updating location failed. After receiving UPDATELOCreq,HLRMAP sends insertuserDATAreq. Sometimes, VLR can receive it but

sometimes not. In case VLR receives it, it sends insertDATAACK butHLRMAP cannot receive it. HLRMAP reports U_ABORT or P_ABORT. At this

time, the local user can serve as the calling party normally and thesending and receiving of short message are normal.


The module is reset due to overload, which may be affected by theexternal network. The alarm shows that the CPU occupation ratio by thene2rece task touches 96%, indicating that the system is affected by theexternal network storm. After disconnecting from the external network(the charging center), it recovers gradually after the reset of the systemMP. Later, it is found that a network cable connected with the chargingcenter is shorted due to being damaged in engineering.

The reason of location update failure when the local user serves as thecalled party is because all users are offline after MSCVLR is reset all. In

this case, a lot of location updates occur, which leads to HLR congestion.The reason of HLR congestion is that the memory of SQL server on HLRDBserver is too small (8192(2k unit), that is, 16 M). However, server 129adopts 32 M. So, it is normal after switching over to server 129.

Solution

1. Other network equipment cannot be directly connected to SWITCH orhub of the LAN where own exchange is, for example, the externalnetwork equipment like the charging center is connected to SWITCH or

hub through router or firewall isolation.

2. Set network storm defending for the SWTICH used by the LAN whereown exchange is. This can limit the traffic effectively when the networkbroadcast is larger than the traffic set.

3. Set the interruption times per second for the handling of networkadapter in the configuration file of MP foreground.


39/51


A p p e n d i x

A

Working/Standy BoardsSwitch

Switch Method1. The board besides of MP board

The boards besides of MP board need switch straightly. Beforeswitching, make sure that the boards have no alarm and working

status is normal. Operation methodIn alarm system, choose module

number; double click working/standby board; in dialog box, switchboard.

2. MP board

Before switching MP board, we should reset standby MP board. Afterthe resetting alarm clear away, we should wait 5 minutes firstly and

begin to switch MP board. Through service observation system andperformance statistics system, we should observe system operation

status.

Notice1. When SYNC or CKI board are switched, it cause receiving error in FBI

board and No.7 signalling Interruption; when DSNI or DSN board areswitched, it cause cacophony phenomena and we should pay attentionfor it and record it.

2. Switch operation should be authorized by the leaders of maintenancedepartment and should be assigned in night when traffic is lower.


40/51


41/51


A p p e n d i x B

Abbreviations

Abbreviation Full Name

A-interface A-interface A3 Authentication algorithm A3

A5/X Encryption algorithm A5/0-7

A8 Ciphering key generating algorithm A8

ACK ACKnowledgement

-Accumulated Call MeterACM

-Address Complete Message

AE Application Entity

AoC Advice of Charge

AoCC Advice of Charge Charging supplementary service

AoCI Advice of Charge Information supplementary service

ASE Application Service Element

ASIG Analog Signalling

ASN.1 Abstract Syntax Notation One

AuC Authentication Centre

B-interface B-interface

BAIC Barring of All Incoming Calls supplementary service

BAOC Barring of All Outgoing Calls supplementary service

BCCH Broadcast Control Channel

BCTL Back Control

BDT Back Digital Trunk

BFBI Back Fiber Bus Interface

BHCA Busy Hour Calling Attempt

BIC-Roam Barring of Incoming Calls when Roaming outside the homePLMN country supplementary service

BNET Back Network

BO all Barring of Outgoing call supplementary services


42/51




BOIC Barring of Outgoing International Calls supplementaryservice

BOIC-exHC Barring of Outgoing International Calls except thosedirected to the Home PLMN Country supplementary service

-Basic Service (group)BS

-Bearer Service

BSG Basic Service Group

BSC Base Station Controller

BSNM Back S Network

BSS Base Station System

BSSAP Base Station System Application Part

BSSMAP Base Station System Management Application Part

BSSOMAP Base Station System Operation and

Maintenance Application Part

BTS Base Transceiver Station

C-interface C-interface

CAI Charge Advice Information

CB Cell Broadcast

CBC Cell Broadcast Centre

CBCH Cell Broadcast Channel

CBK Clear Back signal

-Country CodeCC

-Call Control

CCF Conditional Call Forwarding

CCITT The International Telegraph and Telephone ConsultativeCommittee

Cct Circuit

CF all Call Forwarding services

CFB Call Forwarding on mobile subscriber Busy supplementaryservice

CFNRc Call Forwarding on mobile subscriber Not Reachablesupplementary service

CFNRy Call Forwarding on No Reply supplementary service

CFU Call Forwarding Unconditional supplementary service

CGC Cirduit Group Congestion signal

-Cell IdentityCI

-CUG Index

CKDR Clock Driver


43/51

Appendix B - Abbreviations



CKI Clock Interface

CLI Calling Line Identity

CLIP Calling Line Identification Presentation supplementaryservice

CLIR Calling Line Identification Restriction

supplementary service

CM Connection Management

CMD CoMmanD

COLI COnnected Line Identity

COLP COnnected Line identification Presentation supplementaryservice

COLR COnnected Line identification Restriction supplementaryservice

COMM Communication

CONNACK CONNect ACKnowledgement

CRC Cyclic Redundancy Check (3 bit)

CSM Central Switching Module

CSPDN Circuit Switched Public Data Network

CUG Closed User Group supplementary service

CW Call Waiting supplementary service

D-interface D-interface

DB Data Base

DCCH Dedicated Control Channel

DCS1800 Digital Cellular System at 1800MHz

DET DETach

DISC DISConnect

DL Data Link (layer)

DSN Digital Switching Network

DSNI Digital Switching Network Interface

DTAP Direct Transfer Application Part

DTI Digital Trunk Interface

DTMF Dual Tone Multi-Frequency (signalling)

DPC Destination Point Code

E-interface E-interface

EC Echo Canceller

EIR Equipment Identity Register

EPROM Erasable Programmable Read Only Memory

ETS European Telecommunication Standard


44/51




ETSI European Telecommunications Standards Institute

F-interface F-interface

FBI Fiber Bus Interface

FSM Forward Setup Message

Ftn forwarded-to number

G-interface

G/IW MSC Gateway/Interworking MSC

GMSC Gateway Mobile-services Switching Centre

GRQ General ReQuest message

GSM Global System for Mobile Communications

GSM MS GSM Mobile Station

GSM PLMN GSM Public Land Mobile Network

GT Global Title

HANDO HANDOver

HDLC High level Data Link Control

HLC High Layer Compatibility

HLR Home Location Register

HOLD Call hold supplementary service

HPLMN Home PLMN

IAM Initial Address MessageIAI Initial Address Message with Information

ID IDentification/IDentity/Identifier

IMEI International Mobile station Equipment Identity

IMSI International Mobile Subscriber Identity

ISDN Integrated Services Digital Network

ISUP ISDN User Part (of signalling system No.7)

IWF InterWorking Function

IWMSC InterWorking MSC

IWU InterWorking Unit

Kc Ciphering key

Ki Individual subscriber authentication key

L1 Layer 1

L2ML Layer 2 Management Link

L2R Layer 2 Relay

L3 Layer 3

LA Location Area

LAC Location Area Code


45/51




LAI Location Area Identity

LAN Local Area Network

LAPB Link Access Protocol Balanced

LAPDm Link Access Protocol on the Dm channel

LCN Local Communication Network

LMSI Local Mobile Station Identity

LPLMN Local PLMN

MAP Mobile Application Part

MCC Mobile Country Code

MM Mobility Management

MMI Man Machine Interface

MNC Mobile Network Code

MO Mobile Originated

MON Monitor

MoU Memorandum of Understanding

MP Module Processor

MPM MSC Process Module

MPTY MultiParTY (Multi ParTY) supplementary service

MS Mobile Station

MSC Mobile Switching CentreMSISDN Mobile Station International ISDN Number

MSM Message Switching Module

MSRN Mobile Station Roaming Number

MT Mobile Terminated

MTP Message Transfer Part

NCC Network (PLMN) Colour Code

NDC National Destination Code

NDUB Network Determined User Busy

NE Network Element

NF Network Function

NIC Network Independent Clocking

NM Network Management

NMC Network Management Centre

O&M Operations & Maintenance

OMC Operations & Maintenance Centre

OMM Operate Maintenance Module

OPC Origination Point Code


46/51




OS Operating System

OSI Open System Interconnection

PCH Paging Channel

PCM Pulse Code Modulate

PEPD Peripheral Environment Parameter Detection

PIN Personal Identification Number

PLMN Public Lands Mobile Network

POWER B Power B

PSPDN Packet Switched Public Data Network

PSM Peripheral Switching Module

PSTN Public Switched Telephone Network

PW Pass Word

RAND RANDom number (used for authentication)

REJ REJect (ion)

REL RELease

REQ REQuest

RLG ReLease Guard signal

RLP Radio Link Protocol

RR Radio Resource

RSC ReSet Circuit signalSACCH Slow Associated Control Channel

SAP Service Access Point

-Service Centre (used for SMS)SC

-Service Code

SCCP Signalling Connection Control Part

SCH Synchronization Channel

SDCCH Stand-alone Dedicated Control Channel

SIM Subscriber Identity Module

SME Short Message Entity

SMEM Shared Memory

SMS Short Message Service

SMSCB Short Message Service Cell Broadcast

SMS-SC Short Message Service - Service Centre

SMS/PP Short Message Service/Point-to-Point

SN Subscriber Number

SNM Switching Network Module

SPC Signalling Point Code


47/51




SRES Signed RESponse (authentication)

SS Supplementary Service

SSN Sub-System Number

SS7 Signalling System No.7

STP Signalling Transfer Point

SYCK Sync Clock

TAF Terminal Adaptation Function

TCAP Transaction Capability Application Part

TCH Traffic Channel

TDMA Time Division Multiple Access

TE Terminal Equipment

TM Translate Module

TMN Telecommunications Management Network

TMSI Temporary Mobile Subscriber Identity

USSD Unstructured Supplementary Service Data

VLR Visitor Location Register

VMSC Visited MSC

VPLMN Visited PLMN

VPM Visitor Peripheral Module

VM Voice Mailbox


48/51


49/51


Figures

Figure 1 Procedures of Handling Major Accidents ............................................13Figure 2 Communication Between Module 1 and Module 3................................23


50/51


51/51

Tables

Table1 Typographical Conventions............................................................... viiiTable2 Mouse Operation Conventions........................................................... viiiTable3 Safety Signs.....................................................................................ixTable4 List of Major Accidents of ZXG10 MSC/VLR ..........................................11

Sjzl20060176-ZXG10-MSC VLR (V3[1].04) Maintenance Manual Troubleshooting)

Documents

Transcript of Sjzl20060176-ZXG10-MSC VLR (V3[1].04) Maintenance Manual Troubleshooting)