1.OMA000004 NSS Signalling and Interface Analysis ISSUE3.3

OMA000004 NSS Signalling and interface analysis
Issue 3.3
OMA000004
NSS Signalling and interface analysis
ISSUE3.3
i
OMA000004 NSS Signalling and interface analysis Table of contents
Issue 3.3
Table of contents
Course Description............................................................................................................................ 1
Introduction to the Course.......................................................................................................... 1
Course Objectives...................................................................................................................... 1
Reference Documents............................................................................................................... 1
Chapter 1 Signaling Connection Control Part....................................................................................2
1.1 Overview.............................................................................................................................. 2
1.2 Inter-layer Interfaces of SCCP............................................................................................. 2
1.3 SCCP Message.................................................................................................................... 7
1.3.1 SCCP Message Structure............................................................................................7
1.3.2 SCCP Message Parameters......................................................................................10
1.3.3 SCCP Message Generation and Example.................................................................13
1.4 Connection-oriented Control Process................................................................................14
1.4.1 Common Process...................................................................................................... 14
1.4.2 Other Control Processes........................................................................................... 16
1.5 Summary............................................................................................................................ 18
1.6 Exercises............................................................................................................................ 19
Chapter 2 Transaction Capability Application Part...........................................................................20
2.1 Overview of TCAP.............................................................................................................. 20
2.1.1 Functions of TCAP..................................................................................................... 20
2.1.2 Composition of TCAP................................................................................................ 20
2.1.3 Application of TCAP................................................................................................... 22
2.2 Sub-layer Structure of TCAP.............................................................................................. 23
2.3 TCAP Message Structure................................................................................................... 29
2.3.1 ASN.1 Coding............................................................................................................ 29
2.3.2 TCAP Message Structure.......................................................................................... 32
2.3.3 Examples for TCAP Messages..................................................................................35
2.4 Summary............................................................................................................................ 36
2.5 Exercise............................................................................................................................. 36
Chapter 3 Mobile Application Part................................................................................................... 37
3.1 MAP Functions................................................................................................................... 37
3.2 MAP Message Format........................................................................................................ 40
3.2.1 Message Structure.................................................................................................... 40
3.2.2 MAP Message........................................................................................................... 40
3.2.3 MAP Message Code.................................................................................................. 42
3.3 Message Examples............................................................................................................ 43
3.4 Summary............................................................................................................................ 49
3.5 Exercise............................................................................................................................. 49
Chapter 4 Analysis of C/D Interface Messages...............................................................................50
4.1 Introduction........................................................................................................................ 50
4.2 Signaling Analysis of Typical Flow......................................................................................51
i
OMA000004 NSS Signalling and interface analysis Table of contents
Issue 3.3
4.2.1 Call Flow.................................................................................................................... 51

4.2.2 Location Updating Flow............................................................................................. 54
4.3 Brief Introduction to C/D Interface Flow..............................................................................57
4.4 Summary............................................................................................................................ 61
4.5 Exercise............................................................................................................................. 62
Chapter 5 Signaling Analysis of A Interface.....................................................................................63
5.1 Protocols of A Interface...................................................................................................... 63
5.2 BSSAP............................................................................................................................... 64
5.3 A Interface Flow.................................................................................................................. 68
5.4 Analysis of A Interface Messaged.......................................................................................71
5.4.1 Brief Introduction to A interface Messages.................................................................71
5.5 Message Analysis.............................................................................................................. 72
5.6 Summary............................................................................................................................ 95
5.7 Exercise............................................................................................................................. 95
Chapter 6 ISDN User Part............................................................................................................... 96
6.1 Overview............................................................................................................................ 96
6.2 Message Structure and Coding in ISUP.............................................................................96
6.3 ISUP Message Examples................................................................................................. 100
6.3.1 IAM.......................................................................................................................... 100
6.3.2 ACM......................................................................................................................... 106
6.4 ISUP Basic Signaling Flow............................................................................................... 111
6.4.1 Features of ISUP in an MSC (M900/1800)...............................................................111
6.4.2 Signaling Procedures of ISUP..................................................................................111
6.4.3 Implementation of ISUP in the M900/1800 System..................................................114
6.5 Summary.......................................................................................................................... 115
6.6 Exercises.......................................................................................................................... 115
6.7 Key to the Exercises......................................................................................................... 116
Appendix ASN.1 Coding of MAP Messages...................................................................................117
ii
OMA000004 NSS Signalling and interface analysis Course Description
Issue 3.3
Course Description
Introduction to the Course

This teaching material is applicable to the NSS of the M900/M1800 digital cellular
mobile communication system of Huawei.
This course includes two parts: The first three chapters are advanced contents
about the GSM signaling system, which mainly describe the SCCP, TCAP and
MAP of the Signaling System No. 7 (SS7), the chapter 4 deal with the analysis of
the network interfaces, which mainly describe the signaling flow and message
analysis method of the C/D interface and the A interface. The last chapter
introduces the ISUP.
Course Objectives
After this course, the trainees can master the following contents:
1. Inter-layer interfaces, message structure and parameters of the
SCCP and the connection-oriented control process
2. Sublayer structure and message format of the TCAP
3. MAP message structure and typical MAP message analysis
4. Message tracing and analysis of the C/D interface
5. Message tracing and analysis of the A interface introduces the
ISUP
Reference Documents
ETSI specifications: GSM09.02, GSM04.08 and GSM08.08
1
OMA000004 NSS Signalling and interface analysis Chapter 6 ISDN User Part
Issue 3.3
Chapter 1 Signaling Connection Control Part
1.1 Overview
From the elementary course of the signaling system, we have already got a
relatively systematic understanding of the characteristics and functions of the
Signaling Connection Control Part (SCCP). A quite detailed description of the
message structure of the SCCP has also been given in the elementary course.
However, the description of the SCCP within the NSS is emphasized in the
elementary course, but the SCCP used for the A interface is less mentioned.
Therefore, The SCCP will be further described in the advanced course of the
signaling system.
In this chapter, we mainly describe the parameters of the connection-oriented

messages and the connection-oriented control process of the SCCP.
1.2 Inter-layer Interfaces of SCCP

The SCCP is designed for combination with the third level of the MTP so as to
provide perfect Network Layer functions, and this reflects the tendency of the
convergence of SS7 and the OSI reference model. Therefore, Series of defining
methods and terms meeting the OSI standard are recommended for the SCCP. In
the OSI reference model, except the topmost layer and the bottommost layer, any
layer can be marked as the Nth layer, with its neighboring higher layer and lower
layer respectively marked as the (N+1) layer and the (N-1) layer. Where, the
(N+1) layer is called the user of the N layer for which the N layer provides service;
while the (N-1) layer is called the service provider of the N layer, which provides
communication connection for the N layer. The so-called service is that, under the
request of the (N+1) layer, the N layer communicates with the peer N layer in
another network node through the connection provided by the (N-1) layer
according to the specified N layer protocol so as to implement the message
exchange between the peer N+1 layers. It can be seen that when the (N+1) layer
requests service from the N layer or when the N layer provides service
information for the (N+1) layer, some interactions are needed between the service
user and the service provider, i.e., the inter-layer interface exists between the
neighboring layers. In the OSI reference model, the service primitive is used to
define the inter-layer interface.
The service interfaces from the SCCP to the upper layers and the MTP are
described with the primitives and parameters, as shown in Figure 1-1.
2
Issue 3.3
Higher layer
Service primitive
SCCP service
Service access point Signaling connection control part
Service primitive MTP service
Message transfer part
Figure1.1 Service primitive
Four types of primitives are specified in the OSI:

6. Request
7. Indication
8. Response
9. Confirmation.
The above four types of primitives completely describe the full process of a round
of service between two peer (N+1) layers. For the SCCP, its lower layer is the
MTP and the corresponding primitive is marked as MTP-primitive. Its upper layer
is the SCCP user. The SCCP provides the user with the OSI Network Layer
function, so the primitive between the SCCP and its user is marked as N-
primitive, also called SCCP user primitive. Figure 1-2 shows the primitive marking
method of the inter-layer interfaces of the SCCP. Where, the SCCP message is
the communication message carrier between the peer entities of the SCCP.
3
Issue 3.3
Network service Network service

subscriber subscriber
Confirmation Indication
Request Response
SCCP message
SCCP SCCP
MTP message
MTP MTP
Figure1.2 Inter-layer interfaces of the SCCP
The above only describes the four types of primitives. In fact a complete primitive
includes the primitive name, primitive type and primitive parameter, as shown in
Figure 1-3.
Generic name Special name Parameter
Figure1.3 Syntactic structure of a primitive
Where:
: Indicating the service-providing functional block.
Generic name: i.e., the primitive name, indicating what kind of service is provided.
Special name: i.e., the primitive type, indicating the direction of the primitive flow.
Parameter: The data necessary for implementing the service specified in the
protocol.
For example: When a signaling message is sent to its destination in the form of
UDT through the connectionless service protocol and the destination SCCP
transfers the data to its user, the indication primitive of its unit data is: N-
UNITDATA. Indication (CDA, CGA and UD). Where, N indicates the primitive of
the Network Layer (i.e., the SCCP), the CDA, CGA and UD are the primitive
parameters, respectively indicating the called address, calling address and the
subscriber data.
4
Issue 3.3
Table 1-1 lists the SCCP user primitives and applicable protocol types used in
various network services of the SCCP.
Table3.1 SCCP user primitives used for network services
Primitive name Primitive type Protocol type Primitive parameter
0 1 2 3
N-UNITDATA Request v v CDA CGA SEQ RO UD
Indication v v CDA CGA UD
N-NOTICE Indication v v CDA CGA RR UD
N-CONNECT Request v v CDA CGA RCS EDS CI
Indication v v QOS UD CI
Response v v RA RCS EDS CI
Confirmation v v QOS UD CI
N-DISCONNECT Request v v RA REA UD CI
Indication v v OR RA REA UD CI
N-DATA Request v v CR UD CI
Indication v v
N-DATA ACKNOWLEDGE Request v CI
Indication v
N-EXPEDITED DATA Request v UD CI
Indication v
N-RESET Request v REA CI
Indication v OR REA CI
Response v CI
Confirmation v
N-INFORM Request v v REA QOS CI
Indication v v
The meanings of the abbreviations indicating the primitive parameters are as

follows:
CDA: Called Address
CGA: Calling Address
CI: Connection Identifier
CR: Confirmation Request
EDS: Expedited Data Selection
5
Issue 3.3
QOS: Quality of Service parameter set

OR: Originator
RA: Response Address
RCS: Received Confirmation Selection
REA: Reason
RO: Return option
RR: Return reason
SEQ: Sequence Control UD: User data
Where,
N-UNITDATA: Unit data primitive, used for unit data transfer in the connectionless
service mode (UDT).
N-NOTICE: Notice primitive, used for notifying the message originator,
destination or the transfer point that the SCCP cannot send the message in the
connectionless service mode.
N-CONNECT: Connection primitive, used for connection setup.
N-DISCONNECT: Disconnection primitive, used for disconnection.
N-DATA: Data primitive, used for data transfer in the connection-oriented service
mode.
N-DATA ACKNOWLEDGE: Data acknowledgement primitive, used for
acknowledging that the remote request confirmation message has been received.
N-EXPEDITED DATA: Expedited data primitive, used for the Class-3 protocol to
transfer emergent expedited data.
N-RESET: Reset primitive, used for Class-3 protocol to transfer the connection
reset message so as to reboot the flow control process from the initial state.
N-INFORM: Informing primitive, used for the connection-oriented service to
transfer related network or user information in the data send-off stage.
The service interface between the SCCP layer and the MTP layer is implemented
through the MTP primitives. The relevant MTP primitives are shown in Table 1-2:
Table3.2 MTP service primitives
Primitive Parameter
Primitive name Special name
MTP-TRANSFER Request Indication SCCP message
MTP-RESUME Indication Signaling point influenced
MTP-PAUSE Indication Signaling point influenced
6
Issue 3.3
MTP-STATUS Indication Signaling point influenced
MTP-UPU Indication Signaling point influenced
Where:
MTP-TRANSFER request: Used for the SCCP to access the signaling message
processing function of the MTP.
MTP-TRANSFER indication: The message processing function of the MTP
transfers the signaling message to the SCCP.
MTP-PAUSE indication: Sent by the MTP, indicating that it cannot transfer the
message to the designated destination.
MTP-RESUME indication: Sent by the MTP, notifying the user that the MTP can
provide the MTP service to the designated destination.
MTP-STATUS indication: Sent by the MTP, notifying the user that the MTP can
only partially provide the MTP service to the designated destination. This primitive
also is used to inform the user of the reason why the corresponding remote user
is available or unavailable.
Please note that not every primitive includes all the four types; this depends upon
the protocol process of the specific service.
1.3 SCCP Message

After receiving the primitive request or response sent by a user, the SCCP will
encapsulate the subscriber data and necessary control and routing information
into the SCCP message according to the primitive parameters and then send the
message to the remote peer SCCP entity. In the elementary course, we have
already described the UDT message format in details, so in this section, we will
first briefly review the SCCP message structure and then describe the SCCP
message parameters in detail.
1.3.1 SCCP Message Structure
The SCCP message is encapsulated into the MSU (Message Signal Unit) of the
MTP before being sent out. For the MSU, the SCCP message is its SIF field. It is
composed of the following parts:
---- Route label
---- Message type
---- Fixed length mandatory part (F)
---- Variable length mandatory part (V)
---- Optional part (O)
7
Issue 3.3
The SCCP message structure is shown in Figure 1-4
F CK SIF SIO LI FIB FSN BIB BSN F
Mandatory parameter A
Routing label

Message type Mandatory parameter

Mandatory fixed part Pointer of parameter M
(F)

Pointer of parameter P
Mandatory variable
Start pointer of optional
part (V)
item
Length of parameter M
Parameter M
Optional part (O)

Length of parameter P
Parameter P
Parameter name X
Length of parameter X
Parameter X
Parameter name Z
Length of parameter Z
Parameter Z
Optional parameter end
Figure1.1 SCCP message structure
10. Routing label (Label): The structure is DPC+OPC+SLS.

11. Message type: Used to identify different SCCP messages. Table 1-
3 shows the message type codes of some common messages:
Table1.1 Common SCCP message types and codes
Message type Protocol type Code
8
Issue 3.3
0 1 2 3
Connection Request (CR) * * 0000 0001
Connection Confirmation (CC) * * 0000 0010
Connection Refused (CREF) * * 0000 0011
Connection Released (RLSD) * * 0000 0100
Release completed (RLC) * * 0000 0101
Data (DT1) * 0000 0110
Data (DT2) * 0000 0111
Protocol data unit Error (ERR) * * 0000 1111
Inactivity Test (IT) * * 0001 0000
Unit Data (UDT) * * 0000 1001
Unit Data Service (UDTS) * * 0000 1010
Message explanation:
1. The CR and CC set up the signaling connection.
2. During the signal connection setup, the CREF is the signal sent to
the source node when the intermediate node or destination node
of the SCCP does not have sufficient resources.
3. The DT1, DT2 and ED are several kinds of messages used to
transfer data after the signal connection is succeeded.
4. The RLSD and RLC are used to release the signal connection
after the data transfer.
5. The ERR will be sent if any protocol error is detected and the IT is
used to detect whether the both ends of the signal connection
work normally.
6. The UDT and UDTS are connectionless service messages. The
UDT is used to transfer the connectionless service data. The
UDTS is sent to the source to indicate the reason why the UDT
cannot reach the destination.
12. Fixed length mandatory part: i.e., all mandatory parameters of the
message with fixed length.
13. Variable length mandatory part: i.e., all mandatory parameters of the
message with variable lengths.
14. Optional part: i.e, all optional parameters of the message.
9
Issue 3.3
1.3.2 SCCP Message Parameters
The SCCP message includes 17 kinds of parameters in total. Table 1-4 lists the
parameter names, codes and their inclusion relationship in various message
types. Where, M indicates mandatory parameter and O indicates optional
parameter.
Table1.1 SCCP message parameters
Parameter field Message Parameter
message type name code

U U C C C R R D D A E E R R E I
D D R C R L L T T K D A S S R T
T T E S C 1 2 R C R
Destination local M M M M M M M M M M M M M 00000001
reference
Source local reference M M M M M M M 00000010
Called address M M M O O 00000011
Calling address M M O 00000100
Protocol type M M M M 00000101
Segmentation/reassembly M 00000110
Message receiving M 00000111
sequence number
Sequence/Segmentation M M 00001000
Credit O O M M 00001001
Release reason M 00001010
Diagnosis M O O O 00001011
Reset reason M 00001100
Error reason M 00001101
Subscriber data M M O O O O M M M 00001111
Rejection reason M 00001110
Optional parameter ends O O O O O O 00000000
Parameter explanation:
1) Destination local reference and source local reference
10
Issue 3.3
The destination local reference and source local reference are used for the
connection-oriented service and are the internal numbers used to identify the
connection segment by the destination and source SCCP of the signaling
connection segment. They are independently allocated by the SCCPs at both
ends when the connection is created. This references are used for the later data
transfer messages to indicate the transfer paths. The parameter length is three
octets. All-1 codes are reserved.
2. Called address and calling address
The called and calling address are used to identify the destination, start signaling
point and the user part. For the connectionless messages, they indicate the
destinations and start points of the SCCP messages. In the connection-oriented
service, they are only used for the connection setup and connection confirmation
messages to indicate the start and source points of the signaling connection (not
the signaling connection segment). They belong to variable length parameters.
Their codes have been described in the elementary course in detail.
3. Protocol type
It has been described in the elementary course, so no further description will be
given here.
4. Segmentation/reassembly
It is used in DT1 where the network service data are divided into several
segments transmitted separately, and then the data are reassembled after
reaching the destination. The coding mode is:
87654321
M
Bits 2-8 are standby and bit 1 is the segmentation/reassembly indication bit,
which is called M bit:
If M=0, it indicates there are no more data; if M=1, there are more data.
5. Message receiving sequence number and credit
The message receiving sequence number and credit are mainly used for the data
confirmation message, respectively indicating the sequence number of the next
expected message and the window size. They are used for the flow control. The
two parameters are only used for protocols of class 3.
6. Sequence/segmentation
The sequence/segmentation is used for the DT2 message, with a length of two
octets. It has two roles: (a) indicating the sequence number of the sent message
and the sequence number of the next expected message, used for the flow
control; (b) indicating whether the message is segmented, used for message
segmentation/reassembly.
11
Issue 3.3
7. Release reason
The release reason is used to indicate the reason for connection release. Its
length is one octet, and the code is as follows:
87654321
00000000 Endpoint user originates the release
00000001 Endpoint user is busy
00000010 Fault
00000011 Remote control process error
00000100 Destination incompatible
00000101 Illegal functional request
00000110 Access disabled
00000111 Network congestion
00001000 Unavailable
00001001 Unauthorized
Others Standby
8. Diagnosis parameter
The diagnosis parameter is used for the UDTS message of the connectionless
protocol, informing the reason for message return. The parameter length is one
octet, with the following code:
87654321
00000000 This type of addresses cannot be translated
00000001 The address cannot be translated
00000010 congestion
00000011 Failed
00000100 User not installed
Others Reserved
9. Reset reason, reject reason and error reason
They indicate the reasons for connection reset, connection reject and protocol
error
10. Subscriber data
The content of this field is that the subscriber data sent in the primitives by the
SCCP user sending message will be transparent sent to the destination SCCP
user.
12
Issue 3.3
1.3.3 SCCP Message Generation and Example
Figure 1-5 shows how the SCCP generates a unit data message (UDT) after
receiving the N-unit data sent by the user. The digits in the figure show the
number of bits occupied by the corresponding field.
Network service Network service

subscriber subscriber
Confirmation Indication
Request Response
SCCP message
SCCP SCCP
MTP message
MTP MTP
Figure1.1 UDT message generation and encapsulation
The message generation procedures are as follows:

1) Generating the parameter Message type according to the primitive name
and primitive type, indicating that it is a UDT message.
2. Determining whether the SCCP of the subsequent node should
return the original message if the message cannot be sent out
according to the Return Option parameter (RO) among the
primitive parameters so as to determine bits 8 to 5 of the
parameter Protocol type.
3. Determining the protocol type according to the sequence control
parameter (SC) among the primitive parameters. If it required that
the message should be transmitted sequentially, then class-1
protocol is used, or class-0 protocol will be used. Thus, the bits 4
to 1 of the parameter Protocol type are determined.
If the class-1 protocol is used, please determine the SLS value according to
the SC parameter value, or select an SLS value randomly.
4. With the translation and processing of the SCRC function module,
13
Issue 3.3
transform the calling address parameter (CGA) and the called

address parameter (CDA) among the primitive parameters into the
calling and called addresses in the UDT message and obtain the
DPC for the MTP addressing, and meanwhile please fill in the
OPC code of the this node.
5. Pack the untouched subscriber data in the primitive parameters
into the subscriber data field of the UDT message.
6. Set the service indicator SI=0011, indicating the MTP that its user
is the SCCP.
Up to now, a complete UDT message is formed. Thus, as soon as the MTP
transfers, the request primitives will be sent to the MTP. Finally, the whole
UDT message is embedded into the MTP message as the SIF field and is
transmitted to the far end through the signaling network.
1.4 Connection-oriented Control Process

The CCITT Recommendations have specified the following eight connection-
oriented control processes: connection setup, connection reject, connection
release, data transfer, expedited data transfer, connection reset, reboot and
inactivity control. they completely describe the control process of the connection-
oriented message transfer in various conditions. We will emphasize on the
common process of the connection-oriented service control, and then gives a
brief introduction to the message segmentation/reassembly and fault handling.
1.4.1 Common Process
It has already been described in the elementary course that the signaling control
process of the connection-oriented service is composed of three stages:
connection setup stage, data transfer state and connection release stage. Figure
1-6 shows the control process of a successful connection with intermediate
transfer point, including the primitive interface of the SCCP user.
SCCP1 subscriber SCCP1 SCCP3 SCCP2 SCCP2 subscriber
N-CONN.REQ(CI1) CR(SLR1) CR(SLR2) N-CONN.IND(CI2)
N-CON.CONF(CI1) CC(DLR1,SLR1) CC(DLR2,SLR2) N-CONN.RSP(CI2)
N-DATA. REQ (CI1) DT1(DLR1) DT1(DLR2) N-DATA.IND(CI2)
N-DATA.IND(CI1) DT1(SLR1) DT1(SLR2) N-DATA.REQ(CI2)
N-DISC.REQ(CI1) RLSD(SLR1,DLR1) RLSD(SLR2,DLR2) N-DISC.IND(CI2)
RLC(DLR1,SLR1) RLC(DLR2,SLR2)
14
Issue 3.3
Figure1.1 Common process of connection-oriented signaling control
1. Connection setup and data transfer:
In the connection-oriented service, a parameter is used to uniquely identify the

logic signaling connection corresponding to the message: In the N-primitive, this
parameter is CI, i.e., the connection identifier. In the message related to the
connection setup and release, this parameter is the local reference, i.e. the SCCP
user identifies connections through the CI, while the SCCP identifies the
connections through the local reference. During the connection setup stage, the
calling and called parties create the corresponding relationship between them
one by one through table.
A connection can be composed of certain number of cascaded connection
segments, that is to say, the local reference is used to identify the connection
segments. Each connection segment has a pair of references, i.e., the SLR
(Source Local Reference) and DLR(Destination Local Reference).
When requesting a connection, the originator of the connection segment allocates
the SLR which is used to identify this connection segment later. The terminal of
the connection segment allocates and uses the DLR. The SLR and DLR are
mutually independently, generally with different values.
Except the CR (Connection Request) message, all the other messages in the
connection-oriented service have the mandatory parameter DLR so that the
opposite party can judge to which connection segment the message belongs.
Please note the destination in this parameter refers to the destination of the
current message, i.e., the peer end of the connection segment transferring the
message. If the message transfer direction is opposite to the connection setup
direction, then the DLR of the message is the SLR allocated to the connection
segment during the connection setup.
Besides the connection identification, the local reference also has the following
functions:
1) The SCCP at the message originator allocates the SLS according to the SLR
of the message and the SCCP at the message receiving end identifies the
message according to the DLR so as to guarantee the consistency of the
transmitting/receiving sequence for the connection-oriented message
transfer.
2. An intermediate transfer point establishes the cascading of two
neighboring connection segments through the local reference. As
SCCP3 shown in Figure 1.4-1, the link table of the (SLR1, DLR1)
and (SLR2, DLR2) is set up during the connection setup stage.
After that, as soon as a message from any connection segment is
received, it can be transferred to another connection segment
15
Issue 3.3
through looking up the table.

3. With the application of the local reference identification system,
the signaling multiplexing between any two signaling points can be
implemented for multiple connections, this is the reason why the
signaling connection is called the virtual connection.
One important characteristics of the connection-oriented is that once a
connection is set up, then all messages transfer in this connection only have
local reference, but do not have the calling and called addresses.
2. Connection release
The release of a connection can be originated by the calling subscriber or the

called subscriber (as shown in Figure 1.4-1), or can be originated by any SCCP
(including the intermediate SCCP). If the endpoint SCCP originates the
connection release, then it will send the N-DISC.IND primitives to its own users at
then same time when the SCCP sends the connection release message to the
peer end of the connection segment. If the intermediate SCCP originates the
connection release, then it will simultaneously send the RLSD message to the
connection segments at both sides.
3. Failed connection setup
If any SCCP finds there is no sufficient resources during the connection setup
request, then it can reject the request. For the intermediate SCCP or the
destination SCCP, it will send the CREF message to the forward (calling
direction) connection segment and also point out the reject reason in the
message. After receiving the message, the originating SCCP will send the N-
DISCONNECT.IND to its user. If the originating SCCP does not have sufficient
resources, then it will directly reject the user.
Another possible condition is that the SCCP at the intermediate transfer point
does not receive any connection confirmation message after timeout when it
sends out the backward connection request message. In this case, the
intermediate SCCP will send the backward connection release message and the
forward connection reject message. If the originator is timeout, then the resources
will be released directly. The connection reject can also be originated by the
called subscriber.
16
Issue 3.3
1.4.2 Other Control Processes
1. Message segmentation and reassembly
We have already known that the SCCP message is built in the MTP message as
the SIF field. According to CCITT Recommendations, the maximum length of the
SIF is 272 octets. It can be seen from Figure 1.3-1 that other fields except the
subscriber data occupy 17 octets. Therefore, the maximum length of the field
subscriber data of the SCCP data message is about 255 octets. If the length of
the data (NSDU) a user required to transfer exceeds this value, then in the
connection-oriented protocol, the originating SCCP can unpack the data into
several data messages for transfer. Except the last message, the M bits of all
these data messages are set as 1, indicating there are uncompleted data after it.
The receiving end reassembles the field subscriber data in all the data
messages with the M bit of 1 and the subsequent data message with the M bit of
0 into the original NSDU and transfer it to the called subscriber.
Both the class-2 and class-3 protocols of the connection-oriented service have
this function. Huawei XUDT and XUDTS of class-0 and class-1 protocols of the
connectionless service also support this function.
2. Fault handling
Fault handling includes the inactivity control, protocol error control and reboot
process:
15. Inactivity control
The so-called inactivity control refers to no message transmitting/receiving is
conducted in a certain connection for a long period of time. This phenomenon is
likely caused by fault. For example, during the connection setup stage, the
Connection Confirmation (CC) message is lost; during the data transfer stage, a
certain connection is cleared without notice; the data of the connection saved at
both ends of the connection conflict with each other. In these cases, the
connection cannot work normally forever.
To prevent the node resources from invalid occupation for a long period of time,
these faults should be detected and the system should be restored. This is the
function of the inactivity control process.
The inactivity control requires that two timers should be set at both ends of each
connection segment: Sending inactivity timer (Tias) and receiving activity timer
(Tiar). The timing value of the later is greater than the former.
In this connection segment, the Tias will reset every time when a message is sent
and the Tiar will reset every time when a message is received. If the Tias is
timeout, it indicates that no message has been sent for a long time and an
17
Issue 3.3
inactivity test message (IT) will be sent immediately. The IT message only
includes the parameters related to the connection characteristics, i.e., the
protocol type, sequence/segmentation parameter and credit. After receiving this
message, the receiving end will compare these messages with the messages
reserved locally. If these messages conflict each other, then:
1) If the source local reference or the protocol type conflicts, the connection will
be released.
2) If the sequence/segmentation parameter or credit conflicts, the connection
will be reset.
If finally no message is received when the Tiar is timeout, it indicates that the
connection or the peer node has failed. Thus, the connection release process will
be started and the node resources will be released.
16. Protocol error processing
The protocol errors can be divided into the following types:
1) Syntax error: The format of the received message does not meet the
specifications of the SCCP, such as illegal message type, local reference not
allocated, etc.
2. Logic error: The received message is not the message allowed to
be entered at the current state of the connection segment, such as
a confirmation message is received, but actually no request
message is sent, the length of the subscriber data field in the data
message is too long, etc.
3. Transmission error: Message loss or confirmation timeout.
Besides discarding the received error messages, the SCCP at the receiving end
also conducts the following processing according to different errors:
1) No further processing will be made.
2) The connection release message will be sent with the release reason
informed.
3) The connection reset message will be sent with the reset reason informed.
4) The protocol data unit error message (ERR) will be used to inform the
opposite party of the error.
For the specific handling method, please refer to Appendix B in Recommendation
Q.714.
17. Reboot process
Reboot refers to the restoration process of the signaling connection segment after
a node fails. Its function is similar to the reboot of the fault restoration processing
of an SPC switch. The basic restoration method is to release all connection
18
Issue 3.3
segments used before the fault and then restart the normal connection-oriented
service process.
1.5 Summary
This chapter mainly describes the inter-layer interfaces, message structure and
message parameters and the connection-oriented control process of the SCCP.
Through the learning of this chapter, we should master the message structure of
the SCCP, understand the main parameters of the SCCP message and be
familiar with the connection-oriented control process of the SCCP.
1.6 Exercises
1. Please analyze the following SCCP message and write out the routing label,
message type and parameter part.
3F 83 11 FF 03 09 FF 05 0D 09 81 03 0E 18 0B 12 06 00 12 04 68 31 39 31 00
00 0A 12 07 00 12 04 68 31 09 40 67 2A 62 28 48 04 2B 81 11 00 6C 80 A1 80
02 01 00 02 01 02 30 16 04 08 64 00 30 31 08 00 51 F4 81 06 91 68 31 09 40
67 00 00 00 00
2. Please give a brief introduction to the common connection-oriented control
process of the SCCP.
19
Chapter 6 ISDN User Part
Issue 3.3
Chapter 2 Transaction Capability Application Part
2.1 Overview of TCAP
2.1.1 Functions of TCAP
A type of message is associated with the call setup and release of the circuit
switching. The message transfer is closed related to the control of specific
applications, for example, the TUP and ISUP should work out different protocols
according to different applications so as to form various MTP user parts targeting
at specific applications.
With the increasing development of the telecom industry, the telecom networks
gradually become intelligent and integrated. The subsequent various application
services (for example, the intelligent network services such as called payment
and VPN, the Operation, Maintenance and Administration Part (OMAP) of the
signaling network, Mobile Application Part (MAP) and Closed User Group (CUG),
etc.) require that the databases between the switches and that between the
switch and the network center should be associated so as to provide the
information request and response function between them. If a group of message
types is specially designed for each new application according to the traditional
method, not only the efficiency is low, but also the protocol management is very
complicated. Therefore, as a special network information interaction protocol
unrelated to applications in the Signaling System No.7 (SS7), the Transaction
Processing Capability Protocol (TPCP) plays more and more important roles in
various new services and SS7. The process and message structure of the
protocol is not related to specific applications. This is the Transaction Capability
(TC) protocol in SS7, which is not related to specific applications. The TC-user
part processes various different applications such as MAP, CAP, etc.
Here, the transaction refers to any interaction process between two network
nodes.
2.1.2 Composition of TCAP
Based upon the SCCP, the TCAP is composed of ISP and TCAP. The ISP refers
to the Intermediate Service Part, which corresponds to Layers 4 to 6 of the OSI
and is set up on the connection-oriented basis of the SCCP, while the TCAP
refers to the Transaction Capability Application Part, which corresponds to Layer
7 of the OSI and is set up on the connectionless basis of the SCCP.
According to the different requirements for data transfer, the TC users can be
divided into two categories:
20
Issue 3.3
1) Small volume of data transfer with strict real-time requirement

2) Large volume of data transfer with lower real-time requirement.
The users in the first class are called real-time users who pay attention to the
data transfer rate. For example, in the GSM system, during the call setup stage of
a user, the local switching office queries the HLR for the routing information of the
called party and the information transfer time will directly influence the delay after
dial-up. For this class of users, the ISP part has excessive overhead, so it is not
applicable. In this case, the TC only includes the TCAP, which directly uses the
connectionless service of the SCCP to transfer data.
The users in the second class are called offline users who mainly pay attention to
the security in data transfer and do not have strict requirements for data transfer
rate, for example, a switching office sends batch statistic data to the Network
Management Center, the sending time can be several seconds to several
minutes. For this class of users, the TC should include the ISP and need the
support of the connection-oriented service of the SCCP.
Based upon the SCCP, the TCAP is composed of ISP and TCAP. The ISP refers
to the Intermediate Service Part, which corresponds to Layers 4 to 6 of the OSI
and is set up on the connection-oriented basis of the SCCP, while the TCAP
refers to the Transaction Capability Application Part, which corresponds to Layer
7 of the OSI and is set up on the connectionless basis of the SCCP. The above
two structures are shown in Figure 2-7.
A BEGIN message IE is a
constructor Message type (62H) tag
Message length
Contents of BEGIN IE
Tag of source transaction ID (48H)
Length of source transaction ID
Contents of source transaction ID
This is an option, if there is no

Tag of component part tag (6CH) component part, the length field is set
as 0, but the component tag still exists

Contents of component part
Component 1
Component 2
Component n
21
Issue 3.3
Figure1.1 Connectionless and connection-oriented TC structures
2.1.3 Application of TCAP
18. Data exchange between switching offices

19. Switching office accesses the network database center.
20. Set up remote operation dialogue process between network
databases
To provide unified services for all users, the TCAP abstracts the information
interaction between different nodes as an operation, i.e., the start point invokes
an operation, and the remote destination node should request to execute the
operation and possibly can return the execution results to the start point. The
core of the TCAP is to execute the remote operation.
To implement a service process, many operations may be concerned between
the peer entities of two nodes. The combination of the execution of these related
operations forms a so-called dialogue (i.e., transaction). This kind of operation
model is similar to the man-machine dialogue of a computer: a user requests the
computer to execute a certain operation, the computer responds the request, it
may return the operation results or the computer will request the user to execute
an operation or displays that the request of the user cannot be understood. The
dialogue process will continue until the problem is solved.
Just as a dialogue sentence is composed of some basic words, a TCAP message
is also composed of basic components. A component corresponds to an
operation or an operation response. A message (dialogue) can include multiple
components. Thus limited number of components can form large quantities of
messages. The above unified message structure and syntactic rules are
applicable for TC users of any type. Therefore, the TCAP protocol is not related to
any specific applications, but the semantics of a message, i.e., the meaning of
the information included in each component and the sequence of the components
in a message, depends upon the specific application and is defined by the TC
user.
2.2 Sub-layer Structure of TCAP

To implement the control of the operations and dialogues, the TCAP is further
divided into two sub-layers---the Component Sub-Layer (CSL) and the
Transaction Sub-Layer (TSL). The CSL mainly conducts the operation
management, while the TSL conducts the transaction (dialogue) management.
The hierarchy is shown in Figure 2-8. The CSL interfaces with TC users through
the TCAP primitives and interfaces with the TSL through the TR primitives.
22
Issue 3.3
Application process (AP)
TC subscriber
TCAP service TC primitive
T
CSL
C
TR primitive
A
P TSL
Network service N-primitive
SCCP
MTP
Figure1.1 Hierarchy of TCAP
21. Transaction sublayer

The transaction sublayer implements the signaling communication process
between the local transaction sublayer user and the remote transaction sublayer
user and conducts the transaction management. The transaction sublayer user is
called the TR user. At present, the only known TR user is the Component
Sublayer (CSL). The communication between the peer CSLs is actual the
communication between the peer TC users, called dialogue. Therefore, in the
currently defined TCAP protocol, the transaction is completely equivalent to the
dialogue (they corresponds to each other one by one).
As mentioned above, the so-called dialogue is the signaling process to implement
an application service. During this process, two TC users exchange series of
TCAP messages. The start, end and order of the message exchange and the
message contents are controlled and explained by the TC user, while the
transaction sublayer manages the dialogue starting, holding and terminating,
including the fault detection and processing during the dialogue. Its protocol
process is applicable to the dialogues of any application services.
In the TCAP protocol, the dialogue can be divided into two types ---- Structured
dialogue and unstructured dialogue. This kind of classification is based upon
dialogue management and is not related to specific applications.
1) Unstructured dialogue
23
Issue 3.3
The unstructured dialogue only includes a TCAP message sent by the local end,
without dialogue start, continuation and end processes, and is similar to the
connectionless transfer of the SCCP. It is called unidirectional message. The
unstructured dialogue is used to send the request messages of type 4 operations
which do not require response of the opposite party. The definitions of various
types of operations will be given in the description of the component sublayer in
the following.
2. Structured dialogue
A structured dialogue includes the three stages of begin, hold (i.e., message
exchange) and terminating, that is to say, the TC user designates the start of
dialogue, dialogue continuation of dialogue and end of dialogue. It is similar to the
connection-oriented data transfer in the SCCP. Multiple structured dialogues
exist between two TC users. Each dialogue should be identified with a special
dialogue identifier. Before sending the components, the user should designate the
dialogue type. The messages included in a dialogue can be divided into four
types:
i) Start of dialogue (Begin): Pointing out the start of a dialogue processing, similar
to the connection setup message in the SCCP. This message should have a
source transaction identifier allocated by the local RSL to identify this dialogue.
Ii) Dialogue continues: Used for bi-directional transfer of dialogue messages,
indicating the dialogue is in message exchange state. It is similar to the Data
Transfer (DT) in the connection-oriented service of the SCCP. For the receiving
end to judge to which dialogue the message belongs, the message should have
two transaction identifiers: the destination and source transaction IDs. After
receiving the message, the peer end can identify the dialogue according to the
destination transaction ID.
iii) Dialogue end, indicating the dialogue ends normally. The dialogue end can be
originated by the TC user at any end. It should have the destination transaction
ID.
iv) Dialogue abort: Indicating the dialogue ends abnormally. The dialogue abort
can be originated by the TC user or the transaction sublayer. It should have the
destination ID. The dialogue abort can be originated by the TC user or the
transaction sublayer.
The transaction ID in the structured dialogue is very similar to the local reference
of the signaling connection in the SCCP. Each dialogue corresponds to a pair of
transaction IDs respectively allocated by the transaction sublayers at both ends of
the dialogue. Each identification number is only meaningful in the allocated node.
For each message, the ID allocated at the transmitting end is the source end ID
and that allocated at the receiving end is the destination transaction ID. The
former serves as the destination ID for the receiving end to return message, while
the later is used for the receiving end to determine the superior dialogue of the
message.
24
Issue 3.3
The transaction identification numbers in various types of TCAP messages are

shown in Table 2-5.
Table1.1 Transaction identification numbers in various types of TCAP messages

Message type Transaction identification number
Source end Destination
Begin v
10. Continue v v
End v
Abort v
22. TR primitives
Through the TR request primitives, the transaction sublayer accepts the dialogue
control indications of the TC user sent through the component sublayer,
generates the TCAP messages of designated type for transmission to the remote
end, and meanwhile, transfers the data (components) in the received TCAP
messages to the component sublayer through the TR indication primitives.
The TCAP protocol defines the following six types of TR primitives:
1) TR-UNI (unidirectional): Used to transfer unstructured dialogue message.
2) TR-BEGIN: Used for the begin message of the unstructured dialogue.
3) TR-CONTINUE: Used for the transfer continue message of the structured
dialogue.
4) TR-END: Used for the transfer end message of the structured dialogue.
5) TR-U-ABORT: Used to transfer the dialogue abort message of the structured
dialogue originated by the TC user.
6. TR-P-ABORT: Used to transfer the dialogue abort message of the
structured dialogue originated by the transaction sublayer itself.
23. Component Sublayer
The basic units responsible for the dialogue message transfer in the transaction
sublayer are the components. The Component SubLayer (CSL) implements the
component processing and control of the dialogues. A dialogue message includes
one or multiple components (a few messages do no have any component, they
only implement the dialogue control). A component corresponds to an operation
execution request or an operation execution result. Each component is identified
with different component invoke IDs. The parallel execution of multiple same or
different operation components is controlled with the invoke ID. This invoke ID is
only used for the CSL to differentiate the parallel execution operations so as to
monitor and manage the execution of each operation. It does not indicate what
the operation is. The definitions of the specific operations are identified by the
operation code and defined by the TC user. The meaning depends upon the
specific application service. The TCAP does not make such analysis and
processing.
25
Issue 3.3
The invoke ID is allocated by the CSL originating the operation request. When the
peer end returns the response component, the component also should includes
the invoke ID so as to indicate it is the execution result of which operation. The
components are embedded into messages, i.e., the components are subject to
the dialogues, so the components in different dialogues can use the same invoke
ID. Thus, with the invoke ID, the TCAP can control the parallel execution of large
number of same or different operations.
The contents of components are related to the specific application, but no matter
which application system is used, viewed form the operation process, the
components can be divided into the following five types:
1) Invoke-INV
2) Return Result-last-RR-L
3) Return Result-not last-RR-NL
4) Return Error-RE
5) Reject-RJ
The TCAP also divides the operations into the following four types according to
the different response conditions of the operation execution:
1) Type 1: No matter an operation succeeds or fails, the invoke end should be
reported, i.e., after the INV component of such operation is sent, the peer
end should return the RR or RE component.
2) Type 2: Only the operation failure will be reported. It means that the
operation only requires the remote node to execute one action without the
need to return any information. If this action is executed successfully, then no
return results are needed. Only when the operation is not executed
successfully, an RE component needs to be returned.
3) Type 3: Only the successful operation will be reported. Opposite to
operations of Type 2, the RR component is returned only when the operation
succeeds.
4) Type 4: No matter the operation fails or succeeds, no report is needed, i.e.,
after the local end sends out the INV component, it will not receive any
component from the remote end.
For any type of operations, after sending the INV component, the component
sublayer will start a timer to monitor. The timing value is specified by the
application service.
We have already known that the components are embedded into dialogue
messages. Which components are included in a dialogue message is directly
designated by the TC user. Actually, the TC user not only sends the component
data to the component sublayer, but also controls the dialogue message type
sent by the TC primitive indication through dialogue. The primitive sending
sequence is as follows: first the component data are sent one by one and each
26
Issue 3.3
component primitive has a dialogue ID. Finally a dialogue processing primitive is

sent, which also has a dialogue ID. After receiving the primitive, the component
sublayer will allocate all components with the same dialogue ID received before
to this dialogue for the transaction sublayer to send, i.e., the dialogue process TC
is directly mapped into the TR primitives, the allocated components serve as the
subscriber data of the TR primitives and the dialogue ID in the TC primitive is
directly mapped into the transaction ID in the TR primitive. The dialogue message
type is also designated by the TC user, which reflects the dialogue progress. If
the dialogue only includes one operation, then the message type is related to the
component type to some degree, for example, the message where the operation
invoke component (INV) is located generally belongs to the type Begin, the
message where the Return Result component (RR) is located generally belongs
to the type Continue or End, the message where the Reject component (RJ) is
located generally belongs to the type End, etc.
The component sublayer interfaces with the TC user interface through TC
primitives. The TC primitives can be divided into two types: Component
processing primitives and dialogue processing primitives.
The component primitives are used to transfer component data between the TC
user and the component sublayer, which includes the following nine types:
TC-INVOKE, TC-RESULT-L, TC-RESULT-NL, TC-U-ERROR, TC-U-REJECT, TC-
L-REJECT, TC-R-REJECT, TC-U-CANCEL and TC-L-CANCEL.
2. Component processing primitives and functions
24. TC-INVOKE: Including two request and indication. Function:

Invoke an operation.
25. TC-RESULT-L: (request and indication) function, returning the final
results of successful operations.
26. TC-RESULT-NL: Similar to the TC-RESULT-L, only requiring the
segmentation results be returned.
27. TC-U-ERROR: (request and indication) when the TC user receives
the correct operation type but cannot execute it, this primitive is
used to return the failure cause (fault code). Main parameters
include dialogue ID, error code (defined and explained by the TC
user) and user parameter.
28. TC-U-REJECT: (request and indication) When the operation
component the TC user receives is not correct, the operation will
be rejected. The parameters include the reject cause code.
29. TC-U-CANCEL: (Request primitive) The TC user requests or the
component sublayer cancels a certain operation. Main parameter:
operation ID.
30. TC-L-CANEL: (Indication primitive) If a certain operation is
27
Issue 3.3
timeout, the component sublayer informs the TC user. Parameter:

Operation ID. Not all abort operations are operations not
executed by the peer end.
31. TC-L-REJECT: (Indication primitive) When receiving a component
not in conformity with the expectation of the state diagram or a
component with syntactic error, the component sublayer will inform
the TC user, reject the execution and generate and send the RJ
primitive to the peer end.
Main parameters InvokeID and fault code (defined by the TCGP)
32. TC-R-REJECT: (Indication primitive) After receiving the operation
rejected by the peer end, the component sublayer will inform the
TC user. Main parameters: Operation ID and fault code (defined
by the TCAP).
The dialogue processing primitives are used to transfer the dialogue progress
information between the TC user and the component sublayer and meanwhile
serve as the delimitation indication of the dialogue component set, including the
following six kinds:
TC-UNI, TC-BEGIN, TC-CONTINUE, TC-END, TC-U-ABORT and TC-P-ABORT.
3. Dialogue processing primitives and functions
33. TC-UNI: The TC user requests (indicating the TC user) an

unstructured dialogue.
34. TC-BEGIN: (request and indication) function: Start a dialogue,
Parameter: QoS, source and destination addresses,
corresponding ID, user information and context-specific.
35. TC-CONTINUE: Continue a dialogue (request and indication),
parameter: QoS, source and destination addresses, dialogue ID,
context-specific name and user information.
36. TC-END: (request and indication) End a dialogue, parameter:
QoS, dialogue ID, end mode, context-specific and user
information.
37. TC-U-ABORT: (request and indication) The TC user aborts a
dialogue, main parameters: QoS, dialogue ID and abort cause
(made clear in the dialogue part of the TCAP message).
38. TC-P-ABORT: (Indication primitive) The dialogue abort message
generated when the transaction sublayer detects a message
protocol error or structure error is sent to the local TC user and the
peer end. Main parameters: QoS, dialogue ID and P-ABORT
cause value. The cause value is defined in the TCAP
specifications.
28
Issue 3.3
39. ?TC-NOTICE: (Indication primitive) Function: Informing the TC

user that the network service provider cannot provide the
requested service. Parameters: Dialogue ID and report cause
(determined by the error value returned by the SCCP).
2.3 TCAP Message Structure

The ASN.1 coding principles based upon the Recommendations X. 208 and X.
209CAP are used for the TCAP and MAP message. The nesting information
structure is used, with high flexibility and openness. Therefore, before
introducing the TCAP message structure, a brief introduction to the ASN.1 coding
will be given.
2.3.1 ASN.1 Coding
The basic unit of the ASN.1 coding is the basic information element.
1. Basic information element
The basic information element is called IE for short, including tag, length and
content. The tag is used to differentiate different IEs and determine the
explanation of the content field and the length is used to indicate the number of
bytes included in the content. According to the complexity of the contents, the IE
can be divided into the Primitive and Constructor. The content of the Primitive is
simple data type and the content of the Constructor is one or multiple basic IEs.
2. Tag
The tag is composed of one or multiple octets, including class, form and tag code.
Generally, the tag structure is as shown in Figure 2-9:
H G F E D C B A
Class Form Tag Code
Figure2.1 Basic IE tag
Where, the two bits HG form the class, which divides the tag into four types:
40. HG = 00 Universal, it is the completely standardized tag defined in
the X.209.
41. HG = 01 Application-Wide, it is applied to IEs of various TCAP
application service ASEs (i.e., TCAP user) in SS7, for example,
this type of tags are used for the tags of the transaction sublayer.
42. HG =10 Context-specific, It is used in the IEs specified in the
upper-level Constructor. The sequence of other data elements in
the same constructor should also be considered for these IEs. This
tag can be repeatedly used in other constructors, for example this
29
Issue 3.3
type of tags are used for all tags of the component processing
sublayer.
43. HG=11 Private Use, It is reserved and used in IEs of national,
network or private users. These IEs does not belong to the
protocol scope of the TC.
F format of bit: Referring to the form of the IE,
0: indicating that the IE is a Primitive.
1: indicating that the IE is a constructor
Bits E-A are tag codes, indicating the sequence number of the tag, which can be
extended to multiple bytes. Its format is shown in Figure 2-10:
MS BTS BSC MSC
CC CC
MM MM
BSSMAP
RR RR BSSAP
L3
RR BTSM BTSM
SCCP SCCP
L2 LAPDm LAPDm LAPD LAPD
MTP MTP
L1 Sign. Sign. Sign. Sign.
Layer 1 Layer 1 Layer 1 Layer 1
Um A-bis A
Figure2.2 Format of tag code
In the single byte format, the tag occupies only one octet and the tag code is E-A
bits, with the value range of 00000-11110 (0~30 in decimal notation). If the tag
code is greater than 30, then the extended format of multiple bytes should be
used. In this case, the E-A bit of the first byte is set as 11111. Its function is to
indicate that the tag is represented with multiple-byte format and it is not a part of
the tag code value itself. The H bit of the subsequent byte is used for the
extended bits. If H=1, it indicates that the subsequent byte is still a tag extended
byte; if H=0, it indicates that it is the last tag byte. The serial connection of the G-
A bits of all extended bytes form the tag code. The G bit of the first extended byte
is the Most Significant Bit (MSB) of the tag code and the A bit of the last extended
byte is the Least Significant Bit (LSB). The maximum code value of the extended
format tag is 31, and it only needs an extended byte. The code of the G-A bit of
the byte is 0011111. The extended byte of the tag cannot be all-0, i.e., for a
given tag code value, the minimum number of extended byte should be used.
3. Length
The length indicates the number of octets occupied by the content part, but does
not include the octets of the tag and length fields.
The length field has three coding modes:
30
Issue 3.3
a) If the length is less than 128 octets, then the short format will be used. It only
occupies one byte, the eighth bit is set as 0 and the lower seven bits are the
decimal code value of the length.
b) If the length is greater than or equal to 128 octets, then the long format will be
used. In this coding mode, the length of the code of the length field itself is 2-
127. Where, the H bit of the first byte is set as 1, the length of the decimal code
value length field of the G-A bit is subtracted by 1 and the IE itself is represented
with unsigned decimal digit. Its MSB is the G bit of the second byte and its LSB is
the A bit of the last byte.
c) In the Indefinite coding mode, the length field only occupies one octet and the
start code is fixedly 10000000, which does not indicate the length of the IE, but is
just a tag of the indefinite code. If this coding mode is used, a special EOC (End-
Of-Content) indicator should be set at the end of the IE. This indicator is
processed as an IE. Its tag (Class) is Universal, its Form is Primitive, its Tag Code
is 0 and it does not have the Content part, so its length is 0. The indefinite code
can be used in the IE of any length, with its maximum length only restricted by the
maximum length of the SCCP message. This code can replace the length code of
short or long format. The only requirement is that the applied IE should be of the
Constructor type, since the EOC itself is a message element, as shown in Figure
2-11:
80H
Contents
EOC tag OOH
EOC length OOH
Figure3.1 Indefinite long-format information element
4. IE Examples
04 08 64 00 70 07 09 00 00 F1
The above code is an example of IEs. Where, 04 is the tag, 08 is the length and
the other parts indicate the contents. It can be known from the further analysis of
04 that this IE is of the universal class which has completely standardized
definition in the X.209, and meanwhile, the IE is Primitive and the tag code is 4. It
can be known from X.209 that this tag indicates the Octet String, that is to say,
the content of the IE is an array of one octet. In fact the content of the IE indicates
an IMSI.
6C 80 ...... 00 00
31
Issue 3.3
The above example is also an IE. where 6C is the tag, 80 indicates the indefinite
length, the last two 00 indicates the end of the IE and the omitted part in the
middle indicates the content of the IE. It can be known from the further analysis of
the tag 6C that this IE is of Application-wide class. The IE is a constructor applied
in the TCAP functions in SS7 and the tag code is C. According to the TCAP
protocol, it can be known that this IE indicates the component part of the TCAP.
2.3.2 TCAP Message Structure
The TCAP message is the user data part existing in the SCCP message, as
shown in Figure 2-12:
L2 L3 L2
F B
L2 F CK SIF SIO LI I FSN I BSN F
B B *
L3 Information
Routing label
contents
Address of Address of
SCCP Data the calling the called Protocol Message
subscriber subscriber type ty pe
IE of
component IE of IE of Message Message
TC
part dialogue part transaction part length ty pe
Figure1.1 TCAP message in MSU
The ASN.1 coding principles are used for the TCAP message coding and the
information element is the basic coding unit.
A TCAP message is composed of three parts, as shown in Figure 2-13. The

