Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)
obsoleted by
- rfc-4666 — Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)
Extracted elements (29)
M3UA does not impose the SS7 MTP Level 2 272-octet SIF length limit, allowing larger signalling blocks to be carried natively over SCTP without upper-layer segmentation. However, when an SG interworks to an SS7 network that does not support larger blocks, the 272-octet limit MUST be observed at the SG to prevent downstream ISUP or SCCP fragmentation.
SCTP is the recommended transport for M3UA because it provides explicit packet-oriented delivery, multi-stream in-sequence delivery, multi-homing for network-level fault tolerance, resistance to flooding and masquerade attacks, and MTU-aware data segmentation. TCP MAY be substituted only in back-to-back connections without redundancy requirements.
The Routing Context parameter (a 4-byte integer) acts as an index into a Message Distribution Table with a 1:1 mapping to a Routing Key. This allows an ASP to process traffic for multiple Application Servers over a single SCTP association, with ASPAC/ASPIA messages discriminated by Routing Context.
When an ASP is connected to more than one SGP, the same SS7 network context may be assigned different Network Appearance values at each SGP. The M3UA layer at the ASP must independently maintain availability, restriction, and congestion status per route and derive a combined destination status to present correctly to MTP3-Users.
All fields in an M3UA message MUST be transmitted in network byte order (most significant byte first, big endian) unless otherwise stated.
MTP3 management messages (such as TFPs or TFAs received from the SS7 network) MUST NOT be encapsulated as Data message Payload Data and sent from SG to ASP or from ASP to SG. The SG MUST terminate these messages and generate appropriate M3UA SSNM messages.
Routing Keys SHOULD be unique such that each received SS7 signalling message has a full or partial match to exactly one routing result. Parameter range values within a Routing Key need not be contiguous (e.g., non-contiguous CIC ranges for an AS).
The total length of a parameter (Tag + Length + Value) MUST be a multiple of 4 bytes. Senders pad with all-zero bytes after the Value field; the padding length is NOT included in the Parameter Length field. The receiver MUST ignore padding bytes.
To avoid redundant SCTP associations between M3UA peers, one side SHOULD be designated as client. The default is for the SGP to be the server and the ASP to be the client; ASPs SHOULD initiate the SCTP association to the SGP. The registered SCTP/TCP port for M3UA is 2905.
Traffic requiring in-sequence delivery SHOULD be assigned to the same SCTP stream. MTP3-User traffic may be mapped to streams based on the SLS value in the MTP3 Routing Label or the ISUP CIC assignment, subject to the maximum stream count supported by the SCTP association.
Where the optional Network Appearance parameter is present in a message, it MUST be the first parameter, because it defines the Point Code format used in the Protocol Data field.
M3UA defines nine message classes: Management/MGMT (0), Transfer (1), SS7 Signalling Network Management/SSNM (2), ASP State Maintenance/ASPSM (3), ASP Traffic Maintenance/ASPTM (4), Routing Key Management/RKM (9). Classes 10–127 are reserved by IETF; 128–255 are for IETF-defined extensions.
The ASP State Maintenance (ASPSM) message class contains: ASP Up (ASPUP, type 1), ASP Down (ASPDN, type 2), Heartbeat (BEAT, type 3), and their acknowledgements (ASPUP ACK, ASPDN ACK, BEAT ACK). These establish and monitor the operational readiness of the ASP without reference to specific traffic streams.
The ASP Traffic Maintenance (ASPTM) message class contains: ASP Active (ASPAC, type 1), ASP Inactive (ASPIA, type 2), and their acknowledgements (ASPAC ACK, ASPIA ACK). These control which ASPs are actively processing traffic for a given Routing Context within an Application Server.
The DATA message carries SS7 MTP3-User protocol data as an MTP-TRANSFER primitive. It contains optional Network Appearance (Tag 0x0200), optional Routing Context (Tag 0x0006), mandatory Protocol Data (Tag 0x0210), and optional Correlation Id (Tag 0x0013). Where multiple Routing Keys share a common association, Routing Context MUST be sent to identify the traffic flow.
The Management (MGMT) message class contains Error (ERR, type 0) and Notify (NTFY, type 1) messages, used to report protocol errors and state change notifications respectively. ERR carries an Error Code parameter; NTFY carries a Status parameter. Both trigger M-ERROR and M-NOTIFY indications to Layer Management.
The Network Appearance parameter (Tag 0x0200, 32-bit unsigned integer) identifies the SS7 network context for a message, implicitly specifying the Point Code format, Network Indicator value, and MTP3 variant/version. Its value has local significance only and is coordinated between SGP and ASP; the same SS7 network may map to different Network Appearance values at different SGPs.
The Routing Key Management (RKM) message class provides dynamic Routing Key provisioning: Registration Request (REG REQ, type 1), Registration Response (REG RSP, type 2), Deregistration Request (DEREG REQ, type 3), and Deregistration Response (DEREG RSP, type 4). This is an alternative to static configuration via a management interface.
The SCON message may carry a Congestion Indications parameter (Tag 0x0205) with a Congestion Level field (8 bits): 0=No Congestion/Undefined, 1=Level 1, 2=Level 2, 3=Level 3. This supports national MTP networks with multiple congestion thresholds (e.g., ANSI MTP3); for ITU networks without multiple levels the parameter is omitted.
The SSNM message class carries SS7 network management events: Destination Unavailable (DUNA), Destination Available (DAVA), Destination State Audit (DAUD), Signalling Congestion (SCON), Destination User Part Unavailable (DUPU), and Destination Restricted (DRST). Each carries a mandatory Affected Point Code and optional Network Appearance, Routing Context, and INFO String.
IANA assigned SCTP Payload Protocol Identifier 3 to M3UA (Section 7.1) and registered port number 2905 for M3UA over both SCTP and TCP (Section 7.2). IANA also maintains a registry for M3UA Protocol Extensions covering Message Classes, Message Types per class, and Parameter Tags; values 0x0214–0xffff for Parameter Tags are reserved by the IETF.
M3UA operating over IP is exposed to threats not present in traditional SS7 physical networks, including masquerade of legitimate signalling nodes, replay of signalling messages, and interception of SS7 user data. Unauthorized access to M3UA signalling can enable fraud, eavesdropping, and denial of service to PSTN services.
To protect confidentiality and integrity of M3UA signalling, use of network-layer (IPsec) or transport-layer security is recommended. SCTP provides inherent resistance to flooding and masquerade attacks but does not itself provide confidentiality of user data.
Application Server (AS) states are: AS-DOWN (no ASPs available), AS-INACTIVE (one or more ASPs inactive, none active), AS-ACTIVE (one or more ASPs active), and AS-PENDING (last active ASP departed; awaiting recovery within a T(r) timer). State transitions trigger M-AS_ACTIVE, M-AS_INACTIVE, and M-AS_DOWN indications to Layer Management.
ASP states progress: ASP-DOWN (initial/SCTP down) → ASP-INACTIVE (ASPUP/ASPUP ACK exchanged) → ASP-ACTIVE (ASPAC/ASPAC ACK exchanged). Reverse transitions occur via ASPDN (to ASP-DOWN) and ASPIA (to ASP-INACTIVE). Loss of the SCTP association causes an immediate transition to ASP-DOWN regardless of current state.
All M3UA parameters use a Tag-Length-Value (TLV) format: Parameter Tag (16 bits, unsigned), Parameter Length (16 bits, includes Tag+Length+Value but not padding), and variable-length Parameter Value. Parameters may appear in any order unless explicitly mandated; receivers SHOULD accept them in any order.
The Affected Point Code parameter encodes a list of 32-bit entries each containing an 8-bit Mask and a 24-bit Point Code. ANSI 24-bit PCs are encoded directly; ITU 14-bit PCs are left-padded to 24 bits. A Mask value equal to or greater than the PC bit-width signals that the entire network appearance is affected (network isolation).
The Common Message Header consists of four 8-bit fields — Version, Reserved, Message Class, Message Type — followed by a 32-bit Message Length. The Length includes the Common Header and all parameter padding bytes.
The Protocol Data parameter (Tag 0x0210) encodes the full MTP3 routing label: Originating Point Code (32 bits), Destination Point Code (32 bits), Service Indicator/SI (8 bits), Network Indicator/NI (8 bits), Message Priority/MP (8 bits), Signalling Link Selection/SLS (8 bits), followed by variable-length User Protocol Data. Point Codes are right-justified; unused bits are coded '0'.