SCCP Overview

SCCP Routing Control

SCCP routing control receives messages from other nodes in the network via the MTP-Transfer indication.

A load balancing function assigns each LIM to a service module to distribute the SCCP traffic among the available service modules. When a LIM receives an SCCP message that is destined for the EAGLE, it sends the message to the service module assigned to that LIM. If that LIM does not have a service module assigned to it, the LIM discards the SCCP message. If no service modules are equipped or available, the SCCP message is discarded and the LIM transmits a User Part Unavailable MSU to the sending node.

When a LIM receives an SCCP message that is destined for another node, the LIM performs MTP routing and the SCCP message is not sent to the service module. Figure 2-31 shows the message flow for an SCCP message destined for the EAGLE and for an SCCP message destined for another node.

Figure 2-31 SCCP Message Flow through the EAGLE

When SCCP receives a message from MTP, it checks the routing indicator in the called party address. There are two types of routing shown by the called party address routing indicator.

Subsystem (ssn) – This indicates the message is destined for a subsystem at this node. For the EAGLE, the only valid local subsystem is SCCP management (ssn = 1). If the LNP feature is enabled, the EAGLE contains an LNP subsystem which can be numbered from 2 to 255. The LNP subsystem number can be configured with the "Adding a Subsystem Application" procedure in Administration and LNP Feature Activation Guide for ELAP.
Global Title (gt) – This indicates that global title translation is required. The EAGLE performs the translation, determines the new DPC for the message, and routes the message to that DPC.

Global Title Translation Function

Interaction with the Global Title Translation (GTT) Feature

The SCCP routing function control uses two tables to perform global title translation: the translation type table and the global title translation table. Figure 2-32 shows how these tables are organized.

Figure 2-32 Example of Using Translation Type and Global Title Translation Tables

The translation type table is used by SCCP to determine which global title translation table to access. This allows translation tables to be customized to the type of translations that need to be performed, (for example, 6 digit, 800, etc.). The translation block is accessed by using the translation type in the called party address and the network type of the MSU (ANSI or ITU) as an index within the table. Each entry points to the start of a global title translation table.

The translation type table is configured by the ent-tt command. For more information on the ent-tt command, refer to the Commands Manual.

Each translation type entry in the translation type table contains these fields:

name of translation type (optional) (8 bytes)
number of digits (1 byte)
alias translation type (2 bytes)
pointer to translation table (4 bytes)
network type (1 byte)

The global title translation table is used by SCCP to map a global title address to an SS7 network address so that the SCCP message can be routed to its destination. The global title translation table is configured by the ent-gtt or chg-gtt commands. For more information on the ent-gtt or chg-gtt commands, refer to Commands User's Guide.

Each global title translation entry in the global title translation table contains these fields:

Global title address low value (up to 21 digits) (11 bytes)
Global title address high value (up to 21 digits) (11 bytes)
Destination point code (may be an ANSI, ITU national, or ITU international point code) (4 bytes)
Field that contains either a subsystem number (for route on SSN translation results only) (1 byte) or a new translation type (for new GT translation result only) (1 byte)
Translation result consisting of one of these conditions (1 byte):
- Translate on the DPC only, route on GT (subsequent global title translation required)
- Translate on the DPC only, route on SSN
- Translate on the DPC and SSN, route on GT (subsequent global title translation required)
- Translate on the DPC and SSN, route on SSN
- Translate on new GT (subsequent global title translation required)

The translation result determines what data in the message is replaced. The DPC in the routing label is always replaced after the SCCP message is translated. If a point code exists in the called party address, it is also replaced. The subsystem number or the translation type in the called party address can be replaced, but neither have to be replaced. The routing indicator in the called party address can be set to “route on SSN,” or can remain set to “route on GT.” Table 2-29 shows which fields in the MSU are modified for each translation result.

Table 2-29 MSU Fields Modified by Global Title Translation

Translation Result	Routing Label DPC Replaced	CDPA SSN Replaced	CDPA Routing Indicator Replaced	CDPA Translation Type Replaced	CDPA PC Replaced (if it already exists)
Translate on DPC only, route on GT	yes	no	no – remains set to route on GT	Can be replaced (See note)	yes
Translate on DPC only, route on SSN	yes	no	yes – set to route on SSN	no	yes
Translate on DPC and SSN, route on GT	yes	yes	no – remains set to route on GT	no	yes
Translate on DPC and SSN, route on SSN	yes	yes	yes – set to route on SSN	no	yes
Translate on new GT	yes	no	no – remains set to route on GT	yes	yes
Note: The CDPA translation type can be replaced when translating on the DPC only and routing on GT only if the ANSI/ITU SCCP Conversion feature is enabled. If the ANSI/ITU-China SCCP Conversion feature is not enabled when translating on the DPC only and routing

Route on GT

The “Route on GT” translate indicator (subsequent global title translation required) represents the need for a second translation after the initial one.

This need is indicated by the routing bit being set to “route on GT.” In this case, the remote point code table is not checked for status of the subsystem number. Instead, the MSU is sent directly to MTP for routing to the translated point code. If the point code is inaccessible, the MSU is discarded, and a UDTS (unitdata service) message is generated if the return on error option is set.

Interaction with the Enhanced Global Title Translation (EGTT) Feature

The SCCP routing function control uses three tables to perform global title translation: the GTT Selector table, the GTT Set table, and the global title address (GTA) table. The SCCP use the GTT Set table together with the GTT Selector table to determine which GTA table to access. This allows translation tables to be customized with the type of translations that need to be performed.

Figure 2-33 Example of Using GTT Selector, GTT Set, and GTA Tables

The GTT Set table is configured by the ent-gttset command; the GTT Selector table is configured by the ent-gttsel. For more information on this command, refer to Commands User's Guide.

Each GTT Set table contains these fields:

GTT Set name
Network domain name
Number of digits

Each GTT Selector table contains these fields:

GTT Set name
The global title indicator (GTI). The GTI defines the domain as
- gti and gtia (ANSI) with GTI=2
- gtii (ITU international) with GTI=2 or GTI=4, and
- gtin (ITU national) with GTI=2 or GTI=4.
  The global title indicator is made up of the:
  - name of the global title translation type (TT); and the
  - numbering plan (NP) or numbering plan value (NPV) if GTI=4; and the
  - nature of address indicator (NAI) or nature of address indicator value (NAIV) if GTI=4.
    Note:
    Both the numbering plan and nature of address indicator parameters can be specified by supplying either a mnemonic or an explicit value. At no time may both the mnemonic and the explicit value be specified at the same time for the same parameter.

The GTA table is used by the SCCP to map a global title address to an SS7 network address so that the SCCP message can be routed to its destination. The GTA table is configured by the ent-gta or chg-gta commands. For more information on the ent-gta or chg-gta commands, refer to Commands User's Guide.

Each global title address entry in the GTA table contains these fields:

GTT Set name
Start of the global title address (up to 21 digits)
End of the global title address (up to 21 digits)
Destination point code (may be an ANSI, ITU national, or ITU international point code)
Translated subsystem number
Translate indicator
Cancel Called Global Title indicator
Routing indicator (translation results)
- Translate on the DPC only, route on GT (subsequent global title translation required)
- Translate on the DPC only, route on SSN
- Translate on the DPC and SSN, route on GT (subsequent global title translation required)
- Translate on the DPC and SSN, route on SSN
- Translate on new GT (subsequent global title translation required)

The translation result determines what data in the message is replaced. The DPC in the routing label is always replaced after the SCCP message is translated. If a point code exists in the called party address, it is also replaced. The subsystem number or the translation type in the called party address can be replaced, but neither have to be replaced. The routing indicator in the called party address can be set to “route on SSN” or can remain set to “route on GT.” Table 2-30 shows which fields in the MSU are modified for each translation result.

Table 2-30 MSU Fields Modified by Enhanced Global Title Translation

Translation Result	Routing Label DPC Replaced	CDPA SSN Modified	CDPA Routing Indicator Replaced	CDPA Translation Type Replaced	CDPA PC Replaced (if it already exists)	GT Deleted
Translate on DPC only, route on GT	yes	no	no – remains set to route on GT	Can be replaced (See note)	yes	no
Translate on DPC only, route on SSN	yes	no	yes – set to route on SSN	no	yes	yes
Translate on DPC and SSN, route on GT	yes	yes	no – remains set to route on GT	no	yes	no
Translate on DPC and SSN, route on SSN	yes	yes	yes – set to route on SSN	no	yes	yes
Translate on new GT	yes	no	no – remains set to route on GT	yes	yes	no
Note: The CDPA translation type can be replaced when translating on the DPC only and routing on GT only if the ANSI/ITU SCCP Conversion feature is enabled. If the ANSI/ITU SCCP Conversion feature is not enabled when translating on the DPC only and routing on GT, the CDPA translation type cannot be replaced.

Route on GT

The “Route on GT” translate indicator (subsequent global title translation required) represents the need for a second translation after the initial one.

This need is indicated by routing being set to “route on GT.” In this case, the remote point code table is not checked for status of the subsystem number. Instead, the MSU is sent directly to MTP for routing to the translated point code. If the point code is inaccessible, the MSU is discarded, and a UDTS (unitdata service) message is generated if the return on error option is set.

If an MSU enters the EAGLE and more information is needed to route the MSU (route-on-gt), the signaling connection control part (SCCP) of the SS7 protocol sends a query to a service database to obtain the information. The EAGLE uses the Enhanced Global Title Translation (EGTT) feature of SCCP to determine which service database to send the query messages to.
The EGTT feature uses global title information (GTI) to determine the destination of the MSU. The GTI is contained in the called party address (CDPA) field of the MSU. For gti=4, the GTI is made up of the Numbering Plan (NP), Nature of Address Indicator (NAI), and Translation Type (TT) selectors.
The EGTT feature does a Selector Table lookup based on the selector information extracted. If a match is found, then EGTT is performed on the message. If no match is found in the selector table for this entry, then EGTT performs SCRC error handling on the message.
The EGTT feature decodes the GTA digits and compares the GTA length with the fixed number of digits specified in the ndgt parameter of the ent-gttsel command and expected by the translator. If the number of digits received in the CDPA is more than the number of digits specified in the ndgt parameter, then the EGTT feature considers the leading ndgt digits to perform the translation. If the number of digits received in the CDPA is less than the number of digits specified in the ndgt parameter, then EGTT discards the message and initiates the SCRC error handling.
Note:
If the optional Variable-length Global Title Translation (VGTT) feature is enabled, the EGTT feature allows enhanced global title translation on global title addresses of varying length. For more information about this feature, refer to theVariable-length Global Title Translation Featuresection.
The EGTT feature uses the number of digits received in the CDPA to perform the Translation Table lookup. If a match is found in the database, the translation data associated with this entry is used to modify the message and the resultant message is routed to the next node. If the CDPA GTAI digits are not found in the database, then standard SCRC error handling is performed on this message. Refer to Figure 2-34.
Figure 2-34 EGTT Process

Route on SSN

The “Route on SSN” translate indicator indicates that the point code and SSN is the final destination for the MSU. In this case, the remote point code table is checked to determine the status of the point code and the subsystem number. If the point code or subsystem is unavailable and a backup point code and subsystem is available, the MSU is routed to the backup. Routing to the point codes or subsystems is based upon the data in the remote point code table. There can be up to 31 backup point codes and subsystems assigned to the primary point code and subsystem, thus forming a mated application (MAP) group.

