WIN Products - Topic on the Analysis of the Signaling V1.0-20050401-B

Document No. Usage object Prepared by WIN Engineers WIN

Product name Product version Document version

WIN

V1.1

WIN Products Topic On the Analysis of the Signaling

Drafted by: Reviewed by: Reviewed by: Approved by:

Mao Yuanjian

Date: Date: Date: Date:

2004/4/23

Huawei Technologies Co., Ltd.All rights reserved

For internal use only

~53F3.doc

Confidentiality: for internal use only

Revision RecordDate 2004/4/23 2004/06/02 Revision version 1.0 1.1 It was drafted. Revisions: enriched contents about call trace and log unscramble and added some cases Description Author Mao Yuanjian Mao Yuanjian


~53F3.doc


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


~53F3.doc


2.5.3 Observing Number Analysis Results ....................................................................... 69 2.6 Introduction to Other Tools ................................................................................................. 72 2.6.1 Viewing SCP and Service Version Number lsmscp Tool....................................... 72 Chapter 3 Typical Service Signaling Flows ................................................................................. 74 3.1 Typical Signaling Flow of the Prepaid Service ................................................................... 74 3.1.1 Prepaid Subscribers Call Prepaid Subscribers ........................................................ 74 3.1.2 Prepaid Subscribers Query the Balance.................................................................. 78 3.1.3 Prepaid Subscriber A Uses a Common GSM Mobile Phone (or PSTN Telephone) to Report Loss, User As Homed SCPa Accesses a Different SCP from the Proximate SCPd Accessed by MSCa/VLR/SSP........................................................................................... 82 3.2 Typical Signaling Flow of the IP17951 Service .................................................................. 85 3.2.1 Description of Basic Networking and Theory ........................................................... 85 3.2.2 Theory of National Interconnection .......................................................................... 86 3.2.3 Call the Non-Local PSTN Mobile Phone Subscribers of Other Networks; the Service-Triggering SCP is not the Home SCP of the Subscriber ..................................... 87 3.3 Typical Signaling Flow of the Mobile Phone Rechargeable Card Service ......................... 96 3.3.1 When the Normal Recharging Flow SCPa and SCPb of the GoTone Subscriber are not the Same SCP, the Operation Succeeds.................................................................... 96 3.4 Typical Signaling Flow of the VPMN Service ................................................................... 105 3.4.1 VPMN Services Requirements for Signaling......................................................... 105 3.4.2 When the Calling Party is a VPMN Subscriber, SCP Should Charge ................... 108 3.4.3 Calls inside the Network are Forwarded Unconditionally into the Network ........... 111 Chapter 4 Analysis and Handling of Signaling Faults.............................................................. 112 4.1 General Guideline ............................................................................................................. 112 4.2 Typical Case Study........................................................................................................... 114 4.2.1 A M-zone Subscriber Has a Long-duration Call but does not Enjoy the Charge Rate Discount .......................................................................................................................... 114 4.2.2 Calls originated near the Charge Rate Switching Point do not have Any Charge Rate Discount.................................................................................................................. 115 4.2.3 PPS Dials the Non-local Unicom Mobile Phone but No Toll Charge is Billed ....... 115 4.2.4 Secondary Trigger Leads to Charging of the Free Number................................... 116 4.2.5 Analysis of the Put-through Rate Signaling Statistics ............................................ 118 4.2.6 AIP Announcement Problem.................................................................................. 120 4.2.7 The E Manufacturer End Office Permanently Downs the Robot of SCP ............... 125 4.2.8 The End Office Responds Abnormally to the PA Operation .................................. 131 4.2.9 Number Display Problems Caused by a Certain Parameter Value ....................... 134 4.2.10 Number Attribute Errors Affect Charging ............................................................. 135 4.2.11 Since the hlrto Area Number Table is not Made Complete, Calls to Non-local Subscribers are not Billed with the Toll Charge. ............................................................. 137 4.2.12 POP Card Subscribers Dialing the Local Fixed Phone Number are Billed with the Toll Charge...................................................................................................................... 138


~53F3.doc


4.2.13 Announcement Makes the End Office to Output the Charging Bill ...................... 139 4.2.14 Since the Database Index is not Established, Query Times out and the Call cannot be Put Through................................................................................................................ 139 4.2.15 Dial the PPS Number beyond the Retention Term and the Subscriber Hears The Subscriber You Dialed is Poweroff. ............................................................................... 139 4.2.16 Since the Voice at the End Office is not Loaded, the Call is Terminated Abnormally ......................................................................................................................................... 141 4.2.17 Due to the Number Format Error, the Number of the Calling Party Becomes 00000 and the Familiarity Number Enjoys No Discount ............................................... 141 4.2.18 A Subscriber Queries the Balance but Cannot Hear the Balance Normally........ 142 Chapter 5 Appendix...................................................................................................................... 144 5.1 Encoding Format of the GT Code..................................................................................... 144 5.2 Common Signaling Parameters........................................................................................ 147 5.2.1 Calling Party Number ............................................................................................. 147 5.2.2 Called Party Number.............................................................................................. 150 5.2.3 Generic Number ..................................................................................................... 150 5.2.4 Original Called Number.......................................................................................... 153 5.2.5 Redirection Information .......................................................................................... 153 5.2.6 CalledPartyBCDNumber ........................................................................................ 155 5.2.7 DateAndTime ......................................................................................................... 157 5.2.8 EventTypeBCSM.................................................................................................... 158 5.2.9 SubscriberState...................................................................................................... 159 5.2.10 O-CSI ................................................................................................................... 159 5.3 Execute Operations .......................................................................................................... 162


~53F3.doc


Keyword: Signaling analysis

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

List of Abbreviations:

List of References:


~53F3.doc


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

For more systematic description of the basic signaling knowledge, this document deals with all the IN-related knowledge and those involved in fault analysis and troubleshooting. Nevertheless, we suggest lecturers take a flexible approach according to the students and teaching requirements.

2006-08-30

Confidential document, for internal use only

Page 2 of 203

~53F3.doc


Chapter 1 Basic Signaling KnowledgeThis chapter describes basic signaling knowledge related to the MIN network, involving SCCP, TCAP, CAP, INAP and MAP. It does not touch upon the basic approach knowledge regarding it but deals with fault analysis and troubleshooting. CAP is the focus we have handled and here in this part, we will talk about the function of each important CAP operation and learn how some of the important parameters are used for services. Through study in this part, you will be able to read and understand the signaling flow of most of the service specifications

1.1 Basic KnowledgeFirst we will have a look at the location of the MIN in the entire signaling system:

Figure 1-1 Structure of the signaling system related to IN What is shown above should be remembered by us during routine signaling maintenance, for it will be of great instructive help during t fault locating and troubleshooting. From the above figure we can learn that: 1) MTP is the basis for the transmission of all the signaling. Whenever the signaling passes a NE, it must have to pass this part. Therefore, when the signaling transmission channel has faults, we need to check if each NEs MTP equipment2006-08-30 Confidential document, for internal use only Page 3 of 203

~53F3.doc


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) 2) 3) At which layer this fault occurs? To which module this fault belongs to? If it occurs at the application layer, it is about CAP, INAP or MAP? How this fault is imported? If the application part is newly added or modified, whether its bearer layer (TCAP, SCCP, MTP and etc.) has been correctly configured? If the application layer remains unchanged, whether its bearer layer (including the transmission link) has changed? Signaling faults are most possibly caused due to importing or modification of certain configurations. Therefore, we should clarify this issue soonest possible. What we talk about later on will help you make the correct judgment quickly.

