In this section:

GTT Databases

Global Title Translation provisioning is handled by two databases (DBs), Workspace and Live. The Workspace DB is a working area used to add, modify, and delete translation information without affecting the GTT traffic processing. When the Workspace DB is provisioned as required, the Workspace DB can be committed to the Live DB to put all changes into affect. In the Web UI, the Live DB is a read-only representation of the current translation information used by the SS7 traffic. The Live DB can only be updated by committing the Workspace DB to the Live DB.

Each DB contains the following tables (or lists) which in turn contain individual records:

  • GT Called Searches

    • GT Called Search (Records)

  • GT Calling Searches

    • GT Calling Search (Records)

  • GT OPC Searches

    • GT OPC Search (Records)

  • GT Modifications

    • GT Modification (Records)

  • Command Lists

    • Command List
      • Command List Records
  • PC Lists

    • PC List
      • PC List Records

When an MSU set for Global Title routing is received, the records contained in these tables are searched to obtain a new destination for the MSU and to optionally change or modify various MSU parameters as required.

For class 0 MSUs, which have no same destination requirement, a random seed is used to loadshare the traffic.

For non-class 0 MSUs, if the GTT DB Def PC List Loadshare is set to TCAP Transaction ID (TID), the MSU's TID value is used as the loadshare key if present. The MSU's SLS value is used if the TID is not present, or if the GTT DB Def PC List Loadshare is set to SLS.


GT Standard Search (Called)

An incoming SCCP message from the SS7 network is routed through the Message Transfer Part 3 (MTP3) based on the destination point code (DPC) of the MSU, and then to the SCCP based on the service indicator (SI) of the MSU. The SCCP PC must already be registered with MTP3 before the MTP3 can send the message to SCCP. Incoming MTP3 and SCCP IP user traffic (for example, M3UA and SUA) can also be sent to GTT.

The SCCP examines the Called Party Address’ Global Title contained in the SCCP message. If the Global Title routing option is set in the Called Party Address, then the SCCP queries the GTT database for new routing information for the message. The GTT queries its GT Called Searches table based on the associated NA DB Definition for a matching combination of some or all of the Global Title components found in the Called Party Address parameter. These components can be

  • Digits - Global Title Address Information (GTAI) (mandatory for any search)

  • Global Title Indicator (GTI): 4-bit field that identifies the presence and format of the GT (optional)

  • Numbering Plan (NP): 4-bit field that identifies the digit format used in the GT (optional)

  • Nature of Address (NAI): 7-bit field that identifies the nature of the digits in the GT (optional and only applicable for ITU)

  • Translation Type (TT): 8-bit field that identifies the GT-related network services (optional)

  • Sub-system Number (SSN): 8-bit field that identifies the service to address GT-related special routing cases or MSU service interceptions.

When multiple GT Called Searches with overlapping attributes are configured on a system, the GT Called Search with the best match is selected. For more information on how GT Called Searches Records are selected, see  GT Search Best Match Selection Criteria.

If the search is unsuccessful, then the system’s error handling component processes the message. If the database definition has been configured with a Default PC List Name and an associated PC List Record, then the message is sent to the default destination for further processing. If no default PC List Name is configured, the message is dropped or a Unitdata Service (UDTS) message is returned if the SCCP protocol class was set to return on error.

If the search is successful, GTT uses the PC List associated with the matching GT Called Search to determine the new destination for the resulting message. Each PC List contains one or more PC List Records which includes its relative cost. The SCCP uses the lowest cost destination depending on the availability of the destination, and then forwards the message to MTP3 or an SCCP IP user (for example, SUA) for final routing.

The GT Called Search may optionally be associated with a GT Modification in addition to a PC List. The message Called Party Address parameter is changed according to the GT Modification attributes, then sent to the destination selected by SCCP. If applicable, the GT Modification can be provided with additional digit modification instructions when it is associated with a GT Command List. Up to five GT Command Records can be contained in a GT Command List, each of which represents an individual command that deletes or adds to the digits contained in the SCCP Called Party Address GTAI field.

GT Advanced Search (Called, Calling, and OPC)

The advanced search feature enhances the DSC Platform’s ability to control traffic. It allows GTT to consider the Calling Party Address parameter of an SCCP message and the Originating Point Code (OPC) of the MTP3 routing label when processing a message and selecting a new destination. The optional GT Modification and GT Command List can also be associated with a GT Calling Search.

Entry reference points (EPRs) group GT Calling Searches and GT OPC Searches to provide a means of linking the search tables. The search tables are linked from the GT Called Search, to the optional GT Calling Search, and then to the optional GT OPC Search. The same EPR can be assigned to multiple GT Calling Searches and GT OPC Searches.

