WIN Products - Topic On The Analysis of The Signaling V1.0-20050401-B

Document No.
Product name WIN
Usage object WIN Engineers Product version
Prepared by WIN Document version V1.1
WIN Products – Topic On the Analysis

of the Signaling
Drafted by: Mao Yuanjian Date: 2004/4/23
Reviewed by: Date:
Reviewed by: Date:
Approved by: Date:
Huawei Technologies Co., Ltd.
All rights reserved
For internal use only

Confidentiality: for
~53F3.doc internal use only
Revision Record
Date Revision version Description Author
2004/4/23 1.0 It was drafted. Mao Yuanjian
Revisions: enriched contents about call trace

2004/06/02 1.1 Mao Yuanjian
and log unscramble and added some cases

Table of Contents
Preface............................................................................................................................................... 2
Chapter 1 Basic Signaling Knowledge........................................................................................... 3

1.1 Basic Knowledge .................................................................................................................. 3
1.2 SCCP Knowledge Points ...................................................................................................... 4
1.3 TCAP Knowledge Points ...................................................................................................... 7
1.3.1 Several Concepts ....................................................................................................... 7
1.3.2 Dialogue Primitive ...................................................................................................... 8
1.3.3 Component Primitive................................................................................................ 12
1.4 CAP Knowledge Points....................................................................................................... 15
1.4.1 Basic Concepts ........................................................................................................ 16
1.4.2 CAMEL Service Trigger Process ............................................................................. 21
1.4.3 Major Operations and Explanation of Parameters ................................................... 24
1.5 MAP Knowledge Points ...................................................................................................... 36
1.5.1 Mapping between the MAP Service and the TC Service......................................... 36
1.5.2 Introduction to MAP Operation................................................................................. 37
1.6 INAP Execute Knowledge Points........................................................................................ 38
1.6.1 Background .............................................................................................................. 39
1.6.2 Explanation of the Signaling..................................................................................... 40
1.6.3 How to Understand the Traced Execute Code Stream?.......................................... 42
1.7 Signaling-Related Configuration Items ............................................................................... 44
1.7.1 Time Interval of the Active Test (AT)........................................................................ 44
1.7.2 When the end-office temporary connection message (ETC) is configured, are
bi-directional indicators required? ..................................................................................... 44
1.7.3 Configure parameter screening of Generic Number in the Connect message........ 45
1.7.4 Configure the timeout wait time standard after SCP transmits ATI or SRI .............. 46
1.7.5 Configure the 2 Byte values of redirectionInformation delivered from the Connect
message............................................................................................................................ 46
1.7.6 Configure SRI-supported Version ............................................................................ 47
Chapter 2 Introduction to Signaling Faults Locating Tools....................................................... 47

2.1 OAM Signaling Tracing....................................................................................................... 47
2.2 Tracing Binary Code Streams............................................................................................. 58
2.3 Tracing Detailed Information of Single Calls ...................................................................... 61
2.4 Tracing Database Operations............................................................................................. 64
2.5 Unscrambling Debugging Information ................................................................................ 67
2.5.1 Acquiring Original Number Information.................................................................... 67
2.5.2 Acquiring Detailed Database Operation Information................................................ 68

2.5.3 Observing Number Analysis Results ....................................................................... 69

2.6 Introduction to Other Tools ................................................................................................. 72
2.6.1 Viewing SCP and Service Version Number –lsmscp Tool....................................... 72
Chapter 3 Typical Service Signaling Flows ................................................................................. 74

3.1 Typical Signaling Flow of the Prepaid Service ................................................................... 74
3.1.1 Prepaid Subscribers Call Prepaid Subscribers ........................................................ 74
3.1.2 Prepaid Subscribers Query the Balance.................................................................. 78
3.1.3 Prepaid Subscriber A Uses a Common GSM Mobile Phone (or PSTN Telephone) to
Report Loss, User A’s Homed SCPa Accesses a Different SCP from the Proximate SCPd
Accessed by MSCa/VLR/SSP........................................................................................... 82
3.2 Typical Signaling Flow of the IP17951 Service .................................................................. 85
3.2.1 Description of Basic Networking and Theory ........................................................... 85
3.2.2 Theory of National Interconnection .......................................................................... 86
3.2.3 Call the Non-Local PSTN Mobile Phone Subscribers of Other Networks; the
Service-Triggering SCP is not the Home SCP of the Subscriber ..................................... 87
3.3 Typical Signaling Flow of the Mobile Phone Rechargeable Card Service ......................... 96
3.3.1 When the Normal Recharging Flow SCPa and SCPb of the GoTone Subscriber are
not the Same SCP, the Operation Succeeds.................................................................... 96
3.4 Typical Signaling Flow of the VPMN Service ................................................................... 105
3.4.1 VPMN Service’s Requirements for Signaling......................................................... 105
3.4.2 When the Calling Party is a VPMN Subscriber, SCP Should Charge ................... 108
3.4.3 Calls inside the Network are Forwarded Unconditionally into the Network ........... 111
Chapter 4 Analysis and Handling of Signaling Faults.............................................................. 112

4.1 General Guideline ............................................................................................................. 112
4.2 Typical Case Study........................................................................................................... 114
4.2.1 A M-zone Subscriber Has a Long-duration Call but does not Enjoy the Charge Rate
Discount .......................................................................................................................... 114
4.2.2 Calls originated near the Charge Rate Switching Point do not have Any Charge
Rate Discount.................................................................................................................. 115
4.2.3 PPS Dials the Non-local Unicom Mobile Phone but No Toll Charge is Billed ....... 115
4.2.4 Secondary Trigger Leads to Charging of the Free Number................................... 116
4.2.5 Analysis of the Put-through Rate Signaling Statistics ............................................ 118
4.2.6 AIP Announcement Problem.................................................................................. 120
4.2.7 The E Manufacturer End Office Permanently Downs the Robot of SCP ............... 125
4.2.8 The End Office Responds Abnormally to the PA Operation .................................. 131
4.2.9 Number Display Problems Caused by a Certain Parameter Value ....................... 134
4.2.10 Number Attribute Errors Affect Charging ............................................................. 135
4.2.11 Since the hlrto Area Number Table is not Made Complete, Calls to Non-local
Subscribers are not Billed with the Toll Charge. ............................................................. 137
4.2.12 POP Card Subscribers Dialing the Local Fixed Phone Number are Billed with the
Toll Charge...................................................................................................................... 138

4.2.13 Announcement Makes the End Office to Output the Charging Bill ...................... 139
4.2.14 Since the Database Index is not Established, Query Times out and the Call cannot
be Put Through................................................................................................................ 139
4.2.15 Dial the PPS Number beyond the Retention Term and the Subscriber Hears “The
Subscriber You Dialed is Poweroff”. ............................................................................... 139
4.2.16 Since the Voice at the End Office is not Loaded, the Call is Terminated Abnormally
......................................................................................................................................... 141
4.2.17 Due to the Number Format Error, the Number of the Calling Party Becomes
“00000” and the Familiarity Number Enjoys No Discount ............................................... 141
4.2.18 A Subscriber Queries the Balance but Cannot Hear the Balance Normally........ 142
Chapter 5 Appendix...................................................................................................................... 144

5.1 Encoding Format of the GT Code..................................................................................... 144
5.2 Common Signaling Parameters........................................................................................ 147
5.2.1 Calling Party Number ............................................................................................. 147
5.2.2 Called Party Number.............................................................................................. 150
5.2.3 Generic Number ..................................................................................................... 150
5.2.4 Original Called Number.......................................................................................... 153
5.2.5 Redirection Information .......................................................................................... 153
5.2.6 CalledPartyBCDNumber ........................................................................................ 155
5.2.7 DateAndTime ......................................................................................................... 157
5.2.8 EventTypeBCSM.................................................................................................... 158
5.2.9 SubscriberState...................................................................................................... 159
5.2.10 O-CSI ................................................................................................................... 159
5.3 Execute Operations .......................................................................................................... 162

Keyword: Signaling analysis
Abstract: This document introduces the basic signaling of WIN products and describes fault
analysis.
List of Abbreviations:
List of References:

Preface
For mobile intelligent networks, it is a prerequisite for mobile IN maintenance

personnel and development personnel to master the basic signaling knowledge about
the mobile IN and possess certain fault analysis and troubleshooting capability. We
have never been in any short of materials but they are quite scattered instead of being
integrated into a systematic learning material. Therefore this document is compiled for
the purpose of offering a detailed, complete and systematic learning material to the
most possible maintenance personnel for the HW mobile IN. If we compare these
numerous materials to scattered pearls, we sincerely hope this document can serve as
a rope stringing up these pearls.
You can grasp the necessary signaling knowledge about the mobile intelligent network
and master the tools used to analyze and handle signaling problems and faults by
reading this document. This document can enable you to have a thorough
understanding of the mobile IN concerned.
This document focuses on analyzing and solving faults at layers higher than the TCAP
layer. Signaling and fault analysis about lower layers are introduced in some other
documents and will not be touched upon in detail here. But faults closely related to
services and the common faults at the TCAP layer will also be dealt with in this
document too.
The objects of this document are the senior maintenance personnel with certain IN
maintenance experience and a certain basic signaling knowledge. Therefore it is not
suitable to be used as an introductory reading material.
This document summarizes and rearranges a large amount of relevant materials

compiled by colleagues in the WIN sector, whose names we will not list here one by
one. However we sincerely appreciate all their efforts and abundant contents they
provided us.
For more systematic description of the basic signaling knowledge, this

document deals with all the IN-related knowledge and those involved in fault
analysis and troubleshooting. Nevertheless, we suggest lecturers take a flexible
approach according to the students and teaching requirements.
2006-08-30 Confidential document, for internal use only Page 2 of 203

Chapter 1 Basic Signaling Knowledge
This chapter describes basic signaling knowledge related to the MIN network,
involving SCCP, TCAP, CAP, INAP and MAP. It does not touch upon the basic
approach knowledge regarding it but deals with fault analysis and troubleshooting.
CAP is the focus we have handled and here in this part, we will talk about the function
of each important CAP operation and learn how some of the important parameters are
used for services. Through study in this part, you will be able to read and understand
the signaling flow of most of the service specifications
1.1 Basic Knowledge
First we will have a look at the location of the MIN in the entire signaling system:
Figure 1-1 Structure of the signaling system related to IN
What is shown above should be remembered by us during routine signaling

maintenance, for it will be of great instructive help during t fault locating and
troubleshooting. From the above figure we can learn that:
1) MTP is the basis for the transmission of all the signaling. Whenever the signaling
passes a NE, it must have to pass this part. Therefore, when the signaling
transmission channel has faults, we need to check if each NE’s MTP equipment

works normally when the signaling channel passes it and if the data have been
correctly configured.
2) TCAP is the bearer part of three application parts: INAP, CAP and MAP. They all
use the same TCAP primitive to send their own signalings, so it is prerequisite
that TCAP should be normally configured.
3) The three application parts (INAP, CAP and MAP) are independent from each
other at the application layer, so their signalings will not interfere with each other.
They only interact with the same parts at the opposite end.
4) At the service layer they are usually integrated, so they may affect each other. For
example, CAP IDP triggers the dialog and the service sends INAP Execute
interaction, if CAP ends the dialog, it will lead to abnormal ending of INAP
Execute interaction.
When we detect any signaling fault at the service layer, we should clarify as soon as
possible:
1) At which layer this fault occurs?
2) To which module this fault belongs to? If it occurs at the application layer, it is
about CAP, INAP or MAP?
3) How this fault is imported? If the application part is newly added or modified,
whether its bearer layer (TCAP, SCCP, MTP and etc.) has been correctly
configured? If the application layer remains unchanged, whether its bearer layer
(including the transmission link) has changed? Signaling faults are most possibly
caused due to importing or modification of certain configurations. Therefore, we
should clarify this issue soonest possible.
What we talk about later on will help you make the correct judgment quickly.
1.2 SCCP Knowledge Points
In this section, you should concentrate on the definition of addressing. Only when the
addressing configuration is correctly set can the signaling link normally implement
end-to-end transmission.
At the MTP layer, addressing between two adjacent points is provided. That is to say,
through the original signaling point address (OPC) and the destination signaling point
address (DPC), signalings can be transmitted between two adjacent points. Just as we
send a letter from Guangzhou to Beijing, the sender is only concerned about the
destination Beijing, regardless of how this letter is posted, by air, by train or by bus, or
whether it is transferred in Changsha or in Wuhan. It is for the post office to select a
quick, safe and economical way/path to realize it. Similarly with many signalings
irrelevant to circuits, such as IDP messages, it suffices to ensure that they can be

correctly transmitted from MSC/SSP to the landing point SCP. It is different from
signalings indicating circuit actions in ISUP. GT addressing is exported from SCCP.
Besides, a sub-system number (SSN) is imported at the SCCP layer and used to
identify each SCCP user at one node. When the SCCP message is transmitted to the
destination SCCP, SCCP must obtain the SSN of this message before it can send it to
the user. For the SSN of the IN part, except the CAP SSN used in interaction between
SSP and SCP, SCP needs to send ATI to HLR, so it involves the SSN of HLR; the SCP
of some service flows need to simulate MSC in order to send SRI messages to HLR,
so it involves the SSN of MSC; service invoke notifications are added in the
specification so that MSC can report to SCP on the supplementary service invoke
information (currently this is not used in the existing network), so the SSN of MSC is
involved here.
Those to be configured at the layer are related to signaling channels. So when you
discover signaling transmission is blocked, you should first of all check if the data at
this layer are correctly configured.
We will not describe in detail the specific signaling knowledge at the SCCP layer. Next
the differences between GT addressing and DPC addressing as described below will
help us understand the definition of addressing.
DPC Addressing:
For one message to be sent from A to K, if DPC addressing is adopted, it is necessary

to determine a route in advance, as shown above in red lines A->B->E->I->K; among
them, the format of the message sent by A is as follows:

When this message reaches B/E/I, it is not necessary for it to reach the SCCP layer.
Since it is not the DPC, this message is directly transmitted transparently by the MTP
layer. So when we make data about A/B/E/I, it is necessary to mark the DPC of point K
and the MTP route to point K. It is evident that a lot of MTP-layer data have to be made
for point A.
GT Addressing:
For one message to be sent from A to K, if GT addressing is adopted, it is only

necessary to consider selecting one point out of D/C/B (according to the principle that
different GTs adopt load balancing). A need not consider the routes after it. The format
of the message sent by A is as follows (Suppose the message is transmitted via point
B):
When the message reaches point B and finds out MTP’s DPC is itself, then B sends
the message to SCCP. After SCCP translates GT, it finds out DPC is not itself, so it

rewrites MTP’s DPC and sends the message to the following node. The format of the
message to be sent may be:
According to the principle of load balancing, if B routes the message to K to F.
Differences between DPC Addressing and GT Addressing:

1) For the MTP-layer data in the case of GT addressing, it is only necessary to
consider the adjacent signaling points instead of the remote ones. But if DPC
addressing is adopted, it is necessary to consider the MTP data of non-adjacent
signaling points.
2) DPC addressing needs to be translated again at the SCCP layer when it passes
STP but GT addressing only needs to be translated once at the SCCP layer.
1.3 TCAP Knowledge Points
1.3.1 Several Concepts
Dialogue: it refers to a series of TCAP messages exchanged between two TC users

when a signaling process of the application service is completed. The start, end,
sequence and contents of messages are controlled and interpreted by TC users.
Remember that a dialogue can only exist between two completely same application
parts, for example, a dialogue exists only between CAP of MSC/SSP and CAP of SCP,
but not between CAP of MSC/SSP and MAP of SCP. Normally a CAP dialogue
corresponds to a call process, but a call can correspond to two dialogues, like the
forward flow, two IDP dialogues will be triggered for subscriber B. The end of CAP
dialogues does not mean the end of the call; but the end of call will cause the end of
the dialogue.
Primitive: To put it simply, a primitive corresponds to several TCAP messages. No

matter how the user layer changes, it is borne by these primitives.
According to the transmission direction, for request primitives, the upper layer sends
request while the lower layer transmits messages outward; for indication primitives,
the lower layer transmits the opposite-end messages to the upper lower for handling.

According to their functions, primitives can be divided into component primitives and
dialogue primitives. The former are used in the user-layer data while the latter are
used to indicate the start, continue, end and abort of dialogues. Component primitives
need to be carried by dialogue primitives but the latter can exist independently, such
as tc_u_abort.
1.3.2 Dialogue Primitive
I. tc_begin
The first dialogue must start with it. When we receive this message, we can view:
The source address (sometimes called the calling address, but it is different from the
calling party in meaning) knows from which entity this message comes. Normally we
can view the GT of MSC and then determine from which equipment comes the
problem.
We can also view the application context. Different application contexts correspond to
different types of operations. If we can judge whether it is the CAP operation reported
by MSC/SSP or the ARI operation reported by AIP, or the operation of Execute, or
MAP ATI.
Unscramble the TCAP-layer code streams (this can be read with tools or through the
debugging information of SCP).
tc_begin
0 00 5C 01 00 00 00 02 FF 01 09 12 06 00 12 04 68
16 31 89 75 00 00 00 00 00 00 00 00 07 04 00 00 01
32 00 1D 03 00 00 00 00 09 12 0C 00 12 03 12 34 56
48 78 34 56 78 00 00 00 00 00 00 00 00 02 FF 32 34
64 30 00 00 00 00 FE F4 00 00 00 00 00 00 30 30 30
80 FF FF FE F0 00 00 8C CB 34 32 30 30 30 FF
Byte Length Meaning Value
0, 1 2 Length 00 5C
2 1 TCAP component primitive 01: tc_begin
3-6 4 DialogueID 00 00 00 02
7-8 2 QualityOfService FF 01
09 12 06 00 12 04 68 31 89 75
Destination address
9-26 18 00 00 00 00 00 00 00 00
86139857
Note 1: 09 refers to the valid

Byte Length Meaning Value

length
Note 2: 12 is the address

indicator
07 04 00 00 01 00 1D 03 00 00
27-38 12 Application context name 00 00
Note: 07 refers to the length
Originating address 09 12 0C 00 12 03 12 34 56 78
39-56 18
12345678345678 34 56 78 00 00 00 00 00
57-60 4 DialogueID 00 00 00 02
FF 32 34 30 00 00 00 00 FE F4
00 00 00 00 00 00 30 30 30 FF
61-92 32 userInformation
FF FE F0 00 00 8C CB 34 32 30
30 30
93 1 componentsPresent FF
Common application contexts:
IDP = {0x04,0x00,0x00,0x01,0x00,0x32,0x01};
ARI = {0x04,0x00,0x00,0x01,0x00,0x34,0x01};
SRI_V2 = {0x04,0x00,0x00,0x01,0x00,0x05,0x02}; (MAP Phase2)
SRI_V2+ = {0x04,0x00,0x00,0x01,0x00,0x05,0x03}; (MAP Phase2+)
Execute = {0x00,0x11,0x89,0x4C,0x02,0x03,0x03};
II. tc_continue
For a dialogue, it is necessary to distinguish whether it is the first tc_continue. At the

SCP layer, it is usually called tc_continue1, because though the message ID is the
same, the parameter of the first delivered tc_continue has the source address (SCP
address) and the application context compared with the following tc_continue
messages. Besides, the first tc_continue usually indicates the service is successfully
triggered and the dialogue continues.

Here we need to make sure if the source address (SCP address) of tc_continue1 is
correct, namely whether it is consistent with tc_begin. If it is not consistent, there may
exist some problems.
III. tc_end
It is used to end a dialogue. We should note that a tc_end can carry the component
primitive or be sent alone. By observing the value of parameter componentPresent in
the signaling, we can view whether it carries the component primitive. If not, a dialogue
can be terminated after this message is received. Otherwise we need to wait for the
component primitive. But how can we judge whether it carries the component or not
easily?
00 39 04 00 00 70 38 FF 1C 00 00 70 38 07 00 11
89 4C 02 03 03 00 00 00 00 00 FF 11 89 4C 02 03
03 00 00 00 00 00 00 70 38 FF 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 FF
From the above code stream we can easily find the application context. Starting from
07 there is a 12 Byte, followed by a Byte’s parameter componentPresent. When its
value is 0xFF, it means it is necessary to carry the component; when the value is 0, it is
not necessary.
In addition, when one tc_end is received, do not rush to conclude which dialog has
ended, for after a call is triggered, many dialogues are involved at the service layer
(such as INAP Execute dialogue and MAP ATI dialogue). We should make clear the
dialogue number and confirm the dialogue that ends (Be sure to keep in mind that for
other dialogue end or abort messages, this method also works).
IV. tc_u_abort
Normally when this message is received, it means some exceptions occur during the
dialogue. We can try to infer the cause of the dialogue termination through the cause
value of dialogue abort.
How can we obtain the cause value (abortReason) through the code dream?
00 38 05 00 00 71 40 FF 01 00 00 71 40 01 FF 00
00 00 00 00 00 00 00 00 00 00 FF 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00

Just keep in mind the Byte behind the dialogue number is abortReason.
The SCP of this message can be received or sent. The common abort reasons are as
follow:
NoReasonGiven 1
ApplicationTimerExpired 2
NotAllowedProcedures 3
AbnormalProcessing 4
Congestion 5
The reason why SCP is delivered can be:

1) When the call is aborted in the case of overload, abortReason = 1;
2) When SCF discovers repeated dialogue numbers, abortReason = 4;
V. tc_p_abort
This message may not be sent by the opposite entity but instead by the entity during
the transmission process. For SCP, it is very likely that SAU sends the message to
SCP. For example, when SAU detects no message is delivered during a dialogue
setup process, it will report on this message. Or errors will occur when the message
reaches SAU. Then you should consider whether there are any alarms or logs on
SAU.
Normally we should check if the preceding signaling flow has any exceptions.
VI. tc_notice
This message is common during debugging of new equipment. When a transmission

link has not been configured, the sender will receive such a message. That is to say,
when this message is received, those messages you sent previously may not be
transmitted to the final landing point. Then we should check the signaling transmission
links involved, especially the configuration on SAU.
We can also analyze the reason according to the specific reason values:
87654321
00000000 no translation for an address of such nature
00000001 no translation for this specific address
00000010 subsystem congestion

00000011 subsystem failure
00000100 unequipped user
00000101 MTP failure
00000110 network congestion
00000111 unqualified
00001000 error in message transport (Note)
00001001 error in local processing (Note)
00001010 destination cannot perform reassembly (Note)
00001011 SCCP failure
00001100 hop counter violation
00001101 segmentation not supported
00001110 segmentation failure
00001111
to spare
11111111
You can refer to ITU-T Q714 for interpretation of each specific reason.
Interpretation of the reason:
00 0A CB 00 00 B2 10 00 00 B2 10 01
This message is very short; the Byte after the dialogue number is the reason value
(01).
1.3.3 Component Primitive
I. tc_invoke
It is the most common component primitive carrying CAP, INAP, MAP and other
messages. From it we can learn the operation type (4 types), invokeID, operation ID
and specific operation content of the operation carried by it.
What is more important, we can learn the message ID of the application layer this
message corresponds to according to the operation ID, namely what operation it is.
Note that different application-layer protocols may correspond to the same ID, for

example, the operation IDs of CAP’s releaseCall and MAP’s SendRoutingInfo are both
22. We should also combine tc_begin in order to accurately figure out the messageID.
Of course if we are sure about a dialogue comes from a certain entity, it will be easy to
judge. For example, if the received tc_invoke has the same dialogue number as IDP,
then it must come from MSC/SSP, so this message surely is CAP ReleaseCall; if it is
transmitted to HLR, then it must be MAP SRI.
Specific operation contents will be explained later in combination with the

application-layer protocols.
II. tc_result_l
This primitive is used to return the operation result. Note that its operationID is the
same as that when tc_invoke sends the request. But we learn the result through this
primitive.
In fact most responses are carried through tc_invoke, for example, “play
announcement” (PA) operation ID is 47, its response is “use SRR” operation
(operationID is 49). Only when the operationID is clarified to be consistent response,
this primitive can be used to carry (such as the play collect number PC and activation
test AT).
III. tc_u_error
When signaling faults are transmitted, we should have the awareness to check if this
component primitive exists or not. We should pay attention to the reason value carried
by it.
Interpretation of the code stream:
00 0F 13 00 00 07 71 00 00 07 71 06 00 04 01 00 00 (the reason value is 4)
The common error codes are defined as below:

cancelled Cancelled ::= localValue 0
cancelFailed CancelFailed ::= localValue 1
eTCFailed ETCFailed ::= localValue 3
improperCallerResponse ImproperCallerResponse ::= localValue 4
missingCustomerRecord MissingCustomerRecord ::= localValue 6
missingParameter MissingParameter ::= localValue 7
parameterOutOfRange ParameterOutOfRange ::= localValue 8
requestedInfoError RequestedInfoError ::= localValue 10
systemFailure SystemFailure ::= localValue 11
taskRefused TaskRefused ::= localValue 12
unavailableResource UnavailableResource ::= localValue 13

unexpectedComponentSequence UnexpectedComponentSequence ::= localValue

14
unexpectedDataValue UnexpectedDataValue ::= localValue 15
unexpectedParameter UnexpectedParameter ::= localValue 16
unknownLegID UnknownLegId ::= localValue 17
IV. tc_u_reject
When the operation component received by the TC_user is not correct, this operation
will be rejected for implementation. The parameter contains the reject reason value.
How to view the reason value?
The reason is defined in Specification ITU-TQ773 as follows:

Reject ::= SEQUENCE {
invokeID CHOICE {
derivable InvokeIdType,
not-derivable NULL },
problem CHOICE {
generalProblem [0] IMPLICIT GeneralProblem,
invokeProblem [1] IMPLICIT InvokeProblem,
returnResultProblem [2] IMPLICIT ReturnResultProblem,
returnErrorProblem [3] IMPLICIT ReturnErrorProblem } }
Different types of problem codes are defined as below:

GeneralProblem ::= INTEGER { unrecognizedComponent (0),
mistypedComponent (1),
badlyStructuredComponent (2) }
InvokeProblem ::= INTEGER { duplicateInvokeID (0),

unrecognizedOperation (1),
mistypedParameter (2),
resourceLimitation (3),
initiatingRelease (4),
unrecognizedLinkedID (5),
linkedResponseUnexpected (6),
unexpectedLinkedOperation (7) }
ReturnResultProblem ::= INTEGER { unrecognizedInvokeID (0),

returnResultUnexpected (1),
mistypedParameter (2) }

ReturnErrorProblem ::= INTEGER { unrecognizedInvokeID (0),

returnErrorUnexpected (1),
unrecognizedError (2),
unexpectedError (3),
mistypedParameter (4) }
We can see from above that “problem codes” are divided into 4 types, each with its
own number.
For example debugging is implemented at a certain location and we trace the following
signaling on OAM:
SCP <============= time: 05:45:54
TCContinue2:
qualityOfService={-1,1}
dialogueID=57287
userInformation=
"0xff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"
componentsPresent=-1
SCP <============= time: 05:45:54

TCUReject:
dialogueID=57287
invokeID=3
problemCode={129,2}
lastComponent=1
Here 2 Bytes (of the decimal system) are printed: 129 and 2; 129 in the hexadecimal
system is 0x81; we can ignore the type of ‘8’ used in tag but pay attention to ‘1’, for it
corresponds to the type of the above problem code:
invokeProblem [1] IMPLICIT InvokeProblem,
It indicates it is the invokeProblem; according to 2, find mistypedParameter in

invokeProblem.
1.4 CAP Knowledge Points
CAP is the most important part in MIN signaling. We will not describe the theory of
each signaling in this chapter but we will talk about the functions of common signalings
and some parameters. Through this section, you will be able to easily understand the
signaling flow in the service specification and how a call process is constituted.

CAP is based on the INAP Specification of ITU-T and it is the simplified version of
INAP. If you want to have a further understanding of the intelligent network, you are
advised to reach the INAP Specification (ITU-T Q12xx series).
1.4.1 Basic Concepts
I. Reference specifications
CAMEL protocol family contains a series of protocols.

z GSM02.78 definition of the service
z GSM03.78 definition of the CAMEL functional entity
z GSM09.78 CAP Specification
To adapt to the application of CAMEL, part of the original GSM protocols are modified
accordingly. The major modified protocols are:
z GSM09.02 MAP Specification
z GSM03.18 Call handling
II. Support the GSM network structure of the CAMEL protocol
Originating network
Incoming call
Roaming party
MS originated call -
The forwarded outgoing calling party (or
party the forwarded party)
Query the network Access the network
From the figure above, we should understand why SCP is categorized into the home
network.
We can see SCP, like HLR belongs to the home network. What is the advantage of this?
We should know MS’s location is not fixed but HLR can ensure that others can reach it
no matter where it goes; wherever this MS originates the call, it can get its basic

information. For the same reason, SCP provides the function that wherever MS moves,
it can always enjoy the same service (except some special cooperation for part of the
end offices); meanwhile its account and service attributes will not be affected by the
change of locations. This is the basic advantage about SCP that it can provide
services in a centralized way.
In this figure we also can see it is possibly necessary to interact with SCP on the CAP
interface so as to query and access the network.
III. Functions of the functional entities related to CAP
HLR: it stores the subscription information required by the CAMEL service, such as
O-CSI and T-CSI. When the user powers on the mobile and the location is updated or
the O-CSI information itself changes, then the O-CSI information will be inserted into
VLR; when HLR responds to the route information request of GMSC, O/T-CSI will be
transmitted to GMSC.
MSC: when MSC needs CAMEL support in order to process a call, it will acquire the
O-CSI information in VLR and get the indication to request instruction from gsmSSF.
MSC is responsible for monitoring all the call states or events and notifying gsmSSF
during call handling so that gsmSSF can control the calls in MSC; when MSC invokes
the supplementary services, such as ECT, CD and MPTY, MSC will receive SS-CSI
from VLR, indicating it to deliver supplementary service invoke notification to gsmSCF.
VLR: it saves the O-CSI and SS-CSI of subscribers in the roaming location as part of
the subscriber data and provides the data to MSC when necessary.
GMSC: when GMSC needs CAMEL support in order to process subscribers’ calls, it
will acquire O/T-CSI from HLR by transmitting SRI, indicating it to request instructions
from gsmSSF. GSMC is responsible for monitoring all the call states or events and
notifying gsmSSF during call handling so that gsmSSF can control the calls in MSC;
when GMSC gets from gsmSCF the instruction to continue the call, it will re-send SRI
to HLR and obtain the roaming number so that it can be connected to the access
location MSC of the called party.
gsmSCF: GSM service control function. It can save CAMEL subscribers’ information
related to services, save and implement the service logic.
gsmSRF: GSM service resource function; it has the capability to complete dedicated
resources.

IV. Basic Call state model
O_Null & Authorise_Origination_

O_Exception
DP10 Attempt_Collect_Info
O_Abandon
Collected_Info DP2
Route_Select_ DP4
Failure
DP5
Analyse, Routing O_Busy
& Alerting DP6

O_No_Answer
DP50
O_Not_Reachable
O_Answer DP7
DP9 O_Active
O_Disconnect
Basic Call transition

Transition beyond Basic Call
The figure above is about the BCSM at the originating end and provides to us a view to
the interface between SCP and the exchange layer, namely, SCP can and only can
see events of one call through this model. To put it simply, in order for SCP to see the
call state at the switch side, several “holes” are punched. This figure just describes
these “holes” and their locations.
More “holes” need to be punched in order to acquire more information. In the 3G

version of CAMEL, some “holes” are added.
Meanwhile, this figure describes the call handling flow in the model. After a call is put
through (O_Active), it can only head for DP9 (onhook), then there will be no events
such as the calling party abort or route selection failure.
The specification defines some events for these “holes”, which thus become the
detection points (DP). SCP can instruct MSC/SSP on which DP information it would
like to know. So when passing these DPs during the call, MSC/SSP will report to SCP.

BCSM of the called party:
T_Null T_Exception
DP18
T_Abandon
Terminating_Attempt_Authorised DP12
DP51
T_Not_Reachable
DP13
T_Busy
Terminating Call Handling
DP14
T_No_Answer
T_Disconnect
T_Answer
DP15
DP17 T_Active
Basic Call transition

Transition beyond Basic Call

For the DPs of the called-party model:
CAMEL detection point: DP type Description:
DP12 Indication that the T-CSI is

TDP-R
Terminating_Attempt_Authorised analysed.
Indication that a busy

DP 13 T_Busy EDP-N, EDP-R indication is received from the
destination exchange
Indication that an application

DP 14 T_No_Answer EDP-N, EDP-R timer associated with the
T_No_Answer DP expires
Call is accepted and answered

DP15 T_Answer EDP-N, EDP-R
by terminating party
A disconnect indication is
received from the terminating
DP17 T_Disconnect EDP-N, EDP-R
party or from the originating
party.
A disconnect indication is
received from the originating
DP 18 T_Abandon EDP-N
party during the call
establishment procedure
Not reachable or call

establishment failure event
DP 51 T_Not_Reachable EDP-N, EDP-R can be determined from the
HLR or upon a cause IE in the
ISUP release message.
V. CSI-CAMEL subscriber information
CSI symbolizes the CAMEL attributes of a mobile subscriber. MSC triggers the
CAMEL service according to the CSI information, which is saved in the home HLR of
the mobile phone.
CSI can be divided into O-CSI and T-CSI, including:
gsmSCF Address: the gsmSCF address the user should access when he triggers the
CAMEL service;

ServiceKey: it is used to mark which service logic should be used by gsmSCF;
DefaultCallHandling: used to indicate whether the call should be released or continue

if the gsmSSF/gsmSCF dialogue has some faults.
TDPList: used to indicate the TDP list where DP trigger takes place. Currently O-CSI
can only use DP2 while T-CSI can only use DP12 for triggering.
DP standard: used to indicate whether gsmSSF should request instruction from

gsmSCF.
One important function of DefaultCallHandling is to set for some important clients that
MSC can continue the call when gsmSCF is abnormal without necessarily having to
get the indication of SCP.
1.4.2 CAMEL Service Trigger Process
I. Originating call trigger flow
When a CAMEL subscriber originates a call, the MSC accessed by the CAMEL
subscriber obtain from VLR the CAMEL subscription information (O-CSI) of the calling
party and O-BSCM will be set up in MSC. Then a control relationship will be set up
between MSC/gsmSSF and gsmSCF.
gsmSCF
MSC
gsmSSF/CCF
O(A-B) T(A-B)

1) When the subscriber has the location updated, HLR will insert the subscriber data
into VLR. O-CSI will also be inserted into VLR as part of the subscriber
information.
2) MS originates the call; BSS originates service request to MSC.
3) MSC queries the subscriber information in VLR. When VLR receives this request,
MSC queries the subscriber information and tries to match all the O-CSI with DP
rules. Once O-CSI which satisfies the DP rules is found, it can be confirmed that
the call originated by this subscriber needs CAMEL support. Then MSC/SSP will
trigger the CAMEL service according to the selected O-CSI information.
4) VLR returns to MSC the O-CSI which triggered this call. The O-CSI contains the
service key, SCF address and other key information.
5) MSC requests instructions from gsmSSF with the internal interface.
6) According to the gsmSCF address in O-CSI, gsmSSF originates service request
to this gsmSCF and the service key is contained in InitialDP.
7) According to the service key of InitialDP, gsmSCF implements relevant service
logic program, generates the instances of the service logic program and instructs
the next action of gsmSSF according to the requirements of the service logic.
Normally gsmSSF and gsmSCF set up and maintain a certain relationship
between them (usually the control relationship). Through this relationship,
gsmSSF reports to gsmSCF on the call handling state and receives the
instruction from gsmSCF to maintain, set up or disassemble a call.

8) MSC reports to gsmSSF on the MSC state or events through the internal
interface. The SSF state machine maintained by gsmSSF receives instructions
from gsmSCF and converts the instructions related to call handling into internal
call control instructions before sending them to MSC, such as Int_RealeaseCall,
Int_Continue and Int_Connect,Int_Error.
II. Terminating call trigger flow
When GMSC receives the call whose called party is a CAMEL subscriber, it will obtain
from HLR the terminal CAMEL subscription information (T-CSI) required for triggering
and set up T-BCSM in GMSC. Then a control relationship will be set up between
GMSC/gsmSSF and gsmSCF.
1) GMSC receives the Initial Address message of the switch at the transmitting end
(IAI or IAM).
2) GMSC queries the route information of the called party from HLR.
3) HLR first checks the subscriber information of the called party and checks T-CSI.
If there exists the T-CSI which satisfies the DP rules, it can be confirmed that this
call originated by this subscriber needs CAMEL support. HLR will not return the
subscriber’s route information, instead, it returns the selected T-CSI to GMSC. If it
can be forwarded, the subscriber’s O-CSI information will be also returned to
GMSC.

4) GMSC requests instructions from gsmSSF through the internal interface.

5) According to the gsmSCF address in T-CSI, gsmSSF originates service request
to this gsmSCF; the service key is contained in InitialDP.
6) According to the service key of InitialDP, gsmSCF implements relevant service
logic program, generates the instances of the service logic program and instructs
the next action of gsmSSF according to the requirements of the service logic.
7) Normally gsmSSF and gsmSCF set up and maintain a certain relationship
between them (usually the control relationship). Through this relationship,
gsmSSF reports to gsmSCF on the call handling state and receives the
instruction from gsmSCF to maintain, set up or disassemble a call.
8) GMSC reports to gsmSSF on the MSC state or events through the internal
interface. The SSF state machine maintained by gsmSSF receives instructions
from gsmSCF and converts the instructions related to call handling into internal
call control instructions before sending them to MSC, such as Int_RealeaseCall,
Int_Continue and Int_Connect,Int_Error.
9) GMSC re-queries the route information from HLR and notifies HLR of this query
without returning CSI.
10) GMSC returns the called party’s MSRN.
11) GMSC sends the Initial Address (IAI or IAM) to the terminal switch and continues
the call setup process.
1.4.3 Major Operations and Explanation of Parameters
I. IDP (Initial DP)
IDP is the first operation submitted by SSP in an intelligent call to SCP, containing
quite complete information required by the service logic; it is indispensable for each
intelligent call. Simply speaking, IDP refers to the operation that the switch tells to SCP
all the information it has grasped and the information required by the SCP service logic
so that SCP could acquire based on its own demands.
We need focus on the function of each parameter in this operation.
-Service key: serviceKey
As we know each service logic is identified by one unique interger – Service key (for
example, PPS’s Service key is 1; VPMN’s Service key is 3), different service logics
have different functions. If you hope MS can correctly use the service function, it is
necessary to correctly report the Service key.
When we discover a phone cannot be put through during debugging, we trace the
signaling and find that after MSC/SSP reports to IDP, it directly receives the tc_u_error
released by SCP, the error code is missingCustomerRecord (value: 6), it is very likely

that it is due to a service trigger error; so we need to confirm if the service key
submitted by IDP is what we expected; if the reported service key is the same as the
one we loaded; if this service has been activated.
-Number of the called party: calledPartyNumber:
This parameter contains the number used to identify the called party in the forward
direction, for example, ISUP’s called party number. This parameter is sent only when
the MS terminates a call or forwards a call.
Note that this parameter is only used in the calling flow and the forwarding flow, that is
to say, only the called party IDP uses this parameter to report on the called party
number. As for the calling flow, calledPartyBCDNumber is used (please see the
explanation below).
For this kind of calling/called-party numbers, it is very common that the attributes of
the number are wrong so that the call cannot be put through. By tracing we can judge
whether the attributes of a number are correct or not.
Next we will elaborate on how to read the attributes of the called party number
according to the code stream.
IDP code stream is as below:
00 79 10 00 00 00 61 00 00 00 61 00 01 FF 00 00
01 00 00 00 00 00 64 30 62 80 01 01 82 09 84 10
68 31 16 34 54 81 06 83 09 84 13 68 31 53 13 00
37 00 85 01 0A 88 01 01 8A 05 84 13 68 34 01 BB
07 80 05 90 90 94 03 00 9C 01 0C 9F 32 08 64 00
40 43 11 35 56 F8 BF 33 03 0A 01 03 9F 36 08 FF
A1 FF 07 0A 40 02 C7 9F 37 06 91 68 31 47 40 64
9F 39 08 02 40 30 21 51 70 75 23
Among them, the called party number is 86136143451860.
In the specification, the structure of the calledPartyNumber is defined as below:
8 7 6 5 4 3 2 1
1 Odd/ Nature of address indicator

even
2 INN Ind. Numbering plan Ind. Spare

3 2nd address signal 1st address signal
.
.
n Filler (if necessary) nth address signal
The attributes of the number are defined in the specification as below:
Nature of address indicator
0000000 spare
0000001 subscriber number (national use)
0000010 unknown (national use)
0000011 national (significant) number (national use)
0000100 international number
According to the called party number we know the 7 bits after the second character
before the real number are the attributes of this number, namely, in 0x84, 7bits refer to
the number’s attributes: 4. Its definition is the International number. In fact, this number
is the country code “86”, which is the international attribute indeed.
Generally speaking, numbers with the country code at the beginning have the
attributes of International numbers; those with the area code at the beginning have the
attributes of domestic numbers; some special numbers have unknown attributes. In
the service specification, there are usually some requirements for the attributes of
numbers.
-Number of the calling party: callingPartyNumber:
This parameter identifies the calling subscriber of the call source with the calling
subscriber number.
Besides the number attribute, several other parameters about this number may also
import faults.
Structure of the number of the calling party is shown as below:
8 7 6 5 4 3 2 1

even

2 NI Numbering plan Ind. Address presentation Screening

restricted indicator
.
.
In the table above, Address presentation restricted indicator (number presentation

restricted indicator) will have influence on whether the calling party number can be
displayed in the called subscriber.
Screening is a parameter which can also import signaling faults.
-BCD Code of the Called Party: calledPartyBCDNumber:
This parameter contains the number used to identify the called party in the forward
direction, including the service selection information, * and #. It is used only when the
MS is originating.
Note that this parameter is imported by GSM. Its length has been greatly increased
compared with the called party numberLength defined in ITU-T for the purpose to
expand the actual application of the mobile network. The original called party number
is 20-digit, for example, if we use the IP telephone to dial an overseas number with the
area code, we will discover 20 digits are not enough. Of course, the final number has
to pass ISUP, so it is necessary to comply with the ITU-T Specification, requiring that
the length of SCP should be less than 20 digits with the prefix removed.
-Location Number: locationNumber:
The following requirements are laid down in the service specification:
In the calling flow, the toll area code of the MSC/SSP where the host originates the call
is location is placed in this parameter (such as 86755), it will be used as the location
information for the host to access during charging.
In the called flow, if it is accessed by PSTN through GMSC, then fill in the area code
corresponding to GMSC. But this information has not been used up to now.
-Location Information: locationInformation:
This is also an important parameter, for it contains multiple sub-parameters:
vlr_number: the number of VLR which originates the call (such as 8613900430). This
parameter is mainly used to fill in the VLRNumber of the location accessed by the

subscriber in the called flow. Then SCP will analyze this number and reach the
corresponding area code as the area code of the location accessed by the called
subscriber.
CellID: this parameter is very useful when different charging discounts or statistics are
conducted. For the calling flow, it has been clarified in the service specification that this
parameter must be reported; for the called flow, when the end office does not report,
SCP will send ATI message to HLR to acquire it.
-eventTypeBCSM:
This parameter enables us to easily judge whether it is the calling flow or the called
flow. When it is 12, then it is the called flow (MT); when it is 2 and when the original
called party ID and Redirecting party ID do not exist, it surely is the calling flow (MO);
when it is 2 and the above two parameters exist, it must be the forwarded MF flow.
-Subscriber state: subscriberState
The possible states of the mobile subscriber invoking the CAMEL service are: busy,
idle and unreachable. This parameter may be used on some occasions when the
announcement is played.
-msc Address:
This parameter tells the MSCID allocated to GMSC/MSC and we can know which
MSC the signaling comes from. The parameter’s value is the same as the value of the
source address obtained in tc_begin.
II. RRBE (Request Report BCSM Event)
From the above-mentioned basic call state model (BCSM), we learn that each call is
made up of a series of states. The detection point (DP) is set between states, which
can also be understood as the break point during the call. MSC/SSP meets DP only
because some call events have taken place. On different call branching occasions, the
service only needs to know part of the DPs, so it should instruct MSC/SSP to pay
attention to which DPs.
SCP delivers to MSC/SSP just through this operation. During a call, it is permitted to
deliver RRBE for multi-times. Multiple DPs can be configured for each RRBE. The
calling flow only allows the configuration of DP events defined by this state model.
Keep in mind that for the calling flow, there is only one Disconnect event, but we know
the service flows for the calling onhook and the called onhook can be completely
different (for example, if the called party hangs up, play announcement to make the
calling party continue input another called party number and SCP will reconnect; but if
the calling party hangs up, the call cannot but be released). Into RRBE is imported the

parameter legID. When legID=1, it refers to the calling party; when legID=2, it refers to
the called party. It is necessary to report this parameter when the messages are
reported.
This message is usually necessary to be delivered; otherwise the service is not aware
of the events (such as abort and the called party busy) during the call setup process
and cannot correctly handle them.
III. CTR(Connect To Resource)
We know the announcement or the number receiving resources of the switch is

relatively independent. If the service logic of SCP wants to request the switch to play
the announcement to the subscriber or receive the number, it is necessary to send this
message to MSC/SSP. That is to say, when it is necessary to deliver PA or P&C, this
operation must be delivered; but after it is delivered, PA or P&C can be consecutively
delivered for many times, for then MS has been connected with the announcement
resources, unless SCP has clearly delivered DFC to notify MSC/SSP to cut off the
connection.
There is one parameter: serviceInteractionIndicatorsTwo in this message but its usage

is not clearly clarified in the GSM Specification and this leads to some problems (such
as number receiving failure, generation of common bills when announcement is
played). CMCC stipulates the value of this parameter under different conditions. You
can refer to relevant documents. The basic concept is that if only PA exists, fill in
notRequired(1); as long as P&C exists, fill in Required(0); as long as it passes AIP, fill
in Required(0).
This message is delivered only when announcement playing or number receiving is

conducted through MSC/SSP and before connection has been set up for resources.
IV. ETC(EstablishTemporaryConnection)
What is different from CTR connection is that the announcement number receiving
resources of the MSC/SSP which accesses the call are used by ETC to connect with
the announcement number receiving resources on AIP. Then a voice channel must be
set up through ISUP between MSC/SSP and AIP.
This message contains the following parameters:
assistingSSPIPRoutingAddress: fill in AIP’s GT code so that MSC/SSP can transmit

the signaling to AIP;
correlationID: the content to be filled in depends on each SCP vendor. Currently HW

SCP fills in the robot number of this call. MSC will forward the message to AIP; then
AIP will report to SCP through ARI. SCP finds out the robot which handles this call.

scfID: fill in SCP’s GT (such as 8613740441). The code of this parameter is not
clarified in the GSM Specification, so it is necessary to refer to the documents issued
by CMCC. Currently the bare code is adopted for encoding (tag+len+BCD).
serviceInteractionIndicatorsTwo: the same as CTR.
This message is delivered only when announcement playing or number receiving is

conducted through AIP or other functions on AIP are used and before connection has
not been set up for resources.
V. ARI(AssistRequestInstructions)
It is used to request interaction with SCP after AIP has received MSC’s IAI/IAM
message so that SCP can deliver PA/P&C.
Note that ARI uses a new dialogue of tc_begin, that is to say, it uses a different
dialogue number from that of IDP.
VI. DFC(Disconnect Forward Connectiong)
When SCP judges it is not necessary to play announcement to or receive number from
the subscriber, it will deliver DFC to MSC/SSP and request SSP to cut off dedicated
resources and connection with the subscriber.
This operation involves no parameters. It is applicable to connection set up by CTR or

ETC.
VII. PA (Play Announcement)
SCP delivers to MSC/SSP or AIP and requests to play announcement to subscribers.

PA only plays announcement without receiving numbers but P&C can conduct both.
Major parameters:
elementaryMessageID: each speech has its unique number. SCP instructs which
announcement should be played according to this parameter. It is a 4-Byte interger but
CMCC has specified the value of the 4 Bytes. Each speech ID includes: service
feature Code (usually corresponding to the service key) + language type + internal
speech number of the service.
Definition of elementary message ID
Record announcement No.

Service key Language type Retention
corresponding to the service
bit 31 24 23 22 21 16 15 0

24~31bit: Service key
22~23bit: Language type (00: mixed language, 01: Putonghua, 10: English, 11: local
dialect).
21~16bit: Retention
0~15bit: Record announcement No. corresponding to the service
For example, a speech ID is: 0x140007F, the first byte refers to the service key1;
language type is Putonghua; the speech No.in the service is 127.
Besides, announcement can be played to multiple speeches and variables can be

played.
numberOfRepetitions: the maximum time counts one speech can be repeated;
duration: how long announcement playing can last;
Interval: the pause time gap between two repetitions of announcement playing;
disconnectFromIPForbidden: after announcement is played, when it is false, it is

MSC/SSP or AIP that starts disconnection with MS, then it is no longer necessary to
deliver DFC; when it is true, it is necessary for SCP to deliver DFC to instruct
disconnection. When we need to deliver consecutively multiple PA/P&Cs, the
preceding PA/P&Cs should all be set as True in order to continue using this connection;
when it is the last speech, it can be set as false.
requestAnnouncementComplete: it is used to notify MSC/SSP or AIP whether it is

necessary to report to SCP after announcement is played.
This corresponding result message is SRR.
VIII. P&C (Prompt & Collect user information)
Prompt & collect user information; SCP delivers it to MSC/SSP or AIP to request the
user to play the alert tone and collect the digital information as shown when the user
presses the phone keys. Parameters of P&C include the code of the alert tone and
relevant requirements for the information to be collected.
IX. AC (Apply Charging)
Since the charging point of the intelligent network is in SCP, SCP needs to know
information such as the duration. This operation is delivered by SCP to SSP
requesting SSP to prepare for charging; before SCP delivers to AC, it is necessary to
conduct calculation according to the home location and access location of the calling
subscriber so that relevant charging information can be delivered to SSP through AC.

Once it is detected that the called subscriber replies, collection of the charging
information can begin.
Major parameters:
maxCallPeriodDuration: the maximum call duration that is permitted to give to the

subscriber by MSC/SSP. When the time is up, MSC/SSP should report to ACR. But
then the call is not released but still waits for SCP’s instruction (to deliver one section
duration or to release the call). But why this parameter is imported? We suppose the
subscriber’s conversation lasts one hour, if the conversation goes abnormal in the last
segmentation, then the cost for the previous 45 can still be normally received with only
the last segment chare lost; otherwise it will be the charge for 1 hour. This parameter is
very effective to avoid overdrafting of services which share the same account.
tariffSwitchInterval: rate switch interval. When services are charged, there are cases
when different charge rates are adopted before and after a certain time point (for
example after 11 pm, a 50% discount is implemented). Through this parameter, MSC
will be informed of the distance to this time point so that MSC can distinguish the front
and back segments when reporting on the duration.
This parameter needs not to be delivered for free phones or services are not charged
in SCP. Otherwise it must be delivered when a call is set up and during the call.
X. ACR (Apply Charging Report)
SSP submits to SCP the charging report, which is the reference for SCP to conduct
charging.
Major parameters:
timeInformation: duration information. Note that this parameter refers to the

accumulated duration since the self-reference point (reply point or rate switch point). It
contains the rate switch information.
CallActive: it shows whether the call is in the onhook state. We can judge that directly
with this message. Then the service can deliver ReleaseCall to end the interaction and
release the switch resources without waiting to report ERB event.
XI. FCI (FurnishChargingInformation)
This operation is used to instruct MSC/SSP to insert the sorting ID into the charging
record. Some services were originally charged at the end office but now they are
charged in SCP where bills are generated. These bills generated by SCP will be used
for settlement. But then the end office can still generate bills normally. So we need to
sort them out. This operation can complete this function, for example, the VPMN
service delivers a string “800130” to the end office as the sorting ID of the bills.

XII. Continue
This operation is delivered by SCP to SSP notifying it to continue the call suspended
just now.
When SCP does not change any parameters such as the number of the calling party,
deliver through this operation. After MSC/SSP receives it, begin to connect the call.
XIII. Connect
When the calling/called party numbers are changed, it is necessary to use this
operation to notify MSC/SSP to conduct corresponding changes.
Major parameters:
destinationRoutingAddress: it is the called party number. For example, number B is

dialed, the service changes it into number C; or 17951 + the called party number is
used, the service can directly strip 17951 and then deliver the real called party number.
Then number C or the real number is filled in this parameter; MSC is connected with
this number not the originally-dialed number. Like the code of calledPartyNumber, the
attributes of this number may lead to problems at the end office. Since GSM has no
specific requirements for this parameter and for MSC, manufacturers have different
understandings. Now it is clarified in the service specification. We can see the
requirements for this number in the service specification for different flows.
genericNumbers: currently this parameter is usually used to save the number of the
calling party (when it is necessary to modify the number of the calling party). Similarly,
since this number is not clarified in the GSM Specification, it may import some
problems. So we should refer to the service specification.
Structure of this parameter is:
8 7 6 5 4 3 2 1
1 Number qualifier indicator

even
3 NI ind. Numbering plan Ind. Address presentation Screening

restricted Ind.

Figure 3/Q.763 – Generic number parameter field
This parameter is similar to callingParytNumber but it has one more Byte “Number
qualifier indicator”. It is defined as below:
00000000 reserved (dialled digits) (national use)
00000001 additional called number (national use)
reserved (supplemental user provided calling number – failed

00000010
network screening) (national use)
reserved (supplemental user provided calling number – not

00000011
screened) (national use)
00000100 reserved (redirecting terminating number) (national use)
00000101 additional connected number
00000110 additional calling party number
00000111 reserved for additional original called number
00001000 reserved for additional redirecting number
00001001 reserved for additional redirection number
00001010 reserved (used in 1992 version)
0 0 0 0 1 0 1 1⎫
⎪
to ⎬ spare
0 1 1 1 1 1 1 1 ⎪⎭
10000000⎫
⎪
to ⎬ reserved for national use
1 1 1 1 1 1 1 0 ⎪⎭
11111111 reserved for expansion
However currently it is required to be 0x80 in the service specification.
XIV. ERB (Event Report BCSM)
It is used by SSP to report on call events to SCP. Call events which are prearranged by
RRBE in advance are delivered through SCP.

It is necessary to point out that the forward events and T-Busy can be reported and
parameter Forward Pending can be set through this message in the new specification.
XV. RC (Release Call)
It is delivered by SCP to SSP to notify it to release resources and end call

disconnection.
XVI. SRR (Specialized Resource Report)
Specialized resource report. When PA implementation is completed, such a report will

be submitted to SCP telling it the announcement playing has ended.
XVII. AT (ActiveTest)
It refers to active test. After an intelligent call is set up, SCP will deliver such an
operation to SSP every 6 minutes and SSP will give a final reply after receiving it. After
receiving it, SCP can confirm communication between SCP and SSP is normal; If
having not received it, SCP can confirm contact with SSP is cut off and all the
resources of this call will be disconnected.
This message can protect resources from being suspended for a long time. This
operation only “reports on success”, so if we trace the signaling and observe SCP
delivers AT and can still get the reply after a while, SCP will release the call.
XVIII. About the acquisition of the user access location information
As we know, the user home area code and the access location area code are required
to conduct charging. We can obtain the area code of the home location by directly
analyzing the number. For fixed numbers, we can obtain them by stripping the area
code of the reported number; for mobile numbers, we can obtain them by matching the
hlrtoarea number. But it will be more complicated for the area code of the access
location. For the calling flow, SCP obtains the area code with the country code from
the location number in the IDP message; for the called flow, the specification requires
that MSC/SSP fill the VLRNumber field in locationInformation according to the
VLRNumber returned by SRI. But VLRNumber can only obtain the area code through
the msctoareanumber table to conduct number analysis.
For the acquisition of the cellID, the calling/called flows are different. For the calling
flow, since it is triggered at the VMSC of the calling party, this VMSC can know detailed
cell information and report at the cellID of locationInformation; for the called flow, since
it is also triggered at GMSC or at VMSC of the calling party, it cannot get the detailed
cellID, so IDP of the called party may not be reported. It is necessary for ATI to acquire
it.

XIX. About bill sorting
As we know currently subscribers to the IN service include those with accounts at

BOSS, then SCP and MSC/SSP both can generate bills and transmit them to BOSS
for rating charging. We need a certain ID so that BOSS can sort out such bills of
MSC/SSP.
For the calling flow, since it is triggered at the calling party VMSC, SCP delivers FCI to
MSC/SSP so that it can insert the removal ID into the calling party bill; but for the
called flow, since it is triggered at GMSC or at VMSC of the calling party, but the called
party bill is generated at the called party VMSC, so the problem cannot be solved by
delivering FCI. So we adopt the solution to modify the number of the calling party (with
the prefix 60 added) in the called flow. More specifically, we modify the number of the
calling party in genericNumber of Connect, then MSC covers the original number of
the calling party. The number of the calling party is transmitted through IAM/IAI of
ISUP to the called party VMSC so that the number of the calling party of the called
party bill obtains the removal ID.
1.5 MAP Knowledge Points
Regarding MAP signaling, currently ATI and SRI are mainly used in the intelligent
network. But it has been greatly expanded in the 3G specification.
1.5.1 Mapping between the MAP Service and the TC Service
We know that all the MAP messages are borne by TCAP, but in the MAP specification,
a series of service primitives are defined, these primitives need to be mapped into the
TCAP primitive, such as map_Close primitive, but there is no such a primitive to bear it
for transmission, instead it is mapped into the tc_end primitive. The corresponding
relationship is listed in the table below.
Common services that are mapped to the TC service
MAP service primitive TC service primitive
MAP-OPEN request (+ dedicated

TC-BEGIN request (+ component
service primitive for all subscribers) +
handling primitive )
MAP-DELIMITER request
MAP-OPEN response (+ dedicated

service primitive for all subscribers) TC-CONTINUE request (Note)
(component handling primitive)
+ MAP-DELIMITER request

(dedicated service primitive for all

TC-CONTINUE request (+ component
subscribers) + MAP-DELIMITER
handling primitive)
request
(dedicated service primitive for all TC-END request (+ component handling

subscribers) + MAP-CLOSE request primitive)
MAP-U-ABORT request TC-U-ABORT request
TC service that is mapped onto the common services
TC service primitive MAP service primitive
MAP-OPEN indication (+ subscriber

TC-BEGIN indication (+ component
dedicated service primitive) +
handling primitive )
MAP-DELIMITER indication (Note 1)
The first time: MAPOPEN confirmation (+

subscriber dedicated service primitive) +
TC-CONTINUE (+ indication MAP-DELIMITER indication (Note 1); the
component handling primitive) following times: (subscriber dedicated
service primitive) + MAP-DELIMITER
indication (Note 1)
MAP-OPEN confirmation (Note 6)

TC-END indication (+ component
(subscriber dedicated service primitive) +
handling primitive)
MAP-CLOSE indication
MAP-U-ABORT indication Or
TC-U-ABORT indication MAP-P-ABORT indication (Note
2)MAP-OPEN confirmation (Note 3)
MAP-P-ABORT indication (Note

TC-P-ABORT indication
4)MAP-OPEN confirmation (Note 5)
1.5.2 Introduction to MAP Operation
z ATI (AnyTimeInterrogation)
When SCF conducts service handling, it may need to know some subscriber
information, such as the subscriber state and his current location. The query operation
of MAP Phase II + AnyTimeInterrogation can satisfy this demand. SCF can use ATI
operation at any time to query the current state and location of a subscriber. During

service handling, we can consider implementing charging based on time and location.
Subscriber information that can be queried with ATI by SCF contains:
1) Subscriber State
2) LocationInformation
When HLR handles the ATI operation, if the queried subscriber information is known,
HLR will directly return the ATI response (ATIRes). If the information is unknown, HLR
can use ProvideSubscriberInfo to query relevant information in VLR.
Currently service application mainly involves acquisition of the location information

(when IDP does not report the location information in the called flow), parameters such
as vlr_number, locationNumber and cellIdOrLAI can be returned.
For this operation, SCP originates the dialogue and uses different dialogue number
from that of IDP. According to the mobile phone number, it is sent to HLR (GT code
can be obtained according to the HLR of the mobile phone number, so SCP need not
configure the addressing information of HLR).
Note: It is necessary to confirm before use of this operation whether HLR supports this
operation. According to the existing networks, it is still likely that the HLRs of some
manufacturers do not this operation.
I. SRI (SendRoutingInformation)
In the specification, this interface between SCP and HLR has not been defined, but
some services need to get MSRN, so SCP simulated as MSC will send the SRI
message to HLR.
The return result can be MSRN or the forwarded number. After MSRN is obtained, the
area code of its access location can be got through number analysis in order to
implement charging reference. Besides it can also be used in the color ring service.
After MSRN is obtained, it is used for connection.
For this operation, it is also SCP that originates the dialogue using different dialogue
number from that of IDP. It is sent to HLR according to the mobile phone number (GT
code can be obtained according to the HLR of the mobile phone number, so SCP need
not configure the addressing information of HLR).
1.6 INAP Execute Knowledge Points
The INAP operation here refers to the Execute operation. In the GSM CAMEL
Specification, the interconnecting operation between SCPs is not defined. In the
CMCC MIN, the standard INAP Execute operation is creatively imported in which
recharge and information interaction between SCPs have been put into wide
application.

1.6.1 Background
Status quo:
1) The intelligent service subscribers become more and more;
2) The number of the SCP equipment gradually increases;
3) SCP regions are scattered;
Subscribers hope that their service characteristics will not be affected when they roam;
Meanwhile networking between equipment should be simplified.
Requirements for SCP (VC):

1) Information exchange about the rechargeable card between SCP and VC,
including query and update card No.
2) Service information sharing between SCPs: the services may need to query or
update the information on other SCPs according to the demands.
Typical application:
1) The rechargeable cards are centralizedly placed in several VCs. SCP should
enter any of these VCs to query the balance and validity term of a rechargeable
card. After the subscriber recharges the card, it is necessary to set this card as
invalid;
2) Prepaid subscriber A uses the mobile phone of prepaid subscriber B to report
loss but they belong to different SCPs. The call is triggered to B’s home SCPb,
which needs to notify A’s home SCPa to set this subscriber as loss-report.
How can we select a proper solution that can satisfy SCP interconnection?
1) Openness: SCPs in different locations and of different manufacturers can easily
interconnect each other. The internal change of one SCP will not affect other
SCPs;
2) Expansiveness: A SCP can be easily added to the network;
3) Fully make use of the existing network structure and resources; one method often
adopted abroad is to make use of the manufacturer’s protocol use the data
network or the special signaling network as the bearer network; in China, the
common practice is to adopt the dedicated protocol over the data network mode,
as shown in the figure below:

200 platform
200 platform 200 platform
Packet
switching
200 platform network 200 platform
200 platform 200 platform
200 platform Figure 1. 200

interconnection diagram
But these solutions have poor openness and require large equipment investments, so
they are not suitable for large-scale networking.
In the ITU INAP Specification, SCP’s demand for interconnection has been considered.
In IN CS-2, Execute operation is added, namely, the two communicating parties set
the calculation of a group of operations as an execute method (method). In an
execute signaling, SDF executes this method and returns the result. Different
SCPs require SDF to execute different execute operations. This can be
distinguished by parameter methodID in the execute signaling. In this way, SDF
can adapt to different kinds of service demands.
According to the publicized IN protocol and based on the existing No.7 signaling
network which complies with the specification, it is easy for the intelligent networks of
different manufacturers to implement interconnection and interworking. Information is
transferred through the No.7 signaling network. It has high reliability, small network
delay, powerful system expansion and upgrading capability; its flexible networking
adapts to the demands for service expansion and this is the development direction to
implement the service interconnection function.
1.6.2 Explanation of the Signaling
The definition of the Execute operation is quite complicated but in practical application,
information is transferred only at the service layer of SCP. Its definition depends on the
understanding of the service layer. For more details, we will have to refer to the
definitions of methodID and ObjectID in the service specification as well as the usage
of methodID.
1) How to read the Execute description in the service specification?
For example, in Prepaid Service Signaling Flow Specification 4.2.doc, the loss-report
loss is described as below:
Execute (the first time) Object
RDNSequence

AttributeTypeAndValue
Type id_oi_serviceKey (note)
Value 1
Type id_oi_msisdn (note)
Value Mobile phone number
MethodID id_mt_ppsclaimMissing (note)
InputAssertions
Type id_oi_pinnumber (note)
Value 8-digit subscriber password
SpecificInput
Value 0
Execute Result (the first

time)
SpecificOutput
int4element 1
Note: Object ID type: its value is defined in Appendix 1
Each object of Execute is divided into type and value. Type is a character string, which
will expand with the service specification; while value corresponds to the value of type.
For example, the type is id_oi_serviceKey, the service specification requires its value
be 1.
The id_oi_serviceKey above corresponds to an ObjectID (starting with id_oi), as

defined in the service specification, actually it is a group of character strings. It is
described in the Appendix as id_oi_serviceKey = {itu-t recommendation q 1228
ServiceID (2) attributeType(4)AttributeID(3)}; after converted into the hexadecimal
system, it is “0x00 11 89 4C 02 04 03”. In fact, except the last 2 Bytes after these
id_oi(s) may be the number, the rest parts are the same. So we can obtain its
corresponding strings of the hexadecimal system according to the definition in the
service specification. For example, id_oi_msisdn ={itu-t recommendation q 1228
ServiceID(2) attributeType(4)AttributeID(13)}, only the AttributeID is changed, its
hexadecimal string is “0x00 11 89 4C 02 04 0D”.

Similarly, the function of id_mt_ppsclaimMissing is described in the service

specification – it is the definition of methodID. In the service specification it is defined
as: id_mt-ppsSupplyClaimMissing={itu-t recommendation q 1228 ServiceID(2)
methodType(10)MethodID(3)}. Its corresponding character string is “0x00 11 89 4C 02
0A 03”.
By reading the service specification, we can learn the parameter meanings and values
of Execute during an interconnection process.
1.6.3 How to Understand the Traced Execute Code Stream?
For example, we get the printing below through OAM tracing:

SCP <=============
TCBegin:
destinationAddress=
"0x0a 12 92 00 11 04 68 31 87 00 f2"
applicationContextName=
"0x07 00 11 89 4c 02 03 03"
originatingAddress=
"0x0a 12 92 00 11 04 68 31 87 00 f6"
dialogueID=119
userInformation=
"0xff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"
SCP <=============
**********************Execute Argument **************************
object=
[0]=
type=
global= 304
0x00 11 89 4c 02 04 03
value=
int4Element=4
[1]=
type=
global= 304

0x00 11 89 4c 02 04 0e
value=
stringElement="191000000000000006"
[2]=
type=
global= 32
0x00 11 89 4c 02 04 0d
value=
stringElement="13908882008"
methodID=
0x00 11 89 4c 02 0a 0d
InputAttribute=
[0]=
type=
global= 0
0x00 11 89 4c 02 04 15
value=
SpecificInput=NOT PRESENT
..........................................................................
....
This code stream provides the following information:

1) First we can see in object[0], the corresponding string of type is “0x00 11 89 4c 02
04 03”; after looking up the Appendix Object IdentifierID Allocation Table, we know it
refers to the service key; then its value is =4, which means it correspondsto
Service key 4.
2) Then in object[1], the type is 0x00 11 89 4c 02 04 0e; after looking up the Appendix
Object IdentifierID Allocation Table, we know it correspons to “Password of the
rechargeable card”;
3) Then in object[2], the type is 0x00 11 89 4c 02 04 0d; after looking up the Appendix
Object IdentifierID Allocation Table, we know it correspons to “Mobile phone
number to be recharged”;
4) Then look at methodID, the string is 0x00 11 89 4c 02 0a 0d; after looking up the
Appendix RSDP-MethodID Allocation Table, we know it corresponds to “non-local
the calling number to be recharged”;
5) Finally in InputAttribute [0], the type is 0x00 11 89 4c 02 04 15; after looking up the
Appendix Object IdentifierID Allocation Table, we know it correspons to “Number
of the calling party”.

1.7 Signaling-Related Configuration Items
To solve some of MSC/SSP’s defects in certain signaling parameters on SCP, the

flexibility between SCP and the end office is increased and some parameters are
made into the configuration items.
These items can be dynamically configured.
Under normal circumstances, please do not modify their default values.
1.7.1 Time Interval of the Active Test (AT)
SCP sends an ActiveTest message to MSC/SSP every the local interval. If it receives a
response, the dialogue is regarded as normal; if it does not receive any response (lost
during intermediary transmission or the end office thinks this dialogue is not released),
SCP will release resources.
TimeAT = 360 #time interval for activetest, unit: second, min:120s, max:480s,
defaut:360s
Parameter
Description
name
The specification requires this parameter should be configured as

360 but in actual application, it is discovered that the end-office
equipment of some manufacturers cannot timely report the onhook
TimeAT time to SCP after the subscriber hangs up. This causes untimely
release of the resources. Therefore, this parameter can be
configured as a figure smaller than 360, for example:
unit: second. The value range is [120, 480]; the default value is 360.
1.7.2 When the end-office temporary connection message (ETC) is

configured, are bi-directional indicators required?
This parameter is applicable to the networks which play announcement through

independent IP. This can overcome the defect of the bi-directional indicator in the ETC
of some manufacturers.
When ETC_BOTHWAY is 0, it means the bi-directional indicator is needed; when its

value is 1, it means the bi-directional indicator is not needed; when its value is 2, it
means it uses the SSD value filled in UI or UISCRIPTSIB by the service.

# this item is for reigning the value of bothwayThroughConnectionInd

# in ETC (CAN be dynamic read)
# 0--bothwayPathRequired
# 1--bothwayPathNotRequired
# 2--get the value in SSD
# default--0
ETC_BOTHWAY = 0
Parameter
Description
name
Normally it is the default value 0, which means the bi-directional

indicator is needed. This complies with the requirements of the
specification.
ETC_BOTHWAY Modifying this parameter can severely affect the normal
operation of services! You are advised to consult the technical
support personnel in Huawei and finalize the modification plan
after obtaining the confirmation.
1.7.3 Configure parameter screening of Generic Number in the Connect

message
This parameter can be set to overcome the defects of some of the end-office
equipment, making the call unable to be put through or not filling in the number of the
calling party in the bill.
When the value of SCREENING is 0, it means the transparent transmission mode is

adopted, namely, it should be consistent with the screening in IDP’s number of the
calling party reported by the end office. Otherwise, the configured value will be
mapped to this value.
#this Item is for the value of screening in genericNumber (CAN be dynamic read)
#0--Transparently set to same value as in callingPartyNumber
#1--0x00: user provided, not verified
#2--0x01: user provided, verified and passed
#3--0x02: user provided, verified and failed
#4--0x03: network provided
#default--0
SCREENING =0

Parameter Description
name
SCREENING The value range is [0, 4], the default value is 0. The attributes of
this parameter are defined in ITUT-Q763. Usually it uses the
default value 0, which means the transparent transmission mode
is adopted in order to comply with the requirements of the
specification. Modifying this parameter can severely affect the
normal operation of services! You are advised to consult the
technical support personnel in Huawei and finalize the modification
plan after obtaining the confirmation.
1.7.4 Configure the timeout wait time standard after SCP transmits ATI or
SRI
#this item is to set the time for the ATI or SRI to wait for the HLR's response
#unit: second, Max: 300, Min: 10, Default: 15
TimeOfWaitATIRsp = 15
Parameter name Description
The value range is [10, 300], the default value is 15.

TimeOfWaitATIRsp
The suggested value is 15.
1.7.5 Configure the 2 Byte values of redirectionInformation delivered from

the Connect message.
The format of the value is “xx,yy”. Before the comma is the first Byte’s value; after the
comma is the value of the second Byte. Both are in the hexadecimal system.
# two Bytes’ values of redirectionInformation delivered by Connect.
# each value is in the hexadecimal form; the value range is (00,00 ff,ff]
# it is defaulted or set in the wrong form – 33,31.
RedirectionInformation = 33,31

Parameter name Description
The value range is [00,00, ff,ff]; the default value is 33,31.

In regions where the color ring service is demanded, it is set
as 33,31; but for the overlay network VPMN, it should be set
RedirectionInforma as 31,31.
tion Modifying this parameter can severely affect the normal
operation of services! You are advised to consult the
technical support personnel in Huawei and finalize the
modification plan after obtaining the confirmation.
1.7.6 Configure SRI-supported Version
MapPhaseVersion = 2 # value range [2,3,9]
# support SRIMapPhase2+
# when the value is 2, SRI supports the MapPhase2 version
# when the value is 3, SRI supports the MapPhase2+ version; the delivered
gmsc_Address is the GT code of SCP
# when the value is 9, SRI supports the MapPhase2+ version; the delivered
gmsc_Address is the MSC Address reported byIDP.
Chapter 2 Introduction to Signaling Faults

Locating Tools
It is said one must sharpen his tools before he can do a good job. In this chapter, we
will have a look at the good tools provided by the HW intelligent network can talk about
how they should be properly used.
2.1 OAM Signaling Tracing
In the OAM interface, user-friendly interfaces are provided so that we can do a tracing
job easily.

This function can perform printing the signaling information; the printed contents are
the parameters which have been explained.
This function can be used to trace single calls, so it has little influence on the
performance of the system.
Next let’s look at the methods to use them.
I. Use of interfaces
After logging on OAM as the administrator, you can select function [Info Query/Call
Tracing] to trace the call message; then there will pop up a dialog box as shown in
Figure 2-1. On OAM, there are two modes of message tracing: InitialDPTracing and
RSDPTracing, respectively used to trace the common call flow and the RSDP
signaling flow.

The calling/called party

flow selection
The calling number is input
The called number is input
MscAddress input
Execute operation feature code 1
Execute operation feature code 2
Execute operation methodid
The source SCP address which

sends execute
Name of the document about

the tracing information
Figure 2-1 Call tracing dialog box on OAM and its description
Detailed description of the figure above:

1) Select the calling/called flow
If Mobile calling is selected, it means it is necessary to trace the calling flow; if Mobile
called is selected, it means the called flow is traced. Either of the two is OK.
2) Number input area
Input the calling/called party numbers and MSCAddr, as well as the calling/called party
number needed to trace the signaling flow or the MSC address to be reported to IDP.
Tracing can be implemented by inputting any one of the three.
3) Input the feature code into execute operation

execute operation is different from attached elements such as callingpartynumber and

calledpartynumber in the InitialDP operation. Therefore, it is necessary to trace the
Feature Code to judge whether there are any tracing elements in an execute operation
which interest the subscriber; by judging a sub-string in the execute code stream of
this Feature Code (also a string), you can trace a dialogue triggered by one execute
operation. The value of the Feature Code normally is: for the execute operation
transmitted by the non-local recharging flow SCP to VC, the rechargeable card
number or the mobile number of the subscriber to be recharged. In the loss
report/cancel loss report flow, the mobile phone number used to report loss and cancel
loss report can be used as the feature Code.
4) methodid of the execute operation
The methodid carried by execute can be used to determine the service type to be
triggered, therefore it provides tracing of a specific methodid. The tracing range of
methodid is 1~99.
5) Transmit the source SCP address of execute
SCP interconnection may involve the interconnection of the equipment of multiple
manufacturers. Therefore, the tracing function of an execute operation from a certain
source SCP is provided. The source SCP address is the originatingAddress carried by
TC_BEGIN. At present, there are 3 types of SAU signaling point addresses; normally
we select type 2, namely, ‘only according to the GT addressing mode’, therefore when
tracing this source address, we input the GT code to trace it.
II. Instance of the initialdp tracing mode
Flow of the traced signaling:

In the dialog box as shown in Figure 2-1, select the called flow, in the entry box of the
number of the calling party input 8613902900001 and then click OK, you will obtain the
result as shown in Figure 2-2:

Figure 2-2 Result of the InitialDPTracing Mode
If you feel it inconvenient to view on OAM, you can save the traced message into a
document. Click button Save and input the document name of the traced message to
be saved such as ‘Tr’, then click OK. The traced message will be saved under
directory temp of the $HOME directory of the SCP subscriber. The content of the
document with the name of Tr.trace.Tr.trace is described as below:
SCP <=============
TCBegin:
destinationAddress=
"0x0a 52 92 00 12 04 68 31 09 10 12"
"0x07 04 00 00 01 00 32 01"
originatingAddress=
"0x0a 12 92 00 12 04 68 31 09 72 10"
dialogueID=7241
userInformation=
"0xff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"

SCP <=============
TCInvoke:
dialogueID=7241
operationType=0
invokeID=1
linkedID=-1
operationID=0
lastComponent=1
timeout=0
SCP <=============
CAPInitialDP:
serviceKey=3
calledPartyNumber="008613902900002"
callingPartyNumber="008613902900001"
callingPartysCategory=
"0x0a"
locationNumber="0086755"
originalCalledPartyID=NOT PRESENT
highLayerCompatibility=NOT PRESENT
bearerCapability=
bearerCap="80 90"
eventTypeBCSM=12
extensions=NOT PRESENT
additionalCallingPartyNumber=NOT PRESENT
redirectingPartyID=NOT PRESENT
redirectionInformation=NOT PRESENT
imsi="460090370000027"
subscriberState={
state=assumedIdle
}
locationInformation={
ageOfLocationInformation=1
geographicalInformation=NOT PRESENT
vlr_number="008613902701"
locationNumber=NOT PRESENT
cellIdOrLAI={

cOrl=0
cellId=460F0870550010
}
extensionContainer=NOT PRESENT
}
ext_BasicServiceCode={
teleOrBearer=teleServiceCode
teleServiceCode=17
}
callReferenceNumber=2a bb 00 00 73 00 01 a9
mscAddress="008613902701"
calledPartyBCDNumber=NOT PRESENT
TimeAndTimezone :
20020516194530
timezone : 35
gsm_ForwardingPending = not present
numberInfoSave.iNatureOfCallingNumber = 4
numberInfoSave.iAddressPresentIndicator = 0
numberInfoSave.callingPartyNumber = "8613902900001"
numberInfoSave.iScreening = 3
numberInfoSave.iNatureOfCalledNumber = 4
numberInfoSave.numberInfoType = 2
numberInfoSave.calledPartyNumber = "8613902900002"
.............................................................
.......................................
III. Instance of the RSDP tracing mode
Flow of the traced signaling:

Input conditions as shown in the interface:

Note: In the RSDP Tracing mode, only when the input conditions satisfy all the
necessary conditions, the item concerned can be traced.
The traced dialog box is as shown below:

Similarly we can save it into a document for later viewing. The saved document is
under directory temp of the $HOME directory of the SCP subscriber. The suffix ‘.trace’
of the document will be automatically added. The content of the save document is as
below:
SCP <=============
TCBegin:
destinationAddress=
"0x0a 12 92 00 11 04 68 31 87 00 f2"
"0x07 00 11 89 4c 02 03 03"
originatingAddress=
"0x0a 12 92 00 11 04 68 31 87 00 f6"
dialogueID=119
userInformation=
"0xff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00"
SCP <=============
**********************Execute Argument **************************

object=
[0]=
type=
global= 304
0x00 11 89 4c 02 04 03
value=
int4Element=3
[1]=
type=
global= 304
0x00 11 89 4c 02 04 0e
value=
stringElement="191000000000000006"
[2]=
type=
global= 32
0x00 11 89 4c 02 04 0d
value=
methodID=
0x00 11 89 4c 02 0a 0d
InputAttribute=
[0]=
type=
global= 0
0x00 11 89 4c 02 04 15
value=
SpecificInput=NOT PRESENT
..........................................................................
....
2.2 Tracing Binary Code Streams

1) Brief Introduction
For tracing of single calls on OAM, those signaling faults can easily recur through
obvious operations. In this way, we can easily acquire the fault flow. But in reality, we
may only know the fault exists but we cannot obtain the conditions to make the fault

recur according to very limited information, let alone to obtain the signaling flow of the
fault through dialing test of the specific flow. Therefore we need to introduce a tool to
print all the signaling code streams out.
SCP provides the function to print all the call code streams, including the transmitted
and received signalings. The binary system is adopted because the write/read of it
only occupies fewer system resources than the text as well s the document space.
This function has little influence on the system performance. It cooperates with the
external tracing document tools to trace all the call signalings and analyze them with
specific tools to obtain the signaling flow of the fault. With specific tools, the traced
signalings can be processed to re-appear all the calls according to the original flow.
Those calls in the code stream document are distinguished through different dialogue
numbers but these numbers are limited. After a certain period, they will be reused on a
rotary basis. The binary code stream is for long-term tracing, so the same dialogue
number can have multiple calls. But in terms of time, they are separated and arranged
in serial, so there will be no confusion.
2) Use of Tools
This command can be used to trace the binary document. It is necessary to use the
special decoding tool ‘getcase’ provided by the early-stage network maintenance team
for decoding.
Instance of the tracing of binary code streams:
% setscf bin
// the part in blue are the contents to be input or the notes; the rest are
the prompts exported by the setscf bin command
====== Print bin code ======

Please input printFlag:
printFlag=0, close print (default)
printFlag=1, print code of some call with ration
printFlag=2, print code of all calls
printFlag=1 // input the desired tracing mode or input 2, 1: print part of the
code streams; 2: print all the code streams
Please input ration:

ration is in [1, 10000]
ration=0, print code of every call (default)
ration=1, print code of one call after 1 call
ration=2, print code of one call after 2 calls

ration=10000, print code of one call after 10000 calls
ration=0 // print the code stream of each call or input the call code stream
which satisfy the required conditions and you want to trace.
Please input the begin time of printing:

The format is "YYYYMMDD HHMMSS", for example "20010517 160800".
The time must be between now and 24 hours later, default value is current time.
begin time= // directly press Enter and start tracing from the current time
of the system or you can input the start time for tracing according to the format
begin time out of range, set to current time.
Please input how many seconds to keep printing:

The seconds must be between 1 and 86400(24 hours), default value is 60.
keep seconds=10 // input how long the tracing will last, unit: s
Set printing bin code succeed!
After tracing is completed, a binary code stream document will be generated under the
log directory: scffeam?.bin; among it, ? corresponds to scf’s ID.
If long-term tracing is required, you should take some special handling, for each code
stream document should be no more than 5M. We need renumber and rename the
scffeam?.bin.old document regularly and transfer it to the directory with larger space
(usually the directory on the disk array, such as tellinshare instead of under the telling
directory).
It is easy to use the code stream explanation tool ‘getcase’, so we will not talk about it
in detail here. This function can open multiple code stream documents at the same
time. We should be good at “filtering conditions” to obtain the fault flow we would like
to find out. Among them, the ‘include’ column can enable us to find the flow with a
certain signaling, remove some signaling flows and have multiple choices; while
“number of” can enable us to find the flow with certain signalings occurring many times.
Besides, if coupled with the functions in the configured document, it can provide more
powerful functions.
It is worth mentioning that the binary code stream tool also supports printing of
messages of the RCOMM type; it also can help locate faults of the RCOMM-type
services.

2.3 Tracing Detailed Information of Single Calls
The tools described above only provide tracing of signaling flows but cannot export the
detailed handling flows inside SCP. But if al lhte handling flows inside SCP are printed
out, obviously it will greatly influence the system performance and print too much
useless information. The tracing of single calls can print the detailed handling flow of a
(or certain) call(s).
1) Instance of the use of single IDP call tracing function:
% setscf trace
// the part in blue are the contents to be input or the notes; the rest are
the prompts exported by the setscf trace command
please input traceFlag
traceFlag=0 don't trace
traceFlag=1 trace calls specified
traceFlag=2 trace all information
traceFlag=1 // input 1 to trace specific calls
please input traceType

traceType =0 IDP tracing
traceType =1 RSDP tracing
traceType=0 // input 0 to trace common IDP calls
please input serviceKey, serviceKey=0 no serviceKey

serviceKey = // directly press Enter or you can input the service key you want
to trace
please input callingAddress, callingAddress=0 no callingAddress.

callingAddress=13912005150 // input the number of the calling party you want
to trace
please input calledAddress, calledAddress=0 no calledAddress.

calledAddress= // directly press Enter or you can input the called party number
you want to trace
please input ration(0-10000), ratio=0 no ratio
ratio = // directly press Enter or you can input the condition-meeting call
you want to trace, for example, if you input 2, then the information of either
one of 2 condition-meeting calls will be printed to the document

please choose how to set the print types

choice = 0 keep current setting and set the print types later.
choice = 1 set all print types now.
choice = 1 // input 1; it is required to select 1
// the following is the successfully-set export

===== setscf trace success====
traceFlag = 1
printLevel = 1
printMode = 1 // it means it is exported to the document
serviceKey = 0 // it means there is no restriction on any service
key
callingAddress = 13912005150
calledAddress = // it means there is no restriction on the called party
number
ratio = 0 // it means as long as the condition for printing is
satisfied, debug will be printed
2) Single RSDP Signaling Tracing Function
Determine if it is necessary to trace this RSDP according to the imported tracing
parameters. The tracing parameters consist of Tracecde1/Tracecode2 (Feature Code),
Methodid (method ID) and sourceScpAddr (source SCP address).
z Feature Code (Tracecde1/Tracecode2)
According to the encoding rule, the sub-string in the Execute operation will be directly
encoded into the code stream in the ASCIIcode form. The Feature Code here refers to
the string existing in the code stream. During tracing, a sub-string in the Execute
parameter can be imported and then judge if tracing is necessary based on whether
there is a corresponding sub-string in ExecuteArg; we call this the feature signaling
code. For example, if it is necessary to trace a non-local recharge on VC triggered by
execute, the rechargeable card number can be used as the Feature Code to report
loss or cancel loss report or the mobile phone number used for reporting loss or cancel
loss report can be used as the Feature Code.
Here by importing the tracing of 2 sub-strings (Tracecode1/Tracecode2), we can

reinforce the tracing conditions. When the two Feature Codes are both imported, then
the execute operations of the two sub-strings existing in the code stream can satisfy
the tracing conditions.
z Method ID (methodID)
This ID is the methodid in execute. Since we usually use different methodids to make
the execute operation trigger different services, it is worthwhile to trace this parameter.

z Source SCP Address (sourceScpAddr)

The source SCP address is the originatingAddress of TC_BEGIN. Currently, there are
3 types of SAU signaling point addresses, of which we usually use the second type,
that is, ‘only GT’, so we tracing this source address, we can trace according to the GT
code.
3) Instance of Single RSDP Signaling Tracing Function:
% setscf trace
/ the part in blue are the contents to be input or the notes; the rest are the
prompts exported by the setscf trace command
please input traceFlag
traceFlag=0 don't trace
traceFlag=1 trace calls specified
traceFlag=2 trace all information
traceFlag=1 // input 1 to trace specific calls
please input traceType

traceType =0 IDP tracing
traceType =1 RSDP tracing
traceType=1 // input 1, it means setting tracing RSDP calls; 0 means tracing

IDP calls
please input scpAddress, scpAddress = 0 no scpAddress

ScpAddress=8613902701 // input the GT code of the source SCP address you want
to trace; if you don’t want to input this parameter, directly press Enter or
iput 0.
please input methodid , methodid = 0 no methodid

Methodid=13 // input the method ID you want to trace; otherwise directly press
Enter or iput 0
please input TraceCode1 , TraceCode1 = 0 no TraceCode1

TraceCode1=// directly press Enter or input the Feature Code you want to trace
please input TraceCode2 , TraceCode2 = 0 no TraceCode2

TraceCode2=13432743827 // input the Feature Code you want to trace; otherwise
directly press Enter or iput 0

please choose how to set the print types

choice = 0 keep current setting and set the print types later.
choice = 1 set all print types now.
choice = 1 // input 1 and you are supposed to select 1
// the following is the successfully-set export

===== setscf trace success====
traceFlag = 1
printLevel = 0
printMode = 1 // it means it is exported to the document
ScpAddress = 8613902701
MethodID = 13
tracecode1 =// it means there is no restriction on Feature Code 1
tracecode2 = 13432743827
Here we set the tracing conditions for RSDP calls. When the source SCP address of
the call is 8613902701, the method ID is 13 and the Feature Code is 13432743827,
call tracing can be implemented.
2.4 Tracing Database Operations
When we are about to locate problems, it is sometimes necessary to learn the

implementation state of the database (such as query and update), especially learn
whether the query is successful, whether the memory table or the database table is
queried and the implementation time of querying.
SCP can print complete execute statements and results in the debug document. But
sometimes we are more concerned about whether the execution is successful and the
time of execution and hope more calls are printed. SCP provides such the tool to
satisfy this demand.
Command:
Turn on the tracing switch: setscf sql;
Turn off the tracing switch: setscf 0 0;
Output: under the directory /tellin/log, the sqlx.log file will be generated; x corresponds
to the number of SCF.
Content interpretation:
The complete record of a database operation is:

sqlStatement: select Version,Version1,Version2,Version3,Version4,Version5,Versio
n6,Version7,Version8,MngNumber,CCSNumber,RbtPrefix from pps_version where

ScpNo=
===== SDF ===== after ecSelect span from memtbl(success)= (0 sec) (87 usec)
sql0.zip
Among them, sqlStatement describes the SQL statement of request. Note that
currently SCP uses the dynamic SQL, whose variable part is substituted by “?” in
sqlStatement, for example, “where ScpNo=?”, if the specific variable content is needed,
it can be printed out by using the debug document.
From “(0 sec) (87 usec)”, we can see the time to execute this SQL statement.
From “from memtbl” or from “DB”, we can tell whether the object of this database
operation is the memory table or the database.
From “success” or ”not found record” or ”error”, we can see whether the operation
result is success or not, whether the specified conditions correspond to a blank record
or whether the result is error.
Sometimes when trace the signaling, we may find the time interval between the
request and the response is a bit long by checking the time printed in the signaling,
which may lead to abnormal signaling. Then we can check if it takes too much time for
the database to execute. Through the execute time, we can directly see the time to
execute a certain SQL. But there is no unique criterion to judge if the execute time is
too long. From the past experience, the query time of the memory table is between
100~200 milliseconds; crossing 500 milliseconds may suggest some problems; but
occasional occurrence can be ignored. The query time of the database table is
normally between 1000~3000 milliseconds but it is related to the record number of
specific tables, for example, the record number of the basetab_pps table may reach
700,000/800,000 or above, maybe the query time is over 10,000 milliseconds but for
some small tables, the time may be less than 1000 milliseconds.
If you find it takes a long time to query a certain database table, how should you locate
the problem? Generally speaking, if a database table requires frequent query
operations, an index should be designed. But the index may get lost. SCP provides the
idxcheck.sh tool whose theory is to acquire the sequential scanning counts by reading
the system table of the database. This tool can calculate the difference of the
sequential searching counts before and after a period of time. When the difference is

