Leveraging 5G Physical Layer Monitoring for Adaptive Remote Rendering in XR Applications

Daniel Mej\'ias; Eduardo Jacob; Inhar Yeregui; Jasone Astorga; Mikel Zorrilla; Roberto Viola

REVIEW 4 major objections 4 minor 22 references

Leveraging 5G Physical Layer Monitoring for Adaptive Remote Rendering in XR Applications

T0 review · 4 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read A 5G base station's modulation-and-coding index, read once per second and converted into a theoretical data rate, can drive real-time quality switching that measurably reduces streaming freezes in remote-rendered extended reality.

desk verdict A modest but honest systems paper: MCS-driven XR adaptation works in a single-user testbed, but the capacity estimate is the full-carrier rate, not the stream's available bandwidth, and the QoS gain rests on one run. read the letter →

arxiv 2505.22123 v1 pith:2BMSV47I submitted 2025-05-28 cs.NI

Inhar Yeregui , Daniel Mejías , Mikel Zorrilla , Roberto Viola , Jasone Astorga , Eduardo Jacob This is my paper

classification cs.NI

keywords 5GNewRadiophysicallayermonitoringMCSindexadaptivestreamingremoterenderingextendedrealityqualityofserviceWebRTC

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that a metric already produced by the 5G physical layer—the modulation and coding scheme (MCS) index reported by the base station—can serve as a real-time proxy for available network capacity. The authors convert the index into a data-rate estimate using the 3GPP TS 38.306 maximum-rate formula and use that estimate to switch a remote XR renderer among three quality profiles defined by resolution, framerate, and bitrate. In a controlled mobility test on a standalone 5G testbed, the auto-adaptive controller reduced total freeze time by 17.4 percent relative to a fixed high-quality stream, and by up to 34.9 percent once freezes caused by the renderer's own profile switches are discounted. The general point is that an application can adapt its output to link conditions without guessing, because the base station already reports how the channel is being used.

What carries the argument

The load-bearing mechanism is the MCS index from the gNB, mapped through the 3GPP TS 38.306 maximum data rate formula (Equation 1) using the testbed's parameters: one carrier, one layer, 40 MHz bandwidth, 30 kHz subcarrier spacing, 106 physical resource blocks, a scaling factor of 1, and a downlink overhead of 0.14. Each second the Rate Controller fetches the MCS index, uses it to determine modulation order and coding rate, computes the theoretical rate, and—subject to a three-second guard against oscillation—selects one of three quality profiles. This chain turns a link-layer signal into an application-layer control signal.

What would settle it

Re-run the mobility experiment while a second UE downloads continuously; if the first UE's MCS stays high but the measured throughput to the XR client falls and freezes reappear, the premise that MCS alone captures available capacity is falsified. A weaker test is to compare the Equation (1) time series against the measured throughput point by point and check whether the estimate systematically overshoots by more than the width of the profile thresholds.

Watch

Extended reading notes

Core claim

The central claim is that the MCS index exposed by the gNB, combined with Equation (1) from 3GPP TS 38.306, gives a dependable, one-second-resolution estimate of the bandwidth available to a downlink XR stream, and that acting on this estimate improves quality of service. In the experiments the estimated data rate ranged from 5.025 Mbps at MCS 0 to 158.796 Mbps at MCS 27 as the client moved away from the antenna and back over 140 seconds. The controller switched between a 720p/60 fps/5 Mbps profile, a 1080p/60 fps/8 Mbps profile, and a 4K/60 fps/35 Mbps profile. Total freeze duration fell from 4760 ms without adaptation to 3930 ms with adaptation, average freeze duration fell from 1189 ms to 786 ms, and the client received the top quality profile 76.43 percent of the time. The larger freeze-time reduction, from 17.4 percent to 34.9 percent, is conditional on eliminating the renderer-induced freeze of roughly 277 ms that accompanies each profile switch.

Load-bearing premise

The load-bearing premise is that the MCS index sampled once per second, run through the theoretical maximum-rate formula, represents the throughput the XR stream can actually achieve; if retransmissions, control overhead, or scheduling with other users push real throughput below the estimate, the controller will pick too high a quality profile.

Editorial extensions

If this is right

