Description
Capacity Deallocation (CD) is a fundamental resource management mechanism within 3GPP networks, designed to dynamically release allocated network resources when they are no longer actively needed. This process is integral to the Operation, Administration, and Maintenance (OAM) framework, specifically within the Performance Management (PM) and Fault Management (FM) domains. It operates by monitoring the actual usage of resources—such as radio bearers, transport network bandwidth, or core network processing elements—against their allocated quotas. When sustained underutilization is detected or a service session is terminated, the CD function triggers a controlled release procedure. This involves signaling between network functions (e.g., between the RAN and Core Network) to tear down the reserved resources, update internal state tables, and make the capacity available for other services or users.
The architecture supporting CD is distributed across network elements. In the Radio Access Network (RAN), it involves the Node B (for UMTS) or eNodeB/gNB (for LTE/5G) deallocating radio resource blocks and transport bearers. In the Core Network, entities like the Serving GPRS Support Node (SGSN), Mobility Management Entity (MME), or Session Management Function (SMF) manage the deallocation of packet data protocol (PDP) contexts, packet flows, or PDU sessions. The process is governed by policies defined in the Policy and Charging Rules Function (PCRF) or Policy Control Function (PCF), which dictate conditions for deallocation based on subscriber profiles, service types, and network load.
Key to its operation is the coordination between resource reservation and deallocation to prevent service interruption. CD must be carefully synchronized with mobility events (like handovers) and session continuity mechanisms to avoid prematurely releasing resources still in use. It employs timers and thresholds to distinguish between temporary idle periods and genuine termination of demand. The released resources are then returned to a shared pool, enabling statistical multiplexing gains and improving overall network capacity. This dynamic management is crucial for supporting diverse traffic patterns, from bursty data sessions to always-on IoT connections, ensuring the network can scale efficiently.
From a technical implementation perspective, CD procedures are specified in various 3GPP Technical Specifications (TS). For example, in the context of GTP tunnels, deallocation involves messages to delete tunnels and update forwarding states. In radio resource control (RRC), it involves transitioning user equipment to lower connection states and releasing dedicated channels. The function is closely tied to charging systems, as deallocated resources stop incurring usage charges. Effective CD reduces operational costs by minimizing over-provisioning and enhances user experience by freeing capacity for new requests, thereby reducing congestion and blocking probabilities.
Purpose & Motivation
Capacity Deallocation exists to solve the critical problem of resource wastage in telecommunications networks. Early cellular systems often allocated resources for the entire duration of a call or session, even during silent periods or after effective completion, leading to inefficient utilization. As networks evolved to support packet-switched data services with highly variable bandwidth demands, static allocation became unsustainable. CD was introduced to enable dynamic resource management, allowing networks to adapt to real-time traffic conditions and serve more users with the same physical infrastructure.
The creation of CD was motivated by the need for cost-effective scalability and improved Quality of Service (QoS). Without efficient deallocation, networks would suffer from resource exhaustion, where capacity remains locked by inactive sessions, preventing new sessions from being established. This is particularly problematic for data-centric services common from 3G (UMTS) onwards. CD addresses the limitations of previous 'allocate-and-hold' approaches by introducing intelligence into the resource lifecycle, ensuring resources are held only when genuinely required. This is foundational for implementing advanced QoS features, traffic shaping, and fair usage policies across a shared network.
Historically, as 3GPP standards progressed from R99 (the first UMTS release) through subsequent releases, the importance of CD grew with the increasing complexity of services. It became integral to managing the bursty nature of internet traffic, supporting always-on connectivity without permanently dedicating resources. In modern 5G networks, with network slicing and massive IoT, CD is essential for rapidly reallocating resources between slices or IoT devices with sporadic activity, enabling the network to be both efficient and flexible.
Key Features
- Dynamic release of underutilized radio bearers and transport resources
- Policy-driven deallocation based on subscriber, service, and network conditions
- Coordination with mobility management to ensure session continuity during handovers
- Integration with charging systems to stop billing upon resource release
- Timer and threshold-based mechanisms to distinguish idle states from session end
- Support for statistical multiplexing by returning capacity to a shared pool
Evolution Across Releases
Introduced Capacity Deallocation as a fundamental OAM function within the initial UMTS architecture. It provided mechanisms for releasing PDP contexts and radio access bearers (RABs) in the Packet-Switched (PS) domain, enabling basic dynamic resource management for early 3G data services. Procedures were defined between the UE, RNC, and SGSN to tear down resources upon session termination or prolonged inactivity.
Defining Specifications
| Specification | Title |
|---|---|
| TS 21.905 | 3GPP TS 21.905 |
| TS 22.072 | 3GPP TS 22.072 |
| TS 22.173 | 3GPP TS 22.173 |
| TS 22.273 | 3GPP TS 22.273 |
| TS 22.980 | 3GPP TS 22.980 |
| TS 23.042 | 3GPP TS 23.042 |
| TS 23.097 | 3GPP TS 23.097 |
| TS 23.146 | 3GPP TS 23.146 |
| TS 24.173 | 3GPP TS 24.173 |
| TS 24.186 | 3GPP TS 24.186 |
| TS 24.292 | 3GPP TS 24.292 |
| TS 24.404 | 3GPP TS 24.404 |
| TS 24.406 | 3GPP TS 24.406 |
| TS 24.416 | 3GPP TS 24.416 |
| TS 24.447 | 3GPP TS 24.447 |
| TS 24.504 | 3GPP TS 24.504 |
| TS 24.516 | 3GPP TS 24.516 |
| TS 24.604 | 3GPP TS 24.604 |
| TS 24.606 | 3GPP TS 24.606 |
| TS 24.615 | 3GPP TS 24.615 |
| TS 24.616 | 3GPP TS 24.616 |
| TS 24.642 | 3GPP TS 24.642 |
| TS 24.647 | 3GPP TS 24.647 |
| TS 25.211 | 3GPP TS 25.211 |
| TS 25.213 | 3GPP TS 25.213 |
| TS 25.214 | 3GPP TS 25.214 |
| TS 25.222 | 3GPP TS 25.222 |
| TS 29.292 | 3GPP TS 29.292 |
| TS 29.364 | 3GPP TS 29.364 |
| TS 29.864 | 3GPP TS 29.864 |
| TS 32.275 | 3GPP TR 32.275 |
| TS 32.808 | 3GPP TR 32.808 |
| TS 33.117 | 3GPP TR 33.117 |