Class 1 Elementary Procedure (with response)

Description

Class 1 is a classification of Elementary Procedures (EPs) used throughout 3GPP control-plane protocol specifications. An Elementary Procedure is the smallest unit of interaction between two protocol entities, consisting of an initiating message and, depending on its class, one or more response messages. Class 1 EPs are defined as procedures that are always answered: the receiving node replies with either a success message (often named with the suffix 'Response', 'Complete', or 'Acknowledge') or a failure message (typically named 'Failure' or 'Unsuccessful'). This request-response pattern makes Class 1 procedures reliable and synchronous at the application-protocol level, even though the underlying transport (SCTP, or in older interfaces SCCP/M3UA) is asynchronous.

The concept appears in the 'Elementary Procedure' sections of interface-specific specifications such as 25.413 (RANAP), 25.419 (BSSAP-LE), 25.453 (PCAP), 25.469 (S1AP is actually 36.413; 25.469 covers other UTRAN signalling), 29.168 (Nq/Nq' for MME/SGSN), 29.171 (LCS-AP), 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 (various). Each of these specifications contains a clause listing its elementary procedures and classifying them as Class 1 or Class 2. For example, in NGAP, the Initial Context Setup procedure is Class 1 because the AMF expects an Initial Context Setup Response or Failure from the gNB. In contrast, procedures such as Paging or Error Indication are Class 2 because they are not answered.

Architecturally, Class 1 procedures are implemented by the protocol state machine in each node. When a node sends the initiating message, it starts a timer (for example, the T_ngap or a procedure-specific guard timer). If the peer responds with the success or failure message before the timer expires, the procedure completes normally. If the timer expires, the initiating node treats the procedure as failed and may trigger error handling, connection release, or a reset procedure. This timer-based supervision is what gives Class 1 procedures their dependable, transactional character.

The success and failure responses are not merely acknowledgements; they carry substantive information. A success response typically contains result IEs such as allocated resources, accepted configurations, or identifiers, while a failure response carries a Cause IE explaining why the request could not be fulfilled (for example, 'radio-network: radio-connection-with-UE-lost' or 'misc: unspecified'). This allows the initiating node to make informed decisions, such as retrying with different parameters, releasing resources, or reporting the failure to a management entity.

Class 1 procedures are fundamental to mobility, session management, and resource control. Handover preparation, UE context setup and release, bearer or PDU session establishment, and security mode command are all Class 1. Because they are answered, they provide the deterministic behaviour required for state synchronisation between peer nodes. The distinction between Class 1 and Class 2 is therefore not cosmetic: it determines whether a procedure has a defined completion event, whether timers are needed, and how error conditions are surfaced to the rest of the system.

Purpose & Motivation

Class 1 exists to give 3GPP control-plane protocols a clear, standardised way to model transactional interactions between network nodes. In any signalling system, some messages need confirmation and some do not. Without an explicit classification, implementers would have to infer from each procedure's semantics whether a reply is expected, leading to interoperability problems. Class 1 formalises the 'request must be answered' contract, so that both peers know a procedure is complete only when a success or failure message has been received.

The classification also solves the problem of error handling. Before such conventions were standardised, failures could be silent, leaving nodes in inconsistent states. By requiring a failure response with a Cause IE, Class 1 ensures that the initiating node is always informed of the outcome and can take corrective action. This is especially important in radio access networks, where resources are scarce and state mismatches between a base station and a core network node can cause dropped calls or stranded bearers.

Historically, the Class 1/Class 2 distinction was introduced with the first 3GPP interface specifications in Release 4 (and inherited from earlier 3GPP TSG RAN and CN work). It has been carried forward essentially unchanged into every subsequent release and every new interface — from UTRAN's RANAP through LTE's S1AP to 5G's NGAP, XnAP, and F1AP. This longevity demonstrates that the simple request/response abstraction remains the right design for control-plane signalling, even as the underlying radio and core technologies have been completely replaced.