Skip navigation

Network evolution to support extended reality applications

Networks must evolve to handle the traffic generated by extended reality applications. Beyond volume, this new traffic has some important differences compared with mobile broadband traffic. In particular, the need for low latency and high reliability combined with high data rates challenges the capabilities of current mobile networks.

Ericsson CTO Erik Ekudden’s view on how networks can support emerging XR use cases

One of the defining characteristics of future mobile networks will be their ability to support a wide range of extended reality (XR) applications. Large-scale rollout of time-critical communication (TCC) features, coverage and capacity enhancement features, and densified deployments will all play important roles in the journey toward full XR support.

In this article, the authors examine the traffic characteristics of XR applications and explain the qualitative effects they have on both coverage and capacity. They go on to outline both the different network functionalities needed to better support XR traffic and meet XR requirements, and the expected performance impact. In conclusion, they share the results of several simulations that demonstrate the performance of different types of XR applications in networks with varying characteristics.

Ericsson Technology Review logo

4 May, 2023

Authors: Fredrik Alriksson, Oskar Drugge, Anders Furuskär, Du Ho Kang, Jonas Kronander, Fredric Kronestedt, Jose Luis Pradas, Ying Sun 

Download article as pdf

3GPP – 3rd Generation Partnership Project
BSR – Buffer Status Report
DL – Downlink
DRX – Discontinuous Reception
FDD – Frequency Division Duplex
ISD – Inter-Site Distance
MBB – Mobile Broadband
Mbps – Megabits per Second
ms – Millisecond
QoS – Quality of Service
RAN – Radio-Access Network
TCC – Time-Critical Communication
UE – User Equipment
UL – Uplink
XR – Extended Reality

Networks must evolve to handle the traffic generated by extended reality applications. Beyond volume, this new traffic has some important differences compared with mobile broadband traffic. In particular, the need for low latency and high reliability combined with high data rates challenges the capabilities of current mobile networks.

Enhanced capabilities in terms of both functionality and deployment will be essential for mobile networks to provide a good user experience for extended reality (XR) applications while continuing to deliver high-quality mobile broadband (MBB) and voice services.

As part of the process of defining the new capabilities needed to meet the network requirements of emerging XR applications, Ericsson has defined a set of combinations of XR applications, compute offload levels and device capabilities that we refer to as “XR flavors.” [1] Together with projections on XR uptake, the XR flavors form the basis for requirements on network connectivity. The flavors are represented by the dots in Figure 1, which shows them in the context of both increasing XR requirements over time and the new network capabilities that will be necessary to meet those requirements.

Figure 1: XR flavors in the context of both network requirements and capabilities over time

Figure 1: XR flavors in the context of both network requirements and capabilities over time

The specific traffic characteristics of XR, together with their effect on coverage and capacity, are essential inputs to defining the different kinds of network functionality needed to support XR traffic, live up to XR requirements and meet the expected performance.

In addition to knowledge about the traffic generated per active XR user and the associated performance requirements, predictions about XR uptake among users and daily usage are also necessary to accurately assess network impacts. These two aspects are difficult to predict, but based on the existing research [2], we assume an uptake of up to 6 percent over the next couple of years. For our evaluations, we have chosen to use a near-term uptake of 2 percent and a mid-term uptake of 5 percent. With regard to the daily usage, we assume that during the hours of the highest traffic, the usage of the most demanding XR variants (which we use to dimension the network) approaches 10 percent [1]. Active XR users generate traffic according to the bitrates of the XR flavor.

XR traffic characteristics present new challenges

XR traffic is characterized by multiple service flows, arrival jitter and a wide variation in packet sizes [3]. When combined with stringent requirements on bitrates, delay and reliability, these characteristics have a big impact on a network’s ability to support XR services.

XR traffic constitutes several different service flows, including video, audio, pose and control. Different XR applications may use a different number of flows, each with its own traffic characteristics and requirements. For example, pose may have a 10ms latency requirement, while video could have 20ms or 30ms. For good efficiency, the network should adapt to the needs of the individual flows. Today, multiple flows are commonly multiplexed into a single UDP stream, a practice that will need to be revisited to enable better network efficiency.

Arrival jitter is an issue for network support of XR because XR video traffic is typically quasiperiodic, which means that packets arrive at the network with slightly irregular small offsets from the average interval of arrivals. This is caused by delay variations in application encoding and transport networks [4]. The arrival jitter complicates the delivery of the packets within the bounded latency, as it consumes parts of the delay budget and makes precise allocation of resources in advance more difficult. Arrival jitter also affects several other aspects such as the discontinuous reception (DRX) configuration used to reduce device battery consumption, measurements and scheduling decisions.

The wide variation in packet sizes for XR traffic further complicates the allocation of resources. Depending on the flavor, a substantial part of XR traffic both in the downlink (DL) and the uplink (UL) is video, which is commonly characterized by a mix of packet sizes. Typically, new scenes or larger changes to a scene result in large packets, followed by a series of smaller packets reflecting smaller changes to the scene. In order to handle the largest frames, the network needs to be dimensioned for the peak bitrate. As changes of the scene are not known to the network, frame sizes appear random to the network, which complicates resource allocation.

In short, the combination of the different types of flows, the large packet-size variance even within the same flows, and the arrival jitter, together with the latency and reliability requirement, presents a significant challenge for today’s mobile networks, which are designed for the much more relaxed delay budgets of MBB traffic.

Time-critical communication features for XR traffic

With each new generation, mobile networks have evolved and become more efficient in supporting MBB services. To maintain that efficiency while also ensuring that XR applications work well in 5G networks, it will be essential to separate the XR traffic from best-effort MBB traffic using the 5G Quality of Service (QoS) framework with optimized QoS flows [5].

The 5G QoS framework enables the use of the 5G time-critical communication (TCC) toolbox, which consists of both standardized and non-standardized functionality such as Low Latency, Low Loss, Scalable (L4S) throughput technology [6], UL configured grants, robust link adaptation and tailored scheduling schemes. These tools enable the optimized treatment of XR throughout the mobile network and specifically in the radio-access network (RAN) to mitigate the different sources of delay. Note that different tools may be applied to different flows.

Even with the help of these tools, however, we can expect lower capacity and worse coverage for some XR flows – and for low-latency, high-reliability services in general – compared with MBB. There are a few reasons for this.

Firstly, fading and interference variations cause the channel quality to vary over time in a way that is difficult to predict. Errors occur when we overestimate the channel quality and select an overly aggressive modulation and coding scheme. In the case of MBB, it is possible to use the more generous delay budget to achieve high efficiency nonetheless. We can wait for instances of good channel quality, use aggressive modulation and coding, and repair errors with multiple retransmissions, if needed.

The situation for XR is different. To support reliable low latency for XR, we need to use more robust link adaptation with an increased safety margin to avoid an overly high frequency of errors on the radio interface and reduce the number of retransmissions. Retransmissions are still essential to efficiently support high reliability, but each retransmission has a delay cost in terms of the round-trip time for sending and responding to a negative acknowledgement. This means that the number of retransmissions required to successfully deliver data needs to be reduced compared with MBB to meet the stricter delay bound. The tendency to underestimate the channel quality directly impacts coverage and capacity. Because of this impact, the level of robustness of the link adaptation should be set according to the requirements and not be overly conservative.

Lower capacity and worse coverage for XR are also caused by protocol aspects. It is not possible to use the whole delay budget to send data, since channel access and retransmissions also need to be accounted for within the delay budget. This means that the rate of data transmission over the air interface must be higher than the data transmission rate of the application. Due to the arrival jitter and unknown packet size, the data transmission needs to be preceded by a scheduling request and a buffer status report (BSR), in which the user equipment (UE) tells the network that it has something to transmit and how much data it wants to transmit. This takes time, which means that data transmission over the network cannot start the instant the data arrives from the application. The problem can be mitigated by pre-allocating resources by means of configured grants or smart dynamic prescheduling, which the device will use to transmit the BSR. Channel access latency can be reduced, as the UE can skip the scheduling request procedure, leaving more time for data transmissions.

BSR resource allocation accuracy and UE queueing delays are more critical to the capacity of XR service in comparison with MBB. Large and variable packet sizes may cause the UE to report high buffer status indexes that are inaccurate. In these situations the network overshoots the grant size, which often results in resource wastage. The lower the BSR accuracy, the larger the waste, and vice versa. An increased UE-internal queueing delay results when packets with no chance of meeting the latency requirements remain in the buffer for transmission, even if they are not useful for the application, worsening the delays for other packets that could still meet their latency requirements.

Improving standard support for XR

While much of the functionality described in the previous section can be implemented based on current 3rd Generation Partnership Project (3GPP) standards, some would benefit from enhanced standard support. To build an industry consensus, 3GPP has recognized a set of XR requirements and traffic characteristics [4] similar to ours and is using it as the basis for developing improvements. These improvements include XR awareness in RAN, and capacity and power saving enhancements that consider support for high data rates in combination with bounded latency requirements. The XR awareness in RAN is intended to make the RAN aware of both the XR traffic characteristics and the requirements of the XR application, as well as any changes to either of them in terms of the number and types of flows, minimum/maximum/average packet size for each of the flows, flow periodicity, jitter, and the association between IP packets and application packets, for example.

Capacity and power-saving enhancements are also being standardized in 3GPP Release 18. These are grounded in XR awareness in the RAN, which will likely continue to be the baseline for future RAN features specified in 3GPP. The capacity enhancements in 3GPP Release 18 address delay and resource wastage issues by including more precise buffer status reporting with delay information, supporting the dropping of application packets with no chance of meeting delay requirements and studies of dynamic configured grant adaptation.

The power-saving enhancements include adaptations to XR traffic characteristics of DRX, allowing a better matching of monitoring and sleeping periods to the XR traffic characteristics. We expect studying of further enhancements in future releases of the standard.

XR network simulations

To exemplify the ways in which networks will need to evolve to efficiently support XR traffic, we have run several simulations that demonstrate the performance of a range of XR flavors in different networks with varying characteristics in terms of site density and the type of environment.


Our methodology is to first expose a network, as it is, without special functionality or network densification, to XR traffic and measure the XR user experience. In the second step, we introduce TCC functionality to determine the extent to which it can improve the user experience. Then we repeat the procedure for all networks and all the XR flavors [1].


The subscriber density in our simulations is 10,000 subscribers per square kilometer (1,000 for suburban) and 80 percent of them are indoors. Subscribers generate MBB and XR traffic according to the characteristics of the XR flavors and the assumptions on uptake and daily usage. We assume that 70 percent of the traffic is carried by in-building systems such as the Radio Dot System or Wi-Fi. Macro base stations are deployed with different densities in the different networks.

Average inter-site distances (ISDs) range from 150m to 1,000m. 3GPP New Radio is used on low and mid band, with frequency allocations of 2x10MHz frequency division duplex (FDD) at 800MHz, 2x20MHz FDD at 1,800MHz and 2,600MHz, and 1x100MHz time division duplex at 3,500MHz. Massive MIMO (multiple-input, multiple-output) is used on 3,500MHz and regular sector antennas on the other bands. The TCC functionality used is related to service differentiation, admission control, delay-aware scheduling, robust link adaptation and configured grants for BSR. The same functionality is applied to all flows.


Figure 2 illustrates the results for the XR flavor “near-term, basic with remote rendering and partial spatial compute” [1] in a macro network typical for many urban low-rise areas. We present the results as user positions in a three-dimensional map covering one square kilometer, colored by an estimated user experience, where green is good, gray is bad and blue is in between. The user experience is measured as the packet delay that can be supported with 99 percent reliability. A green marker corresponds to a position where 99 percent of the packets are delivered within 20ms, which for this flavor is assumed to lead to an acceptable user experience.

Figure 2: User satisfaction measured as DL packet delay fulfilled with 99 percent reliability

Figure 2: User satisfaction measured as DL packet delay fulfilled with 99 percent reliability

In the case on the left of Figure 2, traffic load is low and no TCC functionality is used. While there are several green markers, the coverage is far from full. In the middle of Figure 2, the traffic load increases to a level that we expect to see in the near future. This causes the map to turn entirely gray, indicating excessive delays, which we attribute to XR traffic queuing behind MBB traffic.

The right side of Figure 2 shows what happens when TCC functionality is added. The map turns predominantly green, with some gray areas that correspond to users who are not served either due to poor coverage or XR overload in those areas. In this scenario, the next step in the network evolution would be the use of capacity and coverage enhancing features on existing sites, or dedicated deployment in those areas.

Figure 3 presents a summary of the results we achieved when we repeated the analysis for five different XR flavors on five different networks that we refer to as Asian high-rise, US mid-rise, European mid-rise, suburban and 3GPP urban macro. The numbers in brackets represent DL bitrate in megabits per second (Mbps), UL bitrate in Mbps and one-way delay in milliseconds (ms). Coverage is measured as the fraction of users fulfilling the quality requirements in both the DL and UL at the projected traffic load. Three different points in time are assumed, and for each point in time a basic XR flavor and a more advanced XR flavor are covered.

Figure 3: Coverage at target traffic load for five different XR flavors on five different networks

In all five networks, the most basic XR flavor achieves good coverage of between 92 and 99 percent. For other flavors, the coverage varies significantly between the networks. In the Asian high-rise scenario, the network with the highest site density, most of the flavors achieve relatively good coverage, including the more demanding ones. The US mid-rise network is not far behind. Coverage drops for the more sparsely deployed networks, especially for the flavors with higher UL bitrate requirements or lower delay requirements. In these cases, an upgrade of existing sites and a complementary deployment in areas of outage would improve coverage. The impact of densification is roughly indicated by comparing the performance between networks with different site density (represented by the ISD).


The ability to support extended reality (XR) technologies in mobile networks will depend on the availability of new network capabilities that can meet stringent XR requirements on latency, reliability and bitrates. Our research indicates that delay-aware scheduling and robust link adaptation are effective techniques to meet XR requirements in the near term. Newly standardized features will also assist in meeting the XR requirements.

Our network simulations indicate that many modern networks are already able to support basic XR flavors in terms of coverage and capacity, and that the most densely deployed networks are also likely to be able to support more advanced flavors. For less densely deployed networks, the ability to support advanced flavors will likely require the upgrading of existing sites with enhanced coverage and capacity features, along with targeted densification in the case of the most sparsely deployed networks.

As network densification is complex and time-consuming, XR application developers who want full coverage should be encouraged to develop applications that are designed to adapt to varying network conditions.


Receive the latest industry insights straight to your inbox

Subscribe to Ericsson Technology Review

Subscribe here

Further reading

Massive MIMO spectrum efficiency everywhere

The 5G future is here with more deployments, ever-increasing data traffic and subscriber growth. The new performance demands on networks require new levels of spectral efficiency, and flexibility. Massive MIMO technology offers communication service providers the larger bandwidth of the mid-band to deliver powerful 5G experiences nationwide.

Ericsson Uplink Booster

5G is no longer just about being first to market; instead, high performance and good coverage dominates mobile operator requirements. By exceeding service providers' needs, Ericsson’s Uplink Booster efficiently extends 5G mid-band coverage by a considerable margin.

Building networks for the digital future

By 2030, limitless connectivity will be anywhere—and the global mobile network will be the critical infrastructure of the digital society. Are you ready?


Fredrik Alriksson

Fredrik Alriksson

is an expert in system architecture for the Internet of Things (IoT) and new services at Business Unit Networks, where he leads strategic technology and concept development related to the IoT and industry verticals. He joined Ericsson in 1999 and has worked in R&D with architecture evolution, covering a broad set of technology areas including RAN, Core and IP Multimedia Subsystem. Alriksson holds an M.Sc. in electrical engineering from KTH Royal Institute of Technology in Stockholm, Sweden.

Oskar Drugge

Oskar Drugge

is a system designer at Business Unit Networks. Since joining Ericsson in 2004, he has worked with a wide range of wireless technology development from device-side radio-access algorithms to network architecture. His current focus is on concept development within the IoT and industry verticals. Drugge holds an M.Sc. in electrical engineering from Luleå University of Technology, Sweden.

Anders Furuskär

Anders Furuskär

joined Ericsson Research in 1997 and is currently a senior expert focusing on radio resource management and performance evaluation of wireless networks. He holds an M.Sc. in electrical engineering and a Ph.D. in radio communications systems, both from KTH Royal Institute of Technology.

Du Ho Kang

Du Ho Kang

is a senior specialist at Ericsson Research who joined the company in 2014. His expertise is in 5G-and-beyond concept developments and performance evaluation for diverse international standardization and spectrum regulation bodies. His current interest is developing future RAN concepts for emerging services. Kang holds a Ph.D. in wireless infrastructure and deployment from KTH Royal Institute of Technology.

Jonas Kronander

Jonas Kronander

has been with Ericsson Research since 2007. He is currently a research leader and manager for a section focusing on radio networks for machine-type communication. His current research interests include extended reality and its impact on radio networks. Kronander holds an M.Sc. in engineering physics and a Ph.D. in theoretical physics from Uppsala University, Sweden.

Fredric Kronestedt

Fredric Kronestedt

joined Ericsson in 1993 to work on RAN research. Since then, he has taken on many roles, including system design and system management. He currently serves as an expert in radio network deployment strategies at Business Unit Networks, where he focuses on radio network deployment and evolution aspects for 4G and 5G. Kronestedt holds an M.Sc. in electrical engineering from KTH Royal Institute of Technology.

Jose Luis Pradas

Jose Luis Pradas

is a master researcher at Ericsson Research whose current focus is on RAN enhancements to support XR services in 5G networks. He joined Ericsson in 2007 and has worked in research, performing concept development in architecture and RAN protocols, as well as driving 3GPP standardization. Pradas
hold an M.Sc. in tele-communication from the Universitat Politècnica de València, Spain, and an M.Sc. in communications from the Helsinki University of Technology, Finland.

Ying Sun

Ying Sun

is a senior specialist in scheduling. Since joining Ericsson in 2001, she has served as a system engineer, a research engineer and a local product manager. Her current focus is on concept and product development within time-critical communication. Ying holds an M.Sc. in electrical engineering from the Delft University of Technology, the Netherlands.


We would like to thank Håkan Olofsson, Göran Eneroth, Jialu Lun, Panagiota Lioliou, Antzela Kosta, Allan Tart, Birgitta Olin, Yashar Nezami, Michael Björn, Sara Thorson and many other colleagues for their contributions to this work.