larger than a certain value, the log will be written and alarm be sent. We can use this
tool manually to see whether the index exists or not.
Idxcheck.sh can be used to discover problems only when the query statement is
executed to this table; but dbaccess can be used manually to execute one SQL in
order to observe if the searching is conducted through the index.
Method: execute dbaccess-> Query-language->New, input:
set explain on;
select * from hlrtoareanumber where hlrnumber='1381234';
set explain off;
The select statement above should be consistent with the statement needed to be
analyzed in sqlx.log but the variable part should be added with the actual content.
Then exit dbaccess; a document will be generated under the current directory:
sqexplain.out. Its content is:
QUERY:
------
select * from hlrtoareanumber where hlrnumber='1381234'
Estimated Cost: 2
Estimated # of Rows Returned: 1
1) myj.hlrtoareanumber: INDEX PATH
(1) Index Keys: hlrnumber
Lower Index Filter: myj.hlrtoareanumber.hlrnumber = '1381234'
sqexplain.zip
Among them, index path means this is the search based on the index.
If we modify the SQL conditions above as:
select * from hlrtoareanumber where areanumber='755';
The output then will be: 1) myj.hlrtoareanumber: SEQUENTIAL SCAN
It means the searching then is based on sequence (since the index field of this table is
hlrnumber, the areanumber-based searching must be according to the sequence).

When it is confirmed this table uses the index for searching and it takes much time to
query and if the data volume of this table is not very large, we can try to conduct an
update statistics medium to this table to change the statistic information of the system
table in order to enhance the query efficiency (Note: if the record number of this table
is large, such as on a million basis, the execution may take more time, so the
operation should be conducted during idle time).
2.5 Unscrambling Debugging Information
Reading complete debugging information requires high professional knowledge and

the cooperation of service codes; on the other hand, routine maintenance and fault
analysis need no specific analysis and debugging information. Since we are not going
to describe how to read the debugging information in this section but focused on how
to acquire the required information by reading the debug documents during routine
maintenance and fault analysis.
We will carry out our discussion with the contents of the attachments below.
scfdebug0.zip hlr&msctoareanumber.zip
2.5.1 Acquiring Original Number Information
After receiving IDP, SCP may add a prefix to the number to be dialed (for example, ‘00’
is added in the attributes of the international number). If we want to know whether the
original umber reported by MSC/SSP contains the dialing prefix or we would like to
visually obtain the value of the number attributes, we can directly get it from the debug
document without analyzing the hexadecimal code stream.
numberInfoSave.iNatureOfCallingNumber = 3 # the attributes of the

number of the calling party
numberInfoSave.iAddressPresentIndicator = 0 # the display indicator of

the number of the calling party
numberInfoSave.callingPartyNumber = "5952116270" # the original number of

the calling party
numberInfoSave.iScreening = 3 # the screening indicator

of the number of the calling party

numberInfoSave.iNatureOfCalledNumber = 3 # the attributes of the

number of the called party
numberInfoSave.numberInfoType = 2 # the type of the number

of the called party, negligible
numberInfoSave.calledPartyNumber = "5952106001" # the original number of

the called party
The contents above will be printed immediately after IDP is received and decoded.
The part after the dotted line is the explanation. Please refer to the description of
parameter values in the appendix for details.
2.5.2 Acquiring Detailed Database Operation Information
During problem locating, we can always encounter data configuration errors in some
of the database tables, which lead to call failure or charging errors. Through the
debugging information, we can acquire the information such as the input data and
output results of the database operations (mainly query operations) which cannot be
obtained with other tools.
Enter FEA9091 -- ServiceDataManagement SIB
******** enter fea9091 -- SDM
……………………… # omit the irrelevant contents
msgID : id_retrieve
dbName: pps_version
object: ScpNo=?
……………………….
selected: ………………
sqlStatement:……………….
ecSelect:select
Version,Version1,Version2,Version3,Version4,Version5,Version6,Version7,Version8,M
ngNumber,CCSNumber,RbtPrefix from pps_version where ScpNo=? #
complete SQL statement
<<<sqlda_parameter>>>
sqld=1 # the number of the input variable parameters

sqltype:103,sqllen:4
sqldata:200 # the value of the input variable, namely, the

value of where =?
ecSelect open cursor success
rowNum=1, fieldNum=12 # after successful query of the record, the

returned result is 12 fields, in the same sequence as that of SQL
1000000001000000 101160 11100000 00011100

00000000 00000000 00000000 00000000
00000000 13800138000
sqlca.sqlcode = 0 in ecSelect.
===== SDF ===== after ecSelect span from DB(success) = (0 sec) (1530 usec)
# time spent on execution
2.5.3 Observing Number Analysis Results
Sometimes we meet numbers reported in an invalid format, which lead to number

analysis failure and call failure; or parameter hlrtoareanumber and msctoareanumber
lack new data or have extra data, which lead to charging errors. In such cases, we can
judge by reading the number analysis result:
CASE1: (in fact, the value of numberAnalysisType is different, so the number analysis
function completed is different).
Enter TSCSM::FEA9541() -- NumberAnalysis SIB
………………………………
numberAnalysisType is : 1 # number analysis type: 1 (the numbers

with the area code stripped, exported and removed)
SourceNumber is : 05952106001 # the input number to be analyzed
findTollAreaNum:aPartyNumber[5952106001]Output:retCountryNumber[595] #
the area code of the number is ’595’, which can be obtained by searching
tollareanumber
******* Enter TCommonTab::IsMSISDN() ********
Input msisdn is : 2106001 , length is : 7
input strAddress(MSISDN):[2106001]

GetAreaNumberFromHLR() wrong in IsMSISDN()! # describe this number is

not MSISDN, that is, it cannot be matched in hlrtoareanumber
******* Enter TCommonTab::IsMSRN() ********
Input msrn is : 2106001
GetAreaNumberFromMSC() wrong in IsMSRN()! # describe this number is

not MSRN or VLRNumber, that is, it cannot be matched in msctoareanumber
CASE 2:
Enter FEA9541
numberAnalysisType is : 3 # number analysis type: 3 (according to the

requirements, analyze the current location’s area code or the home location’s
area code of the number, that is, analyze the home location’s area code of
MSISDN and the accessed location’s area code of MSRN or VLRNumber)
SourceNumber is : 008613900698 # the input number to be analyzed
findTollAreaNum:aPartyNumber[13900698] # the number with the prefix and

the country code stripped
Input msrn is : 13900698 #describe this number is MSRN or

VLRNumber, that is, it can be matched with the response field in
msctoareanumber
…………………..
findTollAreaNum:strAreaNumber[591]Output:retCountryNumber[1013] # the
area code of the number is ‘591’ after analysis, that is to say, match number
13900698 the fullest possible in the HLRToAreaNumber table or
MSCToAreaNumber and obtain the corresponding area code; the charging area
code is ‘1013’ after analysis, that is to say, the charging area code is obtained by
matching the area code in TollAreaNumber.

CASE 3:
numberAnalysisType is : 2 # number analysis type: 2 (judge whether it is

a fixed number, a mobile number or an international number)
SourceNumber is: 05952106001
findTollAreaNum:aPartyNumber[5952106001]Output:retCountryNumber[595] # the
area code of this number is ‘595’ and describe it surely is not the international
number
******* Enter TCommonTab::IsMSISDN() ********
Input msisdn is : 2106001 , length is : 7
GetAreaNumberFromHLR() wrong in IsMSISDN()! # describe this number is not

MSISDN
Input msrn is : 2106001
GetAreaNumberFromMSC() wrong in IsMSRN()! # describe this number is not

MSRN or VLRNumber
When the domestic area code is figured out, surely it will not be the international
number (Note: the number with the country code is not an international number),
otherwise the analyzed result is: findCountryNum:aPartyNumber [the number to be
analyzed] and Output:retCountryNumber [the country code obtained through analysis];
When it is neither MSISDN nor MSRN, it may be the number impossible to be

analyzed or PSTNnumber. For the former, it will be printed as
“Unknown_Number……”; so the number type in this instance is PSTNnumber.

2.6 Introduction to Other Tools
2.6.1 Viewing SCP and Service Version Number –lsmscp Tool
The SCP version used currently by the system or the service version is the necessary
information required to locate the signaling faults.
I. Brief introduction
We can view each SCP process through the lsmscp tool (manager, scf, scfserver, sdf,
oam, nmf) and the version No. of the services uploaded on them.
% lsmscp
Usage: lsmscp -movsdah | [-]modulename | [-]servicename

-m: display information about machine
-o: display information about OS
-v: display all MSCP's modules version information
-s: display all services version information
-d: display MSCP description information
-a: display all information above except MSCP description information
-h: display command help information
[-]modulename: display appointed module version
[-]servicename: display appointed service version
Examples:
lsmscp manager (display module manager version)
lsmscp -manager (display module manager version)
lsmscp pps.bin (display service pps.bin version)
lsmscp -pps.bin (display service pps.bin version)
Description:
It is necessary to input the service version No. to generate the service. Otherwise you
cannot obtain the version number of relevant services by using this tool.
II. The function of viewing SCP version number
When operating lsmscp, you can query the version No. of each module from each
executable binary document;

z You can view the version No. of the process specified by SCP: lsmscp process
name or lsmscp – process name;
z You can view the version No. of all the SCP processes: lsmscp -v.
Instance:
¾ View the version No. of the SCF process:
% lsmscp scf Or lsmscp -scf

scf module version :
scf: WINV200R002D702
¾ View the version No. of all the SCP processes:
% lsmscp -v
MSCP software version :
Module Name Version
=========== =======
manager WINV200R002D602
scf WINV200R002D602
scfserver WINV200R002D602
sdf WINV200R002D602
oam WINV200R002D602
nmf WINV200R002D602
III. Viewing the service version number on SCP
z View the version No. of the specified service: lsmscp service or lsmscp – service;
it is used to view the version No. of the specified service under directory
servicerun.
z View the version information of all the loaded services on SCP: lsmscp –s
Instance:
¾ View the version No. of service iuser.bin:
% lsmscp iuser.bin Or lsmscp -iuser.bin

Service rsdp.bin version:
iuser.bin: IUSERV2.3D111
¾ View the version information of all the loaded services on SCP
% lsmscp –s
Service version :
Service Name Version
============ =======

iuser.bin IUSERV2.3D111
iuser_attendant.bin IUSERV2.3D111
iuser_bank.bin IUSER_BANKV2.3D111
iuser_called.bin IUSER_CALLEDV2.3D111
iuser_calling.bin IUSER_CALLINGV2.3D111
iuser_callscreen.bin IUSER_SCREENV2.3D111
iuser_chgpwd.bin IUSER_CHGPWDV2.3D111
iuser_claimmis.bin IUSER_MMISV2.3D111
iuser_ctd.bin IUSER_CTDV2.3D111
iuser_fnfc.bin IUSER_FNFCV2.3D111
Note:
1. When you view the service version No., relevant service document should exist
under directory $TELLIN_DIR/servicerun;
2. When lsmscp is used to view the version No., since document scf process is a bit
large, the time spent on it will be long (especially in the HP environment).
Chapter 3 Typical Service Signaling Flows
To reinforce understanding of the previous knowledge, this chapter offers some typical
service signaling flows. For more signaling flows, please refer to the corresponding
service signaling specifications.
3.1 Typical Signaling Flow of the Prepaid Service
3.1.1 Prepaid Subscribers Call Prepaid Subscribers
The Calling Prepaid Subscriber is in the Coverage Scope of MSCa/VLR/SSP and

the Service is Triggered by O-CSI
1) MSCa/VLR/SSP receives the call and triggers the service according to the
subscription information O-CSI of the calling party. It transmits the IDP message
to the calling subscriber’s SCPa and puts the toll area code of the location where
MSCa/VLR/SSP is situated in parameter Location Number in the IDP message.

2) SCPa determines the charge rate of the calling subscriber according to the
location of the calling party and the called party number, converts it to call
duration and then sends RRBE, AC, FCI and Continue to MSCa/VLR/SSP.
3) After MSCa/VLR/SSP receives the Continue message, it sends the SRI message
to HLR of the called party. If the called party is a prepaid subscriber, the
subscriber information O_CSI + T_CSI and the location information of the called
party (Vlr-number) will be returned.
4) MSCa/VLR/SSP sends the IDP message to SCPb and puts the toll area code of
the location where MSCa/VLR/SSP is situated into the location number in the IDP
message and puts the called-party location information (Vlr-number) into Location
Information in the IDP message.
5) After SCPb receives the IDP message, it will first analyze the called subscriber’s
account. If the account is still valid, SCPb will determine the charge rate
according to the called-party location information obtained from IDP, convert it to
call duration and send RRBE, AC, FCI and connect to MSCa/VLR/SSP.
1) MSCa/VLR/SSP re-sends the SRI message to the HLRb of the called party. Then
the SRI message will suppress T-CSI and obtain the roaming number MSRN of
the called party.
2) MSCa/VLR/SSP conducts connection according to the roaming number MSRN of
the called party.
3) The call stops and either of the calling or the called party hangs up.
MSCa/VLR/SSP submits the charging report and the onhook event respectively
to SCPa and SCPb.

Figure 3-1
Parameter description:
The calling subscriber:
Initial DP Information element name
Service Key Value=1
International number(for example:

Calling Party Number
86139XXXXXXXX)

Calling Partys Category 10 (common subscribers)
Event Type BCSM CollectedInfo(2)
IMSI
For MO calls, this parameter must be

locationInfo
selected and it should have CellID.
MSC Address (G) MSC/SSP’s address
Number dialed by the subscriber;

please see Point 5 in “3.4 Other
Called Party BCD Number
Special Requirements and
Description for details
Toll area code with the international

Location Number
code, for example, Beijing: 8610
Note: please see CAP Specification

(09.78) for the filling mode. If this
parameter exists, it means this ssp
has the basic srf function (including
IP SSP Capability collecting DTMF, play the record
notification and tone). If this
parameter’s value is ‘00’H, it means
ssp does not support IP route
addressing (CTR’s parameter).
Currently SCP does not judge this

parameter. after the service has
specific requirements, it will be
Bearer Capability
judged according to the
requirements of the service
department
The called subscriber:
Service Key Value=1
Called Party Number The called number dialed by the


subscriber; please see Point 5 in “3.4
Other Special Requirements and
Description for details
The calling subscriber international

number
Calling Partys Category 10 (common subscribers)
Event Type BCSM DP12
IMSI IMSI of the called subscriber
Toll area code with the international

Location Number
code, such as Beijing: 8610
According to VlrNumber acquired

Location Information from SRI-ack, fill in parameter
VlrNumber in Location Information
Vlr-number
MSC Address MSC/SSP’s address

parameter. after the service has
Bearer Capability specific requirements, it will be judged
according to the requirements of the
service department
3.1.2 Prepaid Subscribers Query the Balance
1) The prepaid subscriber dials the phone number13800138000 to be recharged.

According to the O-CSI information, SSP sends the IDP message to the SCPa
the prepaid subscriber A belongs to.
2) SCPa sends RRBE and CTR messages to MSCa/VLR/SSP.
3) Subscriber A selects the language and flow according to the prompt.
4) SCPa queries and obtains the account balance in the subscriber’s database and
plays the alert tone.
5) SCPa continues the follow-up service flow.

Figure 3-2
Parameter:
Parameter value or
Operation name Information unit name
description
InitialDP serviceKey 1
callingPartyNumber International number
10(common
callingPartyCategory
subscribers)
Note: please see CAP

Specification (09.78) for
the filling mode. If this
parameter exists, it
IPSSPCapabilities means this ssp has the
basic srf function
(including collecting
DTMF, play the record
notification and tone). If

Parameter:
Parameter value or
description
this parameter’s value is
‘00’H, it means ssp does
not support IP route
addressing (CTR’s
parameter).
eventTypeBCSM collectedInfo
IMSI
For MO calls, this

parameter must be
locationInfo
selected and it should
have CellID.
mscAddress (G) MSC/SSP address
Number dialed by the

subscriber, please see
Point 5 in “3.4 Other
calledPartyBCDNumber
Special Requirements
and Description for
details
The toll area code with

locationNumber the international
number, such as: 8610
Currently SCP does not

judge this parameter.
after the service has
Bearer Capability specific requirements, it
will be judged according
to the requirements of
the service department
RequestReportBCSMEvent BCSMEvents
eventType 10
monitorMode notifyAndContinue

Parameter:
Parameter value or
description
legID 1
ConnectToResource resourceAddress NULL
Note: (1) the first digit

interval is 10 seconds;
the inter-digit interval is
7 seconds.
(2) the minimum digit

length is 1. The
maximum digit length
can be defined in 4
types of cases: when
you select the flow, the
PromptAndCollectUserInformation collectedInfo maximum digit length is
1; when you input the
card number, the
maximum digit length is
19; when you input the
password, the maximum
digit length is 9; when
the mobile phone
number is input, the
maximum digit length is
12.
informationToSend
disconnectFromIPForbidden TRUE
Input according to
different prompts
PromptAndCollectUserInformation Note: the end symbol “#”
digitResponse
ack is converted into “OCH”
and then reported to
SCP.
PlayAnnouncement informationToSend

Parameter:
Parameter value or
description
inbandInfo
For the last PA

operation, this
disconnectFromIPForbidden
parameter is “FALSE”,
the rest is TRUE
requestedAnnouncementComplete TRUE
SpecialzedResouceReport NULL
EventReportBCSM eventTypeBCSM 10
legID 1
miscCallInfo
messageType 1
3.1.3 Prepaid Subscriber A Uses a Common GSM Mobile Phone (or PSTN
Telephone) to Report Loss, User A’s Homed SCPa Accesses a Different SCP
from the Proximate SCPd Accessed by MSCa/VLR/SSP.
z The prepaid subscriber A uses the common GSM mobile (or PSTN telephone) to
dial 13800138000. SSP triggers the intelligent call to the default SCPd.
z The subscriber selects the language, report loss/cancel loss report according to
the prompt, input the mobile phone number you will report loss on and the
password.
z SCPd judges the AC (SCPn) the subscriber belongs to according to the mobile
phone number you will report loss on and sends Execute operation (mobile phone
number, password and loss report flag) to AC (SCPn) to report loss on this stored
value card.
z After AC(SCPn) receives the Execute operation, it will report loss on this the
stored value card. If successfully done, it will send Execute-Result (operation
success flag) to SCPd.
z After SCPd receives the Execute-Result message, it will send TC-End to end the
dialogue with AC(SCPn) and prompt operation succeeds.
Please see Figure 3-3 for the signaling flow.

Figure 3-3
Parameter:
Operation
Information unit name Parameter value or description
name
InitialDP serviceKey 2
GSM subscriber: International number
PSTN subscriber: 861063601234 (International

callingPartyNumber
number)
1063601234 (Domestic number)

Parameter:
Operation
name
callingPartyCategory 10(common subscribers)
Note: please see CAP Specification (09.78) for the

filling mode.If this parameter exists, it means this
ssp has the basic srf function (including collecting
IPSSPCapabilities
DTMF, play the record notification and tone). If this
parameter’s value is ‘00’H, it means ssp does not
support IP route addressing (CTR’s parameter).
IMSI
For MO calls, this parameter must be selected and

locationInfo
it should have CellID.
mscAddress (G)MSC/SSP address
Number dialed by the subscriber; please refer to

calledPartyBCDNumber Point 5 in “3.4 Other Special Requirements and
Description” for details
The toll area code with the international number,

locationNumber
such as: 8610
Currently SCP does not judge this parameter. after

the service has specific requirements, it will be
Bearer Capability
judged according to the requirements of the service
department
Execute (the
Object
first time)
RDNSequence
Value 2

Parameter:
Operation
name
Value Mobile phone number
InputAssertions
Type id_oi_pinnumber (note)
Value 8-digit subscriber password
SpecificInput
Value 0
Execute
Result (the MethodID id_mt_ppsclaimMissing (note)
first time)
SpecificOutput
int4element 1
Note: The value of the body ID type is defined in Appendix 1
3.2 Typical Signaling Flow of the IP17951 Service
3.2.1 Description of Basic Networking and Theory
When the 17951IP telephone service is implemented, the networking mode is as

shown in the figure below:

SMP SCP
MML interface Trigger the call to SCP

Document quasi-
realtime interface
BOSS GMSC/SSP
IP gateway or
the toll office
Connect the call to the gateway

office of China Mobile
The subscriber
dials the
access code +
the called The home network
Subscribers of number to
other networks access the of the subscriber
network
Figure 3-4 Networking diagram of the 17951 IP telephone service
3.2.2 Theory of National Interconnection
When the subscriber roams to regions beyond the control of the home SCP, the SCP
of the roaming location needs to be interconnected with the home SCP in order to
query the valid information of the subscriber’s account and conduct operations such
as charging and so on.
Besides, the subscriber recharges for non-local SCP subscribers and when he
recharges for himself after he finishes roaming or when he conducts voice
management, these need to be implemented through SCP interconnection.
The national networking interconnection diagram is as shown below:

Figure 3-5 SCP Interconnection networking diagram of the 17951 IP telephone

service
After subscriber A from province A roams to province B, when he conducts normal

calls and manage/operate his account, it is necessary for the SCP of the roaming
location to be interconnected with the SCP of the home location to query and modify
information.
Subscriber A can recharge for a subscriber from province C at the home location or at
the roaming location. It is necessary for the SCP of the calling party’s home location to
be interconnected with the SCP of the home location of the subscriber from province C
so that he can recharge the home VC of the subscriber from province C.
3.2.3 Call the Non-Local PSTN Mobile Phone Subscribers of Other Networks;
the Service-Triggering SCP is not the Home SCP of the Subscriber
Call process:
1) GMSCa/SSP receives the call and triggers the service according to the access
code;
2) The toll area code of the location where MSCa/VLR/SSP is situated, the access
code + the number of the called subscriber are directly put in Location Number in
the IDP message, which will then be sent to SCPa;
3) After SCPa receives the IDP message, it will judge the subscriber account is at
SCPb and send to SCPb the Execute operation. SCPb judges the validity of the
service, account and the called party number before it returns the payment type
and the deposit.
4) SCPa sends RRBE and AC to GMSCa/SSP according to the current charge rate.

5) SCPa sends the called party number to GMSCa/SSP through the Continue
operation.
6) After GMSCa/SSP receives the Continue message, it will be connected with the
GMSC and go out of the network at the home location of the called party
according to the called party number.
7) The call is connected.
8) After the call is over, either of the calling/called party hangs up and GMSCa/SSP
submits the charging report and the loss-report event.
9) SCPa sends to SCPb the charging application operation based on the practical
call expenses used during this charging cycle. If it is for a prepaid subscriber,
SCPb will complete the actual charging operation. For group subscribers, the
monthly and daily total expenses of the group and individuals will be accumulated.
SCPa generates the bill of this call.

Parameter:
Service Key 4
Calling Party Number Domestic number
Calling Partys Category 10(common subscribers)
Event Type BCSM CollectedInfo(2)
Note: when GMSC forwards the call to the

IMSI
toll SSP trigger service, IMSI is Null when


ISUP signaling is not supported between
GMSC and SSP
MSC Address (G) MSC/SSP’s address
Access code + the number of the called

Called Party BCD Number
subscriber
Toll area code with the international code,

Location Number
for example, Beijing – 8610
IP SSP Capability
Note: when GMSC forwards the call to the

toll SSP trigger service, IMSI is Null when
Bearer Capability
ISUP signaling is not supported between
GMSC and SSP
Execute (the
object
first time)
rDNSequence
attributeTypeAndValue
type id_oi_serviceKey (note)
value 4
type id_oi_locationNumber (note)
Subscriber location information: Toll area

value code with the international code(such as
Beijing: 8610)
type id_oi_calledPartyNumber (note)
Access code+the number of the called

value
subscriber
methodID id_mt_checkIn (note)
inputAssertions

type id_oi_msisdn (note)
Subscriber’s account: for mobile

subscribers, it is the mobile phone number;
value for fixed subscribers, it is the area code +
the fixed phone number (such as:
7558787308)
Execute
Result (the methodID id_mt_checkIn (note)
first time)
outputAssertions
type id_oi_payingType (note)
Charging mode: 1-Prepayment;2-Post

value
charging mode;3-Group charging
type id_oi_accountLeft (note)
Chargeable sum, which is valid only when

value
the charging mode is 1; unit: fen
type id_oi_lockFlag (note)
Whether the subscriber uses the locking

functionis locked
value
1-not locked
2-locked
type id_oi_pinNumber (note)
value Subscriber’s password
type id_oi_payAccount (note)
Common account of subscribers (Charging

mode=2)
value
Or the group account of subscribers
(Charging mode=3)
type id_oi_payAccoutType (note)

Type of the common account, valid only

when the charging mode is 2.
01: Gotone mobiles
02: Account of the ICBC
03: Account of the ABC
04: Account of the BOC
value 05: Account of the CBC
06: Account of the CBC
07: Account of the CMB
08: Account of the CMB
09: Account of the CEB
10: Account of the ECITIC
11: Account of the Commercial Bank
specificOutput
Call permitted
Operation fails.(It refers to the rest

erroneous cases).
Subscriber’s account does not exist
int4element The account is invalid
The local number or dialing is forbidden
Reaching the monthly limit of the group
Reaching the daily limit of the group
Reaching the monthly limit of an individual

subscriber
Reaching the daily limit of an individual


subscriber
Note: when the returned value is the wrong

value (when it is not 1), parameters in
outputAssertions are invalid
Request
Report BCSM Information element name
Event
BCSM Event
Event Type DP (4.5.6.9)
Monitor Mode Interrupted
Leg ID 1 (the calling party), 2 (the called party)
Event Type DP(10)
Monitor Mode Notify and Continue
Leg ID 1 (the calling party)
Apply
Information element name
Charging
ACh Billing Charging

Characteristics
Time Duration Charging
Please see Description (1) for the

Max Call Period Duration
configuration of this parameter
It is defaulted when there is no time for

Tariff Switch Interval
switchover
Release If Duration Please see Description (1) for the

Exceeded configuration of this parameter
Play Tone
Party To Charge 1 (the calling party)

Description (1): Configuration of parameter ”Max Call Period Duration” and “Release if
Duration Exceeded (play tone)”
On principle, the ‘Max Call Period Duration” is 15 minutes but if the last fragment of the
call duration is no more than 1 minute, it is necessary to modify the value of the last
but two call duration from 15 minutes to a value bigger than 15 but smaller than 16
minutes and set it as the last fragment of the call duration so that the subscriber can
still hear the tone.
The configuration principle for “Release if Duration Exceeded (play tone)” is: in the last
fragment of call duration, this parameter is “TRUE’; in other call processes each lasting
for 15 minutes, this parameter does not appear.
Continue Information element name
NULL
Event Report
BCSM
Event type BCSM DP9
1 (the calling party), 2 (the called

Leg ID
party)
Misc Call Info request
Apply Charing
Report
Call Result
Time Duration Charing Result
Time Information Call duration
Party To Charge 1 (the calling party)
The last time is Flase; the rest are

TRUE. But when the call is released
Call Active
due to timeout, this parameter is
“FALSE’.

Execute (the
Object
second time)
RDNSequence
Value 4
Type id_oi_calledPartyNumber (note)
Access code+the number of the

Value
called subscriber
Type id_oi_locationNumber (note)
Subscriber location information: Toll

Value area code with the international
code(such as Beijing: 8610)
Type id_oi_ifEndService (note)
1.
Call ending flag: 1-end the call;

Value
2-the call is not over.
(In this service both are 1)
Type id_oi_time (note)
The accumulated duration of this

Value
call, unit: s
Type id_oi_expense (note)
Value The accumulated charge of this call,

Execute (the
Object
second time)
unit: fen
MethodID id_mt_checkOut (note)
InputAssertions
Subscriber’s account: for mobile

subscribers, it is the mobile phone
Value number; for fixed subscribers, it is
the area code + the fixed phone
number (such as: 7558787308)
Execute Result (the

MethodID id_mt_checkOut (note)
second time)
SpecificOutput
1
int4element (1 -Operation succeeds
2-Operation fails)
3.3 Typical Signaling Flow of the Mobile Phone

Rechargeable Card Service
3.3.1 When the Normal Recharging Flow SCPa and SCPb of the GoTone
Subscriber are not the Same SCP, the Operation Succeeds
Figure 3-6 Normal Recharging Flow of the GoTone Subscriber (SCPa and SCPb are
not the same SCP, the result returned by Boss is success)
Parameter:

Operation
name
InitialDP ServiceKey 2
callingPartyNumber International number
callingPartyCategory 10 (common subscribers)
Note: please see CAP Specification (09.78)

for the filling mode.If this parameter exists, it
means this ssp has the basic srf function
(including collecting DTMF, play the record
IPSSPCapabilities
notification and tone). If this parameter’s
value is '00'H, it means ssp does not
support IP route addressing (CTR’s
parameter).
IMSI
For MO calls, this parameter must be

LocationInfo
selected and it should have CellID.
MscAddress (G) MSC/SSP address
calledPartyBCDNumber Number dialed by the subscriber
The toll area code with the international

locationNumber
number, such as: 8610

parameter. after the service has specific
Bearer Capability
requirements, it will be judged according to
the requirements of the service department
RequestRepor
BCSMEvents
tBCSMEvent
EventType 10
monitorMode notifyAndContinue
LegID 1
ConnectToRes
resourceAddress NULL
ource

Parameter:
Operation
name
Note: (1) the first digit interval is 10

seconds; the inter-digit interval is 7
seconds.
(2) the minimum digit length is 1. The

PromptAndCol maximum digit length can be defined in 4
lectUserInform CollectedInfo types of cases: when you select the flow,
ation the maximum digit length is 1; when you
input the card number, the maximum digit
length is 19; when you input the password,
the maximum digit length is 9; when the
mobile phone number is input, the
maximum digit length is 12.
informationToSend
disconnectFromIPForbidden TRUE
PromptAndCol Input according to different prompts

lectUserInform digitResponse Note: the end symbol “#” is converted into
ation ack “OCH” and reported to SCP.
PlayAnnounce
informationToSend
ment
InbandInfo
For the last PA operation, this parameter is

disconnectFromIPForbidden
“FALSE”, the rest is TRUE
requestedAnnouncementComplete TRUE
SpecialzedRes
NULL
ouceReport
Execute (the
object
first time)
rDNSequence

Parameter:
Operation
name
Value 201
Type id_oi_accountNum (note)
The 18-digit password of the rechargeable

Value
card
Type id_oi_originalmsisdn (note)
The telephone number which originates the

value
recharging
Type id_oi_servicetype (note)
Service type
The national service is 00XXXX
The provincial service is YYZZZZ; YY is the

