SCCP routing control with SSN and GT combinations
Signalling Connection Control Part (SCCP) adds addressing and routing capabilities above MTP3 in an SS7 network. Its routing controls determine whether a message should travel to a known point code, a subsystem, or a destination identified through a Global Title.
The Subsystem Number (SSN) identifies an application or service at a signalling point. A Global Title (GT), by contrast, is an address that can be translated into a point code and SSN. Used together, they allow networks to route signalling traffic even when the originating node does not know the final destination’s signalling point.
This distinction matters in mobile networks, roaming, number portability, SMS delivery, and database queries. A message may arrive with a GT such as a mobile subscriber number, then be translated into a destination point code plus an SSN for an HLR, SMSC, or another application.
For Australian engineers, the model applies across national carrier networks linking Sydney, Melbourne, Brisbane and regional exchanges. Mobile users commonly change operators while retaining their number, and SS7 routing must account for portability, inter-carrier boundaries, and the country code +61.
What SCCP actually routes
MTP3 forwards traffic using a destination point code (DPC), but that address identifies a signalling point rather than a specific service. Several applications can share the same signalling node. SCCP resolves this limitation by adding subsystem addressing and optional GT translation.
The Called Party Address contains routing indicators, point-code information, an SSN, and GT details where required. A routing indicator tells SCCP whether to use the point code and SSN directly or perform Global Title Translation first. This makes SCCP suitable for distributed databases and mobile services.
An SSN is generally a numeric service identifier. Common examples include ISUP-related signalling, HLR and VLR functions, EIR services, and SMS applications. Exact assignments can vary by standard family, operator implementation, and national network design, so engineers should validate values against the applicable ITU-T, ETSI, or 3GPP documentation.
How SSN and GT work together
A message routed directly by SSN usually contains a point code and SSN. This approach is efficient when the sender already knows the destination signalling point. It is common inside a controlled network where routing tables are stable and the application address is locally understood.
GT routing is used when the sender has a logical address rather than a network location. The GT may contain digits, a translation type, numbering plan, and nature of address indicator. A translation service examines those fields and returns a destination point code, SSN, or a revised GT for another translation stage.
For example, an SMS-related query may carry a subscriber number as a GT. The signalling transfer point can inspect the country code and operator prefix, identify the correct home database, and forward the message using the destination point code and the relevant SSN. The receiving application can then process the request without exposing its internal network topology.
Building GT translation rules
A GT translation table should define the numbering plan, nature of address, translation type, digit format, and expected SSN. It should also specify the permitted source point codes, destination point codes, and action when no match exists. Prefix rules need careful ordering because a broad match can capture traffic intended for a more specific operator or service.
Australian numbering requires particular care. The ACMA numbering framework, mobile number portability, and carrier interconnection arrangements mean that a number prefix may not always reveal the subscriber’s current network. Translation logic may therefore depend on portability databases or carrier-controlled routing data rather than a simple prefix list.
Training material on protocol fields, signalling flows, and routing cases is available through structured SS7 training, which can help engineers connect SCCP theory with packet traces and configuration examples.
Australian deployment considerations
A national network may carry traffic between metropolitan signalling points and regional or remote locations where alternate routes are limited. An outage affecting a Melbourne STP pair, a Sydney interconnect, or a long-haul link to Western Australia can expose weak assumptions about route redundancy and translation failure handling.
Emergency communications and lawful access obligations also influence operational controls. The Telecommunications (Interception and Access) Act 1979 and the Privacy Act 1988 create a need for disciplined access to signalling records, subscriber identifiers, and trace data. Logging should support fault analysis without creating unnecessary exposure of personal information.
Number formatting is another frequent source of errors. Australian mobile numbers are commonly represented nationally with a leading zero, while international signalling uses country code +61 and removes that domestic prefix. A GT rule that accepts only one representation can cause translation failures or misrouting across carrier boundaries.
Security and operational risks
GT translation is a security boundary because it determines where sensitive signalling requests are sent. Unrestricted transfer of SCCP messages can enable subscriber enumeration, location queries, SMS interception attempts, or unauthorised access to mobility databases. Screening should consider source point code, GT pattern, SSN, message type, and traffic direction.
Operators commonly use SCCP screening, signalling firewalls, rate limits, and anomaly detection. Rules should reject malformed addresses, unexpected translation types, invalid numbering plans, and requests from unauthorised networks. A valid-looking GT is not sufficient evidence that the source is trusted.
Operational teams should monitor translation misses, abnormal response codes, sudden changes in GT volume, and repeated requests for the same subscriber range. Timeouts and return-on-error behaviour deserve equal attention because a translation failure can otherwise create signalling storms or long delays in services such as SMS and roaming authentication.
Testing and troubleshooting
A practical test begins with the complete Called Party Address: routing indicator, point-code presence, SSN, GT digits, translation type, numbering plan, and nature of address. The engineer then follows each translation step across the STP or signalling firewall, checking the selected route and the rewritten address.
Packet captures should be compared with configuration exports and expected message sequences. Useful checks include whether the GT is normalised before lookup, whether the SSN is preserved after translation, whether the DPC belongs to the intended signalling point, and whether global title translation loops back to the same node.
Fault isolation becomes easier when tests cover valid, invalid, and boundary cases. Test numbers should include Australian mobile formats, international format, ported ranges, unknown prefixes, and deliberately malformed digits. Results should record the returned cause code, hop-by-hop route, and elapsed time.
Applying the model in practice
A sound design separates logical addressing from physical routing. The GT identifies the subscriber, service, or database context; the translation result identifies the reachable signalling point; and the SSN identifies the application within that point. Keeping these roles distinct makes future network changes less disruptive.
Teams can use SS7 learning products to support a consistent vocabulary for SCCP, MTP3, ISUP, timers, and SIGTRAN. The strongest operational designs combine documented translation rules with controlled change management, traceable testing, and security review.
| Routing combination | Typical use | Main validation |
|---|---|---|
| Point code + SSN | Known application at a known signalling point | Confirm DPC reachability and SSN |
| GT + SSN | Logical address translated to a specific service | Check GT format, translation result, and SSN |
| GT without fixed destination | Database or roaming lookup | Validate translation type and numbering plan |
| GT through multiple translations | Inter-carrier or international routing | Detect loops, rewriting errors, and trust-boundary violations |
The practical takeaway is to treat every SCCP route as a controlled relationship between address format, translation logic, destination point code, and SSN. In an Australian network, validating that relationship against number portability, +61 formatting, carrier boundaries, and security policy is essential for reliable signalling.