The EPR values support alphanumeric (forced to upper case) strings that have a maximum size of four characters. The EPR value UNDEFINED (0) is excluded from the maximum size validation.

When the Called Party Address parameter of an SCCP message has been matched to a GT Called Search, GTT looks for an EPR to a GT Calling Search. If no EPR is found, GTT uses the Point Code List associated with the GT Called Search, if defined, to find the appropriate destination for the message.

Note

For a GT Called Search, either a PC List Name or an EPR to a GT Calling Search must be applied. Both cannot be applied at the same time. However, it is possible for two GT Called Searches to be configured with identical attributes, where one would have an associated PC List, and the other would have an EPR to GT Calling Searches. In this case, the EPR would be searched first, and if no match was found in the GT Calling Search, or an associated GT OPC Search, then the PC List of the matching GT Called Search without the EPR would be used.

If an EPR to a GT Calling Search is found, the Calling Party Address parameter of the SCCP message is compared to the GT Calling Searches for that EPR. If the attributes match, GTT looks for an EPR to a GT OPC Search. If no EPR is found, GTT uses the Point Code List associated with the GT Calling Search, if defined, to find the appropriate destination for the message.

Note

For a GT Calling Search, either a PC List Name or an EPR to a GT OPC Search must be applied. Both cannot be applied at the same time. However, it is possible for two GT Calling Searches to be configured with identical attributes, where one would have an associated PC List, and the other would have an EPR to GT OPC Searches. In this case, the EPR would be searched first, and if no match was found in the GT OPC Searches, then the PC List of the matching GT Calling Search without the EPR would be used.

If an EPR to a GT OPC Search is found, the OPC of the MTP3 routing label is compared to the GT OPC Searches for that EPR. If the OPC matches the OPC range of the GT OPC Search, GTT uses the Point Code List associated with the GT OPC Search to find the appropriate destination for the message.

Note

A GT search is considered successful when a destination PC List is found from one of the three GT search tables. The GT search is considered unsuccessful, for example, when the initial GT Called and Calling Searches finds an EPR match, but the associated GT OPC Search fails. From a conceptual perspective, the GT Called, Calling, and OPC Searches are really one GT search that looks at three different parts of an SS7 message.

If the search is unsuccessful, then the system’s error handling component processes the message. The advanced search feature applies the standard search error handling (see GT Standard Search (Called)).

For a successful advanced search, GTT applies the standard search SCCP routing (see GT Standard Search (Called)).

A GT Modification can be associated to either the GT Called Search and the GT Calling Search, or both. Any associated GT modifications are applied when a successful search occurs.

GT Search Best Match Selection Criteria

A GT Search is selected based on the best match between the configured GT search attributes and the SS7 message parameters. The following table shows the order in which the GTT considers the attributes of an SS7 message when determining the best match for a Global Title Translation (GTT).

GT Search Attribute Match Order

Attribute Match Order (First)GT Called SearchGT Calling SearchGT OPC Search

|

|

|

|

|

|

|

|

|

|

|

|
V

SSN  
GTI
NP
NAI
minimum and maximum digit range
Calling EPR (if defined)1
------------------->

EPR

 

SSN
GTI
NP
TT
minimum and maximum digit range

OPC EPR (if defined)2
------------------->


EPR
OPC range3
Attribute Match Order (Last)

1 If the GT Calling Searches EPR is undefined or does not resolve into a match, then the message uses, if defined, the PC List in the matching GT Called Search record. Otherwise, the message uses the Default PC List in the associated GTT DB Def. If neither are defined, a GTT failure is returned to the SCCP. The Called Party Global Title may also be optionally modified by the GT modification record.

2 If the GT OPC Searches EPR is undefined or does not resolve into a match, then the message uses, if defined, the PC List in the matching GT Calling Search record first and the PC List in the matching GT Called Search record second. Otherwise, the message uses the Default PC List in the associated GTT DB Def.  If none are defined, a GTT failure is returned to the SCCP. The Calling Party Global Title may also be optionally modified by the GT modification record.

3 The PC List associated with a successful GT OPC Search is always applied.

For GT Called and Calling Searches, the minimum and maximum digit range must be specified (see GT Called and Calling Search Digit Range Selection for more details) and either a PC List Name, or the EPR of the next GT search. All other attributes can be set to translate on any value; however, if a value is defined, the preceding table shows the order in which these values are considered when determining the best match for a GT search. All attributes in the GT OPC Search are mandatory.


GT Called and Calling Search Digit Range Selection

The leading digits (the first set of defined digits) of a GT Called or Calling Search are used to achieve a match with the called or calling digits contained in an SCCP message. A GT search with more provisioned digits takes precedence over GT searches with fewer digits if both search ranges overlap.

