ACID

Atomicity - Consistency - Isolation - Durability

Other →
Introduced in Rel-8

ACID is a set of properties guaranteeing reliable transaction processing to ensure data integrity for network functions in 3GPP service-based architectures.

Category
Other
Introduced
Rel-8
Where
Services
Specifications
4 specs
ACID Description Purpose Detected Changes Specifications

Description

ACID is a foundational concept in database transaction management, adopted within 3GPP specifications to ensure data integrity and reliability for network functions, particularly in service-based architectures (SBA) like the 5G Core (5GC). It defines four critical properties that a transaction—a logical unit of work—must satisfy to be considered reliable, especially in distributed systems where data may be replicated or accessed concurrently.

Atomicity ensures that a transaction is treated as a single, indivisible unit of work. It follows an 'all-or-nothing' principle: either all operations within the transaction are completed successfully and committed to the database, or if any part fails, the entire transaction is rolled back, leaving the system state unchanged. This prevents partial updates that could lead to data corruption. In a 3GPP network, this is crucial during procedures like registration or session establishment where multiple network functions (NFs) must update their states coherently.

Consistency guarantees that a transaction brings the database from one valid state to another, preserving all defined rules, constraints, and relationships. It ensures that only data adhering to predefined integrity constraints (e.g., foreign keys, uniqueness) is written. For example, in a 3GPP Unified Data Repository (UDR), consistency ensures subscriber profile updates comply with schema rules, preventing invalid configurations from being stored.

Isolation ensures that concurrent execution of transactions leaves the database in the same state as if they were executed sequentially. It manages how and when changes made by one transaction become visible to others, preventing phenomena like dirty reads, non-repeatable reads, and phantom reads. In a 3GPP network, isolation is vital when multiple network exposure functions (NEFs) or applications concurrently access or modify shared data like policy rules or charging records.

Durability guarantees that once a transaction is committed, its changes persist permanently in the database, even in the event of a system failure, power loss, or crash. This is typically achieved through write-ahead logging (WAL) and data replication to non-volatile storage. For 3GPP systems, durability ensures critical data—such as subscriber authentication vectors, session contexts, or charging data records (CDRs)—is not lost, supporting billing accuracy and service continuity.

In 3GPP's service-based architecture, ACID principles are implicitly or explicitly applied in the design of data storage solutions like UDR, Unified Data Management (UDM), and Network Repository Function (NRF). They underpin the reliability of interactions between network functions via HTTP-based services, ensuring that complex, multi-step procedures across distributed NFs maintain data integrity and system stability.

Purpose & Motivation

The ACID properties exist to solve fundamental problems of data reliability and integrity in database systems, which are critical for any complex software infrastructure, including telecommunications networks. Prior to the formalization of ACID, early database systems were prone to data corruption, inconsistencies, and loss during system failures or concurrent access, leading to incorrect system states, financial discrepancies (e.g., in billing), and service disruptions. The concept provides a rigorous model to ensure that transactions—business logic operations like debiting an account or updating a subscriber profile—are processed reliably.

In the context of 3GPP standards, the adoption of ACID principles became increasingly important with the evolution towards cloud-native, service-based architectures in 4G EPC and especially 5G Core. These architectures decompose monolithic network elements into distributed, microservices-based network functions that interact asynchronously and maintain their own or shared data stores. This distribution introduces challenges of data consistency across functions during procedures like handovers or policy updates. ACID provides the theoretical foundation for designing data layers (e.g., in UDM/UDR) that can handle these complex, stateful interactions without corruption.

Specifically, 3GPP specifications reference ACID in the context of service exposure, data management, and charging (as seen in specs like 23.558, 29.558). They address the need for network APIs exposed to third-party applications (via NEF) to guarantee that data modifications are atomic and durable, preventing scenarios where an application's request partially updates network data, leading to service errors. ACID principles ensure that the network can provide predictable, trustworthy data services to both internal NFs and external consumers.

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (2 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Studied in Rel-8, normative work from Rel-17.

Rel-17 1 change

In Release 17, a specific fix was introduced to address a consistency issue within the ACID (Application Client ID) function. This correction ensures the ACID, which uniquely identifies a client application like an SA6MsgClient, is handled uniformly across various procedures such as Application Context Relocation (ACR) and EAS information provisioning. The update clarifies the role of the ACID in identifying the specific Application Client involved in network interactions and service continuity events.

Rel-18 1 change

In Release 18, the primary enhancement for the ACID function was to fix an inconsistency related to service continuity support. This involved clarifying procedures and information elements, such as the EEC's service continuity support indication in provisioning requests, to ensure consistent handling of Application Context Relocation (ACR) events identified by the ACID.

  • Fix the in-consistency for the service continuity support TS 23.558CR0378

Explore further

Broader topics and technologies where ACID plays a role.

Defining Specifications

3GPP specifications that define or reference ACID, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 23.558 vk00 Architecture for Edge Applications Rel-20
TS 29.558 vj40 Enabling Edge Applications Rel-19
TS 32.808 v1800 Common User Profile Storage Framework Rel-8
TR 33.739 vi10 Study on security enhancement of support for Rel-18