If the MCS-based estimate is reliable, application-level adaptation needs no extra network probes: the base station already computes the signal that drives it.
Auto-adaptation under a 140-second mobility pattern reduced total freeze time by 17.4 percent compared with streaming at a fixed 4K profile.
The system delivered the highest quality profile 76.43 percent of the time, so adaptation sacrifices quality only in the intervals where capacity is genuinely low.
Freezes induced by switching are an artifact of the renderer implementation; removing them would bring the total freeze-time reduction to 34.9 percent.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Since the MCS index reflects link quality rather than per-flow allocation, the estimate is more trustworthy in a lightly loaded cell; in dense deployments a practical system would likely combine MCS with per-flow throughput or scheduler feedback.
The one-second sampling interval and the cost of each switch suggest a predictive extension: if the controller can anticipate an MCS drop from movement or signal-strength trends, it could downgrade before freezes begin.
The same control loop transfers to uplink streaming and to other real-time media such as game streaming or volumetric video, provided the renderer can reconfigure its encoder without stalling.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Fairly straightforward read. The genuinely new bit is that they wire the gNB's MCS index through the 3GPP TS 38.306 max-data-rate formula into an XR renderer's quality-profile selector, and then measure it on a real Amarisoft standalone 5G testbed. The formula itself is from the spec, and the threshold logic is textbook adaptive streaming. So the novelty is application and measurement, not method.

Credit where it's due: the validation in Figure 3 is an honest attempt, they use iperf3 as an external throughput reference, and they flag the renderer's switch-induced freeze limitation instead of hiding it. The idea of using physical-layer MCS as a low-latency capacity signal is plausible.

The soft spots are real but proportioned. First, the capacity estimate is not the available capacity. Equation 1 with N_PRB=106 calculates the full-carrier theoretical maximum at the current MCS. The MCS index only tells you spectral efficiency per scheduled PRB; it does not tell you how many PRBs the scheduler gives the UE. In a single-UE testbed the scheduler probably assigns all 106, so the estimate is close to the actual capacity — that is why Figure 3 looks fine. But the paper presents the method as generally applicable, and in any multi-user or scheduler-limited scenario the estimate will run high. Figure 3 is also a single 60-second run with no error metrics, just a visual 'closely follows.'

Second, the QoS comparison rests on a single mobility pattern. Table III reports one run per condition, and the headline 17.4% reduction in total freeze time is that one run. The 'up to 34.9%' figure depends on subtracting freeze time caused by profile switches, which they attribute to their renderer's implementation. That is plausible, but it is a post-hoc correction, not a measured improvement of the system as built.

Third, the profile thresholds (8/35 Mbps) are set directly from the profiles' own bitrates, so the controller is partly comparing the estimate to its own targets. Not circular in a damaging way, but it would be nice to see thresholds justified independently.

Who is this for? People building XR streaming over 5G who want a simple, standards-based capacity probe. It is not a breakthrough; it is a useful integration data point. A serious referee should take it because the mechanism is sound, the testbed is real, and the limitations can be fixed with more runs and error bars. My recommendation: send it to review, but require the authors to either add multi-user or PRB-allocation data, or narrow the claim to single-user scenarios.

Referee Report

4 major / 4 minor

Summary. The manuscript proposes to drive adaptive quality selection for a remotely rendered XR stream from 5G physical-layer measurements. A Rate Controller obtains the MCS index from the Amarisoft gNB every second, evaluates the 3GPP TS 38.306 maximum data-rate expression (Eq. 1) with the testbed parameters in Table II, and instructs a Unity-based remote renderer to switch among three profiles (Table I) when the estimate crosses 8 or 35 Mbps. The experimental section validates Eq. 1 against a single 60-s iperf3 measurement (Fig. 3) and compares one no-adaptation run with one adaptive run along the same 140-s mobility trace. The authors report that the adaptive system reduces total freeze time from 4760 ms to 3930 ms (17.4%), and argue that removing renderer-induced switch freezes would lower it to 3099 ms (34.9%).

Significance. The idea is timely and the system design is simple enough to be of practical interest: using the already-reported MCS index to estimate capacity avoids active probing and is compatible with an edge-based renderer. The paper uses a standard 3GPP formula, discloses the testbed parameters, and is candid about the renderer-induced freeze limitation, which is a strength. The main value is as a proof of concept in a dedicated single-UE cell. The general claim that physical-layer monitoring provides a reliable estimate of available capacity, and that the proposed adaptation reduces freeze time, is not yet supported by the evidence as presented: the validation of Eq. 1 is qualitative and single-trajectory, and the QoS comparison has no reported variance. With additional measurements and a more precise treatment of the estimator's scope, the contribution would be solid.

