6.4.1 Basic Concepts
Signaling connection control part is abbreviated as SCCP. In the layered architecture of SS7, SCCP is one of the UPs. It belongs to the fourth functional group, providing additional functions for MTP at the same time so that circuit related information, non-circuit related information and other information can be transmitted between the switches and special centers of telecommunication network through SS7 network. Thus, connectionless or connection-oriented services can be created, and the third layer (network layer) of OSI layered model can be constructed.
I. Function
The purpose of SCCP is to provide the methods by which data information is transmitted in the following cases:
l Connecting logic signaling in the common channel signaling network.
l Transferring signaling data units with logic signaling connection established or not established.
With SCCP function, the circuit related and non circuit related signaling information of ISUP can be transmitted when peer-to-peer signaling connection is established or not established.
II. Basic Services
SCCP provides the following 4 classes of services:
l Class 0: basic connectionless service
l Class 1: ordered connectionless service
l Class 2: basic connection-oriented service
l Class 3: flow control connection-oriented service
Classes 0 and 1 services are connectionless, and classes 2 and 3 services are connection-oriented.
The connectionless services mean that the user can transfer signaling information through signaling network without setting up signaling connections in advance. The connectionless services of SCCP are equivalent to the data service of data network. Class 0 service do not ensure that messages can be transferred in sequence, while class 1 service can ensure that messages can be transferred to their destination in sequence by using SLS.
The connection-oriented services mean that users exchange control information between SCCPs to reach a protocol before transmitting data. The protocol contains the route through which data are transferred, the class of transferred services (whether it is basic connection-oriented class or flow control connection-oriented one), even possibly the amount of the data transferred, and so on.
The connection-oriented services of signaling can be divided into temporary signaling connection and permanent signaling connection.
Service users control the establishment of temporary signaling connection, which is similar to dialing telephone connection.
Permanent signaling connection is established and controlled by local (or remote) O&M function or by the node management function, which can provide the users with semi-permanent connection, which is similar to a leased telephone line. The connection-oriented connection described here refers to temporary signaling connection.
III. Application in SoftX3000
The SoftX3000 can interwork with SCP through IANP. As IANP needs SCCP and TCAP to transmit signaling, SCCP exists in SoftX3000 to serve as the intermediate layer for transferring messages.
SCCP messages are processed by the FCCU/FCSU in SoftX3000.
6.4.2 Singnaling Message
The SCCP message is a MSU of SS7. Its message contents lie in the SIF of MSU. An MSU is identified to be an SCCP message by the SI being 0011 in the SIO of the MSU, as shown in Figure 6-13.
The route tag in Figure 6-13 has been described in MTP section. The message type employs 8-bit coding. One code determines one SCCP message. The parameters of certain special message type that are described as mandatory and have fixed lengths must be put in the mandatory fixed part. The parameters that are mandatory but have variable lengths must be put in the mandatory variable part. Any individual message may include optional parameters. The optional parameters may be of fixed or variable lengths. If a parameter is mandatory with variable length, it is necessary to point out its position through the pointer. For optional parameters, it is necessary not only to point out their start bits but also to give their respective codes and lengths.
Figure 6-13 SCCP message format
I. SCCP Message Type
| Protocol class | |||||
| Message type | 0 | 1 | 2 | 3 | Code |
| Connection request (CR) | | | X | X | 00000001 |
| Connection confirm (CC) | | | X | X | 00000010 |
| Connection refusal (CREF) | | | X | X | 00000011 |
| Connection released (RLSD) | | | X | X | 00000100 |
| Release completed (RLC) | | | X | X | 00000101 |
| Data type 1 (DT1) | | | X | | 00000110 |
| Data type 2 (DT1) | | | | X | 00000111 |
| Data acknowledgement (AK) | | | | X | 00001000 |
| Unit data (UDT) | X | X | | | 00001001 |
| Unit data service (UDTS) | X | X | | | 00001010 |
| Expedited data (ED) | | | | X | 00001011 |
| Expedited data acknowledgement (EA) | | | | X | 00001100 |
| Reset request (RSR) | | | | X | 00001101 |
| Reset confirmation (RSC) | | | | X | 00001110 |
| Protocol data unit error (ERR) | | | X | X | 00001111 |
| Inactivity test (IT) | | | X | X | 00010000 |
×: means this message can be used in the corresponding protocol class.
The main message types are explained as follows:
l CR and CC are used to establish signaling connection.
l During signaling connection establishment, a CREF message should be sent to the originating node when the intermediate SCCP or the destination point SCCP has no enough resource to establish signaling connection.
l DT1, DT2 and ED are three kinds of messages used to transfer data after signaling connection is established successfully. Among them, DT1 is used for protocol class 2, while DT2 and ED are used for protocol class 3. In addition, DT2 and ED must be acknowledged by AK and EA.
l RLSD and RLC are used to release the signaling connection after data transfer.
l RSR and RSC are in protocol class 3 to re-initialize the data sending sequence numbers in the data transmitting stage.
l ERR is sent when any protocol error is detected, and IF is used to check whether both ends of the signaling connection work.
l UDT, XUDT, UDTS, and XUDTS are connectionless service messages. UDT and XUDT are used to transfer connectionless service data. When UDT and XUDT can not reach their destinations, UDTS and XUDTS must be sent to the originating point to show the causes if it is specified in UDT and XUDT.
II. Parameters of SCCP Message
To implement respective functions, SCCP messages must have parameters to provide all kinds of information. For example, the CR message must have the parameter [Called Address] to access the called subscriber and implement signaling connection. The ERR message must have the parameter [Error Cause] to show the causes of error. If a parameter is indispensable in a message, it is called mandatory (M) parameter for the message, and such messages include the mandatory parameter with fixed length (F) and the mandatory parameter with variable length (V). If a parameter is optional in a message, it is called an optional parameter (O). A parameter is mandatory in one message but may be optional in another message. Therefore, whether a parameter is mandatory or optional depends on the individual message.
Table 6-6 lists the parameters of SCCP message.
Table 6-6 Parameters of SCCP message
| Parameter name | Code |
| Optional parameters end | 00000000 |
| Destination local reference | 00000001 |
| Origin local reference | 00000010 |
| Called address | 00000011 |
| Caller address | 00000100 |
| Protocol class | 00000101 |
| Segmentation/re-assembly | 00000110 |
| Receiving No. P (R) | 00000111 |
| Sorting/segmentation | 00001000 |
| Credit | 00001001 |
| Release cause | 00001010 |
| Return cause | 00001011 |
| Reset cause | 00001100 |
| Error cause | 00001101 |
| Refusal cause | 00001110 |
| Data | 00001111 |
The meanings of the parameters in Table 6-6 are as follows:
l [Destination local reference] and [origin local reference] specify one signaling connection uniquely.
l [Called address] and [caller address] are used to identify originating/destination signaling point and/or SCCP service access point.
l [Protocol class] defines the four kinds of protocols of connectionless services and connection-oriented services.
l If the length of network service data unit (NSDU) is longer than the maximum length of message for data transmitting, the NSDU must be divided into several segments to be transferred and then reassembled when they reach the destination. The parameter [segmentation/reassemble] aims to implement this function. This parameter is only used for DT1.
l [Receiving No.] P(R) shows the expected next sequence number, which is used in DT2 and AK messages of protocol class 3 to confirm that the remote point has received all the messages prior to that numbered P (R) 1.
l [Sorting/segmentation] is an integrated parameter, including [Segmentation/re-assembly], [Sending No.] P (S) and [Receiving No.] P (R). Here P(S) should be in the range of window value prescribed in the protocol in order to implement the flow control of protocol class 3.
l [Credit] appears in CR or CC messages, determining the number of messages contained in the signaling connection transmission part. It is the window of the signaling connection, implementing flow control in protocol class 3. During the data transmission stage, the [credit] in an AK message can modify this window.
l [Release cause], [Reset cause] and [Refusal cause] are used respectively to show the causes for releasing, resetting and refusing the signaling connection. [Error cause] is used to show the causes of error in ERR message. [Return cause] is used in UDTS or XUDTS message of connectionless services to point out why UDT or XUDT is unable to reach the destination.
l [Data] is the network service data (NSD) that the user would send to the destination.
III. Examples of Parameter Format Coding
1) Subscriber address: called address/caller address
Subscriber address is a parameter with variable length. Its structure is illustrated in Figure 6-14.
Figure 6-14 Subscriber address structure
l Address indication
Address indication indicates the type of the address contained, as shown in
Figure 6-15.
Figure 6-15 Address indication
Table 6-7 lists the meaning of the bits of the address indication.
Table 6-7 Meanings of the bits of the address indication
| Bit | Value | Meaning |
| 0 | 0 | The address doe not contain the signaling point code. |
| 1 | The address contains the signaling point code. | |
| 1 | 0 | The address does not contain the subsystem number. |
| 1 | The address contains the subsystem number. | |
| Bits 5–2 | 0000 | The global tile is not included. |
| 0001 | The global title (GT) includes only the nature of address indication. | |
| 0010 | The GT includes only the translation type, coding plan, and coding design. | |
| 0100 | The GT includes the translation type, number design, coding design, and nature of address indication. | |
| 6 | 0 | Route selection should be based on the GT in the address. |
| 1 | Route selection should be based on the DPC in the MTP route tag and the sub-system number (SSN) in the called address (DPC+SSN). | |
| 7 | | National reserved. |
l Address
The order for various units appearing in the address is DPC, SSN, and GT, as shown in Figure 6-16.
Figure 6-16 Order of address units
DPC: Refer to the DPC in the MTP section.
SSN: It is used to identify the SCCP user functions. It is an 8-bit code, as shown below:
Bits: 76543210
00000000 Subsystem unknown
00000001 SCCP management
00000010 Reserved
00000011 ISUP
00000100 Operations, maintenance & administration part (OMAP)
00000101 Mobile application part (MAP)
00000110 Home location register (HLR)
00000111 Visitor location register (VLR)
00001000 Mobile switching center (MSC)
11111111 Reserved for expansion
GT: The format of GT has a variable length, including four possibilities:
GT indicator = 0001
When GT indicator is 0001, GT format is illustrated in Figure 6-17.
Figure 6-17 GT format when GT indicator is 0001
When GT indication is 0001, bits 6–0 of the first octet in GT are address nature indications, as shown below:
Bits 6–0:
0000000 Idle
0000001 User number
0000010 National reserved
0000011 National valid number
0000100 International number
Bit 7 is odd/even indication, which is encoded as follows:
0: even number of addresses
1: odd number of addresses
If the GT indication is 0001, the information after the second octet of the GT bits 7, 4, 3, 0 indicates the address signaling. See Figure 6-18.
Figure 6-18 Address information
Address signaling codes are as follows:
0000 Number 0
0001 Number 1
0010 Number 2
0011 Number 3
0100 Number 4
0101 Number 5
0110 Number 6
0111 Number 7
1000 Number 8
1001 Number 9
1010 Idle
1011 Code 11
1100 Code 12
1101 Idle
1110 Idle
1111 ST
If the address comprises an odd number of address signaling, the filling code 0000 should be added at the end of address signaling.
2) Protocol class and return selection
The protocol class is used to define SCCP service classes. The [Protocol class] field should be used at the stage of signaling connection establishment, and the protocol class should be negotiated by both ends of SCCP.
The protocol class is a 4-bit code.
Bits 3210
0000 Protocol class 0
0001 Protocol class 1
0010 Protocol class 2
0011 Protocol class 3
When bits 0–3 codes indicate that a protocol class is the connection-oriented class (protocol classes 2 and 3), bits 4–7 are idle.
When bits 0–3 codes indicate that a protocol class is the connectionless class (protocol classes 0 and 1), bits 4–7 are encoded as follows:
Bits: 7654
0000 Not specified
0001 to
0111 are idle.
1000 Error returned
1001 to
1111 are idle.
IV. Format and Composition of SCCP Message
Each SCCP message is made up of different parameters, including mandatory part and optional part (if any). Table 6-8 shows the corresponding parameters making up each message.
Table 6-8 SCCP messages and their corresponding parameters
| Message parameter | CR | CC | CREF | RLSD | RLC | DT1 | DT2 | AK | ED | EA | RSR | RSC | ERR | IT | UDT | UDTS |
| Destination local reference | | M | M | M | M | M | M | M | M | M | M | M | M | M | | |
| Origin local reference | M | M | | M | M | | | | | | M | M | | M | | |
| Called address | M | 0 | 0 | | | | | | | | | | | | M | M |
| Caller address | 0 | | | | | | | | | | | | | | M | M |
| Protocol class | | M | | | | | | | | | | | | M | M | |
| Segmentation/re-assembly | | | | | | M | | | | | | | | | | |
| Receiving sequence No. | | | | | | | | M | | | | | | | | |
| Sorting/segmentation | | | | | | | M | | | | | | | M | | |
| Credit | | | | | | | | M | | | | | | M | | |
| Release cause | | | | M | | | | | | | | | | | | |
| Return cause | | | | | | | | | | | | | | | | |
| Reset cause | | | | | | | | | | | M | | | | | |
| Error cause | | | | | | | | | | | | | M | | | |
| User data | 0 | 0 | 0 | 0 | | M | M | | M | | | | | | | |
| Refusal cause | | | M | | | | | | | | | | | | | |
| Optional parameters end | 0 | 0 | 0 | 0 | | | | | | | | | | | | |
M: mandatory parameter (of fixed length or variable length)
0: optional parameter
The composition of the messages is illustrated below:
2) CR message
A CR message comprises:
l Route tag
l Message type code
l Two pointers
For parameters of the CR message, see Table 6-9.
Table 6-9 Parameters of CR message
| Parameter | Type (F, V and O) | Length (octet) |
| Origin local reference | F | 3 |
| Protocol class | F | 1 |
| Called address | V | 3 (minimum) |
| Credit | 0 | 3 |
| Caller address | 0 | 4 (minimum) |
| Data | 0 | 3–130 |
| Optional parameters end | 0 | 1 |
3) UDT message
A UDT message comprises:
l Route tag
l Message type code
l Three pointers
For parameters of the UDT message, see Table 6-10.
Table 6-10 Parameters of UDT message
| Parameter | Type (F, V and O) | Length (octet) |
| Protocol class | F | 1 |
| Called address | V | 3 (minimum) |
| Caller address | V | 2 (minimum) |
| Data | V | 2–X |
X: (To be determined)
4) UDTS message
A UDTS message comprises:
l Route tag
l Message type code
l Three pointers
For parameters of the UDTS message, see Table 6-11.
Table 6-11 Parameters of UDTS message
| Parameter | Type (F, V and O) | Length (octet) |
| Return cause | F | 1 |
| Called address | V | 3 (minimum) |
| Caller address | V | 2 (minimum) |
| Data | V | 2–X |
X: (To be determined)
5) XUDT message
A XUDT message comprises:
l Route tag
l Message type code
l Four pointers
For parameters of the XUDT message, see Table 6-12.
Table 6-12 Parameters of XUDT message
| Parameter | Type (F, V and O) | Length (octet) |
| Protocol class | F | 1 |
| Called address | V | 3 (minimum) |
| Caller address | V | 2 (minimum) |
| Data | V | 2–X |
| Optional | O | 6 |
X: (To be determined)
6) XUDTS message
A XUDTS message comprises:
l Route tag
l Message type code
l Four pointers
For parameters of the XUDTS message, see Table 6-13.
Table 6-13 Parameters of XUDTS message
| Parameter | Type (F, V and O) | Length (octet) |
| Return cause | F | 1 |
| Called address | V | 3 (minimum) |
| Caller address | V | 2 (minimum) |
| Data | V | 2–X |
| Optional | O | 6 |
X: (To be determined)
No comments:
Post a Comment