In this section:
The DSC Platform supports the SCCP primitives for connection-oriented services shown in the following table. These primitives mirror the connection-oriented services as provided in SCCP protocol class 2, providing basic connection-oriented transport. Indication and confirmation messages are sent by SCCP and request messages are sent by the SCCP user application. The connect response messages are sent by the application.
SCCP Connection-Oriented Primitives
| Message Type | Direction | Description |
|---|---|---|
| N-CONNECT | Request/Indication/Response/Confirmation | Initiates connections. |
| N-DISCONNECT | Request/Indication | Terminates connections. |
| N-DATA | Request/Indication | Exchanges data. |
N-CONNECT
This primitive allows users to request a connection with a remote SCCP user application or serves to provide an indication to the remote SCCP user of an incoming connection request.
The DSC Platform sends a N-CONNECT (indication) to the SCCP user application to indicate an incoming connection request which the user must accept or reject. The DSC Platform also sends N-CONNECT (confirmation) to inform the user that the remote SCCP accepted the connection. The following table lists and describes the N-CONNECT parameters.
N-CONNECT Parameters
| Parameter | Req | Ind | Resp | Conf | Description |
|---|---|---|---|---|---|
| SCCP-ROUTING-LABEL | M | M | M | M | MTP3 routing label. |
| SCCP-CALLED-ADDR | M | M | N/A | N/A | Called party address. |
| SCCP-CALLING-ADDR | O | O | N/A | N/A | Calling party address. |
| SCCP-RESP-ADDR | N/A | N/A | O | O | Responding address of the communication. |
| SCCP-QUALITY-OF-SERVICE | M | M | M | M | Quality of service. |
| SCCP-USER-DATA | O | O | O | O | User data (payload). |
| SCCP-CONNECTION-ID | M | M | M | M | Connection identifier. |
| SCCP-GWS | O | O | O | O | Gateway screening. |
| SCCP-MSU-TRACING | O | O | O | O | MSU tracing. |
When a connection has been established, the SCCP reuses the fields (OPC, DPC, and SLS) of the routing label for all subsequent messages on the same connection.
The called and calling party address parameters hold the destination and origination addresses of the connection phase. These addresses are used to reroute the message. Similarly to the MTP3 routing label, these parameters are stored and reused for all subsequent messages on the same connection.
The responding address is present in the response in the event that the local user address differs from the received called address. This scenario occurs when replicated subsystems are used and failure conditions prevail.
User data can be sent along with connection messages, providing for faster payload delivery. A connection identifier is used to uniquely identify the connection instance.
Note
In a connection confirmation, the connection ID parameter contains a destination reference equal to the connection request connection ID Source Reference.
N-DISCONNECT
This primitive allows users to indicate the shutdown of a connection to the remote SCCP user application or serves to reject an incoming connection request.
An SCCP user application sends an N-DISCONNECT (request) to shutdown an active connection or to refuse an incoming connection, and receives an N-DISCONNECT (indication) when this application is notified of the shutdown of an active connection or the rejection of a connection request. The following table lists and describes the N-DISCONNECT parameters.
N-DISCONNECT Parameters
| Parameter | Request | Indication | Description |
|---|---|---|---|
| SCCP-REASON-FOR DISCONNECT | M | M | The reason for the disconnection |
| SCCP-RESP-ADDR | O | O | Responding address of the communication. The responding address is present in the request in the event that the local user address differs from the received called address. This scenario occurs when replicated subsystems are used, and failure conditions prevail, and is only used when rejecting an incoming connection. |
| SCCP-USER-DATA | O | O | User data (payload). User data can be sent along with the disconnect message, providing for faster payload delivery. |
| SCCP-CONNECTION-ID | M | M | Connection identifier. The connection identifier is used to uniquely identify the connection instance, as found originally in the N-CONNECT primitive. |
| SCCP-ORIGINATOR | M | M | Specifies the origin of the error. |
| SCCP-GWS | O | O | Gateway screening. |
| SCCP-MSU-TRACING | O | O | MSU tracing. |
N-DATA
This primitive carries data across to the remote SCCP user application. This primitive only exists as a request or an indication and is bidirectional. The following table lists and describes the N-DATA parameters.
N-DATA Parameters
| Parameter | Request | Indication | Description |
|---|---|---|---|
| SCCP-USER-DATA | M | M | User data containing the SCCP message. |
| SCCP-CONNECTION-ID | M | M | Connection identifier. The connection identifier is used to uniquely identify the connection instance, as found originally in the N-CONNECT primitive. |
| SCCP-SEGMENTING REASSEMBLY | N/A | M | Number of segments received at SCCP. |
| SCCP-GWS | O | O | Gateway screening. |
| SCCP-MSU-TRACING | O | O | MSU tracing. |
Overview
Content Tools