Version

SCCP (Signalling Connection Control Part)

SCCP (Signalling Connection Control Part) is a network layer protocol used in telecommunications for transmitting signalling messages over a network. SCCP provides extended routing, flow control, segmentation, connection-orientation, and error correction facilities in the SS7 protocol suite. 
The base SCCP specification is defined by ITU-T in documentation Q.711 to Q.714, with additional information in Q.715 and Q.716.

SCCP Architecture

SCCP is situated above the Message Transfer Part (MTP) and below the Transaction Capabilities Application Part (TCAP) in the SS7 protocol stack. This positioning allows SCCP to leverage MTP's reliable transport capabilities while providing enhanced routing and addressing services to TCAP and other higher-layer protocols.

+------------------+------------------+
|        ASE       |       OMAP       |
+------------------+------------------+
|        TCAP      |                  |
+------------------+------------------+
|        SCCP      |       ISUP       |
+------------------+------------------+
|     MTP3: Signalling Network Layer  |
+-------------------------------------+
|      MTP2: Signalling Link Layer    |
+-------------------------------------+
|   MTP1: Signalling Data Link Layer  |
+-------------------------------------+

ASE (Application Service Elements): includes application-specific protocols and services.
OMAP (Operations, Maintenance, Administration, and Provisioning): handles network management functions.
TCAP (Transaction Capabilities Application Part): supports database services in telecom networks.
SCCP (Signalling Connection Control Part): provides connectionless and connection-oriented services
ISUP (ISDN User Part): manages the setup, management, and release of voice and data calls.
MTP (Message Transfer Part): 

  • MTP3 (Signalling Network Layer): responsible for message routing between different nodes.
  • MTP2 (Signalling Link Layer): ensures error-free transmission over a physical link.
  • MTP1 (Signalling Data Link Layer): handles the physical and electrical characteristics of the signalling link.

SCCP Message Structure

Unlike the Message Transfer Part (MTP), which routes messages based solely on Point Codes, SCCP allows for more sophisticated routing using either a Point Code and Subsystem Number or a Global Title.

Point Code: This is a unique identifier assigned to each node or network element within an SS7 network, used to direct messages to a specific node.

Subsystem Number: This identifies a specific application or service within a node, enabling targeted communication.

Global Title Translation (GTT): SCCP employs Global Title Translation to map logical addresses (Global Titles) to physical addresses (Point Codes), guiding MTP on how to route messages through the network.

SCCP also defines a structured message format (according to [RFC3868]) that is essential for communication across the network. This structure includes key elements such as:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Version    |   Reserved    | Message Class | Message Type  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Message Length                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Message Data                          |

 

SCCP Message Types

SCCP defines several message types to facilitate different communication functions:

Connectionless Messages (Used in protocol classes 0 and 1)
In connectionless mode, messages are sent independently without establishing a dedicated connection between the sender and receiver. This mode is suitable for applications where quick delivery is more critical than reliability. The following message types are used in connectionless mode:

  • Unitdata (UDT): Used by SCCP to send data in a connectionless mode. It is suitable for applications requiring quick transmission without the need for connection setup. 
  • Unitdata Service (UDTS): Indicates to the originating SCCP that a UDT message cannot be delivered. It is sent when the "return on error" option is set in the UDT. 
  • Extended Unitdata (XUDT): Supports the transmission of data with optional parameters in a connectionless mode. It is also used for segmenting large messages into multiple XUDT messages. 
  • Extended Unitdata Service (XUDTS): Informs the originating SCCP that an XUDT message cannot be delivered. It serves a similar purpose to UDTS but for XUDT messages. 
  • Long Unitdata (LUDT): Used to send larger data messages in connectionless mode without segmentation, taking advantage of MTP capabilities. Allows for NSDU sizes up to 3952 octets. 
  • Long Unitdata Service (LUDTS): Indicates to the originating SCCP that a Long Unitdata (LUDT) message cannot be delivered. This message is used when the LUDT delivery fails. 

Connection-Oriented Messages (Used in protocol classes 2 and 3 if other is not specified)
In connection-oriented mode, SCCP establishes a session between the sender and receiver, ensuring reliable message delivery. This mode is suitable for critical applications requiring data integrity and error correction. The following message types are used in this mode:

  • Connection Request (CR): Initiated by a calling SCCP to request the setup of a signalling connection with a called SCCP. It includes the Source Local Reference (SLR) as the address of the originating entity. 
  • Connection Confirm (CC): Sent by the called SCCP to indicate that the signaling connection has been successfully set up. It contains the SLR as the address of the called entity and DLR as the address of the originating entity. 
  • Connection Refused (CREF): Indicates that the setup of a signaling connection has been refused by the called SCCP or an intermediate node. 
  • Data Form 1 (DT1): Used to send user data between two SCCP nodes during an established connection. Used in the data transfer phase of protocol class 2.
  • Data Form 2 (DT2): Similar to DT1 but includes the ability to acknowledge messages flowing in the opposite direction. Used in the data transfer phase of protocol class 3.
  • Expedited Data (ED): Functions like a Data Form 2 message but bypasses the flow control mechanism, allowing expedited transmission. Used in protocol class 3.
  • Expedited Data Acknowledgement (EA): Acknowledges receipt of an Expedited Data message. Each ED message must be acknowledged by an EA before another ED message can be sent. Used in protocol class 3.
  • Data Acknowledgement (AK): Manages the window flow control mechanism during data transfer, ensuring that data is received and processed in order. Used in protocol class 3.
  • Inactivity Test (IT): Sent periodically to check if the signalling connection is active and to audit connection data consistency. 
  • Protocol Data Unit Error (ERR): Sent when protocol errors are detected, providing details about the error. 
  • Released (RLSD): Indicates that the sender wants to release a signalling connection and associated resources. It prompts the receiving node to release the connection as well. 
  • Release Complete (RLC): Sent in response to a Released message, confirming that the release procedures have been completed. 
  • Reset Request (RSR): Indicates that the sender wants to initiate a reset procedure, reinitializing sequence numbers with the receiver. Used in protocol class 3.
  • Reset Confirm (RSC): Sent in response to a Reset Request, confirming that the reset procedures have been completed. Used in protocol class 3.

SCCP Management Messages
These messages are used for managing subsystems and handling network conditions:

  • Subsystem-Prohibited (SSP): Informs concerned destinations of a subsystem failure, indicating that the subsystem is prohibited. 
  • Subsystem-Allowed (SSA): Informs destinations that a previously prohibited subsystem is now allowed or that an unavailable SCCP is now available. 
  • Subsystem-Status-Test (SST): Verifies the status of a prohibited subsystem or an unavailable SCCP, checking its operational status. 
  • Subsystem Congested (SSC): Sent by an SCCP node experiencing congestion, notifying concerned destinations of the congestion status. 
  • Subsystem-Out-of-Service-Request (SOR): Allows subsystems to go out of service gracefully without degrading network performance. 
  • Subsystem-Out-of-Service-Grant (SOG): Sent in response to a Subsystem-Out-of-Service-Request, confirming that the request has been granted and procedures are in place.

SCCP Protocol classes

SCCP protocol supports a variety of network services through four distinct protocol classes. These classes are designed to accommodate different communication needs.

There are two classes in connectionless mode:

Class 0: Basic Connectionless Class (BCC) 

  • Provides a straightforward, connectionless transport service where messages are sent independently without establishing a session or connection.
  • Ideal for applications like Short Message Service (SMS) where quick delivery is prioritized over reliability, and some message loss or duplication is acceptable.
  • Does not ensure message sequencing or delivery acknowledgment.

Class 1: Sequenced Connectionless Class (SCC)

  • Extends the basic connectionless service by ensuring messages are delivered in the order they were sent, adding a layer of reliability in terms of sequencing.
  • Suitable for applications requiring ordered message delivery, such as command and control systems, while still operating without a dedicated connection.

There are two classes in connection-oriented mode:

Class 2: Basic Connection-Oriented Class (BCCO)

  • Establishes a dedicated session between sender and receiver, ensuring reliable message delivery with flow control and error recovery.
  • Appropriate for transactional communications where data integrity and delivery confirmation are crucial.

Class 3: Flow Control Connection-Oriented Class (FCCO)

  • Builds upon Class 2 by providing enhanced flow control mechanisms, allowing dynamic adjustment of data flow to prevent congestion.
  • Suitable for applications with variable data rates that require both reliability and adaptability to network conditions.

Start innovating with Mobius

What's next? Let's talk!

Mobius Software

As a company you'll get:

  • Get started quickly

  • Support any business model

  • Join millions of businesses

Questions? websupport@mobius.com