transaction part is used for the local/remote TCAP to identify the transaction. The
dialogue part includes relevant information for the dialogue control, including the
dialogue type, dialogue version, etc. The component part includes the invoke ID,
operation code and other parameters of the operation.
32
Issue 3.3
Tag
Message ty pe tag
IE of transaction part Length
Total message length
Contents
Tag
IE of transaction part Length
Contents
IE of dialogue part
Component part tag Component type tag
Message contents
Component part length Component length
Component IE
Component
Com
Component IE
ponentpart
IE of transaction part Parameter
Component type tag

Component length
Component Component IE
Component IE
Parameter
Figure1.2 TCAP message structure
1) Transaction part:
The IEs in the transaction part correspond to the parameters included in the
TCAP message. According to the above-mentioned TCAP functions, it is not so
difficult to understand the transaction IEs included in various messages and their
types. The information codes of the parameters included in the message are
listed as follows:
Table2.1 TCAP messages in the transaction part

IE Message Unidirection Begin Continue End Protocol User
al message message message( message abort(P- abort (U-
(UNI) (BEGIN) Continue) (END) ABORT) ABORT)
Information Class Tag

name code
Source Primitive 0X48 None M M None None None
transaction ID
Destination Primitive 0X49 None None M M M M
transaction ID
Protocol abort Primitive 0X4A None None None None M None
cause
User abort Constructor 0X6B None None None None None O
cause
Dialogue part Constructor 0X6B O O O O O O
Component Constructor 0X6C M O O O None None
part
Certain Constructor M O O O None None
number of
components
33
Issue 3.3
In the above table, the components do not belong to the transaction part, they are
the members of the component part.
2. Component part
The component part is composed of one or multiple components. Each
component is an IE sequence. Generally each IE is a primitive. The specific IEs
included in each component depend upon its function, as shown in the following
table:
Table2.2 TCAP messages in the component part
Invoke Return error Reject

Return result
Message IE component component component
(RETURN RESULT)
(INVOKE) (RETURN ERROR) (REJECT)
IE name Class Tag code LAST NOT Last

Component Constructor A1M A2M A7M A3M A4M
type
Invoke ID Primitive 0X02 M M M M
Link ID Primitive 0X80 O None None None
Error code Primitive 0X02/0X06 None None M None
Fault code Constructor 0XA0/0XA3 None None None M
Parameter Constructor 0X30/0X31 O O None None
sequence
Operation Primitive 0X02/0X06 M O None None
code
Parameter Primitive/ O O O None
Constructor
Note: The fault code and operation code can be divided into two types: Global
(0x06) and Local (0x02).
3. Dialogue part
The dialogue part includes the PDU or user information for the dialogue control.
For the codes, please refer to ITU-T Q.773.
34
Issue 3.3
2.3.3 Examples for TCAP Messages
1. BEGIN message
A BEGIN message IE is a
constructor Message type (62H) tag
Message length
Contents of BEGIN IE
Tag of source transaction ID (48H)
Length of source transaction ID
Contents of source transaction ID
This is an option, if there is no

Tag of component part tag (6CH) component part, the length field is
set as 0, but the component tag still
exists

Contents of component part
Component 1
Component 2
Component n
Figure1.1 BEGIN message
2. Analysis of TCAP message
The TCAP messages are included in the user data part of the SCCP message.
The contents of the TCAP messages can be found by tracing the SCCP message
in the maintenance background.
Based upon the analysis of a TCAP message, the contents of the message is as
follows:
62 80 48 04 36 01 00 A2 6B 80 28 80 06 07 00 11 86 05 01 01 01 A0 80 60 80 A1
80 06 06 03 A3 7D 01 01 01 00 00 00 00 00 00 00 00 00 00 00 00 6C 80 A1
80 ???
The analysis is as follows:
62 80: Begin message, with indefinite length.
48 04 36 01 00 A2: Source transaction ID.
6B 80: Dialogue part, with indefinite length.
28 80: External tag, with indefinite length.
35
Issue 3.3
06 07: Destination ID tag, with the length of 07H bytes.

00 11 86 05 01 01 01: Contents of destination ID.
A0 80: Tag of single ASN1-type, with indefinite length.
60 80: Dialogue request, with indefinite length.
A1 80: Context-specific tag, with indefinite length.
06 06: Destination ID tag, with the length of 06H bytes.
03 A3 7D 01 01 01: Destination ID value.
12 00 bytes: 6 ECO IEs, it is the end tag of the indefinite length.
6C 80: Component part, with indefinite length. The meaning is explained in the
MAP part.
2.4 Summary
This chapter describes the sublayer structure and message structure of the
TCAP. Through the learning of the chapter, we should understand the analysis of
the typical TCAP messages.
2.5 Exercise
Please analyze the following TCAP message.
6C 80 A1 80 02 01 04 02 01 04 30 2B 80
36
Issue 3.3
Chapter 3 Mobile Application Part

The application of the TCAP can be divided into two classes. The first class
supports various user services such as mobile communication service, various
intelligent services, etc. These services need to exchange messages unrelated to
circuits with the network control points. The second class supports the network
Operation, Maintenance and Administration (OMA). A typical TC user of this class
of applications is the Operation, Maintenance and Administration Part (OMAP) in
SS7. The application in the GSM system belongs to the first class, which is called
the Mobile Application Part (MAP).
3.1 MAP Functions

The MAP is a special and important functional unit for intra-net and inter-net
interconnection in the Public Land Mobile Network (PLMN). The MAP
specification present the signaling functions necessary for the mobile network to
use SS7 so as to provide the services needed by the mobile network, such as
voice service and non-voice service.
The MAP specifications of the GSM have specified the MAP signals between the
entities such as the mobile service switching center, location register,
authorization center, equipment identification register, etc. of the 900MHz TDMA
digital cellular mobile communication network, including message flow, definitions
of operations, data type, error type and specific codes.
The MAP is a kind of information exchange mode provided between the GSM
network entities to implement the automatic roaming function of mobile stations.
At present, the transmission of the MAP signaling is based upon the series NO.7
signaling technical specifications released by the CCITT. Actually, the switching of
the MAP signaling can also be based upon other networks in conformity with the
OSI network layer standards. Thus, a network operation corporation can mix,
match and use various protocols to meet its requirements according to the local
actual situations. Of course, the formulation and perfection of relevant protocols
are needed.
The MAP is responsible for the information transfer between the GSM functional
entities in the following process:
----Location update/cancellocation
----Fault restoration of location register
User Management
----Authorization and encryption
----IMEI management
37
Issue 3.3
Routing function
----Access processing and paging
----Processing of supplementary services
----Handover
Short message service
----Operation and maintenance
In the GSM system, the MAP signaling is like the blood in human body, which
transfers the information related to the above protocol between various functional
entities through the blood vessels (No. 7 CCS system) of the GSM. The
architecture of the signaling network is shown in the following figure:
VLR G VLR
B D
MS BSS A MSC C HLR
E
MSC
F
EIR
Figure1.1 GSM network architecture
As shown in the above figure, the MAP signaling will be transferred among the B,
C, D, E, F and G interfaces in the GSM network. The BSSAP is responsible for
the A interface. The description of each interface is as follows:
A-interface: It is the communication interface between the network subsystem

and the base station subsystem. With respect to the functional entity of the
subsystem, the A interface is the interface between the Base Station Controller
(BSC) and the Mobile Switching Center (MSC). The information transferred by
this interface includes mobile station management, base station management,
mobility management and call processing, etc.
B-interface: It is the interface between the VLR and the MSC. The B interface is
used for the MSC to query the current location information of a Mobile Station
(MS) from the Visit Location Register (VLR), or request the VLR to update the
current location information of the MS or is used for the operations of
supplementary services.
C-interface: It is the interface between the MSC and the HLR. If an MS serves as
the called party, the C interface is used for the gateway and the MSC obtains the
routing information (roaming number) of the called MS from the HLR. When
transferring short messages to the MS, the C interface is used for the SMS
38
Issue 3.3
gateway MSC to obtain the number of the MSC where the MS is currently located
from the HLR.
D-interface: It is the interface between the VLR and the HLR. This interface is
used to exchange the location information of the MS and the subscriber
management information. To make sure that a mobile subscriber can set up and
receive calls in the whole service area, the data exchange is needed between the
VLR and the HLR. For example, the VLR needs to inform the HLR of the current
location information of the subordinate mobile subscriber and the HLR needs to
send all VLR-related service data to the VLR. If the VLR area where the mobile
subscriber is previously located has changed, the HLR also needs to delete the
location information of the mobile subscriber in the previous roaming VLR.
Furthermore, the data exchange through the D interface is needed for the service
modification request of the subscriber (such as supplementary service operation)
and the subscriber data modification of the operation.
E-interface: It is the interface between the MSC and the MSC. The E interface is
the interface used to control the handover between different MSCs in the
neighboring cells. During the call connection, when an MS moves from the cell
controlled by an MSC to the cell controlled by another MSC, the handover is
needed to prevent communication interruption. The E interface is used for the
data exchange between the MSCs to start and implement the handover
operation.
F-interface: It is the interface between the MSC and the EIR. When an MSC
needs to check the validity of the International Mobile Equipment Identity (IMEI),
the F interface is needed for exchanging IMEI-related information with the EIR.
G-interface: It is the interface between the VLR and the VLR. When a mobile
subscribers roams to a new VLR-controlled cell and the Temporary Mobile
Subscriber Identity (TMSI) is used to initiate the location updating, the G interface
is used for the current VLR to obtain the IMSI and authorization set from the
previous VLR.
Generally, for a practical GSM system architecture, the VLR and MSC are
integrated into the same entity. Most manufacturers use this architecture for their
M900/M1800 systems. Accordingly, the B interface becomes an internal interface,
the C and D interfaces can pass the same physical connection, and the E and G
interfaces can pass the same physical connection.
3.2 MAP Message Format
3.2.1 Message Structure
The transmission of the MAP messages is based upon the services provided by
each protocol layer of the TCAP, SCCP and MTP. A piece of MAP message
transmitted the signaling link also includes the protocol data of the protocol layers
39
Issue 3.3
of the TCAP, SCCP and MTP. The format of a complete message is shown in the
following figure:
MTP SCCP TCAP message MAP message

message message
Figure1.1 MAP message format
3.2.2 MAP Message
The MAP message is the component part of the TCAP message and the TCAP
message is the data part of the SCCP message. The mobile application SCCP
message is transferred in the SIF field in the Message Signal Unit (MSU) of the
No.7 signaling. The UDT message type is used, the protocol type is Class 0 or 1
and the basic format is shown in the following figure:
F CK SIF LI FIB FSN BIB BSN F
8 16 2 6 1 7 1 7 8 First sent bytes
Routing label
Message type (UDT)
Protocol type
Pointer of the called
address
Pointer of the
calling address
Data part pointer
Length of the called
address
Called address
Length of the calling
address
Calling address
Data address
Data (TCAP message)
Figure1.1 Specific format of mobile SCCP message
Note:
(1) F: Its code pattern is 01111110, which not only indicates the end of the
previous signal unit, but also indicates the start of the next signal unit. Multiple
random F tags can be inserted between two signal units. The F tag can reduce
the processing workload of the system in overload condition.
(2)CK: check error, the 16-bit cyclic redundant code is used to detect the errors
generated during the transmission of the signal unit.
40
Issue 3.3
(3) Sequence number of signal units and retransmission indication bit

BSN: Backward Sequence Number. The BSN indicates the sequence
number for the opposite part until all messages of the BSN have been
received correctly.
BIB: Backward (retransmission) Indication Bit. The BIB is used for
reverseindication of the opposite party starts the retransmission from the
BSN+1 message.
FSN: Forward sequence number, i.e., the sequence number of the message.
FIB: Forward (retransmission) Indication Bit. The FIB is used for
reverseindication of the start of the message retransmission.
(4)LI: Signal unit length indication bit. Its value is equal to the number of octets
between the LI field and the CK field. FISU: LI of FISU = 0, LI of LSSU = 1 or
2 and LI of MSU >2. Since the length of the LI field is 6 bits, with the value range
of 0-63, when the length is greater than or equal to 63, all the values of LI are set
as 63 to maintain the original structure.
(5) SIO: Service Indication Octet. The SIO is only used in MSC for indicating the
message type. The three levels of the MTP allocate messages to the
corresponding functional modules according to the SIO, and meanwhile, it
indicates whether a message is a national network message or an international
network message.
Lower 4 bits: DCBA, service indicator, where the SCCP is 0011.
Higher 4 bits: HGFE, Sub-service field, If HG=00, it indicates the international
network; if HG=01, it indicates the international backup network; if HG=10, it
indicates the national network and if HG=11, it indicates the national backup
network. The FE bits are standby.
A specific MAP service message exists in the TCAP message in the form of
component. Generally, the message types of the MAP service correspond to the
operation codes one by one. However, during the message transfer, a message
corresponds to an invoke ID. The invoke ID is the only identity of a message
during the MAP dialogue. With the differentiation of the invoke ID, a component
can be translated into the corresponding MAP service message.
3.2.3 MAP Message Code
For the detailed protocol of the MAP message, the description of Abstract Syntax
Notation (ASN.1) in the CCITT Recommendation X.208 is used.
The operation code, operation type and operation time limit corresponding to the
MAP service message are given in the ETSI GSM 09.02 specifications. Where,
the operation time limit includes three types: long, intermediate and short time
limits. The specific values depend upon the specific implementation modes.
41
Issue 3.3
The following table lists the operation codes used in the MAP. The operation
codes here are the results of the specific coding of the operation codes in the
Table 3-8 TCAP messages in the component part
Table1.1 MAP message codes

Operation
MAP operation Entity and direction code(Decimal Version
otation)
ActivateSS VLR, VLR<=>HLR 12 Phase1&Phase2
ActivateTraceMode HLR<=>VLR 50 Phase1&Phase2
AlertServiceCentre G/IW MSC<=>HLR 64 Phase2
AlertServiceCentreWithoutResult G/IW MSC<=>HLR 49 Phase1
Cancel location VLR--HLR 54 Phase1
HLR<=>VLR 3 Phase1&Phase2
checkIMEI MSC<=>VLR, MSC<=>EIR 43 Phase1&Phase2
deactivateSS MSC<=>VLR, VLR<=>HLR 13 Phase1&Phase2
deactivateTraceMode HLR<=>VLR 51 Phase1&Phase2
deleteSubscriberData HLR<=>VLR 8 Phase1&Phase2
eraseSS MSC<=>VLR, VLR<=>HLR 11 Phase1&Phase2
forwardAccessSignalling MSC<=>VLR 34 Phase1&Phase2
forwardcheckssindication MSC<=>VLR 38 Phase1&Phase2
forwardShortMessage G/IW MSC<=>MSC 46 Phase1&Phase2
getPassword HLR<=>VLR, VLR<=>MSC 18 Phase1&Phase2
informServiceCentre HLR => G/IW MSC 63 Phase2
interrogateSS MSC<=>VLR, VLR<=>HLR 14 Phase1&Phase2
or only MSC<=>VLR
Insert subscriber data HLR<=>VLR 7 Phase1&Phase2
noteInternalHandover MSC-B => MSC-A 35 Phase1
noteSubscriberPresent VLR--HLR 48 Phase1
performHandover MSC-A<=>MSC-B 28 Phase1
performSubsequentHandover MSC-B<=>MSC-A 30 Phase1
prepareSubsequentHandover MSC-B<=>MSC-A 69 Phase2
processAccessSignalling MSC-B => MSC-A 33 Phase1&Phase2
processUnstructuredSs-Data MSC<=>VLR, VLR<=>HLR 19 Phase1
processUnstructuredSs-Request MSC<=>VLR, VLR<=>HLR 59 Phase2
unstructuredSs-Request HLR<=>VLR, VLR<=>MSC 60 Phase2
Unstructedsupplementary HLR<=>VLR, VLR<=>MSC 61 Phase2
service-notify
provideRoamingNumber HLR<=>VLR 4 Phase1&Phase2
purgeMS VLR<=>HLR 67 Phase2
readyForSM MSC<=>VLR, VLR<=>HLR 66 0Phase2
registerPassword MSC<=>VLR, VLR<=>HLR 17 Phase1&Phase2
registerSS MSC<=>VLR, VLR<=>HLR -30010 Phase1&Phase2
Report short message fault state G/IW MSC <=> HLR 47 Phase1&Phase2
reset HLR=>VLR 37 Phase1&Phase2
restoreData VLR<=>HLR 57 Phase2
sendAuthenticationInfo VLR<=>HLR 56 Phase2
sendEndSignal MSC-B<=>MSC-A 29 Phase1&Phase2
42
Issue 3.3
sendIdentification VLR<=>VLR 55 Phase2

sendIMSI VLR<=>HLR 58 Phase2
sendparameters VLR<=>HLR, VLR<=>HLR 9 Phase1
sendRoutingInfoForSM G/IW MSC <=> HLR 45 Phase1&Phase2
sendRoutingInformation MSC<=>HLR 22 Phase1&Phase2
updateLocation VLR<=>HLR 2 Phase1&Phase2
Note:
(1) G/IW MSC: Gateway/InterWorking MSC, short message gateway intercon-
nection MSC
(2) MSC-A: Main control MSC initiating the handover
(3) MSC-B: MSC to which the a MS is handed over
Each above-mentioned MAP message has special parameter and format. For
details, please refer to Appendix B in the ETSI 0902 Specifications.
3.3 Message Examples

A UDT message is listed as follows:
118>> 30168 UDT 000000d 05FF09 03FF11 3F 3F 83 11 FF 03 09 FF 05 0D
09 81 03 0E 18 0B 12 06 00 12 04 68 31 39 31 00 00 0A 12 07 00 12 04 68 31 09
40 67 2A 62 28 48 04 2B 81 11 00 6C 80 A1 80 02 01 00 02 01 02 30 16 04 08
64 00 30 31 08 00 51 F4 81 06 91 68 31 09 40 67 00 00 00 00
The structure of the above trace message is as follows:
1) The whole message belongs to the MTP layer.
2) The segment from the 09 81 to the last belongs to the SCCP Layer.
3) 3 The segment from 62 28 to the last belongs to the TCAP layer.
4) 4 The segment from the 6C 80 to the last belongs to the component sublayer
of the TCAP layer. The MAP messages can be encapsulated into the
components.
The messages in each layer are as follows:
1) The MTP layer:
3F----indicating the length of the whole MTP message. When the number of all
the message bytes is greater than 63 bytes, the byte is uniformly set as 3F.
83----If the higher four bits are 8, it indicates the network indicator, indicating the
national master network; if the lower four bits are 3, it indicates the service
indicator, indicating the subsequent SCCP message.
11 FF 03----the DPC is 03 FF 11
09 FF 05----the OPC is 05 FF 09
0D----SLS Signaling link selection code
43
Issue 3.3
2. The SCCP layer:

The format of the UDT message type includes message type code, protocol type,
and route tag (including three points: the first pointer points at the address of the
called subscriber, the second pointer points at the address of the calling
subscriber and the third pointer points at the data, i.e., the TCAP part).
09----indicating the message type is UDT.
81----If the higher four bits are 8, it indicates that the QoS(Quality of service)
requires error return; if the higher four bits are 0, it indicates that the QoS does
not require the error return. If the lower four bits are 1, it indicates that the
protocol type of the SCCP is sequential connectionless class 0.
03----The pointer of the called subscriber address: 03 means that the bytes
starting with the third byte after 03 indicate the called address.
0E----The pointer of the calling subscriber address: 0E means that the bytes
starting with the fourteenth byte after 0E indicate the calling address.
18----The pointer of the data address: 18 means the bytes starting with the
twenty-fourteenth byte after 18 indicate the data address, i.e., the start of the
TCAP part.
0B 12 06 00 12 04 68 31 39 31 00 00 ----The address of the called GT code.
0B----indicating the length of the called GT address is 11 bytes.
12----This byte indicates the address indicator and translation type, with the
following meaning:
Bit8----Standby
Bit7----Route indicator
0 indicates the route is selected according to the Global Title (GT) in the
address
1 indicates that the route is selected according to the DPC in the MTP routing
tag and the subsystem in the called subscriber address.
Bit6/5/4/3----GT indicator
0000 indicates GT of Class 0
Bit2----Subsystem indicator
0 indicates the subsystem ID is not included.
1 indicates the subsystem ID is included.
44
Issue 3.3
Bit1----Signaling indicator
0 indicates the signaling point code is not included.
1 indicates the signaling point code is included.
06----Subsystem ID
0000 0000----Undefined subsystem ID/not used
0000 0001----SCCP Management (SCMG)
0000 0010----Standby
0000 0000----ISDNUser Part (ISUP)
0000 0100----Operation, Maintenance and Administration Part (OMAP)
0000 0101----Mobile Application Part (MAP)
0000 0110----Home Location Register (HLR)
0000 0111----Visit Location Register (VLR)
0000 1000----Mobile Switching Center (MSC)
0000 1001----Equipment Identity Center (EIR)
0000 1010----Authorization Center (AUC)
0000 1011----Standby
0000 1100----Intelligent Network Application Part (INAP)
0000 1101
:
: Standby
:
1111 1110
1111 1111----Extended standby
00----This byte is standby in GT of Class 4
12----The higher four bits of this byte indicate the numbering plan and the lower
four bits indicate the coding design.
Numbering plan Coding design
8765
4321
0000 Undefined 0000 Undefined
0001 ISDN/Telephone numbering plan 0001 BCD, Odd number of digits
0010 Standby 0010 BCD, Even number of digits
45
Issue 3.3
0011 Data numbering plan 0011 Standby

0100 Telex numbering plan 0100
0101 Marine mobile numbering plan 0101
0110 Land mobile numbering plan 0110
0111 ISDN/Mobile numbering plan 0111
1000 1000
: Standby Standby
: :
1111 1111
04----Code of address property indicator

7654321
0000000 FREE
0000001 Subscriber number
0000010 National standby
0000011 National valid number
0000100 International number
0000110 Intelligent network service number
0000101 FREE
:
:
1111111 FREE
68 31 39 31 00 00----MSISDN, 86139313000
0A 12 07 00 12 04 68 31 09 40 67----Address of the calling GT code. The
analysis method is the same as that of the address of the called GT code.
22----The length of the SCCP data part, i.e., the length of the TCAP message
3. The TCAP layer:
The TCAP is the data part of the SCCP. The message of the TCAP layer is
composed of Information Elements (IEs). An IE is composed of tag, length and
contents. The division of IEs is the basis for the TC message analysis.
The contents of a TCAP message are described as follows.
62 28 48 04 2B 81 11 00 6C 80 A1 80 02 01 00 02 01 02 30 16 04 08 64 00 30 31
08 00 51 F4 81 06 91 68 31 09 40 67 00 00 00 00
46
Issue 3.3
The specific analysis is as follows:

The transaction sublayer:
62---- The field code of the transaction part, i.e., the message type tag of the
TCAP, indicating that the message type is a message Begin.
Main message type tags (field names) Code H G F E DC B A
Begin 0 1: 1 0 0 0 1 0
End 0 1: 1 0 0 1 0 0
Continue 0 1: 1 0 0 1 0 1
Abort 0 1: 1 0 0 1 1 1
28----According to the composition of the IE, after the message type tag is the IE
length, so it can be seen that the 2A before 62 indicates that the length of this
TCAP message is 42 (2AH) bytes.
48----Indicating the transaction ID in the message type so as to differentiate
different transactions. 48 indicates the source transaction ID tag.
48 indicates the source transaction ID tag.
49 indicates the destination transaction ID tag.
04----Again according to the composition of IE, after the tag also is the IE length,
so
04 indicates that the length of the destination transaction ID value is four bytes.
2B 81 11 00----Source transaction ID value
4. The component sublayer:
This layer includes the MAP messages and is critical to the analysis of the MAP
signaling. Generally, the component sublayer is composed of the component part
and the dialogue part. Most UDTs including the MAP messages include the
component part, but may not include the dialogue part. A component layer
message only including the component part is listed as follows. For the MAP, this
layer is transparent.
6C 80 A1 80 02 01 00 02 01 02 30 16 04 08 64 00 30 31 08 00 51 F4 81 06 91 68
31 09 40 67 00 00 00 00 00 00
The specific analysis is as follows:
6C----Component part tag
6C indicates the component is a part tag.
6B indicates the dialogue is a part tag.
80----According to the composition of the IE, after the tag is the IE length, so 80
indicates the length of the component is indefinite.
A1----Part code tag in the component part
47
Issue 3.3
A1 indicates the part is an invoke part.

