5G SON, Simplified
- Venkateshu Kamarthi
- Sep 18, 2025
- 10 min read
Introduction
SON (Self Organizing Networks) is an automation framework that lets cellular networks configure, optimize, and heal themselves with minimal human intervention, using standardized management models and procedures to close control loops. In 5G, SON is a core enabler for beam‑centric NR, network slicing, energy efficiency, and new topologies like IAB and managed repeaters, extending beyond LTE’s cell‑centric scope and EPC‑era management.
The main elements of SON include:
Self configuration: The aim for the self configuration aspects of SON is to enable new base stations to become essentially "Plug and Play" items. They should need as little manual intervention in the configuration process as possible. Not only will they be able to organise the RF aspects, but also configure the backhaul as well.
Self optimisation: Once the system has been set up, SON capabilities will enable the base station to optimise the operational characteristics to best meet the needs of the overall network.
Self-healing: Another major feature of SON is to enable the network to self-heal. It will do this by changing the characteristics of the network to mask the problem until it is fixed. For example, the boundaries of adjacent cells can be increased by changing antenna directions and increasing power levels, etc..
Why SON is needed
Complexity and scale: 5G introduces flexible numerology, massive MIMO, beams, FR2, BWPs, and cross‑domain slicing—manual tuning cannot keep pace with dynamic traffic and RF conditions, so automation reduces OPEX and errors while sustaining KPIs.
Closed‑loop assurance: Standardized monitoring, analysis, decision, and execution across RAN/Core via MnS(Managed Services) enable fast, safe parameter changes, accelerating rollout, resilience, and energy savings in live networks.
5G SON architecture
3GPP defines three deployment styles: centralized SON (C‑SON in management layer), distributed SON (D‑SON in network functions, e.g., gNB), and hybrid SON (H‑SON spanning both), with defined processes for monitoring, analysis, decision, and execution; algorithms themselves remain vendor‑specific.
5G adds self‑establishment and self‑configuration for NG‑RAN nodes (plug‑and‑connect, auto‑software, config activation), plus domain/cross‑domain coordination for coherent actions across RAN and core.
Below 5G SON architecture diagram shows all key components involved
EMS/C‑SON: Centralized SON running in the management system; it ingests PM/MDT/KPIs from the network and pushes configuration/policy back to nodes for ANR/MRO/load/energy actions.
gNB‑CU and gNB‑DU: RAN nodes that send PM/MDT up and receive config down; UE measurements flow via DU/CU as MDT to EMS/C‑SON for analysis and optimization decisions.
5G Core: Provides KPIs and may receive policy/config when the optimization spans core and RAN domains under centralized or hybrid SON control.
D‑SON(RAN) and D‑SON(Core): Local SON logic embedded in RAN/Core; green arrows indicate hybrid SON coordination where EMS/C‑SON sends policies/targets down and receives KPIs/results up
How SON is compared to O-RAN based RIC, SMO
SON is a 3GPP-standardized closed-loop automation pattern embedded in the management plane that tunes network parameters and topology using PM/MDT and MnS/NRM models, whereas RIC and SMO are O-RAN functions for policy-driven, open, app-based control with near-real-time (xApps) and non-real-time (rApps) loops
SON (3GPP): Management-plane closed loops for self-config, self-optimization, self-healing; standardized info models and services (MnS, NRM, PM/MDT), algorithms vendor-specific; deployable as centralized, distributed, or hybrid (C-SON/D-SON/H-SON).
SMO (O-RAN): Service Management and Orchestration platform hosting non-RT RIC and rApps, handling lifecycle/config/assurance, policy and model management, and enrichment info for RAN; uses O1/O2/A1 open interfaces.
RIC (O-RAN): Non-RT RIC in SMO for policies/models; Near-RT RIC at edge for low-latency control (10 ms–1 s) with xApps over E2; enables multi-vendor, per-UE, cross-layer RRM control.
Dimension | SON (3GPP) | RIC (O-RAN) |
Purpose | Self-config, self-optimization, self-healing via management-plane closed loops; algorithms vendor-specific, interfaces standardized | Open, app-based RAN optimization and control with non-RT and near-RT loops (rApps/xApps) |
Control loop timing | Non-real-time minutes→hours in C-SON; faster local D-SON but still mgmt-centric | Near-RT RIC: 10 ms–1 s actions; Non-RT RIC: >1 s policies/models |
Placement | Management system (C-SON), in-NF (D-SON), or hybrid (H-SON) | Non-RT RIC inside SMO; Near-RT RIC at edge/central cloud connected to E2 nodes |
Interfaces/models | 3GPP 28‑series MnS, NRM, PM/MDT; vendor algorithms not standardized | A1 (policy/model), E2 (near-RT control), O1/O2 (mgmt/cloud); rApps/xApps ecosystem |
Granularity | Cell/sector/beam parameter tuning (ANR, MRO, LBO, ES), topology/config | Adds per-UE/session flow-level RRM and cross-layer control via xApps |
Strengths | Mature, stable ops; multi-vendor via standardized mgmt info models; strong change governance | Fine-grained, low-latency control; openness and rapid innovation via apps and open interfaces |
Typical use | Zero-touch rollout, parameter drift correction, energy saving, mobility/load optimization at cluster level | Traffic steering, interference mitigation, PRB scheduling, QoE control, AI-driven per-UE policies |
Example | C‑SON reduces HOF by tuning A3/A5/TTT across a cluster during maintenance window | Near‑RT RIC xApp steers UEs between cells every 100 ms using CQI/CSI and A1 policies |
SON workflow
Loop phases: monitoring (collect PM/MDT), analysis (detect anomalies, hotspots), decision (compute parameter changes), execution (apply safely with rollback); 3GPP illustrates these within C‑SON, D‑SON, and H‑SON flows.
Hybrid control: H‑SON coordinates which actions run locally in gNB (fast loops) versus centrally (global coordination), with guardrails to prevent conflicting changes and to ensure stability.
Here is the SON workflow in step by step:
Data Collect
Subscribe and pull KPIs, PM counters, and MDT logs from gNB/CU/DU on a schedule or trigger.
Analyze
Convert data to features/timelines and detect issues or hotspots; set optimization targets.
Decide
Compute safe parameter changes and pick an execution window with rollback criteria.
Execute
Push updates to the RAN (e.g., ANR/MRO/LBO/ES parameters) and apply them on nodes.
Verify
Re‑collect post‑change KPIs; keep if targets met, else iterate or roll back.
5G SON Use cases/ features
Some key SON (Self-Organizing Network) and MDT (Minimization of Drive Tests) features in 5G NR focus on automated configuration/optimization and standardized data collection that feed closed-loop RAN control. Core areas include automatic neighbor management, mobility robustness, load balancing, energy saving, coverage/capacity optimization, and rich MDT logging in both idle and connected states for NR and MR-DC deployments.
Several SON use cases are uniquely 5G because they depend on NR‑specific radio features (beam‑centric design, BWPs, multi‑TRP/mMIMO), 5GS management models, and new topologies (IAB, network‑controlled repeaters).
1. Beam‑aware ANR and coverage tuning
Why it matters: NR mobility and coverage are beam‑centric; neighbor relations and coverage must be managed per SSB/CSI‑RS beam and per GNB, not just per cell, to avoid ping‑pong and holes, especially in FR2 and multi-TRP macro grids.
Implementation: SON consumes beam‑tagged MDT/PM (RSRP/RSRQ/SS‑SINR with SSB/CSI‑RS IDs), detects missing/overlapping beams, updates neighbor relations with beam/cell pairs, and reconfigures SSB burst sets, CSI‑RS resources, and beam sweep periodicity via RRC/SON MnS per TS 28.313.
Participants: UE, gNB GNB‑A/B, SON Function; the UE reports beam‑tagged measurements; SON analyzes and reconfigures beams and neighbors.
Inputs: MDT and PM with RSRP/SS‑SINR, SSB index, CSI‑RS resource, CRI/RI, geolocation; neighbor tables per beam; KPI baselines for HOF/ping‑pong.
Steps:
UE sends periodic/logged MDT with beam identifiers; gNB aggregates PM and forwards to SON.
SON detects missing/overlapping beams and mobility issues; correlates with HOF/ping‑pong KPIs.
SON issues reconfig to GNB‑A: adjust SSB burst set (power/azimuth), CSI‑RS density/offset; updates ANR to link GNB‑A beam to GNB‑B beam.
UE measurements improve; loop continues until KPIs stabilize against targets.
2. CHO‑centric mobility robustness (beam/multi‑GNB)
Why it matters: Conditional Handover decouples preparation and execution, enabling beam‑aware, fast, robust HO especially in FR2 and multi‑GNB; LTE had no standardized CHO workflow.
Implementation: SON tunes CHO candidate lists and execution conditions (e.g., A3/A5 with SSB/CSI‑RS measurements, dual thresholds, timers), pushes CHO configs via RRC to UE; evaluates KPIs (HOF, too‑late/too‑early HO) and iterates thresholds.
Example: On a FR2 site, SON configures CHO to a GNB using a CSI‑RS SINR condition and a fallback to FR1 anchor if SS‑SINR falls below X within T ms.
Participants: UE, Source gNB, Target gNB, SON (MRO/CHO); SON crafts CHO policy; Source configures UE; UE executes when condition met.
Inputs: HOF/RLF stats, “too early/late” counters, A3/A5 event hit rates, SSB/CSI‑RS measurement filters; candidate list constraints.
Steps:
Source reports mobility KPIs to SON; SON computes CHO thresholds (A3 (Δ), A5 (Th1/Th2), SSB index filters, candidate ranking.
Source sends RRCReconfiguration with CHO config to UE; UE locally monitors conditions with CSI‑RS/SSB metrics.
UE executes HO directly to Target when condition true; Target logs outcome; SON updates parameters based on post‑HO stats.
3. BWP‑aware load and energy optimization
Why it matters: Bandwidth Parts are unique to NR; activating smaller BWPs at light load cuts UE and gNB power, while switching to wide BWPs under congestion improves throughput—enabling fine‑grained load/energy tradeoffs.
Implementation: SON monitors PRB utilization, latency, and slice KPIs; triggers per‑cell/per‑slice BWP switching policies; coordinates with SCell activation, cell DTX/DRX, and antenna adaptation per 5G‑Advanced energy models.
Example: Night hours in suburban macro: SON moves eMBB users to a 20 MHz BWP on the anchor CC, deactivates a secondary CC (SSB‑less SCell), and reduces active Tx chains from 64T to 32T, saving energy with sub‑5% throughput impact.
Participants: gNB, SON (LBO-Load Balancing Optimization/ES-Energy Saving), OAM/MnS; SON decides BWP and ES policies; OAM provisions; gNB applies runtime changes.
Inputs: PRB utilization, latency, slice KPIs, RF load, energy counters; BWP sets; CC/SCell activation states; antenna chain modes.
Steps:
gNB exports PM; SON decides to narrow BWP, deactivate SCell, and reduce active transmit chains; targets energy KPI improvement.
SON sends provisioning to OAM; OAM applies BWP switch and ES parameters to gNB; gNB reports updated throughput/energy PM
4. Slice‑aware RAN optimization (intent‑driven)
Why it matters: Only 5GS exposes slice intents/SLA; SON enforces per‑slice mobility, load, and coverage policies, balancing isolation vs. efficiency for eMBB/URLLC/IoT.
Implementation: SON consumes 28.552 PM per slice, aligns with RAN Slice Subnet NRM, and pushes policies via MnS; may allocate per‑slice BWPs, PRB quotas, and mobility offsets; evaluates SLA adherence.
Example: A URLLC slice gets tighter HO (lower TTT, higher offsets) and reserved PRBs; eMBB slice gets elastic scheduling; SON monitors SLA breach events and adjusts quotas/offsets.
Participants: Slice Intent Management, SON (Slice‑SON), gNB Scheduler; intents become enforceable policies; scheduler executes.
Inputs: Slice SLA (URLLC latency, eMBB throughput), per‑slice PM per TS 28.552, PRB quota plans, mobility offsets per slice.
Steps:
Intent Mgmt provides SLAs; SON derives scheduler and mobility policies per slice (PRB quotas, BWP map, TTT/offsets).
SON programs scheduler; scheduler reports per‑slice KPIs; SON feeds SLA status back to intent layer with adjustments if needed
5. IAB and network‑controlled repeater topology SON
Why it matters: NR standardizes IAB (Integrated Access Backhaul) and managed repeaters; SON must adapt neighbors, HO rules, and load to dynamic access/backhaul constraints—absent in LTE.
Implementation: SON tracks backhaul quality (IAB link KPIs), tags cells with topology role, modifies ANR and mobility weights to avoid backhaul‑congested nodes, and orchestrates repeater gain/orientation setpoints where supported.
Example: Event venue IAB ring saturates; SON diverts handovers to fiber‑fed macros, reduces repeater gain on overlapping beams to shrink coverage and relieve the IAB mesh.
Participants: IAB‑DU, Macro gNB, SON (Topology‑SON); SON mediates access vs. backhaul tradeoffs.
Inputs: Backhaul throughput/latency/BLER from IAB; access PRB/HOF from macro; topology roles; repeater gain/orientation controls where supported.
Steps:
IAB streams backhaul KPIs; macro provides access KPIs; SON identifies backhaul congestion.
SON deprioritizes HO to congested IAB nodes; commands IAB/repeaters to shrink coverage or adjust beam/gain; monitors relief via PM.
6. NR‑enhanced MDT for beam/multi-TRP analytics
Why it matters: NR MDT carries SSB/CSI‑RS beam IDs and multi-TRP context; SON uses this to tune beam coverage and CHO—granularity LTE MDT never had.
Implementation: Configure immediate/logged MDT including beam identifiers and geotags; SON correlates with HOF/RLF and updates beam patterns, CHO conditions, and ANR entries; expose via 28‑series MnS.
Example: Logged MDT reveals a stairwell dead zone tied to SSB beam 5; SON rotates CSI‑RS beam and raises SSB power by 1.5 dB for that azimuth; HOF rate drops by 30%.
Participants: UE, gNB, SON (MDT‑Analytics); beam‑tagged MDT enables fine optimization.
Inputs: MDT config including SSB/CSI‑RS IDs and location; PM HOF/RLF; CHO/ANR parameters.
Steps:
gNB configures MDT; UE uploads logs; gNB forwards beam‑tagged MDT and PM to SON.
SON localizes dead zones by beam/GNB; pushes beam, CHO, and ANR updates; gNB applies; SON validates KPI gains.
7. DSS/FR2 control‑plane beam coordination
Why it matters: In NR, PDCCH resource mapping and control coverage must be engineered under DSS and FR2 beams; SON coordinates control aggregation/CORESET/SSB to keep control robust—beyond LTE ICIC.
Implementation: SON monitors PDCCH BLER, DMRS/PDCCH SINR by beam; adjusts CORESET/PDCCH aggregation levels, SSB periodicity/offset, and PRACH occasions aligned with beams; evaluates control outage KPIs.
Example: Millimeter‑wave site sees PDCCH outages on outer beams; SON increases aggregation level for those beams and re‑phases SSB bursts to align with user dwell times, stabilizing access/control.
Participants: gNB (FR2), SON (Control‑Plane); SON tunes CORESET/PDCCH/SSB timing and robustness.
Inputs: PDCCH BLER by beam, CORESET SINR, access failure rates, SSB periodicity/offset settings.
Steps:
gNB shares control‑plane KPIs per beam; SON increases PDCCH aggregation level, retimes SSB bursts, or adjusts CORESET density.
gNB reports post‑change KPIs; SON iterates until control outage rate meets target thresholds.
Deploying SON in field networks
Placement patterns: C‑SON runs in the management layer (e.g., OAM/SMO), D‑SON in gNB/CU/DU, H‑SON splits fast vs global loops; selection depends on latency, data volume, stability, and multi‑vendor integration needs.
Integration steps: onboard network resource models (NRM), enable PM/MDT subscriptions, validate control guardrails and rollback, stage changes in maintenance windows, and pilot per domain before broad rollout to avoid contention with legacy optimizers.
This diagram illustrates a practical rollout workflow for SON in a 5G network, moving from lab to production with centralized SON and distributed SON working together.
Onboard NRM, enable PM/MDT feeds: The SMO/OAM with C‑SON onboards the network resource models and turns on performance measurement and MDT streaming from gNB/CU/DU, establishing the monitoring leg for closed loops.
Validate KPIs, guardrails, rollback: In the test environment, changes are verified against KPIs with safety limits and rollback procedures, aligning to SON change governance before production rollout.
Rollout H‑SON policies (domain split): Policies are deployed that split responsibilities between centralized SON and D‑SON in the nodes—hybrid SON—so global decisions and local fast loops operate coherently.
Change results, stability metrics: After applying in the production cluster, measured results and stability KPIs are fed back to the SMO/OAM to confirm impact or trigger adjustments, following the evaluation step of SON.
Tune fast loops vs central loops: Based on results, the balance between local D‑SON (fast) and centralized C‑SON (global) actions is tuned to avoid conflicts and ensure stable automation in live traffic.
Self‑establishment and zero‑touch in 5G
5G defines self‑establishment: new NG‑RAN nodes auto‑download software/config, run self‑tests, update NRM, and become traffic‑ready; this reduces site TTM and errors in multi‑vendor builds.
Plug‑and‑connect concepts and requirements are referenced to accelerate onboarding under common management, enabling early SON actions like ANR seeding and initial parameter guardrails.
Differences: LTE SON vs 5G SON
Management scope: 5G SON is defined in TS 28.313 for 5GS with service‑based management and per‑slice models, whereas LTE SON was rooted in TS 32.500 with EPC context and fewer cross‑domain hooks.
Radio granularity: 5G SON is beam/BWP/multi-TRPaware (e.g., CHO, beam‑level ANR), enabling finer mobility and energy control; LTE SON lacked beam and BWP constructs, leading to coarser control loops.
Aspect | LTE SON | 5G SON |
Specs | TS 32.500 era references | TS 28.313 + 28-series MnS |
Granularity | Cell-centric; no beams/BWPs | Beam- and BWP-aware; multi-TRP |
Mobility | No CHO; classic A3/A5 | CHO, beam tracking, GNB-aware |
Slicing | Not native | Slice intent/PM/NRM native |
Topologies | Macro/small cells | IAB, managed repeaters |
Self-establishment | Basic auto-config | Plug-and-connect, SW/config flows |
Conclusion
SON automates self-configuration, self-optimization, and self-healing so networks roll out faster, drop fewer calls, carry more traffic, run cooler, and cost less to operate; new sites use “plug‑and‑play,” live sites continuously tune parameters based on observed KPIs, and outage mitigation activates automatically; standards define the data and procedures exchanged, but not the vendor algorithms, so smarter SON implementations deliver better results.
Key points
Benefits: faster rollouts, fewer drops, higher throughput, lower congestion, and operational savings in energy and cost through automation of configuration, optimization, and healing.
Plug‑and‑play: new base stations self‑configure on onboarding; operational nodes regularly adapt algorithms and parameters to current KPIs and radio conditions.
Self‑healing: automatic compensation actions (e.g., neighbor retuning/tilt/power changes) bridge service gaps until permanent fixes land.
Implementation-specific: standards specify measurements and interfaces, but not the control logic; outcomes depend on the ingenuity of the SON algorithms.
References
1. ETSI TS 128 313 V18.2.0 5G; Management and orchestration; Self-Organizing Networks (SON) for 5G networks
2. 3GPP TS 28.530 version 18.2.0
Comments