MTP3 message types and their functions
Message Transfer Part level 3 (MTP3) is the network-layer component of SS7 that directs signaling traffic between signaling points. It works above MTP1 and MTP2, using routing labels, signaling point codes, and network management procedures to keep messages moving through the signaling network.
Understanding the MTP3 level message types and their functions makes SS7 traces easier to interpret. Some messages manage traffic during failures, while others report route availability, control congestion, or notify neighboring nodes that a user part cannot be reached.
MTP3 control messages are different from user-part payloads such as ISUP and SCCP. ISUP may request call setup, for example, but MTP3 decides how that signaling information is routed and how the network responds when a link or destination becomes unavailable.
How MTP3 fits into SS7
MTP3 receives signaling messages from higher layers and examines the destination point code in the routing label. It selects an outgoing link set, balances traffic across available links, and passes the message to MTP2 for transmission over a signaling link.
The level also monitors network conditions. When a signaling link fails, a route becomes congested, or a destination cannot be reached, MTP3 generates or processes network management messages. These procedures help prevent message loss and coordinate alternate routing.
Engineers looking for a broader explanation of PSTN signaling, ISUP, SIGTRAN, and related protocols can use these SS7 training resources as a foundation before examining packet captures.
The structure of an MTP3 message
An MTP3 message normally includes the Service Information Octet, a routing label, and a message-specific field. The Service Information Octet identifies the service indicator and network indicator, helping the receiving node determine which higher-layer protocol or network context applies.
The routing label typically contains the originating point code, destination point code, and signaling link selection field. MTP3 control messages then add a message type code and parameters that describe the event, such as the affected destination, link set, or restricted route.
The exact coding can vary between ITU-T and ANSI implementations. The names and operational principles remain similar, but point-code formats, network indicators, and some optional procedures should always be checked against the applicable standard.
Traffic management during failures
Changeover messages are used when a signaling link fails. A Changeover Order (COO) tells a neighboring node to move traffic away from the failed link, while a Changeover Acknowledgement (COA) confirms that the receiving node has accepted the procedure. Emergency variants, ECO and ECA, support accelerated handling when normal coordination is insufficient.
Changeback procedures reverse that action after a link returns to service. A Changeback Declaration (CBD) announces that traffic may be restored, and a Changeback Acknowledgement (CBA) confirms coordination. These exchanges help avoid duplicate delivery, message misordering, and abrupt traffic shifts.
MTP3 also uses Traffic Restart Allowed (TRA) during recovery from a broader outage or restart. It indicates that traffic may resume toward a destination after the required routing and synchronization conditions have been met.
Route status messages and their effects
Transfer status messages describe whether a signaling point or route can accept traffic. Transfer Prohibited (TFP) blocks traffic toward a destination, Transfer Allowed (TFA) announces that the destination is reachable again, and Transfer Restricted (TFR) warns that routing is possible but should be limited or selected carefully.
A receiving node uses these indications to update its routing tables and make local decisions. For example, a TFP can cause traffic to be redirected through an alternate route, while a TFA can restore a previously suppressed route.
| Message type | Main purpose | Typical routing effect |
|---|---|---|
| TFP | Reports that a destination is unavailable | Stop routing traffic toward the destination |
| TFA | Reports that a destination is reachable | Restore normal routing where appropriate |
| TFR | Reports limited or degraded availability | Prefer alternate paths or restrict traffic |
| COO | Announces link failure and traffic diversion | Move traffic to another link |
| COA | Confirms changeover coordination | Complete the diversion procedure |
| TRA | Permits traffic after restart recovery | Resume signaling under controlled conditions |
| UPU | Reports an unavailable user part | Notify the originator that service cannot be reached |
User-part and congestion notifications
User Part Unavailable (UPU) is sent when a higher-layer service, such as ISUP or SCCP, is unavailable at a destination. It does not necessarily mean that the entire signaling point has failed. Instead, it identifies a particular user part and may include information about the affected service.
This distinction matters during fault analysis. A node might continue handling SCCP traffic while ISUP is unavailable, or it might support one subsystem but reject another. Treating every UPU as a complete point-code failure can lead to incorrect routing and unnecessary alarms.
MTP3 also supports procedures for signaling route set testing and congestion control. These messages help nodes verify route availability and avoid sending excessive traffic into a congested signaling path. Timer values and implementation behavior influence how quickly status changes propagate.
Practical checks for trace analysis
When reading an MTP3 capture, focus on the relationship between the message type, the affected point code, and the subsequent routing decision. A single TFP is more meaningful when followed by traffic diversion, repeated route tests, or a later TFA.
Useful operational checks include:
- Confirm whether the message is an MTP3 network management message or a user-part payload.
- Decode the originating and destination point codes before interpreting the event.
- Correlate COO, COA, CBD, and CBA messages with link-state alarms and MTP2 status.
- Check whether TFP, TFA, or TFR changes the selected route in subsequent signaling units.
- Compare timer behavior with the relevant ITU-T or ANSI implementation guide.
MTP3 analysis becomes clearer when message sequences are studied as procedures rather than isolated packets. A changeover, for instance, is a coordinated exchange designed to protect traffic during failure, not merely an alert that a link has gone down.
Apply these concepts to live traces, signaling gateways, and SIGTRAN deployments to identify route failures faster and understand how SS7 networks preserve service continuity.
