Professional Documents
Culture Documents
WIN Products - Topic On The Analysis of The Signaling V1.0-20050401-B
WIN Products - Topic On The Analysis of The Signaling V1.0-20050401-B
WIN Products - Topic On The Analysis of The Signaling V1.0-20050401-B
Revision Record
Date Revision version Description Author
Table of Contents
Preface............................................................................................................................................... 2
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
Abstract: This document introduces the basic signaling of WIN products and describes fault
analysis.
List of Abbreviations:
List of References:
Preface
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 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
First we will have a look at the location of the MIN in the entire signaling system:
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.
In this section, you should concentrate on the definition of addressing. Only when the
addressing configuration is correctly set can the signaling link normally implement
end-to-end transmission.
At the MTP layer, addressing between two adjacent points is provided. That is to say,
through the original signaling point address (OPC) and the destination signaling point
address (DPC), signalings can be transmitted between two adjacent points. Just as we
send a letter from Guangzhou to Beijing, the sender is only concerned about the
destination Beijing, regardless of how this letter is posted, by air, by train or by bus, or
whether it is transferred in Changsha or in Wuhan. It is for the post office to select a
quick, safe and economical way/path to realize it. Similarly with many signalings
irrelevant to circuits, such as IDP messages, it suffices to ensure that they can be
correctly transmitted from MSC/SSP to the landing point SCP. It is different from
signalings indicating circuit actions in ISUP. GT addressing is exported from SCCP.
Besides, a sub-system number (SSN) is imported at the SCCP layer and used to
identify each SCCP user at one node. When the SCCP message is transmitted to the
destination SCCP, SCCP must obtain the SSN of this message before it can send it to
the user. For the SSN of the IN part, except the CAP SSN used in interaction between
SSP and SCP, SCP needs to send ATI to HLR, so it involves the SSN of HLR; the SCP
of some service flows need to simulate MSC in order to send SRI messages to HLR,
so it involves the SSN of MSC; service invoke notifications are added in the
specification so that MSC can report to SCP on the supplementary service invoke
information (currently this is not used in the existing network), so the SSN of MSC is
involved here.
Those to be configured at the layer are related to signaling channels. So when you
discover signaling transmission is blocked, you should first of all check if the data at
this layer are correctly configured.
We will not describe in detail the specific signaling knowledge at the SCCP layer. Next
the differences between GT addressing and DPC addressing as described below will
help us understand the definition of addressing.
DPC Addressing:
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:
When the message reaches point B and finds out MTP’s DPC is itself, then B sends
the message to SCCP. After SCCP translates GT, it finds out DPC is not itself, so it
rewrites MTP’s DPC and sends the message to the following node. The format of the
message to be sent may be:
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.
According to the transmission direction, for request primitives, the upper layer sends
request while the lower layer transmits messages outward; for indication primitives,
the lower layer transmits the opposite-end messages to the upper lower for handling.
According to their functions, primitives can be divided into component primitives and
dialogue primitives. The former are used in the user-layer data while the latter are
used to indicate the start, continue, end and abort of dialogues. Component primitives
need to be carried by dialogue primitives but the latter can exist independently, such
as tc_u_abort.
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
0, 1 2 Length 00 5C
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
07 04 00 00 01 00 1D 03 00 00
27-38 12 Application context name 00 00
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
IDP = {0x04,0x00,0x00,0x01,0x00,0x32,0x01};
ARI = {0x04,0x00,0x00,0x01,0x00,0x34,0x01};
Execute = {0x00,0x11,0x89,0x4C,0x02,0x03,0x03};
II. tc_continue
Here we need to make sure if the source address (SCP address) of tc_continue1 is
correct, namely whether it is consistent with tc_begin. If it is not consistent, there may
exist some problems.
III. tc_end
It is used to end a dialogue. We should note that a tc_end can carry the component
primitive or be sent alone. By observing the value of parameter componentPresent in
the signaling, we can view whether it carries the component primitive. If not, a dialogue
can be terminated after this message is received. Otherwise we need to wait for the
component primitive. But how can we judge whether it carries the component or not
easily?
00 39 04 00 00 70 38 FF 1C 00 00 70 38 07 00 11
89 4C 02 03 03 00 00 00 00 00 FF 11 89 4C 02 03
03 00 00 00 00 00 00 70 38 FF 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 FF
From the above code stream we can easily find the application context. Starting from
07 there is a 12 Byte, followed by a Byte’s parameter componentPresent. When its
value is 0xFF, it means it is necessary to carry the component; when the value is 0, it is
not necessary.
In addition, when one tc_end is received, do not rush to conclude which dialog has
ended, for after a call is triggered, many dialogues are involved at the service layer
(such as INAP Execute dialogue and MAP ATI dialogue). We should make clear the
dialogue number and confirm the dialogue that ends (Be sure to keep in mind that for
other dialogue end or abort messages, this method also works).
IV. tc_u_abort
Normally when this message is received, it means some exceptions occur during the
dialogue. We can try to infer the cause of the dialogue termination through the cause
value of dialogue abort.
How can we obtain the cause value (abortReason) through the code dream?
00 38 05 00 00 71 40 FF 01 00 00 71 40 01 FF 00
00 00 00 00 00 00 00 00 00 00 FF 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
Just keep in mind the Byte behind the dialogue number is abortReason.
The SCP of this message can be received or sent. The common abort reasons are as
follow:
NoReasonGiven 1
ApplicationTimerExpired 2
NotAllowedProcedures 3
AbnormalProcessing 4
Congestion 5
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
We can also analyze the reason according to the specific reason values:
87654321
00000111 unqualified
00001111
to spare
11111111
You can refer to ITU-T Q714 for interpretation of each specific 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).
I. tc_invoke
It is the most common component primitive carrying CAP, INAP, MAP and other
messages. From it we can learn the operation type (4 types), invokeID, operation ID
and specific operation content of the operation carried by it.
What is more important, we can learn the message ID of the application layer this
message corresponds to according to the operation ID, namely what operation it is.
Note that different application-layer protocols may correspond to the same ID, for
example, the operation IDs of CAP’s releaseCall and MAP’s SendRoutingInfo are both
22. We should also combine tc_begin in order to accurately figure out the messageID.
Of course if we are sure about a dialogue comes from a certain entity, it will be easy to
judge. For example, if the received tc_invoke has the same dialogue number as IDP,
then it must come from MSC/SSP, so this message surely is CAP ReleaseCall; if it is
transmitted to HLR, then it must be MAP SRI.
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.
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.
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
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,
CAP is the most important part in MIN signaling. We will not describe the theory of
each signaling in this chapter but we will talk about the functions of common signalings
and some parameters. Through this section, you will be able to easily understand the
signaling flow in the service specification and how a call process is constituted.
CAP is based on the INAP Specification of ITU-T and it is the simplified version of
INAP. If you want to have a further understanding of the intelligent network, you are
advised to reach the INAP Specification (ITU-T Q12xx series).
I. Reference specifications
Originating network
Incoming call
Roaming party
MS originated call -
The forwarded outgoing calling party (or
party the forwarded party)
Query the network Access the network
From the figure above, we should understand why SCP is categorized into the home
network.
We can see SCP, like HLR belongs to the home network. What is the advantage of this?
We should know MS’s location is not fixed but HLR can ensure that others can reach it
no matter where it goes; wherever this MS originates the call, it can get its basic
information. For the same reason, SCP provides the function that wherever MS moves,
it can always enjoy the same service (except some special cooperation for part of the
end offices); meanwhile its account and service attributes will not be affected by the
change of locations. This is the basic advantage about SCP that it can provide
services in a centralized way.
In this figure we also can see it is possibly necessary to interact with SCP on the CAP
interface so as to query and access the network.
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.
O_Abandon
Collected_Info DP2
Route_Select_ DP4
Failure
DP5
Analyse, Routing O_Busy
DP50
O_Not_Reachable
O_Answer DP7
DP9 O_Active
O_Disconnect
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.
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.
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
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
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.
gsmSCF Address: the gsmSCF address the user should access when he triggers the
CAMEL service;
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.
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.
When a CAMEL subscriber originates a call, the MSC accessed by the CAMEL
subscriber obtain from VLR the CAMEL subscription information (O-CSI) of the calling
party and O-BSCM will be set up in MSC. Then a control relationship will be set up
between MSC/gsmSSF and gsmSCF.
gsmSCF
MSC
gsmSSF/CCF
O(A-B) T(A-B)
1) When the subscriber has the location updated, HLR will insert the subscriber data
into VLR. O-CSI will also be inserted into VLR as part of the subscriber
information.
2) MS originates the call; BSS originates service request to MSC.
3) MSC queries the subscriber information in VLR. When VLR receives this request,
MSC queries the subscriber information and tries to match all the O-CSI with DP
rules. Once O-CSI which satisfies the DP rules is found, it can be confirmed that
the call originated by this subscriber needs CAMEL support. Then MSC/SSP will
trigger the CAMEL service according to the selected O-CSI information.
4) VLR returns to MSC the O-CSI which triggered this call. The O-CSI contains the
service key, SCF address and other key information.
5) MSC requests instructions from gsmSSF with the internal interface.
6) According to the gsmSCF address in O-CSI, gsmSSF originates service request
to this gsmSCF and the service key is contained in InitialDP.
7) According to the service key of InitialDP, gsmSCF implements relevant service
logic program, generates the instances of the service logic program and instructs
the next action of gsmSSF according to the requirements of the service logic.
Normally gsmSSF and gsmSCF set up and maintain a certain relationship
between them (usually the control relationship). Through this relationship,
gsmSSF reports to gsmSCF on the call handling state and receives the
instruction from gsmSCF to maintain, set up or disassemble a call.
8) MSC reports to gsmSSF on the MSC state or events through the internal
interface. The SSF state machine maintained by gsmSSF receives instructions
from gsmSCF and converts the instructions related to call handling into internal
call control instructions before sending them to MSC, such as Int_RealeaseCall,
Int_Continue and Int_Connect,Int_Error.
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.
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.
As we know each service logic is identified by one unique interger – Service key (for
example, PPS’s Service key is 1; VPMN’s Service key is 3), different service logics
have different functions. If you hope MS can correctly use the service function, it is
necessary to correctly report the Service key.
When we discover a phone cannot be put through during debugging, we trace the
signaling and find that after MSC/SSP reports to IDP, it directly receives the tc_u_error
released by SCP, the error code is missingCustomerRecord (value: 6), it is very likely
that it is due to a service trigger error; so we need to confirm if the service key
submitted by IDP is what we expected; if the reported service key is the same as the
one we loaded; if this service has been activated.
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.
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
8 7 6 5 4 3 2 1
.
.
0000000 spare
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.
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.
8 7 6 5 4 3 2 1
.
.
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.
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.
vlr_number: the number of VLR which originates the call (such as 8613900430). This
parameter is mainly used to fill in the VLRNumber of the location accessed by the
subscriber in the called flow. Then SCP will analyze this number and reach the
corresponding area code as the area code of the location accessed by the called
subscriber.
CellID: this parameter is very useful when different charging discounts or statistics are
conducted. For the calling flow, it has been clarified in the service specification that this
parameter must be reported; for the called flow, when the end office does not report,
SCP will send ATI message to HLR to acquire it.
-eventTypeBCSM:
This parameter enables us to easily judge whether it is the calling flow or the called
flow. When it is 12, then it is the called flow (MT); when it is 2 and when the original
called party ID and Redirecting party ID do not exist, it surely is the calling flow (MO);
when it is 2 and the above two parameters exist, it must be the forwarded MF flow.
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.
From the above-mentioned basic call state model (BCSM), we learn that each call is
made up of a series of states. The detection point (DP) is set between states, which
can also be understood as the break point during the call. MSC/SSP meets DP only
because some call events have taken place. On different call branching occasions, the
service only needs to know part of the DPs, so it should instruct MSC/SSP to pay
attention to which DPs.
SCP delivers to MSC/SSP just through this operation. During a call, it is permitted to
deliver RRBE for multi-times. Multiple DPs can be configured for each RRBE. The
calling flow only allows the configuration of DP events defined by this state model.
Keep in mind that for the calling flow, there is only one Disconnect event, but we know
the service flows for the calling onhook and the called onhook can be completely
different (for example, if the called party hangs up, play announcement to make the
calling party continue input another called party number and SCP will reconnect; but if
the calling party hangs up, the call cannot but be released). Into RRBE is imported the
parameter legID. When legID=1, it refers to the calling party; when legID=2, it refers to
the called party. It is necessary to report this parameter when the messages are
reported.
This message is usually necessary to be delivered; otherwise the service is not aware
of the events (such as abort and the called party busy) during the call setup process
and cannot correctly handle them.
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.
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).
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.
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.
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.
bit 31 24 23 22 21 16 15 0
22~23bit: Language type (00: mixed language, 01: Putonghua, 10: English, 11: local
dialect).
21~16bit: Retention
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.
Interval: the pause time gap between two repetitions of announcement playing;
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.
Since the charging point of the intelligent network is in SCP, SCP needs to know
information such as the duration. This operation is delivered by SCP to SSP
requesting SSP to prepare for charging; before SCP delivers to AC, it is necessary to
conduct calculation according to the home location and access location of the calling
subscriber so that relevant charging information can be delivered to SSP through AC.
Once it is detected that the called subscriber replies, collection of the charging
information can begin.
Major parameters:
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.
SSP submits to SCP the charging report, which is the reference for SCP to conduct
charging.
Major parameters:
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.
This operation is used to instruct MSC/SSP to insert the sorting ID into the charging
record. Some services were originally charged at the end office but now they are
charged in SCP where bills are generated. These bills generated by SCP will be used
for settlement. But then the end office can still generate bills normally. So we need to
sort them out. This operation can complete this function, for example, the VPMN
service delivers a string “800130” to the end office as the sorting ID of the bills.
XII. Continue
This operation is delivered by SCP to SSP notifying it to continue the call suspended
just now.
When SCP does not change any parameters such as the number of the calling party,
deliver through this operation. After MSC/SSP receives it, begin to connect the call.
XIII. Connect
When the calling/called party numbers are changed, it is necessary to use this
operation to notify MSC/SSP to conduct corresponding changes.
Major parameters:
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.
8 7 6 5 4 3 2 1
This parameter is similar to callingParytNumber but it has one more Byte “Number
qualifier indicator”. It is defined as below:
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 ⎪⎭
It is used by SSP to report on call events to SCP. Call events which are prearranged by
RRBE in advance are delivered through SCP.
It is necessary to point out that the forward events and T-Busy can be reported and
parameter Forward Pending can be set through this message in the new specification.
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.
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.
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.
Regarding MAP signaling, currently ATI and SRI are mainly used in the intelligent
network. But it has been greatly expanded in the 3G specification.
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.
MAP-U-ABORT indication Or
TC-U-ABORT indication MAP-P-ABORT indication (Note
2)MAP-OPEN confirmation (Note 3)
z ATI (AnyTimeInterrogation)
When SCF conducts service handling, it may need to know some subscriber
information, such as the subscriber state and his current location. The query operation
of MAP Phase II + AnyTimeInterrogation can satisfy this demand. SCF can use ATI
operation at any time to query the current state and location of a subscriber. During
service handling, we can consider implementing charging based on time and location.
Subscriber information that can be queried with ATI by SCF contains:
1) Subscriber State
2) LocationInformation
When HLR handles the ATI operation, if the queried subscriber information is known,
HLR will directly return the ATI response (ATIRes). If the information is unknown, HLR
can use ProvideSubscriberInfo to query relevant information in VLR.
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).
The INAP operation here refers to the Execute operation. In the GSM CAMEL
Specification, the interconnecting operation between SCPs is not defined. In the
CMCC MIN, the standard INAP Execute operation is creatively imported in which
recharge and information interaction between SCPs have been put into wide
application.
1.6.1 Background
Status quo:
1) The intelligent service subscribers become more and more;
2) The number of the SCP equipment gradually increases;
3) SCP regions are scattered;
Subscribers hope that their service characteristics will not be affected when they roam;
Typical application:
1) The rechargeable cards are centralizedly placed in several VCs. SCP should
enter any of these VCs to query the balance and validity term of a rechargeable
card. After the subscriber recharges the card, it is necessary to set this card as
invalid;
2) Prepaid subscriber A uses the mobile phone of prepaid subscriber B to report
loss but they belong to different SCPs. The call is triggered to B’s home SCPb,
which needs to notify A’s home SCPa to set this subscriber as loss-report.
How can we select a proper solution that can satisfy SCP interconnection?
1) Openness: SCPs in different locations and of different manufacturers can easily
interconnect each other. The internal change of one SCP will not affect other
SCPs;
2) Expansiveness: A SCP can be easily added to the network;
3) Fully make use of the existing network structure and resources; one method often
adopted abroad is to make use of the manufacturer’s protocol use the data
network or the special signaling network as the bearer network; in China, the
common practice is to adopt the dedicated protocol over the data network mode,
as shown in the figure below:
200 platform
Packet
switching
200 platform network 200 platform
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.
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:
RDNSequence
AttributeTypeAndValue
Value 1
AttributeTypeAndValue
InputAssertions
SpecificInput
Value 0
SpecificOutput
int4element 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.
By reading the service specification, we can learn the parameter meanings and values
of Execute during an interconnection process.
SCP <=============
object=
[0]=
type=
global= 304
0x00 11 89 4c 02 04 03
value=
int4Element=4
[1]=
type=
global= 304
0x00 11 89 4c 02 04 0e
value=
stringElement="191000000000000006"
[2]=
type=
global= 32
0x00 11 89 4c 02 04 0d
value=
stringElement="13908882008"
methodID=
0x00 11 89 4c 02 0a 0d
InputAttribute=
[0]=
type=
global= 0
0x00 11 89 4c 02 04 15
value=
stringElement="8613188800002"
SpecificInput=NOT PRESENT
..........................................................................
....
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
Parameter
Description
name
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.
#this Item is for the value of screening in genericNumber (CAN be dynamic read)
#default--0
SCREENING =0
Parameter Description
name
SCREENING The value range is [0, 4], the default value is 0. The attributes of
this parameter are defined in ITUT-Q763. Usually it uses the
default value 0, which means the transparent transmission mode
is adopted in order to comply with the requirements of the
specification. Modifying this parameter can severely affect the
normal operation of services! You are advised to consult the
technical support personnel in Huawei and finalize the modification
plan after obtaining the confirmation.
1.7.4 Configure the timeout wait time standard after SCP transmits ATI or
SRI
#this item is to set the time for the ATI or SRI to wait for the HLR's response
TimeOfWaitATIRsp = 15
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.
# each value is in the hexadecimal form; the value range is (00,00 ff,ff]
RedirectionInformation = 33,31
# support SRIMapPhase2+
# 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.
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.
In the OAM interface, user-friendly interfaces are provided so that we can do a tracing
job easily.
This function can perform printing the signaling information; the printed contents are
the parameters which have been explained.
This function can be used to trace single calls, so it has little influence on the
performance of the system.
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.
MscAddress input
Figure 2-1 Call tracing dialog box on OAM and its description
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:
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"
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={
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"
.............................................................
.......................................
Note: In the RSDP Tracing mode, only when the input conditions satisfy all the
necessary conditions, the item concerned can be traced.
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 <=============
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
..........................................................................
....
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.
% 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
printFlag=1 // input the desired tracing mode or input 2, 1: print part of the
code streams; 2: print all the code streams
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.
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.
keep seconds=10 // input how long the tracing will last, unit: s
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.
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
/ 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
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.
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:
Output: under the directory /tellin/log, the sqlx.log file will be generated; x corresponds
to the number of SCF.
Content interpretation:
===== SDF ===== after ecSelect span from memtbl(success)= (0 sec) (87 usec)
sql0.zip
Among them, sqlStatement describes the SQL statement of request. Note that
currently SCP uses the dynamic SQL, whose variable part is substituted by “?” in
sqlStatement, for example, “where ScpNo=?”, if the specific variable content is needed,
it can be printed out by using the debug document.
From “(0 sec) (87 usec)”, we can see the time to execute this SQL statement.
From “from memtbl” or from “DB”, we can tell whether the object of this database
operation is the memory table or the database.
From “success” or ”not found record” or ”error”, we can see whether the operation
result is success or not, whether the specified conditions correspond to a blank record
or whether the result is error.
Sometimes when trace the signaling, we may find the time interval between the
request and the response is a bit long by checking the time printed in the signaling,
which may lead to abnormal signaling. Then we can check if it takes too much time for
the database to execute. Through the execute time, we can directly see the time to
execute a certain SQL. But there is no unique criterion to judge if the execute time is
too long. From the past experience, the query time of the memory table is between
100~200 milliseconds; crossing 500 milliseconds may suggest some problems; but
occasional occurrence can be ignored. The query time of the database table is
normally between 1000~3000 milliseconds but it is related to the record number of
specific tables, for example, the record number of the basetab_pps table may reach
700,000/800,000 or above, maybe the query time is over 10,000 milliseconds but for
some small tables, the time may be less than 1000 milliseconds.
If you find it takes a long time to query a certain database table, how should you locate
the problem? Generally speaking, if a database table requires frequent query
operations, an index should be designed. But the index may get lost. SCP provides the
idxcheck.sh tool whose theory is to acquire the sequential scanning counts by reading
the system table of the database. This tool can calculate the difference of the
sequential searching counts before and after a period of time. When the difference is
larger than a certain value, the log will be written and alarm be sent. We can use this
tool manually to see whether the index exists or not.
Idxcheck.sh can be used to discover problems only when the query statement is
executed to this table; but dbaccess can be used manually to execute one SQL in
order to observe if the searching is conducted through the index.
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:
------
Estimated Cost: 2
sqexplain.zip
Among them, index path means this is the search based on the index.
It means the searching then is based on sequence (since the index field of this table is
hlrnumber, the areanumber-based searching must be according to the sequence).
When it is confirmed this table uses the index for searching and it takes much time to
query and if the data volume of this table is not very large, we can try to conduct an
update statistics medium to this table to change the statistic information of the system
table in order to enhance the query efficiency (Note: if the record number of this table
is large, such as on a million basis, the execution may take more time, so the
operation should be conducted during idle time).
We will carry out our discussion with the contents of the attachments below.
scfdebug0.zip hlr&msctoareanumber.zip
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.
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.
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.
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>>>
sqltype:103,sqllen:4
sqlca.sqlcode = 0 in ecSelect.
===== SDF ===== after ecSelect span from DB(success) = (0 sec) (1530 usec)
# time spent on execution
CASE1: (in fact, the value of numberAnalysisType is different, so the number analysis
function completed is different).
………………………………
findTollAreaNum:aPartyNumber[5952106001]Output:retCountryNumber[595] #
the area code of the number is ’595’, which can be obtained by searching
tollareanumber
input strAddress(MSISDN):[2106001]
input strAddress(MSISDN):[2106001]
CASE 2:
Enter FEA9541
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.
CASE 3:
findTollAreaNum:aPartyNumber[5952106001]Output:retCountryNumber[595] # the
area code of this number is ‘595’ and describe it surely is not the international
number
input strAddress(MSISDN):[2106001]
input strAddress(MSISDN):[2106001]
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];
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
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.
When operating lsmscp, you can query the version No. of each module from each
executable binary document;
z You can view the version No. of the process specified by SCP: lsmscp process
name or lsmscp – process name;
z You can view the version No. of all the SCP processes: lsmscp -v.
Instance:
% lsmscp -v
MSCP software version :
Module Name Version
=========== =======
manager WINV200R002D602
scf WINV200R002D602
scfserver WINV200R002D602
sdf WINV200R002D602
oam WINV200R002D602
nmf WINV200R002D602
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:
% lsmscp –s
Service version :
Service Name Version
============ =======
iuser.bin IUSERV2.3D111
iuser_attendant.bin IUSERV2.3D111
iuser_bank.bin IUSER_BANKV2.3D111
iuser_called.bin IUSER_CALLEDV2.3D111
iuser_calling.bin IUSER_CALLINGV2.3D111
iuser_callscreen.bin IUSER_SCREENV2.3D111
iuser_chgpwd.bin IUSER_CHGPWDV2.3D111
iuser_claimmis.bin IUSER_MMISV2.3D111
iuser_ctd.bin IUSER_CTDV2.3D111
iuser_fnfc.bin IUSER_FNFCV2.3D111
Note:
1. When you view the service version No., relevant service document should exist
under directory $TELLIN_DIR/servicerun;
2. When lsmscp is used to view the version No., since document scf process is a bit
large, the time spent on it will be long (especially in the HP environment).
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.
2) SCPa determines the charge rate of the calling subscriber according to the
location of the calling party and the called party number, converts it to call
duration and then sends RRBE, AC, FCI and Continue to MSCa/VLR/SSP.
3) After MSCa/VLR/SSP receives the Continue message, it sends the SRI message
to HLR of the called party. If the called party is a prepaid subscriber, the
subscriber information O_CSI + T_CSI and the location information of the called
party (Vlr-number) will be returned.
4) MSCa/VLR/SSP sends the IDP message to SCPb and puts the toll area code of
the location where MSCa/VLR/SSP is situated into the location number in the IDP
message and puts the called-party location information (Vlr-number) into Location
Information in the IDP message.
5) After SCPb receives the IDP message, it will first analyze the called subscriber’s
account. If the account is still valid, SCPb will determine the charge rate
according to the called-party location information obtained from IDP, convert it to
call duration and send RRBE, AC, FCI and connect to MSCa/VLR/SSP.
1) MSCa/VLR/SSP re-sends the SRI message to the HLRb of the called party. Then
the SRI message will suppress T-CSI and obtain the roaming number MSRN of
the called party.
2) MSCa/VLR/SSP conducts connection according to the roaming number MSRN of
the called party.
3) The call stops and either of the calling or the called party hangs up.
MSCa/VLR/SSP submits the charging report and the onhook event respectively
to SCPa and SCPb.
Figure 3-1
Parameter description:
IMSI
Vlr-number
Figure 3-2
Parameter:
Parameter value or
Operation name Information unit name
description
InitialDP serviceKey 1
10(common
callingPartyCategory
subscribers)
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
RequestReportBCSMEvent BCSMEvents
eventType 10
monitorMode notifyAndContinue
Parameter:
Parameter value or
Operation name Information unit name
description
legID 1
informationToSend
disconnectFromIPForbidden TRUE
Input according to
different prompts
PromptAndCollectUserInformation Note: the end symbol “#”
digitResponse
ack is converted into “OCH”
and then reported to
SCP.
PlayAnnouncement informationToSend
Parameter:
Parameter value or
Operation name Information unit name
description
inbandInfo
requestedAnnouncementComplete TRUE
SpecialzedResouceReport NULL
EventReportBCSM eventTypeBCSM 10
legID 1
miscCallInfo
messageType 1
3.1.3 Prepaid Subscriber A Uses a Common GSM Mobile Phone (or PSTN
Telephone) to Report Loss, User A’s Homed SCPa Accesses a Different SCP
from the Proximate SCPd Accessed by MSCa/VLR/SSP.
z The prepaid subscriber A uses the common GSM mobile (or PSTN telephone) to
dial 13800138000. SSP triggers the intelligent call to the default SCPd.
z The subscriber selects the language, report loss/cancel loss report according to
the prompt, input the mobile phone number you will report loss on and the
password.
z SCPd judges the AC (SCPn) the subscriber belongs to according to the mobile
phone number you will report loss on and sends Execute operation (mobile phone
number, password and loss report flag) to AC (SCPn) to report loss on this stored
value card.
z After AC(SCPn) receives the Execute operation, it will report loss on this the
stored value card. If successfully done, it will send Execute-Result (operation
success flag) to SCPd.
z After SCPd receives the Execute-Result message, it will send TC-End to end the
dialogue with AC(SCPn) and prompt operation succeeds.
Please see Figure 3-3 for the signaling flow.
Figure 3-3
Parameter description:
Parameter:
Operation
Information unit name Parameter value or description
name
InitialDP serviceKey 2
Parameter:
Operation
Information unit name Parameter value or description
name
eventTypeBCSM collectedInfo
IMSI
Execute (the
Object
first time)
RDNSequence
AttributeTypeAndValue
Value 2
AttributeTypeAndValue
Parameter:
Operation
Information unit name Parameter value or description
name
InputAssertions
SpecificInput
Value 0
Execute
Result (the MethodID id_mt_ppsclaimMissing (note)
first time)
SpecificOutput
int4element 1
SMP SCP
BOSS GMSC/SSP
IP gateway or
the toll office
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.
Subscriber A can recharge for a subscriber from province C at the home location or at
the roaming location. It is necessary for the SCP of the calling party’s home location to
be interconnected with the SCP of the home location of the subscriber from province C
so that he can recharge the home VC of the subscriber from province C.
3.2.3 Call the Non-Local PSTN Mobile Phone Subscribers of Other Networks;
the Service-Triggering SCP is not the Home SCP of the Subscriber
Call process:
1) GMSCa/SSP receives the call and triggers the service according to the access
code;
2) The toll area code of the location where MSCa/VLR/SSP is situated, the access
code + the number of the called subscriber are directly put in Location Number in
the IDP message, which will then be sent to SCPa;
3) After SCPa receives the IDP message, it will judge the subscriber account is at
SCPb and send to SCPb the Execute operation. SCPb judges the validity of the
service, account and the called party number before it returns the payment type
and the deposit.
4) SCPa sends RRBE and AC to GMSCa/SSP according to the current charge rate.
5) SCPa sends the called party number to GMSCa/SSP through the Continue
operation.
6) After GMSCa/SSP receives the Continue message, it will be connected with the
GMSC and go out of the network at the home location of the called party
according to the called party number.
7) The call is connected.
8) After the call is over, either of the calling/called party hangs up and GMSCa/SSP
submits the charging report and the loss-report event.
9) SCPa sends to SCPb the charging application operation based on the practical
call expenses used during this charging cycle. If it is for a prepaid subscriber,
SCPb will complete the actual charging operation. For group subscribers, the
monthly and daily total expenses of the group and individuals will be accumulated.
SCPa generates the bill of this call.
Parameter:
Service Key 4
IP SSP Capability
Execute (the
object
first time)
rDNSequence
attributeTypeAndValue
value 4
attributeTypeAndValue
attributeTypeAndValue
inputAssertions
Execute
Result (the methodID id_mt_checkIn (note)
first time)
outputAssertions
2-locked
specificOutput
Call permitted
Request
Report BCSM Information element name
Event
BCSM Event
Apply
Information element name
Charging
Play Tone
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.
NULL
Event Report
Information element name
BCSM
Apply Charing
Information element name
Report
Call Result
Execute (the
Object
second time)
RDNSequence
AttributeTypeAndValue
Value 4
AttributeTypeAndValue
AttributeTypeAndValue
AttributeTypeAndValue
1.
AttributeTypeAndValue
AttributeTypeAndValue
Execute (the
Object
second time)
unit: fen
InputAssertions
SpecificOutput
1
int4element (1 -Operation succeeds
2-Operation fails)
3.3.1 When the Normal Recharging Flow SCPa and SCPb of the GoTone
Subscriber are not the Same SCP, the Operation Succeeds
Figure 3-6 Normal Recharging Flow of the GoTone Subscriber (SCPa and SCPb are
not the same SCP, the result returned by Boss is success)
Parameter:
Operation
Information unit name Parameter value or description
name
InitialDP ServiceKey 2
eventTypeBCSM collectedInfo
IMSI
RequestRepor
BCSMEvents
tBCSMEvent
EventType 10
monitorMode notifyAndContinue
LegID 1
ConnectToRes
resourceAddress NULL
ource
Parameter:
Operation
Information unit name Parameter value or description
name
informationToSend
disconnectFromIPForbidden TRUE
PlayAnnounce
informationToSend
ment
InbandInfo
requestedAnnouncementComplete TRUE
SpecialzedRes
NULL
ouceReport
Execute (the
object
first time)
rDNSequence
attributeTypeAndValue
Parameter:
Operation
Information unit name Parameter value or description
name
Value 201
attributeTypeAndValue
attributeTypeAndValue
AttributeTypeAndValue
Service type
Currently it is “0”
AttributeTypeAndValue
Recharging mode
Value Its value is the same as the recharging
mode in the recharge bill
AttributeTypeAndValue
Parameter:
Operation
Information unit name Parameter value or description
name
InputAssertions
Execute Result
methodID id_mt_ChargeOtherLong (note)
(the first time)
outputAssertions
type id_oi_activeDays
specificOutput
1(
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
value 303
attributeTypeAndValue
AttributeTypeAndValue
AttributeTypeAndValue
Service type
Currently it is “0”
AttributeTypeAndValue
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
id_mt_SupplyRetrieve (note)
MethodID
inputAssertions
Execute Result
(the second methodID id_mt_SupplyRetrieve (note)
time)
outputAssertions
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”
specificOutput
Execute (the
object
third time)
rDNSequence
attributeTypeAndValue
value 303
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
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):
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
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.
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:
861063601234(International number)
Calling Party Number
1063601234(Domestic number)
2006-08-30 Confidential document, for internal use only Page 106 of 203
Confidentiality: for
~53F3.doc internal use only
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.
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:
InitialDP ServiceKey 3
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:
BearerCapability
EventTypeBCSM DP2
IMSI
CallReferenceNumber
2006-08-30 Confidential document, for internal use only Page 109 of 203
Confidentiality: for
~53F3.doc internal use only
Parameter:
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
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.
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.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.
[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.
[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.
[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]
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]
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
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”.
2. Then it involves two system tables whose records are read into the private memory
by the scf process when it is started:
locationid serial,
2006-08-30 Confidential document, for internal use only Page 123 of 203
Confidentiality: for
~53F3.doc internal use only
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)
);
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.
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
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:
……
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 <-
……
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:
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]
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.
[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]
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.
[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
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.
[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
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.
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
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.
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.
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?
netDetNotReachable NotReachableReason,
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={
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
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.
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.
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
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.
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.
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.
2006-08-30 Confidential document, for internal use only Page 143 of 203
Confidentiality: for
~53F3.doc internal use only
Chapter 5 Appendix
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
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:
0010(2) Standby
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:
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
0000101(5) to Idle
1111111(127)
Address information: Octet 3 and those behind it are the address signals. Their
formats are as below:
8 7 6 54 3 2 1 Bit
……
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:
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:
The format of the calling party number parameter field is shown in Figure 1 below.
8 7 6 5 4 3 2 1
.
.
The following codes are used in the calling party number parameter field.
a) Odd/even indicator
2006-08-30 Confidential document, for internal use only Page 147 of 203
Confidentiality: for
~53F3.doc internal use only
0000000 spare
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
0 complete
1 incomplete
0 0 0 spare
0 1 0 spare
2006-08-30 Confidential document, for internal use only Page 148 of 203
Confidentiality: for
~53F3.doc internal use only
1 1 1 spare
00 presentation allowed
01 presentation restricted
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)
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.
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
.
.
8 7 6 5 4 3 2 1
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:
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 ⎪⎭
0000000 spare
2006-08-30 Confidential document, for internal use only Page 151 of 203
Confidentiality: for
~53F3.doc internal use only
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)
00 presentation allowed
01 presentation restricted
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:
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).
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
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).
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
call diverted
Spare
Spare
unknown/not available
0100⎫
⎪
to ⎬ Spare
1 1 1 1 ⎪⎭
2006-08-30 Confidential document, for internal use only Page 154 of 203
Confidentiality: for
~53F3.doc internal use only
bits
unknown/not available
user busy
no reply
Unconditional
0 1 1 1⎫
⎪
to ⎬ Spare
1 1 1 1 ⎪⎭
5.2.6 CalledPartyBCDNumber
maxCalledPartyBCDNumberLength))
-- 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 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*
+-----------------------+-----------------------│
│ │ │ :
:
+-----------------------------------------------+
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".
2006-08-30 Confidential document, for internal use only Page 156 of 203
Confidentiality: for
~53F3.doc internal use only
5.2.7 DateAndTime
-- 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
-- The most significant day digit occupies bits 0-3 of the fourth octet, and the least
significant
-- The most significant hours digit occupies bits 0-3 of the fifth octet, and the least
significant
-- The most significant minutes digit occupies bits 0-3 of the sixth octet, and the least
-- The most significant seconds digit occupies bits 0-3 of the seventh octet, and the
least seconds
5.2.8 EventTypeBCSM
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.
netDetNotReachable NotReachableReason,
msPurged (0),
imsiDetached (1),
restrictedArea (2),
notRegistered (3)}
5.2.10 O-CSI
o-BcsmCamelTDPDataList O-BcsmCamelTDPDataList,
...,
O-BcsmCamelTDPData
--- 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
o-BcsmTriggerDetectionPoint O-BcsmTriggerDetectionPoint,
serviceKey ServiceKey,
...
collectedInfo (2),
... }
-- exception handling:
-- other value than the ones listed the receiver shall ignore the whole
-- O-BcsmCamelTDPDatasequence.
-- other value than the ones listed the receiver shall ignore the whole
-- O-BcsmCamelTDP-Criteria sequence.
O-BcsmCamelTDP-Criteria
o-BcsmTriggerDetectionPoint O-BcsmTriggerDetectionPoint,
2006-08-30 Confidential document, for internal use only Page 160 of 203
Confidentiality: for
~53F3.doc internal use only
... }
-- shall be present
... }
ISDN-AddressString
INTEGER(1..maxNumOfISDN-AddressDigits)
Ext-BasicServiceCode
forwarded (0),
notForwarded (1)}
2006-08-30 Confidential document, for internal use only Page 161 of 203
Confidentiality: for
~53F3.doc internal use only
inhibiting (0),
enabling (1)}
continueCall (0) ,
releaseCall (1) ,
...}
-- exception handling:
phase1 (0),
Definition:
type AttributeType,
value AttributeValue
}OPTIONAL,
2006-08-30 Confidential document, for internal use only Page 162 of 203
Confidentiality: for
~53F3.doc internal use only
type AttributeType,
value AttributeValue
}OPTIONAL,
specific-output [3] SpecificOutput OPTIONAL
rdnSequence RDNSequence }
type AttributeType,
value AttributeValue
2006-08-30 Confidential document, for internal use only Page 163 of 203
Confidentiality: for
~53F3.doc internal use only
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)
2006-08-30 Confidential document, for internal use only Page 164 of 203
Confidentiality: for
~53F3.doc internal use only
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
2006-08-30 Confidential document, for internal use only Page 165 of 203
Confidentiality: for
~53F3.doc internal use only
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
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
2006-08-30 Confidential document, for internal use only Page 167 of 203
Confidentiality: for
~53F3.doc internal use only
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
2006-08-30 Confidential document, for internal use only Page 168 of 203
Confidentiality: for
~53F3.doc internal use only
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
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)
2006-08-30 Confidential document, for internal use only Page 170 of 203
Confidentiality: for
~53F3.doc internal use only
Fixed Subscriber
PPIP Non-local Prepaid IP
account Service Signaling
5 14 2 , 1230 IUSER
transfer and Flow
EA cancellation Specification
(V3.0)
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
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;
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
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;
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:
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
Lists to be received:
1, 0: fail; 1: succeed
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
1, 0: fail; 1: succeed
Lists to be received:
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
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
1, 0 : fail; 1: succeed
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
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;
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
32, id_oi_callnumberlimit:
the number of incoming call
numbers allowed to be preset;
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:
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
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
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
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
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
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)
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
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
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
1 (uus service),
2 (including pps,
msisdnpinnumb igsm, iuser, uc2
17 PinType Account password
er and ppip
service) , 4, 100,
201, 301, 1001
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)
Number of the
2 (uc2 service)
22 sequence String20Type rechargeable card,
201, 301
namely its serial No.
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
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)
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)
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
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)
MultiServiceFla
69 string36 Integrated service flag 1111
g
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}
RevertShortMes
76 IntegerType Revert free SMS entries 1111
sage
Common account
allocation scheme: 0:
allocate according to the
80 CaAllocateType IntegerType 1111
required amount; 1~n:
allocate according to the
various slopes provided
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
Template multi-service
88 GrpMultiSrvFlag String36 1111
function flag
2: fixed telephone
recharge
3: non-prepaid mobile
phone recharge
4: manual recharge
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
f: intelligent user
recharge (unified
recharge fow, reserved)
Brand of the
90 CardType IntegerType 2, 1201
rechargeable card
Recharge discount
support flag: 0:
RechargeGiftFla
95 charType recharge discount is not 1111
g
supported; 1: recharge
discount is supported.
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)
RSDPAccountL
15 IntegerType Amount 4,1216
eft
RSDPPinNumb
17 String36Type Password of the account 4,1216
er
RSDPPayingTy
31 IntegerType Charging mode 4,1216
pe
RSDPAccountT
36 IntegerType Account type 4,1216
ype
CRSDPLocation
39 String36Type The calling location code 4,1216
Number
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
42 String36Type Common account type 4,1216
ountType
2006-08-30 Confidential document, for internal use only Page 198 of 203