AI/ML in Telecom
Networks

Foreword — From Counters to Cognition

For three decades, mobile networks have been tuned by hand. An engineer reads an alarm, opens a counter report, changes a parameter, and waits to see what happens. That craft built the world’s connectivity — but it cannot keep pace with networks that now carry massive MIMO, dynamic TDD, network slicing, and billions of connected devices. The number of knobs has exploded; the number of hours in a day has not.

Machine learning changes the economics of optimization. Instead of one engineer tuning one cell, a single model can learn the behaviour of 100,000 cells at once, predict problems before subscribers feel them, and adjust the network in closed loop. This book is about building those models — not as academic exercises, but as production systems that solve real operator problems.

Who This Book Is For

What Makes This Book Different

Most ML books teach you to classify flowers or predict house prices. The features are clean, the problems are toy, and the gap to a live network is enormous. This book takes the opposite approach: every example starts from telecom data — a real PM counter, a real KPI formula, a real handover statistic — and walks through to a model you could actually deploy. When we forecast traffic, the input is pmPdcpVolDlDrb. When we detect anomalies, the signal is a genuine cell-level KPI time series. No toy datasets; telecom problems with telecom features.

How to Read This Book

1.1 The Data Goldmine Under Every Tower

A modern mobile network generates an extraordinary volume of data. A single LTE/5G base station produces 500+ PM counters every 15 minutes, covering everything from traffic volume and throughput to interference levels and handover success rates. Across a national network of 50,000 sites with 3 sectors each, that is 150,000 cells × 500 counters × 96 intervals/day = 7.2 billion data points per day.

Yet the vast majority of this data goes unanalyzed. Traditional optimization relies on threshold-based alarms and manual drive testing — approaches that worked for 2G/3G but cannot scale to the complexity of 5G networks with massive MIMO, dynamic TDD, and millions of connected devices. This is where AI/ML transforms the game.

1.2 What AI Can Do That Rules Cannot

Traditional network optimization uses hand-crafted rules: "if RSRP < -110 dBm, add a new site" or "if PRB utilization > 80%, split the cell." These rules are static, single-dimensional, and cannot capture the complex, non-linear interactions between hundreds of network parameters. AI/ML brings three fundamental capabilities:

1.3 The AI Use Case Taxonomy

1.4 3GPP & O-RAN Standardization

AI in telecom is no longer experimental — it is being standardized:

1.5 What This Book Covers

• Part I (Ch 1–5): ML/DL fundamentals tailored for telecom — the math, algorithms, and Python tools you need
• Part II (Ch 6–10): Telecom data sources — PM counters, MDT, CDR, feature engineering, data pipelines
• Part III (Ch 11–16): AI-powered RAN optimization — coverage, capacity, interference, handover, energy, SON 2.0
• Part IV (Ch 17–22): Advanced applications — anomaly detection, predictive maintenance, NLP, GenAI/LLMs, O-RAN RIC, digital twins
• Part V (Ch 23–27): Deployment — MLOps, real-world case studies, ethics, 6G AI-native vision, career guide

2.1 The Three Learning Paradigms

2.2 Key Algorithms for Telecom

2.3 Model Evaluation Metrics

Choosing the right metric is critical. A call drop prediction model with 99% accuracy sounds great — until you realize only 0.5% of calls actually drop, so predicting "no drop" every time gives 99.5% accuracy. The right metrics depend on the problem:

3.1 Neural Network Architecture

A neural network is a function approximator composed of layers of interconnected neurons. Each neuron computes a weighted sum of its inputs, adds a bias, and passes the result through a non-linear activation function. For telecom applications, we primarily use:

• Dense (Fully Connected) Networks: For tabular PM counter data. Input = feature vector (500+ KPIs), output = prediction (throughput, drop probability). Typically 3–5 hidden layers with 128–512 neurons each.
• CNN (Convolutional Neural Networks): For spatial data — coverage maps, interference maps, population density grids. The convolution operation captures local spatial patterns (coverage holes, interference hotspots).
• LSTM/GRU (Recurrent Networks): For time-series data — traffic forecasting (predict next 24h from past 7 days), KPI trend prediction, sequence-based anomaly detection.
• Transformer: For sequence data with long-range dependencies — alarm log analysis, NLP-based fault diagnosis, attention over multi-cell KPI sequences.

3.2 Activation Functions

3.3 Training a Telecom DNN

import tensorflow as tf
from sklearn.model_selection import train_test_split
from sklearn.preprocessing import StandardScaler

# Load PM counter dataset (500 features, target = avg_dl_throughput)
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2)
scaler = StandardScaler()
X_train = scaler.fit_transform(X_train)
X_test = scaler.transform(X_test)

# Build model
model = tf.keras.Sequential([
    tf.keras.layers.Dense(256, activation='relu', input_shape=(X_train.shape[1],)),
    tf.keras.layers.Dropout(0.3),
    tf.keras.layers.Dense(128, activation='relu'),
    tf.keras.layers.Dropout(0.2),
    tf.keras.layers.Dense(64, activation='relu'),
    tf.keras.layers.Dense(1)  # Regression output
])

model.compile(optimizer='adam', loss='mse', metrics=['mae'])
model.fit(X_train, y_train, epochs=50, batch_size=64,
         validation_split=0.15, callbacks=[
    tf.keras.callbacks.EarlyStopping(patience=5, restore_best_weights=True)
])

3.4 CNN for Coverage Map Analysis

Coverage maps are 2D spatial data — perfect for CNNs. A coverage map can be represented as a grid where each pixel contains the RSRP value (or SINR, throughput). A CNN trained on labeled coverage maps can identify coverage holes, interference zones, and optimal site locations far faster than manual analysis.

