M3UA Routing Keys Using Point Code and SSN
SIGTRAN carries traditional SS7 signalling over IP networks, allowing signalling points to communicate through SCTP and M3UA rather than dedicated TDM links. Within that model, a routing key defines which incoming messages belong to a particular traffic group and where the signalling process should send them.
A common design uses the destination point code (DPC) together with the SCCP subsystem number (SSN). This combination gives the signalling gateway or IP-based signalling node enough information to distinguish traffic for a specific signalling point and application, such as a Home Location Register, Visitor Location Register, or Short Message Service Centre.
| Element | Function in routing |
|---|---|
| DPC | Identifies the SS7 destination point |
| SSN | Identifies the SCCP application or subsystem |
| Service Indicator | Identifies SCCP traffic at the MTP3 layer |
| Routing Context | Associates matched traffic with an application server |
| ASP | Processes traffic within the application server |
| SCTP association | Provides the IP transport path |
How M3UA Uses A Routing Key
M3UA sits between SCTP and upper-layer SS7 protocols. It transports messages such as SCCP, ISUP, and TUP across an IP network while preserving important SS7 addressing information. The routing key is evaluated by the signalling gateway or M3UA routing function before a message is delivered to an application server.
For SCCP traffic, the DPC identifies the destination signalling point and the SSN identifies the subsystem at that point. A rule such as DPC 2-1234-5 plus SSN 6 can therefore select one routing context, while the same point code with SSN 8 can select another. The service indicator normally confirms that the message belongs to SCCP traffic.
This arrangement is useful when several applications share the same signalling point. Instead of routing every message only by point code, the network can separate MAP, CAP, SMS, or other SCCP-based services at the subsystem level.
Point Code And SSN Roles
A point code is an address within an SS7 numbering plan. Depending on the national or network environment, it may be represented in 14-bit, 24-bit, or another format. The important detail is that all connected nodes must interpret the point code consistently; a mismatch can send traffic to the wrong destination or cause it to be rejected.
The SSN is an SCCP-level address. Typical values identify applications such as mobility management, HLR, VLR, MSC, or SMS-related functions. An SSN does not replace the point code. It refines the destination by identifying which subsystem should receive the message once the signalling point has been selected.
In an Australian carrier environment, the point-code plan must align across national networks, international gateways, and IP signalling platforms. A design used in Sydney may need to interoperate with equipment in Melbourne, Perth, or a regional exchange, so local numbering assumptions should never be hard-coded without checking the operator’s signalling plan.
Routing Context And Application Servers
When an incoming message matches the DPC and SSN combination, M3UA maps that match to a routing context. The routing context identifies the relevant Application Server (AS), while one or more Application Server Processes (ASPs) provide the active processing instances. This separation supports redundancy and controlled failover.
An AS may operate in override, load-share, or broadcast mode, depending on the required behaviour and implementation. In load-sharing mode, traffic is distributed across available ASPs. In override mode, one ASP handles traffic while another remains ready to take over.
A configuration example might associate DPC 2-1234-5, SSN 6, and the SCCP service indicator with routing context 4102. The ASPs serving that context then exchange ASPUP, ASPAC, and heartbeat-related messages to establish and maintain service. Training material from SS7 Training resources can help place these M3UA procedures alongside MTP3 and wider SS7 architecture.
Building A Precise Routing Key
A robust routing key should include every field needed to distinguish the intended traffic, but no unnecessary fields that make operations fragile. For a DPC-and-SSN design, document the point-code format, SSN value, service indicator, network appearance where applicable, and any relevant originating point-code restrictions.
Network Appearance can be significant when multiple SS7 networks or numbering domains share an IP signalling environment. If it is configured differently at opposite ends, messages may fail to match even when the DPC and SSN appear correct. The same applies to point-code representation, especially when equipment vendors display decimal, hexadecimal, or segmented values differently.
Some deployments also include the originating point code (OPC), global title translation results, or other SCCP information. These additions should reflect a real routing requirement. Overly broad rules can mix unrelated services, while overly narrow rules can create rejected messages and difficult fault isolation.
Signalling Gateway Behaviour
The signalling gateway receives SS7 traffic from a legacy link set or another signalling domain, extracts the relevant MTP3 and SCCP information, and applies the M3UA routing key. If the message matches an active routing context, it is sent over SCTP to the selected ASP. If no match exists, the node may discard the message, return an error, or apply a configured default route.
Operators should monitor routing-key misses, ASP state changes, SCTP association status, and M3UA error messages. A useful test plan sends traffic to the correct DPC and SSN, then deliberately changes one value at a time. This confirms that the rule is specific and that unwanted traffic is not being accepted.
Australian networks also need to account for long distances between major data centres and remote service areas. A signalling path between Brisbane and Adelaide may have different latency and resilience characteristics from one inside a Sydney facility. SCTP multihoming, diverse backhaul, and sensible timers help maintain service when an IP path is interrupted.
Testing And Interoperability
Testing should begin with protocol traces that show the DPC, OPC, service indicator, SSN, routing context, and SCTP association. Compare the captured values with the provisioned routing key rather than relying on a vendor interface that may abbreviate fields.
Interoperability testing is especially important when a legacy STP, signalling gateway, and IP-based application server come from different suppliers. Confirm how each device handles duplicate routing keys, inactive ASPs, unavailable application servers, and messages with unknown SSNs. Check whether failover preserves message order where the application requires it.
The same principles remain relevant as operators move from circuit-switched networks towards LTE and IMS. A LTE-to-IMS signalling guide provides useful context for understanding where SS7-based services fit within newer telecom architectures.
Operational Takeaways
The key design decision is to treat the DPC and SSN as a combined address for SCCP application traffic, rather than as unrelated values. The DPC selects the signalling point; the SSN selects the subsystem; M3UA then maps the match to a routing context and an available ASP.
Reliable operation depends on consistent point-code plans, accurate SSN provisioning, compatible network appearance settings, and testing across normal and failure states. What the reader should remember is simple: a precise DPC-plus-SSN routing key gives M3UA the information it needs to deliver SCCP traffic to the right application service.
