xApps vs rApps Explained: O-RAN Intelligence Interview Prep

xApps vs rApps — Decision Tier, Compute, and Feedback Loop

Sample interview questions

1. An xApp in the Near-RT RIC steers beams inside the 10ms–1s control loop. Can it train a new ML model on the fly, or must it run a pre-trained one?
   • A. xApps can train ML models in real-time; latency is not a constraint
   • B. xApps run pre-trained models (trained offline by the rApp/Non-RT RIC). Training is too compute-heavy for the Near-RT loop, so the xApp does forward inference only — a forward pass on a neural net or tree model, typically single-digit milliseconds — well inside the budget ✓
   • C. xApps always use rule-based heuristics; ML is not allowed
   • D. Beam prediction cannot use ML at all

   Option B separates the two roles correctly. The rApp does the heavy compute (training); the xApp does the fast inference. Training means forward pass + backward pass (gradients) + weight updates over many epochs. Even a small model can take hundreds of milliseconds to seconds on a GPU — far outside the Near-RT RIC budget, which the O-RAN architecture caps at 1 second per control loop (and most xApp actions land well under that). The rApp, hosted in the Non-RT RIC inside the SMO, trains offline: it collects historical KPM data (UE trajectories, CSI, beam feedback), runs training for hours or days, and freezes the weights. The xApp loads those weights and runs inference: current KPMs (CSI, UE position) → forward pass → predicted beam → action to the RAN over E2. A forward pass costs a few milliseconds, leaving headroom for the rest of the RIC logic. Offline-train / online-infer is the standard edge-ML split, and O-RAN follows it explicitly. Option A is computationally naive. Option C is too narrow — ML is useful in xApps as inference. Option D is false: beam prediction benefits from data-driven models.

2. An rApp trains a load-balancing model that predicts which cells will be congested in the next hour. How does this rApp output reach the RAN and affect real-time xApp decisions?
   • A. The rApp sends the prediction directly to the RAN via E2
   • B. The rApp sends the prediction to the Near-RT RIC via A1 as a policy: "if cell A will be congested, shift traffic to cell B." The Near-RT RIC xApps read this policy and incorporate it into their scheduling decisions on millisecond timescales. Example: when a new UE attaches, the xApp uses the policy to assign it to cell B instead of cell A ✓
   • C. The rApp sends the prediction directly to UEs; the RAN does not know about it
   • D. Predictions cannot affect real-time decisions; they are for analysis only

   Option B describes the correct information flow. The rApp prediction becomes actionable via A1 policy, which xApps consume. Example flow: 1. rApp collects historical KPM data from the past month 2. rApp trains an LSTM or tree-based model: input = time of day + day of week + current PRB usage → output = predicted PRB usage in 1 hour 3. rApp detects a pattern: "every Tuesday 3-4 PM, cell A is at 90% capacity" 4. rApp encodes this as a policy: {"timestamp": "Tuesday 2:45 PM", "action": "activate cell-congestion mode", "shift_fraction": 0.2} 5. rApp sends the policy via A1 to the Near-RT RIC 6. Near-RT RIC xApp (load balancing) receives the policy and updates its decision logic 7. When a new UE attaches at "Tuesday 2:50 PM", the xApp follows the policy and assigns it to an underutilized cell instead of cell A 8. Result: cell A congestion is prevented The key: rApp provides strategic guidance (policy), xApp executes tactically (per-UE decisions) within that guidance. Option A bypasses A1, breaking the two-tier architecture. Option C is wrong: UEs don't know about RIC predictions. Option D misses the operational benefit of predictive policies.

3. KPM (Key Performance Measurement) subscription filtering is critical for O-RAN scalability. If a DU reports all possible KPMs (per UE, per cell, per 100ms interval), what is the bandwidth impact, and why is filtering essential?
   • A. KPM bandwidth is negligible; filtering is optional
   • B. Unfiltered KPMs from a single 500-site regional DU cluster reporting 200+ metric types per cell every 100ms could exceed 100 Gbps. Filtering (requesting only PRB usage per cell, not per UE) reduces traffic by 50-90%, making E2 sustainable. xApps and rApps jointly decide which KPMs matter most ✓
   • C. KPMs are stored locally; bandwidth is not a concern
   • D. Filtering reduces visibility; operators should not filter

   Option B quantifies the scaling challenge. Unfiltered KPM export is unsustainable at scale. Example (single cell, single second): - 1 cell, 100 active UEs, 10 metric types per UE = 1,000 metric samples - Each sample = 16 bytes (timestamp + metric value) - 1 cell: 1,000 × 16 = 16 KB per second = 1.28 Gbps - Regional DU cluster: 100 cells = 128 Gbps - National operator: 10,000 cells = 1.28 Tbps (unsustainable) Filtering strategies: 1. **Spatial filtering:** Report PRB usage per cell (not per UE) → 10× reduction 2. **Temporal filtering:** Report every 500ms instead of 100ms → 5× reduction 3. **Threshold filtering:** Report only if metric exceeds threshold (e.g., only SINR < 0 dB) → 10-20× reduction 4. **Aggregation:** Report average throughput per cell, not per UE → 10-50× reduction Combined, filtering achieves 100-1000× reduction. xApps and rApps collaborate: xApps request fast, detailed metrics (100ms, per-UE); rApps request slower, aggregated metrics (10s, per-cell). Option A ignores operational limits. Option C is wrong: KPMs are exported, not just stored locally. Option D is reckless: unfiltered KPM would paralyze the RIC.

4. An xApp runs a model that predicts user handover success. If the model predicts handover will fail, the xApp can either prevent the handover (keep user on current cell) or adjust power/beam to improve handover success. What is the risk of the "prevent handover" strategy?
   • A. Preventing handover is always the right choice
   • B. Preventing handover risks cell overload and force-drops. By keeping users on the congested serving cell (instead of moving them to a target cell), the xApp may increase congestion and cause unexpected disconnections. The "adjust power/beam" strategy is safer: it tries to improve the target cell's signal so handover succeeds ✓
   • C. Handover prediction is impossible; this scenario is unrealistic
   • D. Power and beam adjustment have no effect on handover success

   Option B describes the operational trade-off. Preventing handover is a dangerous intervention if not coordinated with congestion management. Scenario: User is moving from cell A (congested) to cell B (better coverage). Model predicts handover might fail because cell B signal is weak. Strategy 1 (prevent handover): - xApp denies the handover, keeps user on cell A - User stays connected but is in a congested, suboptimal cell - Risk: cell A overload → other users get force-dropped → service degradation Strategy 2 (improve handover success): - xApp increases TX power on cell B's DL (to boost signal at user's location) - xApp steers cell B's beams toward the user (to increase SINR) - Handover succeeds; user moves to a better cell - Cell A congestion is relieved The riskier strategy is prevent handover because it treats the symptom (weak signal) rather than the cause (inadequate coverage). Keeping users on congested cells creates a cascading problem: more users on cell A → worse performance → more failed handovers → more forced drops. Proper xApp design coordinates with load-balancing rApp: if cell B is nearly full, preventing handover might make sense as a temporary measure. But preventing without coordination is dangerous. Option A oversimplifies. Option C is wrong: handover prediction is a common use case. Option D is false: beam and power directly affect link quality.

5. An operator wants to roll out a new xApp for energy saving that uses a newly trained ML model from the rApp. The operator is concerned about whether the model will work in live deployment. What is the safest rollout strategy?
   • A. Deploy to all cells immediately; if it fails, the operator can roll back later
   • B. Shadow deployment: run both old and new xApp on the same telemetry in 10% of cells. Compare outcomes (power consumption, performance degradation). After 2 weeks of validation, roll out to 50% of cells, then 100%. This reduces risk of deploying a broken model to the entire network ✓
   • C. Deploy slowly over 1 year; no need to rush
   • D. Operators cannot safely validate new models

   Option B describes the shadow deployment (canary) pattern, which is standard in ML operations. Roll-out phases: 1. **Shadow (weeks 1-2):** Run new xApp alongside old xApp on the same KPM data. Both make decisions, but only old xApp's decision is sent to the RAN. Operator logs outcomes: "new model would have reduced power by 10%, but caused 2 handover failures." Compare metrics side-by-side. 2. **Gradual (weeks 3-4):** If shadow validation is positive, enable new xApp on 5-10% of cells. Monitor power savings, handover success, SINR. If metrics degrade, immediately revert to old xApp (via A1 policy update = fast, <1 second). 3. **Ramp (week 5+):** Scale to 50%, then 100% of cells, monitoring at each step. Benefits: - Actual validation on live traffic (not just simulated data) - Limited blast radius if model is broken - Fast rollback via A1 policy - Data-driven decision (compare metrics) rather than intuition Risks mitigated: - Model overfitting on training data (shadow reveals it) - Concept drift (live traffic differs from training data) - Integration bugs (xApp infra issues) Option A is reckless: deploying broken models to 100% of network risks service outages. Option C is too slow; models degrade over time, so validation should be swift. Option D is wrong: ML models in production need validation, and shadow deployment is the standard approach.

