How SSN Guides SCCP Signaling Traffic
In Signaling System No. 7, the Subsystem Number (SSN) identifies the application or service that should receive a signaling message at a destination signaling point. SCCP uses this value to deliver traffic beyond the basic network node, distinguishing services such as MAP, INAP, CAP, and other upper-layer protocols.
An SSN is meaningful within the context of a signaling point code and network. It does not usually identify a global subscriber or telephone number. Instead, it helps the SCCP layer determine which local subsystem should process a message after routing information has been evaluated.
Understanding this role is essential for engineers working with PSTN interconnection, mobile-core signaling, SIGTRAN deployments, and signaling security. An incorrect SSN can send a correctly transported message to the wrong application, cause rejection, or make a functioning route appear unavailable.
What The Subsystem Number Identifies
The SSN is an address component used by SCCP to identify a particular service within a signaling point. Common assignments include SSN 6 for the Home Location Register (HLR), SSN 7 for the Visitor Location Register (VLR), and SSN 8 for the Mobile Switching Center (MSC), although exact operational use depends on network standards and deployment practices.
A destination point code identifies the signaling node, while the SSN identifies the service inside that node. This distinction allows several signaling applications to share the same physical or logical signaling point without competing for the same message stream.
SCCP addressing can also include a Global Title (GT). In many operational networks, the originating node does not know the final point code and SSN at first. It sends a message using a GT, and an SCCP Global Title Translation (GTT) process converts that address into a destination point code, SSN, and related routing data.
How SCCP Uses SSN During Routing
SCCP routing decisions depend on the called party address and the routing indicator. If routing is based on a point code and SSN, SCCP can send the message directly toward the specified signaling point. If the address contains a GT, the message may pass through one or more translation services before the final SSN becomes available.
Once the destination point code and SSN are determined, lower layers forward the signaling unit through MTP3 or an IP-based signaling transport arrangement. The SSN itself does not select a physical link. It selects the application endpoint that should receive the payload after the signaling network has delivered it to the correct node.
In SIGTRAN architectures, SCTP commonly transports M3UA, which carries signaling traffic across IP networks. Engineers designing resilient paths should also account for SCTP multihoming and failover, because transport redundancy protects connectivity but does not correct an invalid SSN or failed SCCP subsystem.
SSN, Point Codes, And Global Titles
A practical SCCP address may contain a point code, SSN, GT, or a combination of these elements. The point code locates the signaling point, and the SSN identifies the target service. The GT can represent a telephone number, IMSI, routing number, or another logical address that must be translated.
For example, a mobile-originated MAP message may be sent toward an STP using a GT associated with a subscriber. The STP performs GTT and determines that the message belongs at a particular HLR point code with the HLR’s SSN. The resulting route is therefore based on both node identity and application identity.
This layered addressing model supports network growth. Operators can change internal point codes, add signaling transfer points, or distribute application instances while preserving service-level addressing rules. However, translation tables must remain synchronized, and routing policies must match the actual subsystem configuration.
| Address Element | Primary Function | Typical SCCP Use |
|---|---|---|
| Point Code | Identifies a signaling point | Selects the destination node |
| SSN | Identifies an application or subsystem | Delivers traffic to MAP, INAP, CAP, or another service |
| Global Title | Provides a logical address for translation | Represents subscriber or service-related routing data |
| Routing Indicator | Specifies how the address is interpreted | Selects point-code/SSN routing or GT translation |
| Network Indicator | Separates signaling domains | Distinguishes national, international, or operator contexts |
Subsystem Status And Availability
SCCP monitors subsystem availability through status procedures and management messages. A subsystem can be marked prohibited, allowed, congested, or unavailable. These states help signaling nodes avoid repeatedly sending traffic to an application that cannot process it.
When an SSN becomes unavailable, an STP or adjacent signaling point may reroute traffic, return an error, or apply network-specific congestion handling. The result depends on the service, SCCP management configuration, and whether an alternate destination has been provisioned.
Troubleshooting should therefore examine more than link status. An MTP3 route may be active while the target SSN is prohibited. Similarly, an SCTP association and M3UA ASP may be operational even though the application registered for a particular SSN is stopped or misconfigured.
Common SSN Routing Failures
Many SSN-related incidents originate in inconsistent provisioning. A GT translation may resolve to the wrong point code, an application may listen on a different SSN than the routing table expects, or a signaling node may use an incorrect national or international network indicator.
Typical symptoms include SCCP User Adaptation messages indicating an unavailable subsystem, MAP timeouts, returned messages, and traffic reaching a signaling point without being delivered to the intended application. Packet captures should be correlated across SCCP, MTP3, M3UA, and SCTP layers.
Useful checks include:
- Verify the called party SSN and destination point code.
- Confirm that GTT produces the intended address.
- Check subsystem allowed or prohibited status.
- Compare SSN provisioning across STPs and application nodes.
- Review return causes, timers, and alternate routing behavior.
Security monitoring is also important. Unexpected SSNs, abnormal GT patterns, and repeated requests to sensitive subsystems can indicate scanning, misrouting, or signaling abuse. Filtering and screening rules should be precise enough to block unauthorized traffic without disrupting legitimate roaming or inter-operator services.
Designing Reliable SSN-Based Routing
Reliable deployments treat the SSN as part of an end-to-end service identity rather than an isolated numeric field. Application owners, signaling engineers, and security teams should agree on SSN assignments, point-code ownership, translation rules, and failure behavior before production activation.
Redundant signaling points can improve availability, but redundancy must be tested at the subsystem level. A backup route is useful only if the alternate node advertises the required SSN, accepts the relevant SCCP messages, and has access to the necessary service data.
SSN routing connects application logic with the signaling transport beneath it. By understanding how SSN, point code, GT, GTT, SCCP management, and SIGTRAN components interact, engineers can diagnose failures faster and build more predictable telecom networks.
Apply these checks to your SCCP routing inventory, validate each translated address in a controlled test, and monitor subsystem status alongside link and transport health. A disciplined SSN review can prevent silent message loss and improve the resilience of critical signaling services.
