SCCP Connection-Oriented Signaling: CR, CC, DT, And RLSD
Signalling Connection Control Part (SCCP) provides services above MTP3 in the SS7 protocol stack. Its connection-oriented mode creates a logical signalling relationship between two endpoints before application data is exchanged, supporting reliable delivery for services such as TCAP-based transactions and mobile network procedures.
The exchange is built around four important message types: Connection Request (CR), Connection Confirm (CC), Data (DT), and Released (RLSD). Understanding their sequence makes it easier to analyse call flows, troubleshoot signalling links, and relate traditional SS7 networks to SIGTRAN deployments used by Australian carriers and service providers.
| Message | Main purpose | Typical direction | Important result |
|---|---|---|---|
| CR | Requests a logical SCCP connection | Originating node to destination | Connection attempt begins |
| CC | Accepts the requested connection | Destination to originating node | Connection becomes usable |
| DT | Carries user data on the connection | Either direction | Application information is exchanged |
| RLSD | Releases the logical connection | Either endpoint | Connection is cleared |
Where SCCP Fits In The SS7 Stack
SCCP extends MTP3 by adding addressing and transport functions that are valuable when a signalling application needs more than basic point-to-point message delivery. Its addressing can include point codes, subsystem numbers, and global titles, allowing traffic to reach resources such as an HLR, MSC, SCP, or service database.
In practical SS7 architecture, MTP1 and MTP2 carry signalling over a physical or data-link layer, while MTP3 handles network routing. SCCP then provides connectionless or connection-oriented services to upper layers, commonly TCAP. Engineers studying these relationships can use the SS7 training catalogue to connect protocol theory with packet traces and network scenarios.
Connection-oriented SCCP is particularly useful when several related messages need a recognised logical association. The connection itself does not represent a voice path. Instead, it provides a signalling transport context, identified through local and remote references exchanged during setup.
CR Starts The Signalling Relationship
A CR message is sent by the originating SCCP user to request a connection. It can contain a called party address, calling party address, protocol class, source local reference, and user data. The source local reference allows the originator to identify this particular connection before a destination reference has been assigned.
The receiving node examines the address, checks whether the requested SCCP service is available, and decides whether it can accept the connection. In a mobile network, this might involve routing towards a subsystem at a switching centre or database. A failed translation, unavailable subsystem, or unsupported protocol class can prevent the setup from progressing.
Australian operators may have signalling traffic crossing very different geographical conditions, from dense Sydney and Melbourne interconnects to long-haul routes serving regional Queensland or Western Australia. Good trace analysis therefore distinguishes an addressing failure from a link, routing, or application problem.
CC Confirms The Connection
When the destination accepts the request, it returns a CC message. The confirmation normally includes the destination local reference, which the originating side uses together with its own reference to identify the connection. After this exchange, both SCCP users have the information required to send data across the logical association.
A CC can also carry user data, depending on the application and implementation. If the destination cannot accept the request, a different response such as a connection refusal is used rather than CC. Monitoring systems should therefore verify the complete setup sequence instead of treating every response as successful establishment.
Timers are important during this stage. A CR that receives no timely CC may indicate congestion, an unavailable subsystem, incorrect routing, or a broken SIGTRAN association. In a national network supporting services around the clock, alarms should correlate SCCP setup failures with M3UA, SCTP, MTP3, and IP transport events.
DT Carries Application Information
Once the connection is confirmed, DT messages transport user data between the SCCP users. Each DT includes connection references so the receiving side can associate the payload with the correct logical relationship. The data may contain a TCAP component, transaction information, or another application-layer message.
Sequence control depends on the SCCP protocol class and implementation. Connection-oriented service can provide an ordered exchange suitable for applications that need a maintained signalling context. It still does not replace application-level timers, transaction identifiers, or error handling. TCAP and the service using it retain responsibility for their own procedures.
A trace of DT traffic should be read alongside the payload protocol. Looking only at SCCP fields can show that messages were delivered while missing a malformed TCAP dialogue, an unexpected transaction state, or a subscriber-data timeout. This layered approach is useful when analysing roaming, number portability, prepaid services, and emergency-related signalling.
RLSD Clears The Logical Connection
RLSD is used to release an established or partially established SCCP connection. It may be sent after the application has completed its exchange, when a protocol error occurs, or when a node needs to clear resources. The message identifies the connection through the relevant local and remote references and may include a cause value.
The receiving endpoint normally responds with a release confirmation, RLC, completing the clearing procedure. A missing RLC can leave resources allocated until a timer expires, so repeated RLSD exchanges or unusual release delays deserve attention. The cause field can help separate normal completion from congestion, protocol violation, or remote-user failure.
In SIGTRAN networks, SCCP release behaviour should be reviewed alongside SCTP associations, M3UA routing keys, and the availability of signalling gateways. Australian deployments also need to account for ACMA obligations, carrier interconnection arrangements, and the operational importance of 000-related services, where signalling faults require careful escalation and auditing. Practical architecture references are available through signalling solutions.
Practical Checks For Engineers
A disciplined trace review prevents message names from being interpreted in isolation. Check the address translation, point codes, subsystem numbers, protocol class, local references, timers, and release causes together. Useful priorities include:
- Confirm that every CR reaches the intended SCCP subsystem.
- Match each CC with the correct source and destination references.
- Decode DT payloads at the TCAP or application layer.
- Investigate missing RLC messages and repeated timer expiries.
- Correlate SS7 events with M3UA, SCTP, and IP network alarms.
For Australian network teams, testing should include metropolitan traffic patterns, regional backhaul conditions, carrier interconnects, and maintenance windows aligned with local operational practices. A clear baseline for normal CR–CC–DT–RLSD behaviour makes unusual traces easier to isolate.
The key sequence is simple: CR asks to establish the relationship, CC confirms it, DT carries the signalling data, and RLSD releases the connection. Remembering those roles, together with the reference numbers and timers that support them, provides a reliable foundation for troubleshooting SCCP connection-oriented signalling.
