ALARM: Adaptive Layer-Aware Resource Management for Power-Efficient vRANs Ali Srour, Farzad Veisi, Sami Taktak, Vania Conan
arXiv:2609.24765v1 [cs.NI] 21 Sep 2026
CEDRIC Lab, CNAM, Paris, France {ali.srour, farzad.veisi-goshtab, sami.taktak, vania.conan}@cnam.fr
Abstract—The transition to virtualized Radio Access Networks (vRAN) enables dynamic power control through fine-grained CPU resource management. However, existing approaches treat gNB as a monolithic entity, failing to exploit the heterogeneous computational characteristics of different protocol layers. This paper proposes ALARM, a layer-aware adaptive resource management framework for constrained 5G vRAN. ALARM decomposes the gNB into functional layers representing distinct RAN tasks with heterogeneous computational demands, and controls CPU resources at the layer level based on processing weights. The framework monitors per-layer performance to detect violations and responds by scaling only the affected layer. This targeted adaptation avoids the over-provisioning inherent in traditional uniform scaling approaches. Experimental validation on two constrained platforms demonstrates up to 33% power reduction versus non-optimized baseline and 19% beyond uniform approaches, with dynamic adaptation achieving 9.8% additional savings while preserving strict real-time guarantees.
I. I NTRODUCTION The evolution toward vRAN is motivated by the need for greater flexibility and cost-efficient deployment in modern cellular networks. However, this architectural shift also changes the power consumption profile of base stations. In traditional hardware-based RANs, the Radio Unit (RU) typically dominates the energy budget, accounting for 60-80% of total power consumption [1]. In contrast, vRAN introduces additional software processing overhead, increasing the contribution of baseband processing to the overall energy consumption [2]. This effect is particularly pronounced in small-cell deployments, where lower transmit power reduces radio consumption while computational demands remain largely unchanged. As a result, processing power can become comparable to, or even exceed radio power consumption [3], making processing efficiency a key lever for reducing the overall energy consumption of vRAN systems, especially in constrained cells. A 5G gNB comprises multiple protocol layers with fundamentally different computational characteristics. The physical layer dominates processing time [2], [4], with load depending strongly on radio parameters and allocated Physical Resource Blocks (PRBs) [5]. This imbalance reveals significant energysaving potential. Traditional uniform resource control approaches satisfy peak demands of compute-intensive layers but over-allocate to lighter layers. Instead, resource provisioning must be performed at a layer granularity by determining the requirements of each protocol layer. To exploit this opportunity, we examine how vRAN software executes and is scheduled on general-purpose CPUs.
In modern 5G deployments, gNB baseband functions are realized as software processing pipelines, where RAN tasks (e.g., channel coding, MAC scheduling) execute as queuebased user-space threads managed by a worker model [2]. This design is common in vRAN implementations (e.g., Intel FlexRAN [6], OpenAirInterface, srsRAN [7]). RAN threads are then managed by general-purpose OS schedulers (e.g., CFS, FIFO), which do not optimize for power efficiency. Beyond power efficiency, these threads face stringent timing requirements. Physical layer threads execute signal-processing tasks that must be completed within a Transmission Time Interval (TTI), defined by 3GPP slot structure [8]. The consequences of violating deadlines range from performance degradation (e.g., dropped throughput), to system failure (e.g., vRAN software crashing). These real-time requirements constrain the applicability of conventional CPU power-management mechanisms in vRAN systems. Standard approaches have proven effective for realtime applications, however their impact on vRAN is constrained by OS scheduling policies that lack RAN awareness [2]. Prior research on vRAN power management spans adaptive frequency control, core affinity optimization, and traffic-driven resource provisioning [9]–[15], demonstrating measurable energy savings. However, applying identical control levels across all protocol layers, regardless of their vastly different computational intensities creates an inherent efficiency ceiling. Our work extends these proven management techniques with a new dimension, a layer-aware traffic-driven resource management framework, termed ALARM. ALARM leverages the gNB structuring into functional processing layers, each characterized by a weight representing its target CPU share. Resource orchestration policies are assigned to each layer. Dynamic adaptation incorporates violation identification and applies corrective configurations exclusively to the affected layer. We evaluate ALARM using resource-constrained platforms representative of small-cell deployments. ALARM achieves up to 33% power reduction by eliminating over-provisioning, while maintaining the strict real-time guarantees across varying traffic loads and achieving 9.8% additional savings over uniform adaptation scaling approaches. The main contributions of this paper are: • We introduce a fine-grained, power-efficient resource management approach that leverages the layered design of vRANs and treats protocol layers independently
through processing weights, thereby replacing monolithic orchestration with proportional resource control. • We design a per-layer adaptation framework that detects layer-level violations using violated data volume and dynamically adjusts resources based on real-time workload, scaling only affected layers. • We validate the approach on real 5G vRAN testbeds using resource-constrained platforms, demonstrating significant power reduction. II. R ELATED W ORK Standard CPU power management relies on two primary mechanisms: dynamic frequency scaling (P-states) and sleep states (C-states). These mechanisms typically operate at control timescales of 10+ ms [16], which are orders of magnitude slower than vRAN’s sub-millisecond slot deadlines. Consequently, vRAN deployments [6] carefully constrain or entirely disable Linux-based power management features to avoid performance degradation. While enabling these techniques effectively reduce power consumption in general-purpose workloads, their effectiveness in vRAN depends critically on workload accuracy. OS schedulers, lacking RAN-specific awareness, introduce overhead through context switching, thread migration, and cache misses [2]. This scheduling inefficiency triggers unnecessary activity in uncore components (L3 cache, memory controller, PCIe), forcing Dynamic voltage and frequency scaling (DVFS) to elevate frequencies systemwide and limiting energy savings. This motivates RAN-aware power management with real-time guarantees. Prior research on base station energy efficiency has primarily focused on hardware-based systems using sleep modes [16], which are not directly applicable to vRAN’s general-purpose CPU architectures. Recent vRAN power management research has explored multiple directions, each with distinct limitations. Kalia et al. [9] identify the high response latency of standard P/C-states (+60 µs) and propose fast kernel-based reactive frequency scaling for vDU. Building on this direction, Huang et al. [10] use reinforcement learning to adjust CPU frequency based on Packet Data Convergence Protocol (PDCP) traffic load and block error rate (BLER). While these reactive approaches demonstrate the feasibility of dynamic frequency control, they face fundamental constraints in metric selection and resource resolution. PDCP operates at timescales that miss sub-millisecond traffic bursts, while BLER reflects radio channel conditions rather than actual computational load. More critically, these approaches apply uniform frequency scaling across all cores despite uneven load distribution, which could lead to suboptimal efficiency. Another research direction focuses on mapping gNB functions to physical cores to improve resource utilization. Crespo et al. [11] leverage O-RAN dApps for core affinity and frequency scaling, while Urumkar et al. [12], [13] propose CPU sleep modes for entire gNB stacks. While these techniques demonstrate measurable improvements in core utilization, they operate at a coarser granularity than what vRAN’s
architecture permits. Specifically, these approaches lack layerspecific allocation, explicit violation detection, and trafficdriven adaptation. Additionally, sleep mode approaches are difficult to apply to RAN and require low-latency mechanisms to avoid crashes [9]. Recent work has also explored dynamic resource allocation at the DU/CU component level, with Leonelli et al. [14] and Lozano et al. [15] proposing trafficbased resource provisioning between functional components. However, component-level granularity remains too coarse to exploit the fine-grained heterogeneity within the baseband processing pipeline itself. III. ALARM: A DAPTIVE L AYER -AWARE R ESOURCE M ANAGEMENT F RAMEWORK ALARM builds on established power management techniques and extends their scope by introducing layer-level energy efficiency as a complementary dimension. Rather than replacing existing mechanisms, our approach enhances them by monitoring actual computational load through direct perlayer violation detection and adapting resources independently for each affected layer. This strategy preserves the real-time guarantees that prior work has shown to be critical, while exploiting the computational heterogeneity an opportunity that becomes accessible through vRAN’s software architecture. A. Layer-Aware gNB Processing Model To treat all layers differently, we model the gNB as a collection of heterogeneous processing layers. We consider a gNB composed of a finite set of processing layers L = {L, D, U, U p}, corresponding to low-PHY (L) handling lower physical layer processing, DL high-PHY (D) and UL highPHY (U) managing uplink and downlink higher physical layer tasks respectively, and upper layers (Up) executing layer 2/3 protocol functions, where each layer ℓ ∈ L is implemented as one or more threads. While we use this four-layer decomposition for clarity, the modeling framework is adaptable and can accommodate more granular layer definitions based on RAN software architectures. We formalize the layer-aware resource management as follows. For each layer ℓ ∈ L, we define the number of threads Nℓ ∈ N+ , the CPU frequency Fℓ ∈ [Fmin , Fmax ] assigned to cores hosting layer ℓ, and the set of CPU cores Cℓ to which layer ℓ is mapped. The resource control for the entire gNB is then represented by the tuple Rℓ = {(Nℓ , Fℓ , Cℓ ) : ℓ ∈ L}. Each layer maintains an approximately constant share of total CPU utilization across traffic types [4]. This consistent ratio enables defining per-layer processing weights: each layer ℓ is associated with weight wℓ representing its typical CPU P demand share, normalized such that ℓ∈L wℓ = 1, enabling proportional resource control based on actual computational demands. The processing weights wℓ guide initial resource provisioning and core-affinity decisions Cℓ , while actual resource allocation Rℓ adapts dynamically based on traffic patterns, violations, and power optimization.
B. Framework Design This part illustrates the framework architecture and component interactions shown in Fig. 1. The framework consists of three main components: monitoring module, configuration manager module, and violation detection module.
CPUl TBSi Tproc,i
PRBi
Monitoring Module
ALARM Violation Detection Module Tproc,i>TTI CPUl> CPUthreshold Vdata>Vthreshold Vl Configuration Manager number of threads (Nl)
gNB
Nl
RLC
NRLC
core affinity (Cl)
Cl
frequency scaling (Fl)
CPU
Fl FRLC
PDCP RRC MAC H-Phy L-Phy
Per layer configs monitoring configs
Fig. 1: ALARM’s design overview illustrating monitoring of RAN/system metrics, and applying per layer configurations First, the monitoring module interfaces with the gNB software stack through two mechanisms, internal instrumentation where slot-level metrics are exposed by vRAN software through the open interfaces including P RBs, transport block size (T BS) and physical processing time (Tproc ), and external monitoring with system-level metrics (CPU utilization per thread, frequency per core). These measurements are provided to other modules to have visibility on workload variations, deadline violations and per-layer processing bottlenecks. Second, a configuration manager module decides which configuration to apply and enforces action decisions for each layer. Based on layer monitored state the module adjusts the number of worker threads (Nℓ ), CPU core affinity (Cℓ ), and operating frequency (Fℓ ) independently per layer. For example, a thread allocation configuration across all layers is represented as (NL , NU , ND , NUp ). Third, violation detection module analyzes monitored metrics to detect physical layer deadline miss, and traffic load. The control loop is executed at a TTI timescale compatible with vRAN dynamics, allowing the framework to react to sustained workload changes while avoiding instability due to shortterm fluctuations. For a better understanding, the component detailed behaviors are presented in subsequent subsections. C. Traffic Aware and Per-Layer Violation Detection A critical challenge in dynamic vRAN resource management is determining when to scale resources up or down. Aggressive resource reduction saves energy but risks violating real-time deadlines. Given the complexity of processing physical tasks within sub-millisecond slots, per-TTI computational
load is high and primarily driven by the number of allocated PRBs [17]. When processing capacity is insufficient, whether due to limited capacity of processors or insufficient number of executors, packets in the affected slot are dropped [2]. This makes violation detection essential for maintaining realtime guarantees while optimizing power consumption. The violation detection module addresses this challenge through per-layer violation-based feedback. The module gets Tproc from the monitoring module and compares it against the TTI budget to identify individual slot violations: Vslot,i = 1 if processing time exceeds the TTI deadline, and 0 otherwise, where i is slot index. However, not all deadline violations require resource reallocation. Individual violations often stem from transient factors like scheduling jitter or cache misses. Reacting to every violation causes control instability and energy waste. To distinguish transient violations from genuine capacity shortage, the framework computes violated data volume rather than counting violations. This approach weights violations by their impact. For each slot where Vslot = 1, the framework records the T BS of that slot, representing the amount of data that was processed late or potentially dropped. The violated Pn data is accumulated over a sliding window, Vdata = i=1 Vslot,i × TBSi where n is the window size. This accumulated violated data is then compared against a predefined threshold Vthreshold : PHYviolation = 1 if Vdata > Vthreshold , and 0 otherwise. When violated data exceeds the threshold, the violation detection module sends a signal to the configuration manager module to reallocate resources for physical layer. Upper layers (MAC, RLC, PDCP, RRC) operate without strict sub-millisecond deadlines. Their processing tasks like MAC scheduling, RLC segmentation/reassembly, and RRC signaling, have relaxed timing constraints on tens to hundreds of (ms) timescales [18]. For these upper layers, CPU utilization serves as a reliable saturation indicator. The framework detects saturation when CPUℓ > CPUthreshold (e.g., 0.95), where CPUℓ is per layer utilization. However, this metric fails for PHY layers: moderate CPU utilization (60%) can still cause TTI violations if workload parallelization is insufficient. This motivates the violated data mechanism for PHY layers. D. Per-Layer Control Flow Logic ALARM receives monitoring metrics, TBS per slot (TBSi ), physical layer processing time (Tproc ), and per-layer CPU utilization (CPUℓ ), and outputs updated resource configurations (Nℓ , Fℓ , Cℓ ) for each layer. The system initializes to a minimal configuration (lowest threads and frequencies), establishing a power-efficient baseline. The control loop operates continuously. At each iteration, the violation detection module computes per layer violation status (e.g., PHYviolation ). When violations occur, the configuration manager applies frequencyfirst scaling: transition from low to high frequency. If already at maximum frequency, increase thread count (Nℓ ) and invoke core mapping to assign threads based on layer weight (wℓ ) and core capabilities (capc ). Proper mapping prevents cache misses and overhead that negate parallelization benefits. When no violations occur, the manager scales down resources.
We conduct two experimental studies to evaluate ALARM. The first study assesses the impact of instant per-layer resource allocation on power consumption, the second study evaluates ALARM’s dynamic per-layer adaptation. Both studies use the same testbed infrastructure but examine different aspects of the framework under distinct operational modes. A. Testbed Description
B. Quantifying RAN Layers Heterogeneity To quantify the computational heterogeneity across RAN layers, we measured per-thread CPU utilization under varying traffic profiles. We monitored four thread groups: LowPHY, UL high-PHY, DL high-PHY, Upper Layers. As Fig. 2 demonstrates a constant CPU share for each layer over varying traffic load, physical layer threads collectively consume approximately 82% of total CPU resources, while upper layer processing accounts for only 18%. Low PHY
Upper Layers
UL High PHY
DL High PHY
50
48.6
40
Avg. (%)
Share of Total CPU (%)
60
30 20.8 17.8 12.8
20 10 10
20
30
40
1.0 0.8
CDF
The gNB is implemented using srsRAN 5G [7], deployed on Odroid H4 (8-core Intel Core i3 @ 1.8 GHz) and Raspberry Pi 5 (4-core ARM Cortex-A76 @ 2.4 GHz) single-board computers. USRP B210 is used as RU, a commercial 5G smartphone as UE, and the 5G core network is implemented using Open5GS. To isolate baseband processing effects, highcapacity fronthaul and backhaul links are used, and the UE is placed close to the antennas to reduce the influence of radiochannel impairments. The system uses a 30 kHz subcarrier spacing (TTI = 0.5 ms) with a fixed 64-QAM MCS (index 27) over a single and dual 20 MHz channel.
USB events, gNB control, PUCCH, logging). ctrl th have minimal CPU impact but increase scheduling complexity. Uniform: Traditional non layer-aware resource management applied at the gNB entity level. Data plane threads reduced from 11 to 7 and mapped uniformly across cores 1-7 via CPU affinity, treating all RAN processing as a monolithic workload. This configuration represents traditional optimization example that reduces thread count but ignores layer-specific computational heterogeneity. ALARM: Layer-aware resource management, data plane threads reduced from 11 to 5, allocated per layer as (NL :2, NU :1, ND :1, NUp :1). Each layer thread is mapped to a dedicated core via CPU affinity: (CL :[3,4], CU :6, CD :7, CUp :5). Control threads (ctrl th) remain OS-managed on cores 3 and 4. Per-layer frequency scaling was not applied due to hardware limitations, and the default DVFS governor remained active.
50
Data Rate (Mbps)
Fig. 2: Layer-level CPU utilization vs E2E throughput C. Study I: Impact of Per-Layer Resource Management This study evaluates the power consumption benefits of layer-aware resource management under static traffic conditions. We compare Default and Uniform configurations representing related work [9]–[15] to ALARM configuration: Default: Baseline without enhancement. Threads managed by OS scheduler, CPU frequency by Linux DVFS, no core affinity. The RAN spawns 18 total threads 11 data plane and 7 auxiliary control threads denoted ctrl th (radio control, I/O,
1.0
Default ALARM Uniform
0.8
0.6
CDF
IV. M ETHODOLOGY AND E XPERIMENTAL A NALYSIS
0.4 0.2 0.0
Default ALARM Uniform
0.6 0.4 0.2
3
4
Power (W)
(a) Raspberry Pi 5
5
0.0
6
7
8
Power (W)
(b) Odroid
Fig. 3: Power consumption comparison of ALARM against Default and Uniform on Raspberry Pi and Odroid platforms Fig. 3 presents the cumulative distribution of power consumption on two constrained platforms. The sharp CDF transitions reflect power shifts between idle and active transmission states. ALARM achieves 29-33% power reduction versus Default and 11-19% versus Uniform, demonstrating that traditional vRAN deployments waste nearly one-third of their energy budget on resource over-provisioning, while Uniform reduces thread count without layer awareness, leaving substantial efficiency gains uncaptured. By applying the ALARM concept, power consumption is further minimized while preserving real-time guarantees. To understand the source of these savings, we analyze the system-level results. Both platforms show consistent trends, for brevity, we analyze Odroid results. Fig. 4 presents per-core CPU utilization for each configuration, validating the potential for layer-specific processing reduction. In Default and Uniform scenarios, seven cores exhibit high utilization ranging from 56% to 93% in Default and averaging 65.5% in Uniform, reflecting uncontrolled thread distribution with frequent migrations that spread load evenly across cores. In contrast, ALARM’s layer allocation creates functional specialization where each core handles a specific RAN layer, enabling predictable execution patterns. Tab. I demonstrates how ALARM eliminates over-allocation: lightweight layers show 9-78%
CPU Usage (%)
Default
100
Uniform
ALARM
50
0
1 2 3 4 5 6 7 1 2 3 4 5 6 7 1 2 3 4 5 6 7 Core index
Fig. 4: Per-core CPU utilization (%) comparison Core Allocated Layer Default (%) ↓ Uniform (%) ↓
1 L 0 0
2 L 0 0
3 ctrl th 38.77 24.27
4 5 ctrl th Up 69.37 77.91 65.5 74.00
6 U 67.77 70.23
7 D 17.44 8.54
TABLE I: ALARM’s per-core CPU% reduction. CPU reduction, while compute-intensive physical layers retain necessary capacity. The critical question is whether efficiency gains come at the cost of real-time guarantees. Fig. 5 provides a definitive answer. Each point represents a single slot’s processing latency under 50 Mbps traffic. Downlink physical layer processing time remains below the 500 µs TTI deadline for every slot throughout the measurement period, validating that ALARM maintains strict real-time guarantees despite thread minimization.
CCDF
1.0 PDSCH Latency TTI Deadline (0.5 ms)
0.5
0.0
0.1
0.2
0.3
0.4
0.5
Execution Time (ms)
Fig. 5: ALARM physical-layer processing time
Normalized (%)
Default 100
129k
425
0
ALARM
457
383 301
78k 50
Uniform
195 34k
Context Switching
D. Study II: Dynamic Per-Layer Adaptation Aggressive resource reduction shown in Study I improves power efficiency but risks performance degradation under increasing traffic load, necessitating dynamic adaptation mechanisms. This study compares ALARM’s layer-specific adaptation (ALARM Adaptation) against uniform scaling approaches that represent the traditional baseline (Uniform Adaptation) [9], [10], [12], [14]. Default is excluded from this study as it lacks dynamic adaptation capabilities: ALARM Adaptation: Dynamic response to deadline violations through layer-specific resource adjustment. Manages resources by scaling global frequency to minimum level (1.1 GHz) and adjusting per-layer thread allocation. Thread count Nℓ and core mapping Cℓ are modified in response to the violated layer, while per-layer frequency scaling is unavailable due to hardware limitations. Violation threshold Vthreshold is set to 2.5 Mbps, and traffic varies 10-50 Mbps, forcing dynamic adaptation while maintaining real-time guarantees. Uniform Adaptation: Same configuration as ALARM before adaptation, but scales all layers uniformly when violations occur, rather than targeting only affected layers. ALARM (W) 4.9
Uniform Adaptation (W) 5.4
Gain (%) 9.8
TABLE II: ALARM power efficiency vs. uniform adaptation
41 Thread Migration
activity. Eliminating RAN thread migrations preserves cache locality, thread’s data remains resident in CPU’s L1/L2 caches rather being evicted and reloaded. This reduces scheduling overhead, manifested in total CPU utilization decreasing from 383% (Uniform) to 301% (ALARM). The same workload completes in less time because instructions execute faster with hot caches, and the CPU spends more cycles on actual work. A crucial observation is that average CPU frequency remains nearly constant at 1.4 GHz in both scenarios. This proves that power savings do not result only from simply running slower. The same frequency delivers the same throughput with dramatically less overhead. The efficiency gains come entirely from per layer resource allocation, fewer threads, dedicated cores, preserved cache locality, and reduced uncore activity. This is an ALARM’s fundamental advantage, it operates at the same performance point while consuming less power, which was validated in the power results shown in Fig. 3.
Mean CPU Usage (%)
Fig. 6: System-level metrics comparison Fig. 6 compares system-level metrics between Default, Uniform, and ALARM, normalized to the Default baseline (100%). While Uniform successfully reduces total CPU utilization, context switching, and thread migration by reducing the logical executors load, ALARM achieves an additional 43.5% reduction in context switches through per-layer thread minimization and CPU affinity pinning, which eliminates involuntary switching and dramatically reduces OS scheduling
When violations take place, both adapting approaches resolve violations, however Uniform Adaptation does so at significantly higher power cost. Tab. II shows the power efficiency advantage of ALARM’s per-layer adaptation compared to uniform scaling. ALARM achieves at least 9.8% additional power savings by adapting only to the affected layers rather than all layers simultaneously. Fig. 7 presents physical layer processing time across traffic scenarios before adaptation takes place. At light to moderate loads (10-30 Mbps, PRB: 14.6-29.1), some slots miss the deadline but violated data remains below the 312.5 KB threshold. These violations represent transient phenomena such as
PHY violation
scheduling jitter, interference spikes, or cache misses not capacity shortage. ALARM and Uniform maintain minimal configuration (NL :1, NU :1, ND :1, NUp :1) across this range, preserving maximum power efficiency. Processing Time (μs)
1000 800
ALARM & Uniform before adaptation DEADLINE TTI: 0.5 ms PHY violation
600 400 200 0
10
20
30
40
Transmission Data Rate (Mbps)
Fig. 7: Physical layer processing time before adaptation
Processing Time (μs)
1000 800
ALARM Adaptation Uniform Adaptation DEADLINE TTI: 0.5 ms
600 400 200 0
40
50
Transmission Data Rate (Mbps)
Fig. 8: Physical layer processing time after adaptation At 40 Mbps without adaptation, the system crosses into capacity shortage. PRB allocation rises to 37.2, violations occur frequently, and violated data reaches 666.3 KB, exceeding the threshold by multiple of 2. The violation detection module computes Vdata = 666.3 KB, exceeding Vthreshold = 312.5 KB and thus triggering PHYviolation . This signals genuine capacity exhaustion rather than transient spikes. ALARM responds by addressing only the affected physical layers, increasing NL and ND from 1 to 2, then reassigning threads to cores, while Uniform Adaptation increases one thread for all layers to address the problem. The result is immediate as shown in Fig. 8 violated data drops to negligible levels and processing times return to the tight distribution seen at lower loads. The adapted configuration (NL :2, NU :1, ND :2, NUp :1) restores violationfree operation and maintains it through 50 Mbps (PRB: 43.4), validating sustainable reconfiguration. Both scenarios preserve performance, however efficiency is strongly affected by adaptation granularity, Uniform Adaptation allocates resources to unaffected layers, while per-layer adaptation preserves a 9.8% efficiency advantage by avoiding this unnecessary overhead. Discussion: We find that violation severity (violated data volume) provides a more reliable capacity indicator than violation frequency, which primarily reflects transient effects rather than genuine resource shortages. This distinction represents an important consideration for future traffic-aware resource management frameworks. V. C ONCLUSION This paper presented ALARM, a layer-aware resource management framework for energy-efficient vRAN. By decom-
posing the gNB into heterogeneous layers with distinct processing demands, the framework enables surgical per-layer resource orchestration rather than monolithic over-provisioning. ALARM provides per-layer control, layer-level violation detection, and dynamic traffic-driven scaling. Using thread allocation to illustrate the approach, experimental validation demonstrates up to 19% greater power savings than uniform control solutions, with per-layer adaptation achieving 9.8% additional savings over adaptive uniform scaling approaches. While these magnitudes are hardware-specific and depend on the underlying mechanisms (e.g., frequency scaling, sleep states), our key contribution is demonstrating that layeraware management provides complementary optimization that enhances, rather than replaces existing power management mechanisms. Although this work focuses on small-cell deployments, the principles present significant opportunities for larger-scale environments. Cloud-RAN deployments exhibit similar challenges at greater scale, where layer-aware management could enable substantial aggregate power savings. Extending this framework to distributed cloud-based architectures therefore represents an important direction for future research. R EFERENCES [1] L. M. Correia et al., “Challenges and enabling technologies for energy aware mobile radio networks,” IEEE Communications Magazine, 2010. [2] X. Foukas et al., “Concordia: teaching the 5g vran to share compute,” in ACM SIGCOMM, 2021. [3] X. Ge et al., “Energy efficiency challenges of 5g small cell networks,” IEEE Communications Magazine, 2017. [4] C. Wei et al., “5gperf: profiling open source 5g ran components under different architectural deployments,” in ACM SIGCOMM, 2022. [5] T. X. Tran et al., “Understanding the computational requirements of virtualized baseband units using a programmable cloud radio access network testbed,” in IEEE ICAC, 2017. [6] Z. Li et al., “5g l2 sw architecture best practice on ia,” Intel Corporation, White Paper, 2018. [7] “srsRAN Project - Open Source RAN.” [Online]. Available: https: //www.srsran.com/ [8] 3GPP, “NR; Physical Channels and Modulation,” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 38.211, 2023. [9] A. Kalia et al., “Towards energy efficient 5g vran servers,” USENIX NSDI, 2025. [10] Y. Huang et al., “Reinforcement learning based dynamic adaptive frequency scaling for o-ran energy saving,” in IEEE Globecom Workshops, 2024. [11] F. Crespo et al., “Energy-aware cpu orchestration in o-ran: A dappdriven lightweight approach,” arXiv preprint, 2025. [12] S. Urumkar et al., “Power saving in open ran by using advanced cpu scheduling algorithm,” in IEEE SMARTCOMP, 2025. [13] S. Urumkar, B. Ramamurthy et al., “Improving energy efficiency in open ran through dynamic cpu scheduling,” in IEEE ANTS, 2023. [14] C. Leonelli et al., “Dynamic resource allocation and energy optimization in 5g o-ran: Real-world insights and testbed evaluations,” in IEEE ICC Workshops, 2025. [15] J. X. S. Lozano et al., “Airic: Orchestration of virtualized radio access networks with noisy neighbours,” IEEE JSAC, no. 2, pp. 432–445, 2024. [16] J. Wu et al., “Energy-efficient base-stations sleep-mode techniques in green cellular networks: A survey,” IEEE Communications Surveys & Tutorials, vol. 17, no. 2, pp. 803–826, 2015. [17] K. C. Garikipati et al., “Rt-opex: Flexible scheduling for cloud-ran processing,” in ACM CoNEXT, 2016. [18] B. Varga et al., “Latency analysis of mobile transmission,” Internet Engineering Task Force, Internet-Draft, 2024.