Configuring SS7 Routing Tables for Multiple Destination Point Codes
An SS7 routing table tells the signalling network where to send messages addressed to different Destination Point Codes (DPCs). In a traditional PSTN environment, the table connects MTP3 route selection with linksets, signalling links, and adjacent signalling points. In a SIGTRAN deployment, the same logic is carried across SCTP associations and protocols such as M2PA or M3UA.
Multiple DPCs are common when a carrier reaches several exchanges, service control points, SMS centres, or international gateways. A well-designed configuration must distinguish each destination, define the available paths, and specify what happens when a preferred route becomes unavailable.
Australian operators often combine older SS7 interconnects with IP-based signalling as networks evolve around NBN services and mobile infrastructure. A routing design that works for a small Brisbane test network may need additional redundancy and segmentation before it is used across Sydney, Melbourne, or a national carrier footprint.
The examples below use generic point codes because vendors represent them differently. Always confirm whether the platform expects ITU, ANSI, or another point-code format, and check the carrier’s interconnect documentation before applying changes to a live network.
Understanding Point Codes And Route Scope
A point code identifies a signalling point within a specific numbering plan. The DPC is the destination, while the Originating Point Code (OPC) identifies the sender. In an SS7 routing table, each DPC entry normally maps to one or more linksets or SIGTRAN peers. The route may lead directly to a destination exchange or indirectly through a Signal Transfer Point (STP).
Begin by documenting the signalling topology. Record local point code, adjacent point codes, remote destinations, linkset names, transport addresses, and supported traffic types. For M3UA, also record the Application Server Process (ASP), Routing Context, and Network Appearance where applicable.
Do not assume that two visually similar point codes belong to the same network. A 14-bit ITU point code and a 24-bit ANSI point code use different structures. A formatting error can send messages towards the wrong route or cause an apparently valid destination to remain unreachable.
Preparing The Routing Data
Create one clear route record for every DPC. A practical record includes the destination, next signalling point, route priority, linkset, availability state, and traffic restrictions. If several DPCs share the same STP, maintain separate destination entries while reusing the appropriate linkset definition.
For example, DPC 2-10-4 might use the Sydney STP as its primary route and a Melbourne STP as its backup. DPC 2-10-5 could use the same pair of STPs but have a different priority or traffic class. This separation makes fault analysis easier and prevents a broad route change from affecting unrelated services.
If the table supports ranges, use them only when the numbering plan and carrier policy make the range unambiguous. Explicit entries are safer for critical destinations such as an HLR, SCP, SMSC, or international gateway. Global Title Translation may still be required for SCCP traffic, even after MTP3 has delivered the message to the correct signalling point.
Building Route Selection And Failover
A basic route definition includes the DPC, preferred linkset, secondary linkset, and selection policy. Static priority is simple: send traffic through the lowest-cost available route. Load sharing can distribute traffic across equivalent paths, often using the Signalling Link Selection (SLS) value to keep related messages on a consistent path.
For SIGTRAN, check that the DPC is associated with the correct M3UA routing key. The key may include DPC, OPC, Service Indicator, or Network Appearance. The remote ASP must be active, and the SCTP association must be established before the route is considered usable.
Define behaviour for Transfer Prohibited, Transfer Allowed, and Transfer Restricted states. MTP3 timers and management messages should remove failed routes from service without creating unstable flapping. In an Australian national network, a second metropolitan path may protect a Sydney destination, but it should not be treated as genuine geographic diversity unless the underlying carriers and facilities are independent.
Validating Signalling And Service Behaviour
Test each DPC separately with signalling traces. Confirm that the message carries the expected OPC, DPC, Service Indicator, SLS, and circuit or transaction identifiers. For ISUP, verify that IAM, ACM, ANM, REL, and RLC messages follow the same intended path. For SCCP and TCAP, inspect called and calling party addresses as well as translation results.
Application behaviour can reveal routing mistakes that basic reachability tests miss. A VPN or intelligent-network transaction may require a precise TCAP component sequence; the TCAP component sequence is useful when checking whether routing changes have affected dialogue order or service logic.
Checks Before Production
- Confirm every DPC against the approved numbering plan.
- Verify primary and secondary linkset status.
- Capture traces for normal and failed-route scenarios.
- Check alarms, counters, and route management messages.
Warning Signs During Testing
- Messages leave through an unexpected STP.
- SLS distribution is heavily unbalanced.
- Traffic returns with Transfer Prohibited.
- TCAP dialogues time out after route changes.
Use controlled maintenance windows and retain the previous configuration. Coordinate with the relevant carrier or interconnect partner, particularly where Telstra, Optus, or another provider owns part of the signalling path. A route that appears correct locally may still be rejected by remote screening or point-code validation.
Comparing Routing Approaches
The right design depends on destination count, availability requirements, and how much control the operator has over the transport network. A small lab can use static routes, while a carrier-grade platform generally needs route management, health monitoring, and tested failover.
| Approach | Suitable Use | Strength | Main Risk |
|---|---|---|---|
| Static single route | Lab or low-criticality service | Simple to deploy | No resilience |
| Static primary and backup | Small production network | Predictable failover | Manual maintenance |
| Equal-cost load sharing | High-volume signalling | Uses capacity efficiently | More complex fault analysis |
| Dynamic route management | Carrier or multi-STP network | Responds to network state | Requires careful timer tuning |
| M3UA routing keys | SIGTRAN interconnect | Flexible IP-based separation | Misaligned contexts can block traffic |
For Melbourne and Adelaide deployments, operators may prefer distinct STPs and transport providers so a metropolitan fibre incident does not remove both paths. In regional areas, the available options may be narrower, making conservative timers, tested backup routes, and clear escalation procedures especially important. Australian maintenance practices also benefit from documenting local time zones, daylight-saving impacts, and carrier change windows.
The central principle is to treat every DPC as a controlled destination with an explicit path, policy, and failure state. Accurate point-code formats, correctly matched M3UA parameters, verified SCCP translation, and trace-based testing are more valuable than a large table built without operational discipline. A routing table is reliable when each destination has a known route, a tested alternative, and evidence that signalling and services behave correctly during both normal operation and failure.
