johannes/DissLiteratur
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
DissLiteratur/storage/96SL8YWN/.zotero-ft-cache
Johannes Paehr c4354c0441 init
2025-10-18 15:35:31 +02:00

1085 lines
170 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
STANDARDS
IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
IEEE Computer Society
Developed by the Standard Activities Board IEEE Std 3079™-2020
Authorized licensed use limited to: Technische Informationsbibliothek (TIB). Downloaded on February 13,2025 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079™-2020
IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Developed by the Standard Activities Board of the IEEE Computer Society Approved 24 September 2020 IEEE SA Standards Board
Authorized licensed use limited to: Technische Informationsbibliothek (TIB). Downloaded on February 13,2025 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
Abstract: Head-mounted display-based virtual reality sickness-reducing technology is defined.
Keywords: best practices for VR content design, measurement for motion-to-photon latency, network constraint for virtual reality (VR) sickness, VR sickness, VR sickness assessment, VR sickness assessment framework, VR sickness level
The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA
Copyright © 2020 by The Institute of Electrical and Electronics Engineers, Inc. All rights reserved. 29 April 2021. Printed in the United States of America.
IEEE and 802 are a registered trademark in the U.S. Patent & Trademark Office, owned by The Institute of Electrical and Electronics Engineers, Incorporated.
PDF: ISBN 978-1-5044-7102-2 Print: ISBN 978-1-5044-7103-9
STD24431 STDPD24431
IEEE prohibits discrimination, harassment, and bullying. For more information, visit httpss://​www​.ieee​.orgabout/​corporate/​governance/​p9​-26​.html. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher.
Authorized licensed use limited to: Technische Informationsbibliothek (TIB). Downloaded on February 13,2025 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
Important Notices and Disclaimers Concerning IEEE Standards Documents
IEEE Standards documents are made available for use subject to important notices and legal disclaimers. These notices and disclaimers, or a reference to this page (https://s​ tandards​.ieee.​ org/​ipr/​disclaimers.​ html), appear in all standards and may be found under the heading “Important Notices and Disclaimers Concerning IEEE Standards Documents.”
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards Documents
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE SA) Standards Board. IEEE develops its standards through an accredited consensus development process, which brings together volunteers representing varied viewpoints and interests to achieve the final product. IEEE Standards are documents developed by volunteers with scientific, academic, and industry-based expertise in technical working groups. Volunteers are not necessarily members of IEEE or IEEE SA, and participate without compensation from IEEE. While IEEE administers the process and establishes rules to promote fairness in the consensus development process, IEEE does not independently evaluate, test, or verify the accuracy of any of the information or the soundness of any judgments contained in its standards.
IEEE makes no warranties or representations concerning its standards, and expressly disclaims all warranties, express or implied, concerning this standard, including but not limited to the warranties of merchantability, fitness for a particular purpose and non-infringement. In addition, IEEE does not warrant or represent that the use of the material contained in its standards is free from patent infringement. IEEE standards documents are supplied “AS IS” and “WITH ALL FAULTS.”
Use of an IEEE standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard.
In publishing and making its standards available, IEEE is not suggesting or rendering professional or other services for, or on behalf of, any person or entity, nor is IEEE undertaking to perform any duty owed by any other person or entity to another. Any person utilizing any IEEE Standards document, should rely upon his or her own independent judgment in the exercise of reasonable care in any given circumstances or, as appropriate, seek the advice of a competent professional in determining the appropriateness of a given IEEE standard.
IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO: THE NEED TO PROCURE SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE PUBLICATION, USE OF, OR RELIANCE UPON ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE.
Translations
The IEEE consensus development process involves the review of documents in English only. In the event that an IEEE standard is translated, only the English version published by IEEE is the approved IEEE standard.
3
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
Official statements
A statement, written or oral, that is not processed in accordance with the IEEE SA Standards Board Operations Manual shall not be considered or inferred to be the official position of IEEE or any of its committees and shall not be considered to be, nor be relied upon as, a formal position of IEEE. At lectures, symposia, seminars, or educational courses, an individual presenting information on IEEE standards shall make it clear that the presenter’s views should be considered the personal views of that individual rather than the formal position of IEEE, IEEE SA, the Standards Committee, or the Working Group.
Comments on standards
Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of membership affiliation with IEEE or IEEE SA. However, IEEE does not provide interpretations, consulting information, or advice pertaining to IEEE Standards documents.
Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Since IEEE standards represent a consensus of concerned interests, it is important that any responses to comments and questions also receive the concurrence of a balance of interests. For this reason, IEEE and the members of its Societies and Standards Coordinating Committees are not able to provide an instant response to comments, or questions except in those cases where the matter has previously been addressed. For the same reason, IEEE does not respond to interpretation requests. Any person who would like to participate in evaluating comments or in revisions to an IEEE standard is welcome to join the relevant IEEE working group. You can indicate interest in a working group using the Interests tab in the Manage Profile & Interests area of the IEEE SA myProject system. An IEEE Account is needed to access the application.
Comments on standards should be submitted using the Contact Us form.
Laws and regulations
Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with the provisions of any IEEE Standards document does not constitute compliance to any applicable regulatory requirements. Implementers of the standard are responsible for observing or referring to the applicable regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in compliance with applicable laws, and these documents may not be construed as doing so.
Data privacy
Users of IEEE Standards documents should evaluate the standards for considerations of data privacy and data ownership in the context of assessing and using the standards in compliance with applicable laws and regulations.
Copyrights
IEEE draft and approved standards are copyrighted by IEEE under US and international copyright laws. They are made available by IEEE and are adopted for a wide variety of both public and private uses. These include both use, by reference, in laws and regulations, and use in private self-regulation, standardization, and the promotion of engineering practices and methods. By making these documents available for use and adoption by public authorities and private users, IEEE does not waive any rights in copyright to the documents.
4
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
Photocopies
Subject to payment of the appropriate licensing fees, IEEE will grant users a limited, non-exclusive license to photocopy portions of any individual standard for company or organizational internal use or individual, noncommercial use only. To arrange for payment of licensing fees, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400; https://w​ ww​.copyright​ .com/​. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center.
Updating of IEEE Standards documents
Users of IEEE Standards documents should be aware that these documents may be superseded at any time by the issuance of new editions or may be amended from time to time through the issuance of amendments, corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the document together with any amendments, corrigenda, or errata then in effect.
Every IEEE standard is subjected to review at least every 10 years. When a document is more than 10 years old and has not undergone a revision process, it is reasonable to conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE standard.
In order to determine whether a given document is the current edition and whether it has been amended through the issuance of amendments, corrigenda, or errata, visit IEEE Xplore or contact IEEE. For more information about the IEEE SA or IEEE’s standards development process, visit the IEEE SA Website.
Errata
Errata, if any, for all IEEE standards can be accessed on the IEEE SA Website. Search for standard number and year of approval to access the web page of the published standard. Errata links are located under the Additional Resources Details section. Errata are also available in IEEE Xplore. Users are encouraged to periodically check for errata.
Patents
IEEE Standards are developed in compliance with the IEEE SA Patent Policy.
Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to the existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant has filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the IEEE SA Website at https://s​ tandards​.ieee.​ org/​about/s​ asb/​patcom/p​ atents​.html. Letters of Assurance may indicate whether the Submitter is willing or unwilling to grant licenses under patent rights without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination to applicants desiring to obtain such licenses.
Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not responsible for identifying Essential Patent Claims for which a license may be required, for conducting inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their own responsibility. Further information may be obtained from the IEEE Standards Association.
5
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IMPORTANT NOTICE
IEEE Standards do not guarantee or ensure safety, security, health, or environmental protection, or ensure against interference with or from other devices or networks. IEEE Standards development activities consider research and information presented to the standards development group in developing any safety recommendations. Other information about safety practices, changes in technology or technology implementation, or impact by peripheral systems also may be pertinent to safety considerations during implementation of the standard. Implementers and users of IEEE Standards documents are responsible for determining and complying with all appropriate safety, security, environmental, health, and interference protection practices and all applicable laws and regulations.
6
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
Participants
At the time this IEEE standard was completed, the Cybersickness Reduction Working Group had the following membership:
Dillon Seo, Chair Wookho Son, Vice Chair Sangkwon Peter Jeong, Secretary Beom-Ryeol Lee, Technical Editor
Changjoon Choi Dong Soo Choi Jae Boo Choi Dongmin Jang Jong-Beom Jeong Suk-Ju Kang Hak Gu Kim
Hyun Taek Kim Ju Hyeong Kim Namgi Kim GookHwan Lee Sangmin Lee SoonBin Lee Yong-Ho Lee Hyun Kyoon Lim
HyeonWoo Nam Heeseok Oh Minseok Oh Seok-Hee Oh Yong Man Ro Eun-Seok Ryu Kwan-Hee Yoo
The following members of the individual Standards Association balloting group voted on this standard. Balloters may have voted for approval, disapproval, or abstention.
Changjoon Choi Jae Boo Choi Werner Hoelzl Sangkwon Peter Jeong
Piotr Karocki Daozhuang Lin Nick S. A. Nikjoo
R.K. Rannow Michael Stelts Yu Yuan Daidi Zhong
When the IEEE SA Standards Board approved this standard on 24 September 2020, it had the following membership:
Gary Hoffman, Chair Jon Walter Rosdahl, Vice Chair
John D. Kulick, Past Chair Konstantinos Karachalios, Secretary
Ted Burse Doug Edwards J.Travis Griffith Grace Gu Guido R. Hiertz Joseph L. Koepfinger*
David J. Law Howard Li Dong Liu Kevin Lu Paul Nikolich Damir Novosel Dorothy Stanley
Mehmet Ulema Lei Wang Sha Wei Philip B. Winston Daidi Zhong Jingyi Zhou
*Member Emeritus
7
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
Introduction
This introduction is not part of IEEE Std 3079™-2020, IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology. This standard defines the HMD-based VR sickness reducing technology.
8
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
Contents
1. Overview<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 13 1.1 Scope<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 13 1.2  Word usage<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 13
2.  Normative references<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 14 3.  Definitions, acronyms, and abbreviations<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 14
3.1  Definitions<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 14 3.2  Acronyms and abbreviations<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 19 4.  General architecture<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 20 4.1 Introduction<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 20 4.2  General design principles<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 22 5.  VR content design<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 22 5.1 General<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 22 5.2  General scope<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 23 5.3  Use cases<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 23 5.4 Scenarios<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 25 5.5  Best practices for VR sickness reduction<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 26 6.  VR sickness assessment<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 39 6.1 General<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 39 6.2  General scope<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 39 6.3  Use cases<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 39 6.4 Scenarios<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 44 6.5  Framework of assessment for VR sickness<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 46 7.  Motion-to-photon latency<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 59 7.1 Measurement<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 59 7.2 Network<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 62 Annex A (informative) Bibliography<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 72
9
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
List of Figures
Figure 1—Reference model for the HMD-based VR sickness–reducing technology<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 21 Figure 2—Contributing factors of VR sickness<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 23 Figure 3—Considering factors of VR content design to reduce VR sickness<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 24 Figure 4—Applying VR sickness–reduction methods to VR content<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 26 Figure 5—Designing VR content to reduce VR sickness<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 26 Figure 6—System block diagram for VRSL evaluation<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 40 Figure 7—Design tools of clinical trial for VRSL estimation<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 42 Figure 8—Configuration of cloud-based clinical trials<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 43 Figure 9—FPS VR game in the walking attraction with VRSL estimation<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 45 Figure 10—Roller coaster VR game on the motion platform with VRSL estimation<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 45 Figure 11—Relationship between human factor parameters and VR sickness symptoms for the evaluation of VR sickness<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 46 Figure 12—Framework for the analysis and evaluation of VR sickness<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 48 Figure 13—Parameters affecting VR sickness<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 49 Figure 14—Configuration of primitive content<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 50 Figure 15—Clinical trial protocol for primitive content<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 50 Figure 16—Scenario content<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 51 Figure 17—Configuration of scenario content<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 52 Figure 18—Clinical trial for scenario content<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 52 Figure 19—Correlation between primitive content and scenario content<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 53 Figure 20—Typical preparation of clinical trial<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 54 Figure 21—Repeat intervals at clinical trial<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 54 Figure 22—Clinical trial with bio-signal measurement<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 55 Figure 23—Measuring environment for bio-signal<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 56 Figure 24—Operational environments for clinical trial<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 56 Figure 25—Visualization results for system parameters<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 57 Figure 26—Visualization results for bio-signal<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 58 Figure 27—Overall process for the image rendering<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 60 Figure 28—Conceptual architecture of the latency measurement model<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 60
10
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
Figure 29—An example of photosensor-based latency measurement system: (a) yaw-direction encoder, (b) pitch-direction encoder, (c) HMD system, and (d) plate holding the display of the HMD system<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 61 Figure 30—Pixel luminance change detector: (a) photosensor, (b) HMD panel, and (c) chamber<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 61 Figure 31—Cross-sectional diagram of an individual pixel luminance change detector<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 62 Figure 32—Operational process of the pixel luminance change measurement method<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 62 Figure 33—A single VR system connected via a LAN<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 63 Figure 34—A single VR system connected via a WAN<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 64 Figure 35—Multiple VR systems connected via a LAN<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 65 Figure 36—Multiple VR systems connected via a WAN<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 66 Figure 37—Special use case—change of network<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 67 Figure 38—Data cliff<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 67 Figure 39—Alleviation of data cliff phenomenon<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 68
11
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
List of Tables
Table 1—Classification of users for content design<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 23 Table 2—Categorization of VR content parameters<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 27 Table 3—Classification of users for human factor assessment<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 40 Table 4—Naming convention of the primitive contents<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 50 Table 5—Relation between use cases and network requirements<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 69 Table 6—Requirements and capabilities for VR HMDs<08><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD> 71
12
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
1. Overview 1.1 Scope
This standard defines the technical requirements that can reduce or control the VR sickness caused by the HMD‑based VR content service. Hence, the VR content service mentioned in this document is considered HMD-based VR content service by default unless otherwise mentioned. The requirements cover the followings:
— Content design for VR sickness reduction — The framework for VR sickness assessment — The measurement and the network requirements related to motion-to-photon latency for VR sickness
reduction
1.2  Word usage The word shall indicates mandatory requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted (shall equals is required to).1, 2
The word should indicates that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required (should equals is recommended that).
The word may is used to indicate a course of action permissible within the limits of the standard (may equals is permitted to).
The word can is used for statements of possibility and capability, whether material, physical, or causal (can equals is able to).
1The use of the word must is deprecated and cannot be used when stating mandatory requirements; must is used only to describe unavoidable situations. 2The use of will is deprecated and cannot be used when stating mandatory requirements; will is only used in statements of fact.
13
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
2.  Normative references
There are no normative references in this standard
3.  Definitions, acronyms, and abbreviations 3.1  Definitions
For the purposes of this document, the following terms and definitions apply. The IEEE Standards Dictionary Online should be consulted for terms not defined in this clause.3
360-degree camera: A camera designed to capture 360-degree spherical surfaces.
4K ultra high definition (4K UHD): A term referring to high-definition resolution with a horizontal resolution in the order of 4000 pixels.
8K ultra high definition (8K UHD): A term referring to high-definition resolution with a horizontal resolution in the order of 8000 pixels.
accelerometer: A sensor for measuring linear acceleration or angular acceleration by measuring inertiainduced reaction.
angular resolution: A value of representing an interval between pixels of an image displayed by a headmounted display (HMD) on the basis of an angle. The unit of measurement is pixel per degree (PPD).
background complexity: The number of figures, colors, and sizes of objects, and the level of optical flow in background scene. The background complexity may have an effect on cybersickness.
binocular disparity: Difference in image location of an object seen by left and right eye images.
biomarker: A biomarker, or biological marker, generally refers to a measurable indicator of some biological state or condition.
constant bit rate encoding (CBR encoding): An encoding method where the codec’s output data is consumed at a constant rate with respect to time.
chromatic aberration: An effect resulting from dispersion in which there is a failure of a lens to focus all colors to the same convergence point.
contrast ratio (CR): The ratio of the luminance of the brightest color (white) to that of the darkest color (black).
controllability: The level of control over virtual reality (VR) content, which can be either an active control experience or passive exposure to VR content. The more passive the VR experience is, the less controllability the user has.
cybersickness: Psychological and physiological symptoms similar to those of motion sickness. Cybersickness symptoms include discomfort, stomach awareness, nausea, pallor, cold sweating, eye fatigue, and disorientation during or as a result of experiencing virtual environments, especially using head-mounted displays.
3IEEE Standards Dictionary Online is available at: http://d​ ictionary​.ieee.​ org. An IEEE Account is required for access to the dictionary, and one can be created at no charge on the dictionary sign-in page.
14
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
depth of field: The effective focus range or distance between the nearest and farthest objects in a moving scene used to improve sharp images. Inadequate depth of field in rendered virtual reality (VR) stereoscopic scenes can cause the symptoms of VR sickness.
electrocardiography (ECG): Electrophysiological signals of the heart recorded over a period of time using electrodes placed on the skin.
electroencephalography (EEG): Electrophysiological signals of the brain recorded noninvasively using electrodes placed on the scalp.
electrogastrography (EGG): Electrophysiological signals of the stomach recorded using electrodes placed on the abdominal skin.
exit pupils: The range of pupil size in the head-mounted display (HMD). In a general optical system, it refers to a hole through which the light exits, an exit hole seen from the direction in which the optical system is seen from the eye, or a hole through which the image can be formed by the lens behind the optical system.
eye dominance: The preference of processing visual input by the left or right eye.
eye relief: The distance between the eyepiece and the user’s eyes.
eye tracking: A technique to track the position of the eye by sensing the movement of the pupil.
field of view (FOV): The angular width of a screen that fills the user’s visual field. Angles indicate the range of horizontal, vertical, or diagonal directions over which the camera can hold an image through the lens.
foveated rendering: An upcoming graphics rendering technique which uses an eye tracker integrated with a virtual reality headset to reduce the rendering workload by greatly reducing the image quality in the peripheral vision (outside the zone gazed by the fovea).
frame of reference: Referential objects (e.g., trees, clouds, and frames) that are stationary in a moving scene. Other similar definitions include visual guide and point of reference.
frame per second (fps): The number of images that can be processed per second.
frame rate: The amounts of frames through a certain device or a transmission link per a fixed duration. The measurement unit is frames per second (fps).
full high definition (FHD): A term created for a marketing purpose referring to 1920 × 1080 resolution.
galvanic skin response (GSR): One of the most sensitive markers of emotional arousal is galvanic skin response (GSR), also referred to as skin conductance (SC) or electro-dermal activity (EDA).
handover: The process by which a head-mounted display (HMD) obtains facilities and preserves virtual reality (VR) content traffic flow upon change from one link to another.
head-mounted display (HMD): A generic term for display devices that are attached to the head.
head tracking: A technique in which tracks the rotational and translational movement of the head-mounted display (HMD).
inter-ocular distance (IOD): The distance between the ocular lens of the head-mounted display (HMD) optical systems and eyes.
15
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
interpupillary distance (IPD): The distance between the centers of the pupils of the left and the right eyes.
jitter: The deviation from true periodicity of a presumably periodic signal, often in relation to a reference clock signal.
motion blur: The apparent streaking of rapidly moving objects in a still image or a sequence of images, such as a movie or animation.
motion feedback frequency: The frequency that a head-mounted display (HMD) sends collected data, mainly motion, to a virtual reality (VR) server.
motion sickness: Psychological and physiological symptoms that are caused by discordance between visually perceived movement and the sense of bodily movement in vestibular organs.
motion sickness susceptibility questionnaire (MSSQ): Motion sickness susceptibility questionnaires, sometimes called motion history questionnaires, are useful instruments in the prediction of motion sickness due to a variety of provocative environments.
motion-to-audio latency: Time delay from the head-mounted display (HMD) user’s movement and the change of sound in HMD caused by the movement.
motion-to-photon latency: Time delay from the HMD user’s movement and the change of view in headmounted display (HMD) caused by the movement.
nausea scale: A scale that measures a user’s symptoms of nausea using a score between 0 and 5. Nausea levels are reported verbally every minute.
network latency: Amount of time that information takes to traverse a system (or from one node to another node).
no-parallax point: A point on the camera lens resulting in no parallax between foreground and background. To avoid errors in the panorama image-stitching process, parallax-free images are required and can be obtained by rotating on the no-parallax point when shooting a panorama image or a 360‑degree image.
number of motion axes: The number of directional and rotational factors of optical flow. This number influences the magnitude of cybersickness and motion sickness.
objective measurement: Quantification of the user’s behavioral and physiological changes. In the study of cybersickness, objective measures include the user’s magnitude of postural sway and physiological signals, such as measured by an electroencephalogram (EEG), electrogastrogram (EGG), or electrocardiogram (ECG), etc.
ocularity (monocular, binocular, biocular): Type of optical systems used in the head-mounted display (HMD) determined by the number of video signals. When the video signal is delivered to one eye, it is called monocular. When two different video signals are delivered to both eyes, it is called binocular. When a single video signal is delivered to both eyes, it is called biocular.
optical distortion: Distortion occurring in the optical system—often the distorted image is in a barrel or pincushion shape, depending on the system.
optical flow: The apparent movement of edges, surfaces, and objects in a scene that demonstrates the relative motion between an observer head-mounted display (HMD) and the observed scene.
16
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
packet error rate (PER): The number of incorrectly received packets divided by the total number of received packets.
photoplethysmography (PPG): A non-intrusive optical measurement technique that can be used to detect blood volume changes in the microvascular bed of tissue.
pixel per inch (PPI): A measurement of the pixel density of an electronic image device, such as a computer monitor or television display.
polygon per second (PPS): The number of polygons that can be processed per second.
positional tracking: A technique that tracks the rotational and translational movement of all objects including head-mounted display (HMD), controllers, and peripheral devices.
postural stability: The ability to maintain balance using the muscles in your ankles, knees, and hips in response to movement. Postural stability decreases with fatigue, particularly in the knees and hips.
postural sway: The sense of the positions and movements of a person’s own limbs and trunk, plus the strength employed in such movements.
reference object: A visual scene or component that provides stationary location or orientation cue, and which matches the vestibular signal.
refresh rate: The number of pictures that can be processed by the imaging device at one time. The measurement unit is Hertz (Hz).
response time: The amount of time a pixel in a display takes to change. It is measured in milliseconds (ms).
sensory conflict theory: A working hypothesis to explain the physiological mechanism of motion sickness and cybersickness. Sensory disparity between the visual and the vestibular systems can induce symptoms of motion sickness and cybersickness.
sensory mismatch: The discrepancy between different sensations related to orientation and movement, especially from the visual and the vestibular organs, which causes motion sickness and cybersickness (visually induced motion sickness [VIMS], simulator sickness, etc.).
simulator sickness: Psychological and physiological symptoms similar to those of motion sickness, typically experienced by pilots and drivers who receive simulator training.
simulator sickness questionnaire (SSQ): A standard questionnaire used to measure the magnitude of simulator sickness symptoms.
six degrees of freedom (6DOF): Six operating elements of a moving object in three dimensional space. 6DOF can be used to describe rotational movements (roll, pitch, yaw) and translational movements (forward/back, left/right, up/down).
spatial 3D sound: A technology that allows the user to identify the location of a sound source where sound is generated. In conjunction with head tracking of the head-mounted display (HMD), the sound is generated relative to the head direction.
spatial velocity: The velocity of virtual scene movement, as observed in the head-mounted display (HMD), that represents the speed of the scene movement for the user.
17
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
stereoscopy: Three-dimensional vision with the illusion of depth from two-dimensional images using the visual difference of both eyes.
stitch: Technique to combine two or more videos to create 360-degree video and minimize the image distortion.
subjective measurement: Quantification of the user’s subjective experiences. In the study of cybersickness, subjective measures include scores on the Simulator Sickness Questionnaire (SSQ), Nausea scale, fast motion sickness scale (FMS), misery scale (MISC), etc.
three degrees of freedom (3DOF): Three rotational elements of moving objects in three dimensional space. The three degrees refer to the roll (x axis), pitch (y axis), and yaw (z axis) rotation operations on X, Y, and Z axes.
time-warping rendering: A technique in virtual reality (VR) that warps the rendered image before sending it to the display to correct for the head movement that occurred after the rendering. It is either used to reduce the latency or maintain the desired frame rate.
tracking sensor: A device for tracking the movement of the user to synchronize with the content.
ultra high definition (UHD): A term created for marketing purposes to refer to at least 3840 × 2160 resolution.
variable bit rate encoding (VBR encoding): An encoding method—as opposed to constant bit rate (CBR) encoding—where a codec’s output data rate is consumed inconsistently with respect to time.
vection: Visually induced illusions of self-motion experienced by physically stationary observers in a real environment or in a virtual environment.
vestibular system: The sensory system that provides a sense of bodily movement and balance. It also provides the spatial orientation for the purpose of coordinating movement.
video tracking: A computer vision technology for finding the position change of a specific object, such as a person, animal, or car in a video shot by a camera.
viewing angle: The maximum angle at which a display device may be viewed with acceptable visual performance, described by the angular range or viewing cone, and includes various viewing directions.
virtual reality (VR): Refers to any specific environment, situation, or technology that either simulates actual reality or creates virtual spaces and objects according to the imagination of humans using computer graphics or videos.
virtual reality (VR) fidelity: The level of similarity in sensation and perception between real and virtual environments.
virtual reality (VR) sickness (VRS): Syn: cybersickness.
virtual reality (VR) sickness level (VRSL): User levels for the intensity of VR sickness.
visually induced motion sickness (VIMS): Sensations and perceptions similar to traditional motion sickness with limited or no physical movement.
wireless head-mounted display (HMD) access distance: The distance from the virtual reality (VR) content server wireless module to the HMD wireless module, and within that distance the VR HMD should display without severe interruption.
18
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
3.2  Acronyms and abbreviations
3DOF 3GPP 4K UHD 8K UHD CBR CR EEG EGG ECG FOV FPS fps FHD GPU GSR HDMI HMD IMU IOD IPD IRB LAN LOS LTE MIMO MISC MPEG MSSQ NLOS PER PPG PPI PPS QHD QoE
three degrees of freedom Third Generation Project Partnership 4K Ultra High Definition 8K Ultra High Definition constant bit rate contrast ratio electroencephalogram/electroencephalography electrogastrogram/electrogastrography electrocardiogram/electrocardiography field of view first person shooter [game] frame per second full high definition graphics processing unit galvanic skin response high definition multimedia interface head-mounted display inertial measurement unit interocular distance interpupillary distance institutional review board local area network line-of-sight Long Term Evolution multiple input and multiple output misery scale Moving Picture Experts Group motion sickness susceptibility questionnaire non-line of sight packet error rate photoplethysmography pixel per inch polygon per second quad high definition quality of experience
19
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
QoS S3D SSQ UHD USB VBR VIMS VR VRS VRSL WAN
quality of service stereoscopic 3D simulator sickness questionnaire ultra-high definition universal serial bus variable bit rate visually induced motion sickness virtual reality virtual reality sickness virtual reality sickness level wide area network
4.  General architecture
4.1 Introduction
4.1.1 General
This standard describes three areas to consider in order to reduce or control the level of virtual reality (VR) sickness experienced by the users when they are using the VR content service: 1) VR content design, 2) VR sickness assessment and measurement, and 3) network requirements related to motion-to-photon latency. In general, these areas need to be closely examined in order to improve the overall quality of VR experience. While not directly reducing or controlling the VR sickness, it is beneficial to understand what VR sickness is so that the role and purpose of VR sickness-reducing technology are clear and can be better utilized. The following subclauses give an overview of these areas.
20
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 1—Reference model for the HMD-based VR sickness–reducing technology Figure 1 shows the reference model for the HMD-based VR sickness–reducing technologies. However, the scope of this standard only covers VR sickness–reducing parameters for content design, assessment of VR sickness, measurement of motion-to-photon latency, and network constraint for VR content. 4.1.2  VR content design This standard describes some of the best practices for the VR content design and implementation that can reduce the level of VR sickness. The content design parameters mentioned in this standard include content directing, scene capturing and management, human factors of the content users, head-mounted display (HMD) devices, and operational environment for playing VR content. 4.1.3  VR sickness assessment This standard explains the methodology and procedures required to assess the level of VR sickness experienced by the VR content service users. The methodology and procedure quantify the correlation between the VR sickness causing parameters and the VR sickness symptoms. The VR sickness causing parameters include content directing, content scene, human factor, scene capture, HMD device, and operational environment related parameters. VR sickness symptoms include nausea, eye fatigue, and disorientation. 4.1.4  Measurement and network requirements related to motion-to-photon latency This standard introduces HMD-specific network topologies based on their use cases. Then, it suggests wireless transmission technology candidates either available now, or within two years, along with their performance specifications. Also, the capabilities of these technologies and the requirements are compared to explain the areas that already satisfy the demands for wireless HMD and the areas that require further development.
21
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
4.2  General design principles
4.2.1  VR content design
This standard describes how to produce VR content that can reduce or control VR sickness. It specifies which users will use the standard and defines the requirements for each user. Use cases and user scenarios were presented for typical VR content that users could experience. Considerations for creating VR sicknessreducing VR content were derived by dividing them into six categorized parameters. These are: content direction, content scene, human factor, scene capture, HMD device, and operational environment-related parameters. Each individual parameter was described by dividing it into its needs and requirements, evaluation methods, and constraints.
4.2.2  VR sickness assessment
This standard deals with methods and procedures for evaluating the level of occurrence of VR sickness while users experience VR content. We defined the users of this standard and presented the use case and user scenarios for each user. A framework for evaluating VR sickness is presented and detailed configuration module design are included. How reference content is produced to evaluate VR sickness is described. It also describes the methods and procedures of clinical trials. During the clinical trial, the measuring environments for bio-signals, including the subject’s electroencephalogram (EEG), is described. It also describes how to evaluate the results of subjects’ clinical trials through a survey.
4.2.3  Measurement model and network requirements related to motion-to-photon latency
This standard describes a measurement model for evaluating the motion-to-photon latency. We described the overall process of the motion-to-photon latency of the image rendering in the head‑mounted display system. Then, we defined the novel measurement system, which largely consists of a control personal computer (PC), a head position model-based rotary platform, a pixel luminance change detector, and a digital oscilloscope. In addition, we described the measurement procedure from the motion detection in the inertial measurement unit sensor to the rendered image output in the display.
As VR HMDs can be used for different purposes, different network topologies are required. Hence, this standard is designed to introduce five different use cases.
Several standards organizations, such as The IEEE 802®, Moving Picture Experts Group (MPEG), and Third Generation Project Partnership (3GPP), have identified the issues that are both related to network and nonnetwork requirements for VR HMDs. The network-related issues include lower motion-to-photon latency, higher data transmission rate, low jitter, longer transmission range, better mobility, and low packet error rate. The non-network related issues include higher frame rate and display resolution.
Several wireless transmission technologies that are under development can be adopted for the upcoming wireless VR HMDs. Their technical capabilities are described briefly with emphasis on VR HMD requirements. The capabilities of existing wireless transmission technologies are compared with the requirements of a wireless VR HMD system. This comparison will help understand which features already satisfy the requirements and which areas need further enhancement.
5.  VR content design
5.1 General
Clause 5 describes user requirements and system specifications to reduce VR sickness when designing and implementing VR content from the user’s perspective.
22
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
5.2  General scope
Clause 5 describes two use cases to understand how each factor in VR content can contribute to VR sickness and how they could be controlled to reduce this sickness. Also, it presents two scenarios to demonstrate methods that can be used to reduce VR sickness, and provides some of the best practices that can be used to reduce VR sickness when designing and implementing VR content.
5.3  Use cases 5.3.1  Classification of users Table 1 describes the user classification according to their roles for VR content design.
User Content designer Content programmer Content player
Content evaluator
Table 1—Classification of users for content design User’s role
Designing visual scene and stages for VR content Implementing rules and modules for VR content SW Playing VR content Testing VR content and evaluating the virtual reality sickness level (VRSL) of the VR content
5.3.2  Use case 1: Reducing VR sickness of VR content
5.3.2.1 Overview
VR content that causes the feeling of nausea, eye fatigue, and dizziness can be controlled by modifying the VR sickness contributing factors, such as screen rotation, head tilting, frame of reference, etc.
Figure 2—Contributing factors of VR sickness
5.3.2.2  Related users Content player.
23
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
5.3.2.3 Pre-condition VR sickness is experienced while playing the VR content. 5.3.2.4  Event flow
— Play the VR content — Move to the stage or scene where VR sickness is occurring — Apply VR sickness–reducing method — Replay the stage or scene where VR sickness–reducing method is applied 5.3.2.5 Post-condition VR sickness level is reduced while playing the VR content. 5.3.2.6 Requirements 5.3.2.6.1  Functional requirements Reduce VR sickness level of VR content. 5.3.2.6.2  Non-functional requirements None. 5.3.3  Use case 2: Designing VR content to reduce VR sickness 5.3.3.1 Overview Users should be able to experience VR content for an extended period of time without any inconveniences, including nausea, eye fatigue, and dizziness.
Figure 3—Considering factors of VR content design to reduce VR sickness
24
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
5.3.3.2  Related users Content designer, content programmer. 5.3.3.3 Pre-condition Stage or scene is causing VR sickness. 5.3.3.4  Event flow
— Design and play the VR content — Evaluate the stage or scene of VR content to identify VR sickness level — Manage VR sickness level by modifying VR camera flow, VR scene, VR content parameters, etc. 5.3.3.5 Post-condition VR sickness level is reduced in the stage or scene of VR content. 5.3.3.6 Requirements 5.3.3.6.1  Functional requirements Design VR content to reduce VR sickness level. 5.3.3.6.2  Non-functional requirements None.
5.4 Scenarios 5.4.1  Scenario 1: Applying VR sickness–reduction methods to VR content Users playing VR content often experience various forms of VR sickness when the content fails to adjust some of the important factors, such as scene rotation, head tilting, frame of reference, etc. Some of the VR content genres, such as first person shooter (FPS), racing, and rollercoaster, are already causing VR sickness due to their nature, but adjusting these factors may decrease the unnecessary discomfort caused by the wrong implementation. The content can be experienced while seating, standing, or walking. The implementation of scene rotation, head tilting, or frame of reference needs to be adjusted depending on environmental factors in order to reduce the VR sickness. By reducing VR sickness, users may be able to experience the content for an extended period of time more comfortably. The VR content designer should be able to identify the stage or scene where VR sickness occurs, make the necessary adjustments, and reduce the VR sickness level.
25
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 4—Applying VR sickness–reduction methods to VR content 5.4.2  Scenario 2: Designing VR content to reduce VR sickness VR sickness often hinders the users from experiencing the VR content for an extended period of time. However, the VR content designer must make a judgement if reducing VR sickness is hampering the overall VR experience. Reducing VR sickness is important, but it should not undermine the original design intention of VR content. VR content designers should also make sure that the users experiencing the content should not feel any discomfort. Hence, VR content developers should be able to evaluate the VR sickness level while designing the content and manage the VR sickness level by modifying the VR camera flow, scenes, content parameters, etc., so that the users may experience the content with minimal discomfort.
Figure 5—Designing VR content to reduce VR sickness 5.5  Best practices for VR sickness reduction 5.5.1 Overview The best practices for VR sickness reduction imply a content design guideline that VR content designers can use to reduce the VR sickness. Some of the guideline includes content directing, content scene managing, human factor managing, scene capturing, HMD device setting, and operational environment managing.
26
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Table 2 displays how the content parameters can be categorized into different groups for VR content designers who want to modify specific issues in their VR content.
Table 2—Categorization of VR content parameters
Content directing
Content scene managing
Continuity of viewpoint Arrangement of scene space Spatial 3D sound
Virtual camera movement optimization Scene complexity optimization Field of view (FOV) adjustment Sensory conflict synchronization User interface placement Visual flow VR fidelity Frame of reference
Scene capturing
Stitching optimization Rig configuration
HMD device setting
Latency minimization Frame rate optimization Stereoscopic 3D optimization Resolution optimization Display type Flicker optimization
Human factor managing
Gender and age Prior experience Motion sickness susceptibility Duration of VR experience Controllability of VR sickness
Operational environment managing
Motion platform synchronization Vertical synchronization Clinical protocols
5.5.2  Content directing and related parameters
5.5.2.1  Continuity of viewpoint
5.5.2.1.1 Needs
Continuity of viewpoint implies a situation where the major scene event is occurring within the user’s viewpoint with minimal head movement. When major scene events occur, it is important to make these events happen in the users’ viewpoint so that the users do not have to turn their head much. If major scene events are happening both in the front and the back of the scene at the same time, users are forced to select only one scene and miss the other. When the major event scenes are placed beyond users’ viewpoint, it forces users to quickly move their heads, and this may create unnecessary VR sickness. Therefore, the scene events where the content designer intends the users to watch need to be placed within the continuity of viewpoint.
5.5.2.1.2 Implementation
Place the major VR scene events within the continuity of viewpoint. Avoid events occurring beyond the continuity of viewpoints as this will force users to move their heads quickly, which can cause unnecessary VR sickness. When the VR scenes are moving fast for story-telling purposes, these will make the camera accelerate and cause VR sickness. If it is necessary to add this acceleration, make sure that the event still happens within the continuity of viewpoint to minimize VR sickness.
5.5.2.1.3  Evaluation method
Once the content designer follows this implementation, the VR content can be evaluated by a group of experts in producing VR content for a qualitative result. Clinical trials can also be used to evaluate the content for quantitative results.
27
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
5.5.2.1.4 Remarks
In a normal 2D content scene, the content designer has full control over the viewpoint movement. Hence, the major events can occur both in the front and the back at the same time and this does not create any conflict in story-telling. However, the content designer has no control over viewpoint movement in a VR content scene. Therefore, it is difficult to use the conventional method to tell the story. This is the reason that continuity of viewpoint is recommended to tell the VR story more effectively with minimal VR sickness.
5.5.2.2  Arrangement of scene space
5.5.2.2.1 Needs
Arrangement of scene space implies a situation where the major events and the objects needed to tell the story to users are arranged in the particular scene space. This arrangement is recommended to tell the story more effectively and maintain the immersiveness of the VR scene. The particular scene space needs to be the space where users acknowledge the major events and objects, and this space needs to be carefully selected according to the interaction or reaction between the scene and the users. Therefore, the VR content designer needs to implement the interaction or reaction points and arrange the scenes accordingly so that users are looking at the events as the designer intended.
5.5.2.2.2 Implementation
When the VR content designer designs the interaction or reaction between the scene and users, the designer needs to arrange the major events and objects in the particular scene where users can follow through this interaction or reaction and look at these events and objects as the designer intended.
5.5.2.2.3  Evaluation method
Once the content designer follows this implementation, the VR content can be evaluated by a group of experts in producing VR content for a qualitative result. Clinical trials can also be used to evaluate the content for quantitative results.
5.5.2.2.4 Remarks
For story-telling purposes, the major events and objects may need to occur behind the users’ viewpoint. However, this is not recommended as it forces users to look behind their backs, and this may create unnecessary discomfort and VR sickness. Hence, the VR content designer should keep this in mind and arrange the scene so that users can still understand events in a comfortable position with minimal head motion.
5.5.2.3  Spatial 3D sound
5.5.2.3.1 Needs
Spatial 3D sound implies a situation where the sound is played according to the location of the sound source. In other words, the source of 3D sound should be synchronized with the direction of users’ viewpoint. For instance, if users are currently hearing sound from the right, when they turn their heads to look at the sound source, they should be hearing the sound from the front. This is an important factor to consider for the VR content designer as the mismatch between the sound source and the actual audio playback can cause VR sickness.
5.5.2.3.2 Implementation
VR content designers should implement the sound to the object so that the sound is produced as the designer intended. The direction of the generated sound should be determined by the head position of the user. For example, if the sound source is located on the right side of the head, the sound should be heard from the right side. If the user’s head turns toward the sound source, the sound should be heard from the front. It is important
28
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
to recognize this situation as the non-VR scene does not have to consider the direction of the user’s head since the sound is designed as if the user is always looking forward.
5.5.2.3.3  Evaluation method
Once the content designer follows this implementation, the VR content can be evaluated by a group of experts in producing VR content for qualitative results. Clinical trials can also be used to evaluate the content for quantitative results.
5.5.2.3.4 Remarks
In a non-VR scene, the content designer assumes that the user’s viewpoint is always front-facing. Hence, to create more immersive sound environment, multiple speakers are located around the room to generate the sound and it travels around the user’s ears. However, it is difficult for a VR content designer to assume where the user’s head position is going to be as the designer does not have control over the user’s viewpoint. Hence, it is recommended to place the sound to the object and let the user’s head position determine the direction of the sound.
5.5.3  Content scene managing and related parameters
5.5.3.1  Virtual camera movement optimization
5.5.3.1.1 Needs
Virtual camera movement optimization implies a situation where the movement of a camera is optimized so that the VR sickness that user may experience is minimized. Optimization of camera movement is related to the movement speed. When the movement is too drastic, the chance of experiencing VR sickness is high. Therefore, the VR content designer should consider the movement speed of the virtual camera when designing the scene movement so that the VR sickness produced by the camera movement can be minimized.
5.5.3.1.2 Implementation
VR content designers should always remember that unnatural and sudden virtual camera movement can create VR sickness. Hence, virtual camera movement optimization needs to be considered in their VR content design. Unfortunately, quantitative guidelines for the camera optimization is not available. Therefore, the optimization can only be obtained heuristically. However, some of the implementations for the virtual camera movement optimization are as follow:
— Minimize the usage of camera acceleration (left, right, forward, backward, zoom in/out, and turn) and try to keep the camera movement speed constant.
— When filming the VR scene, the movements of camera—such as panning, tilting, rolling, zooming in/out—should not be used. These camera movements should be implemented later during the postproduction process.
— Try to minimize the use of virtual camera movement against the user’s movement—virtual camera movement should coincide with the user’s head movement.
— When the user needs to move from one point to another point in the VR environment, use the teleportation method where the user’s viewpoint changes by making the screen dark briefly and return to normal brightness.
— If the VR content designer wants the user to move from one point to another in the VR environment and does not want to use the teleportation method, then the camera movement speed should match actual human walking speed or a little slower.
29
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
5.5.3.1.3  Evaluation method Use virtual camera measurement software.
Measure speed and acceleration rates by interval within VR content.
5.5.3.1.4 Remarks Viewing time can be reduced when camera movements are limited, since they affect entertainment.
5.5.3.2  Scene complexity optimization 5.5.3.2.1 Needs In case of high image complexity of VR content, users are forced to recognize large amounts of visual information, leading to VR sickness. Complex backgrounds and numerous objects cause rendering computation loads for graphics processing units (GPUs), which can reduce frame rates. Reduce VR sickness by using a simple background and low contrast.
5.5.3.2.2 Implementation When implementing VR content, the background complexity (texture and spatial frequency components) should be made as low as possible. When producing VR content, distribution of objects within images is kept as low as possible. It is recommended to produce a low spatial frequency as well as rapid changes in background texture and object distribution over time.
5.5.3.2.3  Evaluation method Use image complexity measurement software. Spatial frequency domain translation of images and calculation of generalized Gaussian distribution (position, scale, shape variables).
5.5.3.2.4 Remarks Often it is not easy to reduce image complexity, such as background complexity and object distribution, while reflecting the VR content director’s intention.
5.5.3.3  FOV adjustment 5.5.3.3.1 Needs If the scale difference between the virtual camera angle (cFOV) and the display angle (dFOV) occurs, this may cause inconvenience due to motion, image distortion, and poor image quality.
5.5.3.3.2 Implementation Align the virtual camera angle (cFOV) to the fixed display angle (dFOV) as much as possible.
5.5.3.3.3  Evaluation method Use measuring software to check for a match between cFOV and dFOV. Check for match between cFOV and dFOV.
5.5.3.3.4 Remarks Reducing the dFOV can reduce VR sickness, but also reduce the immersion and visual context awareness of VR content.
30
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
5.5.3.4  Sensory conflict synchronization 5.5.3.4.1 Needs Asynchronous behavior that does not coincide with the visual experience of VR content causes dizziness and discomfort to the user.
5.5.3.4.2 Implementation It is recommended to produce VR content that synchronizes the visual experience of VR content and feeling effects.
Interaction VR content inserts a predictable component.
Use head motion information for navigation instead of input/output (i/o) controllers.
5.5.3.4.3  Evaluation method Enable sensory mismatch measurement software. Check synchronization between visual stimuli and perceived effects.
5.5.3.4.4 Remarks It is difficult to synchronize the cognitive feeling between the VR content and the user's experience. Repeated use of VR content results in reduced VR sickness and cumulative fatigue.
5.5.3.5  User interface placement 5.5.3.5.1 Needs A user interface attached to a virtual camera can cause discomfort and nausea when unnecessarily following the user’s gaze.
5.5.3.5.2 Implementation When using the user interface, it is recommended to place three-dimensional objects in a three-dimensional space. The movement of objects that make up a large part of the visual is reduced to help ensure natural user movements. A heads-up display-type user interface needs to be implemented in line with the depth values of three-dimensional objects. When inserting subtitles into VR content, it is recommended to apply spherical distortion.
5.5.3.5.3  Evaluation method Use measuring software of user interface layout.
Check the implementation of user interface on a three-dimensional space on the VR content.
5.5.3.5.4 Remarks Frame of reference within VR content reduce VR sickness.
5.5.3.6  Visual flow 5.5.3.6.1 Needs The visual flow can be used as an objective criterion for assessing VR sickness of VR content. The visual flow of VR content can be controlled as a measure to control VR sickness when creating VR content.
31
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
5.5.3.6.2 Implementation Visual flow can be used as an objective evaluation measure for VR sickness assessment. Visual flow can be used as a basis for controlling cumulative VR sickness during the experience of VR content. 5.5.3.6.3  Evaluation method Use visual flow evaluation software. 5.5.3.6.4 Remarks Visual flow, spatial velocity and object speed in the VR scene should be considered together to reduce VR sickness. 5.5.3.7  VR fidelity 5.5.3.7.1 Needs VR fidelity can be utilized as a measure of similarity level between the virtual world and the real world for VR content being implemented. 5.5.3.7.2 Implementation It is recommended that VR content implemented maintains the best VR fidelity. 5.5.3.7.3  Evaluation method Use evaluation software for VR fidelity level. Define and measure VR fidelity level. 5.5.3.7.4 Remarks Compare realism and scene complexity. 5.5.3.8  Frame of reference 5.5.3.8.1 Needs You can reduce VR sickness by adding objects that are always fixed in VR content scenes. 5.5.3.8.2 Implementation It is recommended that fixed objects are consistently exposed regardless of changes in images of VR content for stages with high VR sickness. Proper consideration is given to the location of fixed objects and time of exposure due to changes in user’s VR sickness. 5.5.3.8.3  Evaluation method Measure whether fixed objects are present or not, the size of fixed objects on the screen, the starting position of exposure, and the time of exposure. 5.5.3.8.4 Remarks Compare independent visual background (IVB) and scene content.
32
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
5.5.4  Scene capturing and related parameters 5.5.4.1  Stitching optimization 5.5.4.1.1 Needs If VR images are not stitching properly, distorted parts of images are exposed to the user’s view, which reduces the user’s sense of immersion.
5.5.4.1.2 Implementation Camera placement, lens distortion, and camera synchronization should be adjusted to minimize stitching errors during filming and post-production of VR content. It is recommended to accurately fit camera synchronization when subjects move faster or are more important, especially when filming in stereoscopic 3D (S3D).
5.5.4.1.3  Evaluation method Use the stitching measurement tools. Measure with frame rate for VR content.
5.5.4.1.4 Remarks Consider technical limitations of stitching errors.
5.5.4.2  Rig configuration 5.5.4.2.1 Needs No-parallax points mismatch between optical instruments due to the physical volume of the camera during rig configuration. In shooting 360-degree VR real content, physical limitations due to camera structure can be overcome through rig system design.
5.5.4.2.2 Implementation When taking multiple photos and stitching them into 360-degree images, the photos should be taken while rotating around the no-parallax point of the camera. The error range of the no-parallax point should be set smaller when shooting a near view than when shooting a distant view. When configuring the rig, it is recommended to place the cameras overlapping at about 20 degrees of the cameras’ field of view (15% to 20% of the recorded video). When shooting VR video, it is recommended to use genlock because synchronization between cameras is required.
5.5.4.2.3  Evaluation method Use measurement software for no-parallax points confirming. Check no-parallax points matching virtual cameras.
5.5.4.2.4 Remarks For high-performance cameras, the volume makes it difficult to get the no-parallax points close to each other. For action cams, it is easy to configure no-parallax points in close proximity, but there is a decrease in quality compared to intermediate instruments.
33
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
5.5.5  HMD device settings and related parameters 5.5.5.1  Latency minimization 5.5.5.1.1 Needs VR latency impacts user immersion and inconvenience.
5.5.5.1.2 Implementation VR latency shall be kept as low as possible, 20 ms or less.
5.5.5.1.3  Evaluation method Use latency-measuring software or hardware. Determine the specifications of the head-tracking speed of a given VR HMD, measure the time taken to render the corresponding motion information reflected in the VR image, and calculate it by combining the head-tracking speed.
5.5.5.1.4 Remarks The latency of a VR appliance needs to be minimized, but delay in each phase is inevitable during the processing of the VR appliance.
5.5.5.2  Frame rate optimization 5.5.5.2.1 Needs Low frame rate may cause users to have headaches, eye fatigue, and seizures in susceptible users as a result of flickering.
5.5.5.2.2 Implementation Frame rate in VR content must be synchronized to the refresh rate of VR HMD, and minimum frame rate is recommended at least 30 fps of images, 60 fps of graphics, and at least 90 fps of interactive content.
5.5.5.2.3  Evaluation method Use frame rate measurement software. Measure with frame rate for VR content.
5.5.5.2.4 Remarks High-contrast VR content may have a flickering effect even though frame rate is high. The frame rate of device refresh rate specification might be different for custom VR content creation.
5.5.5.3  Stereoscopic 3D optimization 5.5.5.3.1 Needs The stereoscopic 3D image implementation is a method of setting up and displaying negative and positive disparity images for each incoming image on the left and right eyes. Therefore, beyond the optimum depth distance, visual fatigue can occur. When viewing stereoscopic 3D content in an HMD environment, a 3D content production technique is required to minimize fatigue as a geometric error causes fatigue in the eyes.
5.5.5.3.2 Implementation When producing HMD-based VR 3D image content, verify that no geometry errors (e.g., vertical, tilting, and scale inconsistencies, etc.) occur. When filming VR 3D images, the distance between cameras should be set at
34
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
around 6.5 cm, based on the distance between human pupils. The subtitles in VR 3D image content should be placed right in front of the user rather than in the depth value applied in the image. It is recommended to refrain from making sudden changes in depth in the video as this results in eye fatigue.
5.5.5.3.3  Evaluation method Use measurement software for stereoscopic 3D geometry error. Verify that the interval between the camera and the virtual camera is less than 6.5 cm, and the parameters of the two cameras are synchronized to minimize the geometry error.
5.5.5.3.4 Remarks Depth of VR S3D images is determined at the shooting phase and is more important than in post-production. For VR S3D image optimization (quality of images), the post-production is considered more important than in the shooting phase, as it is important to avoid stitching inconsistencies.
5.5.5.4  Resolution optimization 5.5.5.4.1 Needs Resolution in the image of VR content affects the degree of user immersion and inconvenience. Higher pixel per inch (ppi) enables sharper screen content.
5.5.5.4.2 Implementation VR content should be at least 4K ultra-high definition (UHD, 3840 × 1920 or 3840 × 2048) based on the user’s vision and hardware parameters of VR HMD.
5.5.5.4.3  Evaluation method Use resolution measurement software. Measure VR content resolution.
5.5.5.4.4 Remarks VR HMD requires a higher level of resolution than TV and movie viewing environments because of the optical system (convex lens) between the user’s eyes and the display.
5.5.5.5  Display type 5.5.5.5.1 Needs HMD is considered for displays for VR content in this document.
5.5.5.5.2 Implementation The display type of VR content should be HMD based.
5.5.5.5.3  Evaluation method Check display type for HMD.
5.5.5.5.4 Remarks VR content display environment: screen, cave automatic virtual environment (CAVE), monitor, and HMD. Consider HMD VR on the simulators. Consider PC-based and standalone-type HMD.
35
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
5.5.5.6  Flicker optimization 5.5.5.6.1 Needs Flicker in VR content display directly affects eyestrain, but the cumulative effect can also increase VR sickness. 5.5.5.6.2 Implementation It is recommended to minimize the effect of flicker on VR screens due to graphic effects when producing VR content. 5.5.5.6.3  Evaluation method Measure the brightness of the entire screen of VR content. 5.5.5.6.4 Remarks Flicker may also occur that is associated with frame rate and vertical frequency synchronization. 5.5.6  Human factors and related parameters 5.5.6.1  Gender and age
5.5.6.2 Needs For evaluation of VRSL of VR content, gender differences and age groups are considered. 5.5.6.2.1 Implementation Reflect gender and age in the design and survey of motion sickness susceptibility questionnaire (MSSQ). 5.5.6.2.2  Evaluation method Check MSSQ sheet. 5.5.6.2.3 Remarks Identifying the personal information of subjects such as their living areas, educational status, race, etc could be helpful to understand their VR sickness level. 5.5.6.3  Prior experience 5.5.6.3.1 Needs Prior experience of subjects with VR content can have a significant impact on VR sickness assessment. 5.5.6.3.2 Implementation Consider whether subjects have prior VR experience and the degree of experience from MSSQ survey. 5.5.6.3.3  Evaluation method Check MSSQ sheet.
36
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
5.5.6.3.4 Remarks Consider the subjects’ health condition, including alcohol use, before VR sickness evaluation. The personal information of subjects can be managed for VR sickness response to the specific VR content. 5.5.6.4  Motion sickness susceptibility 5.5.6.4.1 Needs The sensitivity of motion sickness of users can have a significant impact on VR sickness assessment. 5.5.6.4.2 Implementation Consider user’s personal sensitivity of motion sickness in the MSSQ survey. 5.5.6.4.3  Evaluation method Check MSSQ sheet. 5.5.6.4.4 Remarks Identifying the personal information of subjects such as their living areas, educational status, race, etc., could be helpful to understand their VR sickness level. 5.5.6.5  Duration of VR experience 5.5.6.5.1 Needs The duration of exposure to VR content by users can have a significant impact on the VR sickness assessment. 5.5.6.5.2 Implementation Consider the strength of individual user’s endurance to VR content in the MSSQ survey. 5.5.6.5.3  Evaluation method Check MSSQ sheet. 5.5.6.5.4 Remarks Identifying the personal information of subjects such as their living areas, educational status, race, etc., could be helpful to understand their VR sickness level. 5.5.6.6  Controllability of VR sickness 5.5.6.6.1 Needs The degree of control that users have against VR sickness can have a significant impact on VR sickness assessment. 5.5.6.6.2 Implementation Consider personal VR sickness control level of VR content for MSSQ survey. 5.5.6.6.3  Evaluation method Check MSSQ sheet.
37
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
5.5.6.6.4 Remarks Identifying the personal information of subjects such as their living areas, educational status, race, etc., could be helpful to understand their VR sickness level.
5.5.7  Operational environment and related issues 5.5.7.1  Motion platform synchronization 5.5.7.1.1 Needs Asynchronous behavior between the visual experience and actual movement provided by VR content for motion-platform riders causes users to feel dizzy and uncomfortable.
5.5.7.1.2 Implementation For synchronization between physical movement and visual experience of motion platform boarding users, it is recommended that the transfer delay between VR input and VR motion output be less than 150 ms. Filter motion data based on the precision manufacturing of hardware (communications, motors, apparatus parts, etc.) to minimize transfer delay time and maximize precision and the entertainment elements in the VR content. For constructing motion data of motion platforms, prioritize the axial direction that is not reactive to the human body.
5.5.7.1.3  Evaluation method Use motion platform synchronization measurement software. After recognizing and adjusting the behavior of the motion platform rider, use measuring software to measure the time it takes for the motion platform to deliver the feeling to the user.
5.5.7.1.4 Remarks When motion platform and VR content are created separately, synchronization of motion is difficult because motion information of VR content did not transfer directly to the motion platform.
5.5.7.2  Vertical synchronization 5.5.7.2.1 Needs The frame of the VR content could be lagged or shuttered when the frame rate of VR content is higher than the refresh rate of the screen at vertical synchronization ON mode. It can cause user's eye fatigue and headache. The frame of VR content, however, may be torn at vertical synchronization OFF mode. However, we propose vertical synchronization mode OFF because HMD with 4K resolution or higher could overcome the tearing effect.
5.5.7.2.2 Implementation To optimize the drive of VR content, set vertical sync to off.
5.5.7.2.3  Evaluation method Use vertical sync on/off measurement software. Check vertical sync on/off.
5.5.7.2.4 Remarks If the frame rate of the VR content is below the screen interlacing rate, it becomes meaningless.
38
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
5.5.7.3  Clinical protocols 5.5.7.3.1 Needs To perform safety assessment when creating VR content, measuring subjective VR sickness levels should include measurement of various groups of subjects (age/gender). Based on clinical data, give appropriate consideration to balance subjective design intentions and objective production safety parameters for VR content.
5.5.7.3.2 Implementation It is recommended that the clinical subjects are considered in four categories: the male and the female youth, the male and female middle-aged. The number of clinical participants is calculated considering an elimination rate of 20%. Perform a preliminary vulnerability assessment using the MSSQ. The subjective level of VR sickness is recorded based on VR sickness symptoms in the simulation sickness questionnaire (SSQ).
5.5.7.3.3  Evaluation method Based on the VR sickness symptoms of the SSQ, the level of VR sickness experienced sustainably after watching the reference VR content is measured (Steps 1 to 5). Measure objective indicators that reflect a subject’s bio-signal and VR sickness sensitivity. Collect both pre-SSQ and post-SSQ from the clinical test, which must be approved by the clinical participants in advance.
5.5.7.3.4 Remarks Designing a simple, standardized, clinical protocol enables VR producers to easily assess the safety of their own content.
6.  VR sickness assessment 6.1 General
Clause 6 describes a framework for analyzing and predicting the degree of VR sickness that a user may experience while playing VR content.
6.2  General scope The VR reference content described in this framework contains various sickness-causing factors that can be used as variables to measure the degree of VR sickness. This framework also describes the methods and procedures for clinical tests that are designed to measure the user’s response subjectively and objectively. The framework also contains a set of questionnaires designed to evaluate the pre- and post-condition of the user, and it is given to the user before and after experiencing the VR reference content.
6.3  Use cases 6.3.1  Classification of users Users are categorized into several different groups according to their roles in relation to the scope of the standard for VR sickness assessment, as shown in Table 3.
39
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Table 3—Classification of users for human factor assessment
User
User’s role
Player
Playing VR content Subject for VRSL testing
Content designer
Designing visual scene and stages with best practices for controlling VRSL
Content programmer
Implementing rules and modules for VR content
System operator
Operating the clinical test system
VRSL evaluator
Analyzing subjective and objective components for predicting VRSL
VRSL data manager
Managing VRSL data
6.3.2  Use case 1: Evaluating VRSL
6.3.2.1 Overview
While the user is experiencing the VR content, the user is allowed to evaluate the VR sickness level using the bio-signal and the SSQ.
Figure 6—System block diagram for VRSL evaluation
6.3.2.2  Related users Player, system operator, VRSL evaluator, VRSL data manager 6.3.2.3 Pre-condition
— Prepare VR content for testing
40
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
— Set biomarker and bio-signal measurement equipment — Online SSQ — Define the number of VRSL 6.3.2.4  Event flow
— Acquire bio-signal from measuring equipment — Acquire SSQ data during the VR content play — Synchronize bio-signal with SSQ — Time-frequency analysis and correlation analysis — Frequency selection and feature extraction — Classify extracted feature data using deep learning method, etc. — Level VR sickness, monitoring — Notify VRSL 6.3.2.5 Post-condition
— Store VRSL data for the VR content and user — Notify VRSL 6.3.2.6 Requirements 6.3.2.6.1  Functional requirements
— Support of protocol and methodology for the evaluation of VRSL 6.3.2.6.2  Non-functional requirements Biomarkers: EEG (electroencephalography), ECG (electrocardiography), PPG (photoplethysmography), GSR (galvanic skin response) 6.3.3  Use case 2: Clinical trials 6.3.3.1 Overview While the user is experiencing the VR content, the user is allowed to evaluate the VR sickness level by utilizing bio-signals and SSQ data, which are acquired online.
41
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 7—Design tools of clinical trial for VRSL estimation 6.3.3.2  Related users System operator, content player, content designer, content programmer 6.3.3.3 Pre-condition
— Implement reference VR content — Design protocol for clinical trials — Design SSQ/MSSQ 6.3.3.4  Event flow — Play reference VR content — Acquire bio-signal and online SSQ data — Synchronize bio-signal with SSQ data 6.3.3.5 Post-condition Store bio-signals and online SSQ/MSSQ 6.3.3.6 Requirements 6.3.3.6.1  Functional requirements Support of clinical tests
42
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
6.3.3.6.2  Non-functional requirements Biomarkers: EEG, ECG, PPG, GSR 6.3.4  Use case 3: Cloud-based clinical tests 6.3.4.1 Overview We may want to conduct the clinical tests by exploiting cloud systems to accommodate large-scale subject populations scattered around various remote locations. This helps ensure that the large number of subjects generate meaningful analysis data when processed numerically, either by statistics or machine learning method, in analyzing the VR sickness levels experienced by the users in general.
Figure 8—Configuration of cloud-based clinical trials 6.3.4.2  Related users Content player, system operator, VRSL data manager 6.3.4.3 Pre-condition
— Set up client clinical trial environment — Set up server clinical trial environment — Download user’s VRSL data from server 6.3.4.4  Event flow — Initialize client/server database — Execute client system, start clinical trials, and estimate VRSL for VR content
43
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
— Upload VRSL data and users’ data from client to server system — Send VRSL data mining to server system for clinical tests 6.3.4.5 Post-condition
— Manage VRSL data — Analyze VRSL data 6.3.4.6 Requirements 6.3.4.6.1  Functional requirements Support of cloud-based clinical tests 6.3.4.6.2  Non-functional requirements Clinical test for more than 100 subjects
6.4 Scenarios 6.4.1  Scenario 1: FPS VR game in a walking attraction with VRSL estimation Users of VR content participate in a battle simulation game between multiple users while wearing personal protective clothing with haptic feedback functions in personal space in an attraction space for a gun-shooting game wearing the HMD. Users can walk while moving through the VR game. When gamers reach the boundaries of the designated game space, they will hear a warning sound and see a visual warning indicating the boundary. They can also move through the game stage using a jeep or ride an elevator to a higher floor. When players are shot, haptic feedback on the shooting is delivered through protective clothing. When moving through the game stage, or moving from left to right in a state of sudden head tracking, or moving left to right in a state of severe change of scene, users may feel severe dizziness and nausea. At this time, by presenting the nausea according to the severity of the change, the nausea can be reduced by allowing the gamer to predict the nausea in advance. Also, when moving to a higher place, the motion feeling of the height difference becomes serious due to the virtual feeling. At this time, it is possible to reduce the motion feeling by adjusting the viewing angle of the screen or presenting the visual guide. The variation of the VR sickness of each game stage experienced by the user is stored, and stored as the personalized information of the user. Cumulative changes of the user’s VR sickness are comprehensively determined to determine the sickness of the VR content. Update personalized VR sickness information about changes in the user’s rehabilitation of VR sickness.
44
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 9—FPS VR game in the walking attraction with VRSL estimation 6.4.2  Scenario 2: Roller coaster VR game on a motion platform with VRSL estimation VR content users will experience content that simulates a roller coaster. The motion platform is implemented based on the six degrees of freedom (6DOF). The user experience VR content in the watching mode while the HMD is mounted and the pre-configured contents are loaded on the motion platform without any additional navigation input of user. When riding a roller coaster in the real world or playing VR content with HMD, the user can experience similar motion sickness symptoms. The user experiences a sudden height change in the VR content. The VR user may experience severe VR sickness due to sudden changes in height and severe accelerating speed. On very fast curve travel content, the user may experience very severe VR sickness. Information about the user’s VR sickness is stored in the management information DB of the content that caused VR sickness. At this point, the user can be provided with a visual guide to reduce the VR sickness, or the VR sickness symptoms can be alleviated in all of the content by adjusting the constant velocity motion to better reflect the image, and moderating the sudden fluctuations of the image.
Figure 10—Roller coaster VR game on the motion platform with VRSL estimation
45
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
6.5  Framework of assessment for VR sickness 6.5.1 Overview The evaluation and assessment framework for the VR sickness of VR content includes a framework for quantifying the correlation between human factor parameters of VR content and VR sickness. Human factor parameters for VR content that affect VR sickness include: HMD that present VR content, VR content itself, user elements that reflect the cognitive characteristics of users, environment to drive VR content, and technical elements for obtaining VR scene images. A subjective and objective analysis method should be applied to assess the correlation between human factor parameters for VR content and VR sickness. Objective analytical methods include taking advantage of changes in user biometric information, or directly considering changes in VR content images. Subjective analysis methods can proceed in a survey format for user responses to VR content, and question the user’s responses before, after, and during the experience of VR content. VR sickness is calculated step by step with sickness levels, according to the compilation of each symptom for VR sickness.
Figure 11—Relationship between human factor parameters and VR sickness symptoms for the evaluation of VR sickness
6.5.2  Framework of clinical tests for VR sickness estimation The evaluation and analysis framework for VR sickness and fatigue of VR content includes a framework for quantifying the correlation between the human factor parameters of VR content and the VR sickness symptoms. The clinical measurement framework for predicting VR sickness should include the following components:
— How to configure reference VR content — Criteria for classification of stimuli presented to the user — System parameter components — Subjective evaluation methods and procedures — Objective evaluation methods and procedures — How to deploy and validate a clinical trial database — Correlation analysis methods and procedures for VR sickness
46
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
— Methods and criteria for calculating VR sicknesses — Clinical trial configuration and testing methods for VR sickness assessment and analysis — How to configure and measure a user’s VR sickness survey
In order to test and measure VR sickness, an objective standard for measuring changes in VR sensitivity through image configuration of VR content needs to be established and produced by reference. Through the scene configuration of VR content, a standard should be provided to measure the level of VR sickness in VR content stages from minor to strong VR sickness that causes serious dizziness and vomiting. VR content should be implemented that reflects these criteria. It can be used as a reference content in the form of a case study by utilizing existing VR content. The criteria for classification of stimuli presented to the user must be reflected in the implementation of reference VR content. We need to be able to use these classification criteria to distinguish between objective measures of VR sickness. The elements included in the system parameters may include elements related to VR content, elements related to the display unit of VR content, cognitive/psychological elements related to user personalization, and elements related to the experienced environment of VR content and the acquisition of VR content images. The system parameter components for evaluating and analyzing the level of VR sickness in VR content are handled according to objective and subjective evaluation methods. The data used as a subjective method for evaluating and analyzing VR content can be directly surveyed by users who reflect the subjective opinions of users. Subjective evaluation procedures can be conducted before, after, and during the experience of VR content. Data used for objective evaluation and analysis of VR content can come from the biometric signals of the user measured in the process of experiencing VR content. In addition, separate metrics can be defined to account for the changes in the VR content images themselves. Clinical trial databases produced based on subjective or objective evaluation and analysis results can be accumulated. Reference databases can be built through validation of this database. Methods can be applied to quantify the correlation between the system parameter components and the symptoms of VR sickness experienced by users, and procedures can be defined. Statistical methods, use of machine learning algorithms, etc., can be applied as a method of correlation analysis. It should be possible to provide a baseline for VR sickness by comprehensively determining the correlation between system parameter components and VR sickness. This is defined as VR sickness level, and the scope of application of VR sickness level can be used as a basis for evaluating the whole VR content and for evaluating each stage or scene of VR content. In order to assess and analyze VR sicknesses caused by VR content, the composition and testing methods of clinical trials must be defined. Users who create clinical trials must obtain permission from the institutional review board (IRB), an independent standing committee that can review and approve research plans to ensure the ethical and scientific aspects of the study. IRBs look after the rights, safety, and well-being of those involved in clinical research.
Reflecting a user’s personal characteristics is an essential element of assessing and analyzing the sensitivity to VR content, and reflecting the user’s sensitivity to VR sickness and past experience values enables more sophisticated analysis and interpretation of clinical trial results. A definition of criteria for assessing VR sickness specific to VR content is required for survey assessment that is the basis for research on measuring VR sickness.
47
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 12—Framework for the analysis and evaluation of VR sickness The clinical measurement framework for predicting VR sickness includes measurement tools for analyzing and assessing VR sickness. Measurement tools for analyzing and evaluating VR sickness include tools for implementing reference VR content, clinical protocol design tools for clinical trials, questionnaires for assessing users’ VR sickness, and database deployment tools for clinical trial results. In addition, in order to measure objective user responses, biometric signal information, such as changes in the user’s brainwave signal, skin conductivity, and potential for gastrointestinal changes, are measured. Measuring devices and measurement data analysis tools that perform evaluation analyses of these biological signals are utilized. Based on the design of these clinical trial protocols, clinical trials based on cloud clinical trial environments can also be structured as a way to build and acquire clinical trial data for large users. 6.5.3  Functional and performance requirements of reference content 6.5.3.1 Overview Reference VR content is used for clinical tests in order to acquire the necessary measurement data used for assessing the VR sickness levels of a given VR content. It should be possible to demonstrate an implementation method to distinguish the scene changes of the underlying VR content in order to measure the step-by-step intensity of VR sickness level the users experience while playing VR. For our clinical test purposes, the reference VR contents are categorized into primitive and scenario content.
48
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
6.5.3.2  Primitive content 6.5.3.2.1  Parameters affecting VR sickness
Figure 13—Parameters affecting VR sickness Primitive content identifies itself by a designated value of a certain VR content parameter. Thus, it is supposed to own a unique VR sickness level determined by the parameter value. Individual VR content parameters that affect VR sickness are extracted from the VR content and exploited to derive the correlation between VR content parameter values and VR sickness levels. The composition of the primitive content can be defined as the type of parameter and the value of each parameter. Here, the types of parameters include the direction/ speed/acceleration of virtual cameras applied when constructing scene images of VR content, the direction/ speed/acceleration of objects that make up scene images of VR content, object counts, viewing angles, and visual guides, etc. The combination of these VR content parameter values constitutes the primitive content, and in these combinations the refined measurement methods can be constructed by extracting high contributions to VR sickness experienced by the user. 6.5.3.2.2  Composition of primitive contents The primitive content can be generated systematically by varying a specific parameter value in a step-wise manner. Also, the individual primitive content could be laid out randomly for a reference content composition used in a clinical test session. If the VR sickness is defined in three levels, it can be configured as weak/normal/ serious. Primitive content can be composed as follows: The first part of each shot (Bg1) is the section where the clinical test subject of the VR content is required to be prepared. The latter part of each shot (Bg2) is the feedback time for the subjects’ scoring on VR sickness levels. The overall length of action (Action) for the primitive content shown is held for about 10 seconds, for example. Clinical trial protocols can define how the clinical trials to VR content users for primitive content. These criteria can be defined to assess and analyze the user’s VR sickness level in reference to VR content.
49
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 14—Configuration of primitive content
Figure 15—Clinical trial protocol for primitive content
6.5.3.2.3  Naming of primitive content
A naming convention could be used for identifying the individual primitive contents by themselves in a clinical test environment, and this is explained in Table 4.
Table 4—Naming convention of the primitive contents
Naming
Actions
OM
Object movement
CM
Virtual camera movement
H
Horizontal direction (left and right)
X
Diagonal direction
FB
Forward and backward movement
UD
Up and down movement
RR
Rotation of rolling direction
Table continues
50
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Table 4—Naming convention of the primitive contents (continued)
Naming
Actions
RP
Rotation of pitch direction
RY
Rotation of yaw direction
Vz
Display visual guide
G
Adjust field of view (goggling effect)
6.5.3.3  Scenario content
6.5.3.3.1  Major genre of scenario content
Scenario content is identified by designated multiple values of a certain set of VR content parameters. Thus, it is supposed to own a unique VR sickness level determined by a set of parameter values. VR game contents are examples. More specifically, VR games having typical levels of scenario content are drone shooting or car driving VR game content. Scenario content will be tested and analyzed for combinations of VR content parameters within VR content that affect VR sickness. Through clinical trials of scenario content, VR sickness assessments are conducted on the individual VR content parameters identified in the primitive content.
Figure 16—Scenario content
6.5.3.3.2  Composition of scenario contents The configuration of the scenario content can consist of a stage with a level of VR sickness, and a stage can be placed in an increasing sequence of VR sickness levels. In addition, clinical trials can be performed several times with each stage of the VR sickness level. In the scenario content, before performing a stage of the VR content for measuring VR sickness, a stopped shot can be shown in the form of a cross in the middle of the blank screen to represent the pausing period.
51
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 17—Configuration of scenario content In the clinical protocol of the scenario content, several identical iterations can be performed. It is also possible to order the delivery of VR content in such a way that the scene of the same VR content is repeated and presented to the subject.
Figure 18—Clinical trial for scenario content Scenario content will define how VR content will be operated to reflect a combination of many single VR content parameters applied by the primitive content. As an example of the scenario content, VR sickness levels can be divided into three stages (S1, S2, S3) for both drone riding and flying shooting game content. The level of VR sickness in S1 is low, and scene images of VR content may consist of the appearance of a single-captain aircraft and shooting image stage. In S2, VR sickness levels can be defined as a middle level, and scene images of VR content can be composed of multiple appearances of enemy flights and shooting images. In the S3 stage, the level of VR sickness in VR content is high, and scene images in VR content can be composed of spatialmoving images in drones. 6.5.3.3.3  Correlation between primitive content and scenario content Figure 19 shows the correlation between the primitive content and the scenario content. In primitive content, VR content can be configured to reflect changes in individual VR content parameters of object movement (OM) and virtual camera motion (CM) within the scene image of VR content. It can also reflect cases of horizontal movement (H, X, FB, UD), rotational movement (RR, RP, RY), and design changes in dynamic VR content in a variety of cases, such as presence of visual guide (Vz) and visual angle adjustment (G). Each shot (Pi) of VR content can be organized and presented to users by ordering primitive content. In order to organize scenario content, the shots (Pi) of appropriate primitive content will be used depending on the VR content
52
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
of the drone shooting or driving genre. Reference VR content should be produced according to the scenario content configuration method, which reflects the characteristics of each genre of the content.
Figure 19—Correlation between primitive content and scenario content 6.5.4  Functional and performance requirements of clinical test protocol 6.5.4.1 Overview Reference VR content is prepared for clinical trials first in order to perform clinical trial protocols. It also completes the selection of VR-driven hardware and installation of a user’s biometric device. Clinical trials are conducted on actual users. The clinical test protocol defines these procedures. In general, VR sickness sensitivity by individual users is measured through the questionnaire prior to clinical testing. In addition, the prepared reference VR content are operated separately for each primitive content, scenario content, and session, and then the user is asked to conduct a survey on VR sickness felt. After completing each session survey, appropriate break times are allocated to avoid VR sickness being miscorrelated to new content. 6.5.4.2  Composition of clinical tests 6.5.4.2.1  Preparation for clinical tests Figure 20 shows typical preparedness as a design for clinical trial protocols. Explain to the subjects the sessionby-session configuration and clinical trial procedures of each VR content for clinical trials, and conduct a survey on users’ prior experience and sensitivity to VR content at appropriate times. Set up a measurement environment for clinical trials, and set up a measuring device.
53
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 20—Typical preparation of clinical trial 6.5.4.2.2  Repetition intervals of clinical tests Typical configurations of clinical trial protocols are as follows: Conduct a session of VR content per clinical test, and then survey users’ VR sickness response. The inclusion of resting time between sessions in the clinical trial minimizes the mutual impact between the clinical trial sessions. The resting time also minimizes the cumulative effects of VR sickness as a clinical trial session is conducted. For future analysis, measurement data are stored for each session of the clinical trial for VR sickness levels.
Figure 21—Repeat intervals at clinical trial 6.5.4.2.3  Clinical tests with bio-signal measurement Figure 22 illustrates the configuration of clinical trial protocols, including bio-signal measurements, such as brainwave. Users are required to complete the preparation process of the experiment and the consent form of the experiment before entering the clinical trial, and to conduct basic VR content driving practice. Figure 22 also shows advanced measures for setting up the device environment and for measuring bio‑signals. During the clinical trial, VR content is driven in the order of primitive and scenario content after a resting time to the user’s bio-signal response. Users can minimize the cumulative effect of VR sickness by adding a break time in the middle. The operation of the overall VR content is repeated twice, so that it can be utilized as a verification method for the integrity of the measured data.
54
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 22—Clinical trial with bio-signal measurement 6.5.4.3  Environment of clinical tests 6.5.4.3.1  Operational environments of clinical tests Figure 23 illustrates the measurement environment of clinical trials, such as users’ biometric signal measurement and eye-tracking functions, among clinical test environments, including brain waves. Figure 24 shows a clinical trial being conducted and a subject of the clinical trial being tested. Examples of clinical trial progress are shown, including clinical test measuring devices and measurement environments.
55
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 23—Measuring environment for bio-signal
Figure 24—Operational environments for clinical trial 6.5.4.3.2  Visualization for analyzing system parameters and bio-signals Figure 25 shows a visualization of changes in system characteristic parameters that affect VR sickness as VR content are driven.
56
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 25—Visualization results for system parameters Figure 26 shows the visualization of a user’s biological signal changes as a result of the operation of VR content as data results of a clinical trial.
57
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 26—Visualization results for bio-signal 6.5.4.4  Issues to consider in designing clinical test protocol Consider the following when designing clinical trial protocols. Establish steps for the level of VR sickness in clinical reference VR content by defining the degree of VR sickness. For instance, three steps can be distinguished as weak, normal, and severe. VR sickness scores can consist of five levels, 1 (moderate) to 5 (severe). For measuring scores for VR sickness levels, the subject VR content should be able to provide specific ways to display their VR sickness levels. Additional time factors should take into account the electrode
58
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
attachment time of the biometric device for measuring the user’s biological signal (additional 30 minutes for measuring biological signals, such as brain waves). Prevent clinical test subjects unfamiliar with clinical testing methods from not responding to the first few stimuli of VR sickness. Single stimulation of the image information experienced by the user of VR content is at least 10 seconds, and screens during clinical trial breaks are maintained for at least 5 seconds. Stimulation order for the user to experience scene information of VR content is not recognized by the user who is the subject of clinical trials.
6.5.5  Functional and performance requirements of questionnaire for clinical tests
6.5.5.1 Overview
Clinical trials will generate measurement data for VR sickness levels. This VR sickness level data measures the response of VR sickness through the questionnaire of users who are clinical test subjects experiencing VR content. In the course of clinical trials, the assessment modeling of VR sickness levels based on cognitive physiology is an essential part of the process.
6.5.5.2  SSQ design
Through SSQ surveys, we will test stimuli for VR content, i.e., through surveys by users on VR sickness symptoms after experiencing VR content, and conduct scoring that reflects VR sickness levels (Kennedy et al. [B10]).
6.5.5.3  MSSQ design
The MSSQ conducts a survey on personalized information, including demographic information, VR content experience, and motion sickness sensitivity, before examining clinical trials. Users who are the subjects of clinical trials must be approved by the IRB before clinical trials are conducted. IRB approval is valid for one year from the date of approval and the results of the clinical trial shall be reported (Golding [B4]).
7.  Motion-to-photon latency
7.1 Measurement
7.1.1 General
Subclause 7.1 describes the measurement system for motion-to-photon latency. A sample latency measurement model is described. The model generates an accurate movement of the HMD and measures the movement using high-accuracy encoders and motors. A photosensor detects the luminance of the changed image and calculates the latency between the two events.
7.1.2  General scope
Subclause 7.1 describes main factors that affect motion-to-photon latency. Specifically, the quantified and hardware architectures for measurement are described in the following sections.
7.1.3  Motion-to-photon latency measurement model
Motion-to-photon latency refers to the difference between the starting time point of the head motion to a new orientation and the time point when the matching image on the display of the HMD system is generated. Figure 27 shows the overall process of the image rendering in an HMD system. First, the physical head movement occurs, and the head position is measured using an inertial measurement unit (IMU) and camera sensors. Then, a tracker device transmits the pose data to a PC via a universal serial bus (USB) connection. The PC generates frame buffers using the GPU. Finally, a new image is output to the display of the HMD system. In this case, each module has a latency, and the total summation of the latencies in the whole process is called the motionto-photon latency.
59
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 27—Overall process for the image rendering Subclause 7.1.3 describes an example of the motion-to-photon latency measurement model (Seo et al. [B11]). Figure 28 shows a conceptual architecture of the latency measurement model. This model largely consists of a control PC, a head position model-based rotary platform, a pixel luminance change detector, and a digital oscilloscope.
Figure 28—Conceptual architecture of the latency measurement model This architecture includes the control PC to control and analyze the measured signals. The rotary platform in this architecture models a head movement using the high-accuracy encoders and motors. The pixel luminance change detector measures the luminance change in the HMD display. The oscilloscope measures the voltage values for the changed luminance. 7.1.3.1  Head position model-based rotary platform Figure 29 shows an example of the photosensor-based latency measurement system. This platform fixes the HMD device in the top plate and changes the position using motors and encoders.
60
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 29—An example of photosensor-based latency measurement system: (a) yawdirection encoder, (b) pitch-direction encoder, (c) HMD system, and (d) plate holding the
display of the HMD system The first encoder (Figure 29[a]) measures the rotation angle of the yaw direction. The second encoder (Figure 29[b]) measures the rotation angle of the pitch direction. The top plate (Figure 29[c] and [d]) fixes the HMD system. This place includes the pixel luminance change detection. Specifically, the detailed operation is as follows. First, the head movement scenario is inputted into a control PC. Then, the movements in the several directions are performed, and the position of the HMD system is also changed. At the same time, encoders generate phase signals based on each movement, and the physical movement is detected. 7.1.3.2  Pixel luminance change detector Figure 30 shows the overall architecture of the pixel luminance change detector. Four photosensors detect the directions in front of the HMD panel (Figure 30[a]). The HMD panel (Figure 30[b]) outputs the images, and a chamber connects the photosensors and the panel (Figure 30[c]). An individual pixel luminance change detector prevents external light from entering, as shown in Figure 31. The light is emitted from the panel, and the photosensor uses its light. The pixel luminance change is very small as it enters the chamber.
Figure 30—Pixel luminance change detector: (a) photosensor, (b) HMD panel, and (c) chamber
61
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 31—Cross-sectional diagram of an individual pixel luminance change detector The concept of the pixel luminance change measurement method is described in Figure 32. The image movement is represented by on-off pixels because the display uses two-dimensional pixels. The on-off operation in a pixel is changed by frame. A voltage is measured using the changed luminance in the photosensor, and this voltage is measured. Therefore, the motion-to-photon latency is measured.
Figure 32—Operational process of the pixel luminance change measurement method 7.2 Network 7.2.1 General Subclause 7.2 describes network requirement and system specifications to reduce VR sickness when designing and implementing network configuration. 7.2.2  General scope Subclause 7.2 describes the use case scenarios of VR systems that deliver either a single or a multi-user content through the existing networks with certain capabilities. It also describes the network issues and the limitations for providing the optimal VR user experience when the wired link is replaced by a wireless link. The highlevel network requirements are also identified with a gap analysis and the need for further standardization is discussed.
62
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
7.2.3  Use cases 7.2.3.1  Case 1: A single VR system connected via a local area network (LAN) A user is playing a VR game using a VR HMD connected to a game console system with high definition multimedia interface (HDMI) and USB cables. The HDMI cable is delivering both video and audio for the VR game that are rendered in real time by the game console to the VR HMD. The USB cable is delivering the head-tracking data from the VR HMD to the game console to reflect the user’s head position, so that the game console can render both the video and the audio of the VR game accordingly, in real time. Figure 33 is a logical network connectivity diagram of the above use case scenario in which the VR HMD is communicating with a local content server (e.g., a PC or a gaming console) via a LAN. The VR content service is rendered or decoded in the local content server.
Figure 33—A single VR system connected via a LAN
7.2.3.1.1 Issues/limitations The user mobility is limited due to the HDMI and the USB cables connecting to the VR HMD and to the local content server. 7.2.3.1.2 Recommendation To increase the user mobility while playing a VR game, the wired LAN needs to be replaced with a wireless LAN. Since HDMI 2.0 cable is a fully dedicated and stable wire that can transfer 18 Gbps with less than 1 ms of latency, the wireless LAN that replaces the HDMI cable should be able to match the same conditions to support this use case scenario. 7.2.3.2  Case 2: A single VR system connected via a WAN A user is watching a baseball game in a virtual reality environment using a mobile phone–based VR HMD system. The baseball game in this scenario is being captured with a 360-degree camera and it is being streamed to the VR HMD in real time. The head-tracking data is also transferred to the camera via a mobile network to display the view where the user is looking. Figure 34 is a logical network connectivity diagram of the above use case scenario in which the VR HMD is communicating to a remote content server (such as to a cloud service provider) and receiving the VR content service via a wide area mobile network. In this scenario, the VR content service is rendered or decoded in the remote content server. It is important to note that the remote content server is located outside the local network and WAN consists of both wired and wireless networks.
63
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 34—A single VR system connected via a WAN
7.2.3.2.1 Issues/limitations Since the content server is located outside the local area, and the content data is traversing through multiple networks, network latency is an important factor that will vary depending on network conditions. The increased latency may cause the poor video resolution quality and reduce the frame rate (e.g., due to network congestion). This drop of video quality results in VR sickness. 7.2.3.2.2 Recommendation In order to maintain the optimal VR user experience, it is recommended that the video resolution quality remain as high as possible with a constant data transmission rate of 90 fps. As the current commercial VR HMD supports the display resolution up to quad high definition (QHD, 2560 × 1440) and frame rate up to 90 fps, the data transmission rate, which is calculated using the following equation, data transmission rate = resolution × 24 bit (color) × frame rate is roughly 8 Gbps uncompressed. Hence, the end-to-end network (wired backbone and wireless access) should be capable of transferring 8 Gbps of uncompressed data to support the use case scenario. 7.2.3.3  Case 3: Multiple VR systems connected via a LAN A user is playing a virtual reality game and competing against other remote players using a VR HMD system that is connected to local server (e.g., a PC or a laptop). An HDMI cable connects the VR HMD system, a local server is used to receive the video and audio data of the VR game content, the service of which is being rendered in real time in the local server. A USB cable connects the VR HMD, and a local server is used to exchange the head-tracking data so the server can render the video and audio data accordingly. The remote content server is calculating the scores and the consequential data caused by the remote users’ input. These data are sent to the local content server so it can render the video and audio of the VR game content accordingly. Figure 35 is a logical network connectivity diagram of the above use case scenario where multiple VR systems are connected to a remote content server. The VR HMD is receiving the VR content service rendered or decoded in the local content server. The remote content server is computing the data sent by the local content servers and redistributing the calculated data back to the local content servers.
64
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 35—Multiple VR systems connected via a LAN
7.2.3.3.1 Issues/limitations The user mobility is limited due to the HDMI and the USB cables connecting to the VR HMD and to the local content server. The network between the remote content server and the local content servers may create some additional latency depending on network conditions. The increased latency may cause improper change of content and may create an incorrect impression of certain events of the game. Also, it may drop the video quality and the frame rate. This drop of video quality results in VR sickness. 7.2.3.3.2 Recommendation The wireless LAN connecting the VR HMD and the local content server should be capable of delivering the required bandwidth that VR content data demands, and the link between the two should be always maintained. The WAN connecting the remote content server and the local content servers should provide very low latency to reflect the real-time changes made in VR content according to the users’ input. 7.2.3.4  Case 4: Multiple VR systems connected via a WAN Two or more users are watching a live streamed video game match from their respective homes using their mobile phone–based VR HMD systems. The users are watching the same content in a virtual movie theater rendered by a cloud service provider and the users are being represented as virtual avatars in the virtual reality theater. They are able to interact with each other and also can communicate via audio. The live-streamed video game match and the virtual reality theater are all being rendered in a remote server situated in the cloud service provider network and the VR HMD system is only running a small application for obtaining the cloudrendered VR content. Figure 36 is a logical network connectivity diagram of the above use case scenario where two VR HMD systems are communicating to the remote content server and receiving the VR content service rendered or decoded in the remote content server.
65
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 36—Multiple VR systems connected via a WAN 7.2.3.4.1 Issues/limitations The network between the remote content server and the VR HMD systems may add additional latency to the content delivery depending on the network conditions (e.g., due to congestion). This increased latency may affect the real-time effect in the content delivery, that in turn may create an incorrect impression about the change of events. In addition, it may drop the video quality and the frame rate. This drop of video quality results in VR sickness. 7.2.3.4.2 Recommendation The network connected to the remote content server where the VR content is being rendered or encoded should have the required (e.g., 8 Gbps for uncompressed QHD resolution video) data throughput to send high-quality video and audio data with required frame rate (e.g., 90 fps) to the remote VR HMDs. In addition, the network should provide very low latency to reflect the real-time changes made in VR content according to the users’ input. 7.2.3.5  Case 5: Special use case—change of network A user is watching a streamed movie using a mobile phone–based VR HMD while travelling in a bus or a train. The movie is encoded in the remote server and sent to the VR HMD system via a wide area network. The VR HMD system is only decoding the content sent by the remote server. Figure 37 is a logical network connectivity diagram of the above use case scenario where the VR HMD system is connected to either the bus or train with an IEEE 802.11™ wireless network or connected directly to the mobile network, depending on network conditions. Therefore, the network connection is switched between two local access networks that lead to a network handover condition.
66
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 37—Special use case—change of network 7.2.3.5.1 Issues/limitations As the mobile network offers a limited amount of data usage depending on the personal mobile data plan, users normally prefer to use an IEEE 802.11 wireless network when it is available. When the network connectivity moves from mobile network to wireless network, a network handover occurs and causes a drop of data, also known as a data cliff, shown in Figure 38.
Figure 38—Data cliff When this data cliff occurs, there is a good chance that the data header file of the application that contains the data packet structure will be lost. When the header file is lost, the network needs to resend the entire data packet, and this creates additional latency. This increased latency may drop the video quality and the frame rate, resulting in VR sickness. 7.2.3.5.2 Recommendation When the above handover results in moving from a higher throughput to a lower throughput network, the data cliff can be avoided if there is a way to make the network switching smooth, as shown in Figure 39.
67
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Figure 39—Alleviation of data cliff phenomenon
When the network handover occurs, moving from the faster network to the slower network, maintaining both the high frame rate and the high resolution for the VR content may not be possible. In this case, maintaining the high frame rate needs to be considered as a higher priority, as the frame rate is more critical to VR sickness. 7.2.4  Requirements and capabilities 7.2.4.1 Requirements In recent years, VR sickness caused by VR content service is considered a major problem for VR industry. For VR HMD to be accepted as a mass-market device, VR sickness needs to be addressed. To address this problem, several standards organizations—such as the IEEE 802 (IEEE P802.11-2015/0625r7 [B5]), MPEG (Champel et al. [B2]), and 3GPP (ITU-R M.2083-0 [B9])—have identified both network and non-network related issues and functional requirements in their studies. It is evident that VR industry needs new network requirements for the connectivity between the content server and the HMD device. These requirements are, for example, higher frame rate, reducing the motion-to-photon latency, higher data transmission rate, low jitter, longer transmission range, better mobility, higher resolution, and low packet error rate. A few such important requirements are highlighted as follows:
a) Peak data rate — Peak data rate should be 2.25 Gbps for compressed 4K UHD 3840 × 2160 24 bits/pixel, 90 fps, 8 bits/color. — Peak data rate should be 12 Gbps for compressed 8K UHD 7680 × 4320 24 bits/pixel, 90 fps, 8 bits/ color. — Peak data rate should 27 Gbps for uncompressed 4K UHD 3840 × 2160, 90 fps, 8 bits/color, (4:4:4) chroma subsampling. — Peak data rate should be 4 Gbps for uncompressed 8K UHD 7680 × 4320, 90 fps, 8 bits/color, (4:2:0) chroma subsampling. — The above values are obtained based on the calculation in IEEE P802.11-2015/1074r0 [B6].
b) Jitter — Jitter should be less than 5 ms (IEEE P802.11-2015/0625r7 [B5]) since greater jitter can cause distortion in video and audio rendering.
c) Transmission range — For an indoor environment, it should not exceed 5 m by 5 m. — For an outdoor environment, it may reach up to several hundred meters.
d) Mobility of device and session
68
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
— For an indoor environment, it should be less than 4 km/h.
— For an outdoor environment, it may reach up to 300 km/h.
— Packet loss for session mobility during network handover should be as small as possible.
e) Packet error rate (PER)
— PER should be less than 10−2.
— This PER is the value before any error correction.
f) Resolution
— The required resolution is 40 pixels/degree or 12K (11 520 × 6480) (Champel et al. [B2]).
— While 4K UHD (3840 × 2160) seems to be sufficient for the current display technology, higher than 4K UHD is required. This is because HMDs are mounted very close to human eyes and displays tend to be enlarged.
g) Frame rate
— 90 fps
It is important to note that the frame rate is directly related to motion-to-photo latency. A lower frame rate allows a user’s reaction to be rendered in HMD after a reciprocal of the frame rate. The lower the frame rate is, the more it can cause fatigue and motion sickness. The total motion-tophoton/audio latency in the VR system should be less than or equal to 20 ms (ITU-R M.2083-0 [B9]). The motion-to-photon latency for wireless medium should be less than 5 ms, i.e., between two wireless transceivers (IEEE P802.11-2015/1074r0 [B6]).
h) QoE
— QoE is a measure of the overall level of users’ satisfaction with a VR system. QoE is related to, but differs from, QoS, which refers to any technology that manages data traffic to reduce packet loss, latency, and jitter on the network transport of a VR system. QoS constitutes only the network portion of the QoE, but QoE will be measured by the user. QoE is something that VR system or content developers must take into account to offer a high-quality user experience. Table 5 illustrates the QoS-related conditions that need to be considered for each use case described in 7.2.3.
Table 5—Relation between use cases and network requirements
Network requirements
Use case
Data transfer
rate
Motion-tophoton/audio
latency
Jitter
Transfer range
Mobility
PER
1. Single VR system via LAN
●
●
●
●
○
●
2. Single VR system via WAN
●
●
●
◐
●
●
3. Multiple VR system via LAN
●
●
●
●
○
●
4. Multiple VR system via WAN
●
●
●
◐
●
●
5. Network mobility
○
●
●
○
●
●
strong: ●, moderate: ◐, weak: ○
7.2.4.2 Capabilities
Today’s most immersive virtual reality systems rely on tethering for power and sending high-fidelity imagery to the headset. However, a dangling cable not only causes an inconvenience to users, but also becomes an immersion detractor. The demand for a solution to this issue has spurred a series of new developments for a wireless access link between the server and the HMD or headset. The biggest caveat is that most powerful VR prototypes are inevitably needed to be wired with cables due to the amount of transmitted high-resolution
69
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
video at high frame rates. The wired connections, such as HDMI 2.0 and DisplayPort 1.3, already provide transmission data rates of 18.0 Gbps and 32.4 Gbps, respectively, with very negligible transmission delay. On the other hand, a wireless link between the content server and the HMD can provide the needed mobility for the user and solve the tethering problem. It is our belief that as the wireless transmission technologies evolve, their performance will come close to a point when the wireless link can replace the wired link without severe performance degradation. However, there are some limitations in the technologies that are currently under development.
A few technologies that can be further studied and enhanced to fulfill the needs of the VR HMD industry are listed. There are several wireless transmission technologies that are applicable to wireless VR HMDs today. Some technologies are already standardized, and some standards are still under development.
— IEEE 802.11ax™ The High Efficiency WLAN (HEW) Task Group has started developing IEEE 802.11ax with a main goal of reducing the performance degradation in a dense area of wireless networks. IEEE 802.11ax accomplished Draft 2.0 in November 2017. The standard was approved by the IEEE SASB in February 2021. IEEE 802.11ax, which achieves data transmission rates four times higher than IEEE 802.11ac™, is designed to operate in 2.4 GHz and 5 GHz spectrums. Through increased link efficiency in frequency domain, time domain, and modulation scheme, the IEEE 802.11ax technologies can achieve as high as 12.01 Gbps in an ideal condition (IEEE P802.11ay™ [B8]). At the current development state, this technology does not satisfy the VR network considerations.
— IEEE 802.11ay To develop the follow-up to IEEE 802.11ad™, IEEE 802.11ay was formed in May 2015 to achieve a maximum throughput of at least 20 Gbps using the unlicensed mm-Wave (60 GHz) band, while maintaining or improving the power efficiency per station. They completed Draft 1.0 in January 2018. The standard was approved by the IEEE SASB in March 2021. IEEE 802.11ay can provide a high throughput utilizing various technologies, such as channel bonding/ aggregation, MIMO, multiple channel access, etc. (IEEE P802.11ay™ [B8]). At the current development state, the maximum throughput is satisfied, but it needs to consider device mobility due to the directional propagation of electromagnetic waves in the 60 GHz band.
— 3GPP To reach a fully interconnected VR world, the VR HMD needs to be mobile even in an outdoor environment beyond the communication range of IEEE 802.11. The only technology that can provide that kind of accessibility is through the LTE, one of the 4G technologies, but the data transmission speed is not fast enough to provide proper operation for a standalone HMD in outdoor environments. 5G, deployed in 2018 (Do [B3]) and beyond, can be a most-favorable candidate for nomadic HMD users. The 3GPP completed a technical report on VR services over 3GPP in September 2017 (3GPP Technical Report 26.918 [B1]).
7.2.4.3  Gap analysis
In this subclause, the capabilities of wireless transmission technologies are compared with respect to the requirements of a wireless VR HMD system. This comparison will facilitate the understanding of what enhancements are needed to satisfy the current requirements of wireless VR HMDs.
70
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
NOTE—Requirements, such as resolution and frame rate, which cannot be directly satisfied by the transmission technologies, are omitted in this comparison.4
Table 6—Requirements and capabilities for VR HMDs
Capabilities
VR HMD requirements
IEEE P802.11ax [B7]
IEEE P802.11ay
[B8]
ITU-R M.20830 [B9]
Data transmission rate
~ 20 Gbps (IEEE 802.11 [B5])
~10 Gbps (at least 4 times improvement over IEEE 802.11ac)
~100 Gbps
20 Gbps peak, 100 Mbps userexperience data rate
Latency
“A desirable
~ 5 ms (at wireless medium) level to meet QoS
(IEEE 802.11 [B5])
requirements
20 ms (motion-to-photon/ in high dense
10 ms
1 ms
audio) (Champel et al. [B2]) deployment
scenario”
Jitter
< 5 ms (IEEE P802.11 [B5]) Not specified
Not specified Not specified
Transmission Indoor 5 m (IEEE P802.11 [B5])
range
Outdoor Several hundred meters
Not specified
10 m indoor Not specified
100 m outdoor
Mobility
Indoor Outdoor
Pedestrian speed < 4 km/h (IEEE P802.11 [B5])
200 km/h
Not specified
3 km/h
500 km/h
PER
10−6 (IEEE P802.11 [B5]) Not specified
~10−8
Not specified
From Table 6, it is clear that none of the existing IEEE 802 or other technologies can fully satisfy the network requirements for VR industry.
7.2.5 Summary
As mentioned in gap analysis, at this moment none of the developed or developing wireless transmission technology standards meet the network requirements to offer a high-quality user experience in VR. IEEE 802.11ax and IMT-2020 both fall short of the required data rate, and IEEE 802.11ay does not provide a latency small enough for a high QoE. All other network requirements, such as jitter, transfer range, mobility, and PER, seem to be satisfied. Therefore, to achieve a high QoE a new wireless transmission technology is needed which provides both a high transmission data rate of 20 Gbps or beyond, and a small latency of 5 ms or below, at least in the network portion of the QoE.
4Notes in text, tables, and figures of a standard are given for information only and do not contain requirements needed to implement this standard.
71
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 3079-2020 IEEE Standard for Head-Mounted Display (HMD)-Based Virtual Reality (VR) Sickness Reduction Technology
Annex A
(informative)
Bibliography
Bibliographical references are resources that provide additional or helpful material but do not need to be understood or used to implement this standard. Reference to these resources is made for informational use only.
[B1] 3GPP Technical Report 26.918, Virtual reality (VR) media services over 3GPP, 2017.
[B2] Champel, M., T. Stockhammer, T. Fautier, E. Thomas, and R. Koenen, “Quality requirements for VR,” 116th MPEG Meeting of ISO/IEC JTC1/SC29/WG11, Chengdu, China, vol. 116, p. m39532, 17–21 Oct. 2016.
[B3] Do, M. M., “Timeline of 5G Standardization in ITU-R and 3GPP,” 10 Jan. 2017. Available: https://​www​ .netmanias.​ com/​en/​post/​oneshot/​11147/​5g/​timeline-​ of​-5g​-standardization-​ in​-itu​-r​-and​-3gpp/​.
[B4] Golding, J. F., “Motion sickness susceptibility questionnaire revised and its relationship to other forms of sickness,” Brain Research Bulletin, vol. 47, no. 5, pp. 507–516, November 1998.
[B5] IEEE P802.11-2015/0625r7, TGay Use Cases, Aug. 2017. Available: .5,6,7
[B6] IEEE P802.11-2015/1074r0, TGay Functional Requirements, Sep. 2015. Available: https://m​ entor​.ieee​ .org/​802​.11/​dcn/​15/​11​-15​-1074​-00​-00ay​-11ayfunctional-​ requirements.​ docx.
[B7] IEEE P802.11ax™/D3.0 (June 2018), IEEE Draft Standard for Information Technology— Telecommunications and Information Exchange Between Systems—Local and Metropolitan Area Networks—Specific Requirements—Part 11: Wireless LAN Medium Access Control and Physical Layer (PHY) Specifications—Amendment 6: Enhancements for High Efficiency.
[B8] IEEE P802.11ay™/D2.1 (July 2018), IEEE Draft Standard for Information Technology— Telecommunications and Information Exchange Between Systems—Local and Metropolitan Area Networks—Specific Requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications—Amendment 7: Enhanced Throughput for Operation in License-Exempt Bands above 45 GHz.
[B9] ITU-R M.2083-0 (Sept. 2015), IMT Vision—Framework and overall objectives of the future development of IMT for 2020 and beyond.8
[B10] Kennedy, R. S., N. E. Lane, K. S. Berbaum, and M. G. Lilienthal, “Simulator sickness questionnaire: An enhanced method for quantifying simulator sickness,” International Journal of Aviation Psychology, vol. 3, no. 3, pp. 203–220, November 2009.
[B11] Seo, M., S. Choi, S. Lee, E. Lee, J. Baek, and S. Kang, “Photosensor-based Latency Measurement System for Head-Mounted Displays,” Sensors (Basel), vol. 17, no. 5, pp. 1112–1124, 15 May 2017.
5Numbers preceded by P are IEEE authorized standards projects that were not approved by the IEEE-SA Standards Board at the time this publication went to press. For information about obtaining drafts, contact the IEEE. 6The IEEE standards or products referred to in Annex A are trademarks owned by The Institute of Electrical and Electronics Engineers, Incorporated. 7IEEE publications are available from The Institute of Electrical and Electronics Engineers (https://s​ tandards​.ieee.​ org/​). 8ITU-T publications are available from the International Telecommunications Union (https://w​ ww​.itu​.int/)​ .
72
Authorized licensed use limited to: Technische InformationsCbiobplioytrhigehkt(T©IB2)0. 2D1owIEnlEoEad.eAdllornigFhetsbrrueasryer1v3e,2d0.25 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
RAISING THE WORLD’S STANDARDS
Connect with us on:
Twitter: twitter.com/ieeesa Facebook: facebook.com/ieeesa LinkedIn: linkedin.com/groups/1791118 Beyond Standards blog: beyondstandards.ieee.org YouTube: youtube.com/ieeesa standards.ieee.org Phone: +1 732 981 0060
Authorized licensed use limited to: Technische Informationsbibliothek (TIB). Downloaded on February 13,2025 at 15:21:42 UTC from IEEE Xplore. Restrictions apply.
Reference in New Issue View Git Blame Copy Permalink