A2 indicates the part is the return-result (last) part.
A3 indicates the part is a Return-Error part.
A4 indicates REJECT
80----After the tag is also the IE length, so 80 indicates the length is indefinite.
02----Local invoke tag
01----Operation code length.
00----The invoke ID value is 00.
02----Local operation code tag, indicating the operation conducted for the invoke
this time.
01----The length of the local operation code is one byte, i.e., the next byte is the
operation code.
02----Operation code, indicating the operation conducted for the invoke this time.
The common operations are listed as follows:
Operation code Operation
02 Locating Updating
03 Cancel Location
04 Sent Roaming Number
07 Insert Subscriber Data
09 Sent Parameter
16 Sent Routing Information
56 Sent Authentication Information
30----indicating the sequence tag, this item is optional in the returned component.
Some parts do not have this item.
16----Length
04----Octet string
08----Length
64 00 22 07 08 00 51 F4 -----Mandatory location update parameter: IMSI
81---Tag
06---Length
91----Attribute
68 31 09 00 64 F7 ----Optional parameter for location updating: MSC number
It can be seen from the above analysis that the analysis of the TCAP is actually
the analysis of the SCCP data part. The analysis of the MAP message mainly lies
48
Issue 3.3
in the analysis of the component part, i.e., find the tag of the component part in
the message------6C and then analyze the MAP part.
3.4 Summary
This chapter mainly describes the MAP functions, message structure and the
analysis method of a complete mobile SCCP. Through the learning of this
chapter, we should master the analysis method of the MAP message so as to lay
a solid basis for learning the message analysis of the C/D interfaces.
3.5 Exercise
Please draw out the message structure diagram of the SCCP message.
49
Issue 3.3
Chapter 4 Analysis of C/D Interface Messages
4.1 Introduction
The C interface is the MSC-HLR interface and the D interface is the VLR-HLR
interface. Since the MSC and the VLR are integrated into one entity, the C and D
interfaces become one interface physically, while the MSC-VLR becomes the
internal interface. The C/D interface is an important interface within the NSS. The
MAP messages are transmitted over the C/D interface.
In the above introduction to the signaling basis, we have already known that the
MAP message is the component part of the TCAP message and the TCAP
message is the data part of the SCCP message. The mobile application SCCP
message is transmitted in the SIF field in the Message Signal Unit (MSU) of SS7.
The UDT message type is used and the protocol type is Class 0 or 1. Up to now,
we have already mastered the analysis method of a complete MAP message. In
this chapter, based on the analysis of the MAP message, we will conduct the
signaling analysis of the C/D interface with the combination of the communication
flow.
In the previous chapter, the MAP message and codes have been described,
where the MAP messages transmitted over the C/D interface include:
44. updateLocation
45. ForwardCheckSs_Indication
46. CancelLocation
47. ProvideRoamingNumber
48. SendAuthenticationInfo
49. SendParameters
50. SendImsi
51. SendRoutingInfo
52. InsertSubscriberData
53. DeleteSubscriberData
54. Reset
55. RegisterSS
56. EraseSS
57. ActivateSS
58. DeactivateSS
50
Issue 3.3
59. RegisterPassword
60. InterrogateSS
61. GetPassword
62. ReadyForSM
63. PurgeMs
4.2 Signaling Analysis of Typical Flow

Many contents we have learned before will be used in the signaling analysis,
including signaling and communication flow. In this section, we set the location
updating and call flow as an example to describe the signaling analysis of the C/d
interface.
4.2.1 Call Flow
The call flow of the C/D is as follows:

MSC/VLRMAP HLRMAP
SEND_ROUTING_INFORMATION
---------------------------------------------->
PROVIDE_ROAMING_NUMBER
<----------------------------------------------
PROVIDE_ROAMING_NUMBER_RSP
---------------------------------------------->
SEND_ROUTING_INFORMATION_RSP
<----------------------------------------------
The specific MAP messages on the C/D interface will be described as follows.
1) SEND_ROUTING_INFO
<SCCP NAT 4613 00b 000008 000009 09 81 03 0C 16 09 12 06 00 12 04 68 31
28 07 0A 12 08 00 11 04 68 31 09 82 F0 54 62 80 48 04 39 01 00 38 6B 80 28 80
06 07 00 11 86 05 01 01 01 A0 80 60 80 A1 80 06 07 04 00 00 01 00 05 02 00 00
00 00 00 00 00 00 00 00 6C 80 A1 80 02 01 00 02 01 16 30 14 80 07 91 68 31 28
07 10 55 AA 09 0A 01 04 04 04 04 02 80 90 00 00 00 00 00 00
The message analysis is as follows:
<SCCP NAT 4613 00b 000008 000009 09(Message type: UDT) 81(Protocol
type: Sequential connectionless service of Class 1 messages, message return)
03(Pointer 1 of mandatory variable length part : Called address)0C(Pointer 2 of
51
Issue 3.3
mandatory variable length part : Calling address ) 16(Start pointer of optional

part) 09(Length of the called address) 12 06 00 12 04 68 31 28 07 0A (Length of
the calling address) 12 08 00 11 04 68 31 09 82 F0 54(Subscriber data length)
62(BEGIN) 80 48 (Source transaction identifier)04 39 01 00 38 6B(Dialogue part
tag) 80 28(External tag) 80 06(Destination identification tag: Dialogue PDU) 07 00
11 86 05 01 01 01 A0(Single ASN1 tag) 80 60(Dialogue request tag) 80
A1(Context-specific tag) 80 06(Destination identification tag) 07 04 00 00 01 00
05 02 00 00 00 00 00 00 00 00 00 00 6C(Component part tag) 80 A1(Component
type tag: Invoke) 80 02(Invoke tag) 01 00(INVOKE ID)02(Operation code tag)01
16(SEND_ROUTING_INFO) 30(SEQUENCE)14 80(MSISDN) 07 91 68 31 28 07
10 55 AA(IMPL SEQU:A) 09 0A(ENUM:4) 01 04 04(OCTET STRING) 04 04 02
80 90 00 00 00 00 00 00
2. PROVIDE_ROAMING_NO
>SCCP NAT 4645 004 000009 000008 09 81 03 0D 16 0A 52 07 00 11 04 68
31 09 82 F1 09 12 06 00 12 04 68 31 28 07 6B 62 80 48 04 38 01 01 8A 6B 80
28 80 06 07 00 11 86 05 01 01 01 A0 80 60 80 A1 80 06 07 04 00 00 01 00 03 02
00 00 00 00 00 00 00 00 00 00 6C 80 A1 80 02 01 04 02 01 04 302B 80 08 64 00
22 07 08 00 51 F5 81 06 91 68 31 09 82 F0 82 07 91 68 31 28 07 10 55 84 04 13
26 00 0D A5 08 0A 01 01 04 03 04 01 A0 00 00 00 00 00 00
Message analysis:
>SCCP NAT 4645 004 000009 000008 09(Message type: UDT) 81(Protocol type:
Sequential connectionless service of Class 1 messages, message return)
03(Pointer 1 of mandatory variable length part : Called address) 0D(Pointer 2 of
mandatory variable length part : Calling address ) 16(Start pointer of optional
part) 0A(Length of the called address) 52 07 00 11 04 68 31 09 82 F1 09 (Length
of the calling address) 12 06 00 12 04 68 31 28 07 6B(Subscriber data length)
62(BEGIN) 80 48 (Source transaction identifier) 04 38 01 01 8A 6B(Dialogue
part tag) 80 28(External tag) 80 06(Destination identification tag: Dialogue PDU)
07 00 11 86 05 01 01 01 A0(Single ASN1 tag) 80 60(Dialogue request tag) 80
A1(Context-specific tag) 80 06(Destination identification tag) 07 04 00 00 01 00
03 02 00 00 00 00 00 00 00 00 00 00 6C(Component part tag) 80 A1(Component
type tag: Invoke) 80 02(Invoke tag) 01 04(INVOKE ID)02(Operation code tag)01
04(PROVIDE_ROAMING_NO) 30(SEQUENCE)2B 80(IMPL OCTET STRING:0)
08 64 00 22 07 08 00 51 F5 81(IMPL OCTET STRING:1) 06 91 68 31 09 82 F0
82(IMPL OCTET STRING:2) 07 91 68 31 28 07 10 55 84(IMPL OCTET
STRING:4) 04 13 26 00 0D A5(IMPL SEQU:5) 08 0A(ENUM:1) 01 01 04(OCTET
STRING) 03 04 01 A0 00 00 00 00 00 00
3. PROVIDE_ROAMING_NO_RSP
<SCCP NAT 4662 003 000008 000009 09 00 03 0C 16 09 12 06 00 12 04 68
31 28 07 0A 52 07 00 11 04 68 31 09 82 F1 57 64 80 49 04 38 01 01 8A 6B 80 28
80 06 07 00 11 86 05 01 01 01 A0 80 61 80 A1 80 06 07 04 00 00 01 00 03 02 00
00 A2 03 02 01 00 A3 05 A1 03 02 01 00 00 00 00 00 00 00 00 00 6C 80 A2 80
02 01 04 30 80 02 01 04 04 07 91 68 31 09 82 00 10 00 00 00 00 00 00 00 00
52
Issue 3.3
Message analysis:
<SCCP NAT 4662 003 000008 000009 09(Message type: UDT) 00(Protocol
type: Category 0 basic connectionless service without returned
message)03(Pointer 1 of mandatory variable length part : Called address)
0C(Pointer 2 of mandatory variable length part : Calling address ) 16(Start pointer
of optional part) 09(Length of the called address) 12 06 00 12 04 68 31 28 07 0A
(Length of the calling address) 52 07 00 11 04 68 31 09 82 F1 57(Subscriber
data length) 64(END) 80 49 (Destination transaction identifier) 04 38 01 01 8A
6B(Dialogue part tag) 80 28(External tag) 80 06(Destination identification tag:
Dialogue PDU) 07 00 11 86 05 01 01 01 A0(Single ASN1 tag) 80 61(Dialogue
response tag) 80 A1(Context-specific tag) 80 06(Destination identification tag) 07
04 00 00 01 00 03 02 00 00 A2(Result tag) 03 02 01 00 A3(Result source
diagnosis tag) 05 A1 03 02 01 00 00 00 00 00 00 00 00 00 6C(Component part
tag) 80 A2(Component type tag: Final returned results) 80 02(Invoke tag) 01
04(INVOKE ID)30(Sequence tag)80 02(Operation code tag) 01
04(PROVIDE_ROAMING_NO)04(OCTET STRING) 07 91 68 31 09 82 00 10 00
00 00 00 00 00 00 00
4. SEND_ROUTING_INFO_RSP
>SCCP NAT 4684 009 000009 000008 09 00 03 0D 16 0A 52 08 00 11 04 68
31 09 82 F0 09 52 06 00 12 04 68 31 28 07 63 64 80 49 04 39 01 00 38 6B 80
28 80 06 07 00 11 86 05 01 01 01 A0 80 61 80 A1 80 06 07 04 00 00 01 00 05 02
00 00 A2 03 02 01 00 A3 05 A1 03 02 01 00 00 00 00 00 00 00 00 00 6C 80 A2
80 02 01 00 30 80 02 01 16 30 13 04 08 64 00 22 07 08 00 51 F5 04 07 91 68 31
09 82 00 10 00 00 00 00 00 00 00 00
Message analysis:
>SCCP NAT 4684 009 000009 000008 09(Message type: UDT) 00(Protocol
type: Category 0 basic connectionless service without returned
message)03(Pointer 1 of mandatory variable length part : Called address)
0D(Pointer 2 of mandatory variable length part : Calling address ) 16(Start pointer
of optional part) 0A(Length of the called address) 52 08 00 11 04 68 31 09 82 F0
09 (Length of the calling address) 52 06 00 12 04 68 31 28 07 63(Subscriber
data length) 64(END)80 49 (Destination transaction identifier) 04 39 01 00 38
response tag) 80 A1(Context-specific tag) 80 06(Destination identification tag) 07
04 00 00 01 00 05 02 00 00 A2(Result tag) 03 02 01 00 A3(Result source
diagnosis tag) 05 A1 03 02 01 00 00 00 00 00 00 00 00 00 6C(Component part
tag) 80 A2(Component type tag: Final returned results) 80 02(Invoke tag) 01
00(INVOKE ID)30(Sequence tag)80 02(Operation code tag) 01
16(SEND_ROUTING_INFO)30(SEQUENCE) 13 04(OCTET STRING) 08 64 00
22 07 08 00 51 F5 04(OCTET STRING) 07 91 68 31 09 82 00 10 00 00 00 00 00
00 00 00
53
Issue 3.3
4.2.2 Location Updating Flow
The location updating flow of the C/D interface is as follows:

VLRMAP
HLRMAP
SEND_AUTHENTICATION_INFO
---------------------------------------------->
SEND_AUTHENTICATION_INFO_RSP
<----------------------------------------------
UPDATE_LOCATION
---------------------------------------------->
INSERT_SUBSCRIBER_DATA
<----------------------------------------------
INSERT_SUBSCRIBER_DATA_ACK
---------------------------------------------->
UPDATE_LOCATION_ACK
<----------------------------------------------
The specific messages on the C/D interface are as follows:
1) SEND_AUTHENTICATION_INFO
<SCCP NAT 9100 005 000008 000009 09 81 03 0C 16 09 12 06 00 12 04 68
31 28 07 0A 12 08 00 11 04 68 31 09 82 F0 48 62 80 48 04 39 01 00 2C 6B 80
28 80 06 07 00 11 86 05 01 01 01 A0 80 60 80 A1 80 06 07 04 00 00 01 00 0E 02
00 00 00 00 00 00 00 00 00 00 6C 80 A1 80 02 01 00 02 01 38 04 08 64 00 22 07
08 00 51 F4 00 00 00 00 00 00
Message analysis:
type: Sequential connectionless service of Class 1 messages, message
return)03(Pointer 1 of mandatory variable length part : Called address)
of optional part)09(Length of the called address)12 06 00 12 04 68 31 28 07 0A
(Length of the calling address) 12 08 00 11 04 68 31 09 82 F0 48(Subscriber data
length)62(BEGIN)80 48 (Source transaction identifier)04 39 01 00 2C
request tag) 80 A1(Context-specific tag) 80 06(Destination identification tag) 07
04 00 00 01 00 0E 02 00 00 00 00 00 00 00 00 00 00 6C(Component part tag) 80
A1(Component type tag: Invoke) 80 02(Invoke tag) 01 00(INVOKE ID)
54
Issue 3.3
02(Operation code tag) 01 38(SEND_AUTH_INFO) 04(OCTET STRING) 08 64

00 22 07 08 00 51 F4 00 00 00 00 00 00
2. SEND_AUTHENTICATION_INFO_RSP
<SCCP NAT 9137 00d 000009 000008 09 00 03 0D 16 0A 52 08 00 11 04 68 31
09 82 F0 09 52 06 00 12 04 68 31 28 07 E1 64 80 49 04 39 01 00 2C 6B 80 28
80 06 07 00 11 86 05 01 01 01 A0 80 61 80 A1 80 06 07 04 00 00 01 00 0E 02 00
00 A2 03 02 01 00 A3 05 A1 03 02 01 00 00 00 00 00 00 00 00 00 6C 80 A2 80
02 01 00 30 80 02 01 38 30 81 90 30 22 04 10 11 11 11 11 11 11 11 11 11 11 11
11 11 11 11 11 04 04 02 02 02 02 04 08 03 03 03 03 03 03 03 03 30 22 04 10 11
11 11 11 11...
Message analysis:
<SCCP NAT 9137 00d 000009 000008 09(Message type: UDT) 00(Protocol type:
Class 0 basic connectionless service without returned message)03(Pointer 1 of
mandatory variable length part : Called address) 0D(Pointer 2 of mandatory
variable length part : Calling address ) 16(Start pointer of optional part) 0A(Length
of the called address) 52 08 00 11 04 68 31 09 82 F0 09 (Length of the calling
address) 52 06 00 12 04 68 31 28 07 E1(Subscriber data length) 64(END) 80 49
(Destination transaction identifier)04 39 01 00 2C 6B(Dialogue part tag) 80
28(External tag) 80 06(Destination identification tag: Dialogue PDU) 07 00 11 86
05 01 01 01 A0(Single ASN1 tag) 80 61(Dialogue response tag) 80 A1(Context-
specific tag) 80 06(Destination identification tag) 07 04 00 00 01 00 0E 02 00 00
A2(Result tag) 03 02 01 00 A3(Result source diagnosis tag) 05 A1 03 02 01 00 00
00 00 00 00 00 00 00 6C(Component part tag) 80 A2(Component type tag: Final
returned results) 80 02(Invoke tag) 01 00(INVOKE ID) 30(Sequence tag)80
02(Operation code tag)01 38(SEND_AUTH_INF) 30(SEQUENCE) 81 90 30 22
04 10 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 04 04 02 02 02 02 04 08 03
03 03 03 03 03 03 03 30 22 04 10 11 11 11 11 11...
3. UPDATE_LOCATION
<SCCP NAT 9299 006 000008 000009 09 81 03 0C 16 09 12 06 00 12 04 68
31 28 07 0A 12 08 00 11 04 68 31 09 82 F0 5A 62 80 48 04 39 01 00 2E 6B 80
28 80 06 07 00 11 86 05 01 01 01 A0 80 60 80 A1 80 06 07 04 00 00 01 00 01 02
00 00 00 00 00 00 00 00 00 00 6C 80 A1 80 02 01 00 02 01 02 30 1A 04 08 64 00
22 07 08 00 51 F4 81 06 91 68 31 09 82 F0 04 06 91 68 31 09 82 F1 00 00 00
00 00 00
Message analysis:
<SCCP NAT 9299 006 000008 000009 09(Message type: UDT)
81(Protocol type: Sequential connectionless service of Class 1 messages,
message return) 03(Pointer 1 of mandatory variable length part : Called address)
of optional part) 09(Length of the called address) 12 06 00 12 04 68 31 28 07
0A (Length of the calling address) 12 08 00 11 04 68 31 09 82 F0 5A(Subscriber
data length) 62(BEGIN) 80 48 (Source transaction identifier) 04 39 01 00 2E
55
Issue 3.3

request tag) 80 A1(Context-specific tag) 80 06(Destination identification tag) 07
04 00 00 01 00 01 02 00 00 00 00 00 00 00 00 00 00 6C(Component part tag) 80
A1(Component type tag: Invoke) 80 02(Invoke tag) 01 00(INVOKE ID)
02(Operation code tag) 01 02(UPDATE_LOCATION) 30(SEQUENCE) 1A
04(OCTET STRING) 08 64 00 22 07 08 00 51 F4 81(IMPL OCTET STRING:1) 06
91 68 31 09 82 F0 04(OCTET STRING) 06 91 68 31 09 82 F1 00 00 00 00 00 00
4. 4 INSERT_SUBSCRIBER_DATA
>SCCP NAT 9354 00e 000009 000008 09 00 03 0D 16 0A 52 08 00 11 04
68 31 09 82 F0 09 52 06 00 12 04 68 31 28 07 70 65 80 48 04 38 01 00 CD 49
04 39 01 00 2E 6B 80 28 80 06 07 00 11 86 05 01 01 01 A0 80 61 80 A1 80 06 07
04 00 00 01 00 01 02 00 00 A2 03 02 01 00 A3 05 A1 03 02 01 00 00 00 00 00 00
00 00 00 6C 80 A1 80 02 01 03 02 01 07 30 1E 8008 64 00 22 07 08 00 51 F4 81
07 91 68 31 28 07 10 45 82 01 01 83 01 00 A6 03 04 01 11 00 00 00 00 00 00
Message analysis:
>SCCP NAT 9354 00e 000009 000008 09(Message type: UDT) 00(Protocol
type: Class 0 basic connectionless service without returned message) 03(Pointer
1 of mandatory variable length part : Called address) 0D(Pointer 2 of mandatory
address) 52 06 00 12 04 68 31 28 07 70(Subscriber data length)
65(CONTINUE)80 48 (Source transaction identifier) 04 38 01 00 CD 49
(Destination transaction identifier) 04 39 01 00 2E 6B(Dialogue part tag) 80
28(External tag) 80 06(Destination identification tag: Dialogue PDU) 07 00 11 86
05 01 01 01 A0(Single ASN1 tag) 80 61(Dialogue response tag) 80 A1(Context-
specific tag) 80 06(Destination identification tag) 07 04 00 00 01 00 01 02 00 00
A2(Result tag) 03 02 01 00 A3(Result source diagnosis tag) 05 A1 03 02 01 00 00
00 00 00 00 00 00 00 6C(Component part tag) 80 A1(Component type tag:
Invoke) 80 02(Invoke tag) 01 03(INVOKE ID) 02(Operation code tag) 01
07(INSERT_SUBSCRIBER_DATA) 30(SEQUENCE) 1E 80(IMPL OCTET
STRING:0) 08 64 00 22 07 08 00 51 F4 81(IMPL OCTET STRING:1) 07 91 68 31
28 07 10 45 82(IMPL OCTET STRING:2) 01 01 83(IMPL OCTET STRING:3) 01
00 A6(IMPL SEQUENCE) 03 04 01 11 00 00 00 00 00 00
5. INSERT_SUBSCRIBER_DATA_ACK
1 of mandatory variable length part : Called address) 0C(Pointer 2 of mandatory
variable length part : Calling address ) 16(Start pointer of optional part) 09(Length
of the called address) 12 06 00 12 04 68 31 28 07 0A (Length of the calling
address) 12 08 00 11 04 68 31 09 82 F0 1B(Subscriber data length)
65(CONTINUE)80 48 (Source transaction identifier) 04 39 01 00 2E 49
56
Issue 3.3
(Destination transaction identifier) 04 38 01 00 CD 6C(Component part tag) 80

A2(Result tag) 80 02(Invoke tag) 01 03(INVOKE ID)00 00 00 00 00 00
6. UPDATE_LOCATION_ACK
>SCCP NAT 9375 000 000009 000008 09 00 03 0D 16 0A 52 08 00 11 04 68
31 09 82 F0 09 52 06 00 12 04 68 31 28 07 23 64 80 49 04 39 01 00 2E 6C 80
A2 80 02 01 00 30 80 02 01 02 04 05 91 68 31 28 07 00 00 00 00 00 00 00 00
Message analysis:
>SCCP NAT 9375 000 000009 000008 09(Message type: UDT) 00(Protocol
1 of mandatory variable length part : Called address) 0D(Pointer 2 of mandatory
address) 52 06 00 12 04 68 31 28 07 23(Subscriber data length) 64(END) 80 49
(Destination transaction identifier)04 39 01 00 2E 6C(Component part tag) 80
A2(Result tag) 80 02(Invoke tag) 01 00(INVOKE ID) 30(SEQUENCE) 80
02(Operation code tag) 01 02(UPDATE_LOCATION) 04(OCTET STRING) 05 91
68 31 28 07 00 00 00 00 00 00 00 00
According to the analysis of the call flow and the location updating flow, it have
already been known that the specific MAP service message exists in the TCAP
message in the form of component. Generally, the message types of the MAP
service correspond to the operation codes in the TCAP message one by one.
However, during the message transfer, one message corresponds to an invoke
ID. An invoke ID is the only ID of a message during the MAP dialogue. With the
differentiation of the invoke ID, a component can be translated into the
corresponding MAP service message.
4.3 Brief Introduction to C/D Interface Flow

In the above section, we have set the call flow and normal location updating flow
of the C/D interface as an example to describe the common considerations and
methods of message analysis. In this section, some other flows and standard
MAP error codes on the C/D are described, which will help the signalling analysis
greatly.
1) cancel location
57
Issue 3.3
New Old
HLR D VLR
VLR
Update location
Delete location
Confirmation
Figure1.1 Deleting location
After receiving the location updating request, the VLR will judge the location area:
For the location area updating in the same VLR, the location updating request will
not be sent to the HLR, or the location updating will be requested from the HLR.
Before returning the VLR location updating confirmation signal, the HLR will start
another process to insert the subscriber data. Furthermore, the location updating
confirmation signal returned to the VLR will carry the HLR number.
During the location updating, if a subscriber roams to a new VLR, then in the
location register program, the HLR will send a delete command to the VLR so as
to delete the data of the subscriber.
2. Data updating in VLR
During the location updating, the HLR transfers the data to be inserted into the
VLR to the VLR, or due to management reason, the HLR informs the VLR of the
new subscriber data (after the OMC modification), including the deletion of the
subscriber data.
58
Issue 3.3
VLR D
HLR
Insert subscriber data
Confirm subscriber data insertion
<Insert subscriber data program>
VLR D
HLR
Delete subscriber data
Confirm subscriber data deletion
Figure1.2 Data updating in VLR
3. Procedures for obtaining routing data during call setup
C D
GMSC HLR VLR
Send routing message

MSISDN Provide roaming number
Roaming number
Confirmation (MSRN)
Figure1.3 Procedures for obtaining routing information during call setup
When the HLR returns signal, if the called subscriber activates some
supplementary services, the HLR will use the number (forwarding number) of the
supplementary services to replace the roaming number.
In the book of Communication Flow, the main communication flow of the whole
GSM system has been described in detail, so we emphasize on the interface flow
in the signaling analysis.
In Chapter 3, we have already introduced the operation codes used in the MAP.
Here, we will introduce the standard error codes of the MAP for the convenience
of application in later signaling analysis.
59
Issue 3.3
/*Definitions of standard MAP errors*/