The routing to these backup point codes is based on the relative cost values assigned to the backup point codes. The lower the relative cost value is, the higher priority the point code and subsystem has in determining the routing when the primary point code and subsystem is unavailable. The relative cost value of the primary point code and subsystem is defined by the rc parameter of the ent-map or chg-map commands. The relative cost value of backup point codes and subsystems is defined by the materc parameter of the ent-map or chg-map commands.

There are four routing possibilities for a point code and subsystem number.

Solitary – there is no backup point code and subsystem for the primary point code and subsystem.
Dominant – a group of backup point codes and subsystems exists for the primary point code and subsystem. All the point codes and subsystems in this group have different relative cost values, with the primary point code and subsystem having the lowest relative cost value. All traffic is routed to the primary point code and subsystem, if it is available. If the primary point code and subsystem becomes unavailable, the traffic is routed to highest priority backup point code and subsystem that is available. When the primary point code and subsystem becomes available again, the traffic is then routed back to the primary point code and subsystem.
Load sharing – a group of backup point codes and subsystems is defined for the primary point code and subsystem. All the point codes and subsystems in this group have the same relative cost value. Traffic is shared equally between the point codes and subsystems in this group.
Combined dominant/load sharing – a group that is a combination of the dominant and load sharing groups. A combined dominant/load shared group is a group that contains a minimum of two RC (relative cost) values that are equal and a minimum of one RC value that is different. The traffic is shared between the point codes with the lowest relative cost values, where the relative cost value is considered the relative cost associated with the point code and subsystem of the global title translation and not the actual lowest relative cost in the MAP set. If these point codes and subsystems become unavailable, the traffic is routed to the other point codes and subsystems in the group and shared between these point codes and subsystems.

For each point code, the user has the option of setting the mrc (message reroute on congestion) parameter. The mrc parameter, as well as the other data in the remote point code table, is set with the ent-map or chg-map commands. For more information on the ent-map or chg-map commands, refer to Commands User's Guide.

If the mrc parameter is set to no, and the primary point code is congested, the MSU is discarded, even if a backup point code and subsystem is available. If the mrc parameter is set to yes, and the primary point code is congested, the MSU is routed to the backup point code and subsystem, if it is available. The default value for the mrc parameter is no if the primary point code is an ITU national or international point code, and yes if the primary point code is an ANSI point code.

SCCP Management

SCCP management is responsible for rerouting signaling traffic when network failures or congestion conditions occur.

MTP network management informs SCCP of any changes in point code routing status. Changes in subsystem status are updated by using the subsystem allowed and subsystem prohibited procedures of SCCP management.

SCCP management updates the status of point codes and subsystems. Also, SCCP management broadcasts subsystem allowed and prohibited messages to concerned nodes. The EAGLE supports a broadcast list of up to 96 concerned nodes for each subsystem. This list is configured with the ent-cspc command. For more information on the ent-cspc command, refer to Commands User's Guide.

For ANSI primary point codes, if the backup point code and subsystem are adjacent when the subsystem becomes prohibited or allowed, these messages are sent to the backup subsystem before routing any messages to it:

Subsystem prohibited or allowed message
Subsystem backup routing or subsystem normal routing message

These messages are not required in ITU networks, so if the primary point code is either an ITU national or international point code, these messages are not sent.

Translation Type Mapping

Certain SCCP messages contain a called party address parameter that contains a translation type field. The translation type field indicates the type of global title processing the EAGLE must perform. The values used within any particular network may be different than the standardized values that are defined for internetwork applications.

The translation type mapping feature maps standardized internetwork translation type values to intranetwork translation type values used within any particular network. This feature also maps intranetwork translation type values to standardized internetwork translation type values.