Value provincial code
The value of XXXX,ZZZZ is 0000~9999
The value of YY is 01~31
Currently it is “0”
Type id_oi_tradetype (note)
Recharging mode
Value Its value is the same as the recharging
mode in the recharge bill

Parameter:
Operation
name
Type id_oi_LocationNumber (note)
The calling subscriber’s roaming location

Value Format: country code + area code, such as :
8610
MethodID id_mt_ChargeOtherLong (note)
InputAssertions
Value The recharged telephone number
Execute Result
methodID id_mt_ChargeOtherLong (note)
(the first time)
outputAssertions
value Recharge amount
type id_oi_activeDays
value Validity term of the rechargeable card
specificOutput
1(
0 means the rechargeable card does not

exist;
int4element 1 means the operation succeeds;
2 means the rechargeable card is

invalidated;
3 means the operation fails.
Execute (the
second time) object
Parameter:
Operation
name
rDNSequence
type Id_oi_serviceKey (note)
value 303
type id_oi_accountNum (note)
value 18 is the password of the rechargeable card
Type id_oi_originalmsisdn (note)
Number of the calling party
Value The mobile phone number is

13XXXXXXXXX; the fixed phone number is
075526540168
Type id_oi_servicetype (note)
Service type
The national service is 00XXXX
The provincial service is YYZZZZ; YY is the

Value provincial code
The value of XXXX,ZZZZ is 0000~9999
The value of YY is 01~31
Type id_oi_tradetype (note)
Value Recharging mode
Parameter:
Operation
name
Its value is the same as the recharging

mode in the recharge bill
id_mt_SupplyRetrieve (note)
MethodID
inputAssertions
type id_oi_msisdn (note)
value The recharged telephone number
Execute Result
(the second methodID id_mt_SupplyRetrieve (note)
time)
outputAssertions
The face value of the rechargeable card

value
(counted by RMB)
type id_oi_activeDays (note)
Validity term of the rechargeable card

value
(counted by day)
Type id_oi_batch (note)
Value Lot number of the rechargeable card
Type id_oi_cardtype (note)
Type of the rechargeable card
The national card is 00AAAA
The provincial card is BBCCCC; BB is the

Value
provincial code
The value of AAAA,CCCC is 0000~9999
The value of BB is 01~31
Parameter:
Operation
name
Type id_oi_amount (note)
Value Serial No. of the rechargeable card
specificOutput
0 means the rechargeable card does not

exist;
1 means the operation succeeds;

int4element
2 means the rechargeable card is
invalidated;
3 means the operation fails.
Execute (the
object
third time)
rDNSequence
type id_oi_serviceKey (note)
value 303
methodID id_mt_ppsSupplyModify (note)
Execute Result
(the third time) methodID id_mt_ppsSupplyModify (note)
SpecificOutput
int4element 0
EventReportB
eventTypeBCSM 10
CSM
legID 1
Parameter:
Operation
name
miscCallInfo
messageType 1
A_DEPOSIT transaction_id Transaction ID No.
user_number The subscriber’s mobile phone number
request_timestamp Time of the operation request
account_type Account type, 0103
amount Amount of the rechargeable card (unit: ‰)
Tag 0001
status_description Length 4
A_DEPOSIT_ (The command_status at the head Operatio Operation result
RESP of the message should filled up nResult
with "0000"; it refers to success) Value "0000"
(4
Bytes) (it refers to success)
Description:
If the password input by the subscriber (including the password of the rechargeable
card, the mobile phone number and subscriber’s password) does not end with #, the
call should continue. If the number of digits input by the subscriber is more than the
digits required by the service, it will be regarded as wrong, so relevant record
notification will be played according to the service flow.
Description:
1) The timezone part in parameter TimeAndTimeZone of the IDP operation should
be based on the unit of 15 minutes.
2) Please refer to the table below for the voices corresponding to the error types
returned by Execute (the first time):
Cause of error Chinese message ID English message ID
0 0140000E 0180000E
2 0140000F 0180000F
3 0140002F 0180002F
3.4 Typical Signaling Flow of the VPMN Service
3.4.1 VPMN Service’s Requirements for Signaling
The CONNECT operation is delivered in the called flow to require the manufacturers to
solve the problem of displaying the number of the calling party according to the IN bill
handling plan, that is, “the called end office fills the number of the calling party in IAI or
IAM into the corresponding place in the called party bill and removes its special prefix;
then provides CID directly to the called party.’
After the inter-office signaling is upgraded to ISUP, SSP handles the 80H GENERIC
NUMBER of the QUALIFY delivered by SCP in the same way, that is to say, it replaces
the number of the calling party in IAM instead of inserting into field GENERIC
NUMBER in IAM. Other types of GENERIC NUMBERs will be handled according to
the standard.
When field QUALIFY in GENERIC NUMBER is 80H, the number is: special prefix (60)
+ the real number of the calling party (or the VPMN short number of the calling party);
the attribute of the address is: unknown (02H); other fields should be filled in according
to relevant specifications. When SSP receives this operation, it will replace the number
of the calling party with the content in GENERIC NUMBER, including the attribute of
the address.
You can refer to relevant contents in the Prepaid Signaling Flow and the Compatibility
Test Specification for the requirements on how to fill in specific parameters of each
operation in the signaling flow.
When the area/time-based service function has not been commissioned, when SCP is
required to send the ATI operation to HLR, HLR may not send PSI to MSC in order to
acquire the then location information of the subscriber; when the area/time-based
service is commissioned, when SCP is required to send the ATI operation to HLR,
HLR must send PSI to MSC in order to acquire the then location information of the
subscriber and send it back to SCP.
To ensure the internationally-roaming VPMN subscriber does not trigger the intelligent
flow, when HLR inserts the subscriber data to the VLR of the roaming location, HLR
will judge this subscriber is on international roaming and will not insert the subscriber
O/T-CSI into VLR.
The speeches and speech codes listed in this signaling flow only serve as the
descriptive instances. Speeches actually used in the service should comply with the
requirements of the service specification.
The value of reason in RC delivered by SCP should be filled in with 31. If RC is

delivered according to a certain event after ERB is received, the reason should be
consistent with the reason reported in ERB. If there is no reason in ERB, then it should
be consistent with the event reported by ERB.
In the called flow, when MSC/SSP sends to the called party HLR the SRI operation,
HLR must return O-CSI and T-CSI at the same time.
There are specific regulations on the number formats in each flow (including the calling
party number, the called party BCD number, the called party number, the generic
number and the destination routing address). Please look at the table below for details:
Number Description Remarks
Long number: 8613903000002 (International

number)
Or long number: 13903000002 (Domestic number)
Or long number: 008613903000002 (unknown

number)
Or 013903000001 (unknown number)

calledPartyNumber
1063601234 (Domestic number) (only existing in the
MF flow)
01063601234 (unknown number/Domestic number)

(only existing in the MF flow)
861063601234 (International number) (only existing in

the MF flow)
8613903000001 (International number)
Or 13903000001 (Domestic number)
861063601234(International number)
1063601234(Domestic number)
01063601234(unknown number/Domestic number):

According to the regulations of the Ministry of
Number Description Remarks

Information Industry, the toll prefix “0” can be added in
front of the number of the calling party transmitted by
other operators.
6013903000001 (unknown number)
6001063601234 (unknown number)601002 (unknown

number)
The called number dialed by the subscriber;
Short number: 1002 (unknown number)
Or long number: 13903000002 (unknown number)

number)
CalledPartyBCD
Number Or long number: 8613903000002 (International
number)
Or long number: 010636012334(unknown number)
Or long number: 0085212345678(unknown number)
Or long number: 85212345678(International number

format)
It can be a domestic, an international or an unknown

number as long as the property and content of the
number are consistent
Currently only when the number is changed, Connect

will be sent:
VPMN subscriber calls the operator; this number In the calling

Destination Party should be: 0101860 (unknown number) or flow
number 01063601234 (unknown number). Formats such as
1860 and 63601234 are forbidden.
When the number is not modified, the DRA in Connect

delivered by the called flow should comply with the
In the called
same destination number of the called party number
flow
reported by IDP (including the number and its
attributes).
3.4.2 When the Calling Party is a VPMN Subscriber, SCP Should Charge
Call process:
1. MSCa/VLR/SSP receives the call and triggers the service according to the
subscriber information O-CSI of the calling party;
2. Put the toll area code of the location where MSCa/VLR/SSP is situated in Location
Number in the IDP message and send to SCPa the IDP message;
3. After SCPa receives the IDP message, it will analyze the calling subscriber
account first. When the account is valid and SCP is required to charge the calling
party who is on the toll call, SCPa sends to HLRb the AnyTimeInterrogation
operation to query the location and state of the called subscriber;
4. After SCPa receives the ATI response returned by HLRb, SCPa will send RRBE
and AC to MSCa/VLR/SSP.
5. SCPa sends to MSCa/VLR/SSP the FCI message and notifies SSP to add
relevant content into the bill of this call.
6. VPMN SCPa sends the called party number to SSP through the Continue or
Connect operation.
7. After MSCa/VLR/SSP receives the Continue or Connect message, it will send the
SRI message to HLRb of the called party and obtain the MSRN of the called party.
8. MSCa/VLR/SSP conducts connection.
9. The call ends and either of the calling or the called party hangs up.
MSCa/VLR/SSP submits the charging report and the onhook event.
10. SCPa generates the bill of this call and release the call.
Parameter:
Operation name Information unit name Parameter value or description
InitialDP ServiceKey 3
8613903000001 (International number)Or

13903000001 (Domestic number)
CallingPartyNumber 861063601234(International number)
1063601234(Domestic number)
01063601234(unknown number/Domestic
Parameter:

number)
CallingPartyCategory 10(common subscribers)
IPSSPCapabilities Fill it up according to the practical situation
Country code + toll area code, such as:

LocationNumber
8610
BearerCapability
EventTypeBCSM DP2
IMSI
Vlr-number the location accessed by

LocationInformation the subscriber
Vlr-number
cellIdOrLAI CellIdOrLAI information about the cell
accessed by the subscriber
CallReferenceNumber
MscAddress (G) MSC/SSP address
The called number dialed by the

subscriber;
Short number: 1002 (unknown number)

number)
Or long number: 008613903000002

(unknown number)
CalledPartyBCDNumber
Or long number: 8613903000002
(International number)
Or long number: 010636012334(unknown

number)
Or long number: 0085212345678(unknown

number)
Or long number: 85212345678(in the
Parameter:

international number format)
(if PSTN is dialed and it contains no area

code, in such cases, the record notification
“Please add the area code” should be
played. Note: Several provinces have
special handing. The service defaults it as
the access location call of the calling party;
the area code of the access location of the
calling party is added before the called
party number)
TimeAndTimezone
AnyTimeInterrogation RequestedInfo
SubscriberLocation
SubscriberState
SubscriberIdentity
MSISDN
3.4.3 Calls inside the Network are Forwarded Unconditionally into the
Network
SSP
generates
the CFW bill
SSP
generates
the MTC bill
Chapter 4 Analysis and Handling of Signaling

Faults
Through the study of the previous chapters, we have already had a proper command
of the basic signaling knowledge. Next we will focus on how to put the knowledge into
routine maintenance. For the analysis and handling of signaling faults, correct
methods and relevant experience are very important. Different people will adopt
different methods for the same problem, for their experience will affect the way they
think and different methods will determine the troubleshooting efficiency. Therefore,
we should accumulate our experience and keep on thinking continuously through
routine maintenance so as to adopt the correct method to solve problems soonest
possible. In addition, we can also improve ourselves by exchanging experience and
discussing with others and learning others’ thinking modes.
4.1 General Guideline
If we face a fault, how should we approach it?

1) Stay calm. Through it sounds like a cliché, we should fully understand the
problem (can you clearly talk about the problem to others? Is it about full call
blocking or partial failure? Is it about the failure of some features or continuous
failure?) before checking and tracing it. You are supposed to figure out the
analysis and confirmation scheme (it is better to put them on the paper).
2) Have a good understanding of the network status quo on the spot (Can you draw
it out easily? What is the type of the equipment?).
3) Learn about the SCP service version. What services are loaded? The number of
subscribers to each service? What is the routine call volume of each service?
4) Have the nearest NEs been changed? This is critically important, for signaling
faults seldom take place for no reasons. Most probably they are caused by
changes of the NEs, such as the upgrading of the equipment or the service and
modification of some configuration data.
5) Are these faults caused due to the introduction of new features? For some
NEs may not support the new features or some data lack the configuration or
have the wrong configuration of these features. This type of faults also accounts
for a high percentage.
6) Check if the system has relevant alarms and log records. We should check the
log document and observe whether the errors or alarms of the log records are
related to the occurrence of faults.
7) After collecting the evidences of “the crime scene”, we will go on to “anatomize”
the fault. Imaginative inference coupled with careful verification is a basic
principle. As proven by the practical experience, some faults usually provide very
little information to us, so we should make use of our experience and knowledge
to list various possible causes and analyze and solve them one by one. Those
with “wild imagination” are very welcome now, for we need to consider all the
possible situations.
8) Next it is about “careful verification”. We should try to explain all our inferences
according to various logs, statistics and phenomena on the spot without leaving
out any trace. According to our experience, a fault can be triggered by many
causes. Settling just one problem may not solve the fault. We need more site
evidences to verify our analysis. If possible, we should try to remake the problem.
9) Then we should track on the “suspect”. If we can settle down on several
“suspects”, we can adopt the single call tracing (OAM tracing or setscf tracing as
described in previous chapters). If we only find very few traces, we should use the
binary code stream coding.
10) If there are many faults, we can check if there are any exceptions by analyzing
the statistic items in Profile (if there are just several cases, they cannot be
manifested in the statistics). Is the number of some abnormal signalings (such as
tc_u_abort, tc_u_error, tc_notice, reject and tc_l_delete (internal messages of
SCP) received or transmitted different from other time? Is the ratio between the
number of received IDPs and the number of transmitted tc_continue1 abnormal?
Are the ratios between the number of received IDPs and the number of received
ACRs, between the number of transmitted AC and the received ACR and
between CAPS and the number of the memory robots exceptional? Have the
number of transmitted ATs and the repeated dialogue numbers obviously
increased? Such information is very helpful for locating the problems. If possible,
make them into curve diagrams with Excel and observe the tendency of their
changes. profile0.txt
4.2 Typical Case Study
4.2.1 A M-zone Subscriber Has a Long-duration Call but does not Enjoy the
Charge Rate Discount
Basic symptom: An M-zone subscriber lodges a complaint that his call duration
lasted till after 23: 00 but he did not enjoy the discount of 0.1yuan/minute as the basic
call charge after 23:00.
Further observation: According to the bill, calls with normal charge are put through
after 22: 45 while calls with abnormal charge are put through before 22: 45. Then we
may consider whether it is related to the charge rate switchover on AC and ACR.
To obtain more information, we can conduct binary code stream tracing and compare
the bill analysis. Then we find the second AC of the normal call contains the charge
rate switchover time and MSC/SSP’s ACR has two types of charge rate call durations;
but the second AC of the abnormal call does not contain the charge rate switchover
time, thus MSC/SSP’s ACR only contains the call duration of the non-charge rate
switchover.
For further confirmation, we get the bill of the call from the SCP concerned lasting from
22:30 to 22:40 on August 20 and the bill of call starting between 22:50-23:00 and
lasting till after 23:00 and analyze the two. The charge rate configuration is that after
22:00, the 17951IP phone call (fixed telephone) is charged 0.23 yuan/minute; after
23:00 it is 0.13 yuan/minute (calculated based on the bills). For the first bill, if the call
duration is more than 1800 seconds, 3 ACs will be delivered with the third one located
after 23:00 but the charge rate is calculated unifiedly according to 0.23 yuan/minute.
For the second case, if the call lasts more than 900 seconds, the first AC will be before
23:00 while the second AC after 23:00. The result of bill analysis is that before 23:00,
the charge rate is based on 0.23 yuan/minute while after 23:00 it is based on 0.13
yuan/minute. For that reason, it is true that if the duration lasts till the second AC, the
calling party will enjoy the discount but after the third AC, there will be no discount.
Then we can basically confirm where the problem is located. We only need re-appear
the problem according to the above-mentioned condition in order to clarify the cause:
since MSC and SCP understand charge rate switchover in a different way, charging
errors appear.
4.2.2 Calls originated near the Charge Rate Switching Point do not have Any
Charge Rate Discount
Symptom: According to the setting of the charge, after 23:00 users of the IP
telephone can be exempted from the IP toll charge but some bills still recorded the till
charge after 23:00 for some calls starting around 23:00.
Further observation: By analyzing the bills, we find this type of bills are all distributed
near 23:00, showing it is related to the call put-through time. Besides, for defective
calls, no matter the call duration is long or short, there is no charge rate switchover;
meanwhile, most calls connected around 23:00 are normal with only several
exceptions. Then we may think it is related to the cooperation of the end office.
Analysis: There are two possibilities: one is that when SCP delivers AC, it does not
deliver the charge rate switchover duration correctly or it handles ACR in a wrong way;
the other is that the ACR submitted by MSC shows the charge rate is not switched or it
only records the call duration before the switchover.
Confirmation: Through single call tracing or binary code stream tracing, we further
discover that SCP has delivered the charge rate switching point. So the problem now
lies in different understanding of charge rate switchover between MSC/SSP and SCP.
4.2.3 PPS Dials the Non-local Unicom Mobile Phone but No Toll Charge is
Billed
Symptom: PPS subscribers dial the non-local Unicom mobile but the toll charge is not
shown in the bill.
Further observation: Conduct dialing test manually for call tracing and we find when
a PPS dials the Unicom mobile as the calling party, perhaps MSC triggers it to SCP or
maybe MSC sends it to GMSC and then it is triggered by GMSC. Anyway the format of
the called party number in IDP submitted by the end office is: the local area code +
130YYYYYYYY. A local area code is added here and this may be the cause of the
problem.
Analysis: For example, a subscriber in Guangzhou dials the called subscriber and
020130YYYY is reported. Though 130YYYY belongs to the number section of Beijing
but during number analysis, 020 is regarded as the area code of the called party. So
SCP thinks it is a local call and does not bill the toll charge.
Take 0XXX13YYYYYZZZZ for example, in the number analysis SIB of SCP, the
analyzing process is roughly like this: first the international toll access code “00” in the
localconfig table is used to match the prefix of the number but not successfully; then
the domestic toll access code “0” is used to match the prefix and in a successful way;
and then query the toll area code table tollareano of the country concerned and “XXX”
is match; still, if the number type is unknown, we should search for “13YYYYY” (or
“13YYYYYZ”) respectively in the hlrtoareanumber table and the msctoareanumber
table. In the HLR number section, we find this number’s type is
MSISDN_With_Areanumber and in the MSC number section, we find its type is
MSRN_With_Areanumber instead of the type of PSTN_With_Areanumber; but
whatever the type of the number, the area code of the home location returned should
all be “XXX”.
So we can see if “13YYYYY” is in the HLR number section of Beijing while “XXX” is the
toll area code of Guangzhou, then the home location of this number will be Guangzhou
although “13YYYYYZZZZ” actually is a mobile phone number in Beijing. Therefore the
called party number reported by the end office is in this abnormal format.
Confirmation: The problem has been clarified that the charging error is due to the
wrong number format reported. The solution is that when the number type returned
first time is non-PSTNnumber, re-invoke the number analysis SIB; then the imported
number is “13YYYYYZZZZ”. The platform can find the HLR or MSC number section of
this number and return it as the area code of the home or access location.
4.2.4 Secondary Trigger Leads to Charging of the Free Number
[Problem symptom]
A PPS subscriber issued a complaint saying he was billed on a toll charge basis for
dialing 13800138000. The bill is shown as follows:
0|1|0|1|0|13621979923|138001380001||8613900168||8613900168|||46000197120992
3|20010804000909|20010804000933|24|88|0|1||||021||8893|60|0|28|
[Analysis process]
1. Then this area was being upgraded from the overlay network to the target network;
SCP’s platform and services have all been upgraded to the new version. The earliest
time such a bill appeared should be after the first MSC was upgraded; therefore it is
natural that we think this should be related to the change of the target network.
2. In the overlay mode, when the subscriber dialed 13800138000, the service key
reported by SSP was 2 and SCP triggered Service key2’s management flow service;
in the target network mode, the called party number reported by MSC was whatever
the subscriber dialed; besides, the service key reported by the IN subscriber who also
triggers the subscriber information comes from the registration on HLR. PPS is 1, no
matter it is the calling/ called party or the management flow.
3. Observe the bill and you can see the called number dialed by the subscriber is
138001380001 and the triggered service key is 1. According to the description of the
technical support engineer in the office, the triggered end office is called G14, the
MSC of manufacturer E.
4. By analyzing the service flow, we can find out the cause. The service version used
then was compatible with triggering in the target network and the overlay network
mode, Service key1 contains the calling/called party and the management flow. When
the called party number is “13800138000”, its management flow tributary is selected.
But this is a bit too rigid. If the subscriber dials “13800138000X”, the calling flow will be
adopted and AC and CONTINUE will be delivered.
5. The first problem is solved but why the subscriber can still hear the announcement
of the management flow and why there is ACR to be reported. This is the key reason
why SCP can charge. An engineer in the Wireless Service Department had a fax with
the Mobile Corp., saying, “According to the requirement of the corporation, when
subscribers dial 13800138000, MSC/GMSC/SSP and GMSC/SSP send the ANC
message to the previous switch.” This fax gives us a clue while discussing another
problem: does the triggered MSC G14 have the same problem and is it routed to
another end office, which returns the ANC message to G14. So G14 finally submits
ACR to SCP. Through investigation and verification by the engineer in the office, after
ERICSSON MSC receives the CONTINUE message, it fails in getting the roaming
number of 1380013800X; so according to the overlay network mode, it adds the prefix
40 before the called party number and sends it to the independent SSP for triggering.
But in this mode, ERICSSON MSC restricts the maximum length of the called party
number is 13-digit, so the format of the called party number sent to the independent
SSP is 4013800138000 so that SSP re-triggers the normal management flow service
to SCP according to 13800138000. This is the process of the secondary trigger, which
caused SCP to charge the calling flow of the first IDP.
6. Since the process of the problem has been found, the reason why the calling party
is billed with the toll charge may be this SCP contains the HLR data of 13800138000X,
otherwise the service version of this site will have no area code or find the called party
number of the HLR data as the local PSTN exchange. It is confirmed by the engineer
of the office that SCP contains the HLR data of 1380013, which refers to a non-local
area code. So all the problems are made clear.
[Cause]
After the overlay network is upgraded to the target network, that the service on SCP is
modified inconsiderately is one reason and MSC’s handling of the two trigger modes is
the second reason.
[Solution]
1. Temporary handling measures require that MSC restrict the called number dialed by
the subscriber.
2. SCP adds a characteristic in the next version: when it handles IDP, as long as part
of it is matched with the called party number of “13800138000”, change the Service
key as 2. The service will recover the management flow into Service key2 without
comparing the called party number. This is implemented in the decoding of TC-Invoke
and the IDP in it by the SACF layer of the scf process to ensure the matching of the
original number. The service key conversion function in SCP originates here. After
many times of modification, it is quite perfect now and can support multi-mode
matching and conversion of multiple numbers.
4.2.5 Analysis of the Put-through Rate Signaling Statistics
[Problem symptom]
One China Mobile branch fed back the put-through rate problem of the PPS service.
The specific situation is: during the service put-thru rate test in that region, it is
discovered the number of IDP messages submitted to SCP is greatly different from the
number of RRBE messages delivered by SCP. Since the large-scale upgrading has
just been completed, the local mobile company suspects the problem lies in SCP’s
handling which affects the service put-through rate. In addition, the local company
mentioned the SCP put-through rate viewed through the NMS is very low and the
put-thru rate of the calling/called party of the PPS service is obviously lower than that
of the common GSM subscribers.
[Analysis process]
1. First we should clarify the so-called put-thru rate statistic data on the NMS actually
refer to the result of ACR/IDP. Whether it can be used as the index of the “call put-thru
rate” is still to be decided.
2. Secondly, regarding the fact that the put-thru rate of the intelligent service is lower
than that of the common GSM subscribers, the mobile signaling statistic data is the
statistic result obtained by the calling end office. In fact this contains the following
possibilities:
1) The end office MSC fails in triggering the intelligent service (such as it fails in
obtaining the subscriber information) and thus IDP is not reported at all;
2) Due to the signaling problem from MSC to SCP (probably due to STP
configuration, SAU configuration or the signaling network), SCP does not receive
the IDP message;
3) SCP platform handling problem (such as call dump due to overload) causes the
IDP message not to be handled at all;
4) The service flow is normally released (such as the account balance is not enough
or passes the validity term; the corresponding area code of HLR or MSC cannot
be found);
5) After SCP delivers CONNECT or CONTINUE, due to the signaling network, MSC
has not received the signaling;
6) After the end office receives CONNECT or CONTINUE, due to the signaling
network, connection fails.
For calls of the common GSM subscribers, only step 1 (to obtain the roaming number)
and step 6 may appear errors. But theoretically, since the cal handling flow of the
intelligent service usually have one more path than that of the common GSM, the
probability for exceptions and for low put-thru rate is larger. If the local China Mobile
thinks the gap of put-thru rate is too large and wishes for a thorough investigation of
the cause of the problem, it can adopt the method of manual dialing test + signaling
tracing on each equipment section.
3. For problems that the number of IDP messages received by SCP and the number of
RRBE messages delivered are different, specific analysis is necessary. The setscf
bin function then used on SCP turns on the code stream printing switch and collects
large amount of signaling data and then transmits it back to the local office for
decoding and analysis. The cause description below contains part of the report
provided to the China Mobile.
[Cause]
1. Conduct signaling statistics according to the collected code streams, (the ratio of
(IDP-RRBE) / IDP) is about 5% and it fluctuates with the time. It is lowest during call
busy time at day time, about 4.5% and reaches the highest during call idle time at night,
about 7.3%.
2. There exist the situations that after some calls on SCP are submitted to IDP, RC is
directly delivered and released, including:
1) Since the subscriber status is poweroff (mspurge), the service flow delivers RC
release call; the cause value is 20;
2) Due to the error of the subscriber number, the service flow delivers RC release
call; the cause value is 31.
The specific data is: totally 3969 reported IDP calls are traced on the spot and 289
not-delivered RRBE messages at the ratio of about 7.3%. Among them, since the
subscriber state is poweroff and the number of delivered RC is 255, accounting for
88.24%; since the number of delivered RC is 34 due to the wrong number dialed by
the subscriber, they account for about 11.76%.
3. When SCP delivers RC release call, if the cause value is 20, the end office will play
announcement to the subscriber; if the cause value is 31, there will be no
announcement. Except causes such as “No announcement after the subscriber dials
and the call is directly released” as described in the information provided by the China
Mobile and “the subscriber dials the wrong number”, there may exist problems such as
the network is busy and some end offices have problems in playing announcement.
4. In the original overlay network mode, for example, the called party mobile phone is
powered off, the independent SSP will not trigger the called flow, that is to say, SSP
will not report the called party IDP message to SCP. In the target network mode, no
matter the called party mobile phone is powered off or not, MSC/SSP will trigger the
called flow and report IDP to SCP, then SCP will directly deliver RC. Compared with
before, the chance that RRBE will be returned is less.
5. The signaling data collected on the spot is completely the same as the signaling
statistic result on SCP. This can explain the cause of the above-mentioned statistic
difference. At night the ratio of this difference against the total call volume will increase,
for the number of powered off subscribers grows at night. The ratio of this difference
against the total call volume is related to the ratio of the valid subscribers against all
the subscribers and the powered-off subscribers against all the subscribers. By
comparing with data in other locations, we can judge if the data at this site are in the
normal range.
6. The local China Mobile also mentioned that after MSC reported to IDP, it did not
receive SCP’s response. Through analysis, we get to know that since the dialogue
number is repeated on SCP, so tc_u_abort is delivered. We will talk about this case
when dealing with the problem of the robot down.
4.2.6 AIP Announcement Problem
[Problem symptom]
The end office under SCP adopts AIP to play announcement, MSC can normally play
announcement but GMSC cannot play announcement through AIP. Through call
tracing, we find that when MSC is triggered, SCP delivers ETC; but when GMSC is
triggered, SCP delivers CTR. Since GMSC has no speech, it is certain that
announcement cannot be played correctly.
[Analysis process]
The analyzing process of this problem has very universal significance:
1. First of all, according to the problem phenomena provided by the engineer and the
data collected, combining the theory and design of how SCP realizes AIP
announcement, we can analyze which part causes the problem. For this problem, the
initially submitted information is the AIP data configured by SCP, which may not be
valid; so the result is that SCP should have delivered ETC but it actually delivered CTR.
According to the troubleshooting process for common problems, when such symptoms
appear as failure to play announcement, abnormal recharging, calls that cannot be put
through and so on, if there are no clues, you should first of all check if the equipment
and network related to the information stream operate normally. But here we will not
talk about it. Since we already know the signaling delivered by SCP is abnormal, we
can directly lock the range on SCP and its handling part between receiving IDP and
delivering ETC/CTR.
2. Secondly, since the customer service engineer has submitted the site configuration
data, we can conduct the inspection. We not only need to check the data used by the
problematic single calls but also pay attention to relevant configuration as well as
some marginal conditions. The data to be checked include the SYSCFG.DAT
document and the msglocation and sspipinfo table. These are the basic configuration
of the AIP announcement part. SCP delivers CTR only when it cannot find the target
SSP starting SSP and related to the service speech ID so it regards the startup of SSP
as the integrated IP (IntegrateIP). The index of the start SSP addressing with
abnormal announcement is 2469. Next check if relevant data are valid and if the
announcement to be played is within the configuration range. Besides, the number of
records read into the memory by this document and two tables is limited.
SYSCFG.DAT can read 1000, msglocation 2000 at most and sspipinfo 1000 at most.
Check whether index 2469’s data are within this limit. At last, make sure to confirm if
the checked data are from the document and the database tables themselves or from
the memory. Note that except for SMAP foreground uploading, the data are read into
its respective memory when each scf process is started. In addition, SYSCFG.DAT can
use the dreadcfg command to dynamically refresh itself in the memory and inversely
download it self to the document for checking. Such cases have happened before. The
data on SCP had been manually modified through the background but the dreadcfg
command was not correctly used; they thought restarting the sdf process may be valid,
but actually the data had not been refreshed in the memory.
3. Here common inspection cannot locate the cause. It is necessary to conduct dialing
test and analyze the practical signaling. Normally the data initially submitted cannot
fully satisfy the requirement, therefore it is necessary to contact the site engineer for
on-site test, turn on the tracing switch and collect the signaling data of the call. The call
tracing means which could be used previously were very limited, most of them are
about call tracing on OAM, but the decoded signaling looks visualized but too simple.
The current tracing modes are quite diversified. Except for signaling tracing on OAM,
there are the code stream collections before decoding/after decoding at the FEAM
layer of scfand printing of signal call program debugs. All kinds of switches are be
used jointly. Here we use the trace/collect signals on OAM to obtain the success and
failure test instances of announcement playing and part of debug information about
the previous other calls. The most important is that we get a new clue: the end office
MSC can play announcement normally while the gateway office GMSC (of our
company) cannot play announcement. We discover some traces in the previous debug
fragments: it seems that when the program enters the FEA9121 function in UI SIB
which will play announcement, the index used to start SSP already goes invalid (it is
-1), that’s why the target SSP cannot be found. Besides since only GMSC has faults,
we need to consider if the signaling reported by GMSC/SSP is wrong. By analyzing
the IDP, TC-Invoke and TC-BEGIN in the collected signaling before SCP delivers CTR,
we find the failure instance seems to be related to the originatingAddress parameter
used to start SSP: the GT code reported by GMSC/SSP ends with a Byte of “FF” and
the length of the GT code is 1 more than the value of the one which succeeds in
playing announcement. The problem now focuses on this point that whether this cause
leads to failure of scf to obtain the correct index in order to start SSP.
4. After the focus clarified, the last important job is to verify the analysis conclusion in
the program code or overturn this conclusion and find a new focus. When scf handles
an IDP, before the robot is created, it will obtain the index used to start SSP from the
TC-BEGIN parameter originatingAddress in the saved message. Then compare the
GT code in originatingAddress and the GT code configured in SYSCFG.DAT. Since the
length of the GT code reported by GMSC/SSP is 1 larger, for it includes the Byte “FF”,
therefore it fails in matching with the configuration data in the memory and obtains the
invalid start-SSP index (-1). The conclusion is established.
[Cause]
The implementation of SCP’s support to AIP announcement is described as below:
1. TC-BEGIN reported by MSC/SSP contains a parameter originatingAddress. When

