SCCP Management (SCMG)

SCMG manages the status of subsystems and SCCP-capable signaling points (SPs). It maintains the status of remote SCCP SPs and that of local subsystems. It interacts with the SCRC to ensure that SCCP traffic is not sent to inaccessible destinations; if they are available, they use alternative routes or alternative subsystems to provide SCCP traffic rerouting. In addition, SCMG throttles SCCP traffic in the event of network congestion.

SCMG uses the concept of a "concerned" subsystem or SP. A "concerned" subsystem or SP is marked as requiring immediate notification if the affected subsystem or SP status changes. An affected SP might not have any subsystems or SPs marked as "concerned"; in this case, when a subsystem fails or inaccessibility occurs at the affected SP, it does not broadcast the status change. If it has entities marked as "concerned," it will broadcast the SSP message so the SCMG at the "concerned" entities can react to circumvent routing to the unavailable SP or subsystem.

A response method is used when a message is received that is addressed to an unavailable subsystem from an SP/subsystem that has not been notified of the status change. Upon receiving such a message, the affected SP returns the SSP message. The notified SP/subsystem can then periodically check whether the affected subsystem is available by sending a SCMG Subsystem status Test (SST) to the affected SP. The affected SP returns an SCMG Subsystem Allowed (SSA) message if the subsystem is available again. An SP/subsystem might not have been notified of the status change because it was not on the "concerned" list, the SSA/SSP message sent from the affected SP was lost, or the affected SP was recovering from either an MTP or SCCP failure, in which case it does not make a broadcast upon recovery. Figure 9-22 presents an example of the response method.

In Figure 9-22, the toll-free subsystem (SSN = 254) at SP-Z is down. When SP-Y tries to send connectionless data to the subsystem, SP-Z informs SP-Y that the subsystem is not available using the SSP message. SP-Y periodically checks whether the toll-free subsystem at SP-Z is back up again by using the SST message. On the second SST, the subsystem is available again and, as a result, SP-Z sends back a SSA message. It should be understood that other subsystems might exist at SP-Z and these might be functioning as normal, even though the toll free subsystem went down and later came back up again.

Upon receiving an SSP message, SP-Y updates its translation tables to select statically provisioned alternative routing to backup SPs and/or backup subsystems (if available).

Replicate Subsystems

Subsystems can be deployed in pairs; this is known as a replicate subsystem. Replicate subsystems are normally only used at an SCP pair and are connected to a common intermediate node (STP). Under normal conditions, SCCP traffic can be load-shared across the replicate subsystems. Optionally, one of the subsystems can be designated as primary and the other as backup. If the primary subsystem becomes prohibited, the backup subsystem services the SCCP messages that were originally destined for the primary subsystem.

SCMG messages are used to coordinate the activity of a replicated subsystem. When one subsystem that belongs to the pair wishes to go out of service, a Subsystem Out-of-service Request (SOR) is sent to the replicate's other subsystem. If the subsystem that receives the SOR determines that the replicate can be taken out of service without degrading SCCP performance, a Subsystem Out-of-service Grant (SOG) is sent in response. The determination of whether the SOG is sent is based on the traffic load and available resources.

The ANSI SCCP standards specify three optional messages [2] for providing SCCP traffic mix information when subsystems are deployed as primary/backup pairs:

• Subsystem Backup Routing (SBR)

• Subsystem Normal Routing (SNR)

• Subsystem Routing Test (SRT)

If a primary subsystem becomes prohibited, the intermediate node that is connected to the replicate pair sends an SBR message to the backup subsystem to inform the backup subsystem that it is receiving traffic that was originally destined for the primary subsystem. The SRT is periodically sent to verify the status of a subsystem that is marked as backup routed. When the primary subsystem becomes available again, the SNR message is sent to update the traffic mix information at the backup node. This allows the backup node to be aware that it is no longer serving traffic that is rerouted from the primary node.

Figure 9-23 shows an example of using a replicated subsystem with a designated primary and backup node. When subsystem 254 is being removed from service, an SOR message is sent from SCP A to SCP B. SCP B determines that it is acceptable for the replicate subsystem to be removed from service and returns a SOG. In this example, the optional SBR message indicating that backup traffic is being received is sent from STP C to SCP B.

In Figure 9-24, subsystem 254 is returned to service at SCP A, and the optional SNR message is sent to SCP B to indicate that it is no longer receiving backup traffic.

The messages used by SCMG are detailed in the following section.

SCMG Messages

SCMG messages are carried using the SCCP's connectionless service. When transferring SCMG messages, Class 0 is requested with no special option. The called and calling party address parameters that set the SSN to SCMG, and set the RI to route on SSN. SCMG messages are encapsulated in the data parameter of the UDT, XUDT, or LUDT message.

Table 9-15 shows the SCMG message types.

Table 9-15. The Format Identifiers of ANSI and ITU-T SCCP Management Messages.

Pseudonym/Message	Binary Code
Subsystem Allowed (SSA)	00000001
Subsystem Prohibited (SSP)	00000010
Subsystem Status Test (SST)	00000011
Subsystem Out-of-service request (SOR)	00000100
Subsystem Out-of-service Grant (SOG)	00000101
SCCP/Subsystem Congested (SSC)	00000110
Subsystem Backup Routing[1] (SBR)	11111101
Subsystem Normal Routing[1] (SNR)	11111110
Subsystem Routing Test[1] (SRT)	11111111

^[1] Found only in ANSI SCCP [2]

Appendix C includes a full description of these messages. It should be clear that these are independent from MTP3 signaling network management messages.

Signaling Point Status Management

Signaling point status management informs the other management functions of changes in other nodes. For point code failures, all functions that are associated with the failed node are marked as failed. Message routing programs broadcast messages to the rest of the network to inform the network of the failure.

Subsystem Status Management

Changes in the status of any of the local subsystems are reported to other SPs in the network. If the failure is at another node, this SCCP function informs the local subsystems about the problem.