SCCP Messages

The Signalling Connection Control Part (SCCP) message are used by the peer to peer protocol. Following are the SCCP message used by the peer to connection oriented and connection less services.

Application that uses the service of SCCP are called Subsystems. Refer the SCCP structure for detail SCCP structure.

Classes of service:

• Class 0—Basic connectionless class - it has no sequencing control. i does not impose any condition on SLS, therefore SCCP message can be delivered in out-of-sequece.

• Class 1—In-sequence delivery connectionless class - it adds the sequence control to class 0 service by requiring to insert the same SLS to all NSDU.

• Class 2—Basic connection-oriented class - Assign the local reference numbers (SLR,DLR) to create logical connection. it does not provide the flow control, loss, and mis-sequence detection.

• Class 3—Flow control connection-oriented class - Class 3 is an enhanced connection-oriented service that offers detection of both message loss and mis-sequencing

1. Connection Request (CR): Connection Request message is initiated by a calling SCCP to a called SCCP to request the setting up of a signalling connection between two entities. On Reception of CR message, the called SCCP initiates the setup signalling connection. CR message have the Source Local Reference (SLR) as an address of originating entity. It is used during connection establishment phase by connection-oriented protocol class 2 or 3.

2. Connection Confirm (CC):  Connection Confirm message is initiated by the called SCCP to indicate to the calling SCCP that it has performed the setup of the signaling connection. On reception of a Connection Confirm message, the calling SCCP completes the setup of the signaling connection. CC message have the SLR as an address of called entity and DLR as the address of originating entity. It is used during connection establishment phase by connection-oriented protocol class 2 or 3.

3. Connection Refused (CREF): Connection Refused message is initiated by the called SCCP or an intermediate node SCCP to indicate to the calling SCCP that the setup of the signalling connection has been refused. It is used during connection establishment phase by connection-oriented protocol class 2 or 3.

4. Data Acknowledgement (AK): Data Acknowledgement message is used to control the window flow control mechanism, which has been selected for the data transfer phase. It is used during the data transfer phase in protocol class 3.

5.  Data Form 1 (DT1): A Data Form 1 message is sent by either end of a signalling connection to pass transparently SCCP user data between two SCCP nodes. It is used during the data transfer phase in protocol class 2 only.

6. Data Form 2 (DT2): A Data Form 2 message is sent by either end of a signalling connection to pass transparently SCCP user data between two SCCP nodes and to acknowledge messages flowing in the other direction. It is used during the data transfer phase in protocol class 3 only.

7. Expedited Data (ED): An Expedited Data message functions as a Data Form 2 message but includes the ability to bypass the flow control mechanism which has been selected for the data transfer phase. It may be sent by either end of the signalling connection. It is used during the data transfer phase in protocol class 3 only.

8. Expedited Data Acknowledgement (EA): An Expedited Data Acknowledgement message is used to acknowledge an Expedited Data message. Every ED message has to be acknowledged by an EA message before another ED message may be sent. It is used during the data transfer phase in protocol class 3 only.

9. Inactivity Test (IT): An Inactivity Test message may be sent periodically by either end of a signalling connection section to check if this signalling connection is active at both ends, and to audit the consistency of connection data at both ends. It is used in protocol classes 2 and 3. 

10. Protocol Data Unit Error (ERR): A Protocol Data Unit Error message is sent on detection of any protocol errors. It is used during the data transfer phase in protocol classes 2 and 3.

11. Released (RLSD): A Released message is sent, in the forward or backward direction, to indicate that the sending SCCP wants to release a signalling connection and the associated resources at the sending SCCP have been brought into the disconnect pending condition. It also indicates that the receiving node should release the connection and any other associated resources as well. It is used during connection release phase in protocol classes 2 and 3.

12. Release Complete (RLC): A Release Complete message is sent in response to the Released message indicating that the Released message has been received, and the appropriate procedures have been completed. It is used during connection release phase in protocol classes 2 and 3.

 13. Reset Request (RSR): A Reset Request message is sent to indicate that the sending SCCP wants to initiate a reset procedure (re-initialization of sequence numbers) with the receiving SCCP. It is used during the data transfer phase in protocol class 3.

14. Reset Confirm (RSC): A Reset Confirm message is sent in response to a Reset Request message to indicate that Reset Request has been received and the appropriate procedure has been completed.

It is used during the data transfer phase in protocol class 3.

15. Subsystem-Prohibited (SSP): A Subsystem-Prohibited message is sent to concerned destinations to inform SCCP Management (SCMG) at those destinations of the failure of a subsystem. It is used for SCCP subsystem management.

16. Subsystem-Allowed (SSA): A Subsystem-Allowed message is sent to concerned destinations to inform those destinations that a subsystem which was formerly prohibited is now allowed or that a SCCP which was formerly unavailable is now available. It is used for SCCP management.

17. Subsystem-Status-Test (SST): A Subsystem-Status-Test message is sent to verify the status of a subsystem marked prohibited or the status of an SCCP marked unavailable. It is used for SCCP management.

18. UnitData (UDT): A Unitdata message can be used by an SCCP wanting to send data in a connectionless mode. It is used in connectionless protocol classes 0 and 1.

19. Unitdata Service (UDTS): A Unitdata Service message is used to indicate to the originating SCCP that a UDT sent cannot be delivered to its destination. Exceptionally and subject to protocol interworking considerations, a UDTS might equally be used in response to an XUDT or LUDT message. A UDTS message is sent only when the option field in that UDT is set to "return on error". It is used in connectionless protocol classes 0 and 1.

20. Extended Unitdata (XUDT): An Extended Unitdata message is used by the SCCP wanting to send data (along with optional parameters) in a connectionless mode. It is used for the segmentation of large message into more XUDT messages. It is used in connectionless protocol classes 0 and 1.

21. Extended Unitdata Service (XUDTS): An Extended Unitdata Service message is used to indicate to the originating SCCP that an XUDT cannot be delivered to its destination. It is used in connectionless protocol classes 0 and 1.

22. Subsystem Congested (SSC): A Subsystem Congested message is sent by an SCCP node when it experiences congestion.  It is used for SCCP subsystem management.

23. Long Unitdata (LUDT): Long Unitdata message is used by the SCCP to send data (along with optional parameters) in a connectionless mode. When MTP capabilities according to Recommendation Q.2210 are present, it allows sending of NSDU sizes up to 3952 octets without segmentation. It is used in Connectionless protocol classes 0 and 1.

24. Long Unitdata Service (LUDTS): A Long Unitdata Service message is used to indicate to the originating SCCP that an LUDT cannot be delivered to its destination. It is used in connectionless protocol classes 0 and 1.

25. Subsystem-Out-of-Service-Request (SOR): A Subsystem-Out-of-Service-Request message is used to allow subsystems to go out-of-service without degrading performance of the network. When a subsystem wishes to go out-of-service, the request is transferred by means of a Subsystem-Out-of-Service-Request message between the SCCP at the subsystem's node and the SCCP at the duplicate subsystems, node.

It is used for SCCP subsystem management.

26. Subsystem-Out-of-Service-Grant (SOG): A Subsystem-Out-of-Service-Grant message is sent, in response to a Subsystem‑Out‑of‑Service‑Request message, to the requesting SCCP if both the requested SCCP and the backup of the affected subsystem agree to the request. It is used for SCCP subsystem management.