scf handles IDP, it gets SSP’s address from this parameter and then matches the
index of this address in the SYSCFG.DAT document in the private memory. The
matching format is: For example, originatingAddress is “0x0a 92 05 00 12 04 68 31 09
50 39”. Then “0x0a” means addressLength is 10 hexadecimal Bytes (excluding 0a
itself). Next the address ID “92” is “10010010”, in the ascending order, the 7 byte is not
1; so the DPC+SSN encoding mode is excluded; the first byte is not 1, so the GT+DPC
mode is also excluded; the second Byte is 1, then it is confirmed that it is the GT+SSN
encoding mode. The next Byte “05” is SSN. Though it is in the GT+SSN encoding
mode, actually SSN is useless. The following “00 12 04 68 31 09 50 39” is the GT code,
its encoding format is (each line is 8 binary digits):
Translation type
Numbering plan Encoding scheme
Idle Nature of address indicator
The 2nd address information The 1st address information
The 4th address information The 3rd address information
When there are X (an odd The nth address information

number) address messages:
fill code
When there are X (an even
number) address messages:
the last address information
The translation type is not considered currently and it is set as 00000000; the
numbering plan is ISDN/telephone numbering plan (0001); the encoding scheme is
BCD: when there is an odd number of address information, it is 0001 while in the even
number case, it is 0010; the idle bit is set as 0; the address property indicator is
International number (0000100). Combining all the information, we can get the first
half of the GT code “00 12 04”. This SSP’s address information 8613900593 shows
the last half of the GT code “68 31 09 50 39”.
In SYSCFG.DAT, the corresponding configuration data is :

“1:SSP:2468:024DFF0E9208001204683109503900000002:755:7000”. SSP/IP’s
address index is “2468” and the signaling point address is of 36 bytes
“024DFF0E9208001204683109503900000000”. The number is also expressed in the
hexadecimal system. The first byte “02” is the addressID, meaning GT+SSN;
“4DFF0E” is DPC and useless now; “92” is SSN, useless; “08” means the length of the
GT code is 8-byte, so after the GT code it is “0012046831095039”; the last “00000002”
is the filling bytes. Compare the address reported by TC-BEGIN and the preset
address and we only get the GT code, so the address index used to start SSP is 2468.
2. Then it involves two system tables whose records are read into the private memory
by the scf process when it is started:
create table msglocation
locationid serial,
resourcetype integer not null, //resource type, currently it is 0
messagebegin char(8) not null, //start speech ID
messageend char(8) not null, //end speech ID (the announcement ID is

within the range between the two)
srcsspipindex integer not null, //start-SSP address index
destsspipindex1 integer not null, //target SSP address index 1
destsspipindex2 integer not null, ///target SSP address index 2 (required by the
independent IP for backup)
destsspipindex3 integer not null, ///target SSP address index 3 ((required by the
independent IP for backup)
primary key(locationid)
);
create table sspipinfo
sspipindex integer not null, //SSP address index
sspipaddress char(20) not null, //SSP address GT code
sspipstate integer not null, //SSP state
primary key(sspipindex)
);
scf uses the start-SSP address index to designate the announcement ID together with
the service (suppose it is “018001C6”). Look for it in the msglocation table (suppose
there is the record “620|0|018001C2|018001C9|2468|3008|-1|-1|”), then the target
SSP’s address index is “3008” and it is an independent IP (IndividualIP) or the
assistant SSP IP (AssistSSPIP). Then it obtains the target SSP’s GT address in
sspipinfo and uses ETC to deliver it to the start SSP. If the target SSP cannot be found
in the msglocation table, it means the announcement resource is in the start SSP,
which is the integrated IP (IntegrateIP); scf delivers CTR.
3. Then the start SSP sends the “create/IAM” request to IndividualIP or AssistSSPIP.
4. IndividualIP or AssistSSPIP uses the new TC-BEGIN transaction primitive to send

ARI to SCP. TC-BEGIN’s parameter applicationContextName can show it is
IndividualIP (“0x07 04 00 00 01 00 34 01”) or AssistSSPIP (“0x07 04 00 00 01 00 33
01”). If it is IndividualIP, then enter the subscriber interaction phase. Scf sends
Cancel/PA/PC operation to IP; IP sends to SCP SRR/PCack operation; after
subscriber interaction is completed, scf sends DFC operation to the start SSP or IP
can start disassembly. If it is AssistSSPIP, it will be more complicated. Scf sends CTR
to the assistant SSP, which will send “Create” operation to IP; then it enters the
subscriber interaction phase; scf continues to send PA/PC operation to the assistant
SSP while will forward it to IP; then IP sends SRR/PCR operation to the assistant SSP
which will forward it to SCP; after subscriber interaction is completed, SCP sends DFC
to the start SSP, which will send “Disassemble” to the assistant SSP and the assistant
SSP will send “Disassemble” to IP.
[Solution]
On GMSC, configure the SSP physical address table and change the GTLength field
into 8 (originally it is 9). Then reset the table and you can delete the 1-byte filing code
“FF” from the originatingAddress parameter.
[Summary]
The above steps show how to analyze problems. The key conditions for analysis lie in:
1. First understand the theory of the flow involved in this service and where the
problem is located;
2. Next grasp certain means to collect and check the state and data of relevant
equipment and understand the meanings of these states and data;
3. Finally find out the correct objects which can provide detailed analysis, such as
tracing specific calls and conducting specific tests. During the analyzing process, if the
problem cannot be located with the positive focalizing method, we should filter the
problem with the inverse excluding method. All in all, reduce the range gradually and
locate the problem finally. This requires certain degree of understanding of the design
of the relevant parts.
It is relatively smooth in locating this problem. But for some other problems, it will take
more time and efforts, especially in step 3 and 4 in the above analyzing process. If the
first analysis conclusion is proved wrong in the code, it is necessary to look for the
doubtful point again till it is found.
4.2.7 The E Manufacturer End Office Permanently Downs the Robot of SCP
[Problem symptom]
This SCP bears services such as VPMN under the target network. First two extremely
low put-thru rates occur, which suggest grave call restriction appears. In fact large
amount of robots are downed so that the new calls cannot be set up. First we doubt it
might be the defect of SCP and provide version upgrading. After that, the speed at
which robots are downed slows down. But by days of accumulation, there are still
many robots getting downed.
[Analysis process]
This is the severest case for downed robots. As the situation is quite complicated, so is
the handling process.
1. The office fed back that every Tuesday there would occur call restriction and calls
were difficult to be put through. So they adopted the measures to restart the scf
process and switch the dual system. In fact that was caused by large amounts of
permanently-downed robots and new calls could not be set up in scf. Meanwhile since
most calls could not be put through, subscribers kept retrying and thus a call “surge”
formed; the initial CAPS reaching the manager passed the static overload threshold
and this caused the false symptom of overload. But why it occurred on every Tuesday
was because each scf downed more than 500 robots on a daily basis; after the scf
process was restarted, 4000 robots happened to get downed after a week and thus
caused the coincidence in time.
Since SCP has an old BUG, namely, after it receives IDP, it should deliver CONTINUE
immediately, the service logic returns to BCP as SLPContinue and meanwhile SCP
delivers TC-END too, so there will be no follow-up messages. But then this robot is not
release and downed later. There were few such cases in services and the influence
was small. However VPMN service has two such signaling flows: dialing the
emergency free number; when the non-ultranet number group PSTN dials VPMN, the
called party will be forwarded unconditionally. So many such phenomena take place.
After modifying this BUG, provide the latest version for site upgrading.
2. After upgrading, the speed at which SCP2 robots down drops, but such phenomena
still keep growing. Meanwhile, the newly cutover SCP3 which is just accessed to the
network meets the same problem. According to the profile statistic information then,
the problem is analyzed as below:
1) The robots of the host also get downed and now the number reaches about 2500.
At mid-night, there are about 1100 (they should be the downed robots); even the
message queues pass 4000;
2) The standby host has no such robot-downing phenomena. There are about 1200,
basically in compliance with: CAPS × average call duration (nearly 60 seconds);
the message queues are only about 600;
3) Since SCP has had the anti-robot downing mechanism, if the TC-BEGIN newly
reported by SAU is a repeated dialogue number, the new and the old dialogues
will be both deleted. Therefore if a robot’s dialogue number gets downed only on
SCP, then after the polling time SAU allocates the dialogue numbers (just several
minutes; it is related to CAPS), this robot should be released. Then the number of
downed robots should remain at a stable level instead of keeping growing like this.
Therefore it is very likely this dialogue number on SAU has not been released; the
state machines on SCP and SAU are downed at the same time and almost
permanently so;
4) Besides VPMN, this SCP has the FPH service (exclusive one) under the target
network. Are the different results of robots on the active/standby machines
caused by some special signaling flow or because messages of this type of

signaling are handled in different ways on the active/standby machines?
3. Next we further our analysis by adopting multiple measures:
1) Get back the site configuration and service and ask the Testing Department to
cooperate with the lab to conduct various simulation tests in the hope to discover
the abnormal signaling flow that has never appeared before;
2) Consult the personnel from SAU sector and ask them to provide clues and
inspection means to check the usage status of dialogue numbers on SAU or if
there are similar alarms. The reply should be that for the 128-mode SAU, the
number of the state machines can be queried through the pseudo-messages but
the B-type machine at this site does not have this characteristic;
3) Print the code stream on SCP and decode it with tools so that we can look for the
abnormal signaling in details.
4. Further analyze the statistic data and then in profile and the program, we find some
key clues:
1) First there are few statistic data about the repeated dialogue numbers. This is not
consistent with the downing situation within a certain period. But this can serve as
the evidence that dialogues on SAU are also downed;
2) Next the number of ATs delivered is large and passes the normal range;
especially within a certain call duration, the number of delivered ATs basically
matches the number of the downed robots: the number of downed robots × (call
duration/AT timer 6 minutes)≈ the number of delivered ATs within the duration.
This means SCP keeps conducting the activate test on these downed robots. If
MSC/SSP returns the Abort message or has no response, SCP will release the
calls. Therefore MSC/SSP must have returned the AT-Result message. This may
be caused by the handling of AT by MSC/SSP. Calls have been released but the
AT result is always success; maybe it resembles the previous cases that some of
the signalings reported by MSC/SSP are not complete so that the robots on SCP
cannot be released. The difference is that the dialogues on SAU and MSC cannot
be completed;
3) In scf’s message queues, the number of messages is very large and the allocated
memory keeps growing. This discovery is caused by the BUG of a program. In
some flows of the service, such as the lock is applied for during forwarding, the
related lock used by the scfserver process to manage the robots relies on the
platform to be released when the robots are deleted. Since the robots in scf get
downed, scfserver sends to the scf process a message every 20 minutes
querying if the robot corresponding to the lock exists or not. The memory space of
such messages is not released, so the number of messages keeps increasing.
This BUG in turn indicates the service flow of how robots are downed. Among it,
the related lock of the robot is used. Currently only the VPMN forward flow
satisfies this condition.
5. After the object is clarified, it is much easier to trace the code stream on SCP.
Previously it was quite difficult to look for abnormal signaling messages purposelessly
in the large amounts of code streams and we find a lot of sub-standard signaling flows
but all cannot explain why robots get downed. Again new requirements are proposed
for acquiring the code streams. First printing the duration should contain several ATs;
next conduct a dialing test to the VPMN forward MT flow and continue tracing it after
hang-up; besides, print respectively on the active/standby machines in order to locate
their inconsistency. In the code streams collected this time, we finally find the
breakthrough evidence:
MSC/VLR/SSP SCP
IDP
RRBE
AC
Connect
ACR
AT
AT Result
AT
AT Result
........
We can see in the VPMN forward flow, after MSC/SSP reports ACR (among it, the
parameter callActive=False, which means the call is completed), it does not report
ERB while SCP keeps in the status of waiting for ERB. Such a situation is not the first
time. But later SCP delivers AT every 6 minutes and MSC/SSP keeps returning
AT-Result, so SCP robots cannot be released. We can confirm at least two errors at
the end office:
1) After the call is completed, the ERB message is not reported;
2) After the end of the call, the end office always returns the success response to
the AT operation delivered by SCP.
6. The last problem is the inconsistency of the downed robots between the active and
the standby machines.
1) The following is a call instance on the standby machine:
……
| tc_continue2 tc_invoke (invokeID=31) AT_CAP ->
| tc_continue2 tc_result_l (invokeID=31) IDP_CAP <-
| tc_end tc_u_reject (invokeID=1) ->
SCP delivers multiple ATs, before invokeID=32, the delivered and the reported
invokeIDs are consistent; after 32, the delivered becomes 4 while the reported is 1.
Due to the inconsistency of the invokeID, SCP delivers TC-U-Reject to end the call.
InvokeID is defined in the specification as “This parameter is set by the sending
application process.”, so the above are just the value set in TC-Invoke by scf.
MSC/SSP returns the value delivered by SCP in TC-Result-L. The allocation principle
by scf is polling from 1 to 32 but here 1~3 are skipped.
2) Next it is a call instance on the host; MSC’s source address is 8613740527:
| tc_begin tc_invoke (invokeID=1) IDP_CAP <-
| tc_continue1 tc_invoke (invokeID=1) RRBE_CAP ->
| tc_continue2 tc_invoke (invokeID=2) AC_CAP ->
| tc_continue2 tc_invoke (invokeID=3) CONNECT_CAP ->
| tc_continue2 tc_invoke (invokeID=2) ACR_CAP
tc_l_cancel tc_l_cancel tc_l_cancel <-
……
When MSC/SSP reports ACR, there follow 3 TC-L-Cancel; their messages are as
below:
tcapComponentID=21 tc_l_cancel (dialogueID=13849, invokeID=1)
These 3 TC-L-Cancels which are not supposed to appear use the invokeID of 1~3. In
scf program, when TC-L-Cancel messages are handled, the corresponding invokeID
will be set as unused (TSACF: ManageTCLCancelInd) and so it can be reallocated
next time. But on the standby machine, the manager thinks the TC-L-Cancel message
is useless and should be directly deleted without sending it to the standby machine’s
scf process for handling, so the invokeID of 1~3 are still in the status of being used. So
when AT is delivered and after the invokeID is used after a poll, the host starts from 1
while the standby machine starts from 4. The message delivered by the standby
machine is not really delivered. The invokeID in MSC/SSP’s response message to AT
is only consistent with that of the host. The host forwards one copy of the message
reported by the host to the standby machine, which does not recognizes it though.
This should have been a BUG but the dialogue and the robot are unexpectedly
released by the standby machine.
[Cause]
1. The signalings reported by MSC/SSP are diversified plus some exceptions, such as
with ACR but with no ERB, with neither ACR nor ERB, misreporting Uabort and Pabort.
The severest case is that in the VPMN forward flow, the above abnormal signalings
appear and directly down the robots of SCP permanently. Later on we hear say that a
lot of problems exist when the ERICSSON end office conducts VPMN’s compatibility
test, including that after ATs are received, AT-Result is returned to all. Attention should
be paid to such similar phenomena.
2. SCP itself also has some BUGs. Except that after IDP is received, CONTINUE will
be immediately delivered and this causes the robot to be downed, there are two other
BUGs: the memory is leaked when the message of the robot relative lock is handled;
the active and the standby machines handle TC-L-Cancel differently. They all help
locate the problem.
[Solution]
1. Modify the BUG of SCP.
2. SCP cannot completely solve the problems caused by abnormal signalings of

MSC/SSP. So we cannot but take the passive mitigation measures:
1) Save the CallActive parameter in the received ACR and judge before AT is
delivered. If it is False, it means the call on MSC/SSP has been released; but
ERB report has been lost, SCP can end the dialogue;
2) If ERB and ACR both are lost, according to the maximum call duration and the
length of the AT timer delivered by AC, we can acquire the number of ATs that
should be delivered within the maximum call duration. If the maximum number of
delivered ATs is passed but neither ACR nor ERB is received, it means the
signaling is lost, then the dialogue will be terminated and the robot released.
3. Collect all kinds of abnormal end-office signalings obtained on the spot; the office
will submit them to the local China Mobile in the hope that they will cooperate with the
manufacturer for a solution.
[Summary]
It is energy consuming to locate and solve this problem; so is the analyzing process.
The major steps are: first start from the log document and the profile statistic data in
order to find the necessary clues and then combines the signaling flow of the
implemented service to analyze the handling by the platform; acquire the code
streams and data of the existing network before looking for exceptions within a certain
target range; discover or infer the cause by mutually proving between the actual
signalings and the SCP codes. If necessary, conduct simulation tests.
There may emerge various kinds of problems. Some phenomena are caused by
multiple causes and thus look very confusing; so we can only handle them one by one;
Some superficial phenomena are exactly opposite to the real nature, so they can
misguide you to the wrong direction and we should try to remove all these
interferences; of course there are times when we are lucky enough, for example, BUG
happens to have helped reduce the range of problems. All in all, our analysis and
conclusion should be based on ample evidences and reasons till the final causes are
confirmed. We should label each located problem so that the whole process will be
easier later. Certainly correct positioning at the very beginning is critically important,
otherwise it will be misleading.
4.2.8 The End Office Responds Abnormally to the PA Operation
[Problem symptom]
After SCP is upgraded to the new version, the number of TC-U-Abort signalings
received on MSC/SSP increases, so there appear quite many alarms of “IN protocol
error” (B2C).
[Analysis process]
The engineer of the office conducts tracing on SCP by means of the manual dialing
test, but due to the small percentage of B2C against the total number of calls, not any
value signaling flows are collected. Then on the condition that SCP4 has not launched
the number, turn on all the tracing switches on SCP4; meanwhile trace the lower-layer
signaling messages on SAU. Since the traffic volume on SCP4 is too small, not a
single B2C appears after a whole day of dialing tests.
Then the Network Operation Support Department of China Mobile, MSC manufacturer
and Huawei Technologies reach an agreement to use the signaling tester to trace the
signaling link between MSC3 and SCP2. The MSC engineer discovers an exception
on the signaling tester: sometimes after MSC/SSP submits IDP messages to SCP,
SCP does not return the RRBE message but returns the TC-U-Abort message. After
the customer service engineer feed back the abnormal signaling flow to the company,
PDT dispatches the senior experts in the testing department to conduct site tests with
certain necessary instruments After 3 days and 3 nights spent tracing large amounts of
signalings between MSC/SSP and SCP, the following analysis and conclusion are
obtained.
After upgrading, the reason why B2C increases is that the SCP of the new version
handles the abnormal signalings on the network in a different way. In some situations,
after MSC/SSP plays announcement to the subscriber, it does not return the
announcement result report to SCP or it returns the unexpected message to SCP, so
this causes the dialogue ID to be used for a long time. However the number of
dialogue IDs is stable and they are rotarily allocated. When the traffic volume large,
long time of occupation will lead to the generation of repeated dialogue ID. But the
SCP before version upgrading does not respond to handling of repeated dialogue IDs.
In this way MSC/SSP generates a lot of B2D (intelligent service response timeout)
alarms; but after a newly-upgraded SCP discovers a new dialogue uses a repeated
dialogue ID, it will immediately return the TC-U-Abort message to MSC/SSP to reject
this new dialogue; in this case, MSC/SSP generates B2C (intelligent protocol error)
alarms. According to statistics, under each MSC, during busy hour, the number of
B2Cs accounts for 0.2% or so of the total call volume and this can affect the put-thru
rate to some degree.
[Cause]
In the calling/called flow, after SCP delivers PA or PC operation, the robot of this call
will enter the state of waiting for the end office to return interactive operation states
stipulated by the specification such as SRR, P&C result and so on. If the speech
resources of the network environment have some faults or there are some other
reasons, the robot receives the abnormal signaling or unexpected signaling or the end
office returns no messages at all, it will keep waiting till PA or P&C operation times out;
then SCP delivers TC-U-Abort to MSC/SSP to terminate the downed dialogue. The
practical signaling state monitored by the tester is described as below:
Dialogue numbers are rotarily allocated within the range preset by SAU; each robot
should correspond to a unique one. SCP has different timeout length definitions of
different states of setup dialogues, for example, the timeout length of the PA operation
is 30 minutes, the length of AT after CONTINUE is delivered is 6 minutes. In SAU,
there is one type of expression of setup dialogues – Active state and the timeout
length is 10 minutes. If the end office gives no response to the PA/P&C operation, after
waiting 10 minutes, SAU will release this dialogue and reclaim its number for reuse;
but SCP will keep waiting, for this dialogue number is still in the state of being used.
When it receives a new request for the TCAP dialogue, SAU will reallocate this
dialoguenumber to the new call and report to SCP, so a repeated dialogue number
appears. In the previous versions, SCP does no handling at all; after being upgraded,
SCP will directly return TC-U-Abort to reject the newly reported IDP call.
In this case the influence on the put-thru rate can be roughly calculated: suppose
CAPS is C, the number of downed robots is F; since each robot waits for 30 minutes
and PA/P&C gives no response, the percentage of the downed robots is F/(C*60*30).
Including the repeated dialogue numbers caused by downed robots, the total number
of call loss doubles, so the total call loss rate is F/(C*900). If we simply consider there
exists a positive proportionate relationship between F and C, F=C*R*60*30, R is the
ratio of the number of not-responding PA/P&Cs against the number of total calls, then
the last call loss rate is 2R, which is consistent with the result of visual judgment. Then
it can be compared with relevant statistic data.
[Solution]
1. If the end office returns abnormal signalings or no response to the PA/P&C

operation, SCP need not be modified; instead the cause should be traced in MSC/SSP
and SRF.
2. Since the timeout lengths of SCP and of SAU are not consistent, the repeated
dialogue numbers are generated. 128-mode SAU has the timeout length function used
to configure Active dialogues, so it can solve this problem.
[Summary]
1. The reason why the robots get downed must be due to poor cooperation with the
signaling flows of NEs such as the end office.
2. The result of downed robots usually comes along with the phenomenon of repeated
dialogue numbers. As long as the TCAP dialogue is released on SAU and the robot of
this dialogue is still retained on SCP, the repeated dialogue number will be generated.
4.2.9 Number Display Problems Caused by a Certain Parameter Value
[Problem symptom]
During the process of debugging the local VPN service, we find that when PSTN calls
subscribers in the network and the call is forwarded to the subscribers in the network,
there is no incoming call number display on some of the mobiles of the called parties.
[Analysis process]
According to the site situation, only some mobile phones (domestic manufacturers)
have no incoming call display. We can see in a very visualized way that only the
GenericNumber of the Connect operation has something to do with the display of the
number of the calling party on SCP, so it is necessary to analyze the problem together
with the MSC manufacturer. According to the message traced on MSC, in the signaling
flow of the VPN service, SCP delivers the CONNECT operation while the screening
indicator in the GenericNumber of this operation is 00B, which means “provided by the
subscriber but not verified”. But the local MSC manufacturer insists the value be 11B:
“Currently Huawei SCP sends binary 00 in the SI which has been identified to cause
CLI display problem in the Chinese made mobile phones. The problem will be solved if
they send binary 11 instead in the SI.”, which means “provided by the network”,
otherwise those mobile phones made in China cannot display the incoming call
numbers.
Though description of this part in the specification is different from the description by
ERICSSON, through negotiations Huawei agrees that the value of the Screening
Indicator in the CONNECT operation delivered by SCP should be determined by the
Screening Indicator of parameter CallingPartyNumber in the IDP operation reported by

MSC; that is to say, SCP will deliver whatever MSC submits. In this way, as long as the
Screening Indicator in the IDP reported by ERICSSON MSC is 11B, the Screening
Indicator in CONNECT delivered by SCP will be 11B.
We especially launch a platform version for this site under such circumstances and
conduct the first upgrading. After the upgrading is completed that night, the office
reports on the spot that all the called mobile phones of the forwarded calls have no
incoming call display.
[Cause]
Cause of the problem: E MSC conducts no upgrading, so the equipment does not
support the result of negotiations. Before we are clear about the upgrading conditions,
we venture to modify SCP and access Internet, which leads to bigger problems.
[Solution]
1. The value of the parameter delivered by SCP has been modified for several times.
Then China Mobile also implements the VPMN service and poses the same question.
Till they issue two documents stipulating whatever MSC submits in IDP should be
delivered by SCP in CONNECT, this problem is finally solved.
2. For the sake of security, SCP modifies the value of parameter Screening Indicator
into a configurable mode.
[Summary]
SCP has many signaling cooperation problems with other NEs. This is a quite typical
instance and leads to very grave consequences. It tells us we must be cautious in
modifying the compatibility.
4.2.10 Number Attribute Errors Affect Charging
[Problem symptom]
After this SCP is upgraded to version R002, charging is normal; but for IP international
phone calls dialed with the access code 17951, the toll charge is still abnormal. For
two virtual testing calls to USA, the toll charge should be 2.4 yuan/minute but actually
it is 1.6 yuan/minute.
[Analysis process]
1. Based on the theory the IP international toll charge is calculated, first we should
check the data in the service table pps_iprate and confirm the chargerule recording
17951 is 60; then view the platform table callingintercl and confirm the record
“60|1|202|” exists; then look at the chargemode table and confirm
“202|240|60|60|-1|-1|-1|-1|” is recorded, which means the charge rate is 240 fen/60

seconds. This proves the data configuration is correct.
2. The charge rate of 1.6 yuan/minute has nothing to do with any record in
chargemode and the reason why it is recorded is still unknown. Since the data in
chargemode are not plenty, we can check one by one and come to discover a record
“100|80|6|6|-1|-1|-1|-1|”, which means the charge rate is 80 fen/6 seconds. Then we
look again at the bill and find the call durations on both bills are above 6 seconds but
less than 12 seconds. This justifies our guess: 1.6 yuan/minute is for two metered
charges.
3. The charge rate setting of chargemode=100 is for common international toll charges
in some regions. It shows the call is charged not as the IP phone toll call but as a
common international call and that it is not the data but the charging program flow is
wrong. By further analyzing the bill we note a problem which has been neglected for a
long time: the called party number starts with “0017951” but the testing personnel
confirms the dialed number starts with “17951”, how come so many “00”? Try some
more calls and we find some called party numbers start with “00” but some not. If the
number starts with “17951”, the charging is correct. One SSP expert on the site
remembers an entry of data has been set on a certain SSP of this site, which sets the
calls with 17951 as the prefix of its number with attributes of international toll calls.
[Cause]
According to the characteristics of version SCP R002 and above, before number
analysis, if the number attribute is International number, then the prefix interCallCode
(its value is “00”) of the international number in the localconfig table will be used to
match the original number; if failed, the interCallCode will be added before the original
number; if the number attribute is Domestic number, then the tollCallCode (its value is
“0”) of the domestic toll number in the localconfig table will be used to match the
original number; if failed, the tollCallCode will be added before the original number.
For calls triggered by this SSP in this site, the attribute of the called party number is
International number, so SCP will add “00” before “17951”; during number analysis, it
happens that “001” is analyzed as a common international toll call with USA as the
called location, consistent with the virtual called location during the test.
[Solution]
After deleting the problematic entry of data on SSP, we open OAM’s calling trace menu
to trace the call for dozens of times, but see no more numbers like
“0017951XXXXXXX”.
[Summary]
Charging errors most probably are caused by errors in number analysis results.
Number analysis errors usually lie in the abnormal format and attributes of the number.
Similar cases: when PPS mobile phones are used dial domestic toll calls, they are
charged as international toll calls. Seen from the SCP bill, they are indeed charged as
international toll calls. The reason is that the called party is 005374222864 while 0053
happens to be a valid international area code, so it is inevitable that this call is seen as
an international toll call during charging analysis; the possible causes are: first, the
called party number reported by MSC/SSP is 5374222864 but its attribute is
International number; secondly, the called party number reported by SSP is
005374222864. Both can lead to charging errors. In the first case, MSC/SSP should
report the domestic number attribute; in the second case, this is forbidden.
4.2.11 Since the hlrto Area Number Table is not Made Complete, Calls to
Non-local Subscribers are not Billed with the Toll Charge.
Symptom: Calls to some non-local mobile phone users are not billed with the toll
charge.
Analysis: As we know the precondition to bill the toll charge of the calling party is to
have analyzed the toll area code of the home location of the called party. For fixed
numbers, the area code of the number should be dialed; for mobile phone numbers, it
is necessary to analyze the area code corresponding to its hlrNumber. Through dialing
tests, we find charging problems only exist when mobile phone numbers are dialed but
not for PSTN numbers. Calls to these numbers are charged but not with the toll charge.
Further observe these problematic number and we find they all belong to the newly
added number sections. So we suspect SCP fails in analyzing the toll area code of the
numbers in the new number sections and thus they are charged as the local PSTN
numbers.
To validate the above analysis, we can trace single calls to acquire the debug
document. By reading the number analysis of the mobile phone number of the called
party, SCP cannot judge it is the mobile phone number and obtain the area code by
querying the hlrtoareanumber table; besides since this number does not contain the
area code, the service regards it as a PSTN number and conduct connection. This
proves our analysis is correct.
Solution: The service modifies the corresponding number analysis flow to handle the
mobile phone number with no data existing in hlrtoareanumber. We can tell this is the
mobile phone number or the PSTN number without the area code when the service
analyzes whether the length of the called party number is >=11 digits. If it is the mobile
phone number and there is no corresponding data in hlrtoareanumber, the service will
play the prompt “This number does not exist” and will not put it through. Because when
the home area code of the called party mobile phone is still unknown, the service does
not know how to charge. The calculation for specific judgment is:
1) If we find the called party number is PSTN. (maybe the mobile phone lacks the
Hlr data).
2) Further observe the PSTN number with the area code stripped, if it starts with ‘13’,
that means it is the mobile phone number. Then we can confirm this number is
the mobile phone with necessary data missed and the call will be released after
the proper prompt. If the number does not start with ‘13’ after the area code is
stripped, that means it is a PSTN number and the call can continue.
4.2.12 POP Card Subscribers Dialing the Local Fixed Phone Number are
Billed with the Toll Charge
Symptom: A certain POP card subscriber dials the local fixed phone number
86130797 and he is billed with the toll charge.
Analysis: Respectively use the Shenzhouxing and M-zone card mobile phones to dial
this fixed phone number, both are billed with the toll charge. By checking the SCP bill,
we find the called party number is displayed as 130797 (Note there is no 86 before it).
Through OAM tracing signaling, the called party number is displayed as 86130797.
Since there is no 86 before the called party number recorded in the bill, we are justified
to suspect SCP judges this number as the country code + the mobile phone number
and obtains 130797 as the called party number after stripping the country code.
To further verify our analysis, we can use dbaccess to consider 130797 as the
hlrtoareanumber in hlrtoareanumber and find that the toll area code can be matched.
For still further validation, we can trace single calls to obtain the debug document and
find that when analyzing 130797, SCP will regard it as the mobile phone number and
obtain the area code by querying.
Solution: There are two solutions:

1) In the hlrtoareanumber table, the number section of 130797 is extended as
1307970-1307979. So during number analysis, 130797 cannot be matched and
will not be seen as the mobile phone number.
2) Modify the service and improve the special handling of 8613. We should not only
analyze whether the number after 86 is the mobile phone number but also
analyze whether its length is 11-digit. Only when it is 11-digit long, we can
conduct special handling.
1) can be adopted for temporary mitigation; 2) can be adopted for final resolution.
4.2.13 Announcement Makes the End Office to Output the Charging Bill
Symptom: A subscriber dials the number of a “validity-expired subscriber” and is told

the number does not exist, but the end office generates the charging bill.
Analysis: Contact the MSC engineer for analysis and he thinks the bi-directional
indicator in the ETC delivered by SCP is Required, so MSC generates the bill.
Solution: Refer to 20020320 Notice on Regulating the Usage of Parameter

BOTHWAYthoughconection.tif released by CMCC, SCP delivery complies with the
specification and modification of MSC is supported. Similar situations include that
when CTR plays announcement, the charging bill is generated. Through OAM tracing
signaling, check whether the signaling (ETC or CTR) delivered by SCP complies with
the requirement of this notice.
4.2.14 Since the Database Index is not Established, Query Times out and the
Call cannot be Put Through
Symptom: A certain service call cannot be put through; the phenomenon is that there
is no response long after dialing and the call is release due to timeout.
Analysis: Roughly we judge it is due to the problem of the signaling. The symptom on
the signaling is that the abort message of the end office is received but by checking
the log document, we find there is CPU overuse alarm; use top to observe and see the
occupation of oninit processcpu is really high; turn on the printing switch and we find
the document can be traced but the call used to test the mobile phone cannot be
traced. The cause should be that the use rate of cpu is too high and the response is
too slow, so this call has not been handled. Open the sqlx.log and we see the query
speed of the mvpn_phone table is very slow. The number of records in this table is
very large, so we suspect the index is not established or lost. We can also check if the
index works during querying with the previous method.
Solution: The problem is solved after the index is established.
4.2.15 Dial the PPS Number beyond the Retention Term and the Subscriber
Hears “The Subscriber You Dialed is Poweroff”.
Symptom: There is a Shenzhouxing stored value card, which has not ever been used.
When the owner wants to use it recently only to find it expires the retention term. When
dialing this phone number, he can only hear “The subscriber you dialed is poweroff”.
So the customer issued a complaint. According to the specification, the voice he gets
by dialing the PPS retention-period subscriber should be: “The number you dialed is
invalid”; the voice he gets by dialing the PPS freeze-period subscriber should be: “The
number you dialed does not exist”. However the subscriber actually is powered on but
the voice tells you: “The subscriber you dialed is poweroff”. We guess maybe
something is wrong with the service.
Analysis: The site engineer conducts signaling tracing through OAM and acquires the
signaling flow:
13611146666_gj.trace
We find when the number of this Shenzhouxing stored value card is dialed and after
IDP appears, SCP releases the call but it does not instruct MSC to play announcement
– “The subscriber you dialed is poweroff” should be played by MSC to the calling party
after SCP releases the call. But what prompts MSC to play the wrong announcement?
We notice the subscriber state parameter reported by IDP.
There are several subscriber states as described below:
SubscriberState ::= CHOICE {
assumedIdle [0] NULL,
camelBusy [1] NULL,
netDetNotReachable NotReachableReason,
notProvidedFromVLR [2] NULL}
The not-reachable reasons are described below:
NotReachableReason ::= ENUMERATED {
msPurged (0), //Only when this reason is submitted,the releaseCause

with the value of 20 is delivered
imsiDetached (1),
restrictedArea (2),
notRegistered (3)}
According to the tracing information fed back from the location, in the IPD message
exist the following records:
subscriberState={
state=notReachable //The subscriber state is not reachable
notReachableReason=0 //The reason is mspurged
So SCP will deliver the release-call with the cause value of 20 and instruct SSP to play
the alert tone – “the subscriber you dialed is poweroff” to the subscriber, which
complies with “20010920 Notice on the Record Notification Implementation Plan when
the Called Prepaid Subscriber is Poweroff” released by China Mobile.
20010920关于下发被叫预付费用户关机时录音通知实现方案的通知.tif
Solution: MSC and HLR cooperate on the solution.
4.2.16 Since the Voice at the End Office is not Loaded, the Call is Terminated
Abnormally
Symptom: After a subscriber dials 13800138000 and press 1, he hears the alert tone
“Your input is wrong”.
Analysis: Trace the signaling on OAM and analyze the traced message and we find
after the testing subscriber dials 13800138000 and selects the language, SCP delivers
the play-announcement instruction (ID is 0140003e). This announcement is used to
replace the 0140000b announcement after the familiarity number service is activated.
MSC/SSP returns tc_u_error, errno=13, which means the resource is unusable. This is
probably due to the fact that MSC only loads the PPS announcement but not loads the
familiarity number announcement.
Note: Trace PA or PC on OAM to acquire the announcement ID. But how can it
correspond to the practical announcement content? Usually we need to find the
service specification of the relevant service. Note it is not the service signaling
specification.
Solution: Load the corresponding announcement on MSC.
4.2.17 Due to the Number Format Error, the Number of the Calling Party
Becomes “00000” and the Familiarity Number Enjoys No Discount
Symptom: In the bill of a Shenzhouxing called subscriber, the number of the calling
party is filled up with “00000” and the familiarity number enjoys no discount.
Analysis: Set a local Shenzhouxing testing number 13690000001 as the familiarity

number 07682356060 and use 07682356060 to dial 13690000001 for a test. Trace the
call on SCP1 and view the bill finding the system really gives no discount to
thisfamiliarity number and unexpectedly the number of the calling party in the bill is
“00000”. It is the same case for several tests. chaozhou.trace
Check the IDP message used to trace the document and we find the submitted
number of the calling party is not the international-standard number, nor “00000”. Use
SMAP to query the setting of the familiarity number service and the familiarity number
setting of this number but both are correct.
No discount for the familiarity number is because SCP cannot analyze a number in the
form of 860786xxxxxxx. It is forbidden to submit the case of country code + ‘0’ + the
area code + the common number. The non-standard area code cannot be stripped, so
the familiarity number data cannot be matched.
In the bill of the called party, the number of the calling party ‘00000’ is also caused by
this reason. SCP cannot strip the area code of this type of numbers. So in calculating
the number, the number of the calling party becomes ‘00000’. This calculation is for
correctly matching the familiarity number. The specific calculation is S_Callingaddress
= ’0’ + the area code + PSTN (without the area code). Since the area code cannot be
stripped, the area code=’0000’ and PSTN=blank, that is how ‘00000’ comes from.
Solution: MSC/SSP adjusts the format of the number to be submitted.
4.2.18 A Subscriber Queries the Balance but Cannot Hear the Balance
Normally
Symptom: A certain ppip subscriber “7697883787” can recharge normally and dial ip
phone calls; but when he dials 13800138000 to query the balance, after the prompt
tone “Your account is 7697883787”, there is no more prompt and the call is cut off.
Analysis: Conduct signaling tracing on OAM to trace the document:
放音断线问题.txt . According to the management flow of PPIP and the collected
signaling information, after the first PA announcement “Your account is …“ to this call,
the end office does not submit the SpecialzedResouceReport but submits the ERB/DP
event which means the calling party aborts. The signaling flow is as shown below:
There are two possibilities: 1. The subscriber hangs up the phone directly; 2. The end
office does not play announcement correctly or after the first announcement is played,
it is not reported to SRR so that SCP cannot continue to deliver the second PA playing
the balance of the subscriber. Then after waiting for a while, the subscriber hangs up
the phone.
Solution: Locate the problem in the end office.
Chapter 5 Appendix
5.1 Encoding Format of the GT Code
According to the GT code indicator, there are four types of GT codes. Among them,
the fourth type of GT codes (when the GT code indicator=4) have the widest
application, so next we will describe the format of this type of GT codes. (For other
types of GT codes, their formats are relatively simple and rare, so we will not introduce
them here. If necessary, please refer to relevant materials)
When the GT code indicator is =4, the structure of the GT code is as below:
8 7 6 5 4 3 2 1 bit
Octet 1 GT code indicator
Octet 2 Translation type
Octet 3 Numbering plan Encoding scheme
Octet 4 Idle Address property indicator
Octet N Address information
GT code indicator: Here it is the same as that in the address type indicator. For the
fourth type of GT codes, it should be “04H”.
Description:
It is necessary to clarify that this parameter is provided by the address type indicator in
the SCCP address that is really transmitted. The GT code does not contain this
parameter. But when the GT code is filled in relevant data setting tables, this
parameter should be included at first.
Translation type: It has not been put into application; the fixed value is “00H”.
Numbering plan: Octet 3 high 4 bit is the numbering plan, indicating which mode is
adopted by the address information for numbering. The specific codes are described
as below:
Bit 7654 Meaning
0000(0) Not defined yet
0001(1) ISDN/telephone numbering plan (E.163 and E.164 are

recommended)
0010(2) Standby
0011(3) Data numbering plan (X.121 is recommended)
0100(4) Telex numbering plan (F.69 is recommended)
0101(5) Marine mobile numbering plan (E.210 and E.211 are

recommended)
0110(6) Land mobile numbering plan (E.212 is recommended)
0111(7) ISDN/mobile numbering plan (E.214 is recommended)
1000
to Standby
1111
Encoding scheme: Octet 3 low 4 bit is the numbering plan, indicating the number of
address signals in the address information is odd or even. The codes are as follow:
Bit 7654 Meaning
0000 Not defined yet
0001 An odd number of address signals
0010 An even number of address signals l
0011
to Standby
1111
Address property indicator: Octet 2’s bit 1-7, indicating the property of the address
information. The codes are as follow:
Bit 7654321
0000000(0) Idle
0000001(1) Subscriber number
0000010(2) Domestic standby
0000011(3) Domestic valid number
0000100(4) International number
0000101(5) to Idle
1111111(127)
Address information: Octet 3 and those behind it are the address signals. Their
formats are as below:
Each address signal occupies 4 bits; the codes are as below:
8 7 6 54 3 2 1 Bit
Octet 1 The second address signal The first address signal
The fourth address signal The third address signal
……
-240Octet N 0 (if necessary) The nth address signal
Each address signal occupies 4 bits.
If the number of the address signals is an odd number, behind the address signals
insert the filling code 0000, namely, in the Nth Byte’ high 4 bit fill in 0000.
z Instance 1
The GT code indicator entered by the operator is 4; the translation type is 0 (currently
only 0 can be entered); the numbering plan is the land mobile numbering plan (the
code is 6); the address property indicator is the subscriber number (the code is 1); the
address information is 1234567. Since the address information contains an odd
number of entries, the encoding scheme is 0001 (namely 1). Then:
GT code’s content is: 0400610121436507
GTLength (indicating Octet’s ByteLength): 8

z Instance 2
only 0 can be entered); the numbering plan is the land mobile numbering plan (the
code is 6); the address property indicator is the international number (the code is 4);
the address information is 1234567. Since the address information contains an even

z Instance 3
only 0 can be entered); the numbering plan is the marine mobile numbering plan (the
code is 5); the address property indicator is the domestic valid number (the code is 3);
the address information is 4321679. Since the address information contains an odd
5.2 Common Signaling Parameters
5.2.1 Calling Party Number
The format of the calling party number parameter field is shown in Figure 1 below.
8 7 6 5 4 3 2 1

even
2 NI Numbering plan Ind. Address presentation Screening

.
.
Figure1 Q.763 – Calling party number parameter field
The following codes are used in the calling party number parameter field.
a) Odd/even indicator
0 the number of address signals is an even one
1 the number of address signals is an odd one
b) Nature of address indicator
0000000 spare
0000011 national (significant) number (national use)
0 0 0 0 1 0 1⎫
⎪
to ⎬ spare
1 1 0 1 1 1 1 ⎪⎭
1110000⎫
⎪
1 1 1 1 1 1 0 ⎪⎭
1111111 spare
c) Number Incomplete indicator (NI)
0 complete
1 incomplete
d) Numbering plan indicator
0 0 0 spare
0 0 1 ISDN (Telephony) numbering plan (Recommendation E.164)
0 1 0 spare
0 1 1 Data numbering plan (Recommendation X.121) (national use)
1 0 0 Telex numbering plan (Recommendation F.69) (national use)
1 0 1 reserved for national use
1 1 0 reserved for national use
1 1 1 spare
e) Address presentation restricted indicator
00 presentation allowed
01 presentation restricted
10 address not available (Note) (national use)
11 spare
NOTE – If the parameter is included and the address presentation restricted indicator
indicates address not available, octets 3 to n are omitted, the subfields in items a), b),
c) and d) are coded with 0's, and the subfield f) is coded with 11.
f)Screening indicator
00 reserved (Note)
01 user provided, verified and passed
10 reserved (Note)
11 network provided
NOTE – Code 00 and 10 are reserved for "user provided, not verified" and "user
provided, verified and failed" respectively. Codes 00 and 10 are for national use.
g) Address signal
0000 digit 0
0001 digit 1
0010 digit 2
0011 digit 3
0100 digit 4
0101 digit 5
0110 digit 6
0111 digit 7
1000 digit 8
1001 digit 9
1010 spare
1011 code 11
f)Filler
In case of an odd number of address signals, the filler code 0000 is inserted after the
last address signal.
5.2.2 Called Party Number
The format of the called party number parameter field is shown in Figure 2.
8 7 6 5 4 3 2 1
Odd/
1 Nature of address indicator
even
2 INN Ind. Numbering plan Ind. Spare
.
.
Figure 2/Q.763 – Called party number parameter field
5.2.3 Generic Number
The format of the generic number parameter field is shown in Figure 3.
8 7 6 5 4 3 2 1
1 Number qualifier indicator

even
3 NI ind. Numbering plan Ind. Address presentation Screening

restricted Ind.
Figure 3/Q.763 – Generic number parameter field
The following codes are used in the generic number parameter field:
a) Number qualifier indicator
00000000 reserved (dialled digits) (national use)
00000001 additional called number (national use)
00000010 reserved (supplemental user provided calling number – failed

network screening) (national use)
00000011 reserved (supplemental user provided calling number – not

screened) (national use)
00000100 reserved (redirecting terminating number) (national use)
00000101 additional connected number
00000110 additional calling party number
00000111 reserved for additional original called number
00001000 reserved for additional redirecting number
00001001 reserved for additional redirection number
00001010 reserved (used in 1992 version)
0 0 0 0 1 0 1 1⎫
⎪
to ⎬ spare
0 1 1 1 1 1 1 1 ⎪⎭
10000000⎫
⎪
1 1 1 1 1 1 1 0 ⎪⎭
11111111 reserved for expansion
c) Nature of address indicator
0000000 spare
0000011 national (significant) number
0 0 0 0 1 0 1⎫
⎪
to ⎬ spare
1 1 0 1 1 1 1 ⎪⎭
1110000⎫
⎪
1 1 1 1 1 1 0 ⎪⎭
1111111 spare
NOTE – For each supplementary service the relevant codes and possible default
settings are described in the supplementary service Recommendations
(Recommendation Q.73x)
f)Address presentation restricted indicator
00 presentation allowed
01 presentation restricted
10 address not available
11 spare
(Recommendation Q.73x). When the address presentation restricted indicator
indicates address not available, the subfields in items b), c), d), and e) are coded with
0's, and the screening indicator is set to 11 (network provided).
g) Screening indicator
Only used if the number qualifier indicator is coded 0000 0101 (additional connected
number) or 0000 0110 (additional calling party number). This indicator is coded as
follows:
00 user provided, not verified
01 user provided, verified and passed
10 user provided, verified and failed
11 network provided
(Recommendation Q.73x).
5.2.4 Original Called Number
The format of the original called number parameter field corresponds to the format
shown in Figure 4.
8 7 6 5 4 3 2 1
Odd/
1 Nature of address indicator
even
Address presentation
2 Spare Numbering plan ind. Spare
Figure 4/Q.763 – Original called number parameter field
5.2.5 Redirection Information
The format of the redirection information parameter field is shown in Figure 5.
8 7 6 5 4 3 2 1
1 H G F E D C B A
2 P O N M L K J I
NOTE – The parameter may be received without the second octet from an ISUP'88
(Blue Book).
Figure 5/Q.763 – Redirection information parameter field
The following codes are used in the redirection information parameter field:
bits
CBA Redirecting indicator
no redirection (national use)
call rerouted (national use)
call rerouted, all redirection information presentation

restricted (national use)
call diverted
call diverted, all redirection information presentation restricted
call rerouted, redirection number presentation restricted (national

use)
call diversion, redirection number presentation restricted (national

use)
Spare
Spare
HGFE Original redirection reason
unknown/not available
user busy (national use)
no reply (national use)
unconditional (national use)
0100⎫
⎪
to ⎬ Spare
1 1 1 1 ⎪⎭
Redirection counter. Number of redirections the call has undergone

expressed as a binary number between 1 and 5.
Reserved for national use
bits
PONM Redirecting reason
unknown/not available
user busy
no reply
Unconditional
deflection during alerting
deflection immediate response
mobile subscriber not reachable
0 1 1 1⎫
⎪
to ⎬ Spare
1 1 1 1 ⎪⎭
5.2.6 CalledPartyBCDNumber
CalledPartyBCDNumber ::= OCTET STRING (SIZE

(minCalledPartyBCDNumberLength ..
maxCalledPartyBCDNumberLength))
-- Indicates the Called Party Number, including service selection information.

Refer to GSM
-- 04.08 [25] for encoding. This data type carries only the "type of number",
"numbering plan
-- identification" and "number digit" fields defined in [25]; it does not carry the
"called
-- party BCD number IEI" or "length of called party BCD number contents".
The purpose of the calling party BCD number information element is to identify the
origin of a call.
The calling party BCD number information element is coded as shown in

figure 10.5.93/GSM 04.08 and table 10.5.120/GSM 04.08.
The calling party BCD number is a type 4 information element. In the network to
mobile station direction it has a minimum length of 3 octets and a maximum length of
14 octets. (This information element is not used in the mobile station to network
direction.)
8 7 6 5 4 3 2 1
+-----------------------------------------------+
│ │ Calling party BCD number IEI │ octet 1
+-----------------------------------------------│
│ │
│ Length of calling party BCD number contents │ octet 2
+-----------------------------------------------│
│ 0/1 │ type of │ Numbering plan │
│ ext │ number│ identification │ octet 3
+-----+-----------------------------------------│
│ 1 │presentat. │ 0 0 0 │ screening │
│ ext │ indicator │ spare │ indicator │ octet 3a*
+-----------------------------------------------│
│ │ │
│ Number digit 2 │ Number digit 1 │ octet 4*
+-----------------------+-----------------------│
│ │ │
│ Number digit 4 │ Number digit 3 │ octet 5*
+-----------------------+-----------------------│
│ │ │ :
:
+-----------------------------------------------+
Figure 10.5.93/GSM 04.08: Calling party BCD number information element
The contents of octets 3, 4, etc. are coded as shown in table 10.5.118. The coding of
octet 3a is defined in table 10.5.120 below.
If the calling party BCD number contains an odd number of digits, bits 5 to 8 of the last
octet shall be filled with an end mark coded as "1111".
Table 10.5.120/GSM 04.08: Calling party BCD number

+--------------------------------------------------------+
│ Presentation indicator (octet 3a) │

│ Bits │
│ 7 6 │
│ 0 0 Presentation allowed │
│ 0 1 Presentation restricted │
│ 1 0 Number not available due to interworking │
│ 1 1 Reserved │
││
││
│ If octet 3a is omitted the value "00 - Presentation │
│ allowed" is assumed. │
││
│ Screening indicator (octet 3a) │
││
│ Bits │
│ 2 1 │
│ 0 0 User-provided, not screened │
│ 0 1 User-provided, verified and passed │
│ 1 0 User-provided, verified and failed │
│ 1 1 Network provided │
││
│ If octet 3a is omitted the value "0 0 - User provided, │
│ not screened" is assumed. │
││
+--------------------------------------------------------+
5.2.7 DateAndTime
DateAndTime ::= OCTET STRING (SIZE(7))
-- DateAndTime is BCD encoded. The year digit indicating millenium occupies bits
0-3 of
-- the first octet, and the year digit indicating century occupies bits 4-7 of the first
octet.
-- The year digit indicating decade occupies bits 0-3 of the second octet, whilst the
digit
-- indicating the year within the decade occupies bits 4-7 of the second octet.
-- The most significant month digit occupies bits 0-3 of the third octet, and the least
-- significant month digit occupies bits 4-7 of the third octet.
-- The most significant day digit occupies bits 0-3 of the fourth octet, and the least
significant
-- day digit occupies bits 4-7 of the fourth octet.
-- The most significant hours digit occupies bits 0-3 of the fifth octet, and the least
significant
-- digit occupies bits 4-7 of the fifth octet.
-- The most significant minutes digit occupies bits 0-3 of the sixth octet, and the least
-- significant digit occupies bits 4-7 of the sixth octet.
-- The most significant seconds digit occupies bits 0-3 of the seventh octet, and the
least seconds
-- significant digit occupies bits 4-7 of the seventh octet.
-- For the encoding of digits in an octet, refer to the timeAndtimezone parameter.
5.2.8 EventTypeBCSM
EventTypeBCSM ::= ENUMERATED {

collectedInfo (2),
routeSelectFailure (4),
oCalledPartyBusy (5),
oNoAnswer (6),
oAnswer (7),
oDisconnect (9),
oAbandon (10),
termAttemptAuthorized (12),
tBusy (13),
tNoAnswer (14),
tAnswer (15),
tDisconnect (17),
tAbandon (18)
}
-- Values collectedInfo and termAttemptAuthorized can only be

