How to Identify a Misconfigured Point Code in Global Title Translation
Global Title Translation (GTT) connects subscriber-facing addresses with the signalling destinations that handle them. A small error in a point code, translation type, or subsystem number can send TCAP queries to the wrong node, create routing loops, or cause intermittent failures that are difficult to distinguish from congestion.
In SS7 and SIGTRAN environments, the investigation must follow the complete path: Global Title, translation rule, point code, route set, linkset, and application response. This is especially important in Australian networks, where traffic may cross large geographic areas between Sydney, Melbourne, Perth, Brisbane, and regional exchanges.
What a Point Code Does in GTT
A point code identifies an SS7 signalling node, such as a Signal Transfer Point (STP), service control point, mobile switching centre, or signalling gateway. GTT uses information in a Global Title—often a telephone number, IMSI, or network-specific address—to select a destination point code and, in some cases, an SCCP subsystem number.
The point code itself is meaningful only within the relevant signalling network and numbering format. An international point code, national point code, and signalling point code represented in decimal or hexadecimal may look similar in a log while referring to different destinations. A mismatch between these formats is a common source of false routing.
Recognising the Symptoms
A misconfigured point code often appears as a routing failure rather than an obvious configuration alarm. SCCP Return Cause values such as “no translation for address of such nature” or “subsystem failure” can indicate a GTT problem, although congestion and unavailable destinations can produce related symptoms.
Look for repeated failures from one Global Title range, sudden changes after a routing update, or traffic reaching a node that should never receive the query. A TCAP transaction may leave the originating application correctly, yet receive an unexpected abort or no response. Reviewing TCAP database queries helps separate application faults from signalling-layer routing errors.
Trace the Translation Decision
Start with the exact digits and parameters received by the SCCP translator. Record the Translation Type, Numbering Plan, Nature of Address Indicator, encoding, and whether the address is even or odd. A rule that expects an international E.164 format may fail when the input contains a national prefix or a leading zero.
Next, follow the selected rule to its destination point code and subsystem number. Compare the live configuration with the intended routing design, including primary and backup destinations. In a multi-vendor environment, confirm that one platform has not interpreted a field differently from another.
Check Point Code Format and Scope
Verify that the point code uses the correct structure for the network in which it is advertised. ITU-T, ANSI, and national variants have different bit layouts, and a point code copied from one system into another can become a valid-looking but incorrect value.
Australian operators may also maintain separate domestic and international signalling domains. A route intended for a national STP in Sydney could be mistakenly represented as an international destination, while a gateway in Melbourne may reject or misroute it. Check the configured network indicator and the point-code display convention before changing any rule.
Confirm Route Availability
A correct GTT result still fails if the destination point code is absent from the routing table, prohibited by a management action, or unavailable through the chosen linkset. Inspect MTP3 route status, linkset state, adjacent signalling points, and any restricted-route indicators.
For SIGTRAN, trace the equivalent path through SCTP association, application server, application server process, and routing key. A point code can be correctly translated at SCCP while the M3UA layer sends it towards an unavailable or wrongly defined signalling endpoint.
Use Focused Checks During an Incident
Capture a small, representative sample rather than beginning with every message in the network. Correlate the original Global Title, translated address, destination point code, SCCP result, and TCAP transaction identifier. This makes it easier to prove whether the translation changed as expected.
Useful checks can be grouped into configuration evidence and packet evidence.
Configuration evidence
- Global Title digits and translation type
- Numbering plan and nature of address
- Destination point code and subsystem number
- MTP3 route, linkset, and network indicator
Packet evidence
- SCCP Called Party Address
- MTP3 destination and originating point codes
- M3UA routing context and SCTP association
- Return cause, timeout, or TCAP abort
For production work, take a configuration snapshot before making edits. This is particularly important when a carrier network supports services across Sydney, Melbourne, and remote areas, where a local-looking fix can affect national roaming or inter-operator traffic.
Distinguish Similar Faults
Several signalling faults resemble a bad point code. A wrong subsystem number may deliver traffic to the correct node but to an inactive application. A missing route may produce the same user-facing timeout as an invalid translation. A firewall or SCTP issue can also prevent a correctly addressed message from reaching its destination.
Use controlled tests from more than one origin and compare successful and failed Global Titles. Consult the operator’s signalling solutions resources when mapping legacy SS7 behaviour to IP-based signalling components, particularly where STPs and signalling gateways coexist.
Compare Evidence Before Changing Configuration
The strongest diagnosis comes from comparing the intended design, the live rule, and an actual trace. Do not rely on a management interface label alone; export the underlying values and confirm how the platform encodes each address.
| Evidence | Expected result | Likely fault when different |
|---|---|---|
| Global Title format | Correct digits and indicators | Input normalisation or GTT rule error |
| Translation output | Intended point code and SSN | Wrong rule, prefix, or numbering plan |
| MTP3 route | Reachable destination | Missing, restricted, or stale route |
| M3UA path | Active association and routing key | SIGTRAN configuration fault |
| SCCP response | Valid return or application reply | Unavailable subsystem or downstream failure |
A practical next step is to capture one failed SCCP message, write down its Global Title and translated point code, and compare those values with the active GTT rule and MTP3 route.