6. An rApp ML model for traffic prediction has a 75% accuracy on test data but performs poorly in live deployment (accuracy drops to 55%). What is the most likely cause, and how can the operator fix it?
   • A. The model is inherently broken and should be discarded
   • B. Concept drift: live traffic distribution differs from training data (e.g., new app usage patterns, time-of-year effects, infrastructure changes). Fix: retrain the model weekly using recent live data, or deploy an online-learning approach where the model adapts continuously. Also implement performance monitoring so the operator detects accuracy drift before service impact ✓
   • C. Accuracy cannot vary between test and live; this scenario is impossible
   • D. The model is overfitting, but there is no fix

   Option B describes concept drift, a common challenge when deploying ML models in dynamic environments like RAN. Why accuracy drops: 1. **Temporal drift:** Traffic patterns change seasonally (summer vs winter), daily (morning vs evening), and in response to events (new social media app, sports season). Training data might be from Q1; live deployment is in Q3. Models trained on Q1 data fail to predict Q3 traffic. 2. **Distribution shift:** Network topology changes (new cell added, fiber upgrade), subscriber demographics shift, or user behavior changes (remote work trend). Model's assumptions become stale. 3. **Non-stationary environment:** RAN is a live system with constant changes. A model trained and frozen is inherently outdated. Fix strategies: 1. **Periodic retraining:** Retrain weekly using the last 4 weeks of live data. This keeps the model current. 2. **Online learning:** Instead of retraining offline, the model continuously adapts to new data (gradient-based updates). Requires careful implementation to avoid overfitting to recent noise. 3. **Ensemble:** Use multiple models trained on different time windows and average predictions. Reduces drift impact. 4. **Monitoring:** Track accuracy metrics in production. Alert if accuracy drops below threshold (e.g., 65%). Trigger manual review or automatic rollback. 5. **Feedback loops:** If the model's prediction leads to an action, measure actual outcome and retrain. Example: model predicts "cell will be congested"; operator implements mitigation; measure if congestion actually occurred. Use this ground truth to improve the model. Option A is too harsh: the model is not broken, just outdated. Option C ignores well-documented ML problems. Option D is defeatist: online learning and retraining are standard solutions.

Frequently asked questions

What are xApps?

xApps are modular applications hosted on the Near-RT RIC. They run inside the near-real-time control loop (10ms–1s) and handle reactive decisions: beam selection, power control, radio resource scheduling, interference mitigation, traffic steering. Many are still deterministic rules; others run inference on a model trained by an rApp. They subscribe to RAN telemetry (KPMs) over E2 and push control actions back over the same interface.

What are rApps?

rApps are applications on the Non-RT RIC, which sits inside the SMO. They work on a control loop slower than 1 second — typically minutes to hours — and own the strategic layer: training ML models, deriving A1 policies, balancing load across cells, and forecasting traffic. They read aggregated historical KPMs and reach the Near-RT RIC indirectly, through A1 policy and model updates rather than direct RAN control. rApps talk to the Non-RT RIC platform over the R1 interface.

How do xApps and rApps communicate?

They do not talk directly. The Non-RT RIC trains models and pushes policy/model updates to the Near-RT RIC over A1; xApps consume those. xApps subscribe to and control the RAN over E2; the resulting KPMs flow up through the SMO so rApps can train the next iteration. The chain is rApp → A1 → xApp → E2 → RAN → KPMs → SMO → rApp — a closed loop with the policy boundary at A1.

What are KPMs?

