Transaction-Based GTT Load Sharing

Transaction-Based GTT Load Sharing allows messages with the same transaction parameters (TCAP, SCCP, MTP, or ENHMTP parameters) to be routed to the same destination within an entity set. An entity set is a group of entities that are used to determine the proper destination of a post-GTT message. This group of entities can be one of the following:

• A mated application (MAP) group
• A mated relay node (MRN) group
• A mated application set (MAPSET), if the Flexible GTTLoad Sharing feature is enabled
• A mated relay node set (MRNSET), if the Flexible GTTLoad Sharing feature is enabled.

This feature applies to the following types of SCCP messages:

• UDT/UDTS class 0 messages
• UDT/UDTS class 1 messages
• XUDT/XUDTS class 0 messages
• XUDT/XUDTS class 1 messages.

UDT/UDTS and XUDT/XUDTS messages are loadshared using a key derived from these elements in the message.

• MTP parameters - the first 3 bytes of the incoming OPC and 1 byte of the SLS.
• SCCP parameters - the last 4 bytes of the global title address field of the called party address.
• TCAP parameter - the TCAP Transaction ID in the messages.
• Enhanced MTP parameter - a combination of the SLS and the incoming OPC values.

The parameters used for Transaction-Based GTT Load Sharing are selected using the chg-sccpopts command. These parameters are:

• :tgtt0 – enable or disable Transaction-Based GTT Load Sharing for SCCP Class 0 UDT, UDTS, XUDT, or XUDTS messages.
• :tgtt1 – enable or disable Transaction-Based GTT Load Sharing for SCCP Class 1 UDT, UDTS, XUDT, or XUDTS messages.
• :tgttudtkey – the Transaction Parameter for the incoming UDT or UDTS messages.
• :tgttxudtkey – the Transaction Parameter for the incoming XUDT or XUDTS messages.

Figure 2-3 describes how the Transaction-Based GTT Load Sharing SCCP options are used.

Figure 2-3 Transaction-Based GTT Load Sharing SCCP Options

For more information on provisioning the Transaction-Based GTT Load Sharing option parameters, refer to the Changing the Transaction-Based GTT Load Sharing Options procedure.

Only load shared and combined dominant/load shared entity sets are used to determine the routing for messages that are processed by the Transaction-Based GTT Load Sharing feature.

Using a load shared entity set, the entire entity set is a part of one RC group and the messages are load-shared based on the Transaction Parameter in the entities in the entity set. If none of the entities in the entity set are available for routing, then the message is discarded and a UDTS/XUDTS message is generated if "Return on Error" is set in the SCCP message. A UIM is generated indicating that the message has been discarded.

Using a combined dominant/load shared entity set, the RC group containing the point code, or point code and SSN, obtained as a result of the global title translation process is used to determine how the message is routed. If none of the entities in this RC group are available for routing, the next higher cost RC group is chosen. This is repeated until an entity in an entity set is available for routing. When an entity is found that is available for routing, the message is routed according to the criteria in that entity. If none of the entities in the entity set are available for routing, the message is discarded. A UDTS/XUDTS message is generated if “Return on Error” is set in the SCCP message. A UIM is generated indicating that the message has been discarded.

Once the MSU key is generated, it is passed to to the Weighted GTT Load Sharing mode entity sets to determine how the message will be routed. If the Weighted GTT Load Sharing feature is active and weights have been assigned to the entity set, the Weighted GTT Load Sharing feature uses these weights to determine how to route the message. If no weights have been assigned to the entity set, then each RC group in the entity set is considered to be equally weighted.

Static routing is performed on all the messages that the Transaction-Based GTT Load Sharing feature has assigned an MSU key. Static routing always assigns an MSU key to the same node within an RC group. If static routing does not provide an available entity for routing the message, dynamic routing is used to find an available entity for routing the message. Figure 2-4 illustrates this process.

Figure 2-4 Message Routing using Transaction-Based GTT Load Sharing

Provisioning the Transaction-Based GTT Load Sharing Feature

To provision the Transaction-Based GTT Load Sharing feature, perform these steps.

1. Turn the GTT and EGTT features on using the chg-feat command. Add the required DSMs or SLIC cards to the database using the ent-card command. Perform Adding a Service Module.
2. Enable the Transaction-Based GTT Load Sharing feature using the enable-ctrl-feat command. Perform the Activating the Transaction-Based GTT Load Sharing Feature procedure.

   Note:

   The Transaction-Based GTT Load Sharing feature can be turned on in this step using the chg-ctrl-feat command. If the Transaction-Based GTT Load Sharing feature is not turned on in this step, provisioning for the Transaction-Based GTT Load Sharing feature can still be performed. When the provisioning is completed, the Transaction-Based GTT Load Sharing feature can be turned on. The Transaction-Based GTT Load Sharing feature will not work until the feature is turned on either in this step or step 4.
3. Change the Transaction-Based GTT Load Sharing options, if desired, using the chg-sccpopts command. Perform the Changing the Transaction-Based GTT Load Sharing Options procedure.
4. Turn the Transaction-Based GTT Load Sharing feature on using the chg-ctrl-feat command. Perform the Activating the Transaction-Based GTT Load Sharing Feature procedure.