Class 2 Elementary Procedure (without response)

Description

Class 2 is the second category of Elementary Procedures (EPs) in 3GPP control-plane protocol specifications. Unlike Class 1, a Class 2 procedure consists of a single initiating message that is not answered by the peer entity. There is no success response and no failure response; the procedure is considered complete as soon as the message has been sent (and, depending on the transport, acknowledged at lower layers). This 'fire-and-forget' model is appropriate for information that is either inherently unreliable, time-critical, or where a response would add no value.

The concept is defined alongside Class 1 in the Elementary Procedure clauses of interface specifications such as 25.413 (RANAP), 25.419 (BSSAP-LE), 25.453 (PCAP), 25.469, 25.471, 29.168, 29.171, 36.413 (S1AP), 36.443 (M2AP), 36.444 (M3AP), 36.459 (LPPa), 37.483 (E1AP), 38.413 (NGAP), 38.463 (XnAP), 38.473 (F1AP), and 48.049. In each specification, procedures are explicitly classified, and Class 2 procedures are those without a response message defined.

Typical Class 2 procedures include Paging, Error Indication, Overload Start/Stop, Reset (in some interfaces), and various notification procedures. For example, in NGAP the Paging procedure is Class 2: the AMF sends a Paging message to one or more gNBs and does not expect any reply. The gNB simply attempts to page the UE and, if successful, the UE responds via a separate uplink procedure (such as Service Request) that is itself Class 1. Similarly, Error Indication is Class 2 because it is a notification of a protocol error, not a request for action.

Architecturally, Class 2 procedures simplify protocol design by removing the need for response state machines and guard timers on the initiating side. The sending node does not maintain a pending-procedure context for a Class 2 message. However, this does not mean Class 2 messages are unreliable at the transport layer: on SCTP-based interfaces, the message is still delivered reliably and in order within its stream. The distinction is at the application-protocol level: no application-level response is defined. On older SS7-based interfaces, Class 2 messages might be sent over unreliable transport, but the protocol semantics remain the same — no response is expected.

Because there is no response, error handling for Class 2 procedures relies on other mechanisms. If a Class 2 message is malformed or cannot be processed, the receiver may send an Error Indication (itself Class 2) or simply discard the message and log the event. The initiating node cannot know whether the procedure succeeded, so Class 2 is used only where this is acceptable — for example, paging, where the paging attempt is inherently best-effort and success is signalled by a separate uplink message.

Class 2 procedures are essential for efficient signalling. They reduce message flow and latency for operations that do not require confirmation, and they keep the protocol state machines simple. The Class 1/Class 2 distinction is one of the foundational design patterns of 3GPP control-plane protocols and has been preserved across every generation from UTRAN to 5G NR.

Purpose & Motivation

Class 2 exists to formalise the set of 3GPP elementary procedures that do not require a response. In any signalling protocol, some interactions are naturally one-way: paging a mobile device, broadcasting overload information, or reporting an error. Forcing these into a request/response pattern would add unnecessary messages, latency, and state complexity. Class 2 provides a standard way to declare that a procedure is complete upon transmission, so that implementers do not have to guess whether a reply is expected.

The classification also prevents protocol deadlocks. If a node incorrectly expected a response to a paging message, it would start a timer and eventually declare a failure, even though paging is inherently best-effort. By defining such procedures as Class 2, the specifications make it clear that no timer or response handling is needed, and that success must be inferred from other events (such as the UE initiating a service request).

Historically, Class 2 was introduced together with Class 1 in Release 4, inheriting conventions from earlier 3GPP and pre-3GPP interface specifications. It has been carried forward unchanged into every subsequent release and every new interface, including S1AP, NGAP, XnAP, and F1AP. Its persistence reflects the enduring need for a clean, standardised way to model one-way signalling in complex radio and core network protocols.