Overview

If you run SS7/SIGTRAN networks, “what SSN should this service use and how do I route to it reliably?” is a daily question.

In SCCP, the subsystem number (SSN) identifies the application within a node. This enables accurate delivery of MAP, CAP/INAP, and other transaction-capable services. The behavior is defined in ITU‑T Q.713 and Q.714.

Internationally standardized (global) SSNs occupy 0–31 per ITU‑T Q.713. The remaining range is used nationally. 3GPP profiles list well-known mobile SSNs in 3GPP TS 29.002 and align numbering in 3GPP TS 23.003.

By the end of this guide, you will be able to allocate and register SSNs, choose DPC+SSN or GT+SSN routing, harden interconnects, read traces with confidence, and plan interworking to Diameter and 5G SBA.

Standards and ranges you must know

Engineers often see conflicting lists of “typical SSNs” and wonder which numbers are canonical. The only stable truth comes from the core standards.

SCCP semantics and SSN behavior are defined in ITU‑T Q.711–Q.714. Mobile profiles and well-known MAP SSNs appear in 3GPP TS 29.002/23.003. North American practices derive from ANSI T1.112 with Telcordia GR guidance.

Use these to settle disputes, document your allocations, and drive inter-operator agreements.

ITU‑T Q.711–Q.714 and Q.713: global SSNs 0–31 and SCCP behavior

Operations teams need a precise definition of what the SSN does on the wire. Q.713 defines SCCP addressing, including the Called/Calling Party Address indicators, the Routing Indicator (route on GT vs route on SSN+PC), and when the SSN is present.

Q.714 defines SCCP management messages (SSA/SSP/SSC) that govern subsystem availability and congestion. Practically, the “internationally standardized” SSNs are 0–31. The Address Indicators explicitly signal whether routing is based on DPC+SSN or on Global Title, which your STPs honor according to ITU‑T Q.713.

For example, a MAP UpdateLocation to an HLR typically has CdPA with RI=Route on GT and SSN Present=1. The SSN identifies the HLR application at the far node so that, after GTT, the message can be delivered to the right process.

Intra-PLMN paging on an MSC server is often addressed by DPC+SSN. The CdPA carries the DPC and SSN, and the RI indicates routing on SSN+PC. Record in your runbooks that SSN presence and the RI bit are non-optional for accurate troubleshooting and must be validated in acceptance tests.

3GPP TS 23.003 and 29.002: mobile profiles and national ranges (32–128, 151–254)

Mobile operators look for a definitive list of “the MAP SSN for each service.” 3GPP TS 29.002 enumerates the well-known SSNs used by MAP application contexts such as HLR, VLR, MSC, EIR, and others.

TS 23.003 aligns numbering and identities across PLMN elements. While the exact national range used in a country is regulated locally, 3GPP profiles make two things clear. SSN is the application selector within a destination node, and the internationally standardized values for core MAP entities are fixed by the standard.

In practice, common ITU/3GPP assignments you will see on traces include, for example, HLR, VLR, MSC, and EIR using well-known SSNs per 3GPP TS 29.002.

A CdPA with GT=MSISDN or IMSI and SSN=HLR leads to GTT selecting the HLR GT. The SSN then steers the message to the HLR process. When creating national services (e.g., number portability or value-added IN platforms), operators select SSNs from the national ranges and document them internally and in interconnect MoUs. Validate every new assignment against your national numbering policy and interconnect guide to avoid conflicts.

ANSI T1.112 and Telcordia GRs: North American deviations and service mappings

North American engineers often discover that “typical ITU SSNs” don’t line up with their traces. In ANSI networks, SCCP is defined by T1.112 (now ATIS-1000112), with national service mappings guided by Telcordia GR documents.

The ecosystem historically uses country-specific SSN allocations for services like CNAM, LNP, and 800 translation. Differences also show up in GTT styles (translation types and NPA-NXX constructs) and interworking behaviors at STPs.

For example, an LNP query launched via a Calling Name or routing database may be addressed with a national SSN assigned to the SCP platform. The CdPA GT may reflect an LRN or a “trigger” prefix.

Unlike the international MAP well-known SSNs that are standardized, these national service SSNs are coordinated in industry forums and Telcordia catalogs rather than in 3GPP tables. When operating cross-border interconnects, always reconcile ANSI/GR mappings with the peer’s ITU/3GPP view and capture the equivalence in your interconnect schedule. Add the ATIS and Telcordia references to your design documents.

Addressing and routing with SSN in SCCP

The most costly misroutes happen because the RI and SSN presence bits don’t match the configured routing. ITU Q.713 specifies that SCCP can route either by Destination Point Code plus SSN (DPC+SSN) or by Global Title (GT+SSN).

