The SCCP default routing feature enables routing of SCCP packets generated by local applications, either directly with SCCP or through the TCAP layer, to signaling points whose point codes and subsystem numbers are not preconfigured.
This feature is primarily intended for applications that act as databases, or servers, in an SS7 network and cannot be preconfigured with the point codes of all clients that access the server. This feature is also suitable for other SCCP or TCAP-based applications such as replicated subsystems that do not require the signaling point and subsystem management features of the SCCP management functions.
When default routing is enabled, the SCCP layer attempts to deliver messages for which it has no explicit route entry by relying solely on the MTP layer routing. Default routing applies to all classes of SCCP messages (connectionless, connection-oriented, and management). Default routing effectively disables all SCCP management functionality for those remote signaling points or subsystems without explicit routes.
When default routing is enabled, you can preconfigure routes to certain known destinations, such as adjacent STPs or translators, or other remote subsystems that are replicated and require the SCCP management procedures for routing to backup signaling points in case of outages or congestion.
This topic presents:
Default routing is disabled by default. To enable default routing, add the following statement to the general configuration parameters section of the SCCP configuration file:
DEF_ROUTING TRUE # Default Routing (FALSE = OFF, TRUE = ON)
With default routing enabled, routing of outbound messages by the SCCP layer is performed as follows:
Global title translation, if necessary, is performed on the outbound message.
The SCCP layer checks for an explicit route to the destination point code. If an explicit route exists, the status of the destination signaling point and subsystem, if known, is checked. If the destination signaling point is active and the destination subsystem available (or unknown, such as routing by global title), the message is passed to the MTP 3 layer for delivery. If the signaling point is not accessible or the subsystem is unavailable, standard routing failure treatment is applied.
If no explicit route exists for the destination point code and default routing is disabled, standard routing failure treatment is applied.
If no explicit route exists for the destination point code and default routing is enabled, the message is passed to MTP 3 for delivery. If the MTP 3 layer is unable to deliver the message for any reason, the message is discarded and no notification is given to the application that originated the message.
The SCCP layer does not attempt to track the status of signaling points and subsystems that are not explicitly defined with route entries. Subsystem prohibited (SSP) and subsystem allowed (SSA) messages received for signaling points with no explicit route entry are ignored. Likewise, pause, resume, and remote user unavailable indications from the MTP 3 layer regarding signaling points with no explicit route entry are ignored. In effect, signaling points/subsystems with no explicit route entry are always considered available at the SCCP layer.
Subsystem testing (SST) is applied only to explicitly configured signaling points and subsystems. SST messages are never sent to destinations with no explicit route entry defined.
If an SST message is received from a signaling point that is not explicitly configured with a route entry, the appropriate response (SSA if the local subsystem is available, no response if the local subsystem is prohibited or unequipped) is returned, provided that the MTP 3 layer can route the response to that signaling point.
If the SCCP layer receives a message from an unknown (not explicitly configured) remote signaling point for a local subsystem that is either prohibited or unequipped, a subsystem prohibited (SSP) message is returned to the originating signaling point, provided that the MTP 3 layer can route to that signaling point. The appropriate message return (connectionless) or connection refusal (connection request) procedures are also performed.
The use of default routing effectively disables the SCCP layer management functions for those signaling points not explicitly configured with route entries. Following are some limitations of default routing:
If a local subsystem is to be replicated to take advantage of the SCCP layer's ability to route incoming messages to the backup signaling point when the local application is unavailable, an explicit route to the backup signaling point must be configured.
If a remote subsystem is to be replicated to take advantage of the SCCP layer's ability to route outgoing messages to the backup signaling point when the primary signaling point or subsystem is unavailable, explicit routes to both the primary and backup signaling points must be configured.
If a local application (SCCP or TCAP user) wants to receive status indications for a remote signaling point or subsystem when it becomes available, unavailable, or congested, an explicit route entry must be configured for each such remote signaling point. It must be listed as a concerned point code in the application's user SAP configuration.
If a remote subsystem is to receive automatic SSP and SSA messages when a local application (SCCP or TCAP user) declares itself unavailable or available, an explicit route entry must be configured for each such remote signaling point. It must be listed as a concerned point code in the application's user SAP configuration.
Subsystem prohibited (SSP) and subsystem allowed (SSA) messages received for signaling points with no explicit route entry are ignored. In effect, signaling points or subsystems with no explicit route entry are always considered available at the SCCP layer.