Signaling point and subsystem status procedures

The SCCP service contains functions for maintaining signaling point and subsystem status between the system containing the TX device(s) and backup signaling points or concerned signaling points.

This topic describes the following:

• Coordinated state change

• Subsystem state changes

• Remote signaling point failures

Coordinated state change

An application can request that its subsystem be taken out of service (and have all traffic routed to its backup point code) by invoking SCCPCoordRqst. This request generates an SCCP subsystem-out-of-service-request (SOR) to the backup signaling point (as specified in the SAP configuration). The application receives a SCCPCOORDCFM event when the backup signaling point returns a subsystem-out-of-service-grant (SOG) as shown in the following illustration:

If the backup signaling point fails to return a SOG message and the grant request times out, the SCCP layer returns SCCPCOORDCFM confirmation to the application with an indication that the request failed, and the application should not go out of service.

Alternatively, the backup point code can request to go out of service by sending the SOR message, resulting in the application receiving an SCCPCOORDIND event as shown in the following illustration. The application invokes SCCPCoordResp to accept the request and return the SOG message.

Subsystem state changes

The application notifies all concerned point codes of a change in its state (in-service or out-of-service) by invoking SCCPStateRqst. This request generates a subsystem available (SSA) or subsystem prohibited (SSP) message to all concerned signaling points as specified by the configuration of the application SAP.

Likewise, when the SCCP task receives messages from concerned signaling points indicating that their status has changed, the application receives an unsolicited SCCPSTATEIND indication (subsystem status) or SCCPPCSTIND indication (point code status).

Remote signaling point failures

An application can monitor the status of remote signaling points by specifying a list of concerned point codes in the user SAP configuration corresponding to that application.

If a concerned point code (CPC) becomes inaccessible, the application receives a SCCPPCSTIND event with the status field set to SP_INACC (signaling point inaccessible). In addition, the application receives a SCCPSTATEIND event with the status field set to SS_OOS (subsystem out-of-service) for each known subsystem at that signaling point.

Similarly, if the MTP layer receives an indication from the remote SP that the SCCP user part is unavailable, the application receives the SCCPSTATEIND (SS_OOS) event for each known subsystem at that signaling point. The application does not receive the SCCPPCSTIND event since only the SCCP user part has failed and not the entire signaling point.

The status field associated with an SCCPPCSTIND event indicates whether active connections have been dropped (status SP_INACC) or retained (SP_INACC_NODROP) when a remote signaling point becomes inaccessible. Dropping or retaining connections during an outage is a configuration option. If connections are dropped, the application does not receive an individual release indication for each active connection. Connections must be re-established when the affected signaling point/subsystem returns to service. If connections are retained across an outage and the remote SP remains inaccessible for a duration longer than the configured receive inactivity timer, those connections are released and must be re-established when the link is restored. In this case, the application is notified with an SCCPRELIND event for each connection when it is released.

When communication with the affected signaling point is restored, the application receives an SCCPPCSTIND event with the status field set to SP_ACC (SP accessible). The SCCP layer initiates subsystem status testing of all known subsystems at the affected SP. When the affected SP returns a subsystem available message, the application receives an SCCPSTATEIND event with the status field set to SS_IS (subsystem in-service). The application can re-establish connections and/or resume connectionless data transfer with the affected SP/subsystem.

The following illustration shows an example of remote signaling point failure and recovery procedures:

A remote signaling point can become congested with too many outbound messages. If this occurs, the application receives an SCCPPCSTIND event with a status field of SP_CONG1, SP_CONG2, or SP_CONG3. The status fields indicate a worsening level of congestion. An application first receives SP_CONG1, followed by SP_CONG2 if congestion increases. Upon receiving these indications, the application reduces traffic to this signaling point until the congestion has eased.

At each congestion level, traffic flow to the signaling point is affected as follows:

The following alarm message is generated as each congestion level is reached:

SCCP Route %s Congested, Level = 1
SCCP Route %s Congestion Ended