The GT Searches must be provisioned with a minimum and maximum digits range of the same length. Internally, the minimum and maximum digits are represented as 32 digit numbers, regardless of how many digits are actually entered in the GT search. This is achieved by logically converting minimum digits and maximum digits into 32 digit numbers. The minimum digit is converted to a 32 digit number by adding zeros on the right (6132370000…). The maximum digit is converted to a 32 digit number by adding 9s or 0xFs (depending on the national variant) on the right (61327FFFF....).

For example, the range minimum digits = 613 and maximum digits = 615 in ANSI are logically represented as the range of 32 digit numbers

61300000000000000000000000000000

to

61599999999999999999999999999999.

The digits contained in an SCCP’s Called or Calling GTAI match the GT Search if these digits are within the range of the GT search.

Example 1

  • GT Calling Search is provisioned with the following range: minimum digits = 613, maximum digits = 615.

In this example, the GT Calling Search matches an SCCP message’s Calling GTAI that contains leading digits 613, 614 or 615.

Example 2

  • GT Called Search 1: minimum digits = 613, maximum digits = 614

  • GT Called Search 2: minimum digits = 6135, maximum digits = 6137

  • Received digits contained in the SCCP’s Called GTAI: 6135875555

In this example, two GT Called Searches have an overlapping range of digits. In this case, the range with the most digits has precedence. Therefore, an SCCP message with called digits 6135875555 matches both provisioned search records, but GT Called Search 2 takes precedence because this record has more digits.

Example 3

  • GT Called Search 1: minimum digits = 613, maximum digits = 614

  • GT Called Search 2: minimum digits = 6130, maximum digits = 6133

  • GT Called Search 3: minimum digits = 61310, maximum digits = 61330

In this example, if the incoming GTAI contains

  • digits 613 matches the GT Called Search 1

  • digits 61345 matches the GT Called Search 1

  • digits 6132 matches the GT Called Search 2

  • digits 61320 matches the GT Called Search 3

  • digits 61, there is no matching GT Called Search.

You must remember, however, that there are some additional limitations for GT Searches that are using ranges (see  Limitations for GT Searches Using a Range of Digits).

Limitations for GT Searches Using a Range of Digits

The maximum number of digits in GT Search range entries are 32 for both the minimum digits and the maximum digits. For range value limitations, see the following table:

Range Validation Examples

Range 1Range 2Result

minimum digits: 613

maximum digits: 614

N/AValid. Both digits 6131 and digits 6149 would match.

minimum digits: 613

maximum digits: 613

N/AValid. Same as a single value prefix match (wildcard for 613* would match 6131).

minimum digits: 613

maximum digits: 614

minimum digits: 615

maximum digits: 616

Valid. Ranges do not overlap.

minimum digits: 613

maximum digits: 616

minimum digits: 6141

maximum digits: 6151

Valid. While the ranges overlap, range 2 has more digits, hence, takes precedence.

minimum digits: 614

maximum digits: 613

N/AInvalid. minimum digits must be a lower value than the maximum digits

minimum digits: 613

maximum digits: 614

minimum digits: 614

maximum digits: 616

Invalid. Ranges overlap. 6141 would match both ranges.

minimum digits: 613

maximum digits: 616

minimum digits: 614

maximum digits: 615

Invalid. Ranges overlap. Should be entered as three non-overlapping ranges or more digits should be entered in range 2.

minimum digits: 6141

maximum digits: 6172

minimum digits: 4131

maximum digits: 6161

Invalid. Ranges overlap.

minimum digits: 613

maximum digits: 6161

N/AInvalid. The minimum and maximum digits do not have the same number of digits.

Translation Tables Provisioning Order

To add new translation information such as PC Lists, or GT Searches, the translation integrity must be maintained. For example, a GT Called or Calling Search cannot reference a non-existent GT Modification. Therefore, the order in which these objects are created and provisioned is important.

The following figure shows the translation tables dependencies and provisioning order for GT searches:

GT Searches Dependencies and Provisioning Order

Observed the following order when provisioning a GT Search:

  • Create the PC List and PC List Record(s) for the GT OPC Search (if required and not already defined).

  • Create the GT OPC Search, if required, and associate it with the PC List.

  • Create the GT Modification with its Command List for the GT Calling Search if required.

  • Create the GT Calling Search, if required, and associate it with the EPR of the GT OPC Search (or a PC List if GT OPC Search is not required) and the optional GT Modification.

  • Create the GT Modification with its Command List for the GT Called Search if required.

  • Create the GT Called Search, and associate it with the EPR of the GT Calling Search (or a PC List if GT Calling Search is not required) and the optional GT Modification.
Note

GT Calling and OPC Searches are optional.

A PC List Name cannot be configured in GT Called and Calling Searches if an EPR is entered.

PC List Final Routing

The PC List Records with the lowest available cost are used to loadshare the traffic. If there is more than one lowest cost available, then the weight is considered.

For example, in the following figure, GTT PC List Identical Weight Loadshare Example, the traffic is proportioned at 33% if each of the first three point codes have a lowest available cost of 10 and a weight of 1. The fourth point code with a cost of 20 has no traffic because the cost is higher than the lowest available. The higher cost is only used if all the lowest cost destinations are unavailable.

GTT PC List Identical Weight Loadshare Example

 


If the three lowest costs are available, the traffic is proportioned as 10%, 30%, and 60% according to the specified PC List (see the following figure).

GTT PC List Weighted Loadshare Example

When the third destination is unavailable, the traffic is proportioned as 25%, 75%, and 0% according to the specified PC List (see the following figure.

GTT PC List Weighted Loadshare With Unavailable Destination Example

Using Autocomplete

The Autocomplete feature in the Web UI assists you to provision certain GTT and DSC objects by giving value suggestions in some of these objects' attribute drop-down lists. For more information about this feature, refer to the appropriate section in the Web UI and Menu UI Guide.

Filtering

The GTT database tables can contain thousands of records (see GTT Capacity).

If required to manage a large number of records for Point Code Lists, GT Modifications, Command Lists, and GT Searches (see GTT Capacity), use the GTT Web UI filter capabilities. The Web UI filters large number of these database records based on criteria you define in the Web UI, takes a snapshot of these records, and displays the filtered information in the Web UI for your use.

There are two ways to access a filter table – as a SS7ADMIN user with read/write access or as a monitor user with read-only access.

Note

A maximum of 16 concurrent users can access a filtered table, but only one of the 16 can have the read/write access.  Non-monitor users have the ability to enter the table in read-only access if the read/write access is already in use.

A total of 96 sessions are allowed to access the filtered tables in GTT.

Beyond the 96 user maximum on the GTT, there is always a minimum of one read/write or read-only session guaranteed per table.

Multiple tabs do not equal multiple sessions; however, opening different browsers does create multiple sessions.

Monitor users and users selecting read-only access can only filter up to a maximum of 2,000 records. If the output of the criteria exceeds this maximum, an error will be returned requesting a fine-tune of the criteria for a more restricted output.

 

If you access a filtered table as a read/write user, the Web UI locks the given table until you complete your task. Clearing this lock may take place in the following three ways:

  • after you back out of the filtered table, the Web UI automatically unlocks this table

  • if more than an hour has passed since any activity has occurred

  • another read/write user unlocks the filtered table in the Web UI

If another read/write user wants to unlock the table, the Web UI displays a caution message that the respective filtered table is locked by <username of current read/write user> and unlocking this table forces the release of the table. If the new user only wants to view the GTT, there is an option to continue with Read Only access as a monitor user. Otherwise, the user can force an unlock in order to edit the table. See the following figure:

Example of a locked warning message

When filtering GTT database records, one of the criteria is the DB Def Name. If you do not set the DB Def Name attribute on the respective filter screen, the GTT returns records from all the defined GTT DB Defs that match the criteria. For more information about database definitions, refer to Configuring the GTT DB Def Manager.

Filtered information is usually associated with other records or lists from different tables. The Soft Link feature helps link related filtered records and lists across multiple database tables for the GTT application. The Soft Link (displayed as an arrow on the Web UI, see the following figure) is created between a record or list according to the creation and provisioning hierarchy of the GTT application. As a result, Soft Links have a one-way relationship between database records and lists. For example, a GT Called Search record may have attributes, such as PC List Name, GT Calling Searches EPR, and GT Modification Name, that link to one or multiple records in a different table.

GTT Soft Link Example

Note

Soft Links do not appear in the Web UI if there is no record or table to link to the attribute. In the preceding figure, the GT Calling Searches EPR attribute has no associated Soft Link because it is set to UNDEFINED.

In the GTT filter screens, any filtered objects with related records act as soft links (see the following figure).

GT Called Searches Filtering Example

For GTT, links to records or lists are retrieved using the DB Def Name and one of the following attributes:

Note

The selected attribute depends on the originating record.

  • PC List Name
  • GT Modification Name
  • GT Calling Searches EPR
  • GT OPC Searches EPR
  • Command List Name

If the table owning the linked record or list of records is locked, a warning message appears requesting the user decide to continue with read only access or to unlock the table, forcing the release of the table from the current user who is viewing or editing a record in the table.

Note

After clicking a filtered Soft Link selection, the back button cannot be used to return to the originating record. To get back to the originating record, a new filter must be applied on the given table. This filter application can trigger the lock warning prompt if that table is in use by another user.


  • No labels