3.5 LSTM for Traffic Time Series

3.6 Hyperparameter Guide for Telecom DNNs

4.1 The Five-Layer AI Stack

4.2 Data Volume Estimates

5.1 Loading & Exploring PM Counter Data

import pandas as pd
import numpy as np

# Load PM counter CSV (typical Ericsson/Huawei export format)
df = pd.read_csv('pm_counters_daily.csv', parse_dates=['timestamp'])

# Basic exploration
print(f"Cells: {df['cell_id'].nunique()}")        # 150,000 cells
print(f"Counters: {len(df.columns) - 2}")       # 500+ PM counters
print(f"Time range: {df['timestamp'].min()} to {df['timestamp'].max()}")

# Calculate KPIs from raw counters
df['dl_throughput_mbps'] = df['pmPdcpVolDlDrb'] * 8 / (1e6 * 900)  # bits/sec for 15min
df['prb_util_pct'] = df['pmPrbUsedDl'] / df['pmPrbAvailDl'] * 100
df['ho_success_rate'] = df['pmHoExeSucc'] / df['pmHoExeAtt'] * 100
df['rrc_setup_sr'] = df['pmRrcConnEstabSucc'] / df['pmRrcConnEstabAtt'] * 100

# Find problematic cells (low throughput + high PRB utilization)
problem_cells = df[
    (df['dl_throughput_mbps'] < 10) &
    (df['prb_util_pct'] > 80)
]['cell_id'].unique()
print(f"Congested cells: {len(problem_cells)}")

5.2 Time-Series Analysis

# Group by hour to find busy hour pattern
hourly = df.groupby(df['timestamp'].dt.hour).agg({
    'dl_throughput_mbps': 'mean',
    'prb_util_pct': 'mean',
    'pmActiveUeDl': 'mean'
})

busy_hour = hourly['pmActiveUeDl'].idxmax()
print(f"Network busy hour: {busy_hour}:00")  # Usually 20:00-21:00

# Rolling average for trend detection (7-day window)
df['throughput_7d_avg'] = df.groupby('cell_id')['dl_throughput_mbps'] \
    .transform(lambda x: x.rolling(7, min_periods=1).mean())

# Detect cells with declining throughput trend
trends = df.groupby('cell_id').apply(
    lambda g: np.polyfit(range(len(g)), g['throughput_7d_avg'], 1)[0]
)
declining = trends[trends < -0.5].index  # Losing >0.5 Mbps/day

5.3 Geospatial Analysis for Coverage

import folium
from folium.plugins import HeatMap

# Create coverage heatmap from MDT measurements
mdt = pd.read_csv('mdt_measurements.csv')
m = folium.Map(location=[28.61, 77.23], zoom_start=12)

# RSRP heatmap (weight by signal strength)
heat_data = mdt[['lat', 'lon', 'rsrp']].values.tolist()
HeatMap(heat_data, min_opacity=0.3, radius=15).add_to(m)
m.save('coverage_heatmap.html')

6.1 PM Counter Types

• Event Counters (Cumulative): Count occurrences over the measurement period. Examples: pmRrcConnEstabAtt (RRC connection attempts), pmHoExeSucc (successful handovers). Reset to zero each period. Use for rate calculations: success_rate = success_count / attempt_count.
• Gauge Counters (Snapshot): Instantaneous or average value during the period. Examples: pmActiveUeDl (average active DL users), pmRadioRecInterferencePwrAvg (interference power). Directly usable as ML features.
• DCC (Delta Cumulative Counter): Change in a cumulative counter over the period. Examples: pmPdcpVolDlDrb (DL data volume in bytes). Used for throughput and volume calculations.

6.2 Essential KPI Formulas

6.3 Vendor Counter Mapping

7.1 MDT vs. Drive Test

7.2 The Two MDT Modes (TS 37.320)

3GPP TS 37.320 defines MDT and splits it into two modes — you need both for full coverage. They are configured through the Trace framework (TS 32.421/32.422/32.423):

MDT also defines standardised measurement types — M1 (RSRP/RSRQ, SS-RSRP/RSRQ/SINR in NR), M2 (power headroom), M4 (data volume), M5 (throughput), M6 (packet delay) and M7 (packet loss) — plus the all-important RLF Report reused by MRO (Ch 14). Location comes from GNSS when available or RF fingerprinting otherwise.

7.3 MDT for ML Training Data

MDT provides the ground truth for coverage prediction ML models. Each report contains: (1) GPS location (lat/lon, 10–50 m accuracy), (2) RSRP/RSRQ per detected cell, (3) serving cell ID, (4) timestamp, and (5) trigger event (periodic, A2 threshold). Collect millions of reports over weeks and you have a dense geo-located dataset mapping physical location to signal quality — the training data for ML-based propagation models.

# MDT fields: lat, lon, serving_cell, rsrp, rsrq, timestamp
mdt = pd.read_csv('mdt_reports.csv', parse_dates=['timestamp'])

# Add GIS features (distance to serving cell, terrain height, clutter type)
mdt['dist_km'] = haversine(mdt['lat'], mdt['lon'],
                           mdt['cell_lat'], mdt['cell_lon'])
mdt['terrain_height'] = get_dem_height(mdt['lat'], mdt['lon'])
mdt['clutter_type'] = get_clutter_class(mdt['lat'], mdt['lon'])

# Compute path loss = Tx_power + Ant_gain - Cable_loss - RSRP
mdt['path_loss_db'] = 46 + 17.5 - 2.5 - mdt['rsrp']

