MTP3 Transfer Prohibited And Transfer Allowed Procedures
Signalling System No. 7 relies on MTP3 to select routes between signalling points and maintain a usable path through the network. When a destination becomes unreachable, Transfer Prohibited (TFP) informs neighbouring nodes that traffic must not be sent along a particular route. Transfer Allowed (TFA) reverses that condition when reachability is restored.
These messages are part of MTP3 signalling network management. They support route-set updates without requiring every application, such as ISUP, to discover a failed link through repeated call attempts. Correct handling helps protect network capacity and limits unnecessary signalling traffic.
For engineers working with Australian fixed, mobile, and wholesale networks, the subject remains relevant as legacy PSTN interworking coexists with IP-based transport and SIGTRAN deployments. A signalling point in Sydney may depend on routes through Melbourne, Brisbane, or Perth, while regional and remote exchanges can have fewer practical alternatives.
The material available through SS7 Training provides useful background on MTP3, ISUP, timers, call routing, and signalling architecture. Those foundations make it easier to interpret TFP and TFA traces rather than treating them as isolated protocol events.
Purpose Of TFP
An MTP3 Transfer Prohibited message indicates that a signalling point should stop transferring traffic towards a named destination through a specified route or adjacent signalling point. The destination may be unavailable because of a link failure, an inaccessible signalling route, maintenance activity, or a problem reported by a lower management function.
TFP is a control message, not an application-layer call failure. Once received, the signalling point updates its routing status and chooses another available route if one exists. If no alternate route is suitable, upper layers may eventually receive an unavailable indication, and calls or transactions can fail in a controlled manner.
Purpose Of TFA
Transfer Allowed tells a signalling point that traffic may again be transferred towards a destination. It normally follows restoration of a signalling route, successful alignment of links, or confirmation that the affected destination can be reached through the relevant network path.
A TFA does not automatically guarantee that every service is healthy. MTP3 reachability may be restored while ISUP circuits, SCCP subsystems, databases, or an IP transport association remain impaired. Operators should therefore correlate TFA with link status, route availability, application alarms, and test traffic.
How Route Status Changes
MTP3 maintains route information for destinations reached through adjacent signalling points. When a route fails, the local node may generate TFP towards neighbouring nodes, allowing the prohibited state to propagate through the signalling network. This prevents other points from continuing to send traffic into a known dead end.
When recovery is confirmed, TFA updates the route state to allowed. The timing matters: sending TFA too early can create a loop of failed traffic, while delaying it unnecessarily can leave a functioning path unused. The implementation should follow the relevant ITU-T or national signalling specification and the operator’s engineering rules.
Relationship With Link And Route Failures
A signalling link failure does not always mean that the destination itself is unavailable. MTP3 may reroute traffic over another link in the same linkset or through another route set. TFP becomes necessary when the available alternatives cannot reach the destination, or when network management determines that traffic must be blocked for a specific route.
Australian carriers often operate mixed environments involving SS7 over traditional transport, SIGTRAN over IP, and interconnection gateways. An SCTP association failure, an M2PA or M2UA fault, or an IP routing incident may eventually produce the same operational result as a physical signalling-link outage: a route becomes unavailable and TFP-related events appear in logs.
Reading TFP And TFA In Traces
A useful trace should show the originating point code, destination point code, affected link or route, message direction, timestamp, and subsequent routing decisions. Compare the first TFP with link alarms and route-set changes, then check whether TFA arrives after a genuine recovery rather than after a simple process restart.
Timers and repeated management messages also provide clues. Rapid alternation between TFP and TFA may indicate an unstable link, packet loss, congestion, incorrect route configuration, or inconsistent state between signalling points. A sustained TFP with no recovery message points towards an unresolved fault or a missing alternate route. The route recovery guide offers further context for investigating these conditions.
Australian Network Considerations
Australia’s broad geography makes route diversity especially important. A metropolitan network in Sydney or Melbourne may have several transmission paths, whereas a regional site near Darwin, Alice Springs, or rural Western Australia may depend on fewer backhaul options. A TFP event at a remote exchange can therefore have a larger service impact than the same event in a dense metro cluster.
The retirement of legacy PSTN services and the continuing shift towards IP voice mean that signalling gateways must be monitored carefully during interworking. Emergency calling to 000, number portability, mobile roaming, and wholesale carrier hand-offs all depend on accurate reachability information. ACMA obligations and carrier service commitments also make reliable fault records important when investigating customer-impacting outages.
The local market includes Telstra, Optus, TPG Telecom, NBN-connected service providers, and many wholesale operators with different signalling boundaries. Engineers should avoid assuming that a TFP generated inside one carrier’s network describes the complete condition of an interconnect. Capture evidence at each boundary, including point-code mapping, gateway status, and agreed maintenance windows.
Practical TFP And TFA Handling
When TFP appears, first identify the affected destination and the route that has been withdrawn. Confirm whether traffic was rerouted, rejected, or discarded, and check adjacent signalling points for matching management messages. Do not clear the alarm merely because a later TFA appears; verify that normal call setup, routing queries, and relevant SCCP traffic have resumed.
During recovery, validate link alignment, route configuration, IP transport associations, congestion levels, and signalling point status. In a production Australian network, also correlate the event with carrier maintenance, fibre faults, power incidents, and planned work across different time zones. A documented recovery sequence should state who authorises route restoration and what evidence is required before returning traffic.
Comparing The Two Procedures
TFP and TFA should be treated as complementary state-management messages rather than independent troubleshooting commands. Their meaning depends on the destination, route context, message origin, and current MTP3 state.
| Aspect | TFP | TFA |
|---|---|---|
| Meaning | Traffic must not be transferred towards a destination on the affected route | Traffic may be transferred towards the destination again |
| Typical trigger | Link, route, gateway, or destination unavailability | Confirmed route restoration or destination reachability |
| Routing effect | Removes or restricts a route from consideration | Restores the route to the available set |
| Main risk | Traffic loss if no alternate route exists | Premature restoration and repeated failures |
| Verification | Check alarms, alternate paths, and route status | Check stable links, successful signalling, and service recovery |
A sound operational next step is to capture one complete TFP-to-TFA event in a signalling trace and map each message to the corresponding MTP3 route-state change.