UNKNOWN_SUBSCRIBER, /*1*/
UNKNOWN_BASE_STATION, /*2*/
UNKNOWN_MSC, /*3*/
UNKNOWN_LOC_AREA, /*4*/
UNIDENTIFIED_SUBSCRIBER, /*5*/
UNALLOCATED_ROAMING_NUMBER, /*6*/
UNKNOWN_EQUIPMENT, /*7*/
ROAMING_NOT_ALLOWED, /*8*/
ILLEGAL_MS, /*9*/
BEARER_SERVICE_NOT_PROVISIONED, /*10*/
TELESERVICE_NOT_PROVISIONED, /*11*/
INSUFFICIENT_BEARER_CAPABILITIES, /*12*/
CALL_BARRED, /*13*/
FORWARDING_VIOLATION, /*14*/
CUG_REJECT, /*15*/
ILLEGAL_SS_OPERATION, /*16*/
SS_ERROR_STATUS, /*17*/
SS_NOT_AVAILABLE, /*18*/
SS_SUBSCRIPTION_VIOLATION, /*19*/
SS_INCOMPATIBILITY, /*20*/
FACILITY_NOT_SUPPORTED, /*21*/
INVALID_TARGET_BASE_STATION=23, /*23*/
NO_RADIO_RESOURCE_AVAILABLE, /*24*/
NO_HANDOVER_NUMBER_AVAILABLE, /*25*/
SUBSEQUENT_HANDOVER_FAILURE, /*26*/
ABSENT_SUBSCRIBER, /*27*/
BUSY_SUBSCRIBER, /*28*/
NO_SUBSCRIBER_REPLY, /*29*/
RADIO_CONGESTION, /*30*/
IMPOSSIBLE_CALL_COMPLETION, /*31*/
SUBSCRIBER_BUSY_FOR_MT_SMS = \
60
Issue 3.3
IMPOSSIBLE_CALL_COMPLETION , // 31
SM_DELIVERY_FAILURE = 32, /*32*/
MESSAGE_WAITING_LIST_FULL, /*33*/
SYSTEM_FAILURE, /*34*/
DATA_MISSING, /*35*/
UNEXPECTED_DATA_VALUE, /*36*/
PASSWORD_REGISTRATION_FAILURE, /*37*/
NEGATIVE_PASSWORD_CHECK, /*38*/
NO_ROAMING_NUMBER_AVAILABLE, /*39*/
TRACING_BUFFER_FULL, /*40*/
NUM_OF_PW_ATTEMPTS_VIOLATION , /*43*/
NUMBER_CHANGED=44, /*44*/
//_FOR_SMS
ILLEGAL_EQUIPMENT 12,
ERROR_IN_MS 50,
SMS_LOWER_LAYERS_CAPABILITIES_NOT_PROVISIONED 51 ,
MEMORY_CAPACITY_EXCEEDED 52 ,
SC_CONGESTION 53 ,
MS_NOT_SC_SUBSCRIBER 54,
INVALID_SME_ADDRESS 55,
ABSENT_SUBSCRIBER_WITHOUT_PARA= 56,
//end of _FOR_SMS
ERROR_CODE_BUTT /*41 end tag*/
4.4 Summary
This chapter mainly describes the flow and message analysis method of the C/D
interface. Through the learning of this chapter, we can conduct the message
analysis of the C/D interface with the combination of the flow of the C/D interface.
4.5 Exercise
In a laboratory, please trace the location updating process of a mobile phone in
the link of the C/D interface and analyze the traced information.
61
Issue 3.3
Chapter 5 Signaling Analysis of A Interface
5.1 Protocols of A Interface

Before introducing the protocols of the A interface, let us first review the model of
the GSM signaling system:
MS BTS BSC MSC
CC CC
MM MM
BSSMAP
RR RR BSSAP
L3
RR BTSM BTSM
SCCP SCCP
L2 LAPDm LAPDm LAPD LAPD
MTP MTP
L1 Sign. Sign. Sign. Sign.
Layer 1 Layer 1 Layer 1 Layer 1
Um A-bis A
Figure1.1 Signaling model of the GSM system
For the radio interfaces, many important protocols in the GSM system are
concerned. First, the bottommost layer is the Transport Layer between the BTS
and MS, then the Data Link Layer (the second layer of the radio interfaces) and
the Application Layer (the third layer), where, including the protocol RR (Radio
Resources management) which also appears on the Abis interface. The upper-
layer protocols (MM and CC) have specified signaling switching rules between
the entities of the MS and network. These protocols also appear on the Abis and
A interfaces. It can be seen from the above analysis that the BTS and BSC are
transparent for the switching of some signalings. They only transfer but do not
process the information. For internal connection of the network, each equipment
has unitary interface, i.e., the CCS7 signaling network is used to support the
signaling switching between different kinds of equipment.
The A interface can be used to transfer two kinds of messages: BSSMAP
message and DTAP message. Where, the BSSMAP message is responsible for
the service flow control, which needs the processing of the corresponding
interface functional module of the A interface. For the DTAP message, the A
interface is equivalent to a transmission channel. From the NSS to the BSS, the
62
Issue 3.3
DTAP message is directly transferred to the radio channels; while from the BSS
to the NSS, the DTAP message is transferred to the corresponding function
processing unit. For the A interface, the DTAP message is transparent.
The A interface is based upon the MTP and SCCP of SS7. The structure model is
shown in Figure 5-2:
Air interface transmission Processing module Various applications and control modules
equipment within BSC
BSSAP BSSAP
DTAP BSSMAP DTAP BSSMAP
Allocation function Allocation function
SCCP SCCP
MTP MTP
A interface
BSS MSC
Figure1.2 Protocol structure of A interface
On the A interface, the point-to-point connection is used and various kinds of

service and control information are transferred between the MSC and the BSS.
For the implementation mode, please first set the signaling point codes at the two
ends of the interface, and the direct addressing mode (DPC + SSN) is used
between them so that the addressing mode is simplified at most and the network
architecture is simpler.
5.2 BSSAP
The Base Station Subsystem Application Part (BSSAP) is located on the upper
layer of the SCCP. The BSSAP of the GSM system includes the DTAP and the
BSSMAP, with additional the allocation function. Its architecture is shown in
Figure 5-3:
DTAP BSSMAP
Allocation function
SCCP
Figure1.1 BSSAP architecture
63
Issue 3.3
1) Allocation function
The allocation sublayer between the SCCP and the L3 implements the following
functions:
(a) Differentiating the DTAP and BSSMAP messages.
(b) Allocating the DTAP messages from the MSC to the L2 access point of each
radio link.
(c) Converging the DTAP messages received from the L2 access point of each
radio link to the signaling link of the A interface.
The protocol of this sublayer only simply includes 1-octet or 2-octet data unit.
Each SCCP subscriber data field should include an allocation data unit to serve
as the initial tag, then include the length indication and the BSSMAP and DTAP
messages of L3. The differences between the DTAP and the BSSMAP are shown
in Figure 5-4:
DTAP BSSMAP
Octet 1 Discrimination parameter Octet 1 Discrimination parameter Allocation data unit
Octet 2 DLCI
Octet 3 Length indication (L) Octet 2 Length indication (L) Length indication
L3 Octet 3 L3
Octet 4
: :
L3 message
: :
Octet L+3 L3
Octet L+3 Message
Figure1.2 BSSMAP and DTAP message structure
2. Transmission of DTAP messages

The DTAP is responsible for transparent transmission of L3 messages from an
MS to the MSC or from the MSC to the MS. The BSS will not make any analysis
of the contents. The Class-2 service (basic connection-oriented class) of the
SCCP is used for transmission between the BSS and the MSC.
The subscriber data field includes the allocation data unit, length indication and
actual L3 message. Where, the allocation data unit includes two parameters:
Discrimination parameter and Data Link Connection Identifier (DLCI) parameter.
In this case, the discrimination parameter is set as transparent transmission code
as follows:
Bit 8 7 6 5 4 3 2 1
Discrimination parameter 0 0 0 0 0 0 0 D Where D = 1, indicating transparent transmission
Figure1.3 Discrimination parameter code of DTAP message
64
Issue 3.3
In the messages sent from the MSC to the BSS, the parameter DLCI is used to
indicate the data link type applied to the radio interface; while in the messages
sent from the BSS to the MSC, it is used to indicate the data link type of
generating the data on the radio interface.
3. Transmission of BSSMAP messages
The transmission of the BSSMAP messages in the SCCP is to implement the
information exchange between the BSSMAP functional entities of the MSC and
BSS. The allocation data unit of the BSSMAP messages only includes the
discrimination parameter. Where the discrimination parameter D is configured as
0, indicating non-transparent transmission.
Bit 8 7 6 5
Discrimination parameter Where D = 1, non-transparent transmission
40 0 30 0 20 01 0 D
Figure1.4 Discrimination parameter code of BSSMAP message
In actual operations, many SCCP messages can be seen in the link tracing
between the MSC and the BSC, where the BSSMAP DTAP messages are
included to serve as the subscriber data. The analysis of the SCCP message has
been described in detail in the elementary signaling course and Chapter 3 in this
document. Here, based upon the above descriptions, a BSSMAP message and a
DTAP message are used for the brief explanation of SCCP message analysis.
A complete SCCP CR message from the BSS to the MSC is described as follows:
01 03 00 41 02 02 06 04 43 02 13 FE 04 04 43 BA 13 FE 0F 1E
00 1C 57 05 08 00 64 F0 13 13 09 00 01 17 0F 05 08 71 64 F0 13 13 09 23 05
F4 32 D3 07 00
The analysis is as follows:
The first line: 01 (Message type: CR) 03 00 41(Source local reference) 02
(Protocol type: Class 2) 02 (Pointer of the called address) 06 (Start pointer of
optional part) 04(Length of the called address) 43 02 13 FE 04(Optional
parameter name: Calling address ) 04 (Length of the calling address) 43 BA 13
FE 0F(Optional parameter name: Subscriber data)1E(Subscriber data length)
From the second line to the last 00 is the BSSMAP message (the last 00
indicates the end of the subscriber data). The meaning of each 8-bit decimal
number is as follows:
00: Discrimination parameter, here indicating the BSSMAP message
1C: Length of the BSSMAP message
57: Message type, L3 message
05: Message unit identification, it is the cell identification message unit
08: Length of the message unit
00: Cell identification discriminator, here it indicates the GCI code
65
Issue 3.3
64 F0 13 13 09 00 01 : Cell and GCI code, it ends when the cell identification

message unit reaches 8 bytes.
17: Message unit identification, it is the complete L3 message unit.
0F: Length of the message unit
05: The higher four bits indicate the jumping indication and the lower four bits
indicate the protocol discrimination: This is the mobility management message.
08: MM message type: Location updating request message
71: Higher 4BITS location updating type and lower 4BITS key sequence number
64 F0 13 13 09: Location area identification, five octets in total
23: Type of mobile type: Providing information on high priority of MS equipment
05: Length of MS identification unit
F4 32 D3 07 00: MS identification and the 3 bits after F4 indicate TMSI.
Set a DTAP message example once again, in the following, the DT1 message of
the SCCP is sued to transfer TMSI re-allocation completion message from the
BSS to the MSC:
06 00 00 40 00 01 05
01 00 02 05 5B
The first line 06(SCCP Message type DT1)00 00 40(Destination local reference)
00 (Segmentation/reassembly: Segmentation/reassembly is needed) 01 (Pointer
of subscriber data) 05 (Subscriber data length)
The second line indicates the DTAP message
01: Discrimination parameter, indicating the DTAP message
00: DLCI
02: Message length
05: The front four bits indicate the jumping indication and the last four bits
indicate the protocol discriminator: This is the mobility management message.
5B: Message type: Indicating the TMSI re-allocation is completed.
5.3 A Interface Flow

The A interface can use the two forms of the SCCP (connection-oriented class
and connectionless class) to implement its functions. When an MS and the
network need to switch communication-related information in radio resources, but
there is no MS-related SCCP connection between the MSC and the BSS, a new
connection should be set up. Furthermore, a new connection is also needed for
external handover.
There are two connection setup cases:
66
Issue 3.3
1) Setting up a new processing connection in the radio channel: when the MS

sends the access request message in the RACH, the BSS will allocate a
dedicated radio resource (DCCH or TCH) to the MS. After the L2 connection
is set up in the SDCCH (or FACCH) channel of the allocated resource, the
BSS will start the connection setup.
2. If the MSC wants to conduct an external handover (the destination
BSS is possibly the original BSS), then a new DCCH or TCH
should be reserved for the destination BSS. In this case, the MSC
starts the connection setup.
With the connection or connectionless messages, the A interface mainly
implements the following functional flow:
64. Assignment
The purpose of the assignment is to guarantee the correct radio resource
allocation or reallocate it to the MS needing the resource. Thus, the initial MS will
immediately access and immediately be assigned to a DCCH, which is
processed by the BSS itself and is not under the control of the MSC.
65. Block and unblock
In the assignment program, the MSC should select appropriate ground circuits.
Therefore, if the BSS thinks that some ground circuits not be used continuously, it
should inform the MSC. The block/unblock flow can implement this function.
66. Resource indication
The purpose of the resource indication is to inform the MSC of the following
information:
(a) The quantity of the free radio resources which can serve as the service
channels in the BSS
(b) The quantity of all available radio resources (i.e., the quantity of the radio
resources which can provide services or have already been assigned).
These quantities cannot be easily exported by the MSC from the service
conditions. These information can be considered when the MSC wants to initiate
the external handover.
67. Reset
The purpose of the rest is to initialize the faulty BSS or MSC, for example, if the
BSS fails and loses all reference information on processing, then the BSS will
send the reset message to the MSC to request the MSC to release the
influenced calls, delete the influenced reference information and set all circuits
related to the BSS as Free state.
If it is only a local MSC or BSS fault, the clear program can be used to clear the
influenced part.
68. Handover requirement
67
Issue 3.3
For the following reasons, the BSS can send the Handover requirement to the
MSC to require the handover for an MS already allocated with dedicated
resources:
(a) The BSS detects a radio reason for the handover.
(b) The MSC starts the handover candidate query program and the MS is waiting
the handover.
(c) Due to congestion, the service cell needs to be changed during the call setup
stage, for example, directional retry.
The handover requirement requires the message to be retransmitted every a
period of time until one of the following phenomena occurs:
(a) Receiving the handover command message from the MSC
(b) Receiving the reset message
(c) All communications with the MS are interrupted and the processing is aborted.
(d) The processing ends, for example, call clear.
69. Handover resource allocation
With the handover resource allocation, the MSC can request resource from the
destination BSS and the BSS will reserve the resource and wait the next MS to
access this channel.
70. Handover execution
The handover execution is a process in which the MSC indicates the MS to
access the dedicated radio resources of another cell. During the handover
execution, the original dedicated radio resources and ground resources will be
held until the MSC sends the clear command message or resets.
71. Handover candidate query
With the handover candidate query program, the MSC can determine whether
some MSs in a special cell can be handed over to other designated cells. Only
one Handover candidate query message can be sent to a cell once.
72. Release of radio resources and ground resources
When a certain processing is completed, the MSC sends a clear command to
instruct the BSS to release the radio resources. When receiving the command,
the BSS will start the clear program on the radio interface, and then set the
dominated ground circuits as free state and then return a clear completion
message to the MSC. Then, the MSC will release the local ground resources.
If the resource release is needed due to BSS reasons, the BSS will send a clear
request to request the MSC to release the response resources.
73. Paging
68
Issue 3.3
The connectionless service of the SCCP is used to transfer the MS paging

through the BSSMAP. If the BSS receives the paging response message on the
radio channel interface, it will set up a connection from the MSC to the SCCP.
The paging response message is loaded in the Complete L3 message of the
BSSMAP and is transferred to the MSC through this signaling connection.
74. Trace request
The purpose of the trace request is to notify the entity receiving this message to
conduct trace record of the service processing this time. On the A interface, this
message should be transferred in the connection-oriented service traced and
recorded, but does not require confirmation.
75. Flow control
The flow control can prevent the entities from entering instable state due to
receiving excessive services. The A interface implements the flow control by
notifying the service source to reduce the traffic.
76. Level processing
The purpose of the level updating is to inform the receiving entity of the level
information received by the MS. Generally, the BSS either informs the MSC after
receiving the level information from the MS or after the handover is completed.
The MSC sends the level information of the corresponding MS to the new BSS
through the A interface.
77. Encryption mode control
The encryption mode control flow permits the MSC to transfer the encryption
mode control information to the BSS and start the user equipment and signaling
encryption equipment with correct keys.
78. Queue indication
The purpose of this program is to notify the MSC and BSS to delay the allocation
of the necessary radio resources. This program takes effect only when the queue
function is used for the service channel assignment and handover in the BSS.
79. Load indication
The purpose of the load indication is inform all the neighboring BSSs of the
service conditions of a cell so that the handover service in an MSC can receive
overall control.
5.4 Analysis of A Interface Messaged
5.4.1 Brief Introduction to A interface Messages
After learning the A interface flow and protocols, we will focus on the analysis of
the A interface messages in this section. First, we will take a look at the main
messages of the A interface:
69
Issue 3.3
1) Connection setup messages:

80. Location updating Request
81. CM Service Request message
82. Connect Confirm message
2. Normal connection messages:
83. AUTHENTICATION REQUEST message
84. AUTHENTICATION RESPONSE message
85. CIPHER MODE COMMAND message
86. CIPHER MODE COMPLETE message
87. LOCATION UPDATING ACCEPT message
88. CM SERVICE ACCEPT message
89. SETUP message
90. CALL PROCEEDING message
91. ASSIGNMENT REQUEST message
92. ASSIGNMENT COMPLETE message
93. ALERTING message
94. CONNECT message
95. CONNECT ACKNOWLEDGE connection}
96. DISCONNECT message
97. RELEASE message
98. RELEASE COMPLETE message
99. CLEAR COMMANG
100. CLEAR COMPLETE
3. Connectionless message:
101. RESET CIRCUIT
102. BLOCK CIRCUIT
103. UNBLOCK CIRCUIT
104. RESET message
105. Unequipped circuit
70
Issue 3.3
5.5 Message Analysis
1. Location updating message
In the following, we will make a detailed analysis of the location updating

message traced on an A interface:
FB 0B 3B C3 B2 40 30 E0 01 01 00 41 02 02 06 04 43 B2 00 FE 04 04 43 C1 00
FE 0F 21 00 1F 57 05 08 00 64 F0 20 25 00 00 01 17 12 05 08 20 64 F0 00 25
00 01 08 49 06 20 72 90 00 00 60 00
first, we will analyze the MTP and SCCP messages (note: X indicates the BIT to
be analyzed and ? indicates BIT not analyzed for the time being):
corresponding
Standard message format Corresponding message contents
byte
?XXXXXXX BSN ?1111010 Backward sequence number 0xFB
X??????? BIB 1??????? Backward indication bit
?XXXXXXX FSN 0??????? Forward sequence number 0x0B
X??????? FIB ?0001011 Forward indication bit
??XXXXXX LI ??111011 Signal unit length indication 0x3B
code
XX?????? 00?????? Invalid segment
????XXXX SI ????0011 Service indicator 0xC3
??XX???? ??00???? Invalid segment
??XXXXXX NI 11?????? Network indicator
XXXXXXXX DPC 10100010 Destination signaling point 0xB2
??XXXXXX ??000000 00B2 0x40
0x30
0xE0
XX?????? OPC 01?????? Source signaling point
XXXXXXXX 00110000 00C1
????XXXX ????0000
XXXX???? SLS 1110???? Signaling link selection code
0E
XXXXXXXX Message type 00000001 CR message 0x01
3 bytes Source Local 010041h Source local 0x01
Reference Code 0x00
0x41
????XXXX Protocol type ????0010 Services of Class 2 0x02
XXXX???? 0000???? Invalid segment
1 byte Mandatory 00000010 Pointer of the called address 0x02
variable length
pointer
1 byte Start pointer of 00000110 Pointing at the calling address 0x06
optional part
1 byte Length indicator 04h Length of the called address 0x04
???????X Signaling point ???????1 Including the signaling point 0x43
Indicator code
71
Issue 3.3
corresponding
byte
??????X? Subsystem ??????1? Including subsystem ID
Indicator
??XXXX?? Global title ??0000?? Not including the global title
Indicator
?X?????? Route ?1?????? DPC and SSN routing
Indicator
X??????? 0??????? National standby
2 bytes Signaling point 00B2h Source signaling point code 0xB200
code
1 byte Subsystem No. 0xfe Subsystem of A interface 0xFE
1 byte Optional 0x04 Name of the calling address 0x04
parameter name
5 bytes Optional 04 43 C1 00 The format is the same as that 04 43 C1
parameter FEh of the called address 00 FEh
Contents
1 byte Optional 0x0F SCCP subscriber data 0x0F
parameter name
1 byte Length of optional 0x21 Length of the SCCP subscriber 0x21
parameter data (after it is the BSSAP
message )
Then, let us look at the resolution of the BSSMAP message:
0x00: BSSMAP indicator
0x1f: BSSMAP message length = 31
0x57: Complete L3 information
0x05: Cell ID IEI
0x08: Cell ID length
0x00: Cell ID discriminator
0x64 0xf0: MCC dig.
0x20: MNC dig.
0x25 0x00: LAC
0x00 0x01: CI
0x17: L3 information IEI
0x12: L3 information length = 18
0x05: SI = 0 ( 4 bit ) , PD = B_0101 ( Mobile Manager )
0x08: message type : Locate Update request
0x20: The lower four bits indicate the location updating type, LocUpdate type =
0/1 ( 4 bit ) : Normal Location Updating/Periodic Updating, 0 indicates the normal
location updating. The higher four bits indicate CKSN, Ciphering key sequence =
2
72
Issue 3.3
0x64 0xf0: MCC

0x20: MNC
0x25 0x00: LAC
0x01: Classmark1
0x08: Mobile ID length
0x49: Mobile ID type = 001 (lower three bits) : IMSI
The explanation of the eight bits is as follows:
HGFEDCBA
001 IMSI used for mobile station
010 IMEI used for mobile station
011 IMEISV used for mobile station
100 TMSI used for mobile station
000 No identity
The bit D indicates the odd/even of the identity: 0 indicates even bits and 1
indicates odd bits.
Bits HGFE: If the identity is odd number, then the higher four bits indicate the first
bit of the identity; if the identity is even number, then they should be set as 1111.
Here, since the bit D is 1, the higher four bits indicate the first bit of the IMSI: 4
0x06 0x20 0x72 0x90 0x00 0x00 0x40 : IMSI number
In the above, we have made detailed explanation of an MTP message with
location updating message. Thus, we know the common format of this message,
and in the same way, we can know the specific meaning of the location updating
messages with different information fields and contents.
2. CM Service Request message:
Message traced by the A interface:

91 9C 3B C3 B2 40 30 C0 01 3D 00 41 02 02 06 04 43 B2 00 FE 04 04 43 C1 00
FE 0F 21 00 1D 57 05 08 00 64 F0 20 25 00 00 01 17 12 05 24 21 02 02 04 08
49 06 20 72 90 00 00 60 00 00 00 00
Where, the resolution of the MTP and SCCP messages is basically the same as
that of the location updating message. For details, please refer to the above
analysis.
The resolution of the BSSMAP message is as follows:
73
Issue 3.3
0x1D: BSSMAP message length = 29

0x57: Complete L3 information
0x05: Cell ID IEI
0x64 0xf0: MCC dig.
0x20: MNC dig.
0x25 0x00: LAC
0x00 0x01: CI
0x17 : L3 information IEI
0x10: L3 information length = 16
0x05: TI = 0 ( 4 bit ) , PD = B_0101 ( Mobile Manager )
0x24: message type : CM service request
0x21 CM type = 1 ( 4 bit ) : Mobile Originating Call
Ciphering key sequence = 2 ( 4 bit )
0x02: Classmark 2 information length
0x02 0x00: Classmark 2 information
0x08: Mobile ID length
0x49: Mobile ID type = 001 (lower three bits) : IMSI
0x06 0x20 0x72 0x90 0x00 0x00 0x60: IMSI number
In the above, we have made detailed explanation of an MTP message with the
CM service request message. Thus, we know the common format of this
message, and by analogy, we can know the specific meaning of the CM service
request messages with different information fields and contents.
3. Connect Confirm message:

0C FF 22 C3 C1 80 2C 30 02 03 00 41 00 00 41 02 00
Resolution of the MTP and SCCP messages: (note: X indicates the BIT to be
analyzed and ? indicates the BIT not analyzed for the time being)
Corresponding
byte
?XXXXXXX BSN ?0001100 Backward sequence 0x0C
number
74
Issue 3.3
Corresponding
byte
?XXXXXXX FSN ?1111111 Forward sequence 0xFF.
number
X??????? FIB 1??????? Forward indication bit
??XXXXXX LI ??100010 Signal unit length 0x22
indicator
XXXXXXXX DPC 11000001 Destination signaling 0xC1
??XXXXXX ??000000 point 0x80
00C1 0x2C
0x30
XXXXXXXX 00101100 00B2
????XXXX ????0000
XXXX???? SLS 0011???? Signaling link selection
code
03
XXXXXXXX Message type 00000010 CC message 0x02
3 bytes Destination Local 030041h Destination local 0x03
Reference reference 0x00
0x41
3 bytes Source Local 000041h Source local reference 0x00
Reference 0x00
0x41
????XXXX Protocol type ????0010 code 0x41
1 byte Parameter 00000000 Without optional 0x00
pointer parameter
In the above, we have made detailed explanation of an MTP message with
Connect Confirm" message. Here, the CC message does not have any
parameter. However, by analogy, we can also know the specific meaning of the
CC messages with different information fields and contents.
4. Normal connection message
1) AUTHENTICATION REQUEST message:

0C FF 22 C3 C1 80 2C 30 06 03 00 41 00 01 16 01 00 13 05 12 03 11 11 11 11
11 11 11 11 11 11 11 11 11 11 11 11
First, let us take a look at the resolution of the MTP and SCCP messages: (Note:
X indicates the BIT to be analyzed and ? indicates the BIT not analyzed for the
time being)
75
Issue 3.3
Corresponding
byte
?XXXXXXX BSN ?0001100 Backward sequence number 0x0C
?XXXXXXX FSN ?1111111 Forward sequence number 0xFF
??XXXXXX LI ??100010 Signal unit length indicator 0x22
XXXXXXXX DPC 11000001 Destination signaling point 0xC1
??XXXXXX ??000000 00C1 0x80
0x2C
0x30
XXXXXXXX 00101100 00B2
????XXXX ????0000
03
XXXXXXXX Message type 00000110 DATA FORM 1 0x06
Message
3 bytes Source Local 030041h Source local 0x03
Reference Code 0x00
0x41
1 byte Segmentation/rea 00000000 Without more data 0x00
ssembly
1 byte Mandatory 00000001 Subscriber data pointer 0x01
variable length
pointer
1 byte parameter length 00010110 Subscriber data length (after it 0x16
is the BSSAP message)
The resolution of the DTAP message is as follows:
0x01: DTAP message type
0x00: Spare, DLCI
0x13: DTAP message length
0x05: PD=5 TI=0
0x12: Authentication Request
0x03: CSKN
Authentication parameter rand IEI
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
76
Issue 3.3
authorization request. Thus, we know the common format of this message, and
by analogy, we can know the specific meaning of the authorization request
messages with different information fields and contents..
2. AUTHENTICATION RESPONSE message:
FE 0D 15 C3 B2 40 30 E0 06 00 00 41 00 01 09 01 00 06 05 14 02 02 02 02
The resolution of the MTP and SCCP message header of this message is
basically the same as that of the authorization request message (except the
direction). For details, please refer to the above analysis.
Resolution of the DTAP message:
0x01: DTAP message flag
0x00: Spare
0x06: Length of DTAP message
0x05: Protocol discriminator=5 (L4 bit);Transaction Identifier=0 (H4 bit)
0x14: Message type , Authentication Response
0x02 0x02 0x02 0x02 : Authentication parameter SRES
authorization response message. Thus, we know the common format of this
message, and by analogy, we can know the specific meaning of the authorization
response messages with different information fields and contents..
3. LOCATION UPDATING ACCEPT message:
18 8C 1D C3 C1 80 2C 50 06 07 00 41 00 01 11 01 00 0E 05 02 64 F0 00 25 00
17 05 F4 0A 0E 01 00
basically the same as that of the authorization request message. For details,
please refer to the above analysis.
Please see the resolution of the DTAP message:
0x00: Spare
0x0e: DTAP message length
0x05: PD=5 TI=0
0x02: Location upgrade accept
0x64: MCC digit
77
Issue 3.3
0xf0: MCC third code (L4 bit)

0x00: MCC=460, MNC=0
0x25 0x00: LAC
0x17: Mobile Identify type (O&V)
0x05: Length of mobile identify type
0xf4: L4 bit=0100b: TMSI
0x0A 0x0E 0x01 0x00: TMSI
LOCATION UPDATING ACCEPT message. Thus, we know the common format
of this message, and by analogy, we can know the specific meaning of the
LOCATION UPDATING ACCEPT messages with different information fields and
contents.
4. CM SERVICE ACCEPT message:
18 8C 1D C3 C1 80 2C 50 06 07 00 41 00 01 11 01 00 02 05 21
The resolution of the DTAP message is as follows
0x00 : Spare
0x02 : DTAP message length
0x05: PD_CC
0x21 CM service accept
CM SERVICE ACCEPT message. Thus, we know the common format of this
message, and by analogy, we can know the specific meaning of the CM
SERVICE ACCEPT messages with different information fields and contents
(Note: this message does not have any parameter).
5. SETUP message:
A1 B0 1C C3 B2 40 30 C0 06 3C 00 41 00 01 10 01 00 0D 03 05 04 01 A0 5E 06
80 31 29 07 20 50
78
Issue 3.3
Please see the resolution of the DTAP message in the following:
0x01: dtap_msg_type
0x00: DLCI
0x0d: Length
0x03 : pd_cc
0x05: msg_type
0x04: bear_ie
0x01: bear_len
0xa0: bear_val
0x5e : called_num_ie
0x06 : called_num_len
0xa1 0x31 0x29 0x07 0x00 0x40: called_num_val
SETUP message. Thus, we know the common format of this message, and by
analogy, we can know the specific meaning of the SETUP messages with
different information fields and contents.
6. CALL PROCEEDING message:
B3 A7 11 C3 C1 80 2C 00 06 3D 00 41 00 01 05 01 00 02 83 02
The resolution of the DTAP message is as follows
0x00: Spare
0x02: DTAP message length
0x83: PD_CC
0x02: CALL PROCEEDING
CALL PROCEEDING message. Thus, we know the common format of this
message, and by analogy, we can know the specific meaning of the CALL
79
Issue 3.3
PROCEEDING messages with different information fields and contents (Note: this
message does not have any parameter).
7. ASSIGNMENT REQUEST message:
B3 A8 20 C3 C1 80 2C 00 06 3D 00 41 00 01 14 00 12 01 0B 03 01 08 01 07 02
06 00 06 01 0C 01 00 64 19 01
0x00 : BSSMAP indicator
0x12: BSSMAP message length
0x01: Assignment request information
0x0b: Channel type IEI
0x03: Channel type length
0x01: indicator = 1 : voice type
0x08: indicator = 8 : TCH/Bm
0x01: transparent service ( gsm voice algorithm 1st version )
0x07: L3 header information IEI
0x02: L3 header length
0x06: PD = B_0110 ( Radio Resource Manager )
0x00: TI = 0
0x06: Priority level IEI
0x01: Priority level length
0x03: Priority level
0x01: Circuit ID IEI
0x00 0x64;Circuit ID
0x19: Downlink DTX flag IEI
0x01: Downlink DTX flag : use DTX
ASSIGNMENT REQUEST message. Thus, we know the common format of this
message, and by analogy, we can know the specific meaning of the
ASSIGNMENT REQUEST messages with different information fields and
contents.
8. ASSIGNMENT COMPLETE message:
80
Issue 3.3

A1 B0 1C C3 B2 40 30 C0 06 3C 00 41 00 01 15 00 13 02 15 01 05 08 00 64 F0
00 01 00 03 00 21 08 23 01 24 01
0x13: BSSMAP message length = 19
0x02: Assignment Ack. information
0x15: RR cause IEI
0x01: RR cause
0x05: Cell ID IEI
0x64 0xf0: MCC dig.
0x00: MNC dig.
0x01 0x00: LAC
0x03 0x00: CI
0x21 chosen channel IEI( phase 2 )
0x08: channel
0x23: chosen Encryption algorithm IEI( phase 2 )
0x01: No Encryption
0x24: circuit pool IEI( phase 2 )
0x01: circuit pool number
ASSIGNMENT COMPLETE message. Thus, we know the common format of this
message, and by analogy, we can know the specific meaning of the
ASSIGNMENT COMPLETE messages with different information fields and
contents.
We have spent so much effort and time in the detailed analysis of multiple
common connection-oriented messages. For other connection-oriented
messages, we will not describe here. For the BSSMAP message, please refer to
the specifications GSM08.08 and for the DTAP message, please refer to the
specifications GSM04.08.
81
Issue 3.3
5. Connectionless messages
1) RESET CIRCUIT:
FB 0B 3B C3 B2 40 30 E0 09 00 02 07 0B 04 43 B2 00 FE 04 04 43 C1 00 FE 09
00 07 34 01 00 03 04 01 20
In the following, let us look at the resolution of the MTP and SCCP messages:
correspondi
ng byte
?XXXXXXX BSN ?1111010 Backward sequence number 0xFB
?XXXXXXX FSN ?0001011 Forward sequence number 0x0B
??XXXXXX LI ??111011 Signal unit length indication 0x3B
code
XXXXXXXX DPC 10100010 Destination signaling point 0xB2
??XXXXXX ??000000 00B2 0x40
0x30
0xE0
XXXXXXXX 00110000 00C1
????XXXX ????0000
0E
XXXXXXXX Message type 00001001 UDT message 0x09
????XXXX Protocol type ????0000 Services of Class 0 0x00
1 byte Mandatory variable 00000011 Pointer of the called address 0x03
length pointer
1 byte Mandatory variable 00000111 Pointer of the calling 0x07
length pointer address
1 byte Start pointer of optional 00001011 Pointing at the BSSMAP 0x0B
part Message
1 byte Length indicator 04h Length of the called address 0x04
???????X Signaling point ???????1 Including the signaling point 0x43
Indicator code
??????X? Subsystem Indicator ??????1? Including subsystem ID
??XXXX?? Global title Indicator ??0000?? Not including the global title
?X?????? Routing Indicator ?1?????? DPC and SSN routing
X??????? 0??????? National standby
2 bytes Signaling point code 00B2h Source signaling point code 0xB200
1 byte Subsystem No. 0xfe Subsystem of the A interface 0xFE
82
Issue 3.3
correspondi
ng byte
1 byte Optional parameter 0x04 Name of the calling address 0x04
name
5 bytes Optional parameter 04 43 C1 00 The format is the same as 04 43 C1
Contents FEh that of the called address 00 FEh
1 byte Length of optional 0x09 Length of the SCCP 0x09
parameter subscriber data (after it is
the BSSMAP message)
0x34: Reset Circuit information
0x00 0x03: Circuit ID
0x04: Cause IEI
0x01: Cause length
0x20: Equipment error
RESET CIRCUIT message. Thus, we know the common format of this message,
and by analogy, we can know the specific meaning of the RESET CIRCUIT
2. BLOCK CIRCUIT:
FB 0B 3B C3 B2 40 30 E0 09 00 02 07 0B 04 43 B2 00 FE 04 04 43 C1 00 FE 09
00 07 40 01 00 03 04 01 07
The resolution of MTP and SCCP message header of this message is basically
the same as that of the RESET CIRCUIT message (note: the message transfer
direction is different). For details, please refer to the above analysis.
0x40: Block Circuit information
0x00 0x03: Circuit ID
0x04: Cause IEI
0x01: Cause length
83
Issue 3.3
0x07: O&M
BLOCK CIRCUIT message. Thus, we know the common format of this message,
and by analogy, we can know the specific meaning of the BLOCK CIRCUIT
3. UNBLOCK CIRCUIT:
FB 0B 3B C3 B2 40 30 E0 09 00 02 07 0B 04 43 B2 00 FE 04 04 43 C1 00 FE 09
00 07 42 01 00 03 04 01 07
0x42: UnBlock Circuit information
0x00 0x03 : Circuit ID
0x04;Cause IEI
0x01: Cause length
0x07: O&M
UNBLOCK CIRCUIT message. Thus, we know the common format of this
message, and by analogy, we can know the specific meaning of the UNBLOCK
CIRCUIT messages with different information fields and contents.
4. RESET message:
FB 0B 3B C3 B2 40 30 E0 09 00 02 07 0B 04 43 B2 00 FE 04 04 43 C1 00 FE 09
00 04 30 04 01 20
0x30: Reset information
84
Issue 3.3
0x04: Cause IEI

0x01: Cause length
0x20: Equipment error
RESET message. Thus, we know the common format of this message, and by
analogy, we can know the specific meaning of the RESET messages with
different information fields and contents.
5. Unequipped circuit:
FB 0B 3B C3 B2 40 30 E0 09 00 02 07 0B 04 43 B2 00 FE 04 04 43 C1 00 FE 09
00 08 48 01 00 01 1E 02 00 01
0x48: Unequipped circuit information
0x00 0x01 : Circuit ID
0x1e: Circuit ID list IEI
0x02: length
0x00: circuit scope , range is 3
0x01: ;circuit state
unequipped circuit message. Thus, we know the common format of this message,
and by analogy, we can know the specific meaning of the unequipped messages
with different information fields and contents.
In the following, we will set the location updating and call flow as example to
describe the message analysis of the A interface:
1. Location updating message of the A interface
>SCCP INT 3983 000 00B8 00B1 01(Message type: CR) 01 00 41(Source local
reference: Three bytes) 02(Protocol type: Class 2, basic connection-oriented
service)02(Pointer 1 of mandatory variable length part : Called address) 06(Start
pointer of optional part)04(Length of the called address, i.e., the last four bits
indicate the called address)43 B1 00 FE 04(Optional parameter name: Calling
85
Issue 3.3
address )04(Length of the calling address, i.e., the last four bits indicate the
calling address)43 B8 00 FE 0F(Optional parameter name: Subscriber data) 21
(Subscriber data length) 00 (BSSMAP ID) 1F (BSSMAP MSG lEN) 57 (CMP L3
IND) 05(CELL IEI) 08(CELL LEN) 00(CELL TYPE:CGI) 64 F0 20 25 01 00 01 17
(L3 INF) 12 (L3 INF LEN) 05 (PD:MM) 08 (MSG:LOC_REQ) 20 (LOC_TYPE:
0NORMAL) 64 F0 20 25 01 01 08 49 06 20 72 80 00 10 47 00
<SCCP INT 3984 00f 00B1 00B8 02(Message type: CC) 01 00 41(Destination
local reference: Three bytes) 00 00 41(Source local reference: Three bytes) 02
(Protocol type: Class 2, basic connection-oriented service)00(without optional
parameters)
<SCCP INT 4053 00f 00B1 00B8 06(Message type:DT1) 01

00 41(Destination local reference: Three bytes) 00(Segmentation/reassembly:
Without more data) 01(Pointer 1 of mandatory variable length part : Subscriber
data)16(Subscriber data length) 01(DTAP ID)00(SPARE)13(DTAP MSG LEN)
05(PD:MM) 12(MSG:AUTH_REQ) 00 11 11 11 11 11 11 11 11 11 11 11 11 11 11
11 11
>SCCP INT 4187 000 00B8 00B1 06(Message type:DT1)
00 00 41(Destination local reference: Three bytes) 00(Segmentation/reassembly:
data)09(Subscriber data length) 01(DTAP ID)00(SPARE)06(DTAP MSG LEN)
05(PD:MM) 14(MSG:AUTH_RSP) 02 02 02 02
data)0A(Subscriber data length) 00(BSSMAP ID)08(BSSAP MSG
LEN)53(MSG:CIPH_MOD_CMD) 07 02 06 00 0A 01 01
data)03(Subscriber data length) 00(BSSMAP ID)01(BSSAP MSG
LEN)55(MSG:CIPH_MOD_CMP)
data)11(Subscriber data length) 01(DTAP ID)00(SPARE) 0E(DTAP MSG LEN)
05(PD:MM) 02(MSG:LOC_ACP) 64 F0 20 25 01 17 05 F4 01 E9 00 00
data)05(Subscriber data length) 01(DTAP ID)00(SPARE) 02(DTAP MSG LEN)
05(PD:MM) 1B(MSG:TMSI_REAL_CMP)
86
Issue 3.3

data)0A(Subscriber data length) 00(BSSMAP ID)08(BSSAP MSG
LEN)20(MSG:CLEAR_CMD) 07 02 06 00 04 01 10
data)03(Subscriber data length) 00(BSSMAP ID)01(BSSAP MSG
LEN)21(MSG:CLEAR_CMP)
<SCCP INT 4619 00f 00B1 00B8 04(Message type: RLSD)

03 00 41(Destination local reference: Three bytes)02 00 41(Source local
reference: Three bytes) 00(Release cause: endpoint user originates the release)
00(without optional parameters)
>SCCP INT 4629 000 00B8 00B1 05(Message type: RLC)
reference: Three bytes)
2. SCCP message of the A interface when an MS calls an MS (in the same BSC)
>SCCP INT 4756 000 00B8 00B1 01(Message type: CR)

01 00 41(Source local reference: Three bytes) 02(Protocol type: Class 2, basic
connection-oriented service)02(Pointer 1 of mandatory variable length part :
Called address) 06(Start pointer of optional part)04(Length of the called address,
i.e., the last four bits indicate the called address)43 B1 00 FE 04(Optional
parameter name: Calling address )04 (Length of the calling address) 43 B8 00 FE
0F(Optional parameter name: Subscriber data)1F(Subscriber data length)
00(BSSMAP ID)1D(BSSMAP MSG lEN) 57(CMP L3 IND) 05(CELL IEI) 08(CELL
LEN) 00(CELL TYPE:CGI) 64 F0 20 25 01 00 01 17(L3 INFO) 10(L3 INF LEN)
05(PD:MM) 24(MSG:CM_SER_REQ) 21(CM_SER_TYPE:1MOC) 03 03 18 00 08
49 06 20 72 80 00 10 45 00 (Optional parameter end)
<SCCP INT 4757 00b 00B1 00B8 02(Message type: CC)
reference: Three bytes)02(Protocol type: Class 2, basic connection-oriented
service)00(without optional parameters)
<SCCP INT 4829 00b 00B1 00B8 06(Message type:DT1)
01 00 41(Destination local reference: Three bytes)00(Segmentation/reassembly:
data) 16(Subscriber data length) 01(DTAP ID)00(SPARE) 13(DTAP MSG LEN)
05(PD:MM) 12(MSG:AUTH_REQ) 00 11 11 11 11 11 11 11 11 11 11 11 11 11 11
11 11
87
Issue 3.3
>SCCP INT 4963 000 00B8 00B1 06(Message type: DT1)

05(PD:MM) 14(MSG:AUTH_RSP) 02 02 02 02
<SCCP INT 4964 00b 00B1 00B8 06(Message type: DT1)
data) 12(Subscriber data length) 00(BSSAP ID) 10(BSSAP MSG
LEN)53(MSG:CIPH_MOD_CMD) 07 02 06 00 0A 09 02 03 03 03 03 03 03 03 03
data) 10(Subscriber data length) 01(DTAP ID)00(SPARE) 0D(DTAP MSG LEN)
03(PD:CC) 05(MSG:SETUP) 04 01 A0 5E 06 A1 31 28 07 10 55
83(PD:CC) 02(MSG:CALL_PROCEEDING)
LEN)01(MSG:ASS_REQ) 0B 03 01 08 01 07 02 06 00 06 01 0C 01 00 0A 19 01
LEN)02(MSG:ASS_CMP) 15 00
<SCCP INT 5396 009 00B1 00B8 09(Message type: UDT)
00(Protocol type: Class 0 basic connectionless service without returned
message) 03(Pointer 1 of mandatory variable length part : Called address)
07(Pointer 2 of mandatory variable length part : Calling address ) 0B(Start pointer
of optional part) 04(Length of the called address, i.e., the last four bits indicate the
called address) 43 B8 C0 FE 04(Length of the called address, i.e., the last four
bits indicate the called address) 43 B1 00 FE 1B(Subscriber data
88
Issue 3.3
length)00(BSSMAP ID)19(BSSMAP MSG lEN) 52(MSG:PAGING) 08 08 49 06 20

72 80 00 10 55 09 04 01 BE 00 00 1A 06 04 64 F0 20 25 01
>SCCP INT 5850 001 00B8 00B1 01(Message type: CR)
03 00 41(Source local reference: Three bytes) 02(Protocol type: Class 2, basic
connection-oriented service)02(Pointer 1 of mandatory variable length part :
Called address) 06(Start pointer of optional part) 04(Length of the called
address, i.e., the last four bits indicate the called address) 43 B1 00 FE 04(Length
of the calling address, i.e., the last four bits indicate the called address) 04 43 B8
00 FE 0F(Optional parameter name: Subscriber data)1F(Subscriber data
length)00(BSSMAP ID)1D(BSSMAP MSG lEN) 57(CMP L3 IND) 05(CELL IEI)
08(CELL LEN) 00(CELL TYPE:CGI) 64 F0 20 25 01 00 01 17(L3 INFO) 10(L3
INF LEN) 06(PD:RR) 27(MSG:PAGING_RSP) 02 03 02 00 00 08 49 06 20 72 80
00 10 55 00
<SCCP INT 5851 00c 00B1 00B8 02(Message type: CC )

reference: Three bytes) 02(Protocol type: Class 2, basic connection-oriented
service) 00(without optional parameters)
<SCCP INT 5869 00c 00B1 00B8 06(Message type:DT1)
05(PD:MM) 12(MSG:AUTH_REQ) 00 11 11 11 11 11 11 11 11 11 11 11 11 11 11
11 11
05(PD:MM) 14(MSG:AUTH_RSP) 02 02 02 02
LEN)53(MSG:CIPH_MOD_CMD) 07 02 06 00 0A 09 02 03 03 03 03 03 03 03 03
89
Issue 3.3

03(PD:CC) 05(MSG:SETUP) 04 01 A0
83(PD:CC) 08(MSG:CALL_CNF)
LEN)01(MSG:ASS_REQ) 0B 03 01 08 01 07 02 06 00 06 01 0C 01 00 0B 19 01

LEN)02(MSG:ASS_CMP) 15 00
83(PD:CC) 01(MSG:ALERT)
83(PD:CC) 01(MSG:ALERT)
83(PD:CC) 07(MSG:CONNECT)
83(PD:CC) 07(MSG:CONNECT)
90
Issue 3.3

03(PD:CC) 0F(MSG:CONNECT_ACK)
<SCCP INT 7055 00c 00B1 00B8 06(Message type: DT1)
03(PD:CC) 0F(MSG:CONNECT_ACK)
03(PD:CC) 25(MSG:DISCONNECT) 03 60 81 90

83(PD:CC) 2D(MSG:RELEASE) 08 02 E0 90
03(PD:CC) 25(MSG:DISCONNECT) 02 E0 90
03(PD:CC) 2A(MSG:RELEASE_CMP)
data) 0A(Subscriber data length) 00(BSSAP ID) 08(BSSAP MSG
LEN)20(MSG:CLR_CMD) 07 02 06 00 04 01 10
LEN)21(MSG:CLR_CMP)
<SCCP INT 7999 00b 00B1 00B8 04(Message type: RLSD)
91
Issue 3.3

83(PD:CC) 2D(MSG:RELEASE)
03(PD:CC) 2A(MSG:RELEASE_CMP) 08 02 E0 90
data) 0A(Subscriber data length) 00(BSSAP ID) 08(BSSAP MSG
LEN)20(MSG:CLR_CMD) 07 02 06 00 04 01 10
LEN)21(MSG:CLR_CMP)
<SCCP INT 8119 00c 00B1 00B8 04(Message type: RLSD)
5.6 Summary
This chapter mainly describes the protocols, procedures and message analysis
method of the A interface. Through the learning of this chapter, we can master the
message analysis method and considerations of the A interface.
5.7 Exercise
Please analyze the following two messages traced on the A interface:
18 8C 1D C3 C1 80 2C 50 06 07 00 41 00 01 11 01 00 02 83 01
92
Issue 3.3
2 B8 AD 16 C3 C1 80 2C F0 06 3B 00 41 00 01 0A 00 08 20 07 02 06 00 04 01
20
93
Issue 3.3
6.1 Overview
ISUP (ISDN User Part) is the integrated services digital network user part in No.7
signaling system. In the system, ISUP performs level-4 functions and is one of
the several parallel user parts. In the OSI (Open System Interconnection) model,
ISUP is equivalent to the functions at layers 4-7. On the basis of TUP, ISUP is
composed of the control protocols added with non-voice bearer services and
those of supplementary services. Therefore, ISUP fully supports the basic bearer
services and supplimentary services of ISDN users and can implement the
complete functions of TUP (Telephone User Part) and DUP (Data User Part).
Compared with TUP, ISUP has multiple outstanding fearures:
106. Flexible message structure similar to SCCP. There is a
smaller quantity of messages than TUP, but a message carries
much more information and can meet future needs.
107. Many enhanced functions are stipulated, especially the end-
to-end signaling, which enables the messages to be transparently
transmitted between ISDN users.
108. Brief and clear signaling procedures.
109. Powerful functions, capable of supporting various voice, non-
voice and supplementary services
6.2 Message Structure and Coding in ISUP

ISUP messages are transmitted over signaling links on the MTP layer and are the
same in format as the telephone MSU (Message Signal Unit) of TUP. Besides,
ISUP is the SIF (Signal Information Field) in a processing message.
Nevertheless, the SIF processed in ISUP is an octet stack and is composed of
the route flag, circuit identification code, message type code, mandatory fixed
part, mandatory variable part and optional part. The general format and sending
sequence of an ISUP message are shown in Figure 6-1:
110.
Figure1.1 General format andsending sequence of an ISUPmessage
When a message is sent, first the route flag and finally optional parts will be sent.
When a byte is sent, the least significant bit will be first sent.
Each kind of messages of ISUP are composed of some parameters, each of
which has a name and is encoded by the byte. A parameter may have a fixed or
94
Issue 3.3
variable length. Each variable parameter contains a length indicator identifying

the nubmer of bytes in the parameter content and the length indicator itself
occupies a byte. The contents of various constituents are described as follows
1) Route flag
The route flag in an ISUP message in China has the following format:
SLS OPC DPC
4 4 24 24
First transmitted bits
Figure1.2 Format of the route flag of an ISUP message
In the above figure, DPC (Destination Point Code) indicates the signaling point
code of the destination to where a message will be sent while OPC (Originating
Point Code) indicates the code of the signaling point from where a message is
sent. SLS (Signaling Link Selection) is used for the encoding of the signaling links
under load sharing. It is 8 bits long, but currently only 4 bits are in use, namely,
still the lower 4 bits of a CIC.
2. CIC (Circuit Identification Code)
8 7 6 5 4 3 2 1
CIC (the least significant bit) 1

Spare CIC (the most significant bit) 2
Figure1.3 Format of the CIC of an ISUP message
CIC is the code of the cirucuit between the originating signaling point and the
destination signaling point. Currently the lower 12 bits are in use and the
remaining 4 bits are spare (being 0000).
3. Message type code
The message code specifies the uniform function and format of each kind of
ISUP messages and is mandatory in all messages.
Table3.1 ISUP message type code

Message type Abbreviation Code
Address Complete ACM B00000110
Answer ANM B00001001
Block BLO B00010011
Block Acknowledge BLA B00010101
Call Progress CPG B00101100
Circuit Group Blocking CGB B00011000
Crcuit Group Blocking CGBA B00011010
Acknowledge
95
Issue 3.3