major comments (4)

[§V-A, Eq. (1), Fig. 3] The estimator is implemented with N_PRB = 106 and therefore computes the full-carrier maximum data rate at the reported MCS, not the capacity actually available to the XR flow. The MCS index describes the spectral efficiency per scheduled PRB; it does not indicate how many PRBs the scheduler grants to the UE. In any multi-user or scheduler-limited scenario, the available throughput for the XR stream can be a small fraction of the Eq. (1) value, and the Table I thresholds will then cause the system to select too high a profile. The validation shown in Fig. 3 is a single-user, single 60-second comparison with no quantitative error metric and no record of scheduled PRB counts, HARQ retransmissions, or concurrent load, so it cannot distinguish the full-bandwidth estimate from the actually available capacity. Please either restrict the claims to a dedicated single-UE cell or extend the validation with multi-user/scheduler-load measurements and report per-second PRB allocations and error statistics.
[§V-B, Table III] The headline QoS result rests on a single run per condition. The text states that the experiment was repeated to ensure statistical robustness, but Table III reports no iteration count, no per-run values, and no confidence intervals, and the mobility scenario is a single 140-second trajectory. With four freezes in the baseline and six in the adaptive run, the difference in total freeze duration (4760 ms vs 3930 ms) may well be within run-to-run variability. Please report the number of repetitions and a statistical comparison; without that, the 17.4% reduction is not established.
[§V-B, Table III] The 34.9% figure is a counterfactual projection, not an observed result. It is obtained by subtracting 3 × 277 ms (the measured average duration of switch-induced freezes) from the adaptive run's total freeze time. Those freezes are a direct consequence of the adaptation mechanism and have no counterpart in the no-adaptation run, so the comparison is not apples-to-apples. The measured improvement is the 17.4% value; the 34.9% value should be labeled explicitly as an upper-bound projection conditional on eliminating the renderer's switch-induced freezes, both in Section V-B and anywhere the result is summarized.
[§V-A, Eq. (1)] The paper does not specify how the MCS index is mapped to the terms in Eq. (1). The text says the MCS determines the modulation order Qm, the scaling factor f, and the maximum code rate Rmax, but in Eq. (1) f is the 3GPP scaling factor (1, 0.8, 0.75, or 0.4) and Rmax is the maximum code rate (948/1024); these are distinct quantities. If instead the authors substitute the MCS-specific code rate into Rmax, the formula is no longer the standard TS 38.306 maximum data-rate expression, and the computed values are sensitive to this choice. Please provide the exact MCS-to-(Qm, R) mapping used and the intermediate values that produce, for example, 158.796 Mbps at MCS 27 and 5.025 Mbps at MCS 0.

minor comments (4)

[§V-B] The iperf3 measurement protocol is not specified; state whether TCP or UDP was used and the relevant iPerf3 parameters, since TCP throughput reflects congestion control and may not represent the capacity available to a WebRTC/UDP XR stream.
[§V-B, Fig. 4] The upper threshold is drawn at 36 Mbps, while Table I uses '35 < datarate'. Reconcile the two values and clarify whether the difference is due to the RTP overhead mentioned in Section IV.
[§V-B] The quantification of '76.43% of the time' in the highest quality is not derived in the text; describe how this metric was computed.
[§IV] Minor wording issue: 'physic layer monitoring' should be 'physical layer monitoring'.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: capacity estimate comes from an external 3GPP formula benchmarked against iperf3, and the QoS gain is measured experimentally.

full rationale

The paper's derivation chain is linear and externally grounded. The MCS index is read from the gNB as an independent network observation; Eq. 1 is the 3GPP TS 38.306 maximum-data-rate formula with testbed parameters from Table II, not a quantity fitted to the XR outcome. The validation in Fig. 3 compares this estimate to iperf3 throughput, an external measurement tool, and the QoS comparison in Table III is a controlled experiment rather than a fit. The profile-switch thresholds in Table I are a design configuration derived from the profiles' own bitrates and RTP overhead; this is a control-law choice, not a prediction that reduces to its own input. The 34.9% freeze-time figure is arithmetic on measured freeze durations after subtracting a measured, repeatable renderer-induced switch penalty, not a self-referential reduction. No load-bearing self-citations appear: references are to 3GPP specifications, an IETF RFC, and software/tool documentation. The main limitation is external validity in multi-user or scheduler-limited scenarios, where the full-carrier Eq. 1 estimate may overstate capacity; that is a correctness and scope concern, not circularity.

