The Anatomy of an SS7 SCCP Connectionless Message
Signaling Connection Control Part (SCCP) extends the capabilities of MTP3 by supporting network-layer addressing, subsystem routing, and delivery of signaling data without establishing a dedicated connection. Its connectionless service is widely associated with TCAP transactions, mobile roaming, number portability, and database queries.
An SCCP connectionless message carries a carefully structured set of fields. Each field helps a signaling point decide where to send the message, which application should receive it, and whether the payload requires special handling such as segmentation or return-on-error processing.
Understanding this structure makes packet traces easier to interpret and clarifies how traditional SS7 networks interwork with SIGTRAN-based infrastructures.
Where SCCP Fits In The SS7 Stack
SCCP sits above MTP3 and below users such as TCAP, MAP, and INAP. MTP3 provides signaling network routing between point codes, while SCCP adds more flexible addressing through global titles and subsystem numbers.
A connectionless SCCP message is sent without a preliminary setup exchange. The sender places the required destination information into the message, and intermediate signaling points route it toward the destination. This differs from connection-oriented SCCP services, which maintain a logical signaling connection through a sequence of protocol messages.
The MTP3 service indicator identifies SCCP traffic, while the service information octet and routing label help the adjacent signaling point process the signaling unit. Correct distribution across available signaling links also depends on MTP3 procedures such as those described in this MTP3 load sharing guide.
The Core Message Header
The most common connectionless formats are Unitdata (UDT), Extended Unitdata (XUDT), and Long Unitdata (LUDT). Each begins with a message type code, followed by fields that describe protocol class and addressing parameters.
UDT is suitable for a normal connectionless payload that fits within the permitted signaling unit size. XUDT adds options for segmentation and includes a hop counter, making it better suited to larger messages or networks where loop prevention information is required. LUDT provides expanded length and addressing capabilities for even larger signaling data.
The protocol class indicates the service behavior. Class 0 provides basic connectionless transfer, while Class 1 supports sequenced delivery within a connectionless service. The return option determines whether SCCP should send the original message back when delivery fails.
Calling And Called Party Addresses
The called party address identifies the intended SCCP destination. It can contain a point code, subsystem number (SSN), global title, or a combination of these address indicators. The calling party address identifies the source and may use the same addressing methods.
Address indicators are essential because they tell the receiving node how to interpret the following address components. A destination may be represented directly by a signaling point code and SSN, or indirectly through a global title that must be translated by an STP.
Global title translation maps information such as an E.164 telephone number, IMSI, or service code to a signaling point code and subsystem number. This mechanism allows applications to address a logical destination without knowing its current network point code.
Message Type Comparison
| Message type | Main purpose | Segmentation support | Typical use |
|---|---|---|---|
| UDT | Basic connectionless delivery | No | Small TCAP queries and responses |
| XUDT | Extended connectionless delivery | Yes | Larger messages requiring segmentation |
| LUDT | Long connectionless delivery | Yes, with larger fields | High-volume or expanded signaling payloads |
| UDTS | Return of an undeliverable UDT | Reflects failure | Error notification for UDT traffic |
| XUDTS | Return of an undeliverable XUDT | Reflects failure | Error notification for segmented traffic |
Return messages such as UDTS and XUDTS are generated when a connectionless message cannot reach its destination and the return option permits notification. Their contents generally include enough of the original addressing and user data to identify the failed transaction.
Length Fields, Segmentation, And Hop Control
SCCP uses parameter-length fields so that receiving equipment can locate variable-size address and data components. The exact ordering depends on the message format, but a decoder typically examines the message type, protocol class, hop counter, addressing parameters, and user data in sequence.
When the payload exceeds the size supported by a single SCCP message, XUDT or LUDT may divide it into segments. Segmentation information identifies the position of each part and allows the receiving SCCP layer to reassemble the original user data before passing it upward to TCAP or another SCCP user.
The hop counter limits how many signaling points can forward a message. Each applicable node reduces the counter, and a message that reaches zero is discarded. This protects the network from persistent routing loops and provides a controlled failure response.
From SCCP Payload To Application
The user data parameter is the part delivered to the higher-layer protocol. In a mobile signaling exchange, it may contain a TCAP component carrying MAP operations such as Send Authentication Info, Update Location, or Provide Roaming Number.
SCCP does not interpret the application transaction itself. It transports the payload according to addressing and delivery rules, while TCAP manages dialogue portions, transaction identifiers, and components. This separation allows multiple applications to share the same signaling infrastructure.
An SSN identifies the subsystem at a destination signaling point. Common SSNs are associated with SCCP users such as TCAP, MAP, and maintenance functions. An incorrect SSN can result in a return message even when the network-level route is valid.
Reading A Trace Reliably
When analyzing a capture, begin with the MTP3 routing label and service indicator. Confirm the originating and destination point codes, network indicator, and signaling link selection before examining SCCP fields.
Next, identify the SCCP message type and protocol class. Inspect address indicators, global title format, translation type, numbering plan, encoding scheme, and SSNs. These values frequently reveal whether a message is addressed directly or requires global title translation.
Finally, verify the data length, segmentation markers, hop counter, and return option. Combining these observations with the TCAP layer above SCCP gives a complete view of message intent, routing behavior, and delivery outcome. For broader protocol references and structured lessons, use the SS7 training resource to reinforce packet-level analysis.
Apply this field-by-field method to live traces, lab captures, and SIGTRAN exercises. With practice, an SCCP connectionless message becomes a readable map of its origin, destination, routing decisions, delivery controls, and application payload.
