MTP2 proving failures and timer expiry scenarios
MTP2 proving is the protective stage between physical link alignment and normal SS7 signalling. Before an adjacent signalling point accepts a link for service, both ends exchange valid link status information and prove that frames can travel reliably in both directions. A failure during this period keeps the link out of service, even when the bearer appears electrically healthy.
T2, T3 and T4 expiry events are often reported as generic “proving failed” alarms. Their meaning depends on the Q.703 implementation, vendor terminology and whether the link is undergoing normal or emergency alignment. Understanding the state machine, received signal units and local timer profile is therefore more useful than treating each timer as an isolated fault.
Where proving fits in MTP2
MTP2 operates below MTP3 and carries signalling link signal units over a dedicated timeslot or IP adaptation layer. During alignment, the endpoints exchange Link Status Signal Units (LSSUs), such as alignment status messages, before accepting Fill-In Signal Units (FISUs) and Message Signal Units (MSUs) in normal operation.
The proving interval checks more than carrier presence. It tests sequence numbers, error detection, acknowledgements, octet integrity and the ability to maintain a stable receive path. A link may show a clean Ethernet interface or optical level while still failing MTP2 because of CRC errors, incorrect timeslot mapping or a mismatched signalling mode.
What T2 expiry usually indicates
T2 is commonly associated with the normal proving period. If it expires before the endpoint has observed enough valid proving traffic, the link usually returns to an alignment or out-of-service state. The immediate cause may be silence, repeated invalid frames, missing acknowledgements or a remote end that is still waiting for its own configuration to complete.
A T2 failure should be correlated with the far-end event log. If both ends report expiry at nearly the same time, investigate the path, clocking and framing first. If only one side expires, compare transmit and receive counters, link codes and the configured point code, signalling link code and adjacent point code.
T3 expiry during abnormal proving
T3 is frequently used for another proving or alignment guard interval, particularly in implementations that distinguish normal and emergency procedures. Some equipment documents T3 as a longer wait for completion of proving; other platforms expose a related timer under a different name. The exact value and state transition must come from the vendor’s MTP2 manual.
A T3 expiry often appears when the link repeatedly restarts proving without reaching the ready state. Common triggers include intermittent bit slips, a unidirectional bearer, incorrect E1 framing in regional exchanges, or an IP transport path that delivers packets in bursts. In Sydney or Melbourne carrier networks, checking the hand-off demarcation and timing source can quickly separate a local configuration error from an inter-carrier fault.
T4 and emergency proving behaviour
T4 is generally associated with the timing of an emergency alignment or a later proving safeguard, although naming differs between standards profiles and products. Emergency proving can shorten service restoration procedures, but it still requires sufficient evidence that the link is usable. A T4 expiry therefore does not mean that emergency mode has succeeded; it indicates that its permitted progress window has ended.
Repeated T4 alarms can be caused by an endpoint configured for emergency alignment while the far end permits only normal alignment. They can also follow a remote processor restart, a blocked LSSU path or a signalling link accidentally connected to the wrong adjacent point code. On Brisbane and Queensland routes, planned maintenance after cyclone-related power events can produce this pattern when one transmission shelf reboots before its mate.
Comparing the expiry scenarios
| Timer event | Typical proving context | Observable symptom | Useful first checks |
|---|---|---|---|
| T2 expiry | Normal proving interval | Link leaves proving without reaching ready | LSSU reception, CRC counts, framing and timer profile |
| T3 expiry | Extended or alternate proving guard | Repeated alignment attempts or delayed activation | Emergency/normal mode, clock source and packet loss |
| T4 expiry | Emergency proving or final safeguard | Emergency alignment aborts or falls back | Remote configuration, state transitions and restart history |
Timer labels should never be interpreted without the state in which the timer started. A T2 alarm during initial alignment is a different event from T2 expiry after an endpoint has already exchanged proving messages. Capture the state transition, timer start reason and last received signal unit in the same diagnostic record.
Transport faults that imitate timer problems
On TDM, slips, bipolar violations, incorrect CRC4 settings and a reversed transmit/receive pair are frequent causes. On SIGTRAN, MTP2 is normally adapted through M2PA or M2UA, so packet loss, SCTP association resets, congestion and incorrect stream handling can create equivalent symptoms. An IP path can be reachable by ping while signalling traffic is discarded or delayed.
Australian operators also need to account for long geographic paths between Perth, Sydney and Melbourne, along with managed-service hand-offs where the carrier and enterprise monitor different layers. Compare packet captures or span data at both ends, and check whether latency spikes coincide with the proving window rather than relying on average round-trip time.
A disciplined troubleshooting method
Start with the event timeline: physical interface up, alignment started, LSSU sent, LSSU received, proving timer started, timer expired and link state changed. Then compare both endpoints using the same time source. A clock difference can make a short failure look like a sequence of unrelated alarms.
Next, verify point-code addressing, link code, service indicator handling, bit rate, framing, clock priority and normal-versus-emergency settings. Confirm that the signalling link is connected to the intended adjacent signalling point, not merely to a port that accepts electrical or IP traffic. Preserve a short trace around each expiry before restarting the link.
Preventing repeat failures in production
Use timer values supplied for the deployed MTP2 profile rather than copying settings from another switch. Record the standard revision, vendor release and any carrier-specific modifications. Alarm rules should distinguish a single expiry during maintenance from repeated expiries that indicate a degrading bearer.
For higher-layer effects, proving failures can delay call setup, mobility transactions and SMS delivery after a link oscillates. The relationship between signalling timers and transaction delays is also relevant when reviewing TCAP timeout behaviour, especially where MTP3 reroutes traffic across a congested alternate link.
In an Australian network, schedule controlled tests outside major operational windows such as weekday business peaks in Sydney or Melbourne, and document carrier escalation contacts before isolating a live link. The next practical step is to collect a dual-ended trace containing the MTP2 state, last LSSU, timer name and expiry timestamp for the next failure.
