idnits 2.17.1 draft-ietf-mops-ar-use-case-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (6 March 2022) is 782 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-mops-streaming-opcons' is defined on line 407, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-mops-streaming-opcons-09 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MOPS R. Krishna 3 Internet-Draft InterDigital Europe Limited 4 Intended status: Informational A. Rahman 5 Expires: 7 September 2022 InterDigital Communications, LLC 6 6 March 2022 8 Media Operations Use Case for an Augmented Reality Application on Edge 9 Computing Infrastructure 10 draft-ietf-mops-ar-use-case-04 12 Abstract 14 This document explores the issues involved in the use of Edge 15 Computing resources to operationalize media use cases that involve 16 Extended Reality (XR) applications. In particular, we discuss those 17 applications that run on devices having different form factors and 18 need Edge computing resources to mitigate the effect of problems such 19 as a need to support interactive communication requiring low latency, 20 limited battery power, and heat dissipation from those devices. The 21 intended audience for this document are network operators who are 22 interested in providing edge computing resources to operationalize 23 the requirements of such applications. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 7 September 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions used in this document . . . . . . . . . . . . . . 3 60 3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Processing of Scenes . . . . . . . . . . . . . . . . . . 4 62 3.2. Generation of Images . . . . . . . . . . . . . . . . . . 5 63 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. AR Network Traffic and Interaction with TCP . . . . . . . . . 8 65 6. Informative References . . . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 68 1. Introduction 70 Extended Reality (XR) is a term that includes Augmented Realty (AR), 71 Virtual Reality (VR) and Mixed Realty (MR) [XR]. AR combines the 72 real and virtual, is interactive and is aligned to the physical world 73 of the user [AUGMENTED_2]. On the other hand, VR places the user 74 inside a virtual environment generated by a computer [AUGMENTED].MR 75 merges the real and virtual world along a continuum that connects 76 completely real environment at one end to a completely virtual 77 environment at the other end. In this continuum, all combinations of 78 the real and virtual are captured [AUGMENTED]. 80 XR applications will bring several requirements for the network and 81 the mobile devices running these applications. Some XR applications 82 such as AR require a real-time processing of video streams to 83 recognize specific objects. This is then used to overlay information 84 on the video being displayed to the user. In addition XR 85 applications such as AR and VR will also require generation of new 86 video frames to be played to the user. Both the real-time processing 87 of video streams and the generation of overlay information are 88 computationally intensive tasks that generate heat [DEV_HEAT_1], 89 [DEV_HEAT_2] and drain battery power [BATT_DRAIN] on the mobile 90 device running the XR application. Consequently, in order to run 91 applications with XR characteristics on mobile devices, 92 computationally intensive tasks need to be offloaded to resources 93 provided by Edge Computing. 95 Edge Computing is an emerging paradigm where computing resources and 96 storage are made available in close network proximity at the edge of 97 the Internet to mobile devices and sensors [EDGE_1], [EDGE_2]. These 98 edge computing devices use cloud technologies that enable them to 99 support offloaded XR applications. In particular, the edge devices 100 deploy cloud computing implementation techniques such as 101 disaggregation (breaking vertically integrated systems into 102 independent components with open interfaces using SDN), 103 virtualization (being able to run multiple independent copies of 104 those components such as SDN Controller apps, Virtual Network 105 Functions on a common hardware platform) and commoditization ( being 106 able to elastically scale those virtual components across commodity 107 hardware as the workload dictates) [EDGE_3]. Such techniques enable 108 XR applications requiring low-latency and high bandwidth to be 109 delivered by mini-clouds running on proximate edge devices 111 In this document, we discuss the issues involved when edge computing 112 resources are offered by network operators to operationalize the 113 requirements of XR applications running on devices with various form 114 factors. Examples of such form factors include Head Mounted Displays 115 (HMD) such as Optical-see through HMDs and video-see-through HMDs and 116 Hand-held displays. Smart phones with video cameras and GPS are 117 another example of such devices. These devices have limited battery 118 capacity and dissipate heat when running. Besides as the user of 119 these devices moves around as they run the XR application, the 120 wireless latency and bandwidth available to the devices fluctuates 121 and the communication link itself might fail. As a result algorithms 122 such as those based on adaptive-bit-rate techniques that base their 123 policy on heuristics or models of deployment perform sub-optimally in 124 such dynamic environments.[ABR_1]. We motivate these issues with a 125 use-case that we present in the following sections. 127 2. Conventions used in this document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 3. Use Case 135 We now describe a use case that involves an application with AR 136 systems' characteristics. Consider a group of tourists who are being 137 conducted in a tour around the historical site of the Tower of 138 London. As they move around the site and within the historical 139 buildings, they can watch and listen to historical scenes in 3D that 140 are generated by the AR application and then overlaid by their AR 141 headsets onto their real-world view. The headset then continuously 142 updates their view as they move around. 144 The AR application first processes the scene that the walking tourist 145 is watching in real-time and identifies objects that will be targeted 146 for overlay of high resolution videos. It then generates high 147 resolution 3D images of historical scenes related to the perspective 148 of the tourist in real-time. These generated video images are then 149 overlaid on the view of the real-world as seen by the tourist. 151 We now discuss this processing of scenes and generation of high 152 resolution images in greater detail. 154 3.1. Processing of Scenes 156 The task of processing a scene can be broken down into a pipeline of 157 three consecutive subtasks namely tracking, followed by an 158 acquisition of a model of the real world, and finally registration 159 [AUGMENTED]. 161 Tracking: This includes tracking of the three dimensional coordinates 162 and six dimensional pose (coordinates and orientation) of objects in 163 the real world[AUGMENTED]. The AR application that runs on the 164 mobile device needs to track the pose of the user's head, eyes and 165 the objects that are in view.This requires tracking natural features 166 that are then used in the next stage of the pipeline. 168 Acquisition of a model of the real world: The tracked natural 169 features are used to develop an annotated point cloud based model 170 that is then stored in a database.To ensure that this database can be 171 scaled up,techniques such as combining a client side simultaneous 172 tracking and mapping and a server-side localization are used[SLAM_1], 173 [SLAM_2], [SLAM_3], [SLAM_4]. 175 Registration: The coordinate systems, brightness, and color of 176 virtual and real objects need to be aligned in a process called 177 registration [REG]. Once the natural features are tracked as 178 discussed above, virtual objects are geometrically aligned with those 179 features by geometric registration .This is followed by resolving 180 occlusion that can occur between virtual and the real objects 181 [OCCL_1], [OCCL_2]. The AR application also applies photometric 182 registration [PHOTO_REG] by aligning the brightness and color between 183 the virtual and real objects.Additionally, algorithms that calculate 184 global illumination of both the virtual and real objects 185 [GLB_ILLUM_1], [GLB_ILLUM_2] are executed.Various algorithms to deal 186 with artifacts generated by lens distortion [LENS_DIST], blur [BLUR], 187 noise [NOISE] etc are also required. 189 3.2. Generation of Images 191 The AR application must generate a high-quality video that has the 192 properties described in the previous step and overlay the video on 193 the AR device's display- a step called situated visualization. This 194 entails dealing with registration errors that may arise, ensuring 195 that there is no visual interference [VIS_INTERFERE], and finally 196 maintaining temporal coherence by adapting to the movement of user's 197 eyes and head. 199 4. Requirements 201 The components of AR applications perform tasks such as real-time 202 generation and processing of high-quality video content that are 203 computationally intensive. As a result,on AR devices such as AR 204 glasses excessive heat is generated by the chip-sets that are 205 involved in the computation [DEV_HEAT_1], [DEV_HEAT_2]. 206 Additionally, the battery on such devices discharges quickly when 207 running such applications [BATT_DRAIN]. 209 A solution to the heat dissipation and battery drainage problem is to 210 offload the processing and video generation tasks to the remote 211 cloud.However, running such tasks on the cloud is not feasible as the 212 end-to-end delays must be within the order of a few milliseconds. 213 Additionally,such applications require high bandwidth and low jitter 214 to provide a high QoE to the user.In order to achieve such hard 215 timing constraints, computationally intensive tasks can be offloaded 216 to Edge devices. 218 Another requirement for our use case and similar applications such as 219 360 degree streaming is that the display on the AR/VR device should 220 synchronize the visual input with the way the user is moving their 221 head. This synchronization is necessary to avoid motion sickness 222 that results from a time-lag between when the user moves their head 223 and when the appropriate video scene is rendered. This time lag is 224 often called "motion-to-photon" delay. Studies have shown 225 [PER_SENSE], [XR], [OCCL_3] that this delay can be at most 20ms and 226 preferably between 7-15ms in order to avoid the motion sickness 227 problem. Out of these 20ms, display techniques including the refresh 228 rate of write displays and pixel switching take 12-13ms [OCCL_3], 229 [CLOUD]. This leaves 7-8ms for the processing of motion sensor 230 inputs, graphic rendering, and RTT between the AR/VR device and the 231 Edge. The use of predictive techniques to mask latencies has been 232 considered as a mitigating strategy to reduce motion sickness 233 [PREDICT]. In addition, Edge Devices that are proximate to the user 234 might be used to offload these computationally intensive tasks. 235 Towards this end, the 3GPP requires and supports an Ultra Reliable 236 Low Latency of 0.1ms to 1ms for communication between an Edge server 237 and User Equipment(UE) [URLLC]. 239 Note that the Edge device providing the computation and storage is 240 itself limited in such resources compared to the Cloud. So, for 241 example, a sudden surge in demand from a large group of tourists can 242 overwhelm that device. This will result in a degraded user 243 experience as their AR device experiences delays in receiving the 244 video frames. In order to deal with this problem, the client AR 245 applications will need to use Adaptive Bit Rate (ABR) algorithms that 246 choose bit-rates policies tailored in a fine-grained manner to the 247 resource demands and playback the videos with appropriate QoE metrics 248 as the user moves around with the group of tourists. 250 However, heavy-tailed nature of several operational parameters make 251 prediction-based adaptation by ABR algorithms sub-optimal[ABR_2]. 252 This is because with such distributions, law of large numbers works 253 too slowly, the mean of sample does not equal the mean of 254 distribution, and as a result standard deviation and variance are 255 unsuitable as metrics for such operational parameters [HEAVY_TAIL_1], 256 [HEAVY_TAIL_2]. Other subtle issues with these distributions include 257 the "expectation paradox" [HEAVY_TAIL_1] where the longer we have 258 waited for an event the longer we have to wait and the issue of 259 mismatch between the size and count of events [HEAVY_TAIL_1]. This 260 makes designing an algorithm for adaptation error-prone and 261 challenging. Such operational parameters include but are not limited 262 to buffer occupancy, throughput, client-server latency, and variable 263 transmission times.In addition, edge devices and communication links 264 may fail and logical communication relationships between various 265 software components change frequently as the user moves around with 266 their AR device [UBICOMP]. 268 Thus, once the offloaded computationally intensive processing is 269 completed on the Edge Computing, the video is streamed to the user 270 with the help of an ABR algorithm which needs to meet the following 271 requirements [ABR_1]: 273 * Dynamically changing ABR parameters: The ABR algorithm must be 274 able to dynamically change parameters given the heavy-tailed 275 nature of network throughput. This, for example, may be 276 accomplished by AI/ML processing on the Edge Computing on a per 277 client or global basis. 279 * Handling conflicting QoE requirements: QoE goals often require 280 high bit-rates, and low frequency of buffer refills. However in 281 practice, this can lead to a conflict between those goals. For 282 example, increasing the bit-rate might result in the need to fill 283 up the buffer more frequently as the buffer capacity might be 284 limited on the AR device. The ABR algorithm must be able to 285 handle this situation. 287 * Handling side effects of deciding a specific bit rate: For 288 example, selecting a bit rate of a particular value might result 289 in the ABR algorithm not changing to a different rate so as to 290 ensure a non-fluctuating bit-rate and the resultant smoothness of 291 video quality . The ABR algorithm must be able to handle this 292 situation. 294 5. AR Network Traffic and Interaction with TCP 296 In addition to the requirements for ABR algorithms, there are other 297 operational issues that need to be considered for AR use cases such 298 as the one descibed above. In a study [AR_TRAFFIC] conducted to 299 characterize multi-user AR over cellular networks, the following 300 issues were identified: 302 * The uploading of data from an AR device to a remote server for 303 processing dominates the end-to-end latency. 305 * A lack of visual features in the grid environment can cause 306 increased latencies as the AR device uploads additional visual 307 data for processing to the remote server. 309 * AR applications tend to have large bursts that are separated by 310 significant time gaps. As a result, the TCP congestion window 311 enters slow start before the large bursts of data arrive 312 increasing the perceived user latency. The study [AR_TRAFFIC] 313 shows that segmentation latency at 4G LTE (Long Term Evolution)'s 314 RAN (Radio Access Network)'s RLC (Radio Link Control) layer 315 impacts TCP's performance during slow-start. 317 6. Informative References 319 [ABR_1] Mao, H., Netravali, R., and M. Alizadeh, "Neural Adaptive 320 Video Streaming with Pensieve", In Proceedings of the 321 Conference of the ACM Special Interest Group on Data 322 Communication, pp. 197-210, 2017. 324 [ABR_2] Yan, F., Ayers, H., Zhu, C., Fouladi, S., Hong, J., Zhang, 325 K., Levis, P., and K. Winstein, "Learning in situ: a 326 randomized experiment in video streaming", In 17th USENIX 327 Symposium on Networked Systems Design and Implementation 328 (NSDI 20), pp. 495-511, 2020. 330 [AR_TRAFFIC] 331 Apicharttrisorn, K., Balasubramanian, B., Chen, J., 332 Sivaraj, R., Tsai, Y., Jana, R., Krishnamurthy, S., Tran, 333 T., and Y. Zhou, "Characterization of Multi-User Augmented 334 Reality over Cellular Networks", In 17th Annual IEEE 335 International Conference on Sensing, Communication, and 336 Networking (SECON), pp. 1-9. IEEE, 2020. 338 [AUGMENTED] 339 Schmalstieg, D. S. and T.H. Hollerer, "Augmented 340 Reality", Addison Wesley, 2016. 342 [AUGMENTED_2] 343 Azuma, R. T., "A Survey of Augmented 344 Reality.", Presence:Teleoperators and Virtual 345 Environments 6.4, pp. 355-385., 1997. 347 [BATT_DRAIN] 348 Seneviratne, S., Hu, Y., Nguyen, T., Lan, G., Khalifa, S., 349 Thilakarathna, K., Hassan, M., and A. Seneviratne, "A 350 survey of wearable devices and challenges.", In IEEE 351 Communication Surveys and Tutorials, 19(4), p.2573-2620., 352 2017. 354 [BLUR] Kan, P. and H. Kaufmann, "Physically-Based Depth of Field 355 in Augmented Reality.", In Eurographics (Short Papers), 356 pp. 89-92., 2012. 358 [CLOUD] Corneo, L., Eder, M., Mohan, N., Zavodovski, A., Bayhan, 359 S., Wong, W., Gunningberg, P., Kangasharju, J., and J. 360 Ott, "Surrounded by the Clouds: A Comprehensive Cloud 361 Reachability Study.", In Proceedings of the Web Conference 362 2021, pp. 295-304, 2021. 364 [DEV_HEAT_1] 365 LiKamWa, R., Wang, Z., Carroll, A., Lin, F., and L. Zhong, 366 "Draining our Glass: An Energy and Heat characterization 367 of Google Glass", In Proceedings of 5th Asia-Pacific 368 Workshop on Systems pp. 1-7, 2013. 370 [DEV_HEAT_2] 371 Matsuhashi, K., Kanamoto, T., and A. Kurokawa, "Thermal 372 model and countermeasures for future smart glasses.", 373 In Sensors, 20(5), p.1446., 2020. 375 [EDGE_1] Satyanarayanan, M., "The Emergence of Edge Computing", 376 In Computer 50(1) pp. 30-39, 2017. 378 [EDGE_2] Satyanarayanan, M., Klas, G., Silva, M., and S. Mangiante, 379 "The Seminal Role of Edge-Native Applications", In IEEE 380 International Conference on Edge Computing (EDGE) pp. 381 33-40, 2019. 383 [EDGE_3] Peterson, L. and O. Sunay, "5G mobile networks: A systems 384 approach.", In Synthesis Lectures on Network Systems., 385 2020. 387 [GLB_ILLUM_1] 388 Kan, P. and H. Kaufmann, "Differential irradiance caching 389 for fast high-quality light transport between virtual and 390 real worlds.", In IEEE International Symposium on Mixed 391 and Augmented Reality (ISMAR),pp. 133-141, 2013. 393 [GLB_ILLUM_2] 394 Franke, T., "Delta voxel cone tracing.", In IEEE 395 International Symposium on Mixed and Augmented Reality 396 (ISMAR), pp. 39-44, 2014. 398 [HEAVY_TAIL_1] 399 Crovella, M. and B. Krishnamurthy, "Internet measurement: 400 infrastructure, traffic and applications", John Wiley and 401 Sons Inc., 2006. 403 [HEAVY_TAIL_2] 404 Taleb, N., "The Statistical Consequences of Fat Tails", 405 STEM Academic Press, 2020. 407 [I-D.ietf-mops-streaming-opcons] 408 Holland, J., Begen, A., and S. Dawkins, "Operational 409 Considerations for Streaming Media", Work in Progress, 410 Internet-Draft, draft-ietf-mops-streaming-opcons-09, 1 411 March 2022, . 414 [LENS_DIST] 415 Fuhrmann, A. and D. Schmalstieg, "Practical calibration 416 procedures for augmented reality.", In Virtual 417 Environments 2000, pp. 3-12. Springer, Vienna, 2000. 419 [NOISE] Fischer, J., Bartz, D., and W. Straßer, "Enhanced visual 420 realism by incorporating camera image effects.", 421 In IEEE/ACM International Symposium on Mixed and Augmented 422 Reality, pp. 205-208., 2006. 424 [OCCL_1] Breen, D.E., Whitaker, R.T., and M. Tuceryan, "Interactive 425 Occlusion and automatic object placementfor augmented 426 reality", In Computer Graphics Forum, vol. 15, no. 3 , pp. 427 229-238,Edinburgh, UK: Blackwell Science Ltd, 1996. 429 [OCCL_2] Zheng, F., Schmalstieg, D., and G. Welch, "Pixel-wise 430 closed-loop registration in video-based augmented 431 reality", In IEEE International Symposium on Mixed and 432 Augmented Reality (ISMAR), pp. 135-143, 2014. 434 [OCCL_3] Lang, B., "Oculus Shares 5 Key Ingredients for Presence in 435 Virtual Reality.", https://www.roadtovr.com/oculus- 436 shares-5-key-ingredients-for-presence-in-virtual-reality/, 437 2014. 439 [PER_SENSE] 440 Mania, K., Adelstein, B.D., Ellis, S.R., and M.I. Hill, 441 "Perceptual sensitivity to head tracking latency in 442 virtual environments with varying degrees of scene 443 complexity.", In Proceedings of the 1st Symposium on 444 Applied perception in graphics and visualization pp. 445 39-47., 2004. 447 [PHOTO_REG] 448 Liu, Y. and X. Granier, "Online tracking of outdoor 449 lighting variations for augmented reality with moving 450 cameras", In IEEE Transactions on visualization and 451 computer graphics, 18(4), pp.573-580, 2012. 453 [PREDICT] Buker, T. J., Vincenzi, D.A., and J.E. Deaton, "The effect 454 of apparent latency on simulator sickness while using a 455 see-through helmet-mounted display: Reducing apparent 456 latency with predictive compensation..", In Human factors 457 54.2, pp. 235-249., 2012. 459 [REG] Holloway, R. L., "Registration error analysis for 460 augmented reality.", In Presence:Teleoperators and Virtual 461 Environments 6.4, pp. 413-432., 1997. 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC 2119, 465 DOI 10.17487/RFC2119, March 1997, 466 . 468 [SLAM_1] Ventura, J., Arth, C., Reitmayr, G., and D. Schmalstieg, 469 "A minimal solution to the generalized pose-and-scale 470 problem", In Proceedings of the IEEE Conference on 471 Computer Vision and Pattern Recognition, pp. 422-429, 472 2014. 474 [SLAM_2] Sweeny, C., Fragoso, V., Hollerer, T., and M. Turk, "A 475 scalable solution to the generalized pose and scale 476 problem", In European Conference on Computer Vision, pp. 477 16-31, 2014. 479 [SLAM_3] Gauglitz, S., Sweeny, C., Ventura, J., Turk, M., and T. 480 Hollerer, "Model estimation and selection towards 481 unconstrained real-time tracking and mapping", In IEEE 482 transactions on visualization and computer graphics, 483 20(6), pp. 825-838, 2013. 485 [SLAM_4] Pirchheim, C., Schmalstieg, D., and G. Reitmayr, "Handling 486 pure camera rotation in keyframe-based SLAM", In 2013 IEEE 487 international symposium on mixed and augmented reality 488 (ISMAR), pp. 229-238, 2013. 490 [UBICOMP] Bardram, J. and A. Friday, "Ubiquitous Computing Systems", 491 In Ubiquitous Computing Fundamentals pp. 37-94. CRC Press, 492 2009. 494 [URLLC] 3GPP, "3GPP TR 23.725: Study on enhancement of Ultra- 495 Reliable Low-Latency Communication (URLLC) support in the 496 5G Core network (5GC).", 497 https://portal.3gpp.org/desktopmodules/Specifications/ 498 SpecificationDetails.aspx?specificationId=3453, 2019. 500 [VIS_INTERFERE] 501 Kalkofen, D., Mendez, E., and D. Schmalstieg, "Interactive 502 focus and context visualization for augmented reality.", 503 In 6th IEEE and ACM International Symposium on Mixed and 504 Augmented Reality, pp. 191-201., 2007. 506 [XR] 3GPP, "3GPP TR 26.928: Extended Reality (XR) in 5G.", 507 https://portal.3gpp.org/desktopmodules/Specifications/ 508 SpecificationDetails.aspx?specificationId=3534, 2020. 510 Authors' Addresses 512 Renan Krishna 513 InterDigital Europe Limited 514 64, Great Eastern Street 515 London 516 EC2A 3QR 517 United Kingdom 518 Email: renan.krishna@interdigital.com 520 Akbar Rahman 521 InterDigital Communications, LLC 522 1000 Sherbrooke Street West 523 Montreal H3A 3G4 524 Canada 525 Email: Akbar.Rahman@InterDigital.com