-- used for TDPs.
5.2.9 SubscriberState
This parameter reports to SCP in IDP on the subscriber state, such as busy, not
reachable, and so on.
SubscriberState ::= CHOICE {
assumedIdle [0] NULL,
camelBusy [1] NULL,
netDetNotReachable NotReachableReason,
notProvidedFromVLR [2] NULL}
NotReachableReason ::= ENUMERATED {
msPurged (0),
imsiDetached (1),
restrictedArea (2),
notRegistered (3)}
5.2.10 O-CSI
O-CSI ::= SEQUENCE {
o-BcsmCamelTDPDataList O-BcsmCamelTDPDataList,
extensionContainer ExtensionContainer OPTIONAL,
...,
camelCapabilityHandling [0] CamelCapabilityHandling OPTIONAL
O-BcsmCamelTDPDataList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF
O-BcsmCamelTDPData
--- O-BcsmCamelTDPDataList shall not contain more than one instance of
--- O-BcsmCamelTDPData containing the same value for

o-BcsmTriggerDetectionPoint.
--- For CAMEL Phase 2, this means that only one instance of O-BcsmCamelTDPData
is allowed
--- with o-BcsmTriggerDetectionPoint being equal to DP2.
maxNumOfCamelTDPData INTEGER ::= 10
O-BcsmCamelTDPData ::= SEQUENCE {
o-BcsmTriggerDetectionPoint O-BcsmTriggerDetectionPoint,
serviceKey ServiceKey,
gsmSCF-Address [0] ISDN-AddressString,
defaultCallHandling [1] DefaultCallHandling,
extensionContainer [2] ExtensionContainer OPTIONAL,
...
ServiceKey ::= INTEGER (0..2147483647)
O-BcsmTriggerDetectionPoint ::= ENUMERATED {
collectedInfo (2),
... }
-- exception handling:
-- For O-BcsmCamelTDPData sequences containing this parameter with any
-- other value than the ones listed the receiver shall ignore the whole
-- O-BcsmCamelTDPDatasequence.
-- For O-BcsmCamelTDP-Criteria sequences containing this parameter with any
-- other value than the ones listed the receiver shall ignore the whole
-- O-BcsmCamelTDP-Criteria sequence.
O-BcsmCamelTDPCriteriaList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData)

OF
O-BcsmCamelTDP-Criteria
O-BcsmCamelTDP-Criteria ::= SEQUENCE {
o-BcsmTriggerDetectionPoint O-BcsmTriggerDetectionPoint,
destinationNumberCriteria [0] DestinationNumberCriteria OPTIONAL,
basicServiceCriteria [1] BasicServiceCriteria OPTIONAL,
callTypeCriteria [2] CallTypeCriteria OPTIONAL,
... }
DestinationNumberCriteria ::= SEQUENCE {
matchType [0] MatchType,
destinationNumberList [1] DestinationNumberList OPTIONAL,
destinationNumberLengthList [2] DestinationNumberLengthList OPTIONAL,
-- one or both of destinationNumberList and destinationNumberLengthList
-- shall be present
... }
DestinationNumberList ::= SEQUENCE SIZE

(1..maxNumOfCamelDestinationNumbers) OF
ISDN-AddressString
-- The receiving entity shall not check the format of a number in
-- the dialled number list
DestinationNumberLengthList ::= SEQUENCE SIZE

(1..maxNumOfCamelDestinationNumberLengths) OF
INTEGER(1..maxNumOfISDN-AddressDigits)
BasicServiceCriteria ::= SEQUENCE

SIZE(1..maxNumOfCamelBasicServiceCriteria) OF
Ext-BasicServiceCode
maxNumOfISDN-AddressDigits INTEGER ::= 15
maxNumOfCamelDestinationNumbers INTEGER ::= 10
maxNumOfCamelDestinationNumberLengths INTEGER ::= 3
maxNumOfCamelBasicServiceCriteria INTEGER ::= 5
CallTypeCriteria ::= ENUMERATED {
forwarded (0),
notForwarded (1)}
MatchType ::= ENUMERATED {
inhibiting (0),
enabling (1)}
DefaultCallHandling ::= ENUMERATED {
continueCall (0) ,
releaseCall (1) ,
...}
-- exception handling:
-- reception of values in range 2-31 shall be treated as "continueCall"
-- reception of values greater than 31 shall be treated as "releaseCall"
CamelCapabilityHandling ::= INTEGER(1..16)
-- value 1 = CAMEL phase 1,
-- value 2 = CAMEL phase 2:
-- reception of values greater than 2 shall be treated as CAMEL phase 2
SupportedCamelPhases ::= BIT STRING {
phase1 (0),
phase2 (1) } (SIZE (1..16))
5.3 Execute Operations
Definition:
ExecuteArgument ::= SET{

object [0] Name,
method-id [1] Object Identifier,
input-assertions [2] SEQUENCE OF SEQUENCE{
type AttributeType,
value AttributeValue
}OPTIONAL,
specific-input [3] SpecificInput OPTIONAL
ExecuteResult ::= SET {

method-id [1] Object Identifier,
output-assertions [2] SEQUENCE OF SEQUENCE{
type AttributeType,
}OPTIONAL,
specific-output [3] SpecificOutput OPTIONAL
-- Common Data Types
Name ::= CHOICE { - - only one possibility for now - -
rdnSequence RDNSequence }
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::= AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE{
type AttributeType,
AttributeType ::= Object Identifier
AttributeValue ::= CHOICE{
intElement [0] INTEGER(0..32767 ),
int4Element [1] INTEGER(0..2147483647 ),
charElement [2] OCTET STRING (SIZE (1) ),
stringElement [3] OCTET STRING (0...36 )
SpecificInput ::= SEQUENCE OF AttributeValue
SpecificOutput ::= SEQUENCE OF AttributeValue
RSDP-MethodID Allocation Table:
Table 5-1 RSDP-methodID allocation table
Service key Service key

for the for the
Application Meaning of Reference
message to MethodID message to
service version the message document
reach the originate the
service service
GPRS-IN 2.0
(forward the
subscriber’s
0 20 102 GPRS-IN
request
operation to
SCP)
SCP sends to
Ring back tone
0 45 1,91 AIP the state
service
query
IUSER
2, Query
SMP_SUPPLY information Prepaid service
1 1001, 100, about t the signaling flow
1 FNS
(VC end) 301, PPS specification
UC2 rechargeable (V4.2)
1 card
UUA
IUSER
2,
SMP_SUPPLY Modify the Prepaid service
1 1001, 100, state of the signaling flow
2 FNS
(VC end) 301, rechargeable specification
UC2 card (V4.2)
1
UUA
Bank card
Query the
1 recharge service
rechcharging
4 2 IUSER signaling flow
(VC end) state of the
specification
bank card
(V1.0)
1 Modify the Bank card

5 2 IUSER rechcharging recharge service
(VC end)
state of the signaling flow

for the for the
service service
bank card specification
(V1.0)
In the query WIN V200R002

function, query SER SMP
1 the basic recharge service
10 1001 SMP_SUPPLY information 2.0 (query the
(VC end) about the rechargeable
rechargeable card) detailed
card design instruction
Query the
Unified recharge
1 UC2 information
service signaling
15 2, 201, 301 about the
(VC end) IUSER flow specification
rechargeable
(V1.0)
card
Modify the
state of
the Unified recharge
1 rechargeable service signaling
16 2, 201, 301 UC2 IUSER card
(VC end) flow specification
(SCP end (V1.0)
outputs the bill)
Modify the
state of
the Unified recharge
1 rechargeable service signaling
17 2, 201, 301 UC2 IUSER card
(VC end) flow specification
(VC end (V1.0)
outputs the bill)
Support the
IUSER3.1D20 recharge query
1 52 201, 1
UC2v2.1d20 message of the
private account
1 53 201, 1 IUSER3.1D20 Support the

for the for the
service service
UC2v2.1d20 non-local
recharge SCP
interconnection
message of the
private account
IUSER
Handle loss Prepaid service
FNS report/loss signaling flow
1 3 2, 100, 1
UUA report specification
cancellation (V4.2)
PPIP
Fixed Subscriber
Query the
PPIP Prepaid IP
2 information of
Service Signaling
1 2, 4, 30 IUSER the PPIP
(VC end) Flow
rechargeable
MPH Specification
card
(V3.0)
Fixed Subscriber
Modify the
PPIP Prepaid IP
2 state of the
Service Signaling
2 2, 4, 30 IUSER PPIP
(VC end) Flow
rechargeable
MPH Specification
card
(V3.0)
Query the
information of
2 6 2 PPIP
th e PPIP local
card
IUSER
Handle loss Prepaid service
FNS report/loss signaling flow
2 3 2, 100, 1
UUA report specification
cancellation (V4.2)
PPIP

for the for the
service service
According to
Mobile virtual
the short
dedicated
number, query
network service
3 6 3 VPN the non-local
signaling flow
SCP
specification
subscriber
(V3.1)
information
According to
Mobile virtual
the real
dedicated
number, query
network service
3 7 3 VPN the non-local
signaling flow
SCP
specification
subscriber
(V3.1)
information
Query VPN
subscriber
charge WIN V200R002
package VPNV6.1
3 8 3 VPNV6.1 information Demand
and the Specification
number of the Instructions
closed user
group
Query VPN
subscriber
WIN V200R002
short number,
VPNV6.1
group number
3 9 3 VPNV6.1 Demand
and the
Specification
number of the
Instructions
closed user
group
Query the WIN V200R002

3 10 3 VPNV6.1
charge rate of VPNV6.1

for the for the
service service
the VPN closed Demand
user group and Specification
apply for or Instructions
update the
group package
free-of-charge
time
WIN V200R002
Apply for the
VPNV6.1
group package
free-of-charge
Specification
time
Instructions
WIN V200R002
Query the cell VPNV6.1
3 12 3 VPNV6.1 accessed by Demand
VPN users Specification
Instructions
According to
the long
VPN61D45
number, query
Demand
3 20 3 vpn6.1D45 the non-local
Specification
SCP
Instructions
subscriber
information
According to
WIN V200R002
the type of the
VPNV6.1
number used,
query the long
Specification
number of the
Instructions
VPN user
1216, Non-local China Mobile

IP17951V1.0D10
4 12 account 17951 IP Service
2, 0, PPIP,
transfer and Signaling Flow

for the for the
service service
1230 IUSER, EA account Specification

opening (v1.31), Fixed
Subscriber
Prepaid IP
Service Signaling
Flow
Specification
V3.0
China Mobile
17951 IP Service
IP17951V1.0D10 Signaling Flow
0, Specification
1216,
Non-local (v1.31); Fixed
4 13 2, PPIP, recharging by Subscriber
IUSER, other mobiles Prepaid IP
1230
Service Signaling
EA Flow
Specification
V3.0
China Mobile
17951 IP Service
IP17951V1.0D10 Signaling Flow
0, Non-local Specification
1216,
account (v1.31),Fixed
4 14 2, IUSER, transfer and Subscriber
PPIP, account Prepaid IP
1230
cancellation Service Signaling
EA Flow
Specification
V3.0
Query the
4 15 2 PPIP temporary
account

for the for the
service service
China Mobile
Query the call 17951 IP Service
IP17951V1.0D10
4 17 4, 1216 privilege of the Signaling Flow
0
user Specification
(v1.31)
China Mobile
17951 IP Service
IP17951V1.0D10 Roaming
4 20 1216 Signaling Flow
0 recharging
Specification
(v1.31)
China Mobile
Notify the
17951 IP Service
IP17951V1.0D10 subtraction of
4 21 4, 1216 Signaling Flow
0 th call charge
Specification
of the user
(v1.31)
China Mobile
Query the 17951 IP Service
IP17951V1.0D10
4 22 1216 account Signaling Flow
0
information Specification
(v1.31)
IP 17951
universal
4 30 4, 1216 IP17951
recharging
message
Fixed Subscriber
PPIP Non-local Prepaid IP
account Service Signaling
5 12 2, 1230 IUSER
transfer and Flow
EA opening Specification
(V3.0)
Non-local Fixed Subscriber

5 13 2 , 1230
recharging by Prepaid IP

for the for the
service service
PPIP other mobiles Service Signaling

Flow
IUSER Specification
EA (V3.0)
Fixed Subscriber
PPIP Non-local Prepaid IP
account Service Signaling
5 14 2 , 1230 IUSER
transfer and Flow
EA cancellation Specification
(V3.0)
Query the call

5 17 2, 1230 EA privilege of the
user
Roaming
5 20 2 , 1230 EA
recharging
Notify the
subtraction of
5 21 2 , 1230 EA
the call charge
of the user
Query the
5 22 2 , 1230 EA account
information
Service Service
key for the key for the
Applicatio
message message Reference
MethodID n service Meaning of the message
to reach to document
version
the originate
service the service
Conduct the calling/called Calling/Called

6 25 6 SPL
party authentication handling Party Free
Service Service
Applicatio
version
the originate
service the service
to the caller pay service, Phone Service
select the calling/called Signaling
subscriber type: Specification
(draft to be
Lists to be sent:
reviewed)
1, id_oi_msisdn: the
called-party mobile phone
number;
2, id_oi_roam: the roaming

location of the calling party
(such as 755);

location of the called party
(such as 755);
4, id_oi_authorizetype: 1:
authenticate the calling party;
2: authenticate the called
party; 3: authenticate the
calling/called party at the
same time.
Lists to be received:
1, 0 fail; 1 succeed
Conduct the calling/called

party authentication handling Calling/Called
to the collect call service, Party Free
select the calling subscriber Phone Service
6 26 6 SPL type: Signaling
Specification
Lists to be sent:
(draft to be
1, id_oi_msisdn: the reviewed)
Service Service
Applicatio
version
the originate
service the service
number;

location of the calling party
(such as 755);

location of the called
party(such as 755);
authenticate the calling party;
2: authenticate the called
party; 3: authenticate the
same time.
1, 0: fail; 1: incoming call; 2:

password authentication is
required
Whether to conduct
open-account and
authentication to the calling
party:
Calling/Called
Lists to be sent: Party Free
Phone Service
1, id_oi_roam: the area code
6 27 6 SPL Signaling
of the access location of the
Specification
calling party (such as 755)
(draft to be
2, id_oi_msisdn: the reviewed)
calling-party mobile phone
number
Service Service
Applicatio
version
the originate
service the service
1, 0: the account is not

opened,1: the account has
been opened, 2: the account
has been opened but
suspended for use temporarily
Add the numbers added by

the user and that can be
dialed in into the list:
Lists to be sent: Calling/Called

1, id_oi_msisdn: the number Party Free
input by the user and allowed Phone Service
6 28 6 SPL to be dialed in; Signaling
Specification
2, id_oi_msisdn: the (draft to be
calling-party mobile phone reviewed)
number;
1, 0: fail; 1: succeed
Update the list of numbers

allowed to be dialed in after
they are modified by the user:
Calling/Called
Lists to be sent:
Party Free
1, id_oi_msisdn: the number Phone Service
6 29 6 SPL input by the user and allowed Signaling
to be dialed in; Specification
(draft to be
2, id_oi_msserial: serial
reviewed)
number of the incoming call
number modified by the
user;3, id_oi_msisdn: the
Service Service
Applicatio
version
the originate
service the service
number;
1, 0: fail; 1: succeed; 2:
the number of this serial No.
has not been set yet
User activates the service

update table data processing:
Calling/Called
Phone Service
Specification
number;
(draft to be
Lists to be received: reviewed)
Update the incoming call

mode of the user into the
password mode and select the
password set by the user;
Lists to be sent: Calling/Called

1, id_oi_pinmode: the Party Free
incoming call mode (1 Phone Service
6 31 6 SPL password mode) Signaling
Specification
2, id_oi_msisdn: the (draft to be
calling-party mobile phone reviewed)
number;
1, id_oi_mspinnumber: the call

password;
Service Service
Applicatio
version
the originate
service the service
2, 0 : fail; 1: succeed
Update the password modified

by the user:
Lists to be sent:
Calling/Called
1, id_oi_mspinnumber:
the Party Free
password modified by the Phone Service
6 32 6 SPL user; Signaling
2, id_oi_msisdn: the Specification
calling-party mobile phone (draft to be
number; reviewed)
User suspends the service

update table data processing:
Calling/Called
Phone Service
Specification
number;
(draft to be
Lists to be received: reviewed)
1, 0 : fail; 1: succeed
Validate whether the Calling/Called

password entered by the user Party Free
is correct: Phone Service
Lists to be sent:
Specification
1, id_oi_mspinnumber: the (draft to be
password entered by the user; reviewed)
Service Service
Applicatio
version
the originate
service the service
number
User opens an account:

Calling/Called
Lists to be sent:
Party Free
1, id_oi_msisdn: the Phone Service
6 35 6 SPL calling-party mobile phone Signaling
number; Specification
(draft to be
reviewed)
Select the incomding number

set by the user: Lists to be
sent:
number Calling/Called
Party Free
Phone Service
st
6 36 6 SPL 1, id_oi_msisdn: the 1 Signaling
number allowed to be dialed Specification
in; (draft to be
nd reviewed)
2, id_oi_msisdn: the 2
number allowed to be dialed
in;
Service Service
Applicatio
version
the originate
service the service
.
th
in;
12, id_oi_callnumberlimit: the

number of incoming call
numbers allowed to be preset;
Select the incomding number

set by the user:
Lists to be sent:
number
Calling/Called
st
Party1 Free
number allowed to be dialed Phone Service
6 37 6 SPL in; Signaling
nd Specification
number allowed to be dialed (draft to be
in; reviewed)
.
th
in;
Service Service
Applicatio
version
the originate
service the service
32, id_oi_callnumberlimit:
the number of incoming call
numbers allowed to be preset;
The called party flow of the

collect call service handles the
roaming authentication of the
called party:
Lists to be sent:
number
Calling/Called
2, id_oi_roam: the roaming Party Free
location of the called Phone Service
6 38 6 SPL party(such as 755) Signaling
Specification
(draft to be
authenticate the calling
reviewed)
party;2: authenticate the
called party;3: authenticate
the calling/called party at the
same time.
1, 0: fail; 1: the number can be

dialed in; 2: password
authentication is required
Service
Service
key for
key for
the
the
message Application Meaning of the Reference
message MethodID
to service version message document
to reach
originate
the
the
service
service
Calling/Called Party
Free Phone Service
6 39~40 6 SPL Standby Signaling
Specification (draft
to be reviewed)
MIN point-to-point
SMS authentication SMS
11 10 11 SMS_AUTH
request Implementation
Specification 3.0
MIN point-to-point
SMS transmission SMS
11 11 11 SMS_AUTH
result notification Implementation
Specification 3.0
MIN point-to-point
SMS transmission SMS
11 12 11 SMS_AUTH
request Implementation
Specification 3.0
WIN V200R002
SMS transmission SER CSD PPS V1.0
11 12 1 CSD PPS
request Detailed Deisgn
Instructions
Monternet SCP
Request charging the
Interconnection
12 15 12 MNET user by the home SCP
Signaling
of the charged number
Specification (V2.2)
Monternet SCP
Confirm the charging Interconnection
12 16 12 MNET
by the home SCP Signaling
Specification (V2.2)
Service
Service
key for
key for
the
the
message MethodID
to reach
originate
the
the
service
service
Forward the operation Monternet SCP

12 17 12 MNET request by the user to Interconnection
SCP Signaling
Supplementary
Regulations on the
Request charging the Point-to-Point SMS
user by the home SCP Interconnection
13 18 13 SMS_UNION of the charged number Service
(namely the charging Specification
request) between China
Mobile and China
Unicom.doc
Supplementary
Regulations on the
Point-to-Point SMS
Confirm the charging
Interconnection
by the home SCP
13 19 13 SMS_UNION Service
(namely charging
Specification
confirmation)
between China
Mobile and China
Unicom.doc
Internet access
20 20 20 CSD PPS authencation
request/response
Charging
20 21 20 CSD PPS
request/response
Query subscriber
31 1 31 WAD None
information
31 2 31 WAD Modify subscriber state None
Service
Service
key for
key for
the
the
message MethodID
to reach
originate
the
the
service
service
WIN V200R003
51 Small amount payment MPPV1.0D100 SER
1 50 MPP service rechargeable Software Demand
(VC end) card authentication Specification
Instructions
WIN V200R003
51 Small amount payment MPPV1.0D100 SER
2 50 MPP service rechargeable Software Demand
(VC end) card location Specification
Instructions
Forward the
144 1 144 Operationid=1100
message
Forward the
message
Forward the
message
Forward the
message
Forward the
message
UAC WIN V200R002

Iuser acquires the
172 1 172 UACV1.1D100
password
Software Demand
Service
Service
key for
key for
the
the
message MethodID
to reach
originate
the
the
service
service
Specification
Instructions.lwp
WIN V200R002
UAC UACV1.1D100
Iuser transmits the
172 2 172 Software Demand
message
Specification
Instructions.lwp
Unified recharge
IUSER, GoTone subscriber service signaling
201 1 2, 301
UC2 non-local recharging flow specification
(V1.0)
Unified recharge
PPIP Shenzhouxing
service signaling
201 2 2, 301 subscriber non-local
IUSER flow specification
recharging
(V1.0)
Unified recharge
IUSER GoTone subscriber service signaling
201 13 2, 301
UC2 non-local recharging flow specification
(V1.0)
Mobile
201 Rechargeable Card
2, 301, UC2
(Home 46 Query the black list Service Signaling
end) Flow Specification
(V2.0)
Mobile
2, 301, UC2
(Home 47 Modify the black list Service Signaling
(V2.0)
Service
Service
key for
key for
the
the
message MethodID
to reach
originate
the
the
service
service
Mobile
2, 301, UC2 Query the
(Home 48 Service Signaling
rechargeable card
(V2.0)
Mobile
201 GoTone card Rechargeable Card
2, 301, UC2
(Home 49 recharged by other Service Signaling
end) mobiles Flow Specification
(V2.0)
Mobile
201 Shenzhouxing card Rechargeable Card
2, 301, UC2
(Home 50 queried by other Service Signaling
end) mobiles Flow Specification
(V2.0)
Query the account

information from the
201 51 2, 301 UC21.7D10
access SCP to the
home SCP
China Mobile 17951

Query the
IP Service Signaling
304 1 1216 IP17951V1.0D100 rechargeable card
Flow Specification
information
(v1.31)
China Mobile 17951

Loccate the IP Service Signaling
304 2 1216 IP17951V1.0D100
rechargeable card Flow Specification
(v1.31)
Query the
305 1 1230, 5 EA
rechargeable card
Service
Service
key for
key for
the
the
message MethodID
to reach
originate
the
the
service
service
information
Modify the state of the

305 2 1230, 5 EA
rechargeable card
PPIP Prepaid common

1,005 1 1, 2, 4 account charging
iUSER request
PPIP Prepaid account

1,005 2 2
iUSER validity authentication
WIN V200R002
IUSERV2.3D10
12, 144, iuser account
SER Software
1,111 1 172, UAC authentication and
Demand
10101 query
Specification
Instructions.lwp
WIN V200R002
IUSERV2.3D10
12, 144,
Iuser account resource SER Software
1,111 2 172, UAC
supplement Demand
10101
Specification
Instructions.lwp
WIN V200R002
IUSERV2.3D10
12 , 144, UAC Iuser authentication
SER Software
1,111 3 172, and charging
Demand
10101 application
Specification
Instructions.lwp
Service
Service
key for
key for
the
the
message MethodID
to reach
originate
the
the
service
service
WIN V200R002
IUSERV2.3D11
12, 144,
Iuser account recharge SER Software
1,111 4 172, UAC
operation Demand
10101
Specification
Instructions.lwp
WIN V200R002
IUSERV2.3D11
12 , 144, UAC
Iuser account recharge SER Software
1,111 5 172,
confirmation operation Demand
10101
Specification
Instructions.lwp
1, 2 0 1, 2 UA (Under development)
128 31 1, 2 UA (Under development)
128 32 1, 2 UA (Under development)
Service
Service
key for
key for
the
the
message MethodID
to reach
originate
the
the
service
service
1, 2 31 128 UA (Under development)
1, 2 32 128 UA (Under development)
Object IdentifierID Allocation Table:
Table 5-2 Object IdentifierID allocation table
ID NO.
(DECIMAL FIELD-NAME Field type Meaning Service key
SYSTEM)
1 (uus service), 2
(including pps,
igsm, iuser, uc2
3 servicekey IntegerType Service key and ppip
service), 4, 11,
30, 100, 201,
301, 1001, 3, 20
1 (uus service),
2 (including pps,
igsm, iuser, uc2
Mobile phone number to
13 msisdn CallingNumberType and ppip
be recharged
service), 4, 11,
30, 100, 201,
301, 1001
14 accountnumber String36Type Password of the 1 (uus service),
ID NO.
SYSTEM)
rechargeable card 2 (including pps,
igsm, iuser, uc2
and ppip
service) , 4, 30,
100, 201, 301,
1001
1 (uus service),
2 (including pps,
igsm, iuser, uc2
Amount of the
15 counttotal IntegerType and ppip
rechargeable card
service) , 4, 30,
100, 201, 301,
1001
1 (uus service),
2 (including pps,
igsm, iuser, uc2
Rechargeable card’s
16 activedays IntegerType and ppip
additive validity term
service), 4, 30,
100, 201, 301,
1001
16 monthfeelimit IntegerType Monthly fee limit 3
1 (uus service),
2 (including pps,
msisdnpinnumb igsm, iuser, uc2
17 PinType Account password
er and ppip
service) , 4, 100,
201, 301, 1001
17 montotalfee IntegerType Monthly group fee 3
1 (uus service),
2 (including pps,
igsm, iuser, uc2
18 accountleft IntegerType Bank node number
and ppip
service) , 4, 100,
201, 301, 1001
ID NO.
SYSTEM)
Telephone long number

18 isdnnumber 3
ID
19 power User power set 3
20 groupnumber Group number 3
Number of the calling 2 (uc2 service)

21 calleraddress CallingNumberType
party 201, 301
Number of the
2 (uc2 service)
22 sequence String20Type rechargeable card,
201, 301
namely its serial No.
Operation type/failure 2 (uc2 service)

23 accountstate CharType
type 201, 301
2 (uc2 service)
24 charge1 IntegerType Sum 1
201, 301
2 (uc2 service)
25 charge2 IntegerType Sum 2
201, 301
2 (uc2 service)
26 accountrent IntegerType Account balance
201, 301
2 (uc2 service)
27 callservicestop DateType Validity term
201, 301
2 (uc2 service)
28 msType CharType Mobile subscriber type
201, 301
Whether to authenticate
110 qualifyflag CharType 2, 301, 201
the password of the user
Whether the balance is

111 ifpositive CharType 2, 301, 201
positive
talledPartyNum The number of the called

30 CalledPartyNumType 2, 5, 1230, 305
ber subscriber
ID NO.
SYSTEM)
31 payingType IntegerType Charging mode 2, 5, 1230, 305
Whether the account is

33 lockFlag IntegerType 2, 5, 1230, 305
locked
34 expense IntegerType Expense 2, 5, 1230, 305
Whether the service is

35 ifEndService IntegerType 2, 5, 1230, 305
over
36 accountKind IntegerType Account type 2, 5, 1230, 305
Whether it is the group

37 isGroupAdm IntegerType 2, 5, 1230, 305
administrator
Whether it has entered

38 inBlackList IntegerType 2, 5, 1230, 305
the black list or not
39 tlocationNumber String8Type The calling location code 2, 5, 1230, 305
40 time IntegerType Call duration 2, 5, 1230, 305
Common account funds

60 applicationNo String20Type application transaction 2, 4, 1005
number
applicationAmo Common account funds

61 IntegerType 2, 4, 1005
unt application amount

62 applicationType CharType 2, 4, 1005
application type

63 logoutAmount IntegerType application logout 2, 4, 1005
amount

application
64 identificationNo IntegerType 2, 4, 1005
authentication
transaction number
ID NO.
SYSTEM)

admeasuredAm
65 IntegerType application allocated 2, 4, 1005
ount
amount
22 pinnumber string6type Password of the call 0
Serial No. of the calling

23 serial integer 6
number
Call authentication type:

0 the calling party
authentication, 1 the
called party
authentication, 2
25 authtype chartype authentication of the 6
same time, 3 select the
calling subscriber type, 4
select the called
subscriber type
Number of incoming call

27 SplAmount Integertype numbers allowed to be 6
set
28 pinmode chartype Pin code call mode 6
Roaming area code of

70 callingvplmn string6type the calling party (such as 6
755)
Roaming area code of

71 calledvplmn string6type the called party (such as 6
755)
Mobile phone number of

72 calledmsisdn CalledPartyNumType 6
the called party
73 cmsisdn CalledPartyNumType Incoming call number 6
ID NO.
SYSTEM)
dialed by the subscriber
75 SplNumber1 CalledPartyNumType Incoming call number 1 6
ID NO.
SYSTEM)
1: the balance should be

>0; 2: the balance should
BalanceConditio
66 IntegerType be >=0; 3: no 1111
n
requirement on the
balance
67 GroupNo IntegerType User template number 1111
User charge package

68 PkgFeeType IntegerType 1111
number
MultiServiceFla
69 string36 Integrated service flag 1111
g
70 MoneyLeft IntegerType Account deposit balance 1111
71 ShortMsgLeft IntegerType Free SMS left 1111
72 PointLeft Free points left 1111
73 GprsFlowLeft IntegerType Gprs flow left 1111
UserID originating the

charging request {SCP
number or the GT code
74 ReqChgUserId string20 1111
supplemented at the end
with 0 to 10 digits} + {the
robot number
ID NO.
SYSTEM)
supplementedat the
head with 0 to 10 digits}
75 RevertMoney IntegerType Revert account money 1111
RevertShortMes
76 IntegerType Revert free SMS entries 1111
sage
77 RevertPoint IntegerType Revert free points 1111
78 RevertGprsFlow IntegerType Revert Gprs free flow 1111
1: the first charging

request; 2:intermediate
79 ReqChgType IntegerType 1111
charging request; 3: the
last charging request
Common account
allocation scheme: 0:
allocate according to the
80 CaAllocateType IntegerType 1111
required amount; 1~n:
allocate according to the
various slopes provided
When the request

amount allocation
81 ReqMoneyAmt IntegerType scheme is 1, it is valid; 1111
for the last charging
request, it should be 0
For the first charging

request of the previous
82 UsedMoneyAmt IntegerType 1111
consumed money, it
should be 0

UsedShortMsgA request of the previous
83 IntegerType 1111
mt short message, it should
be 0

84 UsedPointAmt IntegerType 1111
request of the previous
ID NO.
SYSTEM)
free points, it should be 0

UsedGprsFlowA
85 IntegerType request of the previous 1111
mt
Gprs flow, it should be 0
86 AppliedMoney IntegerType Applied money 1111
The service key

87 ReqServiceKey IntegerType originating the request 1111
service
Template multi-service
88 GrpMultiSrvFlag String36 1111
function flag
Recharge trade type
1: prepaid mobile phone

recharge
2: fixed telephone
recharge
3: non-prepaid mobile
phone recharge
4: manual recharge
5: prepaid mobile phone

non-local recharge (state
89 TradeType chartype 1111
5 is not in use currently
and it is combined
together with state 1)
6: pre-charge
8: bank recharge
9: GoTone recharge
(telephone recharge)
a: GoTone recharge
(manual recharge)
c: brand rechargeable
ID NO.
SYSTEM)
card recharge
d: BOSS delivers the

MML command to
directly set the
rechargeable card
f: intelligent user
recharge (unified
recharge fow, reserved)
g: cash recharge service

(recharge gift is required)
h: cash recharge service

(recharge gift is not
required)
Brand of the
90 CardType IntegerType 2, 1201
rechargeable card
Days in the validity term

91 DeductDays IntegerType 1111
to be deducted
Account integrated flag

92 AccountFlag String24Type 1111
bit ID
93 RechargeResult IntegerType Operation type 1111
the called party number

94 Calledaddress CalledPartyNumType or the access code of the 1111
management flow
Recharge discount
support flag: 0:
RechargeGiftFla
95 charType recharge discount is not 1111
g
supported; 1: recharge
discount is supported.
13 RSDPMSISDN String36Type Account number 4,1216
ID NO.
SYSTEM)
RSDPAccountN Password of the

14 String36Type 4,1216
um rechargeable card
RSDPAccountL
15 IntegerType Amount 4,1216
eft
The rest validity term or

RSDPActiveDay
16 IntegerType the retention term of the 4,1216
s
account
RSDPPinNumb
17 String36Type Password of the account 4,1216
er
RSDPOriginalM Number of the calling

SISDN party
RSDPCalledPar the number of the called

tyNum subscriber
RSDPPayingTy
31 IntegerType Charging mode 4,1216
pe
Whether the account is

33 RSDPLockFlag IntegerType 4,1216
locked or not
34 RSDPExpense IntegerType Expense 4,1216
RSDPIfEndServ Whether the service is

35 IntegerType 4,1216
ice over
RSDPAccountT
36 IntegerType Account type 4,1216
ype
CRSDPIsGroup Whether it is the group

Adm administrator
CRSDPInBlack Whether it has entered

List the black list or not
CRSDPLocation
39 String36Type The calling location code 4,1216
Number
40 CRSDPTime IntegerType Call duration 4,1216
ID NO.
SYSTEM)
CRSDPPayAcc Common account bound

ount by the user
CRSDPPayAcc
42 String36Type Common account type 4,1216
ountType

WIN Products - Topic On The Analysis of The Signaling V1.0-20050401-B

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

WIN Products - Topic On The Analysis of The Signaling V1.0-20050401-B

Загружено:

Авторское право:

Доступные форматы

Document No.

Product name WIN

Usage object WIN Engineers Product version

Prepared by WIN Document version V1.1

WIN Products – Topic On the Analysis

Drafted by: Mao Yuanjian Date: 2004/4/23

Reviewed by: Date:

Reviewed by: Date:

Approved by: Date:

Huawei Technologies Co., Ltd.

All rights reserved

For internal use only

2004/4/23 1.0 It was drafted. Mao Yuanjian

Revisions: enriched contents about call trace

For internal use only

Chapter 1 Basic Signaling Knowledge........................................................................................... 3

Chapter 2 Introduction to Signaling Faults Locating Tools....................................................... 47

For internal use only

2.5.3 Observing Number Analysis Results ....................................................................... 69

Chapter 3 Typical Service Signaling Flows ................................................................................. 74

Chapter 4 Analysis and Handling of Signaling Faults.............................................................. 112

For internal use only

Chapter 5 Appendix...................................................................................................................... 144

For internal use only

Keyword: Signaling analysis

For internal use only

For mobile intelligent networks, it is a prerequisite for mobile IN maintenance

This document summarizes and rearranges a large amount of relevant materials

For more systematic description of the basic signaling knowledge, this

2006-08-30 Confidential document, for internal use only Page 2 of 203

Chapter 1 Basic Signaling Knowledge

1.1 Basic Knowledge

Figure 1-1 Structure of the signaling system related to IN

What is shown above should be remembered by us during routine signaling

2006-08-30 Confidential document, for internal use only Page 3 of 203

1.2 SCCP Knowledge Points

2006-08-30 Confidential document, for internal use only Page 4 of 203

For one message to be sent from A to K, if DPC addressing is adopted, it is necessary

2006-08-30 Confidential document, for internal use only Page 5 of 203

For one message to be sent from A to K, if GT addressing is adopted, it is only

2006-08-30 Confidential document, for internal use only Page 6 of 203

According to the principle of load balancing, if B routes the message to K to F.

Differences between DPC Addressing and GT Addressing:

1.3 TCAP Knowledge Points

1.3.1 Several Concepts

Dialogue: it refers to a series of TCAP messages exchanged between two TC users

Primitive: To put it simply, a primitive corresponds to several TCAP messages. No

2006-08-30 Confidential document, for internal use only Page 7 of 203

1.3.2 Dialogue Primitive

Byte Length Meaning Value

2 1 TCAP component primitive 01: tc_begin

2006-08-30 Confidential document, for internal use only Page 8 of 203

Byte Length Meaning Value

Note 2: 12 is the address

Note: 07 refers to the length

Common application contexts:

SRI_V2 = {0x04,0x00,0x00,0x01,0x00,0x05,0x02}; (MAP Phase2)

SRI_V2+ = {0x04,0x00,0x00,0x01,0x00,0x05,0x03}; (MAP Phase2+)

For a dialogue, it is necessary to distinguish whether it is the first tc_continue. At the

2006-08-30 Confidential document, for internal use only Page 9 of 203

2006-08-30 Confidential document, for internal use only Page 10 of 203

The reason why SCP is delivered can be: