Mobile network (RAN) optimisation & energy saving

The radio access network is the largest energy consumer of a mobile operator, yet most sites run at full power around the clock while traffic varies strongly by hour and place. AI agents forecast cell-level load and switch capacity layers, carriers or radio components into sleep modes when demand allows, while tuning tilt, power and handover parameters to keep coverage and experience intact. This is a concrete step towards autonomous networks and also reduces opex and CO2.

Problem & value

• Today: engineers set static energy-saving rules (fixed night-time shutdown of a capacity layer) and tune parameters by drive tests, counter analysis and rule-based SON functions. Rules are conservative, because a wrong shutdown means a coverage hole or congested neighbour. Multi-vendor, multi-technology (2G-5G) networks with hundreds of thousands of cells make manual tuning slow.
• AI value: per-cell traffic forecasting allows finer, more aggressive sleep decisions; RL or constrained optimisation balances energy against throughput, accessibility and retainability; closed-loop control reacts within minutes to events instead of weekly.
• Sourced indicators: energy is a major part of operator opex and the RAN dominates it (GSMA and operator sustainability reports [2]). Vendor/operator trials report double-digit percentage power savings, without a single verified headline figure here; such figures are trial-specific and depend on baseline, traffic profile and QoS constraints, so measure your own baseline.

Variants

• Radio energy saving: carrier/cell on-off, symbol/channel/deep-sleep of massive-MIMO radios, power-amplifier optimisation, traffic steering to efficient layers.
• Self-optimising networks (SON): automatic neighbour relations, mobility robustness, load balancing, coverage-and-capacity optimisation (3GPP SON/MDA) [3].
• Telecom network planning: AI-assisted site, capacity and spectrum planning; coverage prediction from drive-test and crowd data; investment prioritisation (fibre rollout: OPT-036).
• AI-RAN: GPU/accelerated compute hosting both RAN functions and AI workloads at the edge (AI-RAN Alliance, NVIDIA Aerial); the energy trade-off shifts to compute utilisation [5].
• O-RAN rApps/xApps: non-real-time (Non-RT RIC, >1 s) and near-real-time (10 ms-1 s) apps from third parties on open interfaces [4].
• Private 5G / campus networks: same logic at small scale, mostly vendor-managed.
• LLM NetOps copilots: natural-language troubleshooting and intent-based configuration; closer to CODE-010 (incident RCA) and KNOW-004 (technical documentation) and treated there.

How it works

1. PM counters + CM + energy meters (OSS/data lake, streaming)
2. feature store (cell, hour, neighbours, events)
3. traffic forecast per cell (time-series model, hours to days ahead)
4. policy engine: candidate actions (sleep, carrier off, tilt/power, offsets) constrained by QoS guardrails and neighbour capacity
5. digital twin / simulation check of the action (coverage, load shift)
6. action via rApp/xApp, SON or vendor controller (open-loop recommend
7. closed-loop apply)
8. monitoring: KPI degradation
9. automatic rollback and wake-up
10. learning from outcomes (RL reward = energy saved − QoS penalty)

• Forecasting: gradient boosting or deep time-series models on counters (daily/weekly seasonality, events, weather); foundation models for time series are being tested.
• Decision layer: constrained optimisation or safe/offline RL; hard guardrails (minimum coverage, emergency-call capability, protected sites such as hospitals) are rules, not learned.
• Human-in-the-loop: new policies start in recommend-only mode; engineers approve rollout per cluster; rollback and kill switch are mandatory; changes are logged.

Data preparation

The data are performance-management (PM) counters, configuration-management (CM) snapshots, alarms and energy-meter readings per cell, typically held in the vendor OSS, in operator data lakes and in site databases; planning and site master data sit in separate inventory tools. Typical gaps: counter definitions that differ per vendor and software release, missing or misaligned time stamps, gaps from collection outages, cell-name mismatches between OSS and inventory, energy meters not on every site, and change history that is not logged, so effects of earlier actions cannot be separated from natural traffic variation.

Preparation steps: 1. Inventory sources and name owners (PREP-001, PREP-004); connect the OSS through exports or APIs (PREP-005). 2. Build a harmonised cell master table with site, neighbours, vendor and carrier layers (PREP-011, PREP-012). 3. Normalise counters across vendors and releases and document KPI definitions (PREP-012). 4. Fill gaps and flag outages; join CM change logs and energy readings. 5. Mark protected sites (hospitals, emergency-call dependencies) as rule-based guardrails. 6. Create test periods for backtests (PREP-018).

Data are mostly network data, not personal data, but sensitive for security reasons. Expect 50-60% of effort for data harmonisation and OSS integration. See also DATA-003 and GUIDE-003.

Implementation paths

Which path for whom

• enterprise (operators, tower companies): A, because vendor energy-saving features integrate with certified RAN software and keep warranty and support intact.
• developer: C, because the O-RAN Software Community RIC, Sionna and open ML libraries allow building and testing rApps without licence costs.
• public (regulators, municipal or campus networks, research): C, because private networks and research testbeds can run open RIC and srsRAN stacks on own hardware with full control over data and code.

Path A — Buy (default for operators and tower companies)

• RAN vendors with built-in AI energy features: Ericsson (Intelligent Automation Platform, Radio Energy Saving features; EU/Sweden), Nokia (MantaRay, Energy Efficiency; EU/Finland), Huawei and ZTE (outside EU; supply-chain restrictions apply in many member states).
• Multi-vendor SON/automation: Amdocs, Viavi, Cellwize/Qualcomm, Rakuten Symphony, Mavenir, Juniper (RIC), plus EU-based Net-AI/Opanga-type specialists; check actual 2026 availability.
• Choose A when: you operate a live network, since vendor features integrate with certified RAN software and keep warranty and support intact.

Path B — Build on cloud APIs

• Telco data lake on Azure, AWS or Google Cloud (EU regions) or EU sovereign clouds; managed time-series and AutoML services for forecasting, plus streaming ingestion of PM files.
• LLM APIs only for the copilot layer (change summaries, explanations, intent capture), never for direct parameter control. Use an EU-region model endpoint where possible.
• Deploy decisions as O-RAN rApps on the operator's Non-RT RIC (e.g. Ericsson, Nokia, or open-source RIC).

Path C — Self-host (open source)

• RIC platform: O-RAN Software Community near-RT RIC and Non-RT RIC (Linux Foundation) [4]; srsRAN Project and OpenAirInterface for lab and private networks.
• ML stack: Python with scikit-learn/LightGBM, PyTorch, Ray RLlib or Stable-Baselines3 for RL, Sionna (NVIDIA, open source) for link-level and system simulation, Kafka/Flink for streaming.
• Hardware: HW1 suffices for forecasting and inference; HW2 for RL training and simulation. Main cost is integration with vendor OSS, not compute.

Path D — Custom training

Worthwhile for large operators with own data science teams: train site-specific RL policies in a digital twin, then transfer with safeguards. Needs months of per-cell counters, configuration history and a validated simulator; offline RL and conservative policy updates reduce the risk of live exploration.

State of the art (2026)

• Energy saving is the most mature RAN AI use case: major vendors ship AI-driven cell/carrier and radio sleep features, and operators run closed-loop trials at scale. Standardisation: 3GPP energy-saving and SON/MDA specs, O-RAN Alliance rApp/xApp specifications [3][4].
• Open RAN rApps create a marketplace for third-party optimisation, but multi-vendor interoperability and data-model gaps slow adoption.
• AI-RAN (accelerated compute running RAN and AI) is moving from trials to early deployments; the net energy balance depends on utilisation [5].
• Limits and failure modes: forecast errors on events (concerts, outages), coverage holes after sleep, ping-pong handovers, RL reward hacking, feedback loops between neighbouring cells optimised independently, and sim-to-real gaps. Savings often shrink once QoS guardrails match business SLAs. Quantified results should be A/B tested against control clusters.

Shared resources & combinations

• Same capabilities (time-series, optimization-solver, reinforcement-learning): OPT-007 building energy, OPT-022 grid congestion, OPT-025 traffic signals, OPT-015 cloud cost; one MLOps/feature store stack can serve several.
• Upstream/downstream: PRED-019 (demand forecasting methods), CODE-010 (AIOps incident RCA for network faults), KNOW-004 (NetOps documentation copilot), ANOM-024 (telecom fraud on the same OSS/BSS data), SEC-015 (OT/IoT security monitoring).

Effort, cost & KPIs

• Path A: weeks to enable features, 3-9 months to roll out across a network.
• Path B/C: 6-18 months incl. data pipelines, guardrails and certification by network operations.
• Cost drivers: OSS data access, multi-vendor integration, simulation fidelity, field validation.
• KPIs: kWh per site or per GB, % energy saved vs. control cluster, accessibility, retainability, throughput and latency percentiles, customer complaints, sleep-hours per cell, rollback rate, CO2e (Scope 2).

People & change

Involve management for the energy and cost targets, the network operations lead (department-lead) as process owner, IT and IT security for OSS access and kill-switch design, and the vendor (suppliers) for supported interfaces. Legal and compliance review obligations from critical-infrastructure rules (NIS2, emergency-call availability). RAN engineers are the main users: involve them first as reviewers of recommended actions in recommend-only mode, then as approvers per cluster.

Works council: depends. Network counters are not employee data, so pure traffic optimisation usually triggers no co-determination. It does when the tool logs engineers' approvals or overrides and thus is suited to monitor behaviour (section 87(1) no. 6 BetrVG, BAG case law), or when work processes change materially: section 90(1) no. 3 requires timely information, and a short works agreement on logging is advisable.

Data protection: aggregated cell data are normally not personal; check whether user-level or location data enter the pipeline, and then involve the DPO and do a DPIA. AI literacy: support engineers with training on forecast limits and guardrails (GUIDE-006, AI Act Art. 4). Pilot on a rural cluster with low risk, define go/no-go KPIs (GUIDE-009). Typical concern: "AI will degrade quality or cut jobs." Address with hard guardrails, rollback and human approval (GUIDE-011, GUIDE-008).

Risks, regulation & compliance

• EU AI Act: classification depends. Mobile networks are critical digital infrastructure; Annex III(2) high-risk covers AI used as safety components in the management and operation of critical digital infrastructure. Pure energy-saving optimisation that cannot affect availability materially is typically minimal risk; closed-loop control that can disrupt service, including emergency calls, should be assessed as potentially high-risk [1].
• NIS2 and telecom law: operators are essential entities under NIS2 and the EECC (security and resilience duties); the EU 5G Toolbox and national supply-chain rules affect vendor choice.
• GDPR: cell counters are aggregated and usually not personal; per-user or subscriber-level data (location, IMSI traces) is personal data and ePrivacy-relevant, so use aggregation and pseudonymisation and keep optimisation on cell-level KPIs.
• Operational risks: outage from faulty automation, vendor lock-in, model drift. Mitigations: guardrails, staged rollout, rollback, change management, audit logs, emergency-call protection.

Getting started

1. Baseline energy per site and cluster; check what vendor energy-saving features are already licensed.
2. Build a clean PM/CM/energy dataset for a pilot cluster (urban plus rural) with a control cluster.
3. Start in recommend-only mode: forecast traffic and compare suggested sleeps with vendor rules.
4. Define QoS guardrails and rollback triggers with network operations, then enable closed loop.
5. Scale cluster by cluster and report kWh and QoS monthly.

Sources

1. Regulation (EU) 2024/1689 (AI Act), Annex III — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
2. GSMA — Mobile Net Zero / energy efficiency — https://www.gsma.com/solutions-and-impact/connectivity-for-good/external-affairs/climate-action/
3. 3GPP — Self-Organizing Networks (SON) — https://www.3gpp.org/technologies/son
4. O-RAN Software Community (Linux Foundation) — https://o-ran-sc.org/
5. AI-RAN Alliance — https://ai-ran.org/
6. NVIDIA Sionna — https://nvlabs.github.io/sionna/
7. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj