The TCAP service contains functions that provide TCAP applications with access to the SCCP layer facilities for maintaining signaling point and subsystem status between the calling application's system and backup signaling points or concerned signaling points.
An application requests that its subsystem be taken out of service and have all traffic routed to its backup point code by invoking TCAPStateReq with a request type of TCAP_COORDREQ. This generates a SCCP subsystem-out-of-service-request (SOR) to the backup signaling point as specified in the SCCP SAP configuration. The application receives an incoming TCAP event with an event type of TCAP_COORDCFM 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 TCAP_COORDCFM event indication contains a value of UOR_DENIED in the subsystem multiplicity indicator (smi) field, implying that the application should not go out of service.
Alternatively, the backup point code requests to go out of service by sending the SOR message. This results in the application receiving a TCAP_COORDIND event as shown in the following illustration. The application invokes TCAPCoordResp with an event type of TCAP_COORDRESP to accept the request and return the SOG message.
The application notifies all concerned point codes of a change in its state by invoking TCAPStateReq with a status of SS_IS (in service) or SS_OOS (out of service). This request generates a subsystem available (SSA) or subsystem prohibited (SSP) message to all concerned signaling points as specified by the SCCP configuration of the application's SAP.
When the SCCP task receives messages from concerned signaling points indicating that their status has changed, the application receives an unsolicited TCAP event with an event type of TCAP_SSNSTIND (subsystem status) or TCAP_PCSTIND (point code status).
An application can monitor the status of remote signaling points by specifying a list of concerned point codes in the SCCP user SAP configuration corresponding to that application.
If all routes to a concerned point code (CPC) become unavailable, the application receives an unsolicited TCAP event with an event type of TCAP_PCSTIND with the status field set to SP_INACC (signaling point inaccessible). In addition, the application receives an unsolicited TCAP event with an event type of TCAP_SSNSTIND with the status field set to SS_OOS (subsystem out-of-service) for each known subsystem at that signaling point.
If the MTP layer receives an indication from the remote SP that the SCCP user part is unavailable, the application receives a TCAP_SSNSTIND (SS_OOS) event for each known subsystem at that signaling point. This is not true for the TCAP_PCSTIND event indication, since only the SCCP user part has failed and not the entire signaling point.
When communication with the affected signaling point is restored, the application receives an unsolicited TCAP event with an event type of TCAP_PCSTIND and 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 a subsystem available message is returned by the affected SP, the application receives a TCAP event with an event type of TCAP_SSNSTIND and the status field set to SS_IS (subsystem in-service). The application can re-establish communication with the affected SP/subsystem.
The following example shows a remote signaling point failure and recovery procedure: