Oracle® Communications EAGLE Database Administration - GTT User's Guide Release 46.7 E97332-02 |
|
![]() Previous |
![]() Next |
The signaling connection control part (SCCP) is divided into two functions:
Figure 2-30 shows the relationship of these two functions.
Figure 2-30 Logical View of SCCP Subsystems
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.
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:
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:
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:
Each GTT Selector table contains these fields:
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.
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:
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.
gti=4
, the GTI is made up of the
Numbering Plan (NP), Nature of Address Indicator (NAI), and Translation Type
(TT) selectors.
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.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.
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:
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.