The only SCCP messages that are affected by translation type mapping are UDT and XUDT messages, received or transmitted, whose global title indicator is 0010 (ANSI/ITU) or 0100 (ITU). The translation type will be modified for these messages regardless of whether the destination point code in the MTP routing label is an EAGLE point code and regardless of the SCCP CdPA routing indicator value. Other messages that contain the called party address parameter are not affected. For example, UDTS messages are assumed to be MTP routed and need not be examined. XUDTS messages are either MTP routed or use one translation type value indicating global title to point code translation and should not be mapped.

Translation type mapping is performed on each LIM in the linkset. Incoming translation type mapping is performed on linksets bringing messages into the EAGLE, and is performed before the global title translation function, the gateway screening function, or the MSU copy function associated with the STPLAN feature. Outgoing translation type mapping is performed on linksets carrying messages out of the EAGLE to other destinations, and is performed after the global title translation function, the gateway screening function, or the MSU copy function associated with the STPLAN feature.

When outgoing translation type mapping is configured and the MSU is copied for the STPLAN feature, the copied MSU is mapped. This is done because the mapped translation type may have a different meaning in the local network, causing the MSU to be interpreted incorrectly.

When outgoing translation type mapping is configured and the MSU must be re-routed due to a changeback or signaling link failure, the re-routed MSU could be double mapped. This is a limitation since re-screening or re-translating (with possible incorrect results) can occur by performing the global title translation and gateway screening functions on the mapped MSU. Figure 2-35 shows an example of a translation type that is double mapped.

Figure 2-35 An Example of Double Translation Type Mapping

In Figure 2-35, MSUs on the outgoing linkset LS1 containing the existing translation type (ETT) 251 are mapped to translation type 127 (MTT). MSUs on the outgoing linkset LS2 containing the existing translation type 127 are mapped to translation type 96. Linkset LS1 fails and the traffic is re-routed on linkset LS2. Any outgoing traffic that was on linkset LS1 containing the translation type 251 has been changed to translation type 127. When this traffic is re-routed on linkset LS2, the translation type of the messages that was changed to 127 remains 127 and is not changed back to 251. When the messages are sent over linkset LS2, the existing translation type 127 is changed to translation type 96. This is an example of double mapping a translation type. In this example, the messages leaving network 1 on linkset LS1 were mapped to translation type 127, an “800” translation type. Because of double mapping, that translation type was changed to 96, a “LIDB” translation type. These messages can be routed to the wrong subsystem database; or if gateway screening is configured to screen for these messages, these messages could be discarded before they leave network 1, and network 2 would never receive them.

To help prevent this from happening, configure the incoming traffic on the linkset to map the mapped translation type of the outgoing traffic on that linkset (MTT) to the existing translation type for outgoing traffic on that linkset (ETT). In this example, for incoming traffic on linksets LS1 and LS2, map the existing translation type 127 (the mapped translation type for outgoing traffic on these linksets) to the mapped translation type 251 (the existing translation type for outgoing traffic on these linksets). When linkset LS1 fails, the incoming messages on linkset LS2 containing translation type 127, including those that were mapped to 127 on linkset LS1 and are now being rerouted, are now mapped to translation type 251. When these messages become outgoing messages on linkset LS2, those messages containing translation type 251 are mapped to translation type 127 instead of 96. These messages can then continue to be routed to the proper subsystem database. If gateway screening is configured to screen for and discard messages with translation type 96, the rerouted messages are not effected by the results of the translation type mapping.

If the database transport access feature is being used, and the MSU encapsulated by the gateway screening redirect function contains a translation type that must be mapped on an incoming basis, the encapsulated MSU contains the mapped translation type. The translation type of the new MSU is obtained from the gateway screening redirect table.

The EAGLE supports 64 translation type mappings for each linkset. This includes both incoming and outgoing translation type mappings. EAGLE supports translation type mapping entries for 255 linksets. The maximum number of translation type mappings that can be configured in the EAGLE is 16,320.

The translation type mapping information is configured in the database using the ent-ttmap, chg-ttmap, dlt-ttmap, and rtrv-ttmap commands.