At 03:40 on a Tuesday night, a single 5G cell in a mid-size city quietly loses its uplink. Not completely — nothing so kind. Its SINR degrades just enough that retransmissions double, latency creeps up, and by morning rush hour three thousand subscribers are having a slightly worse day. Nobody called. No alarm fired, because no threshold was crossed. In a network of 100,000 cells, this exact story is happening somewhere right now — and the only realistic way to catch it is a machine that never sleeps, never gets bored, and has already learned what "normal" looks like for every one of those cells individually.
That is this book's subject: using AI not as a buzzword but as a working tool for network optimization — grounded in the 3GPP specifications that define what the data is, and in machine-learning practice that actually survives contact with production.
1.1 The scale problem, with real numbers
Optimization used to be a craft you could hold in your head. A 2G BSC engineer knew their cells personally. Let's see why that era is mathematically over:
| Dimension | Typical scale today | Why humans can't keep up |
|---|---|---|
| Cells per national operator | 50,000 – 500,000+ (multi-band 4G + 5G) | One engineer can genuinely "know" perhaps 200 cells |
| Configuration parameters per gNB | Thousands, across CU/DU/RU managed objects | Combinatorial space; many parameters interact non-linearly |
| PM measurements per cell TS 28.552 | Hundreds of measurement types, typically every 5–15 min granularity period | ≈ tens of billions of counter values per day network-wide |
| Frequency layers | 4–10 (700 MHz … 3.5 GHz … mmWave) | Every mobility/load decision is now multi-layer |
| Traffic pattern volatility | Hourly, daily, seasonal, event-driven | Static parameter settings are wrong most of the time |
Notice what this key idea does not say. It doesn't say AI replaces RF engineering. Every successful deployment covered in this book has domain rules wrapped around the model: guard KPIs, rollback conditions, physics-based sanity bounds. The machine supplies scale; the engineer supplies truth. Chapter 3 formalizes this as the "physics first" rule.
1.2 From drive tests to SON to AI — a 20-year arc
AI in telecom did not appear from nowhere. It is the third act of an automation story that 3GPP has been writing since Release 8:
SON was rules; AI is learning. Classic SON functions — Automatic Neighbour Relation (ANR), Mobility Robustness Optimization (MRO), Mobility Load Balancing (MLB) TS 32.500 TS 28.313 — encode fixed if-then logic: "if too-late handovers exceed X, increase CIO." They work, and they are still running in your network. Their limits are exactly the limits of rules: they only handle situations someone anticipated, with thresholds someone hand-tuned once, globally.
The AI era replaces the hand-written rule with a learned function. Three 3GPP workstreams mark the transition — remember these, because the whole book hangs off them:
| Workstream | Spec anchor | What it standardizes |
|---|---|---|
| Management-plane AI (MDA) | TS 28.104 Management Data Analytics · TS 28.105 AI/ML management | Analytics functions in the OAM domain and the full ML lifecycle: training, testing, deployment, monitoring of models as managed entities (Rel-17+) |
| Core-network AI (NWDAF) | TS 23.288 | The Network Data Analytics Function inside the 5G core: standardized analytics (load, mobility, QoS sustainability, abnormal behaviour) with a split into AnLF (inference) and MTLF (training) from Rel-17 |
| RAN AI | TR 37.817 (Rel-17 study) → Rel-18 work item, Xn signaling in TS 38.423; air interface TR 38.843 (Rel-18) → Rel-19 | AI/ML framework for NG-RAN (energy saving, load balancing, mobility optimization use cases) and AI/ML for the air interface itself (CSI feedback, beam management, positioning) |
When a vendor slide says "AI-powered SON," ask one question: "What is learned from my network's data, and what is a fixed rule?" Both are legitimate — but only the learned part will adapt to your traffic, and only the rule part is easy to audit. You need to know which is which before you let it touch parameters. Chapter 10 gives you a full checklist.
1.3 But what is AI? A working tour — no PhD required
Before we bolt AI onto a network, let's be precise about the words — because "AI," "machine learning" and "deep learning" get used interchangeably in vendor slides, and they are not the same thing. They nest inside each other like Russian dolls, and knowing which doll you're buying changes what questions you should ask:
1.3.1 Artificial Intelligence — the umbrella
AI is the oldest and broadest term: a machine doing something that would require intelligence if a human did it — diagnosing, planning, deciding, predicting. Crucially, the definition says nothing about how. A 1990s expert system with ten thousand hand-written if-then rules is AI. Classic SON's ANR — "if the UE reports an unknown PCI, add a neighbor relation" — is AI by this definition, and it never learned anything from anyone. It was told. That distinction — told vs learned — is the border of the next ring, and it's the single most useful question in any AI procurement meeting (you met it in §1.2's field note).
1.3.2 Machine Learning — programs that improve from data
Machine learning flips the programming model on its head. Classic software: a human studies the problem, writes the rules, the machine applies them. ML: a human supplies examples, and the machine works out the rules itself. Formally — and this one line of notation is all the math this section needs — ML searches for a function:
In telecom words: find the recipe f that maps what we measured (X — counters, configuration, hour of day) to what we want to know (y — will this cell congest? is this KPI abnormal? will this radio fail?), such that the recipe would have been least wrong (loss) on everything the network already lived through.
Every ML system, from a two-line regression to a trillion-parameter LLM, is made of the same three ingredients — and diagnosing a failing AI project always starts by asking which ingredient is broken:
| Ingredient | What it is | Telecom translation | When it's the broken one |
|---|---|---|---|
| 1 · Data | Examples of X paired with outcomes y | 8 weeks of counters per cell + what actually happened (Ch. 2) | ~70% of failed projects — dirty, leaky, or mislabeled fuel |
| 2 · Model | A family of candidate functions f with tunable knobs (parameters) | a gradient-boosted tree over 40 counter features; a neural net over raw IQ samples | Rarely — modern defaults are excellent (Ch. 3) |
| 3 · Loss + optimizer | A score for "how wrong," and a procedure that nudges the knobs to reduce it | pinball loss for P90 capacity forecasts; cost-weighted errors when a miss ≠ a false alarm | Sneakily often — optimizing the wrong "wrong" (Ch. 3 §3.3) |
How do the three ingredients come together? In a loop — the loop, the one every "training" ever run consists of. Step through it on the diagram:
Step by step — One trip around the training loop
- 1 · Data in. Say 50,000 examples: each cell-week's features (busy-hour PRB p90, growth trend, band, user counts…) paired with the truth — did it congest the following week? The quality of everything downstream is capped right here.
- 2 · The model guesses. With its current knob settings (initially random or naive), the model predicts every example. Early guesses are terrible. That's expected — and fine.
- 3 · The loss judges. One number summarizes total wrongness. The choice of loss is a business decision wearing math: penalize missed congestion 10× more than a false alarm, and the model becomes cautious exactly the way you asked.
- 4 · The optimizer nudges. Each knob moves a tiny step in whichever direction reduces the loss — like tuning 10,000 RET tilts at once, each by 0.01°, guided by calculus (this is "gradient descent": the loss is a landscape; the optimizer walks downhill).
- 5 · Repeat. Thousands of loops later, the loss stops improving. The knobs now encode patterns no one programmed: "residential cells at 21:00 near a stadium on match nights…" — extracted from data, not from a rule-writer.
- 6 · Freeze and deploy. Training stops; the knobs freeze; the model becomes a fast, cheap function: new features in, prediction out in microseconds. This split matters operationally: heavy training in OAM, light inference at the edge — exactly the deployment split TR 37.817 standardizes for NG-RAN.
- 7 · Watch it age. The network the model learned no longer exists — traffic grew, software upgraded, a mall opened. Monitoring detects the drift; retraining closes the lifecycle loop. A deployed-and-forgotten model is a slow-motion outage.
1.3.3 Deep learning — when the machine learns its own features
Everything above still required a human to choose the features — to decide that "busy-hour PRB p90" and "growth trend" are the right ways to describe a cell. Deep learning removes that last human step. A neural network is built from an almost embarrassingly simple unit — the neuron: multiply each input by a weight, add them up with a bias, squash the result through a simple non-linearity. That's it. One neuron is trivial. The power is in composition:
Now stop reading and be a neuron for two minutes. This single neuron predicts cell congestion from two inputs. The weights are yours to tune — try to make it sensible (high PRB and many users should worry it; an empty cell shouldn't):
This one runs in the interactive reader — open Chapter 1 in the reader to drive it yourself.
Three things you just experienced are the entire conceptual core of deep learning:
- Weights encode importance. Crank w₁ negative and the neuron believes full cells are healthy — weights are opinions, and training is the process of forming opinions from evidence rather than from you.
- The bias sets the burden of proof. A strongly negative b means "assume healthy unless the evidence is loud" — precisely the false-alarm/miss trade-off every NOC threshold embodies (Chapter 4 will formalize it).
- One neuron draws one straight boundary. It cannot express "congested only when PRB is high while users are low (stuck scheduler!)" — a curved, combined judgment. Stack layers, and curves, exceptions and interactions become expressible. That is all "deep" means: enough stacked simplicity to express complexity.
1.3.4 The catch — memorizing vs understanding
A network with millions of knobs can do something dangerous: memorize the training data instead of learning the pattern — like a student who memorizes last year's exam answers and calls it physics. This is overfitting, and it is the central occupational disease of all machine learning:
Telecom data makes overfitting easy to hide: with strong daily/weekly cycles, a memorizer looks brilliant on any test set drawn from the same weeks it trained on. The only honest exam is data from the future relative to training — which is why Chapter 3's Rule 1 (split by time, never randomly) is a hard law in this book, and why every lab in the Lab Track scores against later-in-time ground truth.
1.3.5 And GenAI? The newest doll
Generative AI — the innermost ring of Figure 1.4 — is deep learning pointed at a different target: instead of predicting a number ("p(congested) = 0.83"), it generates content — text, code, configurations, designs. A large language model is, mechanically, a very deep network trained on one humble task at colossal scale: predict the next token. From that single trick emerge summarization, translation, Q&A and code-writing — which is why LLMs feel qualitatively different even though every concept in this section (weights, loss, training loop, overfitting) applies to them unchanged. What LLMs add operationally is a new failure mode — fluent wrongness ("hallucination") — and Chapter 11 is largely about engineering around exactly that, with retrieval grounding and cite-or-abstain discipline.
1.3.6 Choosing your ring — the engineer's cheat sheet
| Approach | Strengths | Costs / risks | Reach for it in telecom when… |
|---|---|---|---|
| Rules (classic AI) | Transparent, auditable, instant, no data needed | Handles only anticipated cases; thresholds rot | Safety interlocks, guard gates, well-understood logic (ANR). Never delete your rules — wrap them around the models. |
| Classic ML (trees/GBM) | Learns per-cell nuance from tabular counters; fast; explainable enough (SHAP) | Needs labeled history; features are your job | 90% of Part II: anomaly scoring, forecasting, failure prediction, ticket routing |
| Deep learning | Learns features from raw signals; masters sequence/image/text structure | Data-hungry, GPU-hungry, harder to explain, easier to overfit | Raw-signal problems: interference spectrograms, CSI compression TR 38.843, long sequences — when Ch. 3's backtest proves the lift |
| GenAI / LLMs | Reads, writes, explains, searches — the language interface to everything above | Hallucination, cost, prompt injection; never wire to CM directly | NOC copilots, spec RAG, ticket summarization, NL→SQL (Ch. 11) — always assistive, always cited |
1.4 The four layers where AI lives
Everything AI does in a mobile network happens in one of four places, distinguished by timescale and what it can touch. This map is the coordinate system for the whole book:
Step by step — Walk the closed loop
- 1 · Observe. Every loop starts with standardized telemetry: PM counters TS 28.552, alarms TS 28.532, call traces & MDT TS 32.422 TS 37.320. Chapter 2 is entirely about this box — it is where most real projects fail first.
- 2 · Analyze. A model turns raw telemetry into a judgment: "this cell is anomalous" (Ch. 4), "this cell will congest in 12 days" (Ch. 5), "this alarm storm has one root cause" (Ch. 8).
- 3 · Decide. Judgment becomes an intended action — always wrapped in guardrails: change windows, guard KPIs, blast-radius limits. In O-RAN this is where A1 policies live; in 3GPP management, where MDA outputs become CM change requests.
- 4 · Act. The action executes: a tilt moves, a cell sleeps, a parameter changes, a ticket dispatches a crew. At Layer 1 this is a PHY procedure; at Layer 3 it is a provisioning operation.
- 5 · …and the loop closes. The same telemetry that fed step 1 now verifies the action. If guard KPIs degrade → automatic rollback. A loop without verification is not automation, it is a hazard. This principle repeats in every playbook chapter.
This book concentrates on Layer 3 — management-timescale optimization — because that is where a network engineer with Python can deliver measurable value in weeks, without waiting for new UE chipsets (Layer 1) or a full RIC deployment (Layer 2). Chapters 10–11 then connect what you built to the RIC, NWDAF and GenAI worlds.
1.5 The KPI tree — defining "better" before optimizing it
You cannot optimize what you haven't defined. 3GPP gives KPIs a formal home — TS 32.450 for E-UTRAN and TS 28.554 for 5G end-to-end KPIs — and groups them into families that every playbook in Part II targets:
1.6 The autonomy ladder — TS 28.100's six levels
3GPP formalized "how autonomous is my network?" in TS 28.100 (Levels of autonomous network, Rel-17), a six-level scale deliberately reminiscent of driving automation levels:
| Level | Name | Who does what | Where most operators are |
|---|---|---|---|
| L0 | Manual operation | Humans do everything; tools only display | Legacy domains |
| L1 | Assisted | System executes; human decides everything | |
| L2 | Partial autonomous | System decides for some scenarios; human approves | ★ Most 4G/5G operations today (SON + supervised AI) |
| L3 | Conditional autonomous | System senses, decides and acts in defined scenarios; human handles exceptions | |
| L4 | High autonomous | System handles exceptions too, within a domain | Leading operators, narrow domains (e.g. energy saving) |
| L5 | Full autonomous | All scenarios, all domains, closed loop | Nobody. The 6G ambition. |
The honest way to use this ladder: per use case, not per network. The same operator can run energy saving at L4 (Chapter 7's playbook, fully closed loop with guard KPIs) while running tilt optimization at L2 (Chapter 6 — recommendations that an engineer approves). The playbooks in Part II each state the autonomy level they're written for, and Chapter 12 shows the safe promotion path L2 → L3 → L4: shadow mode → supervised mode → closed loop with rollback.
Jumping straight to closed loop because a demo looked good. Every mature team runs a new model in shadow mode first — the model recommends, humans act, and you measure agreement for weeks before granting it hands. The playbook chapters build this into their rollout sections.
1.7 How this book works
Three commitments, kept in every chapter:
- 100% spec-grounded. When a data source, procedure or function is standardized, you get the reference — like TS 28.552 for the counters or TS 23.288 for NWDAF — so you can verify everything against the source. Appendix A collects every cited spec into one atlas.
- 100% practical. Part II is six playbooks, each with the same skeleton: Problem → Data → Method ladder (simple → advanced) → Worked example with Python → Rollout & verification → Pitfalls from the field → Quiz. Nothing is included that hasn't a path to production.
- Wire-diagram thinking. Complex systems are drawn as node-and-wire diagrams (in the visual language of interactive flow editors): boxes are functions, animated dashed wires are data or control flows, pink means "the thing to look at." Steppers let you replay flows one step at a time.
One suggestion before you turn the page: pick a pilot cluster in your own network — 200–2,000 cells you know well — and apply each playbook to it as you read. The book is designed so that by Chapter 12 that cluster has a working anomaly detector, a capacity forecast, and at least one closed-loop candidate. That is the whole point.
Chapter 1 — Check yourself
Q1. Which 3GPP specification defines the six levels of autonomous network (L0–L5)?
- TS 28.552
- TS 23.288
- TS 28.100
- TR 38.843
Answer: TS 28.100 — TS 28.100 "Levels of autonomous network" (Rel-17) defines L0–L5. TS 28.552 is 5G performance measurements, TS 23.288 is NWDAF, TR 38.843 is the AI/ML air-interface study.
Q2. What is the fundamental difference between classic SON and AI-era optimization?
- SON runs in the core, AI runs in the RAN
- SON executes fixed hand-written rules; AI learns functions from the network's own data
- SON is 3GPP-standardized, AI is not standardized anywhere
- SON is real-time, AI is always offline
Answer: SON executes fixed hand-written rules; AI learns functions from the network's own data — SON (TS 32.500, TS 28.313) automates via predefined if-then logic; AI learns from data and adapts per cell/time. AI *is* being standardized (TS 28.104/105, TS 23.288, TR 37.817) — so the third option is false.
Q3. NWDAF, defined in TS 23.288, splits from Rel-17 into which two logical functions?
- AnLF (inference/analytics) and MTLF (model training)
- Near-RT and Non-RT functions
- xApp and rApp
- MDAF and MDAS
Answer: AnLF (inference/analytics) and MTLF (model training) — Rel-17 split NWDAF into the Analytics Logical Function (AnLF) that serves inferences and the Model Training Logical Function (MTLF) that trains models. Near/Non-RT RIC and xApp/rApp are O-RAN concepts, not TS 23.288.
Q4. TR 37.817 (Rel-17) studied an AI/ML framework for NG-RAN with three flagship use cases. Which set is correct?
- CSI compression, beam management, positioning
- Churn prediction, ARPU modeling, CX scoring
- Slicing, URLLC scheduling, paging optimization
- Network energy saving, load balancing, mobility optimization
Answer: Network energy saving, load balancing, mobility optimization — TR 37.817's three use cases are energy saving, load balancing and mobility optimization. CSI/beam/positioning is the *air-interface* study, TR 38.843.
Q5. Per the "optimizer's contract," what must every optimization action define in advance?
- The vendor, the license cost, and the release version
- The target KPI, the guard KPIs, and the rollback trigger
- Only the target KPI — the rest emerges during the change
- A neural network architecture
Answer: The target KPI, the guard KPIs, and the rollback trigger — Target KPI + guard KPIs + rollback trigger, named before acting. This contract is independent of whether a human, a rule, or a model made the decision.
Q6. Classic SON's ANR function ("if the UE reports an unknown PCI, add a neighbor") is…
- Machine learning, because it reacts to UE data
- AI but not ML — goal-directed automation whose rules were written by humans, not learned from data
- Deep learning
- Not AI at all
Answer: AI but not ML — goal-directed automation whose rules were written by humans, not learned from data — The AI umbrella includes rule-based systems. The told-vs-learned border is what separates classic AI from ML — and it's the question to ask about every "AI-powered" product.
Q7. Every machine-learning system consists of which three ingredients?
- GPU, cloud, Python
- Neurons, layers, tokens
- Training, testing, marketing
- Data (X,y examples), a model family with tunable parameters, and a loss + optimizer that nudges the parameters to reduce wrongness
Answer: Data (X,y examples), a model family with tunable parameters, and a loss + optimizer that nudges the parameters to reduce wrongness — Data · model · loss+optimizer. When a project fails, diagnose in that order — data is the culprit ~70% of the time, the loss choice sneakily often, the model rarely.
Q8. What does "depth" in deep learning actually buy you?
- Stacked layers learn a hierarchy of features from raw signals — simple patterns combine into abstract ones, removing the human feature-engineering step
- Faster training than classic ML
- Immunity to overfitting
- Smaller models
Answer: Stacked layers learn a hierarchy of features from raw signals — simple patterns combine into abstract ones, removing the human feature-engineering step — One neuron draws one straight boundary; stacked layers express curves, interactions and exceptions — and invent their own features. The costs (data, compute, explainability) are why classic ML still wins on counter tables (Ch. 3).
Q9. A model scores near-perfectly on its training weeks but fails on next month's data. This is called… and the honest defense is…
- Drift; add more layers
- Convergence; celebrate
- Overfitting (memorizing instead of learning); evaluate only on data from the future relative to training — time-based splits
- Hallucination; add citations
Answer: Overfitting (memorizing instead of learning); evaluate only on data from the future relative to training — time-based splits — Telecom's strong seasonality makes memorizers look brilliant on same-period test data. Figure 1.7's lesson becomes Chapter 3's Rule 1: split by time, never randomly.
Q10. Layer 3 ("management AI") differs from Layer 2 ("RAN control AI") mainly by…
- using different programming languages
- being non-standardized
- timescale (seconds–days vs 10 ms–1 s) and what it touches (CM/policy vs live RRM decisions)
- running only in the UE
Answer: timescale (seconds–days vs 10 ms–1 s) and what it touches (CM/policy vs live RRM decisions) — The layers are separated by control timescale and scope of action: Near-RT RIC xApps steer RRM at 10 ms–1 s; management-plane analytics (MDA, rApps, SON) act on configuration and policy at ≥ 1 s, typically minutes to days.