# ML target: predict path_loss from (distance, frequency, terrain, clutter)
features = ['dist_km', 'frequency_mhz', 'terrain_height',
            'clutter_type', 'antenna_height', 'tilt_deg']

8.1 CDR Structure

A CDR captures metadata for every voice call or data session. For a data session, key fields include: IMSI, cell ID, start/end time, uplink/downlink volume (bytes), peak throughput, QCI (QoS class), and bearer type. For voice: call duration, setup time, MOS estimate, codec used. CDRs are the bridge between network KPIs (cell-level) and user experience (subscriber-level).

8.2 User Experience Scoring

CDRs themselves are standardised: the file format in TS 32.297 and the ASN.1 encoding in TS 32.298, produced by the CDF/CGF in the charging architecture (TS 32.240). Each data record carries the QoS identifier — QCI in LTE, 5QI in 5G (TS 23.501) — which tells you whether a session was, say, conversational voice (5QI 1), live video (5QI 2) or best-effort data (5QI 9), and therefore how to weight its experience.

8.3 Churn Prediction from Experience

The highest-value CDR application is churn prediction: subscribers who repeatedly suffer poor experience leave. Aggregate per-subscriber experience over weeks, add tenure/plan/complaint features, and a gradient-boosted classifier flags at-risk users so retention can act before they port out.

9.1 Feature Categories

9.2 Feature Engineering Code Example

def engineer_features(df):
    """Transform raw PM counters into ML-ready features."""
    # Temporal features
    df['hour'] = df['timestamp'].dt.hour
    df['dow'] = df['timestamp'].dt.dayofweek
    df['is_weekend'] = (df['dow'] >= 5).astype('int')
    df['is_busy_hour'] = df['hour'].isin([19,20,21]).astype('int')

    # Rolling statistics (7-day window)
    for col in ['dl_throughput', 'prb_util', 'active_users']:
        df[f'{col}_7d_avg'] = df.groupby('cell_id')[col] \
            .transform(lambda x: x.rolling(7*96).mean())
        df[f'{col}_7d_std'] = df.groupby('cell_id')[col] \
            .transform(lambda x: x.rolling(7*96).std())
        df[f'{col}_pct_change'] = df.groupby('cell_id')[col] \
            .transform(lambda x: x.pct_change(periods=96))  # vs 24h ago

    # Cross-features (domain knowledge!)
    df['users_per_prb'] = df['active_users'] / (df['prb_util'] + 1)
    df['spectral_efficiency'] = df['dl_throughput'] / (df['bandwidth_mhz'] + 1)
    df['ho_ping_pong_ratio'] = df['pmHoPingPong'] / (df['pmHoExeSucc'] + 1)

    return df

10.1 Pipeline Architecture

A production telecom ML pipeline has five stages: Extract (pull PM counters from OSS/NMS via northbound API or file export), Validate (check for missing cells, counter resets, NaN values), Transform (calculate KPIs, engineer features, normalize), Store (write to time-series DB like InfluxDB or data lake), and Serve (provide feature store for ML training and inference).

10.2 Data Quality Checks

• Completeness: Are all expected cells reporting? Missing cells may indicate OSS collection failure, not network outage. Target: >99% cell reporting rate.
• Counter Resets: Cumulative counters reset at midnight or during eNB restart. Detect negative deltas and handle by using max(0, delta) or discarding the sample.
• NaN/Null Handling: PM counters can be null when the cell is locked or during maintenance. Impute with cell-specific median (not global mean) or mark as missing for tree-based models.
• Outlier Detection: A DL throughput of 10 Gbps on an LTE cell is clearly wrong. Apply physical bounds: 0 ≤ throughput ≤ theoretical_max(bandwidth, mimo_config).

10.3 Batch vs Streaming

Most telecom ML runs on batch pipelines: 15-minute PM files land, Airflow orchestrates validate→transform→store, models retrain nightly. But closed-loop use cases (anomaly detection, energy saving, xApp control) need streaming — Kafka ingests counter/telemetry events, a stream processor computes features in flight, and inference runs in seconds. A mature platform runs both and shares one feature store so training and serving see identical feature definitions (no train/serve skew).

11.1 ML-Based Propagation Model

Traditional propagation models (Okumura-Hata, TR 38.901) achieve RMSE 6–10 dB after calibration. ML models trained on MDT data + GIS features consistently achieve RMSE 3–5 dB — a 40–50% accuracy improvement. The key advantage: ML models learn environment-specific propagation characteristics (building materials, vegetation density, terrain micro-features) that parameterized models cannot capture.

import xgboost as xgb
from sklearn.metrics import mean_squared_error
import numpy as np

# Features: distance, frequency, antenna height, tilt, terrain, clutter
features = ['log_distance', 'frequency_ghz', 'ant_height_m',
            'e_tilt_deg', 'm_tilt_deg', 'terrain_delta_m',
            'clutter_height_m', 'clutter_type_encoded',
            'building_density', 'vegetation_index',
            'los_probability', 'fresnel_clearance_pct']

model = xgb.XGBRegressor(
    n_estimators=500, max_depth=8, learning_rate=0.05,
    subsample=0.8, colsample_bytree=0.8, reg_alpha=0.1
)
model.fit(X_train[features], y_train)  # y = path_loss_dB

y_pred = model.predict(X_test[features])
rmse = np.sqrt(mean_squared_error(y_test, y_pred))
print(f"Propagation Model RMSE: {rmse:.1f} dB")  # ~4.2 dB

11.2 Coverage Hole Detection

