Network-Assisted Rate Adaptation for XR and Immersive Media: How 5G-Advanced, NWDAF, and O-RAN Enable Application-Network Collaboration

Executive summary

• XR and immersive media applications demand sustained high data rates, ultra-low latency, and stable quality, but mobile radio capacity can change rapidly because of user mobility, channel variation, scheduling decisions, and coexistence with other traffic.
• Traditional application-layer rate adaptation relies on endpoint-observed symptoms such as buffer state, packet loss, or measured throughput, which means the application often reacts only after quality has already degraded.
• The 5G System (5GS) provides architectural building blocks — including the Network Exposure Function (NEF), Network Data Analytics Function (NWDAF), Policy Control Function (PCF), QoS flows, and RAN assistance mechanisms – that create a foundation for richer application-network collaboration.
• NetXRate is a research approach that illustrates how these building blocks can be combined to deliver per-flow rate recommendations from the network to XR applications, using O-RAN RAN Intelligent Controller (RIC) intelligence, NWDAF analytics, and fairness-aware allocation.
• Simulation results reported in the NetXRate paper show up to 96% reduction in XR session outages compared to conventional Over-The-Top (OTT) adaptation, with additional benefits for coexisting enhanced Mobile Broadband (eMBB) services.
• This direction matters for future telecom and computing systems because immersive services will increasingly depend on coordinated intelligence across applications, core networks, RAN, and developer-facing APIs.

1. Why XR challenges conventional rate adaptation

eXtended Reality (XR) encompasses virtual reality, augmented reality, mixed reality, volumetric video, holographic communication, and cloud-rendered immersive experiences. These services share a common profile: they need sustained high throughput, tight latency budgets, low packet loss, and — critically — stable quality over time. A single-sensor holographic capture setup may require 6–12 Mbps, while a multi-sensor 360° body capture can reach 10–30 Mbps per user. In a multi-party session, a single device may receive multiple such streams simultaneously.

Conventional Adaptive Bitrate (ABR) mechanisms work well for on-demand video streaming over the public Internet. A client monitors playback buffer occupancy, packet arrival times, estimated throughput, or transport-layer loss, and then increases or decreases the media bitrate. These strategies fall into buffer-based, rate-based, and hybrid categories, and they have been extensively studied for two-dimensional video.

In mobile networks, however, the available radio capacity for a given user can change on the order of milliseconds to seconds — because of fading, mobility, handover, scheduler reallocation, or the arrival and departure of other users in the same cell. When an XR application probes for more bandwidth by increasing its sending rate, it may overshoot the available capacity, triggering queuing, retransmissions, and playback stalls. When it backs off after detecting a stall, it may underuse capacity that has since become available. The result is a characteristic sawtooth pattern: repeated cycles of rate increase, congestion, quality drop, and recovery.

For interactive XR, these oscillations are especially harmful. Unlike buffered video-on-demand, interactive immersive media has very little tolerance for stalls or abrupt quality changes. Studies have shown that users may tolerate gradual quality variation, but playback interruptions cause noticeable discomfort and can induce motion sickness. A moderate but stable bitrate is often preferred over a higher but fluctuating one.

Multi-user XR compounds the challenge. When several XR users share a cell and all run independent endpoint-based adaptation, their controllers can become synchronized: all detect congestion at the same moment, all back off, all probe upward together, and all trigger congestion again simultaneously.

2. From application-only adaptation to application-network collaboration

It is useful to distinguish four progressively collaborative models of media rate adaptation.

Application-only adaptation means the media application adapts based solely on what it can observe at the endpoint: buffer level, packet arrivals, transport feedback, loss, delay, or estimated throughput. The application has no direct visibility into network conditions.

Network-aware adaptation means the application has access to some network-related information — for example, an indication of whether a requested Quality of Service (QoS) profile is being honoured, or a periodic report of current connectivity conditions. The application still interprets the information and decides how to adapt.

Network-assisted adaptation goes further. The network provides analytics, measurements, predictions, or guidance that the application can combine with its own endpoint feedback. The application benefits from information that would otherwise be invisible at the endpoint, such as cell-level capacity, competing traffic load, or scheduler state.