KPMs (Key Performance Measurements) are telemetry metrics from the RAN: throughput, latency, SINR, beam usage, power consumption, handover success rate, etc. Both xApps (for immediate reaction) and rApps (for long-term optimization) consume KPMs.

Can an xApp do ML?

Yes — but inference, not training. The Near-RT loop (10ms–1s) cannot absorb a training pass, so an xApp runs forward inference on a model the rApp trained offline. The rApp owns the slow, compute-heavy training; the xApp applies the frozen model inside the loop.

How does xApp model inference work in practice?

An rApp trains a beam-prediction model offline from historical KPMs and UE trajectories. The model — neural-net weights, a decision tree, or a simpler heuristic — is delivered to the Near-RT RIC; A1 carries the policy and, via the A1-ML service, the model-management workflow. The xApp loads it and runs inference (forward pass only) as new KPMs arrive over E2: a single beam-prediction pass is a few milliseconds, leaving headroom for the rest of the RIC. The xApp then issues a control action (e.g. "activate beam 7") back over E2 using the E2SM-RC service model.

What is KPM filtering, and why does it matter?

RAN nodes can export hundreds of potential KPMs (one per UE, per cell, per interval). Exporting all of them overloads the E2 interface and the RIC. KPM filtering lets the RIC subscribe to a subset: e.g., only PRB usage per cell (not per UE), only SINR > threshold, or only every 10th measurement interval. This reduces E2 traffic by 50–80% while preserving decision quality. xApps and rApps work together: xApps request fast, low-latency metrics; rApps request slower, aggregated summaries.

How do you manage xApp model versioning and updates?

Model versioning in O-RAN is handled via A1 policy and near-RT RIC state machine. When rApp completes training, it increments the model version and sends it via A1. The Near-RT RIC can: (1) hot-swap (load new model, discard old) if confident it will improve performance; (2) shadow (run new and old in parallel, compare outputs) for safety; (3) schedule updates during low-traffic windows. A/B testing is feasible: 50% of xApps use the old model, 50% use the new one. Rollback is fast (revert to prior A1 policy) if the new model degrades performance.

What carries an xApp's subscription and control over E2?

E2 runs the E2 Application Protocol (E2AP) over SCTP between the Near-RT RIC and the E2 nodes (O-CU, O-DU). The procedures an xApp uses are E2 Setup (a node registers its capabilities), RIC Subscription (the xApp asks for specific measurements), RIC Indication (the node streams the requested data back), and RIC Control (the xApp writes a parameter change). What an xApp is allowed to read or change is defined by E2 Service Models: E2SM-KPM for performance telemetry, E2SM-RC for RAN control (handover, bearer, scheduling parameters), and E2SM-CCC for cell configuration. The service model is the contract; E2AP is the transport.

What are the three O-RAN control loops, and who owns each?

O-RAN layers three loops by timescale. The real-time loop (under ~10ms) lives in the O-DU itself — HARQ, link adaptation, the MAC scheduler — and is too fast for the RIC to touch. The near-real-time loop (10ms–1s) is the xApp/Near-RT RIC layer: per-UE and per-cell reactions like beam steering and traffic steering. The non-real-time loop (over 1s, often minutes to hours) is the rApp/Non-RT RIC layer inside the SMO: policy, model training, and network-wide optimization. A frequent interview slip is putting xApps in the under-10ms loop — that budget belongs to the DU scheduler, not the RIC.

What does the A1 interface actually carry?

A1 connects the Non-RT RIC to the Near-RT RIC and carries three service types. A1-P delivers declarative policies ("keep cell-edge throughput above X for slice Y") that xApps must honor. A1-EI delivers enrichment information — context the RIC cannot derive from E2 alone, such as predicted traffic, weather, or events. A1-ML supports the model-management workflow for models the xApp will run. A1 sets intent and supplies models; it never issues per-UE commands — that stays inside the Near-RT RIC.

How do rApps compare with traditional RAN management tools?

Traditional RAN tools are vendor-specific and script-driven — each vendor ships its own EMS/NMS and proprietary KPI feeds, so automation is rewritten when the vendor changes. rApps run on the Non-RT RIC, consume standard O1/A1 interfaces, and express optimization intent as policies that any compliant vendor's RAN must obey. See /topics/open-ran-vs-traditional-ran for the full architectural comparison and operator economics.

Related topics