How SCCP Subsystem Numbers Direct Messages to the Right Application
Signaling System No. 7 carries control traffic across Australian mobile networks throughout the day, from a Sydneysider's train arriving in Brisbane to roaming checks for travellers touching down at Perth Airport. None of it reaches the right software without the Signalling Connection Control Part and its subsystem identification mechanism. The SCCP subsystem number, usually abbreviated SSN, is a small but decisive field that tells the transport layers which application on a remote node should receive a particular message.
When an STP receives a packet bearing only a global title rather than a point code plus subsystem, it consults its routing tables to decide where to forward the call. This translation lets a single address serve multiple operators, which matters in a federated market like Australia where Telstra interconnects with Optus and TPG services. Understanding how SSN participates in that translation is essential for anyone building or debugging modern telecom infrastructure.
What SCCP Adds to the SS7 Protocol Stack
SCCP sits above MTP3 and below application layer protocols such as MAP, CAP, INAP, and RANAP. MTP3 handles link management and point-to-point transfer between signalling points, but it does not understand identifiers like IMSI or MSISDN. SCCP fills that gap by providing connectionless datagram delivery and connection-oriented session management, both of which depend on the subsystem number to identify the destination application.
Inside the SCCP header, the called party address carries either a point code combined with an SSN, or a global title that the receiving STP must translate. The SSN field is typically one octet, giving values from 0 to 255, although only a handful are reserved for active subsystems. This compactness keeps headers lean and helps operators in dense urban markets like Melbourne and Adelaide keep signalling bandwidth predictable during peak load.
How Global Title Translation Relates to SSN
Global title translation maps a routable identifier, such as a mobile station roaming number or SMSC address, to a point code and subsystem number pair. A service switching point issuing a query usually does not know which HLR serves the subscriber, so it sends only the global title. The home STP analyses digits, translation type, and numbering plan to derive the destination point code and SSN.
To illustrate how different addressing modes behave across Australian operator networks, the table below summarises the key characteristics of each approach.
| Addressing mode | Header content | Requires STP translation | Typical use case |
|---|---|---|---|
| Point code plus SSN | DPC + SSN only | No | Local MAP traffic between MSC and VLR |
| Global title only | GT digits + translation type | Yes | HLR lookup for roaming subscriber |
| Global title with PC+SSN | GT + DPC + SSN | Optional | Hybrid routing in IP SIGTRAN deployments |
| Connection reference | Local reference number | Yes | Connection-oriented SCCP sessions |
The interaction between translation type, numbering plan, and SSN ultimately dictates which application receives the message, so misconfiguration here produces silent failures that are hard to detect without protocol traces.
Subsystem Numbers Used in Live Networks
Each well-known application running over SCCP has a fixed numeric value. Allocations are coordinated internationally through the ITU, and Australian regulators including ACMA recognise them when drafting interconnection rules. Operators in Brisbane, Perth, and Sydney rarely assign these themselves; they simply configure each network element so queries find the right subsystem at the destination point code.
Common subsystem allocations worth knowing:
- HLR (0 or 6): location register for mobile subscribers
- VLR (1 or 7): visitor location register for authenticating roamers
- MSC (2 or 8): mobile switching centre handling call setup
- EIR (around 9): equipment identity register for stolen-device checks
When provisioning a new application, the first step is to reserve an unused SSN and broadcast a subsystem status test message to confirm reachability. Operators moving voice services to IP after the Australian PSTN switch-off have had to map these legacy numbers into SIGTRAN, which adds extra complexity.
Connectionless Versus Connection-Oriented SCCP
Most modern signalling, including nearly all MAP traffic between HLR and VLR, uses the connectionless service, also known as class 0 or class 1 SCCP. Each message is self-contained and the SCCP layer relies entirely on SSN and point code to deliver datagrams. Connection-oriented service instead establishes a temporary signalling connection using reference numbers, with the SSN selecting the destination application at setup time.
Engineers supporting operators like Telstra or Optus find connectionless traffic easier to load-balance across STPs, while connection-oriented flows require state held at both ends. In Australia, where the National Broadband Network has driven SIGTRAN adoption, connectionless SCCP remains dominant because of its simplicity and predictable latency.
SSN Behaviour in IP-Based SIGTRAN Networks
When signalling travels over IP using protocols like M3UA and SUA, the SCCP layer keeps its original addressing semantics. A gateway that terminates SS7 and presents it as SIP for IMS, as covered in guides on PSTN to IP interworking, still needs to populate the SSN correctly so upstream application servers can route the message. Engineers often debug cases where SSN mismatches cause messages to be silently discarded or returned with a subsystem prohibited cause.
The same discipline carries over when migrating from legacy TDM trunks to all-IP cores, because the application layer does not care which transport carries the bytes beneath it. Preserving SSN semantics through the migration is what keeps roaming, short message service, and supplementary services working seamlessly across generations of infrastructure.
Diagnosing Common SSN Routing Faults
When an application stops responding to queries, engineers in an Australian NOC first check whether the SSN advertised in subsystem status messages matches what the originator is using. ACMA guidance on service quality monitoring suggests keeping detailed logs of SCCP management messages, including subsystem prohibited causes returned when an unknown SSN is addressed.
A practical diagnostic path involves:
- Confirming the destination point code is reachable via MTP3
- Verifying the SSN is configured and active on the receiving node
- Checking the global title analysis table on the STP maps digits to the correct PC+SSN pair
- Reviewing subsystem status test intervals and timeout values
Once these align, messages flow predictably. Engineers ready to move beyond theory can set up a SIGTRAN testbed with a pair of STPs and a real HLR simulator, watching the SCCP subsystem status exchanges live. Capturing traces during a deliberate SSN mismatch is one of the fastest ways to internalise how the protocol behaves when something is wrong. The same staged learning principle shows up in unrelated hobbies, where students often start with white-key songs before progressing to more advanced material, building hand coordination one key at a time. Applied to SCCP troubleshooting, that incremental habit builds the intuition needed to fix production faults quickly when they arise.
