You are on page 1of 203

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

For internal use only


Confidentiality: for
~53F3.doc internal use only

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

For internal use only


Confidentiality: for
~53F3.doc internal use only

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

For internal use only


Confidentiality: for
~53F3.doc internal use only

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

For internal use only


Confidentiality: for
~53F3.doc internal use only

Keyword: Signaling analysis

Abstract: This document introduces the basic signaling of WIN products and describes fault

analysis.

List of Abbreviations:

List of References:

For internal use only


Confidentiality: for
~53F3.doc internal use only

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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:

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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) }

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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;

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


Confidentiality: for
~53F3.doc internal use only

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)

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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

1 Odd/ Nature of address indicator


even

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


Confidentiality: for
~53F3.doc internal use only

2 NI Numbering plan Ind. Address presentation Screening


restricted indicator

3 2nd address signal 1st address signal

.
.

n Filler (if necessary) nth address signal

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

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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

2 Odd/ Nature of address indicator


even

3 NI ind. Numbering plan Ind. Address presentation Screening


restricted Ind.

4 2nd address signal 1st address signal

n Filler (if necessary) nth address signal

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

(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

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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:

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

AttributeTypeAndValue

Type id_oi_serviceKey (note)

Value 1

AttributeTypeAndValue

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


MethodID id_mt_ppsclaimMissing (note)
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”.

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


Confidentiality: for
~53F3.doc internal use only

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:
qualityOfService={-1,1}
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"
componentsPresent=-1

SCP <=============

**********************Execute Argument **************************

object=

[0]=
type=
global= 304
0x00 11 89 4c 02 04 03
value=
int4Element=4
[1]=
type=
global= 304

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


Confidentiality: for
~53F3.doc internal use only

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=
stringElement="8613188800002"
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”.

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

# 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

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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:

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


Confidentiality: for
~53F3.doc internal use only

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:

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


Confidentiality: for
~53F3.doc internal use only

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:
qualityOfService={-1,1}
destinationAddress=
"0x0a 52 92 00 12 04 68 31 09 10 12"
applicationContextName=
"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"

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


Confidentiality: for
~53F3.doc internal use only

componentsPresent=-1

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={

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


Confidentiality: for
~53F3.doc internal use only

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:

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


Confidentiality: for
~53F3.doc internal use only

Input conditions as shown in the interface:

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


Confidentiality: for
~53F3.doc internal use only

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:

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


Confidentiality: for
~53F3.doc internal use only

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:
qualityOfService={-1,1}
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"
componentsPresent=-1

SCP <=============

**********************Execute Argument **************************

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


Confidentiality: for
~53F3.doc internal use only

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=
stringElement="13908882008"
methodID=
0x00 11 89 4c 02 0a 0d
InputAttribute=
[0]=
type=
global= 0
0x00 11 89 4c 02 04 15
value=
stringElement="8613188800002"
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

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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:

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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]

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


Confidentiality: for
~53F3.doc internal use only

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

input strAddress(MSISDN):[2106001]

GetAreaNumberFromMSC() wrong in IsMSRN()! # describe this number is


not MSRN or VLRNumber, that is, it cannot be matched in msctoareanumber

CASE 2:

Enter TSCSM::FEA9541() -- NumberAnalysis SIB

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

******* Enter TCommonTab::IsMSRN() ********

Input msrn is : 13900698 #describe this number is MSRN or


VLRNumber, that is, it can be matched with the response field in
msctoareanumber

input strAddress(MSISDN):[13900698]

…………………..

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.

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


Confidentiality: for
~53F3.doc internal use only

CASE 3:

Enter TSCSM::FEA9541() -- NumberAnalysis SIB

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

input strAddress(MSISDN):[2106001]

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


MSISDN

******* Enter TCommonTab::IsMSRN() ********

Input msrn is : 2106001

input strAddress(MSISDN):[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.

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


Confidentiality: for
~53F3.doc internal use only

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;

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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)

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


Confidentiality: for
~53F3.doc internal use only

Initial DP Information element name

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:

Initial DP Information element name

Service Key Value=1

Called Party Number The called number dialed by the

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


Confidentiality: for
~53F3.doc internal use only

Initial DP Information element name


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

The calling subscriber international


Calling Party Number
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

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

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.

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


Confidentiality: for
~53F3.doc internal use only

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

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


Confidentiality: for
~53F3.doc internal use only

Parameter:

Parameter value or
Operation name Information unit name
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

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


Confidentiality: for
~53F3.doc internal use only

Parameter:

Parameter value or
Operation name Information unit name
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

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


Confidentiality: for
~53F3.doc internal use only

Parameter:

Parameter value or
Operation name Information unit name
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.

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


Confidentiality: for
~53F3.doc internal use only

Figure 3-3

Parameter description:

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)

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


Confidentiality: for
~53F3.doc internal use only

Parameter:

Operation
Information unit name Parameter value or description
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).

eventTypeBCSM collectedInfo

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

AttributeTypeAndValue

Type id_oi_serviceKey (note)

Value 2

AttributeTypeAndValue

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


Confidentiality: for
~53F3.doc internal use only

Parameter:

Operation
Information unit name Parameter value or description
name

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

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


Confidentiality: for
~53F3.doc internal use only

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:

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

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.

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


Confidentiality: for
~53F3.doc internal use only

Parameter:

Initial DP Information element name

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

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


Confidentiality: for
~53F3.doc internal use only

Initial DP Information element name


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

attributeTypeAndValue

type id_oi_locationNumber (note)

Subscriber location information: Toll area


value code with the international code(such as
Beijing: 8610)

attributeTypeAndValue

type id_oi_calledPartyNumber (note)

Access code+the number of the called


value
subscriber

methodID id_mt_checkIn (note)

inputAssertions

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


Confidentiality: for
~53F3.doc internal use only

Initial DP Information element name

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)

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


Confidentiality: for
~53F3.doc internal use only

Initial DP Information element name

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

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


Confidentiality: for
~53F3.doc internal use only

Initial DP Information element name


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)

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


Confidentiality: for
~53F3.doc internal use only

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
Information element name
BCSM

Event type BCSM DP9

1 (the calling party), 2 (the called


Leg ID
party)

Misc Call Info request

Apply Charing
Information element name
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’.

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


Confidentiality: for
~53F3.doc internal use only

Execute (the
Object
second time)

RDNSequence

AttributeTypeAndValue

Type id_oi_serviceKey (note)

Value 4

AttributeTypeAndValue

Type id_oi_calledPartyNumber (note)

Access code+the number of the


Value
called subscriber

AttributeTypeAndValue

Type id_oi_locationNumber (note)

Subscriber location information: Toll


Value area code with the international
code(such as Beijing: 8610)

AttributeTypeAndValue

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)

AttributeTypeAndValue

Type id_oi_time (note)

The accumulated duration of this


Value
call, unit: s

AttributeTypeAndValue

Type id_oi_expense (note)

Value The accumulated charge of this call,

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


Confidentiality: for
~53F3.doc internal use only

Execute (the
Object
second time)
unit: fen

MethodID id_mt_checkOut (note)

InputAssertions

Type id_oi_msisdn (note)

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:

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


Confidentiality: for
~53F3.doc internal use only

Operation
Information unit name Parameter value or description
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).

eventTypeBCSM collectedInfo

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

Currently SCP does not judge this


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

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


Confidentiality: for
~53F3.doc internal use only

Parameter:

Operation
Information unit name Parameter value or description
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

attributeTypeAndValue

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


Confidentiality: for
~53F3.doc internal use only

Parameter:

Operation
Information unit name Parameter value or description
name

Type id_oi_serviceKey (note)

Value 201

attributeTypeAndValue

Type id_oi_accountNum (note)

The 18-digit password of the rechargeable


Value
card

attributeTypeAndValue

Type id_oi_originalmsisdn (note)

The telephone number which originates the


value
recharging

AttributeTypeAndValue

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”

AttributeTypeAndValue

Type id_oi_tradetype (note)

Recharging mode
Value Its value is the same as the recharging
mode in the recharge bill

AttributeTypeAndValue

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


Confidentiality: for
~53F3.doc internal use only

Parameter:

Operation
Information unit name Parameter value or description
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

Type id_oi_msisdn (note)

Value The recharged telephone number

Execute Result
methodID id_mt_ChargeOtherLong (note)
(the first time)

outputAssertions

type id_oi_accountLeft (note)

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

2006-08-30 Confidential document, for internal use only Page 100 of 203
Confidentiality: for
~53F3.doc internal use only

Parameter:

Operation
Information unit name Parameter value or description
name

rDNSequence

attributeTypeAndValue

type Id_oi_serviceKey (note)

value 303

attributeTypeAndValue

type id_oi_accountNum (note)

value 18 is the password of the rechargeable card

AttributeTypeAndValue

Type id_oi_originalmsisdn (note)

Number of the calling party

Value The mobile phone number is


13XXXXXXXXX; the fixed phone number is
075526540168

AttributeTypeAndValue

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”

AttributeTypeAndValue

Type id_oi_tradetype (note)

Value Recharging mode

2006-08-30 Confidential document, for internal use only Page 101 of 203
Confidentiality: for
~53F3.doc internal use only

Parameter:

Operation
Information unit name Parameter value or description
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

type id_oi_accountLeft (note)

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

2006-08-30 Confidential document, for internal use only Page 102 of 203
Confidentiality: for
~53F3.doc internal use only

Parameter:

Operation
Information unit name Parameter value or description
name

Currently it is “0”

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

attributeTypeAndValue

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

2006-08-30 Confidential document, for internal use only Page 103 of 203
Confidentiality: for
~53F3.doc internal use only

Parameter:

Operation
Information unit name Parameter value or description
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

2006-08-30 Confidential document, for internal use only Page 104 of 203
Confidentiality: for
~53F3.doc internal use only

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.

2006-08-30 Confidential document, for internal use only Page 105 of 203
Confidentiality: for
~53F3.doc internal use only

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)
Calling Party Number
1063601234(Domestic number)

01063601234(unknown number/Domestic number):


According to the regulations of the Ministry of

2006-08-30 Confidential document, for internal use only Page 106 of 203
Confidentiality: for
~53F3.doc internal use only

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)

Or long number: 008613903000002 (unknown


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

2006-08-30 Confidential document, for internal use only Page 107 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 108 of 203
Confidentiality: for
~53F3.doc internal use only

Parameter:

Operation name Information unit name Parameter value or description


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)

Or long number: 13903000002 (unknown


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

2006-08-30 Confidential document, for internal use only Page 109 of 203
Confidentiality: for
~53F3.doc internal use only

Parameter:

Operation name Information unit name Parameter value or description


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

2006-08-30 Confidential document, for internal use only Page 110 of 203
Confidentiality: for
~53F3.doc internal use only

3.4.3 Calls inside the Network are Forwarded Unconditionally into the
Network

SSP
generates
the CFW bill

SSP
generates
the MTC bill

2006-08-30 Confidential document, for internal use only Page 111 of 203
Confidentiality: for
~53F3.doc internal use only

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.

2006-08-30 Confidential document, for internal use only Page 112 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 113 of 203
Confidentiality: for
~53F3.doc internal use only

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.

2006-08-30 Confidential document, for internal use only Page 114 of 203
Confidentiality: for
~53F3.doc internal use only

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;

2006-08-30 Confidential document, for internal use only Page 115 of 203
Confidentiality: for
~53F3.doc internal use only

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.

2006-08-30 Confidential document, for internal use only Page 116 of 203
Confidentiality: for
~53F3.doc internal use only

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]

2006-08-30 Confidential document, for internal use only Page 117 of 203
Confidentiality: for
~53F3.doc internal use only

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;

2006-08-30 Confidential document, for internal use only Page 118 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 119 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 120 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 121 of 203
Confidentiality: for
~53F3.doc internal use only

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):

2006-08-30 Confidential document, for internal use only Page 122 of 203
Confidentiality: for
~53F3.doc internal use only

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)

2006-08-30 Confidential document, for internal use only Page 123 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 124 of 203
Confidentiality: for
~53F3.doc internal use only

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.

2006-08-30 Confidential document, for internal use only Page 125 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 126 of 203
Confidentiality: for
~53F3.doc internal use only

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,

2006-08-30 Confidential document, for internal use only Page 127 of 203
Confidentiality: for
~53F3.doc internal use only

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.

2006-08-30 Confidential document, for internal use only Page 128 of 203
Confidentiality: for
~53F3.doc internal use only

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_continue2 tc_invoke (invokeID=32) AT_CAP ->

| tc_continue2 tc_result_l (invokeID=32) IDP_CAP <-

| tc_continue2 tc_invoke (invokeID=4) AT_CAP ->

| tc_continue2 tc_result_l (invokeID=1) 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 <-

| tc_continue2 tc_invoke (invokeID=4) AT_CAP ->

| tc_continue2 tc_result_l (invokeID=4) IDP_CAP <-

| tc_continue2 tc_invoke (invokeID=5) AT_CAP ->

| tc_continue2 tc_result_l (invokeID=5) IDP_CAP <-

……

2006-08-30 Confidential document, for internal use only Page 129 of 203
Confidentiality: for
~53F3.doc internal use only

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)

tcapComponentID=21 tc_l_cancel (dialogueID=13849, invokeID=2)

tcapComponentID=21 tc_l_cancel (dialogueID=13849, invokeID=3)

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:

2006-08-30 Confidential document, for internal use only Page 130 of 203
Confidentiality: for
~53F3.doc internal use only

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]

2006-08-30 Confidential document, for internal use only Page 131 of 203
Confidentiality: for
~53F3.doc internal use only

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;

2006-08-30 Confidential document, for internal use only Page 132 of 203
Confidentiality: for
~53F3.doc internal use only

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.

2006-08-30 Confidential document, for internal use only Page 133 of 203
Confidentiality: for
~53F3.doc internal use only

[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

2006-08-30 Confidential document, for internal use only Page 134 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 135 of 203
Confidentiality: for
~53F3.doc internal use only

“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]

2006-08-30 Confidential document, for internal use only Page 136 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 137 of 203
Confidentiality: for
~53F3.doc internal use only

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.

2006-08-30 Confidential document, for internal use only Page 138 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 139 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 140 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 141 of 203
Confidentiality: for
~53F3.doc internal use only

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:

2006-08-30 Confidential document, for internal use only Page 142 of 203
Confidentiality: for
~53F3.doc internal use only

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.

2006-08-30 Confidential document, for internal use only Page 143 of 203
Confidentiality: for
~53F3.doc internal use only

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

Parameter description:

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

2006-08-30 Confidential document, for internal use only Page 144 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 145 of 203
Confidentiality: for
~53F3.doc internal use only

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
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 international number (the code is 4);

2006-08-30 Confidential document, for internal use only Page 146 of 203
Confidentiality: for
~53F3.doc internal use only

the address information is 1234567. Since the address information contains an even
number of entries, the encoding scheme is 0010 (namely 2). Then:

GT code’s content is: 04006204214365

GTLength (indicating Octet’s ByteLength): 7


z Instance 3
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 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
number of entries, the encoding scheme is 0001 (namely 1). Then:

GT code’s content is: 0400510334127609

GTLength (indicating Octet’s ByteLength): 8

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

1 Odd/ Nature of address indicator


even

2 NI Numbering plan Ind. Address presentation Screening


restricted indicator

3 2nd address signal 1st address signal

.
.

n Filler (if necessary) nth address signal

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

2006-08-30 Confidential document, for internal use only Page 147 of 203
Confidentiality: for
~53F3.doc internal use only

1 the number of address signals is an odd one

b) Nature of address indicator

0000000 spare

0000001 subscriber number (national use)

0000010 unknown (national use)

0000011 national (significant) number (national use)

0000100 international number

0 0 0 0 1 0 1⎫

to ⎬ spare
1 1 0 1 1 1 1 ⎪⎭

1110000⎫

to ⎬ reserved for national use
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

2006-08-30 Confidential document, for internal use only Page 148 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 149 of 203
Confidentiality: for
~53F3.doc internal use only

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

3 2nd address signal 1st address signal

.
.

n Filler (if necessary) nth address signal

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

2 Odd/ Nature of address indicator


even

3 NI ind. Numbering plan Ind. Address presentation Screening


restricted Ind.

4 2nd address signal 1st address signal

n Filler (if necessary) nth address signal

Figure 3/Q.763 – Generic number parameter field

2006-08-30 Confidential document, for internal use only Page 150 of 203
Confidentiality: for
~53F3.doc internal use only

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⎫

to ⎬ reserved for national use
1 1 1 1 1 1 1 0 ⎪⎭

11111111 reserved for expansion

c) Nature of address indicator

0000000 spare

0000001 subscriber number (national use)

0000010 unknown (national use)

0000011 national (significant) number

2006-08-30 Confidential document, for internal use only Page 151 of 203
Confidentiality: for
~53F3.doc internal use only

0000100 international number

0 0 0 0 1 0 1⎫

to ⎬ spare
1 1 0 1 1 1 1 ⎪⎭

1110000⎫

to ⎬ reserved for national use
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

NOTE – For each supplementary service the relevant codes and possible default
settings are described in the supplementary service Recommendations
(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

2006-08-30 Confidential document, for internal use only Page 152 of 203
Confidentiality: for
~53F3.doc internal use only

NOTE – For each supplementary service the relevant codes and possible default
settings are described in the supplementary service Recommendations
(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
restricted indicator

3 2nd address signal 1st address signal

n Filler (if necessary) nth address signal

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

2006-08-30 Confidential document, for internal use only Page 153 of 203
Confidentiality: for
~53F3.doc internal use only

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.

2006-08-30 Confidential document, for internal use only Page 154 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 155 of 203
Confidentiality: for
~53F3.doc internal use only

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


+--------------------------------------------------------+

2006-08-30 Confidential document, for internal use only Page 156 of 203
Confidentiality: for
~53F3.doc internal use only

│ 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

2006-08-30 Confidential document, for internal use only Page 157 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 158 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 159 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 160 of 203
Confidentiality: for
~53F3.doc internal use only

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 {

2006-08-30 Confidential document, for internal use only Page 161 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 162 of 203
Confidentiality: for
~53F3.doc internal use only

ExecuteResult ::= SET {


method-id [1] Object Identifier,
output-assertions [2] SEQUENCE OF SEQUENCE{

type AttributeType,

value AttributeValue

}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,

value AttributeValue

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:

2006-08-30 Confidential document, for internal use only Page 163 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 164 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 165 of 203
Confidentiality: for
~53F3.doc internal use only

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

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

2006-08-30 Confidential document, for internal use only Page 166 of 203
Confidentiality: for
~53F3.doc internal use only

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

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

2006-08-30 Confidential document, for internal use only Page 167 of 203
Confidentiality: for
~53F3.doc internal use only

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
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
3 11 3 VPNV6.1 Demand
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,
3 40 3 VPNV6.1 Demand
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

2006-08-30 Confidential document, for internal use only Page 168 of 203
Confidentiality: for
~53F3.doc internal use only

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

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

2006-08-30 Confidential document, for internal use only Page 169 of 203
Confidentiality: for
~53F3.doc internal use only

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

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

2006-08-30 Confidential document, for internal use only Page 170 of 203
Confidentiality: for
~53F3.doc internal use only

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

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

2006-08-30 Confidential document, for internal use only Page 171 of 203
Confidentiality: for
~53F3.doc internal use only

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
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);

3, id_oi_roam: the roaming


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)
called-party mobile phone

2006-08-30 Confidential document, for internal use only Page 172 of 203
Confidentiality: for
~53F3.doc internal use only

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
number;

2, id_oi_roam: the roaming


location of the calling party
(such as 755);

3, id_oi_roam: the roaming


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

Lists to be received:

2006-08-30 Confidential document, for internal use only Page 173 of 203
Confidentiality: for
~53F3.doc internal use only

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

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;

Lists to be received:

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
calling-party mobile phone

2006-08-30 Confidential document, for internal use only Page 174 of 203
Confidentiality: for
~53F3.doc internal use only

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
number;

Lists to be received:

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
Lists to be sent: Party Free
Phone Service
1, id_oi_msisdn: the
6 30 6 SPL Signaling
calling-party mobile phone
Specification
number;
(draft to be
Lists to be received: reviewed)

1, 0: fail; 1: succeed

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;

Lists to be received:

1, id_oi_mspinnumber: the call


password;

2006-08-30 Confidential document, for internal use only Page 175 of 203
Confidentiality: for
~53F3.doc internal use only

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

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)

Lists to be received:

1, 0: fail; 1: succeed

User suspends the service


update table data processing:
Calling/Called
Lists to be sent: Party Free
Phone Service
1, id_oi_msisdn: the
6 33 6 SPL Signaling
calling-party mobile phone
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
6 34 6 SPL Signaling
Lists to be sent:
Specification
1, id_oi_mspinnumber: the (draft to be
password entered by the user; reviewed)

2006-08-30 Confidential document, for internal use only Page 176 of 203
Confidentiality: for
~53F3.doc internal use only

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

2, id_oi_msisdn: the
called-party mobile phone
number

Lists to be received:

1, 0: fail; 1: succeed

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
Lists to be received:
reviewed)
1, 0: fail; 1: succeed

Select the incomding number


set by the user: Lists to be
sent:

1, id_oi_msisdn: the
calling-party mobile phone
number Calling/Called
Party Free
Lists to be received:
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;

2006-08-30 Confidential document, for internal use only Page 177 of 203
Confidentiality: for
~53F3.doc internal use only

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

.
th
10, id_oi_msisdn: the 10
number allowed to be dialed
in;

11, 0: fail; 1: succeed

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:

1, id_oi_msisdn: the
calling-party mobile phone
number

Lists to be received:
Calling/Called
st
1, id_oi_msisdn: the
Party1 Free
number allowed to be dialed Phone Service
6 37 6 SPL in; Signaling
2, id_oi_msisdn: the 2
nd Specification
number allowed to be dialed (draft to be
in; reviewed)

.
th
30, id_oi_msisdn: the 30
number allowed to be dialed
in;

2006-08-30 Confidential document, for internal use only Page 178 of 203
Confidentiality: for
~53F3.doc internal use only

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

31, 0: fail; 1: succeed

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:

1, id_oi_msisdn: the
called-party mobile phone
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
3, id_oi_authorizetype: 1:
(draft to be
authenticate the calling
reviewed)
party;2: authenticate the
called party;3: authenticate
the calling/called party at the
same time.

Lists to be received:

1, 0: fail; 1: the number can be


dialed in; 2: password
authentication is required

2006-08-30 Confidential document, for internal use only Page 179 of 203
Confidentiality: for
~53F3.doc internal use only

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)

2006-08-30 Confidential document, for internal use only Page 180 of 203
Confidentiality: for
~53F3.doc internal use only

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

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

2006-08-30 Confidential document, for internal use only Page 181 of 203
Confidentiality: for
~53F3.doc internal use only

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

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
144 2 144 Operationid=1101
message

Forward the
144 3 144 Operationid=1102
message

Forward the
144 4 144 Operationid=1103
message

Forward the
144 5 144 Operationid=1104
message

UAC WIN V200R002


Iuser acquires the
172 1 172 UACV1.1D100
password
Software Demand

2006-08-30 Confidential document, for internal use only Page 182 of 203
Confidentiality: for
~53F3.doc internal use only

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
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
201 Rechargeable Card
2, 301, UC2
(Home 47 Modify the black list Service Signaling
end) Flow Specification
(V2.0)

2006-08-30 Confidential document, for internal use only Page 183 of 203
Confidentiality: for
~53F3.doc internal use only

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

Mobile
201 Rechargeable Card
2, 301, UC2 Query the
(Home 48 Service Signaling
rechargeable card
end) Flow Specification
(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

2006-08-30 Confidential document, for internal use only Page 184 of 203
Confidentiality: for
~53F3.doc internal use only

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

2006-08-30 Confidential document, for internal use only Page 185 of 203
Confidentiality: for
~53F3.doc internal use only

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

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)

1, 2 22 1, 2 UA (Under development)

1, 2 23 1, 2 UA (Under development)

1, 2 24 1, 2 UA (Under development)

1, 2 25 1, 2 UA (Under development)

1, 2 26 1, 2 UA (Under development)

1, 2 27 1, 2 UA (Under development)

1, 2 28 1, 2 UA (Under development)

1, 2 29 1, 2 UA (Under development)

1, 2 30 1, 2 UA (Under development)

128 31 1, 2 UA (Under development)

128 32 1, 2 UA (Under development)

2006-08-30 Confidential document, for internal use only Page 186 of 203
Confidentiality: for
~53F3.doc internal use only

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

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),

2006-08-30 Confidential document, for internal use only Page 187 of 203
Confidentiality: for
~53F3.doc internal use only

ID NO.
(DECIMAL FIELD-NAME Field type Meaning Service key
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

2006-08-30 Confidential document, for internal use only Page 188 of 203
Confidentiality: for
~53F3.doc internal use only

ID NO.
(DECIMAL FIELD-NAME Field type Meaning Service key
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

2006-08-30 Confidential document, for internal use only Page 189 of 203
Confidentiality: for
~53F3.doc internal use only

ID NO.
(DECIMAL FIELD-NAME Field type Meaning Service key
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

Common account funds


62 applicationType CharType 2, 4, 1005
application type

Common account funds


63 logoutAmount IntegerType application logout 2, 4, 1005
amount

Common account funds


application
64 identificationNo IntegerType 2, 4, 1005
authentication
transaction number

2006-08-30 Confidential document, for internal use only Page 190 of 203
Confidentiality: for
~53F3.doc internal use only

ID NO.
(DECIMAL FIELD-NAME Field type Meaning Service key
SYSTEM)

Common account funds


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
calling/called party at the
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

2006-08-30 Confidential document, for internal use only Page 191 of 203
Confidentiality: for
~53F3.doc internal use only

ID NO.
(DECIMAL FIELD-NAME Field type Meaning Service key
SYSTEM)
dialed by the subscriber

75 SplNumber1 CalledPartyNumType Incoming call number 1 6

76 SplNumber2 CalledPartyNumType Incoming call number 2 6

77 SplNumber3 CalledPartyNumType Incoming call number 3 6

78 SplNumber4 CalledPartyNumType Incoming call number 4 6

79 SplNumber5 CalledPartyNumType Incoming call number 5 6

80 SplNumber6 CalledPartyNumType Incoming call number 6 6

81 SplNumber7 CalledPartyNumType Incoming call number 7 6

82 SplNumber8 CalledPartyNumType Incoming call number 8 6

83 SplNumber9 CalledPartyNumType Incoming call number 9 6

84 SplNumber10 CalledPartyNumType Incoming call number 10 6

85 SplNumber11 CalledPartyNumType Incoming call number 11 6

86 SplNumber12 CalledPartyNumType Incoming call number 12 6

87 SplNumber13 CalledPartyNumType Incoming call number 13 6

88 SplNumber14 CalledPartyNumType Incoming call number 14 6

89 SplNumber15 CalledPartyNumType Incoming call number 15 6

90 SplNumber16 CalledPartyNumType Incoming call number 16 6

91 SplNumber17 CalledPartyNumType Incoming call number 17 6

92 SplNumber18 CalledPartyNumType Incoming call number 18 6

93 SplNumber19 CalledPartyNumType Incoming call number 19 6

94 SplNumber20 CalledPartyNumType Incoming call number 20 6

95 SplNumber21 CalledPartyNumType Incoming call number 21 6

96 SplNumber22 CalledPartyNumType Incoming call number 22 6

97 SplNumber23 CalledPartyNumType Incoming call number 23 6

2006-08-30 Confidential document, for internal use only Page 192 of 203
Confidentiality: for
~53F3.doc internal use only

ID NO.
(DECIMAL FIELD-NAME Field type Meaning Service key
SYSTEM)

98 SplNumber24 CalledPartyNumType Incoming call number 24 6

99 SplNumber25 CalledPartyNumType Incoming call number 25 6

100 SplNumber26 CalledPartyNumType Incoming call number 26 6

101 SplNumber27 CalledPartyNumType Incoming call number 27 6

102 SplNumber28 CalledPartyNumType Incoming call number 28 6

103 SplNumber29 CalledPartyNumType Incoming call number 29 6

104 SplNumber30 CalledPartyNumType Incoming call number 30 6

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

2006-08-30 Confidential document, for internal use only Page 193 of 203
Confidentiality: for
~53F3.doc internal use only

ID NO.
(DECIMAL FIELD-NAME Field type Meaning Service key
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

For the first charging


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

For the first charging


84 UsedPointAmt IntegerType 1111
request of the previous

2006-08-30 Confidential document, for internal use only Page 194 of 203
Confidentiality: for
~53F3.doc internal use only

ID NO.
(DECIMAL FIELD-NAME Field type Meaning Service key
SYSTEM)
free points, it should be 0

For the first charging


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

2006-08-30 Confidential document, for internal use only Page 195 of 203
Confidentiality: for
~53F3.doc internal use only

ID NO.
(DECIMAL FIELD-NAME Field type Meaning Service key
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

2006-08-30 Confidential document, for internal use only Page 196 of 203
Confidentiality: for
~53F3.doc internal use only

ID NO.
(DECIMAL FIELD-NAME Field type Meaning Service key
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


21 String36Type 4,1216
SISDN party

RSDPCalledPar the number of the called


30 String36Type 4,1216
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


37 IntegerType 4,1216
Adm administrator

CRSDPInBlack Whether it has entered


38 IntegerType 4,1216
List the black list or not

CRSDPLocation
39 String36Type The calling location code 4,1216
Number

40 CRSDPTime IntegerType Call duration 4,1216

2006-08-30 Confidential document, for internal use only Page 197 of 203
Confidentiality: for
~53F3.doc internal use only

ID NO.
(DECIMAL FIELD-NAME Field type Meaning Service key
SYSTEM)

CRSDPPayAcc Common account bound


41 String36Type 4,1216
ount by the user

CRSDPPayAcc
42 String36Type Common account type 4,1216
ountType

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