Circuit Group Query CQM B00101010
Circuit Group Query CQA B00101011
Acknowledge
Circuit Group Reset GRS B00010111
Circuit Group Reset GRA B00101001
Acknowledge
Circuit Group Unblocking CGU B00011001
Circuit Group Unblocking CGUA B00011011
Acknowledge
Charging Information CRG* B00110001
Confusion CFN B00101111
Connect CON B00000111
Continuity COT B00000101
Continuity Check Request CCR B00010001
Performance FAC B00110011
Performance Accept FAA B00100000
Performance Reject FRJ B00100001
Performance Request FAR B00011111
Forward Transfer FOT B00001000
Identification Request IDR B00110110
Identification Response IRS B00110111
Information INF B00000100
Information Request INR B00000011
Initial Address IAM B00000001
Loopback Acknowledge LPA B00100100
Network Resources Management NRM B00110010
Overload OLM B00110000
Pass PAM B00101000
Release REL B00001100
Release Complete RLC B00010000
Reset Circuit RSC B00010010
Restore RES B00001110
Segment SGM B00111000
Subsequent Address SAM B00000010
Suspend SUS B00001101
Unblocking UBL B00010100
Unblocking Acknowledge UBA B00010110
Unallocated CIC UCIC B00101110
User Part Available UPA B00110101
User Part Test UPT B00110100
User-User Signaling USR B00101101
Operator Signal OPR B11111110
Metering Pulse Information MPM B11111101
Calling Party Clear Signal CCL B11111100
Note: those marked with * are not used for the moment and the code Bxxxxxxxx
represents a binary number Xxxxxxxx
96
Issue 3.3
4. Mandatory fixed part (F)

It means the parameter which is mandatory in a message and is fixed in length.
The location, length and order of a parameter are specified by the message type
on a unifed basis, therefore a message does not contain the parameter name and
length indicator
5. Mandatory variable part (V)
It means the parameter which is mandatory in a message and is variable in
length. The start of a parameter is represented with a pointer while the parameter
name and the pointers sending sequence are hidden in a message type. The
quantity of parameters and pointers is speicfied by the message type on a unified
basis.
6. Optional part (O)
Composed of some parameters, it may be fixed or variable in length. Each
optional parameter should contain the parameter name, length indicator and
parameter content. An optional parameter ends with an all-zeros octet.
6.3 ISUP Message Examples

Following describes the two commonly-used ISUP message signaling information
codes, namely, the IAM (Initial Address Message) and ACM (Address Complete
Message).
6.3.1 IAM
IAM (Initial Address Message) is the message sent in the forward direction to
begin occupying outgoing circuits and send numbers and the inforation related to
routing and call processing. First, the message structure of an IAM shall be
discussed. and then the codes of main parts in the structure.
1. IAM message structure
Its first octet is the message type code and next is the mandatory fixed part. Its
type is indicated by F. Then, following the F type is the mandatory variable part,
whose type can be indicated by V. Following the mandatory variable part is the
optional part, whose type can be indicated by O.
The message structure of IAM is shown iin Table 6-2.
Table1.1 IAM message structure

Parameter Type Length (octet)
Message type F 1
Connection nature indicator F 1
Forward call indicator F 2
Caller category F 1
97
Issue 3.3

Transmission medium request F 1
Called number V 4-11
Transit network selection O 4-?
Call reference O 8
Calling number O 4-12
Optional forward call indicator O 3
Redirecting number O 4-12
Redirecting information O 304
CUG interlock code O 6
Connection request O 7-9
Original called number O 4-12
User-User signaling O 3-131
Access transfer O 3-?
User service information O 4-13
User to user indicator O 3
Universal number (note 2) O 5-13
Propagation delay counter O 4
User service information O 4-13
Network private performance O 4-?
Universal digit O ?
Originating ISC point code O 4
User terminal service information O 7
Remote operations O ?
Parameter compatibility information O 4-?
Universal notice (note 1) O 3
Service activation O 3-?
Universal reference (note 2) O 5-?
MLPP preference O 8
Transmission medium reqest O 3
Location number O 5-12
End of optional parameter O 1
Note 1: this parameter can be repeated.
Note 2: for further study.
2. IAM message code
The code of each part in the message structure can be found in the
specifications. Following will list the codes of several main parts to see what each
code means.
According to the bit sending sequence (from right to left), the meanings of the
connection nature indicator code are as follows.
1 Connection nature indicator
Bit BA: satellite indicator
00: no satellite circuit in the connection
98
Issue 3.3
01: one segment of satellite circuit in the connection

10 two segments of satellite circuit in the connection
11: spare
Bit DC: continuity check indicator
00: continuity check not required
01: continuity check required in this circuit
10: continuity check in progress in the previous circuit
11: spare
Bit E: Echo control device indicator
0: outgoing semi-echo control device not included
1: outgoing semi-echo control device included
Bits F~H: standby
2 Forward call indicator
Bit A: national/international call indicator
0: calls processed according to national calls
1: calls processed according to international calls
In an originating country, this bit can be set as any value. In an international
network, this bit will not be checked. In a destination country, this bit in a call from
an international network should be set as 1.
Bit CB: end-to-end mode indicator (note)
00: no end-to-end mode available (the mode of hop-by-hop forwarding available)
01: Transfer mode available
10: SCCP mode available
11: Transfer mode and SCCP mode available
Bit D: Interworking indicator (note)
0: no interworking encountered (NO.7 signals in all directions)
1: Interworking encountered
Bit E: End-to-end information indicator (note)
0: No end-to-end information available
1: end-to-end information available
Bit F: ISDN user part indicator (note)
0: ISDN user part not used in all directions
1: ISDN user part used in all directions
99
Issue 3.3
Bit HG: ISDN user part preferred indicator

00: ISDN user part preferred in all directions
01: ISDN user part not needed in all directions
10: ISDN user part needed in all directions
11: spare
Bit I: ISDN access indicator
0: originating access to non--ISDN
1: originating access to ISDN
Bit KJ: SCCP mode indicator
00: no indication
01:connectionless mode available
10:connection-oriented mode available
11: connectionless and connection-oriented modes available
Bit L: spare
Bit P--M: reserved for national use
(Note: bits B~F and J~K constitute a protocol control indicator).
Caller category
Caller category: mandatory fixed, slightly different from the ISUP in a fixed
network, with the length of an octet (H-A). Its codes are as follows:
Bit HGFEDCBA
00000000 caller category unknown (receive only)
00000001
to spare
00001000
00001001 operator (no intrusion function)
00001010 common user, used between a mobile exchange and a local
exchange/tandem exchange
00001011 preferred user, used between mobile exchanges
00001100 data call
00001101 test call
00001110
to spare
11101111
100
Issue 3.3
11110000 common, no charge, used between a mobile exchange and a toll

exchange (including the international exchange)
11110001 common, periodic, used between a mobile exchange and a toll
11110010 common, user table, immediate (receive only from a local
exchange/tandem exchange)
11110011 common, printer, immediate (receive only from a local
exchange/tandem exchange)
11110100 preferred, no charge, used between a mobile exchange and a toll
11110101 preferred, periodic, used between mobile exchange and a toll
11110110
to spare
11111111
4 Transmission medium request
00000000 voice
00000001 spare
00000010 64kb/s unrestricted
00000011 3.1KHZ audio
00000100 voice (service 2)/64kb/s unrestricted (service 1) alternative (reserved)
00000101 64kb/s unrestricted (service 1)/voice (service 2) alternative (reserved)
00000110 64kb/s preferred
00001001 spare
00001011 spare
to
11111111 spare
Called number
The parameter field of the called number is in the format as shown in Figure 6-3.
101
Issue 3.3
8 7 6 5 4 3 2 1
Odd/even
indicator Address nature indicator
INN
indicator Numbering plan spare
The second address signal The first address signal
q
qq q
qq
Fill code The Nth address signal
Table1.1 Format of the parameter of the called number
a) Odd/even indicator
0 even address signal
1 odd address signal
b} Address nature indicator
0000000 spare
0000001 = subscriber number
0000010 spare, reserved for international uses
0000011 national (valid) number
0000100 = international number
0000101 spare
to
1101111 spare
1110000 reserved for national use
to
1111111 spare
c) INN (Internal Network Number) indicator
0 routing to an internal network number enabled
1 routing to an internal network number disabled
d) Numbering plan indicator
000 spare
001 ISDN (telephone) numbering plan
010 spare
011 data numbering plan
102
Issue 3.3
100 user telegraphy numbering plan

111 spare
e) Address signal
0000 digit 0
0001 digit 1
0010 digit 2
0011 digit 3
0100 digit 4
0101 digit 5
0110 digit 6
0111 digit 7
1000 digit 8
1001 digit 9
1010 spare
1011 code 11
1100 code 12
1101 spare
1110 spare
f) Fill code
If an address signal is an even nubmer, then a fill code (0000) will be inserted
after the last address signal.
6.3.2 ACM
ACM (Address Complete Message) is a message sent in the backward direction

indicating that all address signals needed during the routing of this call to the
called have been received. Likewise, following will first have a look at the
message structure of an ACM, and then the codes of main parts in the structure.
1. ACM message structure
The message structure of ACM is shown in Table 6-4.
Table1.1 ACM message structure
103
Issue 3.3

Message type F 1
Backward call indicator F 2
Optional backward call indicator O 3
Call reference O 8
Cause indicator O 4-?
User-user indicator O 3
User signaling O 3-131
Access transfer O 3-?
Universal notice indicator (note) O 3
Transmission medium used O 3
Echo control information O 3
Access transfer information O 3
Redirecting number O 5-12
Parameter compatibility information O 4-?
Call change information O 3
Network private performance O 4-?
Remote operations O 3-?
Service activation O 3-?
Redirecting number restriction O 3
End of optional parameter O 1
Note: this parameter can be repeated
2. ACM message code
The code of each part in the message structure can be found in the
specifications. Following will list the codes of several main parts to see what
each code means.
According to the bit sending sequence (from right to left), the meanings of the
connection nature indicator codes are as follows.
1 Backward call indicator
A backward call indicator has two octets, whose bits are encoded as A~P
according to the sending sequence.
Bit BA: charging indicator
00 no indication
01 no charging
10 charging
11 spare
Bit DC: called subscriber status indicator
00 No indication
01 unallocated number
104
Issue 3.3
10 space time connection

11 spare
Bit FE: called category indicator
00 no indication
Common subscriber
Payphone
11 spare
Bit HG: end-to-end mode indicator (note)
00 end-to-end mode unavailable (only the mode of hop-by-hop forwarding
available)
01 Transfer mode available
10 SCCP mode available
11 Transfer mode and SCCP mode available
Bit I: interworking indicator (note)
0 interworking not encountered
1 interworking encountered
Bit J: end-to-end information indicator (note)
0 no end-to-end information available
1 end-to-end information available
Bit K: ISDN user part indicator (note)
0 ISDN user part not used in all directions
1 ISDN user part used in all directions
Bit L: Hold indicator
0 hold not requested
1 hold requested
Bit M: ISDN access indicator
0 terminal accessed to non-ISDN
1 terminal accessed to ISDN
Bit N: echo control device indicator
0 incoming semi-echo control device not included
1 incoming semi-echo control device included
Bit PO: SCCP mode indicator
00 no indication
105
Issue 3.3
01 Connectionless mode available

10 connection-oriented mode available
11 connectionless and connection-oriented modes available
Note: bits G~K and O~P constitute a protocol control indicator.
2 Optional backward call indicator
Bit A: Inband information indicator
0 no indication
1 Inband information or proper code pattern currently available
Bit B: call change possible indicator
0 no indication
1 call change possible
Bit C: simple segmentation indicator
0 no additional information sent
1 additional information sent with the segmentation message
Bit D: MLPP user indicator
0 no indication
1 MLPP user
Bits E~H: reserved for national use
3 Call reference
Call reference includes the call identification and signaling point code.
a) Call identification
The binary code represents the identification number allocated to a call.
b) Signaling point code
Signaling point code related to the call identification.
4 User to user indicator
Bit A: Type
0 request
1 response
If bit A equals to 0 (request):
Bit CB: service 1
00 no information
01 spare
106
Issue 3.3
10 request, not mandatory

11 request, mandatory
Bit ED: service 2
00 no information
01 spare
Bit GE: service 3
00 no information
01 spare
Bit H: spare
If bit A equals 1 (response):
Bit CB: service 1
00 no information
01 not provided
10 user to user information provided
11 spare
Bit ED: service2
00 no information
01 not provided
10 provided
11 spare
Bit GF: service 3
00 no information
01 not provided
10 provided
11 spare
Bit H: spare
107
Issue 3.3
6.4 ISUP Basic Signaling Flow
6.4.1 Features of ISUP in an MSC (M900/1800)
Besides the above-mentioned difference in the caller category, there are some
other major differences:
1: MSC adopts the group code sending mode. That is, MSC does not send any
SAM, but sends the called data at one time. However, the receiving is in the
group and overlay modes.
2: First party release mode is adopted in a mobile system and also applied to
special number calls.
3: There must be the optional parameter Caller number in the IAM message of
ISUP transmitted between MSCs.
4: If a mobile user is the called, the called number in the IAM message sent by
GMSC/MSC is MSRN (roaming number).
5: Call Forwarding on mobile subscriber Not Reachable (CFNRc) is added into
the forwarding type.
6: Such mobile-related parameter values as mobile subscirber absent are
added to the cause indicator parameters.
6.4.2 Signaling Procedures of ISUP
1: Basic signaling procedure of successful call connection
MSC TmTandem exchange MSC

Caller Called subscriber
SETUP
IAM IAM
SETUP
ACM
ALERT ACM
ALERT
Ringback tone
ANM ANM CONNECT
CONNECT
Conversation
RELEASE The called
RELEASE REL REL hooks on
RLC RELEASE
RLC
COMPLETE
RELEASE
REL REL
The caller RELEASE RLC RELEASE
hooks on RLC
COMPLETE
Figure1.1 Basic signaling procedure of successful call connection
As shown in Figure 6-5, IAM message is the first message sent by the outgoing
MSC and carries complete information, such as the called number, caller
category, transmission medium request and caller number. When the called is
idle, an ACM message will be sent back and ringing starts. The called answers
and sends back an ANM message, and the converation begins. If the called
108
Issue 3.3
hooks on, REL should be sent directly to clear inter-office circuits and RLC
message will be used for acknowledge. If the caller hooks on, the processing is
the same except that the directions of messages are different (either party in
ISUP can initiate the action of releasing inter-office trunk circuits).
CLP_TAGGING_NO_SCR. Basic signaling procedure of unsuccessful call
connection
MSC Tm(Tandem exchange MSC

Caller
SETUP IAM IAM
REL REL
RELEASE
RLC RLC
Figure1.2 Basic signaling procedure of unsuccessful call connection
As shown in Figure 6-6, the outgoing MSC sends IAM messages and is ready to
establish a call. However, the incoming MSC finds that the subscriber cannot be
paged due to called subscriber busy or base station subsystem fault or that the
called subscriber is not reachable due to other reasons. Then, it sends an
RELmessage to notify about the connection failure. The cause value parameter
in the REL will inform the outgoing MSC of the cause for this unsuccessful
connection. The REL sent by the outgoing MSC to clear inter-office trunk circuits
will be confirmed by RLC.
3: Signaling coordination between ISUP and No.1
Tm(Tandem exchange PSTN

ISUP No.1
IAM Seize
A First digit of the number
A1
.
.
D Last digit of the number
A3
KD
ACM KB=1
Ringback tone
ANM Answer
Conversation
Onhook
SUS The called
REL Disconnect hooks on
RLC Release guard
Tandem
exchange Disconnect
REL
RLC Release guard
Figure1.3 Signaling coordination between ISUP and No.1
In a mobile network, No.7 signaling mode is used between MScs and the
signaling coordination between ISUP and No.1 will occur only in a mobile-to-fixed
call. As shown in Figure 6-7, the tandem exchange converts the information in an
109
Issue 3.3
IAM message into a series of No.1 signals. If the called is idle (KB=1), an ACM
message will be sent back and ringing starts. The called answers and sends back
an ANM message. Then, the converation begins. When the called fixed
subscribers hooks on, he cannot release inter-office circuits, and must send an
SUS (suspend) message to the outgoing MSC to request for disconnection.
Meanwhile, the outgoing MSC shall send an REL message to start clearing the
inter-office trunk circuits. If a call fails, the tandem exchange will, based on
different KB values sent back by PSTN, add the corresponding cause value to the
REL message sent back by the outgoing MSC.
4: Signaling coordination between ISUP and TUP
Tm(Tandem
MSC exchange) MSC
ISUP TUP
IAM IAI
ACM ACM
Ringback tone
ANM ANC/ANN
Conversation
CBK The called
hooks on
REL CLF
RLC
RLG
REL CLF
The caller
RLC
hooks on RLG
Figure1.4 Signaling coordination between ISUP and TUP
Because both ISUP and TUP belong to the SS7 system, their messages and
signaling coordination are very similar. The difference between them is that the
disconnection of inter-office trunk circuits in TUP is initiated by the outgoing MSC
while either party in ISUP can initiate the disonnection. In addition, if a call is
unsuccessful, the same REL message in ISUP is used to carry different cause
value parameters while different messages should be used in TUP to end
different calls.
6.4.3 Implementation of ISUP in the M900/1800 System
The M900/1800 MSC system software adopts modular design and the
communciation between various software modules is achieved by means of
messages. ISUP-related modules in this system are as follows: call-related CC
(Call Control) module, MT (Maintenance Test) module related to circuit
management and MTP (Message Transfer Part). Their relationships are shown in
Figure 6-8:
110
Issue 3.3
CC MT
Call Circuit
control management
primitive primitive
Call process control Circuit management

control
{CPC} {CSC}
MTP
Primitive
MTP
Figure1.1 Relationships between ISUP and CC/MT/MTP
The message between CC and ISUP is called the call control primitive, which is
adapted from the protocol Q.931. The message between MT and ISUP is called
the circuit management primitive, including the blocking, unblocking, reset, query
and continuity check of a circuit/circuit group, and is adapted from the protocol
Q.764. The message between MTP and ISUP adopts the MTP primitive as
stipulated in the protocol Q.701.
ISUP in M900/1800 is divided into two function modules: CPC and CSC. CC
analyzes the called roaming number of the subscriber or the incoming trunk, and
selects the outgoing trunk circuit. Then, it encapsulates related information into a
call control primitive and sends it to the CPC of ISUP. ISUP converts it into an
inter-office message to send to MTP, which transmits it to the peer exchange.
MTP receives the inter-office message and sends it to ISUP. Then, CPC converts
it into a call control primitive and sends it upward to CC for corresponding
processing.
Circuit management process and call control process are almost the same except
that CSC is the module for processing circuit management messages in ISUP.
Besides, the circuit management message about the peer end received from
MTP is processed by CSC alone, which only reports the corresponding
information to MT.
6.5 Summary
This section describes the ISUP, one of the user parts of level 4 functions in the
No.7 signaling mode. ISUP specifies the contents of signaling messages
transmitted between telephone switching exchanges and provides the functions
of call control and circuit management. The foucus is on the format of an ISUP
message and the signaling procedures of a call (including the coordination with
other signaling modes). In addition, the difference between the ISUP in
M900/1800 systems and a fixed network, along with their modes of
implementation, are briefly described.
111
Issue 3.3
6.6 Exercises
1: Draw up the format of an ISUP message and the composition of an IAM
message.
2: Draw up the ISUP signaling procedure of a successful call.
6.7 Key to the Exercises

2-1 The basic features of a common channel signaling system are as follows:
signaling channel and traffic channel are fully separated, and the signaling
information of all trunk lines and all communication services are transmitted over
common data links in the form of messages.
2-2 Signaling point, signaling transfer point and signaling link
2-3 Direct connection mode and quasi-direct connection mode
3-1 message transfer user MTP SCCP ISUP TUP TCAP MAP
3-2 MSU (Message Signal Unit) LSSU (Link Status Signal Unit) FISU (Fill-in
Signal Unit)
MSU SIF SIO unit length
4-1 signaling data link bidirectional 64kbps analog
4-2 signal unit delineation signal unit localization error detection and correction
initial localization signaling link error monitoring
Flow control Processor error control
4-3 signaling message processing function signaling network management
function message routing message discrimination message allocation signaling
service management signaling link management signaling route management
5-1 connection-oriented and connectionless services Class 0 basic
connectionless services
class 1 ordered connectionless services
Class 2 basic connection-oriented services class 3 connection-oriented services
of flow control
5-2 SPC (Signaling Point Code) SSN (SubSystem Number) GT (Global Title)
5-3 05H 06H 08H 07H
6-1 transaction sublayer component sublayer
6-2 tag length value
7-1 location registration/erasure reset after location register fault user
management authentication & encrytion route management function of IMEI
112
Issue 3.3
access processing and paging processing of supplementary services handover

short message services operation and maintenance
8-1 IAM
8-2 group sending mode not sen
113
OMA000004 NSS Signalling and interface analysis Appendix ASN.1 Coding of MAP
Issue 3.3 Messages
Appendix ASN.1 Coding of MAP Messages

updateLocation OPERATION
ARGUMENT
updateLocationArg SEQUENCE {
imsi OCTET STRING (SIZE (3..8)),
locationInfo CHOICE {
roamingNumber [0] IMPLICIT OCTET STRING (SIZE (1..9)),
msc-Number [1] IMPLICIT OCTET STRING (SIZE (1..9))},
vlr-Number OCTET STRING (SIZE (1..9)),
lmsi [10] IMPLICIT OCTET STRING (SIZE (4)) OPTIONAL,
... }
RESULT
updateLocationRes CHOICE {
hlr-Number OCTET STRING (SIZE (1..9)),
extensibleUpdateLocationRes SEQUENCE {
... }}
ERRORS {
-- systemFailure -- localValue 34,
-- dataMissing -- localValue 35,
-- unexpectedDataValue -- localValue 36,
-- unknownSubscriber -- localValue 1,
-- roamingNotAllowed -- localValue 8}
::= localValue 2
cancelLocation OPERATION
ARGUMENT
cancelLocationArg CHOICE {
imsi-WithLMSI SEQUENCE {
114
Issue 3.3 Messages

lmsi OCTET STRING (SIZE (4)),
...}}
ERRORS {
-- unidentifiedSubscriber -- localValue 5}
::= localValue 3
purgeMS OPERATION
ARGUMENT
purgeMS-Arg SEQUENCE {
vlr-Number OCTET STRING (SIZE (1..9)),
...}
::= localValue 67
sendIdentification OPERATION
ARGUMENT
tmsi OCTET STRING (SIZE (1..4))
RESULT
sendIdentificationRes SEQUENCE {
authenticationSetList SEQUENCE SIZE (1..5) OF
SEQUENCE {
rand OCTET STRING (SIZE (16)),
sres OCTET STRING (SIZE (4)),
kc OCTET STRING (SIZE (8)),
... } OPTIONAL,
...}
ERRORS {
115
Issue 3.3 Messages
::= localValue 55
performHandover OPERATION
ARGUMENT
performHO-Arg SEQUENCE {
targetCellId OCTET STRING (SIZE (5..7)),
servingCellId OCTET STRING (SIZE (5..7)),
channelType OCTET STRING (SIZE (1..10)),
classmarkInfo OCTET STRING (SIZE (1..2)),
handoverPriority [11] IMPLICIT OCTET STRING (SIZE (1)) OPTIONAL,
kc [12] IMPLICIT OCTET STRING (SIZE (8)) OPTIONAL}
RESULT
performHO-Res SEQUENCE {
handoverNumber OCTET STRING (SIZE (1..9)),
accessSignalInfo SEQUENCE {
protocolId ENUMERATED {
gsm-0408 (1),
gsm-0806 (2),
gsm-BSSMAP (3),
ets-300102-1 (4)},
signalInfo OCTET STRING (SIZE (1..200)),
...}}
ERRORS {
-- unknownBaseStation -- localValue 2,
-- invalidTargetBaseStation -- localValue 23,
-- noRadioResourceAvailable -- localValue 24,
-- noHandoverNumberAvailable -- localValue 25}
::= localValue 28
116
Issue 3.3 Messages
prepareHandover OPERATION
ARGUMENT
prepareHO-Arg SEQUENCE {
targetCellId OCTET STRING (SIZE (5..7)) OPTIONAL,
ho-NumberNotRequired NULL OPTIONAL,
bss-APDU SEQUENCE {
protocolId ENUMERATED
gsm-0408 (1),
gsm-0806 (2),
gsm-BSSMAP (3),
ets-300102-1 (4)},
... } OPTIONAL,
...}
RESULT
prepareHO-Res SEQUENCE {
handoverNumber OCTET STRING (SIZE (1..9)) OPTIONAL,
bss-APDU SEQUENCE {
gsm-0408 (1),
gsm-0806 (2),
gsm-BSSMAP (3),
ets-300102-1 (4)},
... } OPTIONAL,
...}
ERRORS {
-- noHandoverNumberAvailable -- localValue 25}
117
Issue 3.3 Messages
::= localValue 68
sendEndSignal OPERATION
ARGUMENT
bss-APDU SEQUENCE {
gsm-0408 (1),
gsm-0806 (2),
gsm-BSSMAP (3),
ets-300102-1 (4)},
...}
::= localValue 29
processAccessSignalling OPERATION
ARGUMENT
bss-APDU SEQUENCE {
gsm-0408 (1),
gsm-0806 (2),
gsm-BSSMAP (3),
ets-300102-1 (4)},
...}
1 ::= localValue 33
forwardAccessSignalling OPERATION
ARGUMENT
bss-APDU SEQUENCE {
gsm-0408 (1),
gsm-0806 (2),
118
Issue 3.3 Messages
gsm-BSSMAP (3),
ets-300102-1 (4)},
...}
::= localValue 34
performSubsequentHandover OPERATION
ARGUMENT
performSubsequentHO-Arg SEQUENCE {
servingCellId OCTET STRING (SIZE (5..7)),
targetMSC-Number OCTET STRING (SIZE (1..9)),
classmarkInfo [10] IMPLICIT OCTET STRING (SIZE (1..2)) OPTIONAL}
RESULT
accessSignalInfo SEQUENCE {
gsm-0408 (1),
gsm-0806 (2),
gsm-BSSMAP (3),
ets-300102-1 (4)},
...}
ERRORS {
-- unknownBaseStation -- localValue 2,
-- unknownMSC -- localValue 3,
-- invalidTargetBaseStation -- localValue 23,
-- subsequentHandoverFailure -- localValue 26}
::= localValue 30
prepareSubsequentHandover OPERATION
ARGUMENT
119
Issue 3.3 Messages
prepareSubsequentHO-Arg SEQUENCE {
targetMSC-Number OCTET STRING (SIZE (1..9)),
bss-APDU SEQUENCE {
gsm-0408 (1),
gsm-0806 (2),
gsm-BSSMAP (3),
ets-300102-1 (4)},
...},
...}
RESULT
bss-APDU SEQUENCE {
gsm-0408 (1),
gsm-0806 (2),
gsm-BSSMAP (3),
ets-300102-1 (4)},
...}
ERRORS {
-- unknownMSC -- localValue 3,
-- subsequentHandoverFailure -- localValue 26}
::= localValue 69
sendAuthenticationInfo OPERATION
ARGUMENT
sendAuthenticationInfoArg OCTET STRING (SIZE (3..8))
RESULT
120
Issue 3.3 Messages
sendAuthenticationInfoRes SEQUENCE SIZE (1..5) OF