The Address Indicator in CdPA/ClPA states which to use. Your STP/SGW honors the RI; if it says “Route on GT,” it will perform GTT, potentially change CdPA, and then deliver to the DPC with the SSN. Capture the intended mode in your design so that both ends signal and provision consistently.

For example, an intra-PLMN location update to an HLR cluster is typically GT+SSN. GTT maps IMSI/MSISDN to an HLR GT, and only then uses DPC+SSN to deliver within the HLR node. Conversely, a local SCP for prepaid may be addressed DPC+SSN if it’s always in one node, reducing dependence on GTT. Before go-live, verify that traces show the intended RI and that the called SSN matches the target application on the receiving node.

When should I route by DPC+SSN versus GT+SSN, and what are the trade-offs?

Short answer: Use GT+SSN when you need portability, number-based distribution, or inter-PLMN resiliency; use DPC+SSN when you target a fixed node or when GTT adds no value. GT+SSN scales better for services identified by digits (IMSI/MSISDN/GT) and enables centralized steering; DPC+SSN is simpler and faster for local services but couples routing to topology.

SSN allocation governance and registration

SSN selection is often treated as “pick a free number,” which leads to collisions, unlogged changes, and opaque troubleshooting. The standards give you the ranges, but allocation governance is an operator responsibility.

Define who can request SSNs, how you avoid conflicts internally and with peers, how you publish decisions, and how you retire numbers. Align your process with national regulators or industry bodies if they maintain a registry.

A practical governance model designates an SSN custodian (in Core Engineering). Maintain a master catalog of SSNs and their owning applications. Enforce change control via architecture and interconnect review boards.

For cross-operator services, the interconnect agreement must record the SSN and any fallbacks. Update your STP/SGW provisioning and firewalls in the same maintenance window. Capture the change in your RTR (runbook-to-runbook) references.

How do I select and reserve a new SSN for a custom application within the national range (32–254)?

You select and reserve SSNs by policy and record them in a shared catalog before any provisioning begins.

Before go-live, verify that the SSN appears in all routing, firewall, and monitoring systems. Ensure your SSNM alarms map to the correct owner for response.

Is there a registry or formal process to avoid SSN conflicts with other operators in my country?

In many countries, there is no public “SSN registry.” Coordination happens via the regulator, national numbering forums, or bilateral MoUs.

Where a national body governs SS7 routing and numbering, they may publish a national SSN plan. Otherwise, operators document assignments in interconnect schedules and update them during change control. Your process should assume proactive coordination.

A lightweight governance checklist helps you avoid conflicts:

SCCP management (SSNM): activating, auditing, and alarms

“SSN down” tickets are hard to triage without a shared understanding of SSNM. ITU‑T Q.714 defines SCCP Subsystem Management: Subsystem Allowed (SSA), Subsystem Prohibited (SSP), and Subsystem Congested (SSC).

STPs relay these states so signaling peers know whether a subsystem at a DPC is reachable and under what load. Operators should actively use SSNM to verify availability and clear misconfigurations. Use ITU‑T Q.714 to anchor expected behavior.

For instance, if a new SCP SSN is configured but never sends SSA, peers will keep the SSN in “prohibited” state. This causes SCRC to reject messages or route to alternatives.

Conversely, receiving SSP from a peer for your HLR SSN indicates an outage at their node or a routing split. Your runbook should require correlation with M3UA/SCTP status and node health. Instrument counters for SSA/SSP/SSC per DPC/SSN to create baselines and alarms.

How can I verify if an SSN is active or prohibited on a remote node using SCCP management messages?

You confirm SSN state by observing or soliciting SSNM flows and correlating them with your STP/SGW counters.

Document expected SSA/SSP/SSC behavior in your acceptance tests and keep “who to page” mapped to each critical SSN.

Global title translation (GTT): failure modes and optimization

Many “mystery” misroutes are simply GTT rules not matching the Address Indicator or GT digits. SCCP routing can be directed to route on GT. In that case your STP applies GTT using the GT’s translation type, numbering plan, nature of address, and digits.

Precedence matters. If a more-specific rule doesn’t exist, a broad catch‑all may send calls to the wrong HLR or SCP. Changes to MSISDN/IMSI ranges must be reflected atomically across active STPs.

A classic failure mode is an IMSI-based GTT that expects a particular translation type, while messages arrive with a different type. The STP does not normalize and applies a generic rule, misrouting to a default HLR.

Another is a CdPA marked route-on-SSN+PC sent to a peer that expected GT routing. The peer never performs GTT, and the SSN appears “down” from your perspective.

Optimize by keeping GTT rules tidy. Use explicit translation types for each service. Stage changes with shadow counters to verify traffic matches the intended rules before activation. Always trace pre- and post-GTT CdPA to confirm correctness.

Security hardening and interconnect policy

Unauthorized MAP operations against open SS7 interconnects remain a real threat. GSMA’s FS.11 and IR.82 prescribe layered defenses: filter by origin, by service (SSN), by operation, and by subscriber scope.

Monitor for abuse patterns and ensure change control around any SSN exposure. Build these controls into your border STPs and firewalls and validate them during interconnect acceptance and periodic audits.

Map threats to controls explicitly. For example, illegitimate ProvideSubscriberInfo or AnyTimeInterrogation toward HLR/MSC SSNs should be blocked when sourced from untrusted networks.

SMS fraud through MAP-FORWARD-SM to SMSC SSNs must be constrained by origin and subscriber lists. Unlawful location should be denied except through approved GMLCs. Align your design and ops with GSMA FS.11 and GSMA IR.82 and keep policies current with incident learnings.

Which security controls should I implement to block unauthorized MAP operations by SSN at interconnects?

Enforce least privilege at the SSN and operation level, then monitor continuously.

Document every interconnect’s SSN/operation matrix and keep it under change control with security sign-off.

Interworking cookbook: SSN mappings to Diameter and 5G SBA

As networks modernize, teams need deterministic ways to map legacy SS7/MAP services to Diameter and, increasingly, to 5G SBA APIs. There is no one-to-one numeric mapping of SSN to Diameter Application-IDs or 5G service names.

Interworking gateways translate protocol semantics while preserving service identity and policy. Your job is to specify which legacy SSNs map to which Diameter apps or 5G services. You must also define fallback and rollback plans.

A practical pattern is to place a MAP–Diameter IWF at the edge of your HLR/HSS domain. For example, MAP UpdateLocation or AuthenticationInfoRequest flows map to Diameter S6a/S6d (Application‑Id 16777251) toward the HSS.

EIR checks map from MAP to Diameter S13 (Application‑Id 16777252). LCS functions may map through Diameter to GMLC interfaces.

For 5G, subscriber data functions shift to UDM over SBA (e.g., nudm-uecm/nudm-ueau) and SMS evolves to SMSF. The interworking remains a gateway function, not a numeric SSN mapping. Anchor your target architecture on 3GPP SBA definitions in 3GPP TS 29.500 and keep legacy SSN policies consistent with the new service identities.

How do SSNs map to Diameter Application-IDs or 5G SBA service names during interworking?

Short answer: they don’t map numerically; you map services. For each SSN-exposed service, define the target Diameter application or 5G service and implement translation in the IWF or API gateway.

During cutovers, maintain dual-running, mirror KPIs, and stage traffic gradually with explicit rollback criteria.

Configuration and operations: STP/SGW/M3UA

Misconfigurations at the signaling edge cause outsized impact, especially with SIGTRAN. IETF RFC 4666 defines M3UA roles and routing keys.

In practice, you configure SCTP associations, assign Application Server Processes (ASPs) to Application Servers (ASs), and select routing keys using DPC/SSN and/or GT. Keep your design vendor-neutral. Define per-service routing contexts when isolation is needed, and measure health per AS.

For example, expose your HLR SSN via one AS keyed by DPC+SSN and a second AS keyed by GT+SSN for interconnect resilience. This allows separate control over peering and internal traffic.

For an SCP, a per-SSN routing context simplifies maintenance windows by letting you quiesce that service independently. Document ASP↔SGP mappings, heartbeat intervals, and alarm routes in your runbooks. Verify with synthetic probes before onboarding new peers.

How-to: Step-by-step configuration of DPC+SSN vs GT+SSN routing on STP/SGW and core nodes

You can reduce risk by following a repeatable, testable sequence.

Monitor per-AS counters (messages, rejects, congestion), per-SSN SSNM, and SCTP health continuously. Attach alerting thresholds to known-normal baselines.

KPIs, traces, and troubleshooting playbooks

Without a standard playbook, SSN reachability issues can drag on. Focus your KPIs on what SCCP and TCAP actually signal: per-SSN SSA/SSP/SSC events; SCCP Return Cause distributions; TCAP Begin/Continue/End ratios; rejects at the border firewall by SSN and operation; M3UA ASP up/down flips per AS.

Combine counters with trace-driven checks of Address Indicators to detect misroutes fast.

A MAP transaction failing at Begin with a Return Cause of “Subsystem failure” while SSNM shows SSP for that SSN points to a real outage. The same Return Cause with no SSP often implies wrong RI or missing SSN presence in CdPA.

Keep a decision tree. Check SCTP/M3UA, then SSNM, then Address Indicator bits, then GTT hits, then application logs. Feed these patterns back into onboarding tests and recurring audits.

How do I decode Called and Calling Party Address indicators to confirm which SSN was used in a trace?

Start by reading the Address Indicator bits and the presence flags. In SCCP, the Called Party Address (CdPA) indicator includes the Routing Indicator (route on GT vs SSN+PC), the Global Title indicator (which GT format is present), the SSN Present flag, and the Point Code Present flag.

If RI=Route on GT and SSN Present=1, the message expects STP GTT followed by delivery to the destination SSN at the resolved DPC. If SSN Present=0 in this context, delivery will likely fail or route to a default.

For example, a CdPA showing GT with NAI=E.164, TT=0 and SSN Present=1 indicates a GT+SSN flow. After GTT, the post-translation CdPA in the STP trace should show DPC and the same SSN.

In a DPC+SSN route, the CdPA indicator shows RI=route on SSN+PC, SSN Present=1, and Point Code Present=1. The GT is typically absent.

Typical misconfig signatures include RI=SSN+PC with Point Code Present=0, or RI=GT with SSN Present=0 for a service that requires SSN routing. The Calling Party Address (ClPA) is usually less critical for routing, but its presence and format can trigger peer policies. Ensure it matches interconnect requirements.

Validate every interconnect with golden traces capturing pre- and post-GTT CdPA/ClPA. Log them with your runbooks.

Testing, certification, and training

You cannot assume SSN behavior is correct until you test it against the standards and your policies. Build conformance checks aligned to Q.713 addressing and Q.714 SSNM (SSA/SSP/SSC) behaviors.

Automate transaction-level tests using TTCN‑3 or your vendor’s simulator. Include GSMA IR.82 security controls in interconnect acceptance. Re-test after any GTT or firewall change.

A solid program includes lab tests for Address Indicator correctness, SSNM events on application start/stop, congestion signaling, firewall allow/deny by SSN and operation, and dual-running scenarios for interworking.

Certify engineers on SCCP/TCAP trace reading and SIGTRAN operations. Require playbook-driven drills for SSN-prohibited incidents. Keep your test artifacts versioned and tie them to every SSN addition or migration.

Capacity planning, scale, and resilience

As traffic grows, the question becomes how to scale behind one SSN without breaking affinity or transactions. At SCCP/TCAP level, transactions can be distributed by GT digits at the STP, by M3UA loadsharing across ASPs in an AS, or by application-layer hashing that preserves TCAP dialogue affinity.

Your plan must describe how multiple application instances behind a single SSN are balanced and how failures propagate via SSNM.

For example, for an HLR cluster fronted by a single SSN, you may distribute by IMSI ranges in GTT so that each resolved GT maps to a specific instance. SSN remains the same but DPC changes per instance.

If instances are behind a single GT/DPC, use M3UA loadsharing among ASPs. Ensure the application correlates TCAP dialogues to a stable worker (stickiness). Build failover so that SSC events throttle senders gracefully and SSPs remove an instance from distribution.

Monitor per-instance utilization, TCAP aborts, and end-to-end latency to detect imbalances early.

What happens if multiple application instances share the same SSN behind one GT, and how should I design for scale and resilience?

Short answer: the network still sees one service, so you must provide deterministic distribution and clean failure signaling underneath. Use GTT or M3UA loadsharing with transaction affinity, and ensure SSNM accurately reflects per-instance health.

Change management and migration

SSN renumbering, platform swaps, and protocol migrations fail when cutovers are big-bang. Deliver zero downtime by introducing new SSNs or pathways in parallel, proving them under shadow traffic, and shifting gradually with hard rollback gates.

For protocol migrations, isolate interworking in gateways and keep legacy SSN policies consistent with new Diameter or SBA identities until traffic is fully cut over.

For example, when migrating an SCP to a new platform, assign a new SSN. Duplicate policy and GTT, run dual for a measured period, then move ranges in increments. Keep SSA/SSP under strict control to avoid flapping.

For MAP→Diameter, deploy the IWF, mirror KPIs across legacy and target, and cut subscribers or services in cohorts. Pre-approve rollback triggers (e.g., TCAP aborts > X per K transactions, or Diameter error rates > Y%) and rehearse them.

Decision: Migration paths from SS7/MAP SSNs to Diameter/5G SBA services; coexistence strategies

Short answer: isolate translation in gateways, dual-run with mirrored KPIs, and move in cohorts with explicit rollback. Coexistence is normal; priority is consistent policy and measured risk.

Governance and compliance checklist

Good operations are auditable operations. Use a concise checklist to keep SSN usage safe, documented, and compliant across its lifecycle.

By grounding your SSN strategy in the core standards, enforcing clear governance, and running to playbooks for routing, security, and interworking, you will make SSN-related incidents rare, bounded, and quickly reversible. That is exactly how critical signaling should be operated.