Network-recommended adaptation is the most actionable form. Instead of exposing only raw metrics, the network provides an explicit recommendation — for example, "this flow should not exceed X Mbps for the next interval." The application can use the recommendation as an upper bound or operating guide while retaining full control over codec settings, resolution, frame rate, pacing, and quality-level selection.

A critical principle across all these models is that network assistance does not mean network control of the application. The network provides useful context; the application makes the final adaptation decision.

3. The 5G System as an enabling foundation

The 5G System, as defined in 3GPP specifications such as TS 23.501 (architecture) and TS 23.502 (procedures), provides a rich set of building blocks that enable application-network collaboration.

Application Function (AF): Represents application-side logic that can interact with 5GS capabilities through standardized interfaces. An XR service backend is a natural example of an AF.

Network Exposure Function (NEF): Provides controlled, authorized exposure of network capabilities and events to external or internal application functions. The NEF is the primary gateway for developer-facing network interaction.

Network Data Analytics Function (NWDAF): Provides network analytics to network functions and, through exposure, potentially to application functions. NWDAF can collect data from multiple sources and generate insights about load, performance, mobility patterns, and service experience.

Policy Control Function (PCF): Provides policy and QoS context, including session-level policy data such as 5G QoS Identifier (5QI) settings, Allocation and Retention Priority (ARP), and traffic treatment rules.

Session Management Function (SMF): Manages PDU sessions and QoS flows. User Plane Function (UPF): Handles packet forwarding, traffic detection, QoS enforcement, and user-plane measurement. Access and Mobility Management Function (AMF): Provides registration, reachability, mobility, and location context.

NG-RAN: The next-generation Radio Access Network provides radio resource management, scheduling, and radio-level measurements.

The 5GS QoS model operates at the granularity of QoS flows, each associated with QoS characteristics including resource type (Guaranteed Bit Rate or non-GBR), priority level, packet delay budget, packet error rate, and maximum data burst volume. The system supports QoS monitoring, event exposure, and notification mechanisms.

Recent 5GS evolution introduces XR and interactive media support, including multi-modal QoS frameworks, PDU Set based handling for burst-level treatment, mechanisms for RAN-controlled uplink bitrate recommendation, support for ECN marking for Low Latency Low Loss Scalable Throughput (L4S), and network exposure of 5GS information relevant to high-data-rate low-latency services.

Together, these building blocks create a foundation on which researchers and system designers can explore increasingly collaborative adaptation models.

4. NetXRate as an example approach

NetXRate is a research proposal published in IEEE Transactions on Broadcasting that explores network-assisted rate recommendation for XR services. The paper demonstrates how network-side analytics, RAN awareness, and application-layer rate control can be combined to deliver per-flow rate recommendations to XR applications.

The core idea is straightforward: rather than forcing the XR application to infer the available rate only after congestion becomes visible at the endpoint, the network estimates a sustainable rate and exposes that value to the application as guidance. The application can then select its effective rate as the minimum of the endpoint-derived rate and the network-recommended rate:

\[rXR(t)=min⁡(rNetX(t),  rOTT(t))r_{XR}(t) = \min\bigl(r_{NetX}(t),\; \]

\[r_{OTT}(t)\bigr)rXR​(t)=min(rNetX​(t),rOTT​(t))\]

This means any existing OTT adaptation strategy can be combined with NetXRate without replacement — the recommendation acts as a ceiling, not a mandate.

NetXRate uses a fairness-aware allocation mechanism inspired by proportional fairness and water-filling. The algorithm estimates residual cell capacity after accounting for eMBB load, HARQ retransmissions, and channel conditions, and then distributes the available capacity among XR users according to their radio efficiency and requested rates. A conservative margin (90% of estimated capacity) is retained to absorb estimation errors and short-term fluctuations.

The paper evaluates NetXRate through packet-level simulations using ns-3 with the 5G-LENA module. Results show:

Importantly, NetXRate also improves performance for coexisting eMBB users. By making XR traffic more conservative and stable, the approach reduces unnecessary contention and frees capacity for other services.

5. Conceptual architecture

The NetXRate architecture involves several cooperating components that map naturally onto 5GS and O-RAN concepts.

The XR application client runs on the user device and maintains endpoint measurements such as buffer level and rendering deadlines. The XR application server (acting as an AF) manages session-level control and makes the final media rate decision.