SEQUENCE {
...}
ERRORS {
-- unknownSubscriber -- localValue 1}
::= localValue 56
checkIMEI OPERATION
ARGUMENT
imei OCTET STRING (SIZE (8))
RESULT
equipmentStatus ENUMERATED {
whiteListed (0),
blackListed (1),
greyListed (2)}
ERRORS {
-- unknownEquipment -- localValue 7}
::= localValue 43
sendParameters OPERATION
ARGUMENT
sendParametersArg SEQUENCE {
subscriberId CHOICE {
121
Issue 3.3 Messages
imsi [0] IMPLICIT OCTET STRING (SIZE (3..8)),

tmsi [1] IMPLICIT OCTET STRING (SIZE (1..4))},
requestParameterList SEQUENCE SIZE (1..2) OF
ENUMERATED {
requestIMSI (0),
requestAuthenticationSet (1),
requestSubscriberData (2),
requestKi (4)}}
RESULT
sentParameterList SEQUENCE SIZE (1..6) OF
CHOICE {
authenticationSet [1] IMPLICIT SEQUENCE {
...},
subscriberData [2] IMPLICIT SEQUENCE {
msisdn [1] IMPLICIT OCTET STRING (SIZE (1..9)) OPTIONAL,
category [2] IMPLICIT OCTET STRING (SIZE (1)) OPTIONAL,
subscriberStatus [3] IMPLICIT ENUMERATED {
serviceGranted (0),
operatorDeterminedBarring (1)} OPTIONAL,
bearerServiceList [4] IMPLICIT SEQUENCE SIZE (1..50) OF
OCTET STRING (SIZE (1)) OPTIONAL,
teleserviceList [6] IMPLICIT SEQUENCE SIZE (1..20) OF
provisionedSS [7] IMPLICIT SEQUENCE SIZE (1..30) OF
CHOICE {
forwardingInfo [0] IMPLICIT SEQUENCE {
ss-Code OCTET STRING (SIZE (1)) OPTIONAL,
forwardingFeatureList SEQUENCE SIZE (1..13) OF
122
Issue 3.3 Messages
SEQUENCE {
basicService CHOICE {
bearerService [2] IMPLICIT OCTET STRING (SIZE (1)),
teleservice [3] IMPLICIT OCTET STRING (SIZE (1))}
OPTIONAL,
ss-Status [4] IMPLICIT OCTET STRING (SIZE (1))
OPTIONAL,
forwardedToNumber [5] IMPLICIT OCTET STRING (SIZE
(1..9)) OPTIONAL,
forwardedToSubaddress [8] IMPLICIT OCTET STRING (SIZE
(1..21)) OPTIONAL,
forwardingOptions [6] IMPLICIT OCTET STRING (SIZE (1))
OPTIONAL,
noReplyConditionTime [7] IMPLICIT INTEGER (5..30)
OPTIONAL,
...},
...},
callBarringInfo [1] IMPLICIT SEQUENCE {
callBarringFeatureList SEQUENCE SIZE (1..13) OF
SEQUENCE {
OPTIONAL,
ss-Status [4] IMPLICIT OCTET STRING (SIZE (1))
OPTIONAL,
...},
...},
cug-Info [2] IMPLICIT SEQUENCE {
cug-SubscriptionList SEQUENCE SIZE (1..10) OF
SEQUENCE {
cug-Index INTEGER (0..32767),
cug-Interlock OCTET STRING (SIZE (4)),
intraCUG-Options ENUMERATED {
123
Issue 3.3 Messages
noCUG-Restrictions (0),
cugIC-CallBarred (1),
cugOG-CallBarred (2)},
basicServiceGroupList SEQUENCE SIZE (1..13) OF
CHOICE {
OPTIONAL,
...},
cug-FeatureList SEQUENCE SIZE (1..13) OF
SEQUENCE {
OPTIONAL,
preferentialCUG-Indicator INTEGER (0..32767) OPTIONAL,
interCUG-Restrictions OCTET STRING (SIZE (1)),
... } OPTIONAL,
...},
ss-Data [3] IMPLICIT SEQUENCE {
ss-Status [4] IMPLICIT OCTET STRING (SIZE (1)) OPTIONAL,
ss-SubscriptionOption CHOICE {
cliRestrictionOption [2] IMPLICIT ENUMERATED {
permanent (0),
temporaryDefaultRestricted (1),
temporaryDefaultAllowed (2)},
overrideCategory [1] IMPLICIT ENUMERATED {
overrideEnabled (0),
overrideDisabled (1)}} OPTIONAL,
CHOICE {
124
Issue 3.3 Messages

OPTIONAL,
... }} OPTIONAL,
odb-Data [8] IMPLICIT SEQUENCE {
odb-GeneralData BIT STRING {
allOG-CallsBarred (0),
internationalOGCallsBarred (1),
internationalOGCallsNotToHPLMN-CountryBarred (2),
premiumRateInformationOGCallsBarred (3),
premiumRateEntertainementOGCallsBarred (4),
ss-AccessBarred (5)} (SIZE (6)),
odb-HPLMN-Data BIT STRING {
plmn-SpecificBarringType1 (0),
plmn-SpecificBarringType4 (3)} (SIZE (4)) OPTIONAL,
... } OPTIONAL,
roamingRestrictionDueToUnsupportedFeature [9] IMPLICIT NULL
OPTIONAL,
regionalSubscriptionData [10] IMPLICIT SEQUENCE SIZE (1..10) OF
OCTET STRING (SIZE (2)) OPTIONAL},
ki [4] IMPLICIT OCTET STRING (SIZE (16))}
ERRORS {
::= localValue 9
insertSubscriberData OPERATION
ARGUMENT
insertSubscriberDataArg SEQUENCE {
imsi [0] IMPLICIT OCTET STRING (SIZE (3..8)) OPTIONAL,
125
Issue 3.3 Messages
category [2] IMPLICIT OCTET STRING (SIZE (1)) OPTIONAL,

subscriberStatus [3] IMPLICIT ENUMERATED {
serviceGranted (0),
operatorDeterminedBarring (1)} OPTIONAL,
provisionedSS [7] IMPLICIT SEQUENCE SIZE (1..30) OF
CHOICE {
SEQUENCE {
OPTIONAL,
forwardedToNumber [5] IMPLICIT OCTET STRING (SIZE (1..9))
OPTIONAL,
forwardedToSubaddress [8] IMPLICIT OCTET STRING (SIZE
(1..21)) OPTIONAL,
OPTIONAL,
noReplyConditionTime [7] IMPLICIT INTEGER (5..30) OPTIONAL,
...},
...},
SEQUENCE {
126
Issue 3.3 Messages

OPTIONAL,
...},
...},
SEQUENCE {
CHOICE {
OPTIONAL,
...},
SEQUENCE {
OPTIONAL,
interCUG-Restrictions OCTET STRING (SIZE (1)),
... } OPTIONAL,
...},
127
Issue 3.3 Messages

permanent (0),
CHOICE {
teleservice [3] IMPLICIT OCTET STRING (SIZE (1))} OPTIONAL,
... }} OPTIONAL,
odb-Data [8] IMPLICIT SEQUENCE {
odb-GeneralData BIT STRING {
ss-AccessBarred (5)} (SIZE (6)),
odb-HPLMN-Data BIT STRING {
plmn-SpecificBarringType4 (3)} (SIZE (4)) OPTIONAL,
... } OPTIONAL,
OPTIONAL,
regionalSubscriptionData [10] IMPLICIT SEQUENCE SIZE (1..10) OF
...}
128
Issue 3.3 Messages
RESULT
insertSubscriberDataRes SEQUENCE {
ss-List [3] IMPLICIT SEQUENCE SIZE (1..30) OF
odb-GeneralData [4] IMPLICIT BIT STRING {
ss-AccessBarred (5)} (SIZE (6)) OPTIONAL,
regionalSubscriptionResponse [5] IMPLICIT ENUMERATED {
msc-AreaRestricted (0),
tooManyZoneCodes (1),
zoneCodesConflict (2),
regionalSubscNotSupported (3)} OPTIONAL,
...}
ERRORS {
::= localValue 7
deleteSubscriberData OPERATION
ARGUMENT
deleteSubscriberDataArg SEQUENCE {
basicServiceList [1] IMPLICIT SEQUENCE SIZE (1..70) OF
129
Issue 3.3 Messages
CHOICE {
ss-List [2] IMPLICIT SEQUENCE SIZE (1..30) OF
OPTIONAL,
regionalSubscriptionIdentifier [5] IMPLICIT OCTET STRING (SIZE (2))
OPTIONAL,
...}
RESULT
deleteSubscriberDataRes SEQUENCE {
regionalSubscriptionResponse [0] IMPLICIT ENUMERATED {
msc-AreaRestricted (0),
tooManyZoneCodes (1),
zoneCodesConflict (2),
regionalSubscNotSupported (3)} OPTIONAL,
...}
ERRORS {
::= localValue 8
reset OPERATION
ARGUMENT
resetArg SEQUENCE {
networkResource ENUMERATED {
plmn (0),
hlr (1),
vlr (2),
pvlr (3),
controllingMSC (4),
130
Issue 3.3 Messages
vmsc (5),
eir (6),
rss (7)} OPTIONAL,
hlr-List SEQUENCE SIZE (1..50) OF
OCTET STRING (SIZE (3..8)) OPTIONAL,
...}
::= localValue 37
forwardCheckSS-Indication OPERATION
::= localValue 38
restoreData OPERATION
ARGUMENT
restoreDataArg SEQUENCE {
lmsi OCTET STRING (SIZE (4)) OPTIONAL,
...}
RESULT
restoreDataRes SEQUENCE {
msNotReachable NULL OPTIONAL,
...}
ERRORS {
::= localValue 57
activateTraceMode OPERATION
ARGUMENT
131
Issue 3.3 Messages
activateTraceModeArg SEQUENCE {
traceReference [1] IMPLICIT OCTET STRING (SIZE (1..2)),
traceType [2] IMPLICIT INTEGER (0..255),
omc-Id [3] IMPLICIT OCTET STRING (SIZE (1..20)) OPTIONAL,
...}
ERRORS {
-- facilityNotSupported -- localValue 21,
-- unidentifiedSubscriber -- localValue 5,
-- tracingBufferFull -- localValue 40
::= localValue 50
deactivateTraceMode OPERATION
ARGUMENT
deactivateTraceModeArg SEQUENCE {
...}
ERRORS {
::= localValue 51
traceSubscriberActivity OPERATION
ARGUMENT
132
Issue 3.3 Messages
traceSubscriberActivityArg SEQUENCE {
traceType [2] IMPLICIT INTEGER (0..255),
omc-Id [3] IMPLICIT OCTET STRING (SIZE (1..20)) OPTIONAL,
callReference [4] IMPLICIT OCTET STRING (SIZE (1..3)) OPTIONAL}
::= localValue 52
noteInternalHandover OPERATION
ARGUMENT
noteInternalHO-Arg SEQUENCE {
handoverType ENUMERATED {
interBSS (0),
intraBSS (1)},
targetCellId [1] IMPLICIT OCTET STRING (SIZE (5..7)) OPTIONAL,
channelId [2] IMPLICIT SEQUENCE {
gsm-0408 (1),
gsm-0806 (2),
gsm-BSSMAP (3),
ets-300102-1 (4)},
... } OPTIONAL}
::= localValue 35
sendIMSI OPERATION
ARGUMENT
msisdn OCTET STRING (SIZE (1..9))
RESULT
imsi OCTET STRING (SIZE (3..8))
ERRORS {
133
Issue 3.3 Messages

::= localValue 58
sendRoutingInfo OPERATION
ARGUMENT
sendRoutingInfoArg SEQUENCE {
msisdn [0] IMPLICIT OCTET STRING (SIZE (1..9)),
cug-CheckInfo [1] IMPLICIT SEQUENCE {
cug-OutgoingAccess NULL OPTIONAL,
... } OPTIONAL,
numberOfForwarding [2] IMPLICIT INTEGER (1..5) OPTIONAL,
networkSignalInfo [10] IMPLICIT SEQUENCE {
gsm-0408 (1),
gsm-0806 (2),
gsm-BSSMAP (3),
ets-300102-1 (4)},
... } OPTIONAL,
...}
RESULT
sendRoutingInfoRes SEQUENCE {
routingInfo CHOICE {
roamingNumber OCTET STRING (SIZE (1..9)),
forwardingData SEQUENCE {
OPTIONAL,
forwardedToSubaddress [4] IMPLICIT OCTET STRING (SIZE (1..21))
OPTIONAL,
forwardingOptions [6] IMPLICIT OCTET STRING (SIZE (1)) OPTIONAL,
134
Issue 3.3 Messages
...}},
cug-CheckInfo SEQUENCE {
cug-OutgoingAccess NULL OPTIONAL,
... } OPTIONAL,
...}
ERRORS {
-- numberChanged -- localValue 44,
-- bearerServiceNotProvisioned -- localValue 10,
-- teleserviceNotProvisioned -- localValue 11,
-- absentSubscriber -- localValue 27,
-- callBarred -- localValue 13,
-- cug-Reject -- localValue 15,
-- forwardingViolation -- localValue 14}
::= localValue 22
provideRoamingNumber OPERATION
ARGUMENT
provideRoamingNumberArg SEQUENCE {
msc-Number [1] IMPLICIT OCTET STRING (SIZE (1..9)) OPTIONAL,
previousRoamingNumber [3] IMPLICIT OCTET STRING (SIZE (1..9))
OPTIONAL,
lmsi [4] IMPLICIT OCTET STRING (SIZE (4)) OPTIONAL,
gsm-BearerCapability [5] IMPLICIT SEQUENCE {
gsm-0408 (1),
135
Issue 3.3 Messages
gsm-0806 (2),
gsm-BSSMAP (3),
ets-300102-1 (4)},
... } OPTIONAL,
networkSignalInfo [6] IMPLICIT SEQUENCE {
gsm-0408 (1),
gsm-0806 (2),
gsm-BSSMAP (3),
ets-300102-1 (4)},
... } OPTIONAL,
...}
RESULT
roamingNumber OCTET STRING (SIZE (1..9))
ERRORS {
-- noRoamingNumberAvailable -- localValue 39}
::= localValue 4
registerSS OPERATION
ARGUMENT
registerSS-Arg SEQUENCE {
1: ss-Code OCTET STRING (SIZE (1)),
136
Issue 3.3 Messages

OPTIONAL,
OPTIONAL,
...}
RESULT
ss-Info CHOICE {
SEQUENCE {
OPTIONAL,
OPTIONAL,
OPTIONAL,
...},
...},
SEQUENCE {
...},
137
Issue 3.3 Messages
...},
SEQUENCE {
CHOICE {
...},
SEQUENCE {
1: interCUG-Restrictions OCTET STRING (SIZE (1)),
... } OPTIONAL,
...},
permanent (0),
138
Issue 3.3 Messages

CHOICE {
...}}
ERRORS {
-- illegalSS-Operation -- localValue 16,
-- ss-ErrorStatus -- localValue 17,
-- ss-SubscriptionViolation -- localValue 19,
-- ss-Incompatibility -- localValue 20}
::= localValue 10
eraseSS OPERATION
ARGUMENT
ss-ForBS SEQUENCE {
ss-Code OCTET STRING (SIZE (1)),
...}
RESULT
ss-Info CHOICE {
139
Issue 3.3 Messages

SEQUENCE {
OPTIONAL,
OPTIONAL,
OPTIONAL,
...},
...},
SEQUENCE {
...},
...},
SEQUENCE {
140
Issue 3.3 Messages
CHOICE {
...},
SEQUENCE {
... } OPTIONAL,
...},
permanent (0),
CHOICE {
141
Issue 3.3 Messages
...}}
ERRORS {
-- ss-SubscriptionViolation -- localValue 19}
::= localValue 11
activateSS OPERATION
ARGUMENT
ss-ForBS SEQUENCE {
...}
RESULT
ss-Info CHOICE {
SEQUENCE {
142
Issue 3.3 Messages

OPTIONAL,
OPTIONAL,
OPTIONAL,
...},
...},
SEQUENCE {
...},
...},
SEQUENCE {
CHOICE {
...},
143
Issue 3.3 Messages

SEQUENCE {
... } OPTIONAL,
...},
permanent (0),
CHOICE {
...}}
ERRORS {
144
Issue 3.3 Messages

-- ss-Incompatibility -- localValue 20,
-- negativePW-Check -- localValue 38,
-- numberOfPW-AttemptsViolation -- localValue 43}
1 ::= localValue 12
deactivateSS OPERATION
ARGUMENT
ss-ForBS SEQUENCE {
...}
RESULT
ss-Info CHOICE {
SEQUENCE {
OPTIONAL,
OPTIONAL,
OPTIONAL,
145
Issue 3.3 Messages

...},
...},
SEQUENCE {
...},
...},
SEQUENCE {
CHOICE {
...},
SEQUENCE {
146
Issue 3.3 Messages

... } OPTIONAL,
...},
permanent (0),
CHOICE {
...}}
ERRORS {
147
Issue 3.3 Messages

::= localValue 13
interrogateSS OPERATION
ARGUMENT
ss-ForBS SEQUENCE {
...}
RESULT
interrogateSS-Res CHOICE {
ss-Status [0] IMPLICIT OCTET STRING (SIZE (1)),
forwardedToNumber [1] IMPLICIT OCTET STRING (SIZE (1..9)),
basicServiceGroupList [2] IMPLICIT SEQUENCE SIZE (1..13) OF
CHOICE {
teleservice [3] IMPLICIT OCTET STRING (SIZE (1))},
forwardingFeatureList [3] IMPLICIT SEQUENCE SIZE (1..13) OF
SEQUENCE {
OPTIONAL,
OPTIONAL,
forwardingOptions [6] IMPLICIT OCTET STRING (SIZE (1)) OPTIONAL,
...},
cli-RestrictionInfo [4] IMPLICIT SEQUENCE {
148
Issue 3.3 Messages
ss-Status OCTET STRING (SIZE (1)),

cliRestrictionOption ENUMERATED {
permanent (0),
temporaryDefaultAllowed (2)} OPTIONAL,
...}}
ERRORS {
-- ss-NotAvailable -- localValue 18}
::= localValue 14
processUnstructuredSS-Data OPERATION
ARGUMENT
ss-UserData IA5String (SIZE (1..200))
RESULT
ss-UserData IA5String (SIZE (1..200))
ERRORS {
-- unexpectedDataValue -- localValue 36}
::= localValue 19
processUnstructuredSS-Request OPERATION
ARGUMENT
ussd-Arg SEQUENCE {
ussd-DataCodingScheme OCTET STRING (SIZE (1)),
149
Issue 3.3 Messages
ussd-String OCTET STRING (SIZE (1..160)),

...}
RESULT
ussd-Res SEQUENCE {
...}
ERRORS {
-- unknownAlphabet -- localValue 71,
-- callBarred -- localValue 13}
::= localValue 59
unstructuredSS-Request OPERATION
ARGUMENT
ussd-Arg SEQUENCE {
...}
RESULT
ussd-Res SEQUENCE {
...}
ERRORS {
-- illegalSubscriber -- localValue 9,
150
Issue 3.3 Messages
-- illegalEquipment -- localValue 12,

-- ussd-Busy -- localValue 72}
::= localValue 60
unstructuredSS-Notify OPERATION
ARGUMENT
ussd-Arg SEQUENCE {
...}
ERRORS {
-- illegalSubscriber -- localValue 9,
-- illegalEquipment -- localValue 12,
-- ussd-Busy -- localValue 72}
::= localValue 61
registerPassword OPERATION
ARGUMENT
ss-Code OCTET STRING (SIZE (1))
RESULT
newPassword NumericString (FROM ("0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9")|
SIZE (4))
ERRORS {
151
Issue 3.3 Messages

-- pw-RegistrationFailure -- localValue 37,
LINKED {
-- getPassword -- localValue 18}
::= localValue 17
getPassword OPERATION
ARGUMENT
guidanceInfo ENUMERATED {
enterPW (0),
enterNewPW (1),
enterNewPW-Again (2),
badPW-TryAgain (3),
badPW-FormatTryAgain (4)}
1: RESULT
currentPassword NumericString (FROM ("0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9")|
SIZE (4))
::= localValue 18
beginSubscriberActivity OPERATION
ARGUMENT
beginSubscriberActivityArg SEQUENCE {
originatingEntityNumber OCTET STRING (SIZE (1..9))}
::= localValue 54
sendRoutingInfoForSM OPERATION
ARGUMENT
routingInfoForSM-Arg SEQUENCE {
sm-RP-PRI [1] IMPLICIT BOOLEAN,
152
Issue 3.3 Messages
serviceCentreAddress [2] IMPLICIT OCTET STRING (SIZE (1..20)),

teleservice [5] IMPLICIT OCTET STRING (SIZE (1)) OPTIONAL,
...}
RESULT
routingInfoForSM-Res SEQUENCE {
locationInfoWithLMSI [0] IMPLICIT SEQUENCE {
locationInfo CHOICE {
msc-Number [1] IMPLICIT OCTET STRING (SIZE (1..9))},
lmsi OCTET STRING (SIZE (4)) OPTIONAL,
...},
mwd-Set [2] IMPLICIT BOOLEAN OPTIONAL,
...}
ERRORS {
-- callBarred -- localValue 13}
::= localValue 45
forwardSM OPERATION
ARGUMENT
forwardSM-Arg SEQUENCE {
sm-RP-DA CHOICE {
lmsi [1] IMPLICIT OCTET STRING (SIZE (4)),
153
Issue 3.3 Messages
serviceCentreAddressDA [4] IMPLICIT OCTET STRING (SIZE (1..20)),

noSM-RP-DA [5] IMPLICIT NULL},
sm-RP-OA CHOICE {
serviceCentreAddressOA [4] IMPLICIT OCTET STRING (SIZE (1..20)),
noSM-RP-OA [5] IMPLICIT NULL
154

1.OMA000004 NSS Signalling and Interface Analysis ISSUE3.3

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

1.OMA000004 NSS Signalling and Interface Analysis ISSUE3.3

Transféré par

Droits d'auteur :

Formats disponibles

OMA000004 NSS Signalling and interface analysis

NSS Signalling and interface analysis

4.2.1 Call Flow.................................................................................................................... 51

Introduction to the Course

Chapter 1 Signaling Connection Control Part

In this chapter, we mainly describe the parameters of the connection-oriented

1.2 Inter-layer Interfaces of SCCP

Service access point Signaling connection control part

Service primitive MTP service

Message transfer part

Figure1.1 Service primitive

Four types of primitives are specified in the OSI:

Network service Network service

Figure1.2 Inter-layer interfaces of the SCCP

Generic name Special name Parameter

Figure1.3 Syntactic structure of a primitive

Table3.1 SCCP user primitives used for network services

Primitive name Primitive type Protocol type Primitive parameter

N-UNITDATA Request v v CDA CGA SEQ RO UD

Indication v v CDA CGA UD

N-NOTICE Indication v v CDA CGA RR UD

N-CONNECT Request v v CDA CGA RCS EDS CI

Response v v RA RCS EDS CI

N-DISCONNECT Request v v RA REA UD CI

N-DATA ACKNOWLEDGE Request v CI

N-EXPEDITED DATA Request v UD CI

N-RESET Request v REA CI

N-INFORM Request v v REA QOS CI

The meanings of the abbreviations indicating the primitive parameters are as

QOS: Quality of Service parameter set

Table3.2 MTP service primitives

Primitive name Special name

MTP-TRANSFER Request Indication SCCP message

MTP-RESUME Indication Signaling point influenced

MTP-PAUSE Indication Signaling point influenced

MTP-STATUS Indication Signaling point influenced

MTP-UPU Indication Signaling point influenced

1.3 SCCP Message

1.3.1 SCCP Message Structure

The SCCP message structure is shown in Figure 1-4

F CK SIF SIO LI FIB FSN BIB BSN F

Message type Mandatory parameter

Optional parameter end

Figure1.1 SCCP message structure

10. Routing label (Label): The structure is DPC+OPC+SLS.

Table1.1 Common SCCP message types and codes

Message type Protocol type Code

Connection Request (CR) * * 0000 0001

Connection Confirmation (CC) * * 0000 0010

Connection Refused (CREF) * * 0000 0011

Connection Released (RLSD) * * 0000 0100

Release completed (RLC) * * 0000 0101

Data (DT1) * 0000 0110

Data (DT2) * 0000 0111

Protocol data unit Error (ERR) * * 0000 1111

Inactivity Test (IT) * * 0001 0000

Unit Data (UDT) * * 0000 1001

Unit Data Service (UDTS) * * 0000 1010

1.3.2 SCCP Message Parameters

Table1.1 SCCP message parameters

Parameter field Message Parameter

message type name code

Called address M M M O O 00000011

Calling address M M O 00000100