Assumptions & free parameters 3 free parameters · 3 assumptions · 0 invented entities

The central claim rests on a standard 3GPP formula, not derived in-paper, on a domain assumption about MCS availability, and on hand-chosen quality thresholds. No new entities are introduced.

free parameters (3)

Quality profile thresholds = 8 Mbps and 35 Mbps
Chosen by hand from the profile bitrates plus RTP overhead; they determine when the renderer switches between 720p, 1080p, and 4K. Appear in Table I.
Streaming profile bitrates = 5, 8, and 35 Mbps
Taken from YouTube recommended encoding settings (reference [14]); not derived from network measurements. They define Q1, Q2, and Q3 in Table I.
Switch debounce interval = 3 seconds
Chosen to prevent rapid oscillation between profiles; it directly affects the measured freeze count and QoS results in Section IV.

assumptions (3)

standard math The 3GPP TS 38.306 maximum data-rate formula (Eq. 1) is valid for the testbed and yields a conservative upper bound on achievable throughput.
Invoked in Section III and V-A without derivation; the formula is standard, but its use assumes ideal channel conditions and full scheduler allocation.
domain assumption The MCS index retrieved from the gNB reflects the instantaneous channel quality of the UE and is available at one-second granularity.
Used throughout Section V to drive Eq. 1; commercial gNBs may not expose MCS to applications, and MCS varies with scheduler decisions.
domain assumption The XR renderer can change quality profile without disrupting the video stream.
Required for the adaptive benefit; the experiments show the opposite, each switch caused a 277 ms freeze, and the paper corrects for this post hoc in Section V-B.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Leveraging 5G Physical Layer Monitoring for Adaptive Remote Rendering in XR Applications." pith.science (2026). https://pith.science/paper/2BMSV47I

@misc{pith2026250522123,
  author       = {Pith},
  title        = {Pith review of: Leveraging 5G Physical Layer Monitoring for Adaptive Remote Rendering in XR Applications},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2BMSV47I}},
  note         = {Machine review of arXiv:2505.22123}
}

read the original abstract

As immersive eXtended Reality (XR) applications demand substantial network resources, understanding their interaction with 5G networks becomes crucial to improve them. This paper investigates the role of 5G physical-layer monitoring to manage and enhance the remote rendering of XR content dynamically. By observing network metrics directly from the physical layer, we propose a system to adapt streaming parameters such as bitrate, framerate, and resolution in real time based on available network capacity. Using theoretical formulas to estimate maximum data rate, our approach evaluates network resource availability, enabling the renderer to self-adjust media content representation. This is critical for providing consistent and smooth XR experiences to users, especially as network conditions fluctuate. Our findings suggest that physical-layer monitoring offers valuable insights to increase the Quality of Service (QoS) and has the potential to elevate user experience in remote-rendered XR applications.

Figures

Figures reproduced from arXiv: 2505.22123 by the authors.

**Figure 2.** Sequence diagram. the XR Remote Renderer, a limit of one change every three seconds has been applied. This mechanism helps avoid unnecessary switching in scenarios where the channel quality fluctuates slightly above and below the predefined thresholds. By imposing this restriction, the system ensures stability and prevents rapid oscillations between streaming quality profiles due to minor, short-term variations in n… view at source ↗

**Figure 3.** Comparison between estimated data rate and measured [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Figures from the paper (1 more)

**Figure 4.** Figure 4: Estimated data rate and current streaming profile. [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

22 extracted references · 20 canonical work pages

[1]

Toward truly immersive holographic-type communication: Challenges and solutions,

A. Clemm, M. T. Vega, H. K. Ravuri, T. Wauters, and F. De Turck, “Toward truly immersive holographic-type communication: Challenges and solutions,” IEEE Communications Magazine , vol. 58, no. 1, pp. 93–99, 2020

work page 2020
[2]

5g-advanced toward 6g: Past, present, and future,

W. Chen, X. Lin, J. Lee, A. Toskala, S. Sun, C. F. Chiasserini, and L. Liu, “5g-advanced toward 6g: Past, present, and future,”IEEE Journal on Selected Areas in Communications , vol. 41, no. 6, pp. 1592–1619, 2023

2023
[3]

Toward supporting xr services: Architecture and enablers,

T. Taleb, A. Boudi, L. Rosa, L. Cordeiro, T. Theodoropoulos, K. Tserpes, P. Dazzi, A. I. Protopsaltis, and R. Li, “Toward supporting xr services: Architecture and enablers,” IEEE Internet of Things Journal , vol. 10, no. 4, pp. 3567–3586, 2022

work page 2022
[4]

Standardization of extended reality (xr) over 5g and 5g-advanced 3gpp new radio,

M. Gapeyenko, V . Petrov, S. Paris, A. Marcano, and K. I. Pedersen, “Standardization of extended reality (xr) over 5g and 5g-advanced 3gpp new radio,” IEEE network , vol. 37, no. 4, pp. 22–28, 2023

work page 2023
[5]

Enabling extended reality over 5g with distributed computing,

H. Sampath, P. Tinnakornsrisuphap, and P. Hande, “Enabling extended reality over 5g with distributed computing,” IEEE Communications Magazine, vol. 62, no. 8, pp. 32–37, 2024

work page 2024
[6]

A survey on mobile augmented reality with 5g mobile edge computing: Architectures, applications, and technical aspects,

Y . Siriwardhana, P. Porambage, M. Liyanage, and M. Ylianttila, “A survey on mobile augmented reality with 5g mobile edge computing: Architectures, applications, and technical aspects,” IEEE Communications Surveys & Tutorials , vol. 23, no. 2, pp. 1160–1192, 2021

work page 2021
[7]

Wireless communication research challenges for extended reality (xr),

I. F. Akyildiz and H. Guo, “Wireless communication research challenges for extended reality (xr),” ITU Journal on Future and Evolving Technologies, vol. 3, no. 1, pp. 1–15, 2022

work page 2022
[8]

Ai-assisted improved service provisioning for low-latency xr over 5g nr,

M. Laha, D. Roy, S. Dutta, and G. Das, “Ai-assisted improved service provisioning for low-latency xr over 5g nr,” IEEE Networking Letters , 2023

work page 2023

Show all 22 references

[9]

Adaptive cloud-based extended reality: Modeling and optimization,

M. Liubogoshchev, K. Ragimova, A. Lyakhov, S. Tang, and E. Khorov, “Adaptive cloud-based extended reality: Modeling and optimization,” IEEE Access , vol. 9, pp. 35 287–35 299, 2021

2021
[10]

Enhancing 5g qos management for xr traffic through xr loopback mechanism,

B. Bojovi ´c, S. Lag ´en, K. Koutlia, X. Zhang, P. Wang, and L. Yu, “Enhancing 5g qos management for xr traffic through xr loopback mechanism,” IEEE Journal on Selected Areas in Communications , vol. 41, no. 6, pp. 1772–1786, 2023

2023
[11]

Xr-aware next generation networks,

R.-A. Stoica, H. Bagheri, J. L ¨ohr, and D. Karampatsis, “Xr-aware next generation networks,” IEEE Communications Magazine , vol. 62, no. 8, pp. 62–68, 2024

2024
[12]

Mec in 5g networks,

S. Kekki, W. Featherstone, Y . Fang, P. Kuure, A. Li, A. Ranjan, D. Purkayastha, F. Jiangping, D. Frydman, G. Verin et al. , “Mec in 5g networks,” ETSI white paper , vol. 28, no. 2018, pp. 1–28, 2018

2018
[13]

3GPP TS 38.306 V15.2.0 (2018-06): NR; User Equipment (UE) radio access capabilities,

“3GPP TS 38.306 V15.2.0 (2018-06): NR; User Equipment (UE) radio access capabilities,” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 38.306, June 2018, release

2018
[14]

Recommended upload encoding settings,

Google Support, “Recommended upload encoding settings,” 2024, accessed: 2024-12-03. [Online]. Available: https://support.google.com/ youtube/answer/1722171?hl=en#zippy=%2Cvideo-codec-h%2Cbitrate

2024
[15]

Available: https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId=3289

[Online]. Available: https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId=3289
[16]

Rtp: A transport protocol for real-time applications,

H. Schulzrinne, S. Casner, R. Frederick, and V . Jacobson, “Rtp: A transport protocol for real-time applications,” Internet Engineering Task Force (IETF), Tech. Rep. RFC 3550, 2003. [Online]. Available: https://www.rfc-editor.org/info/rfc3550

2003
[17]

Amarisoft: 4G/5G Software Solutions,

Amarisoft, “Amarisoft: 4G/5G Software Solutions,” 2025, accessed: 2025-02-10. [Online]. Available: https://www.amarisoft.com

2025
[18]

5G NR; User Equipment (UE) radio transmission and reception; Part 1: Range 1 Standalone (TS 138 101- 1 version 15.2.0 Release 15),

“5G NR; User Equipment (UE) radio transmission and reception; Part 1: Range 1 Standalone (TS 138 101- 1 version 15.2.0 Release 15),” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 138 101-1, June 2018, release 15. [Online]. Available: https://portal.3gpp.org/desktopm...

2018
[19]

5G NR; Physical layer procedures for data (3GPP TS 38.214 version 15.2.0 Release 15),

“5G NR; Physical layer procedures for data (3GPP TS 38.214 version 15.2.0 Release 15),” 3rd Generation Partnership Project (3GPP), Tech. Rep. TS 38.214, June 2018, release

2018
[20]

Available: https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId=3216

[Online]. Available: https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId=3216
[21]

Documentation available at https://unity.com

Unity Technologies, Unity Game Engine , 2025, version 2025. Documentation available at https://unity.com

2025
[22]

iPerf3: A TCP, UDP, and SCTP Network Bandwidth Measurement Tool,

ESnet (Energy Sciences Network), “iPerf3: A TCP, UDP, and SCTP Network Bandwidth Measurement Tool,” 2025, accessed: 2025-02-10. [Online]. Available: https://iperf.fr/

2025

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

Toward truly immersive holographic-type communication: Challenges and solutions,

A. Clemm, M. T. Vega, H. K. Ravuri, T. Wauters, and F. De Turck, “Toward truly immersive holographic-type communication: Challenges and solutions,” IEEE Communications Magazine , vol. 58, no. 1, pp. 93–99, 2020

work page 2020

[2] [2]

5g-advanced toward 6g: Past, present, and future,

W. Chen, X. Lin, J. Lee, A. Toskala, S. Sun, C. F. Chiasserini, and L. Liu, “5g-advanced toward 6g: Past, present, and future,”IEEE Journal on Selected Areas in Communications , vol. 41, no. 6, pp. 1592–1619, 2023

2023

[3] [3]

Toward supporting xr services: Architecture and enablers,

T. Taleb, A. Boudi, L. Rosa, L. Cordeiro, T. Theodoropoulos, K. Tserpes, P. Dazzi, A. I. Protopsaltis, and R. Li, “Toward supporting xr services: Architecture and enablers,” IEEE Internet of Things Journal , vol. 10, no. 4, pp. 3567–3586, 2022

work page 2022

[4] [4]

Standardization of extended reality (xr) over 5g and 5g-advanced 3gpp new radio,

M. Gapeyenko, V . Petrov, S. Paris, A. Marcano, and K. I. Pedersen, “Standardization of extended reality (xr) over 5g and 5g-advanced 3gpp new radio,” IEEE network , vol. 37, no. 4, pp. 22–28, 2023

work page 2023

[5] [5]

Enabling extended reality over 5g with distributed computing,

H. Sampath, P. Tinnakornsrisuphap, and P. Hande, “Enabling extended reality over 5g with distributed computing,” IEEE Communications Magazine, vol. 62, no. 8, pp. 32–37, 2024

work page 2024

[6] [6]

A survey on mobile augmented reality with 5g mobile edge computing: Architectures, applications, and technical aspects,

Y . Siriwardhana, P. Porambage, M. Liyanage, and M. Ylianttila, “A survey on mobile augmented reality with 5g mobile edge computing: Architectures, applications, and technical aspects,” IEEE Communications Surveys & Tutorials , vol. 23, no. 2, pp. 1160–1192, 2021

work page 2021

[7] [7]

Wireless communication research challenges for extended reality (xr),

I. F. Akyildiz and H. Guo, “Wireless communication research challenges for extended reality (xr),” ITU Journal on Future and Evolving Technologies, vol. 3, no. 1, pp. 1–15, 2022

work page 2022

[8] [8]

Ai-assisted improved service provisioning for low-latency xr over 5g nr,

M. Laha, D. Roy, S. Dutta, and G. Das, “Ai-assisted improved service provisioning for low-latency xr over 5g nr,” IEEE Networking Letters , 2023

work page 2023