The NEF provides the application-facing exposure point. In the NetXRate design, the NEF Analytics Exposure API is extended to support XR-specific rate recommendations. The NEF also exposes the AsSessionWithQoS API used by CAMARA Quality on Demand (QoD) for priority management.

The NWDAF hosts a dedicated NetXRate Analytics Module that generates per-session rate recommendations. The NWDAF determines which cell serves the target XR user (via AMF location services), retrieves policy information from the PCF (including priority, 5QI, and ARP), and communicates with the RAN-side intelligence.

The O-RAN near-Real-Time RIC hosts the NetXRate xApp, which performs the actual capacity estimation and rate computation. The xApp subscribes to Distributed Unit (DU) counters via O-RAN E2 service models and runs the fairness-aware allocation algorithm. O-RAN RIC and xApps provide a complementary RAN intelligence framework and should be distinguished from 3GPP-defined 5GS functions.

The application rate controller on the XR server combines the network recommendation with its own OTT adaptation logic. The application retains full control over the final rate decision.

6. Procedure-level intuition

The operational flow can be understood in eight intuitive steps.

1. Session initiation: The XR application starts a session and the XR Rate Control Function declares required uplink and downlink data rates for the XR flow to the NEF, identified by IP address.
2. Exposure request: The NEF forwards the request to a dedicated module within the NWDAF.
3. UE localization: The NWDAF uses AMF location reporting services to identify the cell serving the target UE.
4. Policy retrieval: The NWDAF queries the PCF to retrieve policy information including priority treatment for the XR flow.
5. RAN subscription: The selected xApp subscribes to DU counters (capacity, load, channel quality, retransmissions) for the identified cell.
6. Rate computation: The xApp estimates residual capacity, runs the fairness-aware allocation, and computes per-user rate recommendations.
7. Recommendation delivery: Recommendations flow from the xApp to NWDAF, then to NEF, and finally to the XR Rate Control Function.
8. Periodic refresh: Recommendations are updated periodically (for example, every 200 ms) as radio and traffic conditions evolve.

This flow should be read as a research design rather than a mandatory standardized procedure. It illustrates how existing architectural concepts — exposure, analytics, policy, location, and RAN intelligence — can be composed to support application-network collaboration.

7. Why rate recommendation is different from simple monitoring

Three levels of network-to-application information can be distinguished.

Measurements tell the application what has happened or what is currently observed: throughput, packet loss, delay, radio conditions, or QoS monitoring data. Measurements are useful, but the application must still interpret the measurements and infer the best action.

Predictions tell the application what may happen next: expected congestion, expected throughput, or likely service performance. Predictions are more useful than raw observations when conditions are changing quickly.

Recommendations translate measurements, predictions, policy, and fairness objectives into actionable guidance. A rate recommendation says: "given current radio conditions, cell load, competing traffic, your priority level, and fairness across other users, this is a sustainable operating point for your XR flow."

This distinction matters because:

• XR quality stability: A recommendation can help the application avoid probing into unavailable capacity, preventing the sawtooth oscillations characteristic of purely reactive adaptation.
• Multi-user fairness: A recommendation can encode fairness-aware allocation across all XR users in a cell, something no single endpoint can compute independently.
• Congestion avoidance: Recommendations keep the aggregate XR offered load within feasible capacity, preventing systematic overshoot.
• Developer-friendly APIs: A single recommended-rate value is easier for an application developer to consume than a collection of low-level radio measurements.

8. Relationship to CAMARA, O-RAN, and network APIs

The idea of network-assisted rate recommendation connects to several broader industry trends.

CAMARA-style network APIs reflect a movement toward developer-facing exposure of network capabilities. The CAMARA Quality on Demand (QoD) API allows an application to request differentiated treatment for selected IP flows. The CAMARA Connectivity Insights API enables subscription to periodic notifications about whether a requested QoS profile is being honoured.

A rate recommendation API would be complementary to these mechanisms. QoD influences how the network treats a flow; a rate recommendation guides how much traffic the application should generate. Connectivity Insights informs the application about current conditions; a recommendation translates that context into an actionable media-control input.

O-RAN RIC and xApps provide a platform for RAN-aware intelligence. In the NetXRate design, the xApp uses O-RAN E2 service models to access DU-level counters and compute capacity estimates. This illustrates how O-RAN intelligence can complement 5GS exposure and analytics.

The larger trend is toward semantic network exposure: instead of exposing only raw network state, future APIs may expose higher-level, more actionable information — recommended rate, confidence level, validity time, or recommended application behaviour.

9. Design considerations and research questions

Several design considerations shape the evolution of network-assisted XR adaptation.

• Recommendation periodicity: The NetXRate paper uses 200 ms intervals, balancing responsiveness against signalling overhead and measurement reliability. The optimal periodicity may depend on traffic dynamics and XR frame rates.
• Validity time and confidence: Applications benefit from knowing how long a recommendation remains valid and how confident the network is in the estimate.
• Measurement freshness: Radio-aware recommendations depend on timely observations of load, channel quality, retransmissions, and competing traffic.
• Closed-loop stability: The interaction between the application adaptation loop and the network recommendation loop should avoid oscillatory behaviour.
• Fairness: Multi-user XR and XR/eMBB coexistence require allocation policies that are efficient and fair.
• Privacy and authorization: Network exposure should remain controlled, authorized, and policy-governed.
• Encrypted traffic: Increasing transport encryption makes coordination more dependent on explicit APIs and signalling rather than packet inspection.
• QoS and charging interaction: Rate guidance may interact with QoS profiles, policy control, and commercial service models.
• Scalability: NetXRate's per-cell, per-session design scales linearly with XR users per cell. The paper evaluates scenarios with up to 30 XR users with stable control performance.
• Coexistence with predictive ABR: Network recommendations can complement — rather than replace — predictive or learning-based adaptive bitrate algorithms.

10. Future direction

Several possible future directions emerge from this area.

Application-facing rate recommendation APIs could provide clear semantics: recommended bitrate, direction (uplink or downlink), flow scope, validity time, confidence, and fallback behaviour. Such an API would help application developers consume network intelligence without needing to interpret low-level radio measurements.

NWDAF-assisted application adaptation represents an emerging opportunity where analytics are used not only for internal network optimization but also to support application behaviour through controlled exposure. This direction fits naturally with broader evolution of network analytics and event exposure.

RAN-assisted XR bitrate guidance is a complementary direction already being explored within 5GS evolution, including mechanisms for RAN-controlled uplink bitrate recommendation. Research proposals such as NetXRate explore how these capabilities can be extended and combined with core-network analytics and application-facing exposure.

AI/ML-based predictive adaptation is a natural extension. NetXRate currently uses measurement-based estimation; future systems could incorporate machine-learning models for capacity prediction, mobility-aware pre-adaptation, and proactive quality management.

Semantic APIs may evolve from "expose network state" toward "expose recommended application action." For XR and immersive media, this could include recommended bitrate, recommended burst timing, congestion risk indicators, or service-specific adaptation hints.

11. Key takeaways

1. XR services need rate adaptation mechanisms that respond to radio dynamics faster than endpoint-only feedback can often provide.
2. Network-assisted adaptation allows applications to combine endpoint measurements with network-side information, analytics, or recommendations.
3. A rate recommendation is not the same as network control of the application; the application retains the final media adaptation decision.
4. The 5G System provides architectural enablers for application-network collaboration through exposure, analytics, policy, QoS, session management, mobility context, and RAN assistance.
5. NetXRate demonstrates one way to expose rate recommendations from network intelligence to XR application control loops, using O-RAN RIC xApp logic, NWDAF analytics, and fairness-aware allocation.
6. Fairness-aware rate recommendation can help multiple XR users share radio resources more predictably than independent endpoint-driven adaptation.
7. Network-assisted XR adaptation can also benefit coexisting eMBB traffic by reducing unnecessary congestion and contention.
8. CAMARA-style APIs, Quality on Demand, connectivity insights, and O-RAN RIC/xApps are complementary ecosystem elements for application-network collaboration.
9. Recommendation validity time, confidence, measurement freshness, authorization, and closed-loop stability are important design considerations for future systems.
10. Future immersive systems may evolve toward semantic network exposure — APIs that convey not only network state but recommended application actions.

13. Glossary