Signalling Connection Control Part User Adaptation Layer (SUA)
Extracted elements (28)
SUA is designed to be modular and symmetric to support both an SG-to-ASP architecture (interworking SS7 and IP) and a peer-to-peer IPSP architecture (all-IP, no SG required). This symmetry avoids duplicating protocol machinery for the two deployment modes.
The Address Mapping Function (AMF) is specified as implementation-dependent (local tables, DNS, LDAP, etc.) rather than mandated, because address resolution mechanisms vary widely across deployments and standardizing one mechanism would unnecessarily constrain implementations.
At a Signalling Gateway, SUA interworks with SCCP by translating SCCP management primitives (SSP, SSA, SST, SSC) to SUA SNM messages (DUNA, DAVA, DAUD, DRST, DUPU, SCON) and vice versa; full SCCP–SUA interworking procedures for both connectionless and connection-oriented transfer are defined in section 4.7.
A sender SHOULD NOT pad a TLV parameter with more than 3 bytes. The receiver MUST ignore padding bytes.
For protocol class 1 (sequenced connectionless), SUA MUST select ordered SCTP delivery; the stream is selected based on the sequence parameter from the upper layer and other traffic information.
For protocol classes 2 and 3 (connection-oriented), SUA MUST select ordered SCTP delivery; the stream is selected based on the source local reference of the connection and other available traffic information.
Routing keys MUST NOT span multiple network appearances. A received SS7 signalling message cannot be directed to more than one Routing Key; Routing Keys are mutually exclusive.
The total length of a TLV parameter (Tag + Length + Value fields) MUST be a multiple of 4 bytes. The sender pads with all-zero bytes after the Parameter Value field as needed; padding length is not included in the Parameter Length field.
Message Classes 0–9 are defined: MGMT (0), SNM (2), ASPSM (3), ASPTM (4), Connectionless (7), Connection-Oriented (8), and RKM (9). Classes 1, 5, and 6 are reserved. Classes 10–127 are reserved by IETF; 128–255 are reserved for IETF-defined extensions.
Release Request (RELRE) and Release Complete (RELCO) messages tear down connection-oriented sessions. RELRE carries mandatory Routing Context, Destination Reference Number, Source Reference Number, and SCCP Cause. RELCO carries Routing Context, both reference numbers, and optional Importance. Cover SCCP RLSD and RLC.
Routing Key Management (RKM) messages (REG REQ, REG RSP, DEREG REQ, DEREG RSP) support dynamic registration and deregistration of Routing Keys between an ASP and its SGP, as an alternative to static provisioning via MIB or external database.
The Connection Acknowledge (COAK) message confirms a CORE. Mandatory parameters: Routing Context, Protocol Class, Destination Reference Number, Source Reference Number, Sequence Control, and Credit (class 3 only). Destination Address is included when the received CORE conveyed a Source Address. Covers SCCP CC.
The Connection Oriented Data Transfer (CODT) message carries connection-oriented data; it represents DT1 (Sequence Number present with 'more' indicator), DT2 (Sequence Number present with P(S)/P(R)/more), or Expedited Data (Sequence Number absent) depending on presence of the Sequence Number parameter.
The Connection Request (CORE) message establishes a signalling connection. Mandatory parameters: Routing Context, Protocol Class, Source Reference Number, Destination Address, Sequence Control. Sequence Number and Credit are mandatory only for protocol class 3. Covers SCCP CR.
The Connectionless Data Response (CLDR) message reports errors in a received CLDT when the return-on-error option is set. Mandatory parameters: Routing Context, SCCP Cause, Source Address, Destination Address. Covers SCCP UDTS, XUDTS, and LUDTS messages.
The Connectionless Data Transfer (CLDT) message transfers data between SUA peers. Mandatory parameters: Routing Context, Protocol Class, Source Address, Destination Address, Sequence Control, Data. Optional: SS7 Hop Count, Importance, Message Priority, Correlation ID, Segmentation. Covers SCCP UDT, XUDT, and LUDT messages.
The Network Appearance is an SUA local integer reference shared by SG and AS that, together with a Signalling Point Code, uniquely identifies an SS7 node by indicating the specific SS7 network it belongs to.
The Routing Context parameter uniquely identifies an Application Server from the perspective of an SGP or ASP. There is a 1:1 relationship between a Routing Context value and a Routing Key within an AS; it functions as an index into an AS Table containing the AS Routing Keys.
The Signalling Network Management (SNM) messages—DUNA, DAVA, DAUD, SCON, DUPU, DRST—carry SS7 network status information from the SG to ASPs, notifying them of destination unreachability, reachability, congestion, restricted state, and user-part unavailability.
The SS7 Hop Count parameter prevents routing loops in relay scenarios. The originating node sets the counter to a maximum value (≤15); each relay node decrements it. When the counter reaches zero, return or refusal procedures are invoked with reason 'Hop counter violation'.
IANA assigns an SCTP Payload Protocol Identifier for SUA (value 4) in the SCTP Payload Protocol Identifiers registry.
IANA assigns well-known port 14001 (SCTP and TCP) for SUA in the port number registry.
IANA manages SUA protocol extension registries for Message Classes, Message Types (per class), Parameter Tags, and Error Codes. Within each namespace, values 0–127 are reserved by IETF and 128–255 are reserved for IETF-defined extensions; requests for new values require IETF Review.
SUA transports SS7 SCCP-user signalling (including sensitive MAP/CAP messages) over IP. The RFC recommends use of IPsec to provide authentication, integrity, and confidentiality for SUA associations; without such protection, an attacker with IP network access could inject or intercept signalling messages.
An Application Server (AS) transitions among AS-DOWN, AS-INACTIVE, AS-ACTIVE, and AS-PENDING states based on the aggregate state of its constituent ASPs. AS-PENDING is entered when the last active ASP becomes unavailable, causing the SGP to buffer messages for timer T(r) until an ASP becomes available or T(r) expires.
An ASP transitions among three states: ASP-DOWN (no active SCTP association or not yet initialized), ASP-INACTIVE (SCTP association established but not processing traffic), and ASP-ACTIVE (processing traffic). Transitions are driven by ASP Up/Down/Active/Inactive messages and SCTP association events.
SUA parameters use a Tag-Length-Value (TLV) format: Parameter Tag (16-bit unsigned integer, 0–65535), Parameter Length (16-bit unsigned integer, includes Tag+Length+Value but excludes padding), and variable-length Parameter Value. Total parameter length MUST be a multiple of 4 bytes; padding bytes are zero-filled and NOT counted in the Length field.
The Common Message Header is 8 bytes: Version (8 bits), Reserved (8 bits), Message Class (8 bits), Message Type (8 bits), and Message Length (32 bits, includes header and all padding). The data portion carries SCCP-User data directly, not an encapsulated SCCP message.