Network evolution to support extended reality applications

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.

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.

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.

Methodology

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].

Assumptions

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.

Results

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.

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.

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).

Conclusion

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.

1. Ericsson Technology Review, Future network requirements for extended reality applications, Alriksson, F et al.
2. Ericsson, 5G: The next wave
3. Ericsson blog, Network performance and the metaverse: Can 5G deliver what’s needed?, November 30, 2022, Kang, D H and Pradas, J L
4. 3GPP Technical Report 38.838, Study on XR (Extended Reality) Evaluations for NR, December 2021 (zip)
5. Ericsson Technology Review, XR and 5G: Extended reality at scale with time-critical communication, August 24, 2021, Alriksson, F et al
6. Ericsson-Deutsche Telekom white paper, Enabling time-critical applications over 5G with rate adaptation, May 2021, Willars, P et al.