1.2 SCCP Knowledge PointsIn this section, you should concentrate on the definition of addressing. Only when the addressing configuration is correctly set can the signaling link normally implement end-to-end transmission. At the MTP layer, addressing between two adjacent points is provided. That is to say, through the original signaling point address (OPC) and the destination signaling point address (DPC), signalings can be transmitted between two adjacent points. Just as we send a letter from Guangzhou to Beijing, the sender is only concerned about the destination Beijing, regardless of how this letter is posted, by air, by train or by bus, or whether it is transferred in Changsha or in Wuhan. It is for the post office to select a quick, safe and economical way/path to realize it. Similarly with many signalings irrelevant to circuits, such as IDP messages, it suffices to ensure that they can be

2006-08-30


Page 4 of 203

~53F3.doc


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

For one message to be sent from A to K, if DPC addressing is adopted, it is necessary to determine a route in advance, as shown above in red lines A->B->E->I->K; among them, the format of the message sent by A is as follows:

2006-08-30


Page 5 of 203

~53F3.doc


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

For one message to be sent from A to K, if GT addressing is adopted, it is only necessary to consider selecting one point out of D/C/B (according to the principle that different GTs adopt load balancing). A need not consider the routes after it. The format of the message sent by A is as follows (Suppose the message is transmitted via point B):

When the message reaches point B and finds out MTPs DPC is itself, then B sends the message to SCCP. After SCCP translates GT, it finds out DPC is not itself, so it

2006-08-30


Page 6 of 203

~53F3.doc


rewrites MTPs DPC and sends the message to the following node. The format of the message to be sent may be:

According to the principle of load balancing, if B routes the message to K to F. Differences between DPC Addressing and GT Addressing: 1) For the MTP-layer data in the case of GT addressing, it is only necessary to consider the adjacent signaling points instead of the remote ones. But if DPC addressing is adopted, it is necessary to consider the MTP data of non-adjacent signaling points. 2) DPC addressing needs to be translated again at the SCCP layer when it passes STP but GT addressing only needs to be translated once at the SCCP layer.

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

Primitive: To put it simply, a primitive corresponds to several TCAP messages. No matter how the user layer changes, it is borne by these primitives. According to the transmission direction, for request primitives, the upper layer sends request while the lower layer transmits messages outward; for indication primitives, the lower layer transmits the opposite-end messages to the upper lower for handling.

2006-08-30


Page 7 of 203

~53F3.doc


According to their functions, primitives can be divided into component primitives and dialogue primitives. The former are used in the user-layer data while the latter are used to indicate the start, continue, end and abort of dialogues. Component primitives need to be carried by dialogue primitives but the latter can exist independently, such as tc_u_abort.

1.3.2 Dialogue PrimitiveI. tc_beginThe 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 16 32 48 64 80 00 5C 01 00 00 00 02 FF 01 09 12 06 00 12 04 68 31 89 75 00 00 00 00 00 00 00 00 07 04 00 00 01 00 1D 03 00 00 00 00 09 12 0C 00 12 03 12 34 56 78 34 56 78 00 00 00 00 00 00 00 00 02 FF 32 34 30 00 00 00 00 FE F4 00 00 00 00 00 00 30 30 30 FF FF FE F0 00 00 8C CB 34 32 30 30 30 FF

Byte 0, 1 2 3-6 7-8

Length 2 1 4 2 Length

Meaning 00 5C 01: tc_begin 00 00 00 02 FF 01

Value

TCAP component primitive DialogueID QualityOfService Destination address

09 12 06 00 12 04 68 31 89 75 00 00 00 00 00 00 00 00 Note 1: 09 refers to the validPage 8 of 203

9-26

18 86139857

2006-08-30


~53F3.doc


Byte

Length

Meaning length

Value

Note 2: 12 is the address indicator 07 04 00 00 01 00 1D 03 00 00 27-38 12 Application context name 00 00 Note: 07 refers to the length Originating address 39-56 18 12345678345678 57-60 4 DialogueID 09 12 0C 00 12 03 12 34 56 78 34 56 78 00 00 00 00 00 00 00 00 02 FF 32 34 30 00 00 00 00 FE F4 61-92 32 userInformation 00 00 00 00 00 00 30 30 30 FF FF FE F0 00 00 8C CB 34 32 30 30 30 93 1 componentsPresent FF

Common application contexts: IDP ARI = {0x04,0x00,0x00,0x01,0x00,0x32,0x01}; = {0x04,0x00,0x00,0x01,0x00,0x34,0x01}; = {0x04,0x00,0x00,0x01,0x00,0x05,0x02}; (MAP Phase2) (MAP Phase2+)

SRI_V2

SRI_V2+ = {0x04,0x00,0x00,0x01,0x00,0x05,0x03}; Execute = {0x00,0x11,0x89,0x4C,0x02,0x03,0x03};

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

2006-08-30


Page 9 of 203

~53F3.doc


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_endIt 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 Bytes 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_abortNormally when this message is received, it means some exceptions occur during the dialogue. We can try to infer the cause of the dialogue termination through the cause value of dialogue abort. How can we obtain the cause value (abortReason) through the code dream? 00 38 05 00 00 71 40 FF 01 00 00 71 40 01 FF 00 00 00 00 00 00 00 00 00 00 00 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

2006-08-30


Page 10 of 203

~53F3.doc


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 ApplicationTimerExpired NotAllowedProcedures AbnormalProcessing Congestion 1 2 3 4 5

The reason why SCP is delivered can be: 1) 2) When the call is aborted in the case of overload, abortReason = 1; When SCF discovers repeated dialogue numbers, abortReason = 4;

V. tc_p_abortThis 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_noticeThis message is common during debugging of new equipment. When a transmission link has not been configured, the sender will receive such a message. That is to say, when this message is received, those messages you sent previously may not be transmitted to the final landing point. Then we should check the signaling transmission links involved, especially the configuration on SAU. We can also analyze the reason according to the specific reason values: 87654321 00000000 00000001 00000010 no translation for an address of such nature no translation for this specific address subsystem congestion

2006-08-30


Page 11 of 203

~53F3.doc


00000011 00000100 00000101 00000110 00000111 00001000 00001001 00001010 00001011 00001100 00001101 00001110 00001111 to 11111111

subsystem failure unequipped user MTP failure network congestion unqualified error in message transport (Note) error in local processing (Note) destination cannot perform reassembly (Note) SCCP failure hop counter violation segmentation not supported segmentation failure

spare

You can refer to ITU-T Q714 for interpretation of each specific reason. Interpretation of the reason: 00 0A CB 00 00 B2 10 00 00 B2 10 01 This message is very short; the Byte after the dialogue number is the reason value (01).

1.3.3 Component PrimitiveI. tc_invokeIt 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, for2006-08-30 Confidential document, for internal use only Page 12 of 203

~53F3.doc


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

II. tc_result_lThis 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_errorWhen signaling faults are transmitted, we should have the awareness to check if this component primitive exists or not. We should pay attention to the reason value carried by it. Interpretation of the code stream: 00 0F 13 00 00 07 71 00 00 07 71 06 00 04 01 00 00 (the reason value is 4) The common error codes are defined as below:cancelled cancelFailed eTCFailed improperCallerResponse missingCustomerRecord missingParameter parameterOutOfRange requestedInfoError systemFailure taskRefused unavailableResource Cancelled CancelFailed ETCFailed ImproperCallerResponse MissingCustomerRecord MissingParameter ParameterOutOfRange RequestedInfoError SystemFailure TaskRefused UnavailableResource ::= localValue 0 ::= localValue 1 ::= localValue 3 ::= localValue 4 ::= localValue 6 ::= localValue 7 ::= localValue 8 ::= localValue 10 ::= localValue 11 ::= localValue 12 ::= localValue 13

2006-08-30


Page 13 of 203

~53F3.docunexpectedComponentSequence 14 unexpectedDataValue unexpectedParameter unknownLegID UnexpectedDataValue UnexpectedParameter UnknownLegId UnexpectedComponentSequence

Confidentiality: for internal use only::= localValue

::= localValue 15 ::= localValue 16 ::= localValue 17

IV. tc_u_rejectWhen the operation component received by the TC_user is not correct, this operation will be rejected for implementation. The parameter contains the reject reason value. How to view the reason value? The reason is defined in Specification ITU-TQ773 as follows:Reject ::= SEQUENCE {

invokeID CHOICE { derivable InvokeIdType,

not-derivable NULL }, problem CHOICE { generalProblem invokeProblem [0] IMPLICIT GeneralProblem, [1] IMPLICIT InvokeProblem,

returnResultProblem [2] IMPLICIT ReturnResultProblem, returnErrorProblem [3] IMPLICIT ReturnErrorProblem } }

Different types of problem codes are defined as below:GeneralProblem ::= INTEGER { unrecognizedComponent (0), mistypedComponent (1), badlyStructuredComponent (2) }

InvokeProblem

::= INTEGER {

duplicateInvokeID (0), unrecognizedOperation (1), mistypedParameter (2), resourceLimitation (3), initiatingRelease (4), unrecognizedLinkedID (5), linkedResponseUnexpected (6), unexpectedLinkedOperation (7) }

ReturnResultProblem

::= INTEGER {

unrecognizedInvokeID (0), returnResultUnexpected (1), mistypedParameter (2) }

2006-08-30


Page 14 of 203

~53F3.docReturnErrorProblem ::= INTEGER {

Confidentiality: for internal use onlyunrecognizedInvokeID (0), returnErrorUnexpected (1), unrecognizedError (2), unexpectedError (3), mistypedParameter (4) }

We can see from above that problem codes are divided into 4 types, each with its own number. For example debugging is implemented at a certain location and we trace the following signaling on OAM:SCP 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; MSCs source address is 8613740527: IDP_CAP RRBE_CAP AC_CAP ->

| tc_begin tc_invoke (invokeID=1) | tc_continue1 tc_invoke (invokeID=1) | tc_continue2 tc_invoke (invokeID=2) | tc_continue2 tc_invoke (invokeID=3) | tc_continue2 tc_invoke (invokeID=2) tc_l_cancel tc_l_cancel tc_l_cancel

CONNECT_CAP -> ACR_CAP =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 when2006-08-30 Confidential document, for internal use only Page 137 of 203

~53F3.doc


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) 2) If we find the called party number is PSTN. (maybe the mobile phone lacks the Hlr data). 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 ChargeSymptom: A certain POP card subscriber dials the local fixed phone number 86130797 and he is billed with the toll charge. Analysis: Respectively use the Shenzhouxing and M-zone card mobile phones to dial this fixed phone number, both are billed with the toll charge. By checking the SCP bill, we find the called party number is displayed as 130797 (Note there is no 86 before it). Through OAM tracing signaling, the called party number is displayed as 86130797. Since there is no 86 before the called party number recorded in the bill, we are justified to suspect SCP judges this number as the country code + the mobile phone number and obtains 130797 as the called party number after stripping the country code. To further verify our analysis, we can use dbaccess to consider 130797 as the hlrtoareanumber in hlrtoareanumber and find that the toll area code can be matched. For still further validation, we can trace single calls to obtain the debug document and find that when analyzing 130797, SCP will regard it as the mobile phone number and obtain the area code by querying. Solution: There are two solutions: 1) In the hlrtoareanumber table, the number section of 130797 is extended as 1307970-1307979. So during number analysis, 130797 cannot be matched and will not be seen as the mobile phone number. 2) Modify the service and improve the special handling of 8613. We should not only analyze whether the number after 86 is the mobile phone number but also analyze whether its length is 11-digit. Only when it is 11-digit long, we can conduct special handling. 1) can be adopted for temporary mitigation; 2) can be adopted for final resolution.

2006-08-30


Page 138 of 203

~53F3.doc


4.2.13 Announcement Makes the End Office to Output the Charging BillSymptom: A subscriber dials the number of a validity-expired subscriber and is told the number does not exist, but the end office generates the charging bill. Analysis: Contact the MSC engineer for analysis and he thinks the bi-directional indicator in the ETC delivered by SCP is Required, so MSC generates the bill. Solution: Refer to 20020320 Notice on Regulating the Usage of Parameter BOTHWAYthoughconection.tif released by CMCC, SCP delivery complies with the specification and modification of MSC is supported. Similar situations include that when CTR plays announcement, the charging bill is generated. Through OAM tracing signaling, check whether the signaling (ETC or CTR) delivered by SCP complies with the requirement of this notice.

4.2.14 Since the Database Index is not Established, Query Times out and the Call cannot be Put ThroughSymptom: A certain service call cannot be put through; the phenomenon is that there is no response long after dialing and the call is release due to timeout. Analysis: Roughly we judge it is due to the problem of the signaling. The symptom on the signaling is that the abort message of the end office is received but by checking the log document, we find there is CPU overuse alarm; use top to observe and see the occupation of oninit processcpu is really high; turn on the printing switch and we find the document can be traced but the call used to test the mobile phone cannot be traced. The cause should be that the use rate of cpu is too high and the response is too slow, so this call has not been handled. Open the sqlx.log and we see the query speed of the mvpn_phone table is very slow. The number of records in this table is very large, so we suspect the index is not established or lost. We can also check if the index works during querying with the previous method. Solution: The problem is solved after the index is established.

4.2.15 Dial the PPS Number beyond the Retention Term and the Subscriber Hears The Subscriber You Dialed is Poweroff.Symptom: There is a Shenzhouxing stored value card, which has not ever been used. When the owner wants to use it recently only to find it expires the retention term. When dialing this phone number, he can only hear The subscriber you dialed is poweroff. So the customer issued a complaint. According to the specification, the voice he gets by dialing the PPS retention-period subscriber should be: The number you dialed is invalid; the voice he gets by dialing the PPS freeze-period subscriber should be: The2006-08-30 Confidential document, for internal use only Page 139 of 203

~53F3.doc


number you dialed does not exist. However the subscriber actually is powered on but the voice tells you: The subscriber you dialed is poweroff. We guess maybe something is wrong with the service. Analysis: The site engineer conducts signaling tracing through OAM and acquires the signaling flow:

13611146666_gj.trace

We find when the number of this Shenzhouxing stored value card is dialed and after IDP appears, SCP releases the call but it does not instruct MSC to play announcement The subscriber you dialed is poweroff should be played by MSC to the calling party after SCP releases the call. But what prompts MSC to play the wrong announcement? We notice the subscriber state parameter reported by IDP. There are several subscriber states as described below: SubscriberState ::= CHOICE { assumedIdle camelBusy [0] NULL, [1] NULL,

netDetNotReachable NotReachableReason, notProvidedFromVLR [2] NULL}

The not-reachable reasons are described below: NotReachableReason ::= ENUMERATED { msPurged (0), //Only when this reason is submitted,the releaseCause

with the value of 20 is delivered imsiDetached (1), restrictedArea (2), notRegistered (3)} According to the tracing information fed back from the location, in the IPD message exist the following records: subscriberState={ state=notReachable notReachableReason=02006-08-30

//The subscriber state is not reachable //The reason is mspurgedPage 140 of 203


~53F3.doc


} So SCP will deliver the release-call with the cause value of 20 and instruct SSP to play the alert tone the subscriber you dialed is poweroff to the subscriber, which complies with 20010920 Notice on the Record Notification Implementation Plan when the Called Prepaid Subscriber is Poweroff released by China Mobile.

20010920.tif

Solution: MSC and HLR cooperate on the solution.

4.2.16 Since the Voice at the End Office is not Loaded, the Call is Terminated AbnormallySymptom: After a subscriber dials 13800138000 and press 1, he hears the alert tone Your input is wrong. Analysis: Trace the signaling on OAM and analyze the traced message and we find after the testing subscriber dials 13800138000 and selects the language, SCP delivers the play-announcement instruction (ID is 0140003e). This announcement is used to replace the 0140000b announcement after the familiarity number service is activated. MSC/SSP returns tc_u_error, errno=13, which means the resource is unusable. This is probably due to the fact that MSC only loads the PPS announcement but not loads the familiarity number announcement. Note: Trace PA or PC on OAM to acquire the announcement ID. But how can it correspond to the practical announcement content? Usually we need to find the service specification of the relevant service. Note it is not the service signaling specification. Solution: Load the corresponding announcement on MSC.

4.2.17 Due to the Number Format Error, the Number of the Calling Party Becomes 00000 and the Familiarity Number Enjoys No DiscountSymptom: In the bill of a Shenzhouxing called subscriber, the number of the calling party is filled up with 00000 and the familiarity number enjoys no discount. Analysis: Set a local Shenzhouxing testing number 13690000001 as the familiarity number 07682356060 and use 07682356060 to dial 13690000001 for a test. Trace the call on SCP1 and view the bill finding the system really gives no discount to

2006-08-30


Page 141 of 203

~53F3.doc


thisfamiliarity number and unexpectedly the number of the calling party in the bill is

00000. It is the same case for several tests. chaozhou.trace Check the IDP message used to trace the document and we find the submitted number of the calling party is not the international-standard number, nor 00000. Use SMAP to query the setting of the familiarity number service and the familiarity number setting of this number but both are correct. No discount for the familiarity number is because SCP cannot analyze a number in the form of 860786xxxxxxx. It is forbidden to submit the case of country code + 0 + the area code + the common number. The non-standard area code cannot be stripped, so the familiarity number data cannot be matched. In the bill of the called party, the number of the calling party 00000 is also caused by this reason. SCP cannot strip the area code of this type of numbers. So in calculating the number, the number of the calling party becomes 00000. This calculation is for correctly matching the familiarity number. The specific calculation is S_Callingaddress = 0 + the area code + PSTN (without the area code). Since the area code cannot be stripped, the area code=0000 and PSTN=blank, that is how 00000 comes from. Solution: MSC/SSP adjusts the format of the number to be submitted.

4.2.18 A Subscriber Queries the Balance but Cannot Hear the Balance NormallySymptom: A certain ppip subscriber 7697883787 can recharge normally and dial ip phone calls; but when he dials 13800138000 to query the balance, after the prompt tone Your account is 7697883787, there is no more prompt and the call is cut off. Analysis: Conduct signaling tracing on OAM to trace the document:

.txt . According to the management flow of PPIP and the collected

signaling information, after the first PA announcement Your account is to this call, the end office does not submit the SpecialzedResouceReport but submits the ERB/DP event which means the calling party aborts. The signaling flow is as shown below:

2006-08-30


Page 142 of 203

~53F3.doc


There are two possibilities: 1. The subscriber hangs up the phone directly; 2. The end office does not play announcement correctly or after the first announcement is played, it is not reported to SRR so that SCP cannot continue to deliver the second PA playing the balance of the subscriber. Then after waiting for a while, the subscriber hangs up the phone. Solution: Locate the problem in the end office.

2006-08-30


Page 143 of 203

~53F3.doc


Chapter 5 Appendix5.1 Encoding Format of the GT CodeAccording 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 Octet 1 Octet 2 Octet 3 Octet 4 Octet N 7 6 5 4 3 2 1 bit

GT code indicator Translation type Numbering plan Idle Encoding scheme

Address property indicator

Address information

Parameter description: GT code indicator: Here it is the same as that in the address type indicator. For the fourth type of GT codes, it should be 04H. Description: It is necessary to clarify that this parameter is provided by the address type indicator in the SCCP address that is really transmitted. The GT code does not contain this parameter. But when the GT code is filled in relevant data setting tables, this parameter should be included at first.

Translation type: It has not been put into application; the fixed value is 00H.

2006-08-30


Page 144 of 203

~53F3.doc


Numbering plan: Octet 3 high 4 bit is the numbering plan, indicating which mode is adopted by the address information for numbering. The specific codes are described as below: Bit 7654 0000(0) 0001(1) recommended) 0010(2) 0011(3) 0100(4) 0101(5) recommended) 0110(6) 0111(7) 1000 to 1111 Encoding scheme: Octet 3 low 4 bit is the numbering plan, indicating the number of address signals in the address information is odd or even. The codes are as follow: Bit 7654 0000 0001 0010 0011 to 1111 Address property indicator: Octet 2s bit 1-7, indicating the property of the address information. The codes are as follow: Bit 7654321 0000000(0)2006-08-30

Meaning Not defined yet ISDN/telephone numbering plan (E.163 and E.164 are

Standby Data numbering plan (X.121 is recommended) Telex numbering plan (F.69 is recommended) Marine mobile numbering plan (E.210 and E.211 are

Land mobile numbering plan (E.212 is recommended) ISDN/mobile numbering plan (E.214 is recommended)

Standby

Meaning Not defined yet An odd number of address signals An even number of address signals l

Standby

IdleConfidential document, for internal use only Page 145 of 203

~53F3.doc


0000001(1) 0000010(2) 0000011(3) 0000100(4) 0000101(5) 1111111(127)

Subscriber number Domestic standby Domestic valid number International number to Idle

Address information: Octet 3 and those behind it are the address signals. Their formats are as below: Each address signal occupies 4 bits; the codes are as below: 8 Octet 1 7 6 54 3 2 1 Bit The first address signal The third address signal

The second address signal The fourth address signal

-240Octet N

0 (if necessary)

The nth address signal

Each address signal occupies 4 bits. If the number of the address signals is an odd number, behind the address signals insert the filling code 0000, namely, in the Nth Byte high 4 bit fill in 0000. Instance 1 The GT code indicator entered by the operator is 4; the translation type is 0 (currently only 0 can be entered); the numbering plan is the land mobile numbering plan (the code is 6); the address property indicator is the subscriber number (the code is 1); the address information is 1234567. Since the address information contains an odd number of entries, the encoding scheme is 0001 (namely 1). Then: GT codes content is: 0400610121436507 GTLength (indicating Octets ByteLength): 8 Instance 2 The GT code indicator entered by the operator is 4; the translation type is 0 (currently only 0 can be entered); the numbering plan is the land mobile numbering plan (the code is 6); the address property indicator is the international number (the code is 4);

2006-08-30


Page 146 of 203

~53F3.doc


the address information is 1234567. Since the address information contains an even number of entries, the encoding scheme is 0010 (namely 2). Then: GT codes content is: 04006204214365 GTLength (indicating Octets ByteLength): 7 Instance 3 The GT code indicator entered by the operator is 4; the translation type is 0 (currently only 0 can be entered); the numbering plan is the marine mobile numbering plan (the code is 5); the address property indicator is the domestic valid number (the code is 3); the address information is 4321679. Since the address information contains an odd number of entries, the encoding scheme is 0001 (namely 1). Then: GT codes content is: 0400510334127609 GTLength (indicating Octets ByteLength): 8

5.2 Common Signaling Parameters5.2.1 Calling Party NumberThe format of the calling party number parameter field is shown in Figure 1 below. 8 1 Odd/ even 2 NI Numbering plan Ind. Address presentation restricted indicator 3 . . n Filler (if necessary) nth address signal 2nd address signal 1st address signal Screening 7 6 5 4 3 2 1

Nature of address indicator

Figure1 Q.763 Calling party number parameter field The following codes are used in the calling party number parameter field. a) 0 Odd/even indicator the number of address signals is an even one

2006-08-30


Page 147 of 203

~53F3.doc


1

the number of address signals is an odd one

b)

Nature of address indicator spare subscriber number (national use) unknown (national use) national (significant) number (national use) international number

0000000 0000001 0000010 0000011 0000100

0 0 0 0 1 0 1 to 1101111 1110000 to 1111110 1111111

spare

reserved for national use

spare

c)

Number Incomplete indicator (NI)

0 complete 1 incomplete d) Numbering plan indicator

0 0 0 spare 0 0 1 ISDN (Telephony) numbering plan (Recommendation E.164) 0 1 0 spare 0 1 1 Data numbering plan (Recommendation X.121) (national use) 1 0 0 Telex numbering plan (Recommendation F.69) (national use) 1 0 1 reserved for national use 1 1 0 reserved for national use2006-08-30 Confidential document, for internal use only Page 148 of 203

~53F3.doc


1 1 1 spare e) 00 01 10 11 Address presentation restricted indicator presentation allowed presentation restricted address not available (Note) (national use) 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 01 10 11 reserved (Note) user provided, verified and passed reserved (Note) 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 digit 0 digit 1 digit 2 digit 3 digit 4 digit 5 digit 6 digit 7 digit 8 digit 9 spare

0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010

2006-08-30


Page 149 of 203

~53F3.doc


1011 f)Filler

code 11

In case of an odd number of address signals, the filler code 0000 is inserted after the last address signal.

5.2.2 Called Party NumberThe format of the called party number parameter field is shown in Figure 2. 8 1 2 3 . . n Filler (if necessary) nth address signal Odd/ even INN Ind. 7 6 5 4 3 2 1

Nature of address indicator Numbering plan Ind. Spare 1st address signal

2nd address signal

Figure 2/Q.763 Called party number parameter field

5.2.3 Generic NumberThe format of the generic number parameter field is shown in Figure 3. 8 1 2 7 6 5 4 3 2 1

Number qualifier indicator Odd/ even Nature of address indicator

3

NI ind.

Numbering plan Ind.

Address presentation restricted Ind.

Screening

4 : n

2nd address signal

1st address signal

Filler (if necessary)

nth address signal

Figure 3/Q.763 Generic number parameter field2006-08-30 Confidential document, for internal use only Page 150 of 203

~53F3.doc


The following codes are used in the generic number parameter field: a) Number qualifier indicator reserved (dialled digits) (national use) additional called number (national use) reserved (supplemental user provided calling number failed network screening) (national use) 00000011 reserved (supplemental user provided calling number not screened) (national use) 00000100 00000101 00000110 00000111 00001000 00001001 00001010 reserved (redirecting terminating number) (national use) additional connected number additional calling party number reserved for additional original called number reserved for additional redirecting number reserved for additional redirection number reserved (used in 1992 version)

00000000 00000001 00000010

0 0 0 0 1 0 1 1 to 0 1 1 1 1 1 1 1 10000000 to 11111110 11111111

spare


reserved for expansion

c)

Nature of address indicator spare subscriber number (national use) unknown (national use) national (significant) number

0000000 0000001 0000010 0000011

2006-08-30


Page 151 of 203

~53F3.doc


0000100

international number

0 0 0 0 1 0 1 to 1101111 1110000 to 1111110 1111111

spare


spare

NOTE For each supplementary service the relevant codes and possible default settings are described in the supplementary service Recommendations (Recommendation Q.73x) f)Address presentation restricted indicator 00 01 10 11 presentation allowed presentation restricted address not available spare

NOTE For each supplementary service the relevant codes and possible default settings are described in the supplementary service Recommendations (Recommendation Q.73x). When the address presentation restricted indicator indicates address not available, the subfields in items b), c), d), and e) are coded with 0's, and the screening indicator is set to 11 (network provided). g) Screening indicator

Only used if the number qualifier indicator is coded 0000 0101 (additional connected number) or 0000 0110 (additional calling party number). This indicator is coded as follows: 00 01 10 11 user provided, not verified user provided, verified and passed user provided, verified and failed network provided

2006-08-30


Page 152 of 203

~53F3.doc


NOTE For each supplementary service the relevant codes and possible default settings are described in the supplementary service Recommendations (Recommendation Q.73x).

5.2.4 Original Called NumberThe format of the original called number parameter field corresponds to the format shown in Figure 4. 8 1 Odd/ even Spare 7 6 5 4 3 2 1

Nature of address indicator Address presentation restricted indicator 1st address signal

2 3 . . n

Numbering plan ind.

Spare

2nd address signal

Filler (if necessary)

nth address signal

Figure 4/Q.763 Original called number parameter field

5.2.5 Redirection InformationThe format of the redirection information parameter field is shown in Figure 5. 8 1 2 H P 7 G O 6 F N 5 E M 4 D L 3 C K 2 B J 1 A I

NOTE The parameter may be received without the second octet from an ISUP'88 (Blue Book). Figure 5/Q.763 Redirection information parameter field The following codes are used in the redirection information parameter field: bits

2006-08-30


Page 153 of 203

~53F3.doc


CBA

Redirecting indicator no redirection (national use) call rerouted (national use) call rerouted, all redirection information presentation

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

Spare Spare

HGFE

Original redirection reason unknown/not available user busy (national use) no reply (national use) unconditional (national use)

0100 to 1111

Spare

Redirection counter. Number of redirections the call has undergone expressed as a binary number between 1 and 5.

2006-08-30


Page 154 of 203

~53F3.doc


Reserved for national use bits

PONM

Redirecting reason unknown/not available user busy no reply Unconditional deflection during alerting deflection immediate response mobile subscriber not reachable

0 1 1 1 to 1111

Spare

5.2.6 CalledPartyBCDNumberCalledPartyBCDNumber (minCalledPartyBCDNumberLength .. maxCalledPartyBCDNumberLength)) -Indicates the Called Party Number, including service selection information. ::= OCTET STRING (SIZE

Refer to GSM -04.08 [25] for encoding. This data type carries only the "type of number",

"numbering plan -identification" and "number digit" fields defined in [25]; it does not carry the

"called -party BCD number IEI" or "length of called party BCD number contents".

2006-08-30


Page 155 of 203

~53F3.doc


The purpose of the calling party BCD number information element is to identify the origin of a call. The calling party BCD number information element is coded as shown in figure 10.5.93/GSM 04.08 and table 10.5.120/GSM 04.08. The calling party BCD number is a type 4 information element. In the network to mobile station direction it has a minimum length of 3 octets and a maximum length of 14 octets. (This information element is not used in the mobile station to network direction.)8 7 6 5 4 3 2 1

+-----------------------------------------------+ Calling party BCD number IEI octet 1

+----------------------------------------------- Length of calling party BCD number contents octet 2

+----------------------------------------------- 0/1 ext type of number Numbering plan octet 3

identification

+-----+----------------------------------------- 1 presentat. 0 ext indicator 0 spare 0 screening

indicator octet 3a*

+----------------------------------------------- Number digit 1 octet 4*

Number digit 2

+-----------------------+----------------------- Number digit 3 octet 5*

Number digit 4

+-----------------------+----------------------- : +-----------------------------------------------+ :

Figure 10.5.93/GSM 04.08: Calling party BCD number information element The contents of octets 3, 4, etc. are coded as shown in table 10.5.118. The coding of octet 3a is defined in table 10.5.120 below. If the calling party BCD number contains an odd number of digits, bits 5 to 8 of the last octet shall be filled with an end mark coded as "1111". Table 10.5.120/GSM 04.08: Calling party BCD number+--------------------------------------------------------+

2006-08-30


Page 156 of 203

~53F3.doc Presentation indicator (octet 3a) Bits 7 6 0 0 0 1 1 0 1 1 If octet 3a is omitted the value "00 - Presentation allowed" is assumed. Screening indicator (octet 3a) Bits 2 1 0 0 0 1 1 0 1 1 If octet 3a is omitted the value "0 0 - User provided, not screened" is assumed. +--------------------------------------------------------+ User-provided, not screened Presentation allowed Presentation restricted


Number not available due to interworking Reserved

User-provided, verified and passed User-provided, verified and failed Network provided

5.2.7 DateAndTimeDateAndTime ::= OCTET STRING (SIZE(7))

-- DateAndTime is BCD encoded. The year digit indicating millenium occupies bits 0-3 of -- the first octet, and the year digit indicating century occupies bits 4-7 of the first octet. -- The year digit indicating decade occupies bits 0-3 of the second octet, whilst the digit -- indicating the year within the decade occupies bits 4-7 of the second octet. -- The most significant month digit occupies bits 0-3 of the third octet, and the least

2006-08-30


Page 157 of 203

~53F3.doc


-- significant month digit occupies bits 4-7 of the third octet. -- The most significant day digit occupies bits 0-3 of the fourth octet, and the least significant -- day digit occupies bits 4-7 of the fourth octet. -- The most significant hours digit occupies bits 0-3 of the fifth octet, and the least significant -- digit occupies bits 4-7 of the fifth octet. -- The most significant minutes digit occupies bits 0-3 of the sixth octet, and the least -- significant digit occupies bits 4-7 of the sixth octet. -- The most significant seconds digit occupies bits 0-3 of the seventh octet, and the least seconds -- significant digit occupies bits 4-7 of the seventh octet. -- For the encoding of digits in an octet, refer to the timeAndtimezone parameter.

5.2.8 EventTypeBCSMEventTypeBCSM collectedInfo routeSelectFailure oCalledPartyBusy oNoAnswer oAnswer oDisconnect oAbandon termAttemptAuthorized tBusy tNoAnswer tAnswer tDisconnect tAbandon } ::= ENUMERATED { (2), (4), (5), (6), (7), (9), (10), (12), (13), (14), (15), (17), (18)

-- Values collectedInfo and termAttemptAuthorized can only be -- used for TDPs.

2006-08-30


Page 158 of 203

~53F3.doc


5.2.9 SubscriberStateThis parameter reports to SCP in IDP on the subscriber state, such as busy, not reachable, and so on. SubscriberState ::= CHOICE { assumedIdle [0] NULL, camelBusy [1] NULL, NotReachableReason,

netDetNotReachable

notProvidedFromVLR [2] NULL} NotReachableReason ::= ENUMERATED { msPurged (0), imsiDetached (1), restrictedArea (2), notRegistered (3)}

5.2.10 O-CSIO-CSI ::= SEQUENCE { o-BcsmCamelTDPDataList O-BcsmCamelTDPDataList, extensionContainer ..., camelCapabilityHandling } O-BcsmCamelTDPDataList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF O-BcsmCamelTDPData --- O-BcsmCamelTDPDataList shall not contain more than one instance of --- O-BcsmCamelTDPData containing the same value for o-BcsmTriggerDetectionPoint. --- For CAMEL Phase 2, this means that only one instance of O-BcsmCamelTDPData is allowed [0] CamelCapabilityHandling OPTIONAL ExtensionContainer OPTIONAL,

2006-08-30


Page 159 of 203

~53F3.doc


--- with o-BcsmTriggerDetectionPoint being equal to DP2. maxNumOfCamelTDPData INTEGER ::= 10 O-BcsmCamelTDPData ::= SEQUENCE { o-BcsmTriggerDetectionPoint serviceKey ServiceKey, [0] ISDN-AddressString, [1] DefaultCallHandling, [2] ExtensionContainer OPTIONAL, O-BcsmTriggerDetectionPoint,

gsmSCF-Address defaultCallHandling extensionContainer ... }

ServiceKey ::= INTEGER (0..2147483647) O-BcsmTriggerDetectionPoint ::= ENUMERATED { collectedInfo (2), ... } -- exception handling: -- For O-BcsmCamelTDPData sequences containing this parameter with any -- other value than the ones listed the receiver shall ignore the whole -- O-BcsmCamelTDPDatasequence. -- For O-BcsmCamelTDP-Criteria sequences containing this parameter with any -- other value than the ones listed the receiver shall ignore the whole -- O-BcsmCamelTDP-Criteria sequence. O-BcsmCamelTDPCriteriaList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF O-BcsmCamelTDP-Criteria O-BcsmCamelTDP-Criteria ::= SEQUENCE { o-BcsmTriggerDetectionPoint O-BcsmTriggerDetectionPoint, OPTIONAL,

destinationNumberCriteria [0] DestinationNumberCriteria basicServiceCriteria2006-08-30

[1] BasicServiceCriteria OPTIONAL,Page 160 of 203


~53F3.doc


callTypeCriteria ... }

[2] CallTypeCriteria

OPTIONAL,

DestinationNumberCriteria ::= matchType destinationNumberList destinationNumberLengthList

SEQUENCE { [0] MatchType, [1] DestinationNumberList [2] DestinationNumberLengthList OPTIONAL, OPTIONAL,

-- one or both of destinationNumberList and destinationNumberLengthList -- shall be present ... } DestinationNumberList ::= SEQUENCE SIZE

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

(1..maxNumOfCamelDestinationNumberLengths) OF INTEGER(1..maxNumOfISDN-AddressDigits) BasicServiceCriteria SIZE(1..maxNumOfCamelBasicServiceCriteria) OF Ext-BasicServiceCode maxNumOfISDN-AddressDigits INTEGER ::= 15 maxNumOfCamelDestinationNumbers INTEGER ::= 10 maxNumOfCamelDestinationNumberLengths INTEGER ::= 3 maxNumOfCamelBasicServiceCriteria INTEGER ::= 5 CallTypeCriteria forwarded (0), ::= ENUMERATED { ::= SEQUENCE

notForwarded (1)} MatchType ::= ENUMERATED {

2006-08-30


Page 161 of 203

~53F3.doc


inhibiting enabling

(0), (1)}

DefaultCallHandling ::= ENUMERATED { continueCall (0) , releaseCall (1) , ...} -- exception handling: -- reception of values in range 2-31 shall be treated as "continueCall" -- reception of values greater than 31 shall be treated as "releaseCall" CamelCapabilityHandling ::= INTEGER(1..16) -- value 1 = CAMEL phase 1, -- value 2 = CAMEL phase 2: -- reception of values greater than 2 shall be treated as CAMEL phase 2 SupportedCamelPhases ::= BIT STRING { phase1 (0), phase2 (1) } (SIZE (1..16))

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

2006-08-30


Page 162 of 203

~53F3.doc


ExecuteResult method-id output-assertions type value }OPTIONAL, specific-output }

::=

SET { [1] Object Identifier, [2] SEQUENCE OF SEQUENCE{ AttributeType, AttributeValue

[3] SpecificOutput OPTIONAL

-- Common Data Types Name rdnSequence RDNSequence ::= CHOICE { - - only one possibility for now - RDNSequence } ::= SEQUENCE OF RelativeDistinguishedName

RelativeDistinguishedName ::= AttributeTypeAndValue AttributeTypeAndValue type value } AttributeType ::= Object Identifier ::= SEQUENCE{

AttributeType, AttributeValue

AttributeValue ::= CHOICE{ intElement int4Element charElement stringElement } SpecificInput ::= SEQUENCE OF AttributeValue [0] INTEGER(0..32767 ), [1] INTEGER(0..2147483647 ), [2] OCTET STRING (SIZE (1) ), [3] OCTET STRING (0...36 )

SpecificOutput ::= SEQUENCE OF AttributeValue RSDP-MethodID Allocation Table:

2006-08-30


Page 163 of 203

~53F3.doc


Table 5-1 RSDP-methodID allocation table Service key for the message to reach the service MethodID Service key for the message to originate the service GPRS-IN (forward 0 20 102 GPRS-IN subscribers request operation SCP) Ring back tone service IUSER 2, SMP_SUPPLY 1 1 (VC end) 301, UC2 1 UUA IUSER 2, SMP_SUPPLY 1 2 (VC end) 301, UC2 1 UUA Query 1 4 (VC end) 2 IUSER state of the the Bank signaling specification (V1.0) the Bank of the signaling card flow card flow 1001, 100, FNS Modify state card of the Prepaid the signaling specification (V4.2) service flow 1001, 100, FNS SCP sends to AIP the state query Query information about PPS rechargeable card t Prepaid the signaling specification (V4.2) service flow to 2.0 the Application service version Meaning of the message Reference document

0

45

1,91

rechargeable

rechcharging bank card

recharge service

1 5 (VC end) 2 IUSER

Modify state

rechcharging

recharge service

2006-08-30


Page 164 of 203

~53F3.doc


Service key for the message to reach the service MethodID

Service key for the message to originate the service bank card specification (V1.0) In the query WIN V200R002 SMP (query the Application service version Meaning of the message Reference document

function, query SER 1 10 (VC end) 1001 SMP_SUPPLY the about card Query 1 15 (VC end) 2, 201, 301 IUSER UC2 information about card Modify state 1 16 (VC end) 2, 201, 301 UC2 IUSER of the the rechargeable the information rechargeable 2.0 card)

basic recharge service the rechargeable detailed design instruction Unified recharge service signaling flow specification (V1.0)

the Unified recharge rechargeable service signaling card flow specification (SCP end (V1.0) outputs the bill) Modify state of the

1 17 (VC end) 2, 201, 301 UC2 IUSER

the Unified recharge rechargeable service signaling card flow specification (VC end (V1.0) outputs the bill) Support the

IUSER3.1D20 1 52 201, 1 UC2v2.1d20 1 53 201, 1 IUSER3.1D20

recharge query message of the private account Support thePage 165 of 203

2006-08-30


~53F3.doc



Service key for the message to originate the service UC2v2.1d20 non-local recharge SCP interconnection message of the private account IUSER Handle FNS loss Prepaid signaling specification (V4.2) service flow Application service version Meaning of the message Reference document

1

3

2, 100, 1 UUA PPIP

report/loss report cancellation

PPIP 2 1 (VC end) MPH 2, 4, 30 IUSER

Query information the card

the of PPIP

Fixed Subscriber Prepaid Flow Specification (V3.0) IP Service Signaling

rechargeable

PPIP 2 2 (VC end) MPH 2, 4, 30 IUSER

Modify state PPIP of

the the

Fixed Subscriber Prepaid Flow Specification (V3.0) IP Service Signaling

rechargeable card Query the of

2

6

2

PPIP

information card

th e PPIP local

IUSER Handle FNS 2 3 2, 100, 1 UUA PPIP report/loss report cancellation loss Prepaid signaling specification (V4.2) service flow

2006-08-30


Page 166 of 203

~53F3.doc



Service key for the message to originate the service According the to short non-local Mobile dedicated network signaling specification (V3.1) to real non-local service flow virtual Application service version Meaning of the message Reference document

number, query 3 6 3 VPN the SCP subscriber information According the 3 7 3 VPN the SCP subscriber information Query subscriber charge package 3 8 3 VPNV6.1 information and closed group Query subscriber short number, 3 9 3 VPNV6.1 group number and closed group 3 10 3 VPNV6.1 Query the user number of the VPN VPN

Mobile dedicated network signaling

virtual service flow

number, query

specification (V3.1)

WIN

V200R002

VPNV6.1 Demand the Specification user

number of the Instructions

WIN

V200R002

VPNV6.1 Demand Specification Instructions

the WIN

V200R002

charge rate of VPNV6.1

2006-08-30


Page 167 of 203

~53F3.doc



Service key for the message to originate the service the VPN closed Demand user group and Specification apply update for or Instructions the Application service version Meaning of the message Reference document

group package free-of-charge time Apply for the 3 11 3 VPNV6.1 group package free-of-charge time WIN V200R002

VPNV6.1 Demand Specification Instructions WIN V200R002

Query the cell VPNV6.1 3 12 3 VPNV6.1 accessed VPN users by Demand Specification Instructions According the 3 20 3 vpn6.1D45 the SCP subscriber information According number to WIN V200R002 to long non-local VPN61D45 Demand Specification Instructions

number, query

the type of the 3 40 3 VPNV6.1 used, query the long number of the VPN user 1216, 4 12 2, IP17951V1.0D10 0, PPIP, Non-local account transfer

VPNV6.1 Demand Specification Instructions China Mobile Flow

17951 IP Service and Signaling

2006-08-30


Page 168 of 203

~53F3.doc



Service key for the message to originate the service 1230 IUSER, EA account opening Specification (v1.31), Subscriber Prepaid Flow Specification V3.0 China IP17951V1.0D10 1216, 0, Non-local PPIP, IUSER, EA recharging other mobiles Signaling Specification (v1.31); by Subscriber Prepaid Flow Specification V3.0 China IP17951V1.0D10 1216, 0, IUSER, PPIP, EA Non-local account transfer account cancellation Signaling Specification (v1.31),Fixed and Subscriber Prepaid Flow Specification V3.0 Query the IP Service Signaling Mobile Flow IP Service Signaling Fixed Mobile Flow IP Service Signaling Fixed Application service version Meaning of the message Reference document

17951 IP Service

4

13

2, 1230

17951 IP Service

4

14

2, 1230

4

15

2

PPIP

temporary account

2006-08-30


Page 169 of 203

~53F3.doc



Service key for the message to originate the service China Mobile Flow Application service version Meaning of the message Reference document

4

17

4, 1216

IP17951V1.0D10 0

Query the call 17951 IP Service privilege of the Signaling user Specification (v1.31) China Mobile Flow

4

20

1216

IP17951V1.0D10 Roaming 0 recharging

17951 IP Service Signaling Specification (v1.31)

Notify 4 21 4, 1216 IP17951V1.0D10 subtraction 0 of the user

the of

China Signaling

Mobile Flow

17951 IP Service Specification (v1.31) China Mobile Flow

th call charge

4

22

1216

IP17951V1.0D10 0

Query account information

the 17951 IP Service Signaling Specification (v1.31)

IP 4 30 4, 1216 IP17951 universal

17951

recharging message Fixed Subscriber

PPIP 5 12 2, 1230 IUSER EA

Non-local account transfer opening

Prepaid and Flow Specification (V3.0)

IP

Service Signaling

5

13

2 , 1230

Non-local recharging

Fixed Subscriber by Prepaid IP

2006-08-30


Page 170 of 203

~53F3.doc



Service key for the message to originate the service PPIP IUSER EA other mobiles Service Signaling Flow Specification (V3.0) Fixed Subscriber PPIP Non-local account transfer cancellation Prepaid and Flow Specification (V3.0) Query the call IP Service Signaling Application service version Meaning of the message Reference document

5

14

2 , 1230

IUSER EA

5

17

2, 1230

EA

privilege of the user

5

20

2 , 1230

EA

Roaming recharging Notify the of

5

21

2 , 1230

EA

subtraction of the user Query

the call charge

the

5

22

2 , 1230

EA

account information

Service key for the message to reach the service 6 25 MethodID

Service key for the message to originate the service 6 SPL Conduct the calling/called Calling/Called Free Applicatio n service version Meaning of the message Reference document

party authentication handling Party

2006-08-30


Page 171 of 203

~53F3.doc



Service key for the message to originate the service to the caller pay service, Phone Service select the calling/called Signaling Specification (draft the phone to be reviewed) subscriber type: Lists to be sent: 1, id_oi_msisdn: mobile Applicatio n service version Meaning of the message Reference document

called-party number;

2, id_oi_roam: the roaming location of the calling party (such as 755); 3, id_oi_roam: the roaming location of the called party (such as 755); 4, 2: id_oi_authorizetype: authenticate 3: the 1:

authenticate the calling party; called the the at party; authenticate party

calling/called same time.

Lists to be received: 1, 0 fail; 1 succeed Conduct the calling/called

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

called-party

2006-08-30


Page 172 of 203

~53F3.doc



Service key for the message to originate the service number; 2, id_oi_roam: the roaming location of the calling party (such as 755); 3, id_oi_roam: the roaming location of the called party(such as 755); 4, 2: id_oi_authorizetype: authenticate 3: the 1: Applicatio n service version Meaning of the message Reference document

authenticate the calling party; called the the at party; authenticate party

calling/called same time.

Lists to be received: 1, 0: fail; 1: incoming call; 2: password required Whether open-account party: Lists to be sent: 6 27 6 SPL 1, id_oi_roam: the area code of the access location of the calling party (such as 755) 2, number Lists to be received: id_oi_msisdn: mobile to conduct and authentication is

authentication to the calling Calling/Called Party Signaling Specification (draft to be Free Phone Service

the reviewed) phone

calling-party

2006-08-30


Page 173 of 203

~53F3.doc



Service key for the message to originate the service 1, 0: the account is not opened,1: the account has been opened, 2: the account has been opened but suspended for use temporarily Add the numbers added by the user and that can be dialed in into the list: Lists to be sent: Calling/Called Applicatio n service version Meaning of the message Reference document

Free 1, id_oi_msisdn: the number Party input by the user and allowed Phone Service 6 28 6 SPL to be dialed in; 2, id_oi_msisdn: mobile Signaling Specification the (draft to be phone reviewed)

calling-party number;

Lists to be received: 1, 0: fail; 1: succeed

Update the list of numbers allowed to be dialed in after they are modified by the user: Lists to be sent: Calling/Called Party Free 1, id_oi_msisdn: the number Phone Service input by the user and allowed Signaling to be dialed in; 2, id_oi_msserial: modified mobile by serial the the phone Specification (draft to be reviewed)

6

29

6

SPL

number of the incoming call number user;3, id_oi_msisdn:

calling-party

2006-08-30


Page 174 of 203

~53F3.doc



Service key for the message to originate the service number; Lists to be received: 1, 0: fail; 1: succeed; 2: Applicatio n service version Meaning of the message Reference document

the number of this serial No. has not been set yet User activates the service update table data processing: Lists to be sent: 6 30 6 SPL 1, id_oi_msisdn: mobile the phone Calling/Called Party Signaling Specification (draft to be reviewed) Free Phone Service


Lists to be received: 1, 0: fail; Update 1: succeed the incoming call

mode of the user into the password mode and select the password set by the user; Lists to be sent: 1, 6 31 6 SPL id_oi_pinmode: call mode Calling/Called Free the Party (1 Phone Service Signaling Specification the (draft to be phone reviewed)

incoming

password mode) 2, id_oi_msisdn: mobile


Lists to be received: 1, id_oi_mspinnumber: the call password;

2006-08-30


Page 175 of 203

~53F3.doc



Service key for the message to originate the service 2, 0 : fail; 1: succeed Update the password modified by the user: Lists to be sent: Calling/Called the Party Free password modified by the Phone Service 1, id_oi_mspinnumber: Applicatio n service version Meaning of the message Reference document

6

32

6

SPL

user; 2, id_oi_msisdn: mobile

Signaling the Specification phone (draft to be reviewed)


Lists to be received: 1, 0: fail; 1: succeed

User suspends the service update table data processing: Lists to be sent: 6 33 6 SPL 1, id_oi_msisdn: mobile the phone Calling/Called Party Signaling Specification (draft to be reviewed) Free Phone Service


Lists to be received: 1, 0 : fail; Validate is correct: 6 34 6 SPL Lists to be sent: 1, id_oi_mspinnumber: 1: succeed whether

the Calling/Called Free Phone Service Signaling Specification the (draft to be

password entered by the user Party

password entered by the user; reviewed)

2006-08-30


Page 176 of 203

~53F3.doc



Service key for the message to originate the service 2, number Lists to be received: 1, 0: fail; 1: succeed User opens an account: Lists to be sent: 1, id_oi_msisdn: mobile Calling/Called Party phone Signaling Specification (draft to be reviewed) Free the Phone Service id_oi_msisdn: mobile the phone Applicatio n service version Meaning of the message Reference document

called-party

6

35

6

SPL


Lists to be received:

WIN Products - Topic on the Analysis of the Signaling V1.0-20050401-B

Documents