SCCP global title translation to point code and SSN
SCCP connectionless service lets signaling nodes exchange messages without establishing a persistent logical connection. Its called-party address may contain a Global Title (GT), while the routing label identifies the destination signaling node and application. The key operation is Global Title Translation (GTT), which turns global number information into a point code and Subsystem Number (SSN).
That separation is central to SS7 engineering: the GT describes the intended service or subscriber, the point code locates a node in the signaling network, and the SSN selects a function inside it. Sigtran carries the signaling stack over IP, but it does not remove the need for accurate numbering and translation.
How connectionless SCCP finds a destination
SCCP connectionless service uses messages such as Unit Data to send signaling independently, without maintaining connection state between exchanges. MTP3 provides the underlying message transport, while SCCP adds addressing and service selection. ISUP call-control information and other application traffic can then move toward the appropriate destination node.
Global Title Translation normally takes place in a Signaling Transfer Point (STP). The STP examines the called-party address, consults its GTT configuration and derives the point code and SSN required for onward routing. The SS7 training modules provide a structured way to study this routing process and the related protocol layers.
Global title translation mechanics
A GT contains digits interpreted within a numbering plan. It may represent a subscriber, service or other logical destination, but it is not itself a signaling-node address. A GTT procedure can match a digit prefix or range alongside additional selectors, allowing one translation configuration to cover many numbers.
The resulting mapping commonly supplies a point code and SSN in the SCCP routing label. Depending on the operator’s procedure, the original GT may remain in the called-party address or be replaced by translated digits. The essential distinction remains: the GT identifies the numbered destination, the point code identifies where signaling goes, and the SSN identifies what service receives it there.
Point codes, SSNs, and delivery roles
A point code operates at the MTP routing level and identifies a signaling node within an operator’s network. Its format and length are implementation-specific, so it should never be confused with a consumer telephone number. The SSN, also called the service subsystem number, identifies an SCCP service or application class at that node. An optional subsystem field can distinguish a particular instance further.
| Element | Primary purpose | Routing significance |
|---|---|---|
| Global Title | Identifies a numbered subscriber or service | Provides the input used by GTT |
| Point Code | Identifies the destination signaling node | Directs MTP3 and SCCP forwarding |
| Subsystem Number | Identifies an SCCP service or application | Selects the receiving function at the destination |
| Optional subsystem | Distinguishes a particular service instance | Refines application-level delivery |
Once the destination is selected, MTP3 transports the signaling toward the point code, and SCCP uses the SSN to determine the receiving function. A valid point code paired with an incorrect SSN can therefore produce a different symptom from an incorrect point code: the signaling reaches the right node but the intended application is unavailable.
Australian numbering and GTT context
Australian destinations require careful normalisation. International numbering uses the country code +61, while domestic calls commonly use a leading zero. Sydney uses 02, Melbourne 03, Brisbane 07 and Perth 08; mobile numbers normally begin with 04. Australian users tend to say “mobile” and “landline”, although technical documentation may call a mobile subscriber number an MSISDN. Conversion between 0400…, +61400… and other received formats should be tested before it drives a GTT lookup.
Service numbers such as 1300 and 1800 are not geographic and require separate treatment from fixed-line area codes. Australia’s retail mobile market also includes MVNOs that operate over a host network, so the signaling path may depend on which infrastructure carries the message. Mobile Number Portability adds another layer: a basic GTT lookup should not be confused with the operator number-portability database or redirect procedure used for a ported destination.
These numbering rules need consistent documentation, particularly where engineers and partners handle different examples. A blog publishing guide can help technical teams present normalisation requirements and routing examples clearly without exposing live subscriber data.
Security and translation verification
A controlled translation test begins with the inputs and the expected destination:
- Confirm the called-party digits and normalisation, including
+61and national-prefix handling. - Check the GTT selector, digit range, match priority and any overlapping entries.
- Reconcile the mapped point code, SSN and optional subsystem with the destination inventory.
- Confirm MTP3 routing and the receiving application’s readiness.
Captured SCCP traces can expose MSISDNs and other subscriber information. The user-part masking guide describes how STPS output can conceal sensitive portions while retaining enough digits for correlation. Masking should affect operational views and exports, not the values used for actual routing.
The observed failure can indicate where the translation chain broke:
- No GTT match occurs, or the STP rejects the request.
- Traffic reaches the correct node but the SCCP application refuses it.
- Signaling is sent to a valid but unintended point code.
- Intermittent misses result from inconsistent normalisation or overlapping ranges.
Controlled rollout and final validation
Build the change in a lab using representative synthetic numbers for international, mobile, geographic and non-geographic destinations. Test both active STPs and compare their GTT mappings, routing results and downstream responses. A small canary set can then reveal differences between laboratory assumptions and production signaling without exposing the entire network to an incorrect translation.
The next concrete step is to export one sanitised GTT entry from the test STP, verify its point code and SSN against the destination application inventory, and attach that evidence to the change record before any production update.