Coverage holes are areas where RSRP falls below the service threshold (-110 dBm for LTE, -105 dBm for data service). ML can detect them from three data sources:

• MDT-based: Cluster MDT measurements with RSRP < threshold. Use DBSCAN to identify spatial clusters of weak coverage. Advantage: actual user measurements.
• CDR-based: Identify locations where sessions fail or throughput drops below minimum. Requires geo-tagged CDRs.
• Counter-based: Cells with high RACH failure rate, low RSRP percentiles, or high TA values (users at cell edge) likely have coverage issues. Use anomaly detection to flag.

11.3 Automated Tilt Optimization with RL

Reinforcement Learning is the ideal framework for antenna tilt optimization because: (1) the action space is well-defined (tilt change: -2° to +2° per step), (2) the reward is measurable (coverage KPI improvement), and (3) the environment is dynamic (traffic changes daily). A DQN or PPO agent learns the optimal tilt policy by trial-and-error in a digital twin simulator, then deploys the policy to the live network.

12.1 Traffic Forecasting with LSTM

Mobile traffic follows strong temporal patterns: daily cycles (peak at 20:00–21:00), weekly cycles (weekday vs. weekend), and seasonal trends (growing 30–50% annually). LSTM networks capture these multi-scale patterns by maintaining a memory state across time steps.

import tensorflow as tf

# Input: past 7 days (672 time steps @ 15min), predict next 96 steps (24h)
model = tf.keras.Sequential([
    tf.keras.layers.LSTM(128, return_sequences=True,
                         input_shape=(672, n_features)),
    tf.keras.layers.Dropout(0.2),
    tf.keras.layers.LSTM(64),
    tf.keras.layers.Dropout(0.2),
    tf.keras.layers.Dense(96)  # 96 time steps = 24 hours
])
model.compile(optimizer='adam', loss='mse')

# Features per time step: traffic_volume, active_users, prb_util,
# hour_sin, hour_cos, dow_encoded, is_holiday

12.2 Capacity Exhaustion Prediction

The goal is to predict when a cell will exceed 80% PRB utilization during busy hours, triggering the need for capacity expansion (new carrier, split, or new site). Using trend extrapolation on the LSTM-predicted traffic growth, combined with the cell's current configuration (bandwidth, MIMO, carrier count), we can predict the exhaustion date with typical accuracy of ±2–4 weeks over a 6-month horizon.

import numpy as np
from datetime import timedelta

def predict_exhaustion(cell_id, traffic_forecast, current_capacity):
    """Predict when cell will exceed 80% PRB utilization."""
    threshold = current_capacity * 0.80  # 80% of max throughput

    # Find first day forecast exceeds threshold
    for day_idx, daily_peak in enumerate(traffic_forecast):
        if daily_peak > threshold:
            exhaustion_date = today + timedelta(days=day_idx)
            return {
                'cell_id': cell_id,
                'exhaustion_date': exhaustion_date,
                'days_remaining': day_idx,
                'action': 'URGENT' if day_idx < 30 else 'PLAN',
                'recommendation': get_expansion_options(cell_id)
            }
    return {'cell_id': cell_id, 'status': 'OK for 180 days'}

# Expansion options based on current config
def get_expansion_options(cell_id):
    config = get_cell_config(cell_id)
    options = []
    if config['carriers'] < config['max_carriers']:
        options.append('Add carrier (cheapest, +50-100% capacity)')
    if config['mimo'] == '4T4R':
        options.append('Upgrade to 64T64R mMIMO (+3-5x capacity)')
    options.append('Cell split (new site, +100% capacity, highest cost)')
    return options

12.3 Model Accuracy Benchmarks

13.1 Interference Detection

Interference manifests as: elevated noise floor (RTWP/RSSI above normal), low SINR despite good RSRP, high BLER, or degraded throughput. An ML model trained on these features can detect interference conditions and classify the type:

• PIM (Passive Intermodulation): Correlated with DL traffic load. RTWP increases when DL power increases. ML signature: strong correlation between pmTransmittedCarrierPower and pmUlInterference.
• External Interference: Constant RTWP elevation regardless of traffic. Often frequency-specific. ML signature: high RTWP with no correlation to DL load.
• Neighbor Overshoot: Good RSRP but poor SINR. Many neighbor cells detected. ML signature: high CQI variance, many A3 events, PCI confusion reports.

13.2 Interference Classification Model

import xgboost as xgb
from sklearn.metrics import classification_report

# Features for interference classification
interference_features = [
    'rtwp_avg',              # Avg UL interference power (dBm)
    'rtwp_stddev',           # RTWP variance over 24h
    'rtwp_dl_correlation',   # Correlation(RTWP, DL_power)
    'sinr_rsrp_gap',         # Expected SINR - actual SINR
    'cqi_variance',           # Variance of CQI distribution
    'neighbor_count_avg',     # Avg detected neighbors per UE
    'bler_dl_avg',            # DL BLER percentage
    'prb_dl_interference',   # PRBs with high interference
    'rtwp_hour_pattern',      # Encoded hourly pattern type
    'vswr_avg',               # Average VSWR (PIM indicator)
]

# Labels: 0=Normal, 1=PIM, 2=External, 3=Overshoot
clf = xgb.XGBClassifier(
    n_estimators=300, max_depth=6, learning_rate=0.05,
    scale_pos_weight=3,  # Handle class imbalance
)
clf.fit(X_train[interference_features], y_train)

print(classification_report(y_test, clf.predict(X_test[interference_features]),
      target_names=['Normal','PIM','External','Overshoot']))
# Typical F1: Normal 0.95, PIM 0.82, External 0.78, Overshoot 0.85

13.3 Feature Importance for Interference Detection

14.1 The Mobility Measurement Framework

Before any handover happens, the UE measures serving and neighbour cells and reports them per a ReportConfig configured over RRC (TS 38.331 for NR, TS 36.331 for LTE). Each report is triggered by a measurement event. ML-based mobility optimization is, at its core, the art of choosing the right event thresholds and offsets per cell pair — so you must know the events cold.

14.2 The A3 Event — Where the Knobs Live

The A3 entering condition is the equation MRO actually tunes. The neighbour must beat the serving cell by the configured offset, after individual offsets and hysteresis, and stay that way for Time-to-Trigger (TTT):

Raising a3-Offset or the per-pair CIO makes the UE cling to the serving cell longer (fewer too-early HOs and ping-pongs, but more too-late HOs); lowering it does the opposite. timeToTrigger and hysteresis trade responsiveness against stability. The L3 filter coefficient (filterCoefficient, TS 38.331 §5.5.3.2) smooths the measurement and adds its own delay. These five parameters, per cell pair, are the entire MRO action space.

14.3 The Handover Failure Taxonomy (MRO)

Mobility Robustness Optimization (TS 28.313 SON management; TS 38.300 procedures) classifies failures from the UE’s RLF Report and the inter-node Handover Report. The reconnection cell after a Radio Link Failure tells you which failure occurred:

14.4 ML Model: Predicting the Failure Type per Cell Pair

The killer application is a supervised classifier that, given a cell pair’s context, predicts its dominant failure mode — so you can pre-emptively re-tune before subscribers suffer drops. XGBoost on tabular cell-pair features reaches F1 > 0.8 in practice.

import xgboost as xgb
from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report

# X: cell-pair features (Table 14.3); y in {ok, too_late, too_early, wrong_cell, pingpong}
X_tr, X_te, y_tr, y_te = train_test_split(X, y, test_size=0.2, stratify=y)

clf = xgb.XGBClassifier(
    n_estimators=400, max_depth=6, learning_rate=0.05,
    subsample=0.8, colsample_bytree=0.8,
    objective='multi:softprob', eval_metric='mlogloss')
clf.fit(X_tr, y_tr)

# SHAP tells you WHY a pair is flagged — essential before auto-tuning the network
print(classification_report(y_te, clf.predict(X_te)))

14.5 Closing the Loop: RL for Auto-Tuning

Classification tells you what is wrong; reinforcement learning decides how much to change. Frame MRO as a contextual bandit / RL problem per cell pair:

This maps directly onto the 3GPP/O-RAN split: the policy is trained in the Non-RT RIC (rApp, A1 policy) and the per-cell decisions are enforced in the Near-RT RIC (xApp over E2), exactly the mobility-optimization use case in 3GPP TR 37.817.

14.6 Modern Mobility: CHO, DAPS & L1/L2-Triggered Mobility

• Conditional Handover (CHO, Rel-16, TS 38.331): the target is prepared early and the UE executes autonomously when condEventA3/condEventA5 is met — removing the fragile measurement-report-then-command race. ML predicts the best CHO candidate set and execution thresholds.
• DAPS HO (Rel-16): Dual Active Protocol Stack keeps the source link while connecting the target, cutting interruption time to near-zero for URLLC. ML helps decide which handovers justify the extra UE complexity.
• L1/L2-Triggered Mobility (LTM, Rel-18): beam-level, lower-layer mobility for FR2. ML on beam-quality time series predicts the next-best beam/cell before the link degrades.

15.1 The Energy Opportunity

RAN energy consumption accounts for 60–80% of a mobile operator's total energy cost. A typical macro site consumes 3–6 kW (without mMIMO) or 8–15 kW (with 64T64R mMIMO). Yet network traffic varies dramatically: 3–5 AM traffic is often <5% of busy-hour traffic. AI can identify when and which cells/carriers can be temporarily deactivated without affecting coverage or user experience.

15.2 The Four Domains of Network Energy Saving

Rel-18 Network Energy Saving (NES) and the TR 37.817 energy-saving use case organise techniques along four domains. AI’s job is to pick the right combination, per cell, per time, without breaking the user experience.

15.3 The AI Energy-Saving Pipeline

The closed loop: (1) forecast traffic 30–60 min ahead per cell (LSTM / gradient boosting, MAPE < 15%); (2) check that neighbour cells have the headroom to absorb this cell’s load if it sleeps (coverage-overlap model); (3) choose the deepest safe sleep mode from Table 15.1; (4) act via O-RAN E2/A1; (5) monitor and wake instantly if traffic or RACH attempts breach a guard threshold. The coverage check in step 2 is what separates a real ES rApp from a naive timer.

def decide_sleep(cell, forecast_prb, neighbors):
    # forecast_prb: predicted PRB utilisation next 30 min (0..1)
    if forecast_prb > 0.15:
        return "keep_active"            # too much traffic to sleep

    # Can neighbours absorb this cell's offered load without congesting?
    spare = sum(max(0, 0.7 - n.forecast_prb) for n in neighbors)
    if spare < cell.forecast_prb:
        return "symbol_muting"         # light sleep only — keep coverage

    if forecast_prb < 0.03 and cell.is_capacity_layer:
        return "carrier_shutdown"      # deep sleep on a capacity-only carrier
    return "mimo_layer_reduction"

16.1 SON 1.0 vs SON 2.0

16.2 Closed-Loop Optimization Architecture

AI-SON operates in a closed loop: Observe (collect PM counters) → Analyze (ML model predicts KPI impact of parameter changes) → Decide (RL agent selects best action) → Act (push config change via O-RAN E2/A1) → Observe (measure impact). The loop runs every 15–60 minutes for near-RT optimization or every 100ms–1s for xApp-based scheduling optimization.

16.3 The Three 3GPP AI/ML Use Cases

3GPP TR 37.817 (RAN3) standardised the functional framework for AI/ML in the RAN around exactly three use cases — the backbone of SON 2.0. Each follows the same Data Collection → Model Training → Model Inference → Actor functional split:

16.4 SON Function Conflict Resolution

The hardest problem in SON 2.0 is that functions fight each other: energy saving wants to sleep a cell, load balancing wants to push traffic onto it, and mobility optimization is re-tuning the very handover thresholds load balancing depends on. SON 1.0 resolved this with brittle static priorities. SON 2.0 treats it as multi-objective optimization — an RL agent (or NSGA-II-style search) finds a Pareto-optimal action that balances energy, capacity, coverage and quality, with hard safety constraints so no single objective can collapse another.

17.1 Sleeping Cell Detection

A sleeping cell is a cell that appears operational (no alarms) but provides degraded service — low throughput, high drop rate, or zero traffic despite having coverage. Traditional alarm-based monitoring misses these because no threshold is explicitly violated. ML approaches:

• Autoencoder: Train on "normal" cell behavior (7 days of healthy KPIs). Reconstruction error on new data identifies cells behaving abnormally. Sleeping cells have high reconstruction error on traffic/throughput features.
• Isolation Forest: Fast, unsupervised anomaly detection. Scores each cell based on how easily it can be isolated from the rest. Sleeping cells are isolated due to their unusual KPI combination (low traffic + good RSRP).
• Statistical (Z-score): Compare each cell's KPIs to its cluster average. Cells with traffic >2σ below cluster average are flagged. Simple but effective for obvious sleeping cells.

# Autoencoder: learns to reconstruct normal cell behavior
encoder = tf.keras.Sequential([
    tf.keras.layers.Dense(128, activation='relu', input_shape=(n_features,)),
    tf.keras.layers.Dense(32, activation='relu'),   # Bottleneck
    tf.keras.layers.Dense(8, activation='relu'),    # Latent space
])
decoder = tf.keras.Sequential([
    tf.keras.layers.Dense(32, activation='relu', input_shape=(8,)),
    tf.keras.layers.Dense(128, activation='relu'),
    tf.keras.layers.Dense(n_features, activation='linear'),
])
autoencoder = tf.keras.Model(encoder.input, decoder(encoder.output))
autoencoder.compile(optimizer='adam', loss='mse')

# Train on HEALTHY cells only
autoencoder.fit(X_healthy, X_healthy, epochs=50, batch_size=64)

# Score all cells: high reconstruction error = anomaly
X_reconstructed = autoencoder.predict(X_all)
anomaly_scores = np.mean((X_all - X_reconstructed)**2, axis=1)
sleeping_cells = cell_ids[anomaly_scores > np.percentile(anomaly_scores, 95)]

18.1 From Reactive to Predictive

Equipment failures cause service outages that cost operators $1,000–10,000 per hour per site in lost revenue and SLA penalties. Traditional maintenance is either reactive (fix after failure) or preventive (scheduled replacement regardless of condition). Predictive maintenance uses ML to estimate remaining useful life (RUL) of equipment and trigger maintenance before failure.

18.2 Failure Prediction Features

• Alarm sequences: Specific alarm patterns (VSWR high → PA degradation → cell down) often precede failures. LSTM models learn these temporal patterns.
• PM counter trends: Gradual VSWR increase, TX power drift, noise floor elevation indicate hardware degradation.
• Environmental: Temperature, humidity, power supply voltage. Extreme conditions accelerate failure.
• Age & model: Equipment age, hardware revision, firmware version. Some hardware batches have known failure modes.

18.3 Framing the Prediction Problem

There are three standard framings, in increasing sophistication:

import xgboost as xgb

# Label = 1 if the unit failed within 72h AFTER the feature window.
# Critical: exclude the failure window itself to avoid label leakage.
features = roll_window(pm_counters, alarms, env, window='7D')   # trends, slopes, counts
labels   = failed_within(events, horizon='72H', guard='2H')

clf = xgb.XGBClassifier(
    n_estimators=500, max_depth=5, learning_rate=0.03,
    scale_pos_weight=40,            # failures are rare (~2%) — weight them up
    eval_metric='aucpr')           # precision-recall AUC, not accuracy
clf.fit(X_tr, y_tr)

# Convert risk score to a maintenance ticket only above a precision-tuned threshold,
# so field crews aren't flooded with false alarms.
risk = clf.predict_proba(X_live)[:, 1]
dispatch = site_ids[risk > OPERATING_THRESHOLD]

19.1 Alarm Correlation & Deduplication

A typical NOC receives 50,000–200,000 alarms per day. Most are duplicates, cascaded from a single root cause, or informational. NLP-based alarm correlation groups related alarms, identifies the root cause alarm, and suppresses noise — reducing actionable alarms by 60–80%.

The techniques, in order of sophistication:

• Rule + topology correlation: group alarms by site/board/cell and parent-child resource relationships — kills the obvious cascades cheaply.
• Temporal-pattern mining: alarms that co-occur within seconds across many incidents form a signature (frequent-itemset / FP-growth).
• Embedding clustering: embed alarm text + attributes, cluster, and treat the earliest alarm in a dense cluster as the probable root cause.

19.2 Trouble Ticket Classification & Routing

Support tickets often contain unstructured text: “Customer reports no signal at home, address: 123 Main St.” A fine-tuned transformer (BERT/DistilBERT on a telecom corpus) classifies tickets into categories (coverage, capacity, interference, hardware, core), extracts entities (location, technology, symptom), and routes to the right team — cutting mean-time-to-resolution (MTTR) by 25–40%.

from transformers import pipeline

clf = pipeline("text-classification",
               model="telco-bert-ticket-router")   # fine-tuned on labelled tickets

ticket = "No 5G indoors since the storm; LTE only. Area: sector 3."
pred = clf(ticket)[0]
# -> {'label': 'coverage/hardware', 'score': 0.94}  --> auto-route to RF field team

20.1 The Telecom LLM Opportunity

LLMs (GPT-4, Claude, Llama) can serve as intelligent copilots for telecom engineers. Key applications:

• NOC Copilot: "Why is cell X showing high drop rate?" → LLM queries PM counters, alarm history, recent config changes, and neighbor behavior to provide a structured root cause analysis.
• Configuration Assistant: "Generate the MML script to add a new NR cell on n78 with 100 MHz bandwidth" → LLM generates vendor-specific configuration scripts (Ericsson AMOS, Huawei MML, Nokia NetAct).
• 3GPP Spec Q&A: "What is the maximum number of SSB beams in FR2?" → LLM trained on 3GPP specifications provides accurate, referenced answers.
• Report Generation: "Create the weekly KPI report for the Delhi cluster" → LLM generates formatted reports with charts, trend analysis, and recommendations from raw PM data.
• Training & Onboarding: New engineers ask questions in natural language and get expert-level answers sourced from internal knowledge bases.

20.2 RAG: Grounding the Model in Truth

Retrieval-Augmented Generation is non-negotiable for telecom. Instead of trusting the model’s parametric memory, you retrieve verified facts — the live counter catalogue, the actual 3GPP clause, this site’s current config — and force the model to answer only from them, with citations.

20.3 From Copilot to Agent

The trajectory runs from copilot (answers questions, drafts scripts — human executes) to agent (plans and calls tools — query PM database, run a diagnostic, draft a change request — with the human approving the final action). The safe pattern keeps the human on the loop for any write to the network.

21.1 O-RAN RIC Architecture

• Non-RT RIC: Runs in the SMO (Service Management and Orchestration). Timescale: >1 second. Hosts rApps for policy management, ML model training, and network analytics. Communicates with Near-RT RIC via A1 interface (policies) and O1 interface (management).
• Near-RT RIC: Runs close to the RAN (CU/DU). Timescale: 10ms–1s. Hosts xApps for real-time RAN control: scheduling optimization, beam management, handover decisions. Communicates with E2 nodes (CU-CP, CU-UP, DU) via E2 interface.
• A1 Interface: Carries ML policies from Non-RT RIC to Near-RT RIC (e.g., "optimize for energy saving during 2–6 AM").
• E2 Interface: Carries real-time telemetry and control messages between Near-RT RIC and RAN nodes.

21.2 Example xApp: Traffic Steering

A traffic steering xApp monitors per-UE throughput and cell load in real-time (<100ms), and triggers handovers to less loaded cells or different frequency layers. The xApp uses an ML model to predict which target cell will provide the best user experience, considering load, RSRP, and historical performance. This achieves 10–20% throughput improvement for cell-edge users.

21.3 xApp Development Workflow

from ricxappframe.xapp_frame import RMRXapp
import json, pickle

# Load pre-trained ML model
model = pickle.load(open('traffic_steering_model.pkl', 'rb'))

def traffic_steering_handler(self, summary, buf):
    """Called every 100ms with E2 telemetry."""
    payload = json.loads(buf)
    cell_id = payload['cell_id']
    ue_list = payload['ue_measurements']

    for ue in ue_list:
        features = extract_features(ue)  # RSRP, load, history
        best_target = model.predict([features])[0]

        if best_target != ue['serving_cell']:
            # Send handover command via E2
            self.rmr_send(create_ho_control(ue['ue_id'], best_target))

xapp = RMRXapp(traffic_steering_handler, rmr_port=4560)
xapp.run()

22.1 What is a Network Digital Twin?

A digital twin is a software simulation of the live network that mirrors: (1) the physical topology (site locations, antenna configs, frequencies), (2) the propagation environment (terrain, clutter, calibrated model), (3) the traffic patterns (per-cell, per-hour demand from historical data), and (4) the network behavior (scheduling, handovers, interference). The twin runs at 10–100x real-time, enabling millions of parameter combinations to be tested in hours instead of months.

22.2 Digital Twin for RL Training

The primary use case for digital twins in AI-telecom is as the training environment for RL agents. Instead of learning by trial-and-error on the live network (risky, slow, expensive), the RL agent trains in the digital twin where it can safely explore millions of tilt/power/frequency combinations. Once the policy converges in the twin, it is validated against recent live data and then deployed cautiously to the real network.

22.3 Building a Digital Twin

23.1 The MLOps Challenge in Telecom

87% of ML models never reach production. In telecom, the gap is even wider because: (1) models must be validated against live network safety constraints, (2) vendor OSS integration is complex, (3) regulatory requirements demand explainability, and (4) network changes affect millions of users. A robust MLOps framework is essential.

23.2 The Telecom MLOps Pipeline

