RFC 9699
Use Case for an Extended Reality Application on Edge Computing Infrastructure
✨ RFC 9699 · Part 1 of 5 ✨
Okay bestie, this is RFC 9699 🎀, and its title is "Use Case for an Extended Reality Application on Edge Computing Infrastructure" 🦋. The authors are R. Krishna and A. Rahman, both from Ericsson 💜. It's Informational, which means it's published for info and is not a Standards Track spec 💅. The ISSN is 2070-1721, and it's dated December 2024 🌸. The header doesn't list any Obsoletes or Updates, so it isn't replacing or changing anything else 🙈.
Abstract ✨
This doc is all about using edge computing resources to make an Extended Reality (XR) app actually work 🔥. The app can run on devices with totally different form factors (different sizes and shapes, you know the vibe 💖). The problems it's trying to fix are the need for low-latency interactive communication, limited battery power, and heat dissipation from those devices 😭. It also talks about how XR apps behave, which can be used to manage traffic 🦋, and what service requirements XR apps need so they can run on the network 🧚. The intended audience is network operators who want to offer edge computing resources to make these apps work, so if that's you, this one's for you 💅.
Status of This Memo 📜
This document is not an Internet Standards Track specification. It's published for informational purposes 🌸.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community ✨. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 🫶. Not every IESG-approved doc is a candidate for any level of Internet Standard, though, so see Section 2 of RFC 7841 if you want the deets 🤓.
For info on the current status of this doc, any errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc9699 💜.
Copyright Notice 🎀
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved 💖.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 🙈. Code Components pulled out of this doc must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License ⚖️.
Table of Contents 🗺️
1. Introduction
2. Use Case
2.1. Processing of Scenes
2.2. Generation of Images
3. Technical Challenges and Solutions
4. XR Network Traffic
4.1. Traffic Workload
4.2. Traffic Performance Metrics
5. Conclusion
6. IANA Considerations
7. Security Considerations
8. Informative References
Acknowledgements
Authors' Addresses1. Introduction 🌷
Extended Reality (XR) is the umbrella term that covers Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR) [XR] 🌈. AR mixes the real and the virtual, it's interactive, and it lines up with the user's physical world [AUGMENTED_2] ✨. VR, on the other hand, drops the user inside a virtual environment that a computer generates [AUGMENTED] 🎮. MR blends real and virtual along a continuum, with a totally real environment at one end and a totally virtual one at the other. Every combo of real and virtual along that line counts as MR [AUGMENTED] 💜.
XR apps have a lot of demands on the network and on the mobile devices running them 😭. Some XR apps (like AR ones) need real-time processing of video streams to recognize specific objects 👀. That processing is then used to overlay info on the video the user sees 🦋. Other XR apps (AR and VR both) also need to generate new video frames to play for the user 🎬. Real-time video processing and overlay generation are both computationally intense, and they make heat [DEV_HEAT_1] [DEV_HEAT_2] and drain battery [BATT_DRAIN] on the mobile device running the app 🔥. So if you want XR-style apps on mobile devices, those heavy tasks need to get offloaded to edge computing resources 💅.
Edge computing is an up-and-coming paradigm. For this doc's purposes, computing resources and storage are made available close to mobile devices and sensors, at the edge of the Internet [EDGE_1] [EDGE_2] 🧚. A computing resource or storage counts as close to a mobile device or sensor when there's a short, high-capacity network path to it, so the latency and bandwidth needs of the apps on those devices or sensors can be met 🌸. These edge devices use cloud tech that lets them support offloaded XR apps. Specifically, cloud implementation techniques [EDGE_3] like these can be deployed 💖:
- Disaggregation: Using Software-Defined Networking (SDN) to break vertically integrated systems into independent components. These components can have open interfaces that are standard, well documented, and non-proprietary 🧩.
- Virtualization: Being able to run multiple independent copies of those components, like SDN Controller applications and Virtual Network Functions, on one common hardware platform 🖥️.
- Commoditization: Being able to elastically scale those virtual components across commodity hardware as the workload dictates 📈.
These techniques let XR apps that need low latency and high bandwidth get delivered by nearby edge devices 🚀. That's because the disaggregated components can run on nearby edge devices instead of a remote cloud several hops away, which lets them deliver low-latency, high-bandwidth service to the offloaded apps [EDGE_2] 🦋.
This doc talks through the issues that come up when network operators offer edge computing resources to meet the needs of XR apps running on devices with different form factors 🎀. For this doc, a network operator is any organization or individual that manages or operates the computing resources or storage close to a mobile device or sensor 💼. Examples of form factors include: 1) head-mounted displays (HMDs), like optical see-through HMDs and video see-through HMDs; 2) hand-held displays; and 3) smartphones with video cameras and location-sensing capabilities using systems like a global navigation satellite system (GNSS) 📱. These devices have limited battery capacity and dissipate heat when running 🔥. And as the user moves around while running the XR app, the wireless latency and bandwidth available to the device fluctuates, and the communication link itself might fail 😵. Because of that, algorithms based on Adaptive Bitrate (ABR) techniques, which base their policy on heuristics or models of deployment, perform sub-optimally in these dynamic environments [ABR_1] 📉.
Network operators can also expect the parameters that describe XR apps' expected behavior to be heavy-tailed 🐉. Heaviness of tails is defined as the difference from the normal distribution in the proportion of values that fall a long way from the mean [HEAVY_TAIL_3] 📊. Workloads like that need appropriate resource management policies on the edge 🛠️. The service requirements of XR apps are also more challenging than current video apps. Several Quality-of-Experience (QoE) factors, like motion sickness, are unique to XR apps and must be considered when operationalizing a network 🤢. This doc looks at these issues through the use case in the next section 👑.
2. Use Case 🎀
This use case involves an XR app running on a mobile device 📱. Picture a group of tourists touring the historical site of the Tower of London 🏰. As they walk around the site and inside the historic buildings, they can watch and listen to 3D historical scenes that the XR app generates. Their XR headsets then overlay those scenes onto their real-world view 🥽. The headset keeps updating their view as they move 🌈.
The XR app first processes the scene that the walking tourist is watching in real time, and it identifies objects that will be targeted for overlay of high-resolution videos 🔍. It then generates high-resolution 3D images of historical scenes that match the tourist's perspective, also in real time ⏱️. Those generated video images are overlaid on the tourist's view of the real world 💫.
Processing scenes and generating high-resolution images are covered in more detail below 💖.
2.1. Processing of Scenes ✨
okay so processing a scene is basically a three-step pipeline, bestie 🎀 the subtasks run one after another: tracking, acquisition of a model of the real world, and registration [AUGMENTED].
Tracking: the XR application running on the mobile device needs to track the six-dimensional pose 🦋 (translational in the three perpendicular axes and rotational about those three axes) of the user's head, eyes, and any objects in view [AUGMENTED]. it does this by tracking natural features, like points or edges of objects, which then get used in the next stage of the pipeline. main character tracking energy 💅
Acquisition of a model of the real world: the tracked natural features get used to develop a model of the real world. one way to do this is an annotated point cloud (a set of points in space that are each annotated with descriptors) that gets stored in a database. to make sure that database can scale up, techniques like combining client-side simultaneous tracking and mapping with server-side localization are used to construct the model [SLAM_1] [SLAM_2] [SLAM_3] [SLAM_4] 🌸 another model is built using a polygon mesh and texture mapping technique. the polygon mesh encodes a 3D object's shape, which is expressed as a collection of small flat surfaces that are polygons. in texture mapping, color patterns get mapped onto an object's surface. a third modeling technique uses a 2D lightfield that describes the intensity or color of the light rays arriving at a single point from arbitrary directions. this gets stored as a two-dimensional table. assuming distant light sources, the single point is approximately valid for small scenes. for larger scenes, many 3D positions are additionally stored, which makes the table 5D. a set of all these points (either a 2D or 5D lightfield) can then be used to construct a model of the real world [AUGMENTED] 🧚
Registration: the coordinate systems, brightness, and color of virtual and real objects need to be aligned with each other, and this process is called "registration" [REG] 🔥 once the natural features are tracked, virtual objects get geometrically aligned with those features through geometric registration. next up is resolving occlusion that can happen between virtual and real objects [OCCL_1] [OCCL_2]. the XR application also does photometric registration [PHOTO_REG] by aligning brightness and color between the virtual and real objects. on top of that, algorithms that calculate global illumination of both the virtual and real objects [GLB_ILLUM_1] [GLB_ILLUM_2] get executed. various algorithms are also required to deal with artifacts generated by lens distortion [LENS_DIST], blur [BLUR], noise [NOISE], etc. 💀
2.2. Generation of Images 🎨
the XR application must generate a high-quality video that has the properties described above, then overlay that video on the XR device's display. this step is called "situated visualization" 💖 a situated visualization is one where the virtual objects that the XR user needs to see are overlaid correctly on the real world. this means dealing with any registration errors that may arise, making sure there is no visual interference [VIS_INTERFERE], and finally maintaining temporal coherence by adapting to the movement of the user's eyes and head ✨
3. Technical Challenges and Solutions 🌈
As discussed in Section 2, the components of XR applications perform tasks that are computationally intensive, like real-time generation and processing of high-quality video content. this section talks about the challenges these applications can face as a result, and offers some solutions 🫶
as a result of doing computationally intensive tasks on XR devices such as XR glasses, excessive heat gets generated by the chipsets involved in the computation [DEV_HEAT_1] [DEV_HEAT_2] 🥵 the battery on these devices also drains quickly when running such applications [BATT_DRAIN] 😭
a solution to the heat and battery drainage problem is to offload the processing and video generation tasks to the remote cloud. however, running these tasks on the cloud is not feasible, because the end-to-end delays must be within the order of a few milliseconds 🙅♀️ these applications also need high bandwidth and low jitter to provide a high QoE to the user. to hit these hard timing constraints, computationally intensive tasks can be offloaded to edge devices 🧚
another requirement for our use case and similar applications, like 360-degree streaming (streaming of video that represents a view in every direction in 3D space), is that the display on the XR device should synchronize the visual input with the way the user is moving their head 👀 this synchronization is necessary to avoid motion sickness, which results from a time lag between when the user moves their head and when the appropriate video scene is rendered. this time lag is often called "motion-to-photon delay". studies have shown that this delay can be at most 20 ms and preferably between 7-15 ms in order to avoid motion sickness [PER_SENSE] [XR] [OCCL_3] 🍓 out of these 20 ms, display techniques, including the refresh rate of write displays and pixel switching, take 12-13 ms [OCCL_3] [CLOUD]. that leaves 7-8 ms for processing motion sensor inputs, graphic rendering, and round-trip time (RTT) between the XR device and the edge. the use of predictive techniques to mask latencies has been considered as a mitigating strategy to reduce motion sickness [PREDICT]. in addition, edge devices that are close to the user might be used to offload these computationally intensive tasks. towards this end, a 3GPP study suggests an Ultra-Reliable Low Latency of 0.1 to 1 ms for communication between an edge server and User Equipment (UE) [URLLC] 🦋
note that the edge device providing the computation and storage is itself limited in these resources compared to the cloud. for example, a sudden surge in demand from a large group of tourists can overwhelm the device. this results in degraded user experience, because the XR device experiences delays in receiving the video frames 😩 to deal with this problem, the client XR applications will need to use ABR algorithms that choose bitrate policies tailored in a fine-grained manner to the resource demands, and play back the videos with appropriate QoE metrics as the user moves around with the group of tourists 🗺️
however, the heavy-tailed nature of several operational parameters (e.g., buffer occupancy, throughput, client-server latency, and variable transmission times) makes prediction-based adaptation by ABR algorithms sub-optimal [ABR_2] 🙈 this is because with such distributions, the law of large numbers (how long it takes for the sample mean to stabilize) works too slowly [HEAVY_TAIL_2], and the mean of the sample does not equal the mean of the distribution [HEAVY_TAIL_2]. as a result, standard deviation and variance are unsuitable as metrics for such operational parameters [HEAVY_TAIL_1] 📉 other subtle issues with these distributions include the "expectation paradox" [HEAVY_TAIL_1] (the longer the wait for an event, the longer a further need to wait) and the mismatch between the size and count of events [HEAVY_TAIL_1]. these issues make designing an algorithm for adaptation error-prone and challenging 😤 on top of that, edge devices and communication links may fail, and logical communication relationships between various software components change frequently as the user moves around with their XR device [UBICOMP] 💜
4. XR Network Traffic 👑
4.1. Traffic Workload 🎀
okay so, like we talked about in Sections 1 and 3, the numbers that describe how XR apps behave are heavy-tailed 🌸 That covers arrival times between app invocations, how much data gets moved, and the gaps between packets inside one session. So any traffic model built on those numbers is heavy-tailed too 😭 Which makes it genuinely hard to predict performance when the network operator changes how resources are allocated. Both uplink and downlink traffic to a user device have stuff like XR data volume, burst time, and idle time that are all heavy-tailed. It's not one thing, it's the whole vibe 💅
Table 1 shows a bunch of streaming video apps and their throughput requirements [METRICS_1] ✨ Our use case is a 6 degrees of freedom (6DoF) video or point cloud, so according to the table it needs 200 to 1000 Mbps of bandwidth 🔥 The table also shows that XR apps, like ours, push a way bigger amount of data per unit time than regular video apps. That's bigger than regular video, periodt 🌈 So the issues from heavy-tailed parameters, like long-range dependent traffic [METRICS_2] and self-similar traffic [METRICS_3], show up at timescales of milliseconds and microseconds instead of hours or seconds 🫶 Burstiness at the tens-of-milliseconds timescale from the multi-fractal spectrum of traffic also shows up [METRICS_4] 👑 Long-range dependent traffic can have long bursts, and different traffic parameters from widely separated times can be correlated [HEAVY_TAIL_1]. Self-similar traffic has bursts at a whole range of timescales [HEAVY_TAIL_1]. Multi-fractal spectrum bursts summarize the statistical distribution of local scaling exponents found in a traffic trace [HEAVY_TAIL_1].
Operationally, this means the edge servers that a bunch of XR devices connect to wirelessly could face long bursts of traffic [METRICS_2] [METRICS_3] 😭 Multi-fractal spectrum burstiness at the millisecond scale could also cause jitter that contributes to motion sickness [METRICS_4]. That's because bursty traffic plus variable queueing delays leads to big delay jitter [METRICS_4] 💀 Edge server operators will need to run a "managed edge cloud service" [METRICS_5] to handle all of this. Functionalities that such a service could operationally provide include dynamic placement of XR servers, mobility support, and energy management [METRICS_6] 🧚 Support for edge servers using the techniques in [RFC8939], [RFC9023], and [RFC9450] could help guarantee XR app performance. For example, those techniques could be used on the link between the XR device and the edge, as well as inside the managed edge cloud service 💜 Another option for network operators is to deploy equipment that supports differentiated services [RFC2475] or per-connection Quality-of-Service (QoS) guarantees using RSVP [RFC2210] 🎀
So, provisioning edge servers (the number of servers, the topology, where they're placed, and how link capacity, CPUs, and Graphics Processing Units (GPUs) are assigned) should be done with all of the above in mind 🍓
+===============================================+============+
| Application | Throughput |
| | Required |
+===============================================+============+
| Real-world objects annotated with text and | 1 Mbps |
| images for workflow assistance (e.g., repair) | |
+-----------------------------------------------+------------+
| Video conferencing | 2 Mbps |
+-----------------------------------------------+------------+
| 3D model and data visualization | 2 to 20 |
| | Mbps |
+-----------------------------------------------+------------+
| Two-way 3D telepresence | 5 to 25 |
| | Mbps |
+-----------------------------------------------+------------+
| Current-Gen 360-degree video (4K) | 10 to 50 |
| | Mbps |
+-----------------------------------------------+------------+
| Next-Gen 360-degree video (8K, 90+ frames per | 50 to 200 |
| second, high dynamic range, stereoscopic) | Mbps |
+-----------------------------------------------+------------+
| 6DoF video or point cloud | 200 to |
| | 1000 Mbps |
+-----------------------------------------------+------------+
Table 1: Throughput Requirements for Streaming Video
Applications4.2. Traffic Performance Metrics 📊
The performance requirements for XR traffic have characteristics you need to consider when you operationalize a network ✨ We'll get into those characteristics in this section.
The bandwidth requirements of XR apps are way higher than those of video-based apps 🔥
The latency requirements of XR apps were studied recently [XR_TRAFFIC], and these characteristics came out of it:
- The uploading of data from an XR device to a remote server for processing dominates the end-to-end latency 😭
- A lack of visual features in the grid environment can cause increased latencies, because the XR device uploads extra visual data for processing to the remote server 💅
- XR apps tend to have large bursts that are separated by significant time gaps 🌸
Also, XR apps interact with each other on a timescale of an RTT propagation, and you have to consider that when you operationalize a network 🫶
Table 2 shows a taxonomy of apps with their required response times and bandwidths (this data is from Table V in [METRICS_6]) 🦋 Response time is the interval between the end of a request submission and the end of the matching response from a system 🧚 If the XR device offloads a task to an edge server, the server's response time is the RTT from when a data packet is sent from the XR device until a response comes back 💖 The required response time is an upper bound on the sum of the time for computational tasks (like processing scenes and generating images) and the RTT 👑 That response time depends only on the QoS an application requires, so it's independent of the underlying network technology and of how long the computational tasks take 🌈
Our use case needs a response time of 20 ms at most, and preferably between 7-15 ms, as we discussed earlier 🎀 That's similar to the first two entries in Table 2 ✨ The required bandwidth for our use case is 200 to 1000 Mbps (see Section 4.1) 🔥 Since our use case has multiple users running the XR app on their devices and connecting to the edge server closest to them, these latency and bandwidth connections grow linearly with the number of users 😭 Operators should match network provisioning to the maximum number of tourists that a link to an edge server can support 🍓
+===================+==============+==========+=====================+
| Application | Required | Expected | Possible |
| | Response | Data | Implementations/ |
| | Time | Capacity | Examples |
+===================+==============+==========+=====================+
| Mobile XR-based | Less than 10 | Greater | Assisting |
| remote assistance | milliseconds | than 7.5 | maintenance |
| with uncompressed | | Gbps | technicians, |
| 4K (1920x1080 | | | Industry 4.0 |
| pixels) 120 fps | | | remote |
| HDR 10-bit real- | | | maintenance, |
| time video stream | | | remote assistance |
| | | | in robotics |
| | | | industry |
+-------------------+--------------+----------+---------------------+
| Indoor and | Less than 20 | 50 to | Guidance in theme |
| localized outdoor | milliseconds | 200 Mbps | parks, shopping |
| navigation | | | malls, |
| | | | archaeological |
| | | | sites, and |
| | | | museums |
+-------------------+--------------+----------+---------------------+
| Cloud-based | Less than 50 | 50 to | Google Live View, |
| mobile XR | milliseconds | 100 Mbps | XR-enhanced |
| applications | | | Google Translate |
+-------------------+--------------+----------+---------------------+
Table 2: Traffic Performance Metrics of Selected XR Applications5. Conclusion 🌟
To operationalize a use case like the one in this document, a network operator could dimension their network to give a short, high-capacity network path from the edge computing resources or storage to the mobile devices running the XR app 💖 This is required to ensure a response time of 20 ms at most, and preferably between 7-15 ms ✨ Such apps also need a bandwidth of 200 to 1000 Mbps 🔥 To deal with the characteristics of XR traffic discussed here, network operators could deploy a managed edge cloud service that operationally provides dynamic placement of XR servers, mobility support, and energy management 🧚 The use case is technically feasible, but economic viability is an important factor that has to be considered 💅
6. IANA Considerations 🎀
This document has no IANA actions. Nothing to register here, bestie 🫶
7. Security Considerations 💀
The security issues for the presented use case are similar to those described in [DIST], [NIST1], [CWE], and [NIST2] 😭 This document does not introduce any new security issues ✨ Still, the usual security habits apply, so don't skip them 🔒
8. Informative References 📚
[ABR_1] Mao, H., Netravali, R., and M. Alizadeh, "Neural Adaptive
Video Streaming with Pensieve", SIGCOMM '17: Proceedings
of the Conference of the ACM Special Interest Group on
Data Communication, pp. 197-210,
DOI 10.1145/3098822.3098843, 2017,
<https://dl.acm.org/doi/10.1145/3098822.3098843>.
[ABR_2] Yan, F., Ayers, H., Zhu, C., Fouladi, S., Hong, J., Zhang,
K., Levis, P., and K. Winstein, "Learning in situ: a
randomized experiment in video streaming", 17th USENIX
Symposium on Networked Systems Design and Implementation
(NSDI '20), pp. 495-511, February 2020,
<https://www.usenix.org/conference/nsdi20/presentation/
yan>.[AUGMENTED] Schmalstieg, D. and T. Höllerer, "Augmented Reality: Principles and Practice", Addison-Wesley Professional, 2016, <https://www.oreilly.com/library/view/augmented-reality-principles/9780133153217/>.
[AUGMENTED_2] Azuma, R.T., "A Survey of Augmented Reality", Presence: Teleoperators and Virtual Environments, vol. 6, no. 4, pp. 355-385, DOI 10.1162/pres.1997.6.4.355, August 1997, <https://direct.mit.edu/pvar/article-abstract/6/4/355/18336/A-Survey-of-Augmented-Reality?redirectedFrom=fulltext>.
[BATT_DRAIN] Seneviratne, S., Hu, Y., Nguyen, T., Lan, G., Khalifa, S., Thilakarathna, K., Hassan, M., and A. Seneviratne, "A Survey of Wearable Devices and Challenges", IEEE Communication Surveys and Tutorials, vol. 19 no. 4, pp. 2573-2620, DOI 10.1109/COMST.2017.2731979, 2017, <https://ieeexplore.ieee.org/document/7993011>.
[BLUR] Kan, P. and H. Kaufmann, "Physically-Based Depth of Field in Augmented Reality", Eurographics 2012 - Short Papers, pp. 89-92, DOI 10.2312/conf/EG2012/short/089-092, 2012, <https://diglib.eg.org/items/6954bf7e-5852-44cf-8155-4ba269dc4cee>.
[CLOUD] Corneo, L., Eder, M., Mohan, N., Zavodovski, A., Bayhan, S., Wong, W., Gunningberg, P., Kangasharju, J., and J. Ott, "Surrounded by the Clouds: A Comprehensive Cloud Reachability Study", WWW '21: Proceedings of the Web Conference 2021, pp. 295-304, DOI 10.1145/3442381.3449854, 2021, <https://dl.acm.org/doi/10.1145/3442381.3449854>.
[CWE] SANS Institute, "CWE/SANS TOP 25 Most Dangerous Software Errors", <https://www.sans.org/top25-software-errors/>.
[DEV_HEAT_1] LiKamWa, R., Wang, Z., Carroll, A., Lin, F., and L. Zhong, "Draining our glass: an energy and heat characterization of Google Glass", APSys '14: 5th Asia-Pacific Workshop on Systems, pp. 1-7, DOI 10.1145/2637166.2637230, 2014, <https://dl.acm.org/doi/10.1145/2637166.2637230>.
[DEV_HEAT_2] Matsuhashi, K., Kanamoto, T., and A. Kurokawa, "Thermal Model and Countermeasures for Future Smart Glasses", Sensors, vol. 20, no. 5, p. 1446, DOI 10.3390/s20051446, 2020, <https://www.mdpi.com/1424-8220/20/5/1446>.
[DIST] Coulouris, G., Dollimore, J., Kindberg, T., and G. Blair, "Distributed Systems: Concepts and Design", Addison-Wesley, 2011, <https://dl.acm.org/doi/10.5555/2029110>.
[EDGE_1] Satyanarayanan, M., "The Emergence of Edge Computing", Computer, vol. 50, no. 1, pp. 30-39, DOI 10.1109/MC.2017.9, 2017, <https://ieeexplore.ieee.org/document/7807196>.
[EDGE_2] Satyanarayanan, M., Klas, G., Silva, M., and S. Mangiante, "The Seminal Role of Edge-Native Applications", 2019 IEEE International Conference on Edge Computing (EDGE), pp. 33-40, DOI 10.1109/EDGE.2019.00022, 2019, <https://ieeexplore.ieee.org/document/8812200>.
[EDGE_3] Peterson, L. and O. Sunay, "5G Mobile Networks: A Systems Approach", Synthesis Lectures on Network Systems, DOI 10.1007/978-3-031-79733-0, 2020, <https://link.springer.com/book/10.1007/978-3-031-79733-0>.
[GLB_ILLUM_1] Kan, P. and H. Kaufmann, "Differential Irradiance Caching for fast high-quality light transport between virtual and real worlds", 2013 IEEE International Symposium on Mixed and Augmented Reality (ISMAR), pp. 133-141, DOI 10.1109/ISMAR.2013.6671773, 2013, <https://ieeexplore.ieee.org/document/6671773>.
[GLB_ILLUM_2] Franke, T., "Delta Voxel Cone Tracing", 2014 IEEE International Symposium on Mixed and Augmented Reality (ISMAR), pp. 39-44, DOI 10.1109/ISMAR.2014.6948407, 2014, <https://ieeexplore.ieee.org/document/6948407>.
[HEAVY_TAIL_1] Crovella, M. and B. Krishnamurthy, "Internet Measurement: Infrastructure, Traffic and Applications", John Wiley and Sons, 2006, <https://www.wiley.com/en-us/Internet+Measurement%3A+Infrastructure%2C+Traffic+and+Applications-p-9780470014615>.
[HEAVY_TAIL_2] Taleb, N., "Statistical Consequences of Fat Tails: Real World Preasymptotics, Epistemology, and Applications", Revised Edition, STEM Academic Press, 2022, <https://arxiv.org/pdf/2001.10488>.
[HEAVY_TAIL_3] Ehrenberg, A., "A Primer in Data Reduction: An Introductory Statistics Textbook", John Wiley and Sons, 2007, <https://www.wiley.com/en-us/A+Primer+in+Data+Reduction%3A+An+Introductory+Statistics+Textbook-p-9780471101352>.
[LENS_DIST] Fuhrmann, A., Schmalstieg, D., and W. Purgathofer, "Practical Calibration Procedures for Augmented Reality", Virtual Environments 2000, pp. 3-12, DOI 10.1007/978-3-7091-6785-4_2, 2000, <https://link.springer.com/chapter/10.1007/978-3-7091-6785-4_2>.
[METRICS_1] ABI Research, "Augmented and Virtual Reality: The first Wave of Killer Apps: Qualcomm - ABI Research", April 2017, <https://gsacom.com/paper/augmented-virtual-reality-first-wave-5g-killer-apps-qualcomm-abi-research/>.
[METRICS_2] Paxon, V. and S. Floyd, "Wide area traffic: the failure of Poisson modeling", IEEE/ACM Transactions on Networking, vol. 3, no. 3, pp. 226-244, DOI 10.1109/90.392383, June 1995, <https://ieeexplore.ieee.org/document/392383>.
[METRICS_3] Willinger, W., Taqqu, M.S., Sherman, R., and D.V. Wilson, "Self-similarity through high variability: statistical analysis and Ethernet LAN traffic at source level", IEEE/ACM Transactions on Networking, vol. 5, no. 1, pp. 71-86, DOI 10.1109/90.554723, February 1997, <https://ieeexplore.ieee.org/abstract/document/554723>.
[METRICS_4] Gilbert, A.C., "Multiscale Analysis and Data Networks", Applied and Computational Harmonic Analysis, vol. 10, no. 3, pp. 185-202, DOI 10.1006/acha.2000.0342, May 2001, <https://www.sciencedirect.com/science/article/pii/S1063520300903427>.
[METRICS_5] Beyer, B., Ed., Jones, C., Ed., Petoff, J., Ed., and N.R. Murphy, Ed., "Site Reliability Engineering: How Google Runs Production Systems", O'Reilly Media, Inc., 2016, <https://research.google/pubs/site-reliability-engineering-how-google-runs-production-systems/>.
[METRICS_6] Siriwardhana, Y., Porambage, P., Liyanage, M., and M. Ylianttila, "A Survey on Mobile Augmented Reality With 5G Mobile Edge Computing: Architectures, Applications, and Technical Aspects", IEEE Communications Surveys and Tutorials, vol. 23, no. 2, pp. 1160-1192, DOI 10.1109/COMST.2021.3061981, 2021, <https://ieeexplore.ieee.org/document/9363323>.
[NIST1] NIST, "Cloud Computing Synopsis and Recommendations", NIST SP 800-146, DOI 10.6028/NIST.SP.800-146, May 2012, <https://csrc.nist.gov/pubs/sp/800/146/final>.
[NIST2] NIST, "Guide to General Server Security", NIST SP 800-123, DOI 10.6028/NIST.SP.800-123, July 2008, <https://csrc.nist.gov/pubs/sp/800/123/final>.
[NOISE] Fischer, J., Bartz, D., and W. Strasser, "Enhanced visual realism by incorporating camera image effects", 2006 IEEE/ACM International Symposium on Mixed and Augmented Reality, pp. 205-208, DOI 10.1109/ISMAR.2006.297815, 2006, <https://ieeexplore.ieee.org/document/4079277>.
[OCCL_1] Breen, D.E., Whitaker, R.T., Rose, E., and M. Tuceryan, "Interactive Occlusion and Automatic Object Placement for Augmented Reality", Computer Graphics Forum, vol. 15, no. 3, pp. 11-22, DOI 10.1111/1467-8659.1530011, August 1996, <https://onlinelibrary.wiley.com/doi/10.1111/1467-8659.1530011>.
[OCCL_2] Zheng, F., Schmalstieg, D., and G. Welch, "Pixel-wise closed-loop registration in video-based augmented reality", 2014 IEEE International Symposium on Mixed and Augmented Reality (ISMAR), pp. 135-143, DOI 10.1109/ISMAR.2014.6948419, 2014, <https://ieeexplore.ieee.org/document/6948419>.
[OCCL_3] Lang, B., "Oculus Shares 5 Key Ingredients for Presence in Virtual Reality", Road to VR, 24 September 2014, <https://www.roadtovr.com/oculus-shares-5-key-ingredients-for-presence-in-virtual-reality/>.
[PER_SENSE] Mania, K., Adelstein, B.D., Ellis, S.R., and M.I. Hill, "Perceptual sensitivity to head tracking latency in virtual environments with varying degrees of scene complexity.", APGV '04: Proceedings of the 1st Symposium on Applied perception in graphics and visualization, pp. 39-47, DOI 10.1145/1012551.1012559, 2004, <https://dl.acm.org/doi/10.1145/1012551.1012559>.
[PHOTO_REG] Liu, Y. and X. Granier, "Online Tracking of Outdoor Lighting Variations for Augmented Reality with Moving Cameras", IEEE Transactions on Visualization and Computer Graphics, vol. 18, no. 4, pp. 573-580, DOI 10.1109/TVCG.2012.53, 2012, <https://ieeexplore.ieee.org/document/6165138>.
[PREDICT] Buker, T.J., Vincenzi, D.A., and J.E. Deaton, "The effect of apparent latency on simulator sickness while using a see-through helmet-mounted display: reducing apparent latency with predictive compensation", Human Factors, vol. 54, no. 2, pp. 235-249, DOI 10.1177/0018720811428734, April 2012, <https://pubmed.ncbi.nlm.nih.gov/22624290/>.
[REG] Holloway, R.L., "Registration Error Analysis for Augmented Reality", Presence: Teleoperators and Virtual Environments, vol. 6, no. 4, pp. 413-432, DOI 10.1162/pres.1997.6.4.413, August 1997, <https://direct.mit.edu/pvar/article-abstract/6/4/413/18334/Registration-Error-Analysis-for-Augmented-Reality?redirectedFrom=fulltext>.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, DOI 10.17487/RFC2210, September 1997, <https://www.rfc-editor.org/info/rfc2210>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.
[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. Bryant, "Deterministic Networking (DetNet) Data Plane: IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, <https://www.rfc-editor.org/info/rfc8939>.
Okay bestie, the reference list keeps going, so here's the rest of it 📚✨
[RFC9023] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, "Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN)", RFC 9023, DOI 10.17487/RFC9023, June 2021, <https://www.rfc-editor.org/info/rfc9023>. 🌸
[RFC9450] Bernardos, CJ., Ed., Papadopoulos, G., Thubert, P., and F. Theoleyre, "Reliable and Available Wireless (RAW) Use Cases", RFC 9450, DOI 10.17487/RFC9450, August 2023, <https://www.rfc-editor.org/info/rfc9450>. 💖
[SLAM_1] Ventura, J., Arth, C., Reitmayr, G., and D. Schmalstieg, "A Minimal Solution to the Generalized Pose-and-Scale Problem", 2014 IEEE Conference on Computer Vision and Pattern Recognition, pp. 422-429, DOI 10.1109/CVPR.2014.61, 2014, <https://ieeexplore.ieee.org/document/6909455>. 🦋
[SLAM_2] Sweeny, C., Fragoso, V., Höllerer, T., and M. Turk, "gDLS: A Scalable Solution to the Generalized Pose and Scale Problem", Computer Vision - ECCV 2014, pp. 16-31, DOI 10.1007/978-3-319-10593-2_2, 2014, <https://link.springer.com/chapter/10.1007/978-3-319-10593-2_2>. 🧚
[SLAM_3] Gauglitz, S., Sweeney, C., Ventura, J., Turk, M., and T. Höllerer, "Model Estimation and Selection towards Unconstrained Real-Time Tracking and Mapping", IEEE Transactions on Visualization and Computer Graphics, vol. 20, no. 6, pp. 825-838, DOI 10.1109/TVCG.2013.243, 2014, <https://ieeexplore.ieee.org/document/6636302>. 🎀
[SLAM_4] Pirchheim, C., Schmalstieg, D., and G. Reitmayr, "Handling pure camera rotation in keyframe-based SLAM", 2013 IEEE International Symposium on Mixed and Augmented Reality (ISMAR), pp. 229-238, DOI 10.1109/ISMAR.2013.6671783, 2013, <https://ieeexplore.ieee.org/document/6671783>. 🍓
[UBICOMP] Bardram, J. and A. Friday, "Ubiquitous Computing Systems", Ubiquitous Computing Fundamentals, 1st Edition, Chapman and Hall/CRC Press, pp. 37-94, 2009, <https://www.taylorfrancis.com/chapters/edit/10.1201/9781420093612-6/ubiquitous-computing-systems-jakob-bardram-adrian-friday>. 📖
[URLLC] 3GPP, "Study on enhancement of Ultra-Reliable Low-Latency Communication (URLLC) support in the 5G Core network (5GC)", 3GPP TR 23.725, 2019, <https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3453>. ⭐
[VIS_INTERFERE] Kalkofen, D., Mendez, E., and D. Schmalstieg, "Interactive Focus and Context Visualization for Augmented Reality", 2007 6th IEEE and ACM International Symposium on Mixed and Augmented Reality, pp. 191-201, DOI 10.1109/ISMAR.2007.4538846, 2007, <https://ieeexplore.ieee.org/document/4538846>. 👑
[XR] 3GPP, "Extended Reality (XR) in 5G", 3GPP TR 26.928, 2020, <https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3534>. 🌈
[XR_TRAFFIC] Apicharttrisorn, K., Balasubramanian, B., Chen, J., Sivaraj, R., Tsai, Y., Jana, R., Krishnamurthy, S., Tran, T., and Y. Zhou, "Characterization of Multi-User Augmented Reality over Cellular Networks", 2020 17th Annual IEEE International Conference on Sensing, Communication, and Networking (SECON), pp. 1-9, DOI 10.1109/SECON48991.2020.9158434, 2020, <https://ieeexplore.ieee.org/document/9158434>. 💅
Acknowledgements 🫶
Huge thank-yous, literally the best group chat ever: Spencer Dawkins, Rohit Abhishek, Jake Holland, Kiran Makhijani, Ali Begen, Cullen Jennings, Stephan Wenger, Eric Vyncke, Wesley Eddy, Paul Kyzivat, Jim Guichard, Roman Danyliw, Warren Kumari, and Zaheduzzaman Sarker for giving helpful feedback, suggestions, and comments. You're all iconic 💜✨
Authors' Addresses 💌
Here's where the authors can be reached:
Renan Krishna
United Kingdom
Email: renan.krishna@gmail.comAkbar Rahman
Ericsson
349 Terry Fox Drive
Ottawa Ontario K2K 2V6
Canada
Email: Akbar.Rahman@ericsson.com📦 where this page comes from
- ietf: rfc9699 2024-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms