Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer
Extracted elements (30)
M2UA supports an n+k redundancy model (active-standby, load-sharing, or broadcast) where n ASPs handle traffic and k additional ASPs are available for fail-over. The 1+1 active/standby and simplex 1+0 models are subsets. This allows flexible high-availability configurations for the SG-to-MGC signaling path.
SCTP was chosen as the transport because it provides explicit packet-oriented delivery, multi-stream sequenced delivery, multi-homing for network-level fault tolerance, resistance to flooding and masquerade attacks, and data segmentation. TCP is permitted as an alternative only in scenarios where redundancy is not required or is provided below the transport layer.
The Interface Identifier is placed in the M2UA message header (rather than derived from the SCTP stream) because SCTP streams are unidirectional: a M2UA layer has no visibility into its peer's stream assignments, so an explicit per-message identifier is required to demultiplex SS7 links.
The optional Correlation Id parameter on Data messages allows an SGP implementation to obtain confirmation that an MSU was delivered to the M2UA peer before acknowledging it to the SS7 peer, eliminating the risk of message loss due to SCTP association failure or congestion.
The Japanese TTC variant of SS7 uses a distinct Protocol Data 2 parameter (Tag 0x301) instead of the standard Protocol Data 1 (Tag 0x300); TTC PDUs begin at the Length Indicator (LI) octet rather than the Signalling Information Octet (SIO), and the spare bits of the LI are used for priority.
A peer MUST send a Heartbeat Ack (BEAT ACK) in response to every Heartbeat (BEAT) message, echoing all parameters of the received BEAT without change.
All fields in an M2UA message MUST be transmitted in network byte order (most significant byte first, big endian) unless otherwise stated.
It is recommended that both SGP and ASP support both client and server roles. ASPs SHOULD initiate the SCTP association to the SGP. The registered SCTP and TCP port number for M2UA is 2904.
Mandatory parameters MUST be placed before optional parameters in a message. Parameter total length (Tag+Length+Value) MUST be a multiple of 4 bytes; a sender MUST NOT pad with more than 3 bytes; the receiver MUST ignore padding bytes.
Message Length MUST include parameter padding bytes. Message Length MUST NOT be longer than a MTP3 message plus the length of the common and M2UA message headers.
SCTP Stream 0 SHOULD NOT be used for MAUP messages; Stream 0 SHOULD only be used for ASP Management (ASPM) messages. Separate SCTP streams are recommended per SS7 link or per SLS to minimize transmission and buffering delay.
The ASP Identifier MUST be used in the ASPUP message where the SGP cannot identify the ASP by pre-configured address/port number information (e.g., when the ASP uses dynamic address/port assignment).
The Data Ack message MUST be sent if a Correlation Id parameter is received from the peer. The Data Ack message MUST NOT be sent if no Correlation Id was received. Failure to send Data Acks will eventually cause SS7 link failure due to lack of MTP Level 2 acknowledgments.
The integer formatted Interface Identifier MUST be supported; the text formatted Interface Identifier MAY optionally be supported. When the optional Interface Identifier parameter is present in ASPAC, integer format MUST be supported while text MAY be supported.
The M2UA layer MUST maintain a map of Interface Identifier to physical interface, and MUST also maintain a map of Interface Identifier to SCTP association and stream. The SGP MUST maintain AS/ASP states and reference them during routing of messages.
The SGP SHALL send a Congestion Indication message when the congestion or discard level changes (differs from previously sent message), and SHALL use an implementation-dependent algorithm to limit the frequency of such messages.
ASPSM (Message Class 3) messages handle ASP lifecycle: ASP Up (1), ASP Down (2), Heartbeat (3), ASP Up Ack (4), ASP Down Ack (5), Heartbeat Ack (6). ASPTM (Message Class 4) handles traffic activation: ASP Active (1), ASP Inactive (2), ASP Active Ack (3), ASP Inactive Ack (4).
Congestion Status and Discard Status parameters (Tags 0x304 and 0x305, Length=8 each) encode SS7 link congestion levels: LEVEL_NONE (0x0), LEVEL_1 (0x1), LEVEL_2 (0x2), LEVEL_3 (0x3). Networks without multiple congestion levels use only LEVEL_NONE and LEVEL_3.
MAUP (Message Class 6) message types: Data (1), Establish Request (2), Establish Confirm (3), Release Request (4), Release Confirm (5), Release Indication (6), State Request (7), State Confirm (8), State Indication (9), Data Retrieval Request (10), Retrieval Confirm (11), Retrieval Indication (12), Retrieval Complete Indication (13), Congestion Indication (14), Data Acknowledge (15).
Message Class field (8-bit unsigned) identifies the protocol adaptation layer: 0=MGMT, 3=ASPSM, 4=ASPTM, 6=MAUP (M2UA-specific MTP2 user adaptation messages), 10=IIM (Interface Identifier Management). Values 11-127 are reserved by IETF; 128-255 reserved for IETF-defined extensions.
State Indication Event parameter (Tag 0x303, Length=8) carries a 32-bit Event value reporting SS7 link conditions: EVENT_RPO_ENTER (0x1), EVENT_RPO_EXIT (0x2), EVENT_LPO_ENTER (0x3), EVENT_LPO_EXIT (0x4), indicating remote/local processor outage entry and exit.
State Request/Confirm parameter (Tag 0x302, Length=8) carries a 32-bit State value: STATUS_LPO_SET (0x0), STATUS_LPO_CLEAR (0x1), STATUS_EMER_SET (0x2), STATUS_EMER_CLEAR (0x3), STATUS_FLUSH_BUFFERS (0x4), STATUS_CONTINUE (0x5), STATUS_CLEAR_RTB (0x6), STATUS_AUDIT (0x7), STATUS_CONG_CLEAR (0x8), STATUS_CONG_ACCEPT (0x9), STATUS_CONG_DISCARD (0xa).
Traffic Mode Type parameter (Tag 0x0b, Length=8) in ASPAC/ASPAC Ack specifies how an ASP operates within an AS: Override (0x1, primary/backup take-over), Load-share (0x2, traffic distribution), Broadcast (0x3, all active ASPs receive all traffic). Only one mode per AS is permitted.
IANA assigned SCTP Payload Protocol Identifier value for M2UA (Section 8.1). M2UA-specific parameter tags occupy the range 0x0300-0x03FF (768-784 defined), while common adaptation layer parameters occupy 0x00-0xFF. IETF reserves message class values 11-127; values 128-255 are reserved for IETF-defined extensions.
Section 7.1 identifies threats including unauthorized peers injecting or modifying SS7 signaling messages over the IP backhaul path between SG and MGC. An attacker gaining access to the M2UA/SCTP channel could disrupt or manipulate SS7 call processing.
Section 7.2 recommends protecting the confidentiality and integrity of M2UA traffic using IPsec or TLS to secure the SCTP associations between SG and MGC, preventing eavesdropping and tampering with backhauled SS7 signaling.
ASP states are DOWN, INACTIVE, and ACTIVE. Transitions: DOWN→INACTIVE triggered by sending/receiving ASP Up/ASP Up Ack; INACTIVE→ACTIVE triggered by ASP Active/ASP Active Ack; ACTIVE→INACTIVE by ASP Inactive/ASP Inactive Ack; any→DOWN by ASP Down/ASP Down Ack or SCTP association loss. State is maintained at both SGP and ASP sides.
Common Message Header is 8 bytes: Version (8 bits), Spare (8 bits), Message Class (8 bits), Message Type (8 bits), followed by Message Length (32 bits) inclusive of the header. All fields are transmitted in network byte order.
M2UA Message Header (integer Interface Identifier): Tag=0x1, Length=8, followed by 32-bit Interface Identifier. Alternatively, text-based Interface Identifier uses Tag=0x3, variable length, encoded in ANSI X3.4-1986, max 255 octets. This header immediately follows the Common Message Header and is only used with MAUP messages.
Variable-Length Parameters use a Tag-Length-Value format: Parameter Tag (16 bits unsigned), Parameter Length (16 bits, includes Tag+Length+Value fields), Parameter Value (variable). The total parameter length MUST be a multiple of 4 bytes; senders pad with zero bytes (not counted in length field), max 3 padding bytes.