• Data Pipeline: Automated PM counter ingestion → feature engineering → feature store (hourly refresh)
• Training Pipeline: Scheduled retraining (weekly) on latest data. Version models with MLflow. Track metrics history.
• Validation Gate: Before deployment: (1) accuracy on held-out test set, (2) backtesting on last 30 days, (3) safety check (no recommendation exceeds physical bounds), (4) human review for critical changes.
• Deployment: Shadow mode first (run model but don't apply changes for 1 week). Then canary deployment (apply to 5% of cells). Then full rollout if KPIs improve.
• Monitoring: Track model accuracy vs. live outcomes. Alert if prediction error exceeds threshold (model drift). Auto-trigger retraining if drift detected.

23.3 The Safe-Deployment Ladder

You never flip a model straight to 100% of a live network. Climb the ladder, and keep an automatic rollback at every rung:

23.4 Drift: The Network Is Non-Stationary

A telecom model decays because the network underneath it changes — new sites, new traffic patterns, new devices, software upgrades. Watch for data drift (input feature distributions shift) and concept drift (the input–output relationship itself changes, e.g. after a parameter audit). Monitor prediction error against realised outcomes, alert on threshold breach, and auto-trigger retraining — a model that was excellent last quarter can be dangerous today.

24.1 Case Study Highlights

24.2 What the Winners Have in Common

• One sharp problem, not a platform. Every success started from a specific, measurable pain (sleeping cells, energy bill, edge throughput) — not “let’s do AI”.
• Supervised first. Boring, explainable models (XGBoost, LSTM) shipped value long before anyone reached for reinforcement learning.
• Gradual rollout. Shadow → canary → ramp (Ch 23) — the network is too important to flip at once.
• Domain experts in the loop. RF engineers vetted features and sanity-checked recommendations; pure data-science teams stalled.

24.3 Why Projects Fail

• No clean ground truth — labels were noisy or absent, so the model learned the wrong thing.
• Train/serve skew & leakage — great offline numbers, useless live (see Ch 9, Ch 10).
• No OSS integration path — the model could predict but nothing could act on it.
• Black-box outputs — engineers wouldn’t trust unexplained recommendations, so adoption died.

25.1 Bias in Coverage Optimization

An ML model optimized purely on aggregate KPIs may inadvertently deprioritize rural or low-income areas because they generate less revenue per cell. If the optimization objective is "maximize average throughput," the model will focus resources on urban high-traffic cells. Responsible AI requires explicit fairness constraints: minimum coverage thresholds for all areas, equitable service levels across demographics, and monitoring for disparate impact.

25.2 Explainability Requirements

When an AI system recommends changing a network parameter that affects millions of users, the engineer must understand why. Use SHAP (SHapley Additive exPlanations) values to explain feature contributions for each prediction. For regulatory compliance, maintain audit trails of all AI-driven network changes, including the model version, input features, predicted outcome, and actual outcome.

25.3 Safety: What Happens When the Model Is Wrong?

AI here manages critical infrastructure — emergency calls, hospitals, payment systems all ride this network. So the design question is never “is the model accurate?” but “what happens when it is wrong?” Responsible telecom AI is built to fail safe:

• Bounded actions: every recommendation is clamped to physically and operationally safe limits.
• Automatic rollback: a KPI watchdog reverts any change that regresses service, without waiting for a human.
• Human-on-the-loop: high-impact changes require approval; the system explains itself first.
• Graceful degradation: if the model or its data feed fails, the network falls back to a safe rule-based default — never to undefined behaviour.

26.1 From AI-Assisted to AI-Native

In 5G, AI is bolted onto a hand-designed system — we use ML to optimize parameters that were designed by humans. In 6G, the system itself is designed by AI: neural network-based channel estimation replaces DMRS, learned codebooks replace static precoding matrices, and RL-based MAC schedulers replace round-robin/proportional fair algorithms. The air interface becomes a learned, end-to-end optimized communication system.

26.2 Key 6G AI Technologies

• Semantic Communication: Transmit meaning, not bits. AI encoders at the transmitter learn to compress information based on what matters to the application. 10x reduction in required data rate for equivalent service.
• Learned Channel Estimation: Replace pilot-based channel estimation with neural networks that learn the channel structure. Reduces pilot overhead by 50–70%, critical for high-mobility scenarios.
• Distributed AI: Intelligence at every network node — UEs, RUs, DUs, CUs, and core. Federated learning enables model training without centralizing data.
• Intent-Driven Networking: Operators specify high-level goals ("guarantee 100 Mbps DL in Stadium X during events") and the AI system automatically configures all parameters end-to-end.

26.3 IMT-2030: Where AI Is Built In

The ITU-R framework for 6G — IMT-2030 (Recommendation ITU-R M.2160) — makes intelligence a first-class citizen. Two of its six usage scenarios are explicitly AI-centric, and “ubiquitous intelligence” is one of the overarching design principles:

26.4 Integrated Sensing & Communication (ISAC)

In 6G the same waveform that carries data also senses — reflections reveal position, velocity and even gestures. ML is what converts raw echoes into usable inference (object detection, environment mapping), and the resulting world model feeds back into beamforming, blockage prediction and proactive mobility. This is the deepest fusion yet of the radio and the model.

27.1 The Skills Stack

27.2 A 90-Day Starter Plan

Appendix A: Open Telecom Datasets for ML

Appendix B: Python Library Quick Reference

Appendix C: Glossary

Appendix D: Key 3GPP & O-RAN References

Standards & Specifications

• 3GPP — TR 37.817, TR 38.843, TS 28.105, TS 28.104 (search the 3GPP specification portal by number)
• O-RAN Alliance — WG2 (Non-RT RIC), WG3 (Near-RT RIC), and the AI/ML workflow specifications
• ITU-T FG-ML5G — architectural framework for machine learning in future networks

Open-Source Projects Worth Cloning

Keep Learning with CafeTele