From 73c4f8a8cbc6ccea0a90eb3af7af3b3a0ab4718e Mon Sep 17 00:00:00 2001 From: Godopu Date: Fri, 21 Aug 2026 11:07:34 +0900 Subject: [PATCH] docs(research): add MCM and MVQM project reference specifications - Add MCM (Multilateral and Collaborative Metaverse) Part 1 specification document - Add MVQM (Management of Visual Quality in Metaverse Systems) Part 1 document - Update TO-FIX.md with references to research project documents --- TO-FIX.md | 2 + research/projects/mcm.md | 536 ++++++++++++++++++++++++++++++++++++++ research/projects/mvqm.md | 533 +++++++++++++++++++++++++++++++++++++ 3 files changed, 1071 insertions(+) create mode 100644 research/projects/mcm.md create mode 100644 research/projects/mvqm.md diff --git a/TO-FIX.md b/TO-FIX.md index 4b678ab..2d15ee8 100644 --- a/TO-FIX.md +++ b/TO-FIX.md @@ -25,6 +25,7 @@ - CCIS -> MCM으로 수정 - `#project-ccis > div.space-y-4 > div.flex.items-start.justify-between.gap-3.border-b.border-line\/60.pb-3 > span` : 2026 ~ Present - `#project-ccis > div.space-y-4 > p` : MCM 내용으로 수정 + - @`/research/projects/mcm.md` 참조 - `#project-ccis > div.space-y-4 > div.flex.flex-wrap.gap-1\.5.pt-1` : MCM 관련 키워드로 수정 - `#project-ccis > div.space-y-3.pt-3.border-t.border-line\/60.text-xs.font-mono > div.flex.items-baseline.justify-between.gap-2 > span.text-cobalt-dark.font-bold` - "IEC/TC 100/TA 17" -> "IEC/TC 100/WG 12 supported by KEIT" @@ -33,6 +34,7 @@ - `#project-vlc-iot` - VLC-IoT -> MVQM으로 수정 - `#project-vlc-iot > div.space-y-4 > p` : MVQM 내용으로 수정 + - @`/research/projects/mvqm.md` 참조 - `#project-vlc-iot > div.space-y-4 > div.flex.flex-wrap.gap-1\.5.pt-1` : MVQM 관련 키워드로 수정 - `#project-vlc-iot > div.space-y-3.pt-3.border-t.border-line\/60.text-xs.font-mono > div.flex.items-baseline.justify-between.gap-2 > span.text-cobalt-dark.font-bold` - "ITU-T SG20" -> "IEC/TC 100/WG 12 supported by KEIT" diff --git a/research/projects/mcm.md b/research/projects/mcm.md new file mode 100644 index 0000000..17324f0 --- /dev/null +++ b/research/projects/mcm.md @@ -0,0 +1,536 @@ + +# REQUIREMENTS FOR MULTILATERAL AND COLLABORATIVE METAVERSE – Part 1: General + +## CONTENTS + + + +- [FOREWORD](#foreword) +- [INTRODUCTION](#introduction) +- [1 Scope](#1-scope) +- [2 Normative references](#2-normative-references) +- [3 Terms and definitions](#3-terms-and-definitions) + - [3.1 Terms and definitions](#31-terms-and-definitions) + - [3.2 Abbreviated terms](#32-abbreviated-terms) +- [4 General Considerations for Multilateral and Collaborative Metaverse Systems](#4-general-considerations-for-multilateral-and-collaborative-metaverse-systems) + - [4.1 Overview of MCM Systems](#41-overview-of-mcm-systems) + - [4.1.1 Definition and Concept of MCM](#411-definition-and-concept-of-mcm) + - [4.1.2 Position of MCM within the Metaverse Ecosystem](#412-position-of-mcm-within-the-metaverse-ecosystem) + - [4.2 Fundamental Characteristics of MCM Systems](#42-fundamental-characteristics-of-mcm-systems) + - [4.2.1 Collaboration-centered Service Objectives](#421-collaboration-centered-service-objectives) + - [4.2.2 Simultaneous Multilateral Participation](#422-simultaneous-multilateral-participation) + - [4.2.3 Shared Virtual Context](#423-shared-virtual-context) + - [4.2.4 Coordinated Roles and Interdependent Activities](#424-coordinated-roles-and-interdependent-activities) + - [4.2.5 Real-time Reciprocal Interaction](#425-real-time-reciprocal-interaction) + - [4.2.6 Coherence of Shared Session State](#426-coherence-of-shared-session-state) + - [4.2.7 Participant Presence and Mutual Awareness](#427-participant-presence-and-mutual-awareness) + - [4.2.8 Continuity of Collaborative Participation](#428-continuity-of-collaborative-participation) + - [4.3 Representative MCM Service Domains](#43-representative-mcm-service-domains) + - [4.3.1 Professional Work and Organizational Collaboration](#431-professional-work-and-organizational-collaboration) + - [4.3.2 Education and Training](#432-education-and-training) + - [4.3.3 Healthcare and Care Services](#433-healthcare-and-care-services) + - [4.3.4 Industrial Engineering and Operations](#434-industrial-engineering-and-operations) + - [4.3.5 Commerce and Customer Services](#435-commerce-and-customer-services) + - [4.3.6 Public and Civic Services](#436-public-and-civic-services) + - [4.3.7 Entertainment, Culture, and Creative Participation](#437-entertainment-culture-and-creative-participation) + - [4.4 Technical Considerations for MCM Systems](#44-technical-considerations-for-mcm-systems) + - [4.4.1 Heterogeneous Access and Participant Representation](#441-heterogeneous-access-and-participant-representation) + - [4.4.2 Multimodal Interaction and Temporal Coordination](#442-multimodal-interaction-and-temporal-coordination) + - [4.4.3 Shared state and Data Consistency](#443-shared-state-and-data-consistency) + - [4.4.4 Identity, Roles, and Access](#444-identity-roles-and-access) + - [4.4.5 Interoperability and Service Continuity](#445-interoperability-and-service-continuity) + - [4.4.6 Distributed Processing and Service Scalability](#446-distributed-processing-and-service-scalability) + - [4.4.7 AI-assisted and Autonomous Participation](#447-ai-assisted-and-autonomous-participation) + - [4.4.8 Physical-digital Integration](#448-physical-digital-integration) + - [4.4.9 Trust, Security, Privacy, and Safety](#449-trust-security-privacy-and-safety) +- [5 Classification of MCM Services](#5-classification-of-mcm-services) + + - [5.1 Classification Framework Overview](#51-classification-framework-overview) + - [5.2 Domain-based Classification](#52-domain-based-classification) + - [5.3 Media-based Classification](#53-media-based-classification) + - [5.4 Technology-based Classification](#54-technology-based-classification) +- [6 Gap Analysis](#6-gap-analysis) + - [6.1 Current international Standardization Activities](#61-current-international-standardization-activities) + - [6.2 Gaps in Existing Standards](#62-gaps-in-existing-standards) + - [6.3 Recommendations for Future Standardization](#63-recommendations-for-future-standardization) +- [Annex A (informative) Roadmap for MCM Standard Development](#annex-a-informative-roadmap-for-mcm-standard-development) +- [Appendix Z — IEC Word Template Scaffolding (not part of the Technical Report)](#appendix-z--iec-word-template-scaffolding-not-part-of-the-technical-report) + +## FOREWORD + +1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as "IEC Publication(s)"). Their preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with may participate in this preparatory work. International, governmental and non-governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for Standardization (ISO) in accordance with conditions determined by agreement between the two organizations. + +2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international consensus of opinion on the relevant subjects since each technical committee has representation from all interested IEC National Committees. + +3) IEC Publications have the form of recommendations for international use and are accepted by IEC National Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any misinterpretation by any end user. + +4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications transparently to the maximum extent possible in their national and regional publications. Any divergence between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter. + +5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any services carried out by independent certification bodies. + +6) All users should ensure that they have the latest edition of this publication. + +7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and members of its technical committees and IEC National Committees for any personal injury, property damage or other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC Publications. + +8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is indispensable for the correct application of this publication. + +9) IEC draws attention to the possibility that the implementation of this document may involve the use of (a) patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights in respect thereof. As of the date of publication of this document, IEC had not received notice of (a) patent(s), which may be required to implement this document. However, implementers are cautioned that this may not represent the latest information, which may be obtained from the patent database available at https://patents.iec.ch. IEC shall not be held responsible for identifying any or all such patent rights. + +IEC 6XXXX has been prepared by IEC technical Committee TC 100: Audio, video and multimedia systems and equipment. It is Technical Report. + +The text of this Technical Report is based on the following documents: + +| Draft | Report on voting | +|---|---| +| XX/XX/FDIS | XX/XX/RVD | + +Full information on the voting for its approval can be found in the report on voting indicated in the above table. + +The language used for the development of this Technical Report is English. + +This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, available at www.iec.ch/members_experts/refdocs. The main document types developed by IEC are described in greater detail at www.iec.ch/publications. + +The committee has decided that the contents of this document will remain unchanged until the stability date indicated on the IEC website under webstore.iec.ch in the data related to the specific document. At this date, the document will be +- reconfirmed, +- withdrawn, or +- revised. + +## INTRODUCTION + +As metaverse technologies have matured, a distinct class of services has emerged in which the simultaneous presence and active collaboration of multiple participants forms the fundamental premise of the service itself. These services, referred to in this document as Multilateral and Collaborative Metaverse (MCM) systems, constitute a subset of the metaverse specifically designed to enable purposeful, real-time collaboration among two or more simultaneous participants. MCM systems differ structurally and functionally from general metaverse platforms designed primarily for individual use or incidental social interaction, in that collaboration is not incidental but the fundamental condition for service delivery. + +MCM systems are increasingly adopted across a broad range of domains, including remote work and collaboration, education and training, industrial manufacturing, healthcare, entertainment, commerce, and public administration. In each of these contexts, the realization of a coherent collaborative experience depends on the consistent integration of spatial, audio, video, avatar, and identity information across heterogeneous platforms and devices. This integration challenge is not adequately addressed by existing international standards, which have largely focused on platform architecture, device specifications, and content formats rather than on the service-level requirements specific to MCM. The absence of dedicated international standards for MCM systems has resulted in fragmented implementations across the industry, leaving cross-platform interoperability, avatar and digital asset portability, and consistent identity management largely unresolved. + +MCM systems are implemented and realized through multimedia systems and equipment. This positions IEC TC 100 as the appropriate forum for MCM-specific standardization activities, given its established role as the leading standardization body in the area of multimedia systems and equipment. + +The IEC 6XXXX — Requirements for Multilateral and Collaborative Metaverse (MCM) Systems series consists of the following parts: + +Part 1 : General; +Part 2 : Service Requirements; and +Part 3 : Media Requirements. + +Part 1 of IEC TR 6XXXX (this document) defines MCM systems and establishes their conceptual boundaries relative to general metaverse services, presents a classification of MCM services across three complementary dimensions of domain of application, media type, and enabling technology, and identifies gaps in existing international standards with respect to MCM service requirements, with recommendations for future standardization priorities. This Technical Report is informative in nature and serves as the analytical and conceptual foundation upon which subsequent parts of this series are developed. + + +Part 2 of IEC 6XXXX describes common service requirements applicable to MCM systems across major domain categories, including but not limited to work and collaboration, education, commerce, entertainment, and healthcare. Domain-specific requirements that extend beyond the common framework are addressed in dedicated sub-parts, organized in accordance with the service classifications established in Part 1. + +Part 3 of IEC 6XXXX describes common media requirements applicable to MCM systems, addressing the general technical characteristics of media types including audio, video, 3D objects, haptics, and spatial data. Media-specific requirements that extend beyond the common framework are addressed in dedicated sub-parts, organized in accordance with the media classifications established in Part 1. + +## 1 Scope + +This document describes the general considerations for Multilateral and Collaborative Metaverse (MCM) systems, including the definition and key characteristics of MCM, the classification of MCM services by domain, media, and technology, and a gap analysis of existing international standards with respect to MCM service requirements. + +For the purposes of this document, MCM is defined as a subset of the metaverse in which two or more participants simultaneously interact within a shared virtual space for a common collaborative purpose. The following are explicitly excluded from the scope of this document: + +- single-user metaverse experiences in which collaboration is absent or incidental; +- multiplayer environments in which interaction is competitive rather than collaborative; +- asynchronous virtual environments in which participants do not share simultaneous presence; and +- general metaverse platform infrastructure not specific to MCM service requirements. + +## 2 Normative references + +The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. + +- IEC TR 63614-1, Multimedia systems and equipment for metaverse – Part 1: General +- IEC TS 63614-2, Multimedia systems and equipment for metaverse – Part 2: Classification +- IEC TR 63614-3, Multimedia systems and equipment for metaverse – Part 3: Gap analysis + +## 3 Terms and definitions + +For the purposes of this document, the following terms and definitions apply. + +ISO and IEC maintain terminology databases for use in standardization at the following addresses: + +- IEC Electropedia: available at https://www.electropedia.org/ +- ISO Online browsing platform: available at https://www.iso.org/obp + +### 3.1 Terms and definitions + +#### 3.1.1 metaverse +digital-based virtual environment in which users, represented by avatars, access a virtual space through a network using a device to experience various activities through digital content and platforms + +#### 3.1.2 multilateral and collaborative metaverse (MCM) +subset of the metaverse specifically designed to enable purposeful, real-time collaboration among two or more simultaneous participants within a shared virtual space, where collaborative participation is the fundamental condition for service delivery + +> **Note 1** — MCM systems are distinguished from general metaverse services in that the service itself cannot be constituted without the presence of multiple collaborative participants. + +#### 3.1.3 avatar +digital representation of a participant within a virtual space, capable of conveying spatial presence, movement, and non-verbal expression + +#### 3.1.4 session +bounded instance of MCM service operation during which multiple participants engage in real-time collaborative interaction within a shared virtual space + +#### 3.1.5 spatial presence +perceptual experience of being co-located with other participants in a shared virtual space, enabled by spatial audio, positional awareness, and immersive rendering + +#### 3.1.6 cross-platform interoperability +capability of MCM systems to maintain a coherent collaborative experience across heterogeneous platforms and devices without loss of functional or experiential continuity + +#### 3.1.7 digital asset +digitally represented object within an MCM environment that holds functional or economic value, including but not limited to avatars, virtual goods, and environmental content + +#### 3.1.8 Quality of Experience (QoE) +degree to which a user perceives the overall performance and suitability of an MCM service, encompassing technical, contextual, and perceptual dimensions + +#### 3.1.9 AI agent +autonomous software entity that participates in an MCM environment, capable of perceiving context, generating responses, and interacting with human participants in real time + +### 3.2 Abbreviated terms + +| Abbreviation | Term | +|---|---| +| AI | Artificial intelligence | +| AR | Augmented Reality | +| DID | Decentralized identifier | +| IoT | Internet of Things | +| MCM | Multilateral and Collaborative Metaverse | +| MR | Mixed Reality | +| NPC | Non-Player Character | +| QoE | Quality of Experience | +| QoS | Quality of Service | +| VR | Virtual Reality | +| WoT | Web of Things | +| XR | Extended reality | + +## 4 General Considerations for Multilateral and Collaborative Metaverse Systems + +### 4.1 Overview of MCM Systems + +#### 4.1.1 Definition and Concept of MCM + +The metaverse encompasses digitally mediated virtual environments in which users, represented directly or indirectly through digital identities or avatars, participate in activities within a virtual space. These activities include individual content consumption, social interaction, entertainment, commerce, education, industrial operations, and other forms of digitally mediated experience. Within this broader concept, Multilateral and Collaborative Metaverse (MCM) systems constitute a distinct category of metaverse systems in which purposeful and coordinated collaboration among two or more simultaneous participants is the primary objective and an essential condition of service delivery. + +An MCM service provides a shared virtual environment in which participants perceive and interact with a common context, including other participants, digital objects, information resources, and environmental states. Participants perform coordinated activities toward a shared or mutually aligned objective. Such activities include joint decision-making, co-creation, learning, training, consultation, design, operation, performance, service provision, or public participation. In the context of MCM, the term “multilateral” refers to the involvement of two or more interacting participants whose actions can affect a shared session, shared objects, or other participants. The term “collaborative” refers to coordinated interaction directed toward a common activity, objective, or outcome. Collaborative participation does not require all participants to perform identical functions. Participants have different roles, responsibilities, access privileges, or levels of authority within the same MCM session. + +MCM is defined primarily from a service perspective and is not dependent on a particular device, platform, degree of immersion, or implementation architecture. An MCM service is accessed through head-mounted displays, personal computers, mobile devices, spatial computing devices, or other multimedia systems and equipment. Similarly, the use of extended reality, avatars, spatial audio, artificial intelligence, digital twins, or other enabling technologies does not by itself constitute an MCM service. The presence of multiple users alone is insufficient to classify a metaverse service as MCM. Multi-user environments in which interaction is incidental, loosely connected, exclusively competitive, or primarily based on independent content consumption do not fall within the conceptual boundary of MCM. Competitive or individual activities are included in an MCM service, provided that they form part of a broader collaborative process and that the primary service objective depends on coordinated participation. Accordingly, the defining condition of an MCM system is that the intended collaborative function or service outcome cannot be fully realized through the participation of a single user acting independently. + +#### 4.1.2 Position of MCM within the Metaverse Ecosystem + +MCM systems form a subset of the broader metaverse ecosystem. They do not represent a separate type of virtual environment defined by a specific platform or technology. Rather, they represent a service-oriented category distinguished by the structural role of collaboration in the design and operation of the service. General metaverse services support multiple users, social interaction, avatar communication, shared events, commerce, or content creation. However, such services remain operable for an individual user, and interaction with other users may be optional, incidental, or secondary to the principal service objective. By contrast, an MCM system is designed around a shared collaborative session. Participants interact within a common virtual environment, maintain awareness of shared activities and states, and contribute to a collaborative process or outcome. The service value arises primarily from coordinated interaction among participants rather than from the independent experience of each participant. + +MCM systems are related to several adjacent service and technology areas, including virtual worlds, immersive communication, collaborative computing, digital twin environments, online multiplayer services, and conventional video collaboration systems. However, no single one of these areas is equivalent to MCM. MCM is distinguished by the combined presence of the following conditions: + +- two or more simultaneous participants; +- a shared virtual environment or shared digitally mediated context; +- coordinated interaction among participants; +- a common or mutually aligned objective; and +- a service function or outcome that depends on multilateral participation. + +Table 1 summarizes the principal differences between general metaverse services and MCM systems. + +**Table 1. Comparison of general metaverse services and MCM Systems** + +| Attribute | General Metaverse | Multilateral and Collaborative Metaverse | +|---|---|---| +| Primary service objective | Individual experience, content consumption, social interaction, entertainment, or other activities are performed independently | Purposeful collaboration and coordinated participation toward a shared activity, objective, or outcome | +| Participation structure | Support either individual or multiple user participation | Requires two or more simultaneous participants for the collaborative function | +| Role of interaction | Interaction with other users is optional, incidental, social, or competitive | Interaction among participants is integral to service delivery | +| Shared context | Users occupy the same environment without sharing a common task, state, or objective | Users share an environment, task context, resources, objects, or service state | +| Participant roles | Roles are undefined or unrelated to the service outcome | Participants have differentiated but coordinated roles, responsibilities, permissions, or authority | +| Service operability | Generally used or experienced by a single user | Generally used or experienced by multi-users | +| Value creation | Generated primarily through individual experience or optional interaction | Generated through the collaborative process, coordinated activity, or shared result | + +As shown in Table 1, general metaverse services provide shared virtual spaces and support interaction among multiple users without requiring coordinated participation. Individual users independently consume content, explore virtual environments, create digital items, or engage in optional social interaction, while the principal service remains available regardless of the participation of others. In an MCM system, participants are connected through a shared activity, task, or service process. Their actions occur within a common context and influence shared objects, environmental states, other participants, or the outcome of the collaborative session. Participants assume different roles, responsibilities, permissions, and levels of authority, while these differentiated roles remain coordinated toward a common or mutually aligned objective. The participation structure and service operability identified in Table 1 provide the principal basis for distinguishing MCM systems from general metaverse services. A service qualifies as an MCM service when its intended function, collaborative process, or shared outcome depends on the simultaneous and coordinated participation of two or more participants. The mere presence of multiple users within the same virtual environment does not satisfy this condition. + +The conceptual boundary established in this subclause provides the basis for the fundamental characteristics described in 4.2, the representative service domains described in 4.3, and the multidimensional classification framework specified in Clause 5. + + +### 4.2 Fundamental Characteristics of MCM Systems + +MCM systems exhibit a set of common characteristics related to the structure of collaborative participation, the organization of shared activities, and the continuity of interaction within a shared virtual environment. These characteristics apply across the representative service domains described in 4.3, although their relative importance and detailed realization differ according to the purpose and operational context of each domain. + +#### 4.2.1 Collaboration-centered Service Objectives + +An MCM service is organized around a collaborative objective that connects the activities of all participants within a shared session. The objective represents a common activity, task, process, or outcome toward which participants contribute through coordinated interaction. + +Collaborative objectives include joint decision-making, co-creation, instruction and learning, consultation, design review, operational coordination, performance, and public participation. The specific objective differs across service domains, but the collaborative process remains central to the operation and value of the service. The collaborative objective also provides the basis for the organization of participant roles, interaction procedures, shared resources, and session activities. Individual actions acquire meaning through their relationship with the actions of other participants and with the shared objective. Interaction that remains optional, incidental, or unrelated to the principal service outcome does not constitute collaboration in the context of MCM. + +#### 4.2.2 Simultaneous Multilateral Participation + +MCM services involve the simultaneous participation of two or more participants within a shared virtual session. Simultaneous participation refers to overlapping active presence during which participants exchange information, observe actions, and adjust their own activities in response to others. The number of participants varies according to the service domain and use case. An MCM session ranges from a small collaborative group, such as a medical consultation or design review, to a large-scale session, such as a virtual public event or civic consultation. + +The participant group consists primarily of human participants and, in certain services, includes AI agents that perform collaborative or supporting functions. Regardless of participant type, each active participant has an identifiable relationship with the shared activity and with other participants in the session. Asynchronous activities, including preparation, review, recording, and follow-up, form supplementary elements of an MCM service. The principal collaborative phase, however, depends on simultaneous interaction among multiple participants. + +#### 4.2.3 Shared Virtual Context + +MCM participants interact within a shared virtual context that provides a common basis for collaborative activity. The shared virtual context includes the virtual environment, participant representations, digital objects, information resources, task status, and other session-related elements perceived or accessed by participants. A shared virtual context does not require identical visual presentation for every participant. Views and interaction interfaces differ according to participant role, access device, permissions, or service function. + +Despite these differences, participants retain a consistent understanding of the shared environment, collaborative activity, and relevant object or task states. The shared context supports situational awareness by enabling participants to recognize where an activity takes place, who participates, which objects or information are involved, and how the collaborative process progresses. This common understanding distinguishes an MCM session from independent user activities that occur within the same platform without a shared task or coordinated context. + +#### 4.2.4 Coordinated Roles and Interdependent Activities + +Participants in an MCM system perform roles associated with the collaborative objective. These roles define relationships among participants and structure responsibilities, permissions, authority, access to information, and control over shared resources. Participant roles differ according to the service domain. Examples include employer and employee in work environments, instructor and learner in education, performer and audience member in entertainment, healthcare professional and patient in medical services, operator and remote expert in industrial environments, and public official and citizen in public services. + +Different roles do not imply equal functions or identical access. MCM collaboration involves coordinated contributions in which participants perform complementary activities toward a shared objective. The output or action of one participant influences the activities, decisions, or available information of other participants. Role relationships also change during a session. A participant transitions between observing, presenting, controlling, assisting, approving, or performing functions according to the progression of the collaborative activity. Clear representation of roles and role transitions supports coherent interaction among participants. + +#### 4.2.5 Real-time Reciprocal Interaction + +MCM systems support reciprocal interaction in which participants exchange information and respond to one another during the shared session. Reciprocal interaction includes verbal communication, non-verbal expression, manipulation of shared objects, navigation within the virtual environment, and actions related to the shared task. Real-time interaction refers to a level of temporal responsiveness that preserves the continuity and meaning of collaborative activity. It does not imply the complete absence of transmission or processing delay. The acceptable level of responsiveness depends on the interaction type and service context. Conversation, collaborative object manipulation, remote operation, live performance, and clinical interaction present different temporal sensitivities. + +Reciprocal interaction also involves mutual influence. A participant action changes the shared context, produces information for other participants, or affects the progression of the collaborative process. Other participants recognize the action and respond within the temporal conditions of the service. + +#### 4.2.6 Coherence of Shared Session State + +An MCM session maintains a coherent shared state across participating users, devices, and service components. The shared session state includes participant presence, role status, object state, task progress, environmental conditions, interaction history, and other information relevant to the collaborative activity. + +State coherence does not require every participant device to render the virtual environment in an identical manner. It requires consistent interpretation of the meaning and effect of shared actions and objects. For example, when one participant moves, modifies, assigns, approves, or removes a shared object, other participants receive a corresponding representation of that change appropriate to their roles and interfaces. Loss of state coherence results in different understandings of the same collaborative situation. Such inconsistency disrupts coordination, reduces trust in the shared environment, and affects the validity of collaborative outcomes. + +#### 4.2.7 Participant Presence and Mutual Awareness + +MCM services provide participants with awareness of the presence, identity, role, and activity of other participants. Mutual awareness enables participants to interpret who is present, who is speaking or acting, where attention is directed, and how individual actions relate to the collaborative process. Participant presence is represented through avatars, video representations, digital humans, spatial indicators, cursors, status information, or other forms of digital representation. The form and fidelity of representation differ according to the service domain, media configuration, access device, and interaction objective. + +Mutual awareness extends beyond the visual representation of participants. It includes awareness of participant availability, location, focus, current activity, communication status, and relationship to shared objects or tasks. This awareness supports coordination and reduces ambiguity during multilateral interaction. Non-verbal information, including gesture, posture, gaze direction, facial expression, and spatial orientation, contributes to mutual awareness in services where such information carries collaborative meaning. The significance of each form of non-verbal information differs across domains and use cases. + +#### 4.2.8 Continuity of Collaborative Participation + +MCM systems preserve the continuity of collaborative participation throughout the lifecycle of a session. Continuity includes the association of each participant with an identity, role, permission set, interaction state, and contribution to the shared activity. Participants enter, leave, reconnect to, or transition between access environments during an MCM session. The collaborative context retains relevant information concerning participant roles, shared objects, task progress, and previous actions throughout these transitions. Continuity also applies to collaborative outcomes that remain available after the real-time session. Records, jointly created content, decisions, annotations, digital assets, and task results form part of the service context where persistence supports subsequent activities. + +The scope and duration of continuity differ across service domains. A live entertainment event emphasizes continuity during the active session, while education, industrial design, healthcare, and public administration often involve persistent records and collaborative processes extending across multiple sessions. + + +### 4.3 Representative MCM Service Domains + +MCM services appear across different social, economic, institutional, and industrial contexts. For the purposes of this document, service domains are distinguished according to the principal collaborative objective, the operational context of the activity, the roles and relationships of participants, and the type of shared outcome produced through the session. The domain classification focuses on the purpose of the service rather than on the device, platform, media configuration, or enabling technology used for implementation. The same technical environment supports services in different domains, while services within one domain use different technical configurations. + +The domains in this subclause are representative rather than exhaustive. A service involving more than one operational context is treated as a cross-domain MCM service. Its primary domain corresponds to the principal collaborative objective, while additional domains describe complementary activities or service functions. This approach preserves a consistent basis for the domain-oriented requirements without restricting emerging MCM services to a fixed industry structure. + +This document identifies the following representative domains: + +- professional work and organizational collaboration; +- education and training; +- healthcare and care services; +- industrial engineering and operations; +- commerce and customer services; +- public and civic services; and +- entertainment, culture, and creative participation. + +#### 4.3.1 Professional Work and Organizational Collaboration + +The professional work and organizational collaboration domain covers MCM services that support coordinated activities among participants engaged in professional, administrative, research, or organizational work. The principal objective is the production of a shared work result, decision, plan, design, or organizational action. + +Representative activities include virtual meetings, collaborative planning, document and content development, brainstorming, design discussion, research collaboration, professional consultation, project coordination, onboarding, and distributed teamwork. Participants include employees, managers, researchers, consultants, clients, external partners, and AI agents performing facilitation or assistance functions. + +The shared virtual context contains work-related information, common resources, task status, participant roles, and jointly produced outputs. The distinction from conventional communication services lies in the dependence of the service outcome on coordinated work within the shared context rather than on communication alone. + +#### 4.3.2 Education and Training + +The education and training domain covers MCM services that support instruction, collaborative learning, practice, assessment, and skill development. The principal objective is the acquisition, application, or evaluation of knowledge and competence through interaction among instructors, learners, peers, assessors, and supporting agents. + +Representative activities include virtual classrooms, collaborative laboratories, simulation-based training, procedural rehearsal, technical instruction, group problem-solving, mentoring, role-playing, and guided practice. The shared virtual context provides learning resources, simulated objects or environments, task progress, demonstrations, and feedback. + +This domain includes formal education, vocational training, professional development, and safety or operational training. Services that reproduce a workplace or industrial process for learning purposes remain within this domain when learning and competence development represent the principal objective. + +#### 4.3.3 Healthcare and Care Services + +The healthcare and care services domain covers MCM services that support clinical, therapeutic, rehabilitative, preventive, and care-related collaboration. The principal objective is the assessment, treatment, support, coordination, or improvement of an individual or group health condition. + +Representative activities include multidisciplinary consultation, remote clinical assessment, collaborative treatment planning, rehabilitation, group therapy, clinical case review, patient education, caregiver coordination, and medical simulation associated with care delivery. Participants include healthcare professionals, patients, caregivers, technicians, specialists, and AI-based support agents. + +The shared virtual context contains health-related information, participant observations, treatment or care activities, virtual representations, and records of collaborative decisions. Differentiated professional authority, restricted information access, participant consent, and continuity across related sessions form central aspects of this domain. + +#### 4.3.4 Industrial Engineering and Operations + +The industrial engineering and operations domain covers MCM services associated with the design, production, operation, inspection, maintenance, and lifecycle management of products, facilities, equipment, and technical systems. The principal objective is the coordinated execution or improvement of an engineering or operational process. + +Representative activities include collaborative design review, virtual prototyping, factory and facility planning, remote expert assistance, equipment maintenance, process simulation, quality inspection, operational coordination, and interaction with digital twins. Participants include engineers, designers, operators, technicians, inspectors, managers, suppliers, and AI-based operational agents. + +The shared virtual context often represents physical assets, operational conditions, technical data, and task states. Relationships between virtual actions and physical processes distinguish this domain from general professional collaboration. Industrial training remains classified under education and training when learning represents the principal service objective. + +#### 4.3.5 Commerce and Customer Services + +The commerce and customer services domain covers MCM services that support commercial consultation, product or service exploration, configuration, evaluation, negotiation, and transaction-related decision-making. The principal objective is the collaborative exchange of commercial information or the completion of a customer-oriented service process. + +Representative activities include virtual showrooms, assisted shopping, collaborative product configuration, property or facility tours, live product demonstrations, customer consultation, group purchasing, and professional service delivery. Participants include customers, sales representatives, product specialists, service providers, advisors, designers, and AI-based customer service agents. + +The shared virtual context contains product or service representations, configuration states, preferences, annotations, recommendations, and transaction-related information. This domain emphasizes the coordinated relationship between customers and service providers, or among multiple customers participating in a shared decision. + +#### 4.3.6 Public and Civic Services + +The public and civic services domain covers MCM services that support public administration, civic participation, community consultation, institutional coordination, and public service delivery. The principal objective is the execution of a public function or the participation of stakeholders in a civic or administrative process. + +Representative activities include virtual public hearings, participatory planning, administrative consultation, emergency response coordination, inter-agency collaboration, public education, community engagement, and review of public proposals. Participants include public officials, civil servants, citizens, community representatives, experts, emergency personnel, and AI-based public service agents. + +The shared virtual context contains public information, proposals, service records, spatial or administrative data, stakeholder input, and records of collective activity. Accessibility, inclusion, representation of authority, transparency of process, and traceability of decisions form significant aspects of this domain. + +#### 4.3.7 Entertainment, Culture, and Creative Participation + +The entertainment, culture, and creative participation domain covers MCM services that support shared performance, recreation, cultural engagement, artistic creation, and interaction with cultural heritage. The principal objective is the production or experience of entertainment, cultural, or creative value through coordinated participation. + +Representative activities include virtual concerts, interactive performances, collaborative games, participatory storytelling, fan events, virtual exhibitions, guided museum or heritage experiences, collaborative art creation, rehearsals, and cultural workshops. Participants include performers, creators, audiences, curators, educators, researchers, moderators, and AI-driven characters, guides, or creative agents. + +This domain combines entertainment and culture because both rely on participatory experience, creative expression, performance, interpretation, and audience engagement within a shared context. A service based solely on independent content consumption or adversarial activity without a collaborative objective remains outside the MCM boundary. Competitive elements remain relevant where they form part of team cooperation, collective production, or a shared participatory event. + + +### 4.4 Technical Considerations for MCM Systems + +MCM systems combine multiple participants, media types, devices, platforms, and service components within a shared collaborative environment. Their technical configuration differs according to the service domain, collaborative objective, participant structure, media configuration, and operational environment. + +This subclause identifies common technical consideration areas associated with MCM systems. These areas provide a general reference for understanding the technical aspects of MCM and for organizing the classifications and subsequent parts of this series. They do not define a specific implementation architecture, technology, or performance level. + +#### 4.4.1 Heterogeneous Access and Participant Representation + +Participants in an MCM session access the shared environment through different types of devices and interfaces, including immersive and non-immersive systems. The form of participant representation also differs according to the service context and access environment. + +Despite differences in devices and representations, participants retain a consistent relationship with the shared session, including their identity, role, activity, and interaction with shared resources. Heterogeneous access therefore represents an important consideration for maintaining a coherent collaborative experience across different participation environments. + +#### 4.4.2 Multimodal Interaction and Temporal Coordination + +MCM services involve combinations of media and interaction information, including audio, video, participant representations, gestures, spatial information, shared objects, and other forms of digital content. + +Collaborative interaction depends not only on the individual quality of each media element but also on the temporal relationship among them. Appropriate coordination among communication, participant actions, and changes in the shared environment supports consistent interpretation of collaborative activities. + +#### 4.4.3 Shared state and Data Consistency + +Participants in an MCM session interact with shared information, objects, tasks, and environmental states. Actions performed by one participant influence the collaborative context experienced by other participants. + +Consistency of shared state supports a common understanding of participant activities, object conditions, task progress, and collaborative outcomes. The representation of a shared state differs across devices or participant roles, while the meaning and effect of the state remain consistent within the collaborative context. + +#### 4.4.4 Identity, Roles, and Access + +MCM services involve participants with different identities, roles, responsibilities, and levels of authority. Participant roles influence access to information, shared objects, service functions, and collaborative activities. + +Identity and role information therefore form part of the technical context of an MCM session. This context also includes participant authentication, access control, role transitions, ownership relationships, and the association between participants and their activities within the shared environment. The detailed significance of these elements differs according to the service domain and collaborative objective. + +#### 4.4.5 Interoperability and Service Continuity + +MCM environments involve heterogeneous platforms, devices, service components, and digital resources. Interoperability supports coherent interaction among these elements and contributes to continuity of collaborative participation across different technical environments. + +In the context of MCM, interoperability extends beyond the exchange of individual data elements. It also relates to continuity of participant identity, roles, shared objects, interaction context, session information, and collaborative activities. The scope of interoperability differs according to the service configuration and forms an important reference area for the classification and gap analysis presented in subsequent clauses. + +#### 4.4.6 Distributed Processing and Service Scalability + +MCM services involve processing and communication functions distributed across participant devices, network resources, edge systems, cloud environments, and service platforms. These functions include media processing, shared-state management, rendering, session management, and other operations associated with collaborative interaction. + +The distribution of these functions influences responsiveness, service continuity, and the number and geographical distribution of participants supported within an MCM environment. Different service domains present different processing and scalability characteristics according to their collaborative activities and media configurations. + +#### 4.4.7 AI-assisted and Autonomous Participation + +Artificial intelligence performs various functions within MCM environments. AI-based functions include assistance with communication, content generation, information processing, interaction support, and management of collaborative activities. + +AI agents also participate directly in an MCM session as identifiable entities associated with specific roles or functions. The involvement of AI introduces additional considerations regarding participant representation, role assignment, interaction context, authority, and distinction between human and AI participants. The role and level of AI involvement differ according to the collaborative objective and service domain. + +#### 4.4.8 Physical-digital Integration + +Some MCM services incorporate information and objects representing physical environments, assets, devices, or operational processes. Such integration connects collaborative activities in the virtual environment with states or events originating from physical environments. + +Digital twins, sensing systems, connected devices, and spatial information represent examples of elements associated with physical-digital integration. Their relevance varies across domains, with stronger relationships appearing in industrial operations, healthcare, public services, and other services involving physical environments or assets. Physical-digital integration also supports cross-domain MCM scenarios in which participants interact with shared representations of real-world environments and systems. + +#### 4.4.9 Trust, Security, Privacy, and Safety + +MCM services involve interactions among multiple participants and the exchange of participant, service, media, and environmental information. The significance of trust, security, privacy, and safety differs according to the service domain, participant relationship, type of information, and effect of collaborative activities. + +Relevant considerations include protection of participant and service information, reliability of identity and role information, integrity of shared states and collaborative outcomes, and management of risks arising from interactions between participants, AI agents, digital resources, and physical environments. These aspects represent cross-cutting considerations across MCM service domains rather than characteristics of a particular implementation technology. + +The technical consideration areas described in 4.4 provide a general reference for the classification of MCM services in Clause 5. Individual MCM services combine these areas in different ways according to their domain, media configuration, enabling technologies, and collaborative objectives. Detailed technical and service aspects are addressed in subsequent parts of this series according to their respective scopes. + +## 5 Classification of MCM Services + +### 5.1 Classification Framework Overview + +As described in Clause 4, MCM services span a heterogeneous landscape across application domains, media types, and enabling technologies. MCM systems are applied across multiple domains, combine different media types, and depend on several technology areas. This diversity introduces challenges for standardization. A single set of requirements is not sufficient to address the range of operational contexts, media configurations, and technical architectures associated with MCM services. + +The operational constraints that determine service adequacy differ substantially between MCM domains. An immersive virtual concert distributes high-fidelity audio and visual media to a large audience, where sustained media quality, rendering fidelity, and scalability of concurrent participation govern the participant experience. A remote medical consultation involves a small number of participants, where end-to-end latency, temporal precision, and fidelity of clinical detail govern the validity of the collaborative outcome. Both are MCM services under the conditions established in Clause 4, and both depend on simultaneous multilateral participation, yet the requirements that determine their adequacy are not the same. As noted in 4.2.5, live performance and clinical interaction present different temporal sensitivities. A single undifferentiated set of requirements therefore either constrains one domain beyond its operational need or leaves the other insufficiently specified. Classification by domain of application allows requirements to be expressed at the level at which these constraints actually differ. + +Participants access a shared MCM session through heterogeneous terminals, including head-mounted displays, personal computers, mobile devices, and spatial computing devices. As described in 4.2.3 and 4.2.6, participants do not require identical presentation of the shared environment, but they do require consistent interpretation of shared actions, objects, and session state. Interoperability across these terminals therefore depends not only on the mapping of capabilities between devices, but also on common baseline constraints that bound the permissible variation in timing, media quality, representation of participants, and interaction semantics. Where such constraints are absent, differences between access environments propagate into the collaborative process itself and produce divergent understandings of the same session. These constraints are not uniform across MCM services; they depend on the domain, media configuration, and enabling technologies involved. + +This clause introduces a classification framework to support the identification of standardization requirements and gaps. The framework organizes MCM services along three dimensions: domain of application, media type, and enabling technology. The framework serves the following purposes within this Technical Report and the IEC TR series. + +**Scope definition** +- The classification provides a structured basis for defining the scope of MCM services and their relation to adjacent technology domains. It distinguishes MCM services from adjacent forms of digital interaction, including conventional metaverse services and non-immersive collaboration systems. The classification provides a consistent basis for determining the applicability of standardization activities across different MCM service contexts. + +**Analytical reference** +- The classification provides a structured vocabulary and framework for describing and comparing MCM services across contexts. It supports the identification of common requirements across categories and category-specific requirements within particular domains, media types, or technologies. + +**Gap analysis foundation** +- The classification dimensions define the basis for identifying and assessing gaps in existing international standards, as described in Clause 6. Each gap identified in 6.2 is mapped to one or more classification categories. This mapping supports systematic evaluation of limitations in current standards relative to MCM service requirements. + +**Requirements structuring** +- The classification informs the structure of subsequent parts in this series. Part 2 (Service Requirements) follows the domain classification defined in 5.2. Part 3 (Media Requirements) follows the media classification defined in 5.3. + +Classification by domain alone does not account for convergence between MCM services. Services in different domains draw on the same enabling technologies, and capabilities developed in one domain are transferable to others, as noted in 4.3.3.3. Classification by enabling technology, applied in parallel with the domain and media dimensions, identifies requirements that are common across domains and avoids the duplication that would result from specifying each domain independently. The technology dimension defined in 5.4 therefore complements the domain and media dimensions rather than subdividing them. + +The classification in this clause is informative and analytical. It serves as a reference framework and does not define a normative taxonomy. Category boundaries are not fixed. MCM services span multiple domains, media types, and enabling technologies. The three dimensions are treated as complementary perspectives for analysis. + +### 5.2 Domain-based Classification + +TBD + +### 5.3 Media-based Classification + +TBD + +### 5.4 Technology-based Classification + +TBD + +## 6 Gap Analysis + +### 6.1 Current international Standardization Activities + +TBD + +### 6.2 Gaps in Existing Standards + +TBD + +### 6.3 Recommendations for Future Standardization + +TBD + +## Annex A (informative) Roadmap for MCM Standard Development + +TBD + + + +## Appendix Z — IEC Word Template Scaffolding (not part of the Technical Report) + + + +### Z.1 How to use this document (source: p.1–2) + +This document provides you with the general structure of an IEC publication and some information about individual elements. Links to more detailed information can be found in the individual sections. +Basic formatting instructions are provided for Word 2007 and later. + +**Typographical conventions in this template** +- Content in red needs to be provided by you. Please revert the font colour to black once you have adapted it. +- Content in black is boilerplate text and cannot be modified. +- Additional explanations appear in blue with a red border; a special style (IEC INSTRUCTIONS) was created for this purpose. + +To format text, use the styles from the IEC template. +Most of those required are available in the IEC tools tab. +Others can be accessed from Word's Styles panel – consult the user guide to the IEC template for more information. +Download the user guide for in-depth instructions and brief video tutorials (in progress). + +**Table of contents guidance** +- To update the table of contents below, click on it and press F9. Do the same for the list of figures and the list of tables. +- To create a new table of contents, delete the old one and click on Table of contents in the IEC tools tab. +- If updating the table of contents produces an error message, please use Word's built-in feature to create a table of contents (in the Reference tab, click on Table of contents and select one you like). At CDV stage, we will insert the correct table at the IEC. + +### Z.2 Unselected Clause 3 boilerplate variants (source: p.7–8) + +> Note: The document author selected Variant ① (Standard boilerplate text) for Clause 3 because the TR defines 9 internal terms and does not cite an external terms document. Variants ② and ③ were left unselected in the template. + +**Variant ② — Terms and definitions listed in a different document:** + +For the purposes of this document, the terms and definitions given in [external document reference] apply. + +ISO and IEC maintain terminology databases for use in standardization at the following addresses: +- IEC Electropedia: available at https://www.electropedia.org/ +- ISO Online browsing platform: available at https://www.iso.org/obp + +**Variant ③ — Terms and definitions listed in a different document and in this document:** + +For the purposes of this document, the terms and definitions given in [external document reference] and the following apply. + +ISO and IEC maintain terminology databases for use in standardization at the following addresses: +- IEC Electropedia: available at https://www.electropedia.org/ +- ISO Online browsing platform: available at https://www.iso.org/obp + +### Z.3 Authoring instruction (source: p.8) + +To insert terms and definitions, use the Insert term form from the IEC tools tab. +If the tab does not appear on your screen, make sure the IEC template is attached to your working document, and consult the user guide. diff --git a/research/projects/mvqm.md b/research/projects/mvqm.md new file mode 100644 index 0000000..d3f23ff --- /dev/null +++ b/research/projects/mvqm.md @@ -0,0 +1,533 @@ +# IECSTD - Version 4 + +XXX © IEC:202x – 1 – XXX © CEI:202x CONTENTS 2 + +1. Scope ............................................................................................................................... 7 3 + +2. Normative references ....................................................................................................... 7 4 + +3. Definitions and terminology .............................................................................................. 7 5 3.1. Definitions ............................................................................................................... 7 6 3.1.1. Management of Visual Quality in Metaverse Systems (MVQM) .................... 7 7 3.1.2. Hybrid Visual Asset (HVA) ........................................................................... 7 8 3.1.3. Visual Quality .............................................................................................. 7 9 3.1.4. Area of Interest (AoI) ................................................................................... 7 10 3.1.5. Level of Detail (LOD) ................................................................................... 8 11 3.1.6. Orchestration ............................................................................................... 8 12 3.1.7. Telemetry .................................................................................................... 8 13 3.1.8. Control Plane .............................................................................................. 8 14 3.1.9. Data Plane .................................................................................................. 8 15 3.1.10. Reference Point ........................................................................................... 8 16 3.2. Abbreviations .......................................................................................................... 8 17 3.2.1. AoI .............................................................................................................. 8 18 3.2.2. ASE ............................................................................................................. 8 19 3.2.3. CCE ............................................................................................................ 8 20 3.2.4. CG .............................................................................................................. 8 21 3.2.5. CHIE ........................................................................................................... 8 22 3.2.6. CPU ............................................................................................................ 8 23 3.2.7. CSRE .......................................................................................................... 8 24 3.2.8. GPU ............................................................................................................ 9 25 3.2.9. HEVC .......................................................................................................... 9 26 3.2.10. HMD ............................................................................................................ 9 27 3.2.11. HVA ............................................................................................................. 9 28 3.2.12. IF ................................................................................................................ 9 29 3.2.13. IOE .............................................................................................................. 9 30 3.2.14. KPI .............................................................................................................. 9 31 3.2.15. LOD ............................................................................................................. 9 32 3.2.16. MIV ............................................................................................................. 9 33 3.2.17. MVQM ......................................................................................................... 9 34 3.2.18. NDE ............................................................................................................ 9 35 3.2.19. NIE .............................................................................................................. 9 36 3.2.20. NMCE .......................................................................................................... 9 37 3.2.21. OCDE .......................................................................................................... 9 38 3.2.22. OQDE .......................................................................................................... 9 39 3.2.23. PBR ............................................................................................................. 9 40 3.2.24. PME ............................................................................................................ 9 41 3.2.25. PWCE ......................................................................................................... 9 42 3.2.26. P0~P3 ......................................................................................................... 9 43 3.2.27. QoE ........................................................................................................... 10 44 3.2.28. QoS ........................................................................................................... 10 45 3.2.29. RTT ........................................................................................................... 10 46 3.2.30. SDCE ........................................................................................................ 10 47 XXX © IEC:202x – 2 – XXX © CEI:202x 3.2.31. SDME ........................................................................................................ 10 48 3.2.32. SIAE .......................................................................................................... 10 49 3.2.33. SLA ........................................................................................................... 10 50 3.2.34. SPE ........................................................................................................... 10 51 3.2.35. SRE ........................................................................................................... 10 52 3.2.36. TRE ........................................................................................................... 10 53 3.2.37. UHRE ........................................................................................................ 10 54 3.2.38. V-PCC ....................................................................................................... 10 55 +4. Considerations on MVQM ............................................................................................... 10 56 4.1. Motivation ............................................................................................................. 10 57 4.2. Metaverse system with multiple users using various networks and devices ........... 11 58 4.3. Heterogeneous production methods of visual objects in metaverse systems .......... 12 59 4.4. Context-aware visual quality management based on avatar behavior .................... 13 60 +5. Adaptation with MVQM ................................................................................................... 13 61 5.1. Bandwidth-aware adaptation ................................................................................. 13 62 5.2. Device capability-based adaptation ....................................................................... 13 63 5.3. Object-specific adaptation based on production methods ...................................... 14 64 5.4. Adaptation based on the avatar's context .............................................................. 14 65 5.5. Candidate items for standardization ...................................................................... 15 66 +6. Example scenarios for MVQM......................................................................................... 15 67 6.1. Adaptive visual quality management using scalable bitstreams ............................. 15 68 6.2. Object- and region-based visual quality control using scalable bitstreams ............. 17 69 6.3. Multi-source visual data management and adaptive composition ........................... 18 70 6.4. Visual quality management based on avatar context ............................................. 20 71 +7. Conceptual model of MVQM ........................................................................................... 21 72 7.1. General ................................................................................................................. 21 73 7.2. Layered model of MVQM ....................................................................................... 22 74 7.2.1. General ..................................................................................................... 22 75 7.2.2. Description of the layers ............................................................................ 22 76 7.2.3. Architectural principles .............................................................................. 23 77 7.2.4. Hierarchical and Scalable Representation ................................................. 23 78 7.3. Functional architecture of MVQM........................................................................... 23 79 7.3.1. General ..................................................................................................... 23 80 7.3.2. Data Source Layer ..................................................................................... 24 81 7.3.3. Orchestration Layer ................................................................................... 24 82 7.3.4. Network Layer ........................................................................................... 25 83 7.3.5. Client Layer ............................................................................................... 25 84 7.3.6. Operational Workflow ................................................................................ 25 85 Annex A (informative) Gap analysis with the existing standards .......................................... 26 86 Annex B (informative) Relationship between MVQM and IEC TC110 standards................... 31 87 B.1 Scope of IEC TC110 standards ....................................................................................... 31 88 B.2 Scope of MVQM within IEC TC100 ................................................................................. 31 89 B.3 Fundamental differences between MVQM and TC110 standards..................................... 32 90 B.4 Complementary relationship ........................................................................................... 32 91 B.5 Summary ........................................................................................................................ 32 92 Annex C (informative) Relationship between MVQM and ISO/TC159/SC4/WG2 93 standards ....................................................................................................................... 33 94 C.1 Scope of ISO/TC159/SC4/WG2 standards ...................................................................... 33 95 XXX © IEC:202x – 3 – XXX © CEI:202x C.2 Scope of MVQM (IEC TC100) ......................................................................................... 33 96 C.3 Fundamental differences and non-overlapping scopes .................................................... 34 97 C.4 Complementary relationship ........................................................................................... 34 98 C.5 Conclusion ..................................................................................................................... 34 99 Bibliography .......................................................................................................................... 35 100 XXX © IEC:202x – 4 – XXX © CEI:202x INTERNATIONAL ELECTROTECHNICAL COMMISSION 103 ____________ 104 MANAGEMENT OF VISUAL QUALITY IN METAVERSE SYSTEMS 105 – PART 1: GENERAL 106 + +107 + +108 FOREWORD 109 + +1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all national 110 electrotechnical committees (IEC National Committees). The object of IEC is to promote international co -operation on all 111 questions concerning standardization in the electrical and electronic fields. To this end and in addition to other activities , IEC 112 publishes International Standards, Technical Specifications, Technical Reports, Publicly Available Specifications (PAS) and 113 Guides (hereafter referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; any IEC Natio nal 114 Committee interested in the subject dealt with may participate in this preparatory work. International, governmental and non 115 governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely with the 116 International Organization for Standardization (ISO) in accordance with conditions determined by agreement between the two 117 organizations. +118 + +2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international consensus of 119 opinion on the relevant subjects since each technical committee has representation from all interested IEC National Committee s. +120 + +3) IEC Publications have the form of recommendations for international use and are accepted by IEC National Committees in that 121 sense. While all reasonable efforts are made to ensure that the technical content of IEC Publications is accurate, IEC cannot 122 be held responsible for the way in which they are used or for any misinterpretation by any end user. +123 + +4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications transparently to th e 124 maximum extent possible in their national and regional publications. Any divergence between any IEC Publication and the 125 corresponding national or regional publication shall be clearly indicated in the latter. +126 + +5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity assessment 127 services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any services carried out by 128 independent certification bodies. +129 + +6) All users should ensure that they have the latest edition of this publication. +130 + +7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and members of its 131 technical committees and IEC National Committees for any personal injury, property damage or other damage of any nature 132 whatsoever, whether direct or indirect, or for costs (including legal fees) and expenses arising out of the publication, use of, or 133 reliance upon, this IEC Publication or any other IEC Publications. +134 + +8) Attention is drawn to the normative references cited in this publication. Use of the referenced publications is indispensable for 135 the correct application of this publication. +136 + +9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent rights. IEC 137 shall not be held responsible for identifying any or all such patent rights. +138 The IEC XXX has been prepared by the working group 12: Management of Visual Quality in Metaverse 140 Systems, of IEC technical committee 100: Audio, Video and Multimedia Systems and Equipment. +141 This publication has been drafted in accordance with the ISO/IEC Directives, Part 2. +142 The committee has decided that the contents of this publication will remain unchanged until the stability 143 date indicated on the IEC web site under "http://webstore.iec.ch" in the data related to the specific 144 publication. At this date, the publication will be 145 +- reconfirmed, 146 +- withdrawn, 147 +- replaced by a revised edition, or 148 +- amended. +149 The National Committees are requested to note that for this publication the stability date is .... +150 THIS TEXT IS INCLUDED FOR THE INFORMATION OF THE NATIONAL COMMITTEES AND WILL BE DELETED AT THE 151 PUBLICATION STAGE. +152 XXX © IEC:202x – 5 – XXX © CEI:202x INTRODUCTION 153 The rapid evolution of metaverse platforms and immersive services has led to a growing 154 demand for high-quality three-dimensional (3D) visual experiences delivered to multiple 155 concurrent users. Unlike traditional multimedia systems, metaverse environments require the 156 continuous delivery, rendering, and synchronization of complex visual information while 157 supporting real-time interaction among users represented by avatars in a shared virtual space. +158 In a metaverse system, visual information is not limited to a single media format or 159 representation. Instead, diverse types of visual assets coexist within the same environment, 160 including geometry-based objects, point-based representations, volumetric visual data, and 161 engine-based interactive assets. These visual assets differ significantly in terms of data 162 structure, scalability, computational requirements, and sensitivity to network conditions. As a 163 result, managing visual quality in a metaverse environment presents challenges that cannot be 164 adequately addressed by conventional video streaming or static quality control mechanisms. +165 Another defining characteristic of metaverse systems is the heterogeneity of user environments. +166 Users access the same virtual space through networks with varying bandwidth, latency, and 167 reliability, and through terminal devices with widely different processing capabilities, display 168 resolutions, and rendering performance. Furthermore, users may engage in different activities 169 at the same time, such as social interaction, object manipulation, or passive observation. These 170 factors cause the perceptual importance of visual information to vary dynamically across users 171 and over time. +172 In such environments, visual quality cannot be treated as a fixed or uniform system parameter. +173 Instead, it must be managed adaptively by considering user context, system conditions, and 174 the relative importance of visual information within the virtual scene. Efficient allocation of visual 175 resources is therefore essential to maintaining immersion and usability while avoiding 176 unnecessary consumption of network and computational resources. +177 To address these challenges, this Technical Report introduces the concept of Management of 178 Visual Quality in Metaverse Systems (MVQM). MVQM represents a user-centric and context179 aware approach to visual quality management, aiming to dynamically adapt visual data delivery 180 according to changing user behavior, device capabilities, and network conditions. Rather than 181 prescribing specific algorithms or implementations, MVQM provides a conceptual foundation for 182 understanding how visual quality can be managed systematically in complex metaverse 183 environments. +184 This document is Part 1 of the MVQM series and serves as a Technical Report (TR). It focuses 185 on general considerations, motivations, and representative concepts related to visual quality 186 management in metaverse systems. Detailed quantitative requirements and performance 187 metrics are specified in Part 2, while the functional architecture and framework for implementing 188 MVQM are defined in Part 3. Together, these documents establish a coherent and extensible 189 basis for the standardization of visual quality management in metaverse systems. +190 This IEC xxxx series consists of the following parts, under the general title Management of 191 Visual Quality in Metaverse Systems: +192 + +- Part 1: General; +193 + +- Part 2: Requirements; +194 + +- Part 3: Framework. +195 Part 1 of IEC xxxx, which is a Technical Report (TR), describes general considerations, 196 motivations, and representative use cases for the management of visual quality in metaverse 197 systems. +198 Part 2 of IEC xxxx, which is an International Standard (IS), specifies the quantitative 199 performance requirements and functional metrics (KPIs) necessary to ensure the high-fidelity 200 and low-latency delivery of hybrid visual assets. +201 XXX © IEC:202x – 6 – XXX © CEI:202x Part 3 of IEC xxxx, which is an International Standard (IS), specifies the 4-layer reference 202 architecture, the definitions of logical functional entities, and the formal interface specifications 203 (IF-1 to IF-4) required to implement a synchronized MVQM framework. +204 XXX © IEC:202x – 7 – XXX © CEI:202x MANAGEMENT OF VISUAL QUALITY IN METAVERSE SYSTEMS 206 – PART 1: GENERAL 207 + +208 + +1. Scope 209 This Technical Report describes general considerations, motivations, and representative 210 concepts for the management of visual quality in metaverse systems. This document does not 211 specify quantitative performance requirements, functional entities, or implementation 212 architectures, which are addressed in other parts of the MVQM series. +213 + +2. Normative references 214 None 215 + +3. Definitions and terminology 216 This clause provides the essential terms and definitions required to understand the general 217 concepts, motivations, and illustrative discussions presented in this Technical Report. The 218 definitions in this clause are intentionally limited to conceptual and architectural notions that 219 are referenced throughout Part 1. +220 NOTE Detailed definitions of implementation-specific functional entities, algorithms, and 221 interface parameters are specified in IEC xxxx‑2 (Part 2: Requirements) and IEC xxxx‑3 (Part 222 3: Framework) and are therefore outside the primary scope of this clause. +223 For the purposes of this document, the following terms and definitions apply. +224 3.1. Definitions 225 3.1.1. Management of Visual Quality in Metaverse Systems (MVQM) +226 A conceptual and functional approach for managing the visual quality of metaverse systems by 227 dynamically adapting visual data delivery in response to user context, device capability, and 228 network conditions. +229 NOTE 1 MVQM focuses on user‑centric and context‑aware quality management rather than 230 static or system‑centric optimization. +231 NOTE 2 The detailed architectural realization of MVQM is specified in IEC xxxx‑3. +232 3.1.2. Hybrid Visual Asset (HVA) +233 A logical visual asset that integrates one or more heterogeneous visual representations into a 234 single coherent entity for synchronized delivery and rendering within a metaverse environment. +235 NOTE 1 Heterogeneous representations may include geometry‑based, point‑based, volumetric, 236 or engine‑based visual components. +237 NOTE 2 The internal structure and processing of HVA are described in IEC xxxx‑3.. +238 3.1.3. Visual Quality 239 The level of visual experience perceived by a user when interacting with visual information in a 240 metaverse system. Visual quality may be influenced by spatial resolution, temporal resolution, 241 visual fidelity, and rendering consistency, as well as by perceptual factors related to user 242 context and interaction. +243 3.1.4. Area of Interest (AoI) +244 A spatial region within the virtual environment that is considered perceptually or functionally 245 relevant to a user at a given moment. +246 NOTE AoI is a conceptual construct used to identify visual regions that may warrant 247 differentiated quality treatment. +248 XXX © IEC:202x – 8 – XXX © CEI:202x 3.1.5. Level of Detail (LOD) +249 A discrete representation level corresponding to a specific degree of visual fidelity for a visual 250 asset. LOD selection may vary dynamically in response to contextual factors such as user 251 proximity, viewing direction, or system constraints. +252 3.1.6. Orchestration 253 A high‑level coordination process that manages the collection of contextual information and the 254 adaptation of visual quality across multiple system components. +255 NOTE The concrete orchestration mechanisms and entities are defined in IEC xxxx‑3 256 3.1.7. Telemetry 257 Contextual and status information reported by system components to support adaptive visual 258 quality management. Telemetry may include user‑related information, device capability 259 indicators, or network condition metrics. +260 A process in which measurements are made at some remote location and the results are 261 transmitted by telecommunication. (https://www.electropedia.org) +262 3.1.8. Control Plane 263 The logical domain responsible for signaling, coordination, and decision exchange related to 264 visual quality management. +265 3.1.9. Data Plane 266 The logical domain responsible for the transmission and delivery of visual data streams. +267 3.1.10. Reference Point 268 A conceptual interaction point that enables information exchange between logical domains or 269 system components. +270 A virtual point at the interface between two non-overlapping functional groups. +271 (https://www.electropedia.org) +272 NOTE Reference points are defined abstractly in this Technical Report and specified in detail 273 in IEC xxxx‑3. +274 3.2. Abbreviations 275 3.2.1. AoI 276 Area of Interest 277 3.2.2. ASE 278 Adaptive Streaming Entity 279 3.2.3. CCE 280 Client Control Entity 281 3.2.4. CG 282 Computer Graphics 283 3.2.5. CHIE 284 Client Hybrid Integration Entity 285 3.2.6. CPU 286 Central Processing Unit 287 3.2.7. CSRE 288 Client Stream Receiving Entity 289 XXX © IEC:202x – 9 – XXX © CEI:202x 3.2.8. GPU 290 Graphics Processing Unit 291 3.2.9. HEVC 292 High Efficiency Video Coding 293 3.2.10. HMD 294 Head-Mounted Display 295 3.2.11. HVA 296 Hybrid Visual Asset 297 3.2.12. IF 298 Interface (Reference Point) +299 3.2.13. IOE 300 Intelligent Orchestration Engine 301 3.2.14. KPI 302 Key Performance Indicator 303 3.2.15. LOD 304 Level of Detail 305 3.2.16. MIV 306 MPEG Immersive Video 307 3.2.17. MVQM 308 Management of Visual Quality in Metaverse Systems 309 3.2.18. NDE 310 Network Delivery Entity 311 3.2.19. NIE 312 Network Information Entity 313 3.2.20. NMCE 314 Network Management and Control Entity 315 3.2.21. OCDE 316 Orchestration Command Dispatch Entity 317 3.2.22. OQDE 318 Optimal Quality Decision Entity 319 3.2.23. PBR 320 Physically Based Rendering 321 3.2.24. PME 322 Policy Management Entity 323 3.2.25. PWCE 324 Priority Weight Calculation Entity 325 3.2.26. P0~P3 326 Priority Class 0 to Priority Class 3 327 XXX © IEC:202x – 10 – XXX © CEI:202x 3.2.27. QoE 328 Quality of Experience 329 3.2.28. QoS 330 Quality of Service 331 3.2.29. RTT 332 Round-Trip Time 333 3.2.30. SDCE 334 Streaming Delivery Control Entity 335 3.2.31. SDME 336 Spatial Data Management Entity 337 3.2.32. SIAE 338 State Information Aggregation Entity 339 3.2.33. SLA 340 Service Level Agreement 341 3.2.34. SPE 342 State Prediction Entity 343 3.2.35. SRE 344 Streaming Resource Entity 345 3.2.36. TRE 346 Telemetry Reporting Entity 347 3.2.37. UHRE 348 Unified Hybrid Rendering Engine 349 3.2.38. V-PCC 350 Video-based Point Cloud Compression 351 + +4. Considerations on MVQM 353 4.1. Motivation 354 Metaverse systems deliver immersive services by integrating a wide range of visual assets that 355 must be rendered and synchronized in real time for multiple concurrent users. These assets 356 include geometry-based objects, point-based representations, volumetric visual data, and 357 engine-native interactive components, all of which coexist within a shared three-dimensional 358 space. Unlike conventional multimedia services, the visual workload in a metaverse is inherently 359 spatial, interactive, and user-dependent, requiring continuous adaptation as users navigate, 360 observe, and interact within the environment. Consequently, visual quality in a metaverse 361 system cannot be treated as a static property of media content, but must be managed 362 dynamically at the system level [1]. +363 At the same time, the visual data required to support immersive experiences—such as 360364 degree coverage and six degrees of freedom (6DoF) navigation—results in extremely large data 365 volumes. Although compression and scalable representations are commonly employed, 366 transmitting and rendering full-fidelity visual data for all users and all visual assets is neither 367 feasible nor efficient. Users connect to the same metaverse environment through 368 heterogeneous networks and devices with widely varying bandwidth, latency, processing 369 capability, and display performance. Without adaptive control, high-capacity visual data may be 370 XXX © IEC:202x – 11 – XXX © CEI:202x delivered to terminals that cannot utilize it, while users on constrained networks may experience 371 interruptions or degraded visual continuity. These limitations motivate the need for a systematic 372 mechanism that manages visual quality in accordance with network conditions, device 373 capabilities, and user context. +374 Therefore, strategies are required for the efficient delivery of visual data in metaverse systems 375 to users who connect through networks with varying bandwidth and who employ devices with 376 different performance capabilities. For example, when users access the system through narrow377 bandwidth networks, it is necessary to avoid transmitting the entire high-capacity visual data. +378 Instead, only the portion of data that can be effectively transmitted within the available 379 bandwidth should be delivered. Even if only part of the data is transmitted, the system must 380 ensure seamless playback on the user’s display device and maintain the highest possible visual 381 quality within the given constraints. Another example is when user devices have limited 382 performance capabilities, such as restricted screen resolution, frame rate, or other device 383 specific limitations. In such cases, the metaverse system should transmit only the portion of 384 visual data that corresponds to the playback capacity of the device, avoiding unnecessary 385 transmission of data that cannot be reproduced. This requires algorithms and mechanisms that 386 dynamically adapt the delivery of visual information to match both network and device 387 conditions. +388 Beyond network and device constraints, a fundamental challenge for visual quality management 389 in metaverse systems arises from the increasing heterogeneity of visual information. The visual 390 content constituting a metaverse environment is no longer produced using a single 391 representation or processing model, but instead integrates multiple types of visual assets with 392 inherently different characteristics. Such heterogeneity introduces additional complexity in 393 managing visual quality in a consistent and efficient manner, as different asset types may 394 exhibit distinct requirements in terms of representation, processing, and scalability. As a result, 395 traditional uniform approaches to visual quality control become insufficient in metaverse 396 environments, motivating the need for a unified quality management framework capable of 397 accommodating heterogeneous visual assets. +398 Furthermore, an emerging challenge in metaverse systems is that the perceived importance of 399 visual information is highly dependent on the real-time context of the user. Unlike conventional 400 multimedia services, where visual quality requirements can often be defined statically, 401 metaverse environments require visual quality to adapt continuously as users move, observe, 402 and interact within a three-dimensional space. This dynamic and user-dependent nature of 403 visual perception implies that visual quality management must go beyond static or system404 centric optimization and instead consider user context as a key motivating factor. The need to 405 account for such context-aware variability in visual importance provides a strong motivation for 406 the development of MVQM, which aims to allocate visual resources in a manner that is 407 responsive to real-time user behavior. +408 4.2. Metaverse system with multiple users using various networks and devices 409 In a metaverse system, multiple users may access and utilize diverse services simultaneously, 410 as conceptually illustrated in Figure 1. These users may connect through different types of 411 networks, which can provide widely varying bandwidth capacities. Such variations in bandwidth 412 lead to significant differences in the quality of visual information experienced by each participant. +413 ⚫ A participant connected via a wireless network with narrow bandwidth may experience 414 frequent visual interruptions and distortions, since the transmitted visual data cannot be 415 delivered within the required time. As a result, the user’s display may freeze or the visual 416 content may appear corrupted. +417 ⚫ A participant connected via a broadband network may experience high-quality and stable 418 visual information. +419 XXX © IEC:202x – 12 – XXX © CEI:202x In addition to network conditions, the performance of user terminals, such as head-mounted 424 displays (HMDs), differs significantly among participants. These differences influence both the 425 amount of visual information that can be processed and the quality of visual content that can 426 be rendered. +427 ⚫ A participant using a low-performance HMD may only be able to process reduced-resolution 428 or compressed visual information, resulting in limited quality of experience. +429 ⚫ A participant using a high-performance HMD, in combination with a broadband network, 430 may experience immersive, high-resolution visual content with minimal distortion. +431 To address these heterogeneous environments, there is a need for MVQM (Management of 432 Visual Quality in Metaverse Systems) to allocate and manage resources efficiently. MVQM 433 enables adaptive transmission of visual data by considering both network bandwidth and device 434 performance, ensuring reliable service provision and preventing inefficiencies caused by 435 unnecessary transmission of unsupported data. +436 4.3. Heterogeneous production methods of visual objects in metaverse systems 437 The visual environment of a metaverse system is characterized by the integration of Hybrid 438 Visual Assets (HVA) produced through a wide variety of technical representation methods. +439 Unlike traditional 2D video services, a single metaverse scene typically comprises 440 heterogeneous data formats, each with distinct characteristics: +441 ⚫ Diverse Data Types: User avatars may be represented as high-fidelity computer graphics 442 (CG) or engine-native functional assets (e.g., Unity Prefabs); distant environments and 443 architectural structures may be constructed using point clouds derived from LiDAR or 444 photogrammetry; and interactive foreground objects, such as vehicles or tools, are often 445 represented as polygonal meshes. +446 + +![Figure 1. A metaverse system with multiple users using various networks and devices 423](assets/images/figure_1_p11.png) + +XXX © IEC:202x – 13 – XXX © CEI:202x ⚫ Divergent Compression and Scalability: Each of these technical representations employs 447 different compression standards (e.g., Draco for meshes, V-PCC for point clouds, or HEVC 448 for volumetric video) and different mechanisms for providing Level of Detail (LOD) scalability. +449 For example, point clouds utilize Octree-based spatial partitioning, while meshes rely on 450 discrete LODs or progressive encoding [2][3]. +451 Need for Standardization: To maintain a cohesive and high-quality immersive experience, it is 452 essential to standardize how these diverse data types are managed within a unified framework. +453 MVQM provides the necessary orchestration to ensure that quality adaptation is applied 454 effectively across these disparate formats, preventing visual inconsistencies and optimizing the 455 utilization of system resources. +456 4.4. Context-aware visual quality management based on avatar behavior 457 In a metaverse system, the perceived importance of visual information is highly dynamic and 458 depends on the real-time context and behavior of the user’s avatar. Consequently, visual quality 459 management should not be static but must adapt according to the following contextual factors: +460 ⚫ Gaze-contingent Priority: The system should prioritize the visual quality of assets within the 461 user's central field of vision. By applying a Gaze-contingent Weight, high-resolution data is 462 delivered to the focal region, while peripheral areas are provided at a lower quality to 463 conserve bandwidth. +464 ⚫ Proximity-based Management: Visual fidelity should be managed based on the spatial 465 distance between the avatar and virtual objects. Objects in close proximity to the avatar 466 require high-detail representations for interaction, whereas distant backgrounds and 467 buildings can be represented at a lower LOD without significantly impacting the user's sense 468 of presence. +469 ⚫ Activity-aware Optimization: The quality of visual assets should be tailored to the avatar’s 470 current activity. For instance, in a social interaction scenario, high-fidelity resources should 471 be allocated to the facial expressions and movements of counterpart avatars. In an 472 exploration scenario, the system may prioritize the environmental assets in the direction the 473 avatar is walking. +474 Need for Standardization: To enable this personalized experience, there is a need to 475 standardize the "Sense-Analyze-Adapt" loop that captures avatar telemetry and calculates 476 priority scores based on these multi-dimensional contextual weights. MVQM establishes the 477 functional entities and interfaces required to perform this context-aware orchestration in real 478 time, ensuring that visual quality is always optimized for the user's current situational needs . +479 + +5. Adaptation with MVQM 481 This clause organizes the key adaptation dimensions of MVQM by categorizing how visual 482 quality can be adjusted according to network conditions, device capabilities, asset 483 characteristics, and avatar context, providing a conceptual bridge between the considerations 484 discussed in Clause 4 and the example scenarios presented in Clause 6. +485 5.1. Bandwidth-aware adaptation 486 ⚫ The system shall not transmit full-capacity visual data to users connected via narrow487 bandwidth networks, as this may result in transmission failures, screen distortion, or 488 playback interruption. +489 ⚫ Instead, MVQM shall deliver only the portion of visual data that fits within the transmission 490 capacity of the network. +491 ⚫ MVQM shall incorporate algorithms or strategies to maximize perceived visual quality within 492 the limited data capacity. +493 5.2. Device capability-based adaptation 494 ⚫ The system shall not transmit visual data beyond the rendering capacity of the user’s device. +495 XXX © IEC:202x – 14 – XXX © CEI:202x ⚫ For example, if the terminal supports only 2K resolution, the system shall not transmit 4K 496 data; only data up to 2K resolution shall be delivered. +497 ⚫ Similarly, if the terminal supports only a 30 Hz frame rate, the system shall not transmit 60 498 Hz video data, but only data aligned with 30 Hz. +499 ⚫ By transmitting only what user devices can reproduce, the system shall ensure efficient 500 resource management and reduced service complexity. +501 5.3. Object-specific adaptation based on production methods 502 The visual environment of a metaverse system is composed of Hybrid Visual Assets (HVA) +503 created through various production techniques, such as polygonal meshes, point clouds, 504 volumetric videos, and engine-native functional assets. Since each technical representation has 505 different data structures and compression characteristics, MVQM shall apply differentiated 506 adaptation strategies. +507 ⚫ Adaptation for Polygonal Meshes: The system shall support discrete Levels of Detail (LOD) +508 or progressive mesh encoding. For distant objects or low-resource terminals, the Adaptive 509 Streaming Entity (ASE) shall transmit simplified base meshes, while high-fidelity refinement 510 records shall be delivered only when the asset enters the user's primary focus. +511 ⚫ Adaptation for Point Clouds: The system shall utilize hierarchical data structures, such as 512 Octree-based spatial partitioning. The ASE shall dynamically adjust the point density by 513 transmitting bitstreams up to a specific Octree depth based on the available network 514 bandwidth and terminal rendering capacity. +515 ⚫ Adaptation for Volumetric and Realistic Video: For dynamic realistic surfaces, the system 516 shall employ Scalable Video Coding (SHVC) or tile-based partitioning (e.g., MIV). This 517 allows the delivery of a base layer for global visibility, with enhancement layers or specific 518 spatial tiles being added to increase resolution only for the user's current viewport. +519 ⚫ Adaptation for Functional/Engine Assets: For logic-infused assets (e.g., Unity Prefabs), the 520 system shall manage the lifecycle and script execution through priority-aware loading. The 521 Streaming Delivery Control Entity (SDCE) shall coordinate the activation of these assets 522 based on their functional relevance to the current session. +523 5.4. Adaptation based on the avatar's context 524 The MVQM framework shall dynamically adjust the visual quality of objects by calculating a 525 Priority Score derived from the real-time context of the user's avatar. This ensures that system 526 resources are concentrated where they provide the most significant impact on the user's 527 immersion. +528 ⚫ Gaze-contingent Adaptation: The system shall prioritize the visual quality of assets within 529 the user's central field of vision. Utilizing the Gaze-contingent Weight (𝑊𝑣𝑖𝑒𝑤), the Optimal 530 Quality Decision Entity (OQDE) shall assign high-quality tiers to objects at the focal point, 531 while assets in the peripheral area or behind the avatar are delivered at lower quality to 532 conserve bandwidth. +533 ⚫ Proximity-based Adaptation: The system shall adapt the Level of Detail (LOD) based on the 534 spatial distance (D) between the avatar and the virtual objects. Interactive objects near the 535 avatar shall be rendered with high geometric and texture fidelity, while distant backgrounds 536 and buildings shall be delivered as simplified representations to reduce transmission load. +537 ⚫ Activity-aware Adaptation: The system shall apply a Contextual Weight (𝑊𝑐𝑜𝑛𝑡𝑒𝑥𝑡) to adjust 538 quality according to the avatar’s current activity. For example: +539 ✓ In Social/Conversation Mode, high-fidelity resources shall be allocated to the facial 540 features and body movements of counterpart avatars. +541 ✓ In Exploration/Navigation Mode, the State Prediction Entity (SPE) shall forecast the 542 avatar's movement trajectory to pre-fetch and upscale environmental assets in the 543 direction of travel. +544 XXX © IEC:202x – 15 – XXX © CEI:202x ⚫ Predictive Quality Management: If network latency threatens to disrupt visual continuity, the 545 system shall utilize Predictive Adaptation to forecast the avatar’s future position and gaze 546 (typically with a 50 ms to 200 ms horizon), ensuring that high-quality data is ready for 547 rendering before the user's focus actually shifts. +548 5.5. Candidate items for standardization 549 The standardization of MVQM shall: +550 ⚫ provide mechanisms for managing visual information in a manner adaptive to the 551 capabilities of user devices (e.g., HMDs) and network conditions; +552 ⚫ define visual quality management and adaptation algorithms for various visual objects 553 based on their technical representation and production methods, including point clouds, 554 polygonal meshes, volumetric videos, and engine-native functional assets (e.g., Unity 555 Prefabs). +556 ⚫ specify visual quality management algorithms that dynamically adapt based on the avatar's 557 real-time context, such as spatial proximity (distance), gaze-contingent focal points, and 558 specific activity types (e.g., social interaction, exploration, or navigation). +559 (Editor’s Note) Requirements for MVQM will be described in Part 2. +560 + +6. Example scenarios for MVQM 562 6.1. Adaptive visual quality management using scalable bitstreams 563 + +_Figure 2 illustrates a conceptual model in which multiple users connected to a metaverse 564 system receive visual information of different qualities, depending on their network bandwidth 565 and terminal performance. In this use case, the visual information of the metaverse is assumed 566 to be represented in a scalable bitstream structure [2][3]. 567_ (이미지 추출 실패) + +![Figure 2. Example of scalable visual quality management in metaverse systems 569](assets/images/figure_2_p14.png) + +XXX © IEC:202x – 16 – XXX © CEI:202x When visual data are encoded as a scalable bitstream, portions of the bitstream can be 571 selectively transmitted to different users. This allows the system to provide varying amounts of 572 data and corresponding levels of visual quality according to the conditions of each participant. +573 By contrast, in non-scalable bitstreams, the failure to receive even a small portion of the data 574 may prevent any visual information from being displayed. With scalable bitstreams, however, 575 users can reconstruct and play visual content even if only part of the bitstream is received. In 576 such cases, the quality of the displayed content depends on how much of the bitstream is 577 available: partial data enable lower-quality rendering, while the full bitstream allows high-quality 578 playback. +579 For users connected through narrow-bandwidth networks or using low-performance devices, 580 transmitting the entire high-capacity visual data may result in delayed playback or failure to 581 display. In these situations, it is preferable to deliver only a subset of the scalable bitstream, 582 even at lower quality, to ensure continuous playback and service continuity. Conversely, 583 transmitting large-capacity data to devices that cannot utilize them results in wasted resources 584 and system inefficiency. +585 The example illustrated in Figure 2 can be described in more detail as follows: +586 ⚫ Participant 1 is connected through a narrowband network and is assumed to be using a 587 low-performance device. In this case, the Intelligent Orchestration Engine (IOE) determines 588 the quality tier, and the Adaptive Streaming Entity (ASE) transmits only the basic data 589 portion of the scalable bitstream, which represents low-resolution visual information. As a 590 result, Participant 1 experiences uninterrupted playback, albeit at reduced quality. +591 ⚫ Participant 2 is connected through a medium-bandwidth network. The quality management 592 module transmits both the basic data and additional data portions of the bitstream. By 593 combining these, Participant 2 can reconstruct higher-quality visual information than 594 Participant 1. +595 ⚫ Participant 3 is connected through a broadband network and is using a high-performance 596 device. In this case, the quality management module transmits the entire scalable bitstream, 597 including basic data, additional data, and enhancement data. With access to all layers of 598 the bitstream, Participant 3 experiences the highest-quality visual content with minimal 599 distortion. +600 Through this scenario, the metaverse visual quality management module demonstrates the 601 ability to deliver differentiated visual services according to user network conditions and device 602 capabilities. At the same time, this approach enables efficient utilization of system resources, 603 ensuring that unnecessary data are not transmitted to users who cannot process them. +604 From a conceptual viewpoint, the adaptive behavior illustrated in this scenario can be 605 understood as the result of coordinated functions operating across multiple logical domains of 606 an MVQM system. The preparation of scalable visual representations, the assessment of 607 network and device conditions, and the selection of appropriate visual quality levels are 608 performed as distinct but interrelated functions within the overall system. +609 Although these functions are described here at a scenario level without reference to specific 610 system components, they are conceptually aligned with the layered organization and functional 611 roles defined in the MVQM framework. The relationships among these functional domains are 612 further formalized through a layered model and a functional architecture, which are specified in 613 Parts 2 and 3 of this document series. +614 XXX © IEC:202x – 17 – XXX © CEI:202x 6.2. Object- and region-based visual quality control using scalable bitstreams 615 Metaverse systems are composed of a large number of visual objects distributed across a three618 dimensional virtual space. These objects differ in geometric complexity, spatial extent, update 619 frequency, and perceptual relevance. To manage such complexity efficiently, MVQM adopts an 620 object- and region-based approach to visual quality control, in which visual assets are treated 621 as independently addressable units and spatially organized regions. +622 In this approach, visual assets are logically divided into objects and spatial regions, allowing 623 the system to selectively manage their visual representations. An object may correspond to an 624 individual entity such as an avatar, an interactive item, or a structural component of the 625 environment, while a region represents a spatial grouping of multiple objects within a defined 626 area of the virtual space. This distinction enables the system to apply different visual quality 627 levels to different parts of the scene, rather than uniformly treating the entire visual space. This 628 object- and region-based organization of visual assets, together with differentiated visual quality 629 levels, is conceptually illustrated in Figure 3, which shows how multiple visual elements within 630 a metaverse scene can be managed with heterogeneous quality assignments. +631 To support such selective control, MVQM assumes the use of scalable visual data structures. +632 Visual assets are encoded or represented in a manner that allows partial transmission and 633 reconstruction, such as discrete Levels of Detail (LOD), hierarchical spatial partitioning, or 634 progressive refinement. For example, polygonal meshes may support multiple LODs, point 635 clouds may be organized using hierarchical structures such as octrees, and volumetric or video 636 based assets may provide layered or tile-based representations. These scalable bitstreams 637 allow the system to adjust visual fidelity incrementally without requiring full retransmission of 638 assets. +639 Region-based control further enables the system to associate different quality levels with 640 different spatial areas. A region of interest may be defined as a subset of the virtual environment 641 for which higher visual fidelity is desirable, while other regions may be delivered at lower quality. +642 + +![Figure 3. Example of object-focused visual quality control in metaverse systems 617](assets/images/figure_3_p16.png) + +XXX © IEC:202x – 18 – XXX © CEI:202x At this level, the concept of a region is treated in a structural sense, providing a mechanism for 643 grouping and managing visual data spatially, rather than prescribing how or why a specific 644 region is selected. +645 By combining object-based control, region-based partitioning, and scalable representations, 646 MVQM establishes a technical framework for flexible and efficient visual quality management. +647 This framework provides the structural mechanisms for quality control and is independent of 648 specific user behaviors. Based on this framework, higher-level user-centric quality decisions— 649 such as those derived from avatar gaze direction, interaction, or contextual information —can 650 be applied, as described in subsequent clauses. +651 6.3. Multi-source visual data management and adaptive composition 652 + +Figure 4 presents another example of MVQM use cases. In this scenario, the visual information 653 composing the metaverse system is partially generated using different devices and software 654 tools. For instance, the distant city background may be produced from drone camera footage 655 (Data Type 1). Avatars representing users and robots flying in the sky may be created using 656 Unity tools (Data Type 2). The background space may be generated through computer graphics 657 (Data Type 3), while the large warship on the left-hand side may be derived from LiDAR-based 658 imaging (Data Type 4). The terrain on which the avatars are standing may be constructed from 659 infrared sensor data (Data Type 5), and the buildings on the right may be synthesized from 660 optical camera footage (Data Type 6). +661 MVQM, while managing visual information in metaverse systems, can distinguish, separate, 662 and selectively combine these different data types for transmission. This capability serves 663 multiple purposes: adapting the total data volume to the bandwidth of user networks, 664 differentiating between regions or objects that users focus on versus those they do not, or 665 enabling the dynamic reconstruction of scenes according to user preferences. +666 + +![Figure 4. Example of MVQM using heterogeneous visual data sources 669](assets/images/figure_4_p17.png) + +_Figure 5 further complements the use case illustrated in Figure 4. In this case, MVQM adapts 670 visual information not only based on network bandwidth and device performance but also 671 according to user-specific customization. For example, the metaverse system may deliver to 672_ (이미지 추출 실패) + +XXX © IEC:202x – 19 – XXX © CEI:202x Participant 1 a visual data stream with part of Data Type 2 omitted. Upon receiving this 673 incomplete set, Participant 1 may reconstruct the missing region by synthesizing new objects, 674 such as a helicopter or alternative avatars, in place of the omitted data. +675 Through these functions, MVQM enables efficient management of heterogeneous visual 678 information, reduces unnecessary system resource usage, and supports adaptive scene 679 composition tailored to user conditions and preferences. +680 In this scenario, the visual objects composing the metaverse environment may be represented 681 using different underlying representation technologies, such as polygonal meshes, point clouds, 682 volumetric video, or engine-based visual assets. Since these representation types exhibit 683 different structural characteristics, the mechanisms available for scalability and visual quality 684 adaptation also differ. +685 For example, mesh-based objects typically support scalability through discrete levels of detail 686 or progressive refinement, allowing geometric complexity to be adjusted according to system 687 constraints. Point cloud–based objects often employ hierarchical spatial structures, enabling 688 the selective transmission of point density for different regions. Volumetric or video-based 689 visual objects may support scalability through spatial, temporal, or quality-based layering, while 690 engine-based assets may rely on asset-level selection, shader complexity control, or texture 691 resolution adjustment. +692 + +![Figure 5. Example of MVQM enabling user-specific customization of visual data 677](assets/images/figure_5_p18.png) + +XXX © IEC:202x – 20 – XXX © CEI:202x MVQM accommodates these heterogeneous scalability mechanisms by managing visual quality 693 at an abstract level, without assuming a uniform adaptation method across all visual object 694 types. In this context, MVQM can apply different visual quality management strategies to 695 individual objects or regions, depending on their representation characteristics, importance 696 within the scene, and relevance to the user. +697 By enabling differentiated visual quality control across heterogeneous visual object types, 698 MVQM supports efficient resource utilization while preserving visual coherence within the 699 composed scene. This capability is particularly important in metaverse environments where 700 visual content is generated from multiple sources using diverse creation pipelines and sensing 701 technologies. +702 6.4. Visual quality management based on avatar context 703 While object- and region-based visual quality control provides the structural means to vary 704 visual fidelity, effective management of visual quality in metaverse systems ultimately depends 705 on the dynamic context of the user’s avatar. Visual importance is not static; it changes 706 continuously according to how the user perceives, navigates, and interacts within the virtual 707 environment. MVQM therefore emphasizes avatar context as a primary driver for visual quality 708 decisions. +709 Avatar context encompasses multiple dimensions of user state, including viewing direction, 710 spatial position, movement, and interaction activity. Among these, viewing direction plays a 711 critical role in determining perceptual relevance. Visual assets that fall within or near the 712 avatar’s current field of view tend to have a higher impact on perceived immersion than assets 713 located outside the viewing direction. Consequently, visual quality management decisions may 714 prioritize assets that align with the avatar’s gaze while deprioritizing those in peripheral or non 715 visible areas. +716 Spatial proximity is another important contextual factor. Objects located close to the avatar are 717 more likely to support interaction or detailed observation and therefore require higher visual 718 fidelity. In contrast, distant objects often contribute primarily to background context and may 719 tolerate reduced visual detail. Importantly, proximity-based relevance is not absolute; it may 720 vary depending on the user’s activity and intent within the metaverse environment. +721 Avatar activity further refines visual quality decisions. For example, when an avatar is engaged 722 in a conversation or focused interaction with another entity, the visual quality of relevant avatars 723 or objects may be emphasized, while surrounding environmental details may be deemphasized. +724 Conversely, when the avatar is exploring or observing the environment, broader spatial regions 725 may require more balanced visual quality allocation. These distinctions illustrate that visual 726 quality management must account not only for spatial factors but also for the functional role of 727 visual information in the user’s current activity. +728 By incorporating avatar context into visual quality management, MVQM adopts a user-centric 729 adaptation paradigm. Decisions regarding visual fidelity are driven by real-time changes in user 730 state, rather than fixed system-level rules. This context-aware perspective complements the 731 structural mechanisms described in Clause 6.2 and forms the conceptual basis for closed -loop 732 orchestration and priority-based decision-making, which are further elaborated in the 733 architectural framework described in Part 3. +734 (Editor’s Note) Specific framework for MVQM will be described in detail in Part 3. +735 XXX © IEC:202x – 21 – XXX © CEI:202x + +7. Conceptual model of MVQM 737 7.1. General 738 + +Figure 6 illustrates the high-level conceptual model of the Management of Visual Quality in 741 Metaverse Systems (MVQM) within a layered metaverse environment. This conceptual view 742 focuses on how visual quality is dynamically managed in response to user context, without 743 assuming any specific implementation architecture or protocol. The model serves as an intuitive 744 foundation for understanding the motivation and rationale behind the layered reference model 745 and functional framework specified in subsequent parts of this series [1]. +746 In the conceptual model shown in Figure 6, a user accesses the metaverse system through a 747 terminal device such as a head-mounted display (HMD), personal computer, or smartphone, 748 connected via a wired or wireless communication network. Within the virtual environment, the 749 user is represented by an avatar that navigates and interacts in a shared three-dimensional 750 space. As the avatar moves, changes viewing direction, or engages in different activities (e.g. +751 communication, observation, or interaction), the visual information required by the user varies 752 continuously. This implies that visual quality cannot be statically defined, but must be adaptively 753 managed according to the user’s real-time context. +754 From the perspective of visual quality management, Figure 6 highlights that not all visual objects 755 and regions in the metaverse have equal perceptual importance at a given moment. Visual 756 assets located within the avatar’s current viewing direction, close proximity, or active interaction 757 region require higher visual fidelity, whereas assets that are distant, occluded, or outside the 758 user’s field of view may be delivered at a reduced quality without significantly degrading 759 perceived immersion. MVQM conceptually addresses this challenge by enabling selective 760 allocation of visual quality based on contextual relevance, thereby improving the efficiency of 761 network and computational resource usage. +762 + +![Figure 6. Conceptual model of MVQM within a layered metaverse system 740](assets/images/figure_6_p20.png) + +_Figure 6 also emphasizes the coexistence of heterogeneous visual asset types —such as 763 polygonal meshes, point clouds, volumetric video, and engine-based assets—within a single 764 metaverse environment. These Hybrid Visual Assets (HVA) differ in representation, scalability 765 mechanisms, and processing requirements. The conceptual model assumes that effective 766_ (이미지 추출 실패) + +XXX © IEC:202x – 22 – XXX © CEI:202x visual quality management must operate across these heterogeneous assets in a unified 767 manner, allowing the system to coordinate quality adaptation consistently despite differences 768 in data formats or production methods. +769 Furthermore, the conceptual model implicitly reflects the closed-loop nature of MVQM operation. +770 User behavior and device conditions influence visual quality decisions, and the resulting visual 771 presentation in turn affects user perception and interaction. Although the detailed sensing, 772 decision-making, and adaptation mechanisms are not defined at this level, Figure 6 establishes 773 the principle that visual quality management in metaverse systems is inherently user -centric, 774 dynamic, and context-aware. +775 In summary, Figure 6 provides a conceptual overview of MVQM as a user-driven visual quality 776 management paradigm operating within a layered metaverse system. Based on this conceptual 777 view, Clause 7.2 introduces a structured layered model to organize the system into logical 778 domains, while Clause 7.3 further elaborates a functional architecture that enables the practical 779 realization of MVQM concepts in interoperable systems. +780 7.2. Layered model of MVQM 782 7.2.1. General 783 To manage the complexity of streaming Hybrid Visual Assets (HVA) across heterogeneous 784 environments, the MVQM system adopts a four-layer reference model. This model provides a 785 structural foundation that partitions the system into distinct functional domains, ensuring 786 modularity, scalability, and independent evolution of each layer. The model is designed to 787 maintain a consistent Quality of Experience (QoE) for multiple concurrent users by balancing 788 high-fidelity visualization with low-latency interaction. +789 7.2.2. Description of the layers 790 The MVQM reference model consists of the following four logical layers: +791 + +![Figure 7. Structural diagram of the MVQM four-layer reference model 793](assets/images/figure_7_p21.png) + +XXX © IEC:202x – 23 – XXX © CEI:202x ⚫ Data Source Layer: This layer is responsible for the lifecycle management and adaptive 794 delivery of Hybrid Visual Assets (HVA). It handles the persistent storage and spatial 795 indexing of various data formats, including polygonal meshes, point clouds, and volumetric 796 videos. Based on orchestration commands, it dynamically adjusts encoding parameters to 797 match user-specific context. +798 ⚫ Orchestration Layer: Acting as the central intelligence hub, this layer performs high-level 799 quality decisions and resource coordination. It aggregates real-time state metadata from all 800 layers, calculates user-centric priority weights (e.g., based on gaze and proximity), and 801 determines the optimal Level of Detail (LOD) for each asset. +802 ⚫ Network Layer: This layer ensures the reliable and prioritized delivery of HVA bitstreams . It 803 continuously monitors network performance indicators (KPIs) such as bandwidth, latency, 804 and jitter, and applies Quality of Service (QoS) policies to prioritize critical data packets. +805 ⚫ Client Layer: The termination point of the framework where user interaction is captured and 806 the final scene is reconstructed. It reports multimodal telemetry (gaze, position), integrates 807 disparate data formats into a unified 3D coordinate system, and executes high-fidelity 808 rendering through a unified rendering engine. +809 7.2.3. Architectural principles 810 The layered model of MVQM is governed by the following core principles to ensure 811 interoperability and performance: +812 ⚫ Layered Modularity: Each layer performs specialized tasks through standardized interfaces. +813 This independence allows technical evolutions in one layer (e.g., upgrading a rendering 814 engine in the Client Layer) without necessitating changes in other layers. +815 ⚫ Decoupling of Control and Data Planes: The architecture enforces a strict logical separation 816 between the Control Plane (signaling for orchestration and telemetry) and the Data Plane 817 (high-throughput content delivery). This prevents heavy media traffic from interfering with 818 time-critical orchestration signaling. +819 ⚫ Closed-loop Operation: The model supports a continuous "Sensing-Decision-Action" loop. +820 Telemetry gathered from the Client and Network layers is processed by the Orchestration 821 Layer to dispatch adaptation commands back to the Data Source and Client layers in real 822 time. +823 ⚫ Scalability for Multi-user Environments: The model is designed to handle multiple users with 824 disparate device capabilities and network conditions by individualized priority scoring and 825 quality tier mapping. +826 7.2.4. Hierarchical and Scalable Representation 827 To support the dynamic adaptation across these layers, the model assumes that Hybrid Visual 828 Assets are structured in a scalable or hierarchical format (e.g., Octree-based point clouds or 829 LOD-based meshes). This enables the system to transmit only the necessary portions of the 830 bitstream that match the available network bandwidth and terminal performance. +831 7.3. Functional architecture of MVQM 833 7.3.1. General 834 The functional architecture of MVQM is designed to optimize the visual experience for multiple 835 users in a metaverse system by dynamically managing Hybrid Visual Assets (HVA). The 836 architecture adopts a 4-layer reference model consisting of the Data Source Layer, 837 Orchestration Layer, Network Layer, and Client Layer, which collectively maintain a closed-loop 838 "Sensing-Decision-Action" cycle. +839 To ensure responsiveness, the architecture enforces a strict separation between the Control 840 Plane (signaling via IF-1, IF-2, and IF-3) and the Data Plane (high-throughput streaming via IF841 4). +842 XXX © IEC:202x – 24 – XXX © CEI:202x 7.3.2. Data Source Layer 846 The Data Source Layer is responsible for the lifecycle management and adaptive streaming of 847 HVAs. It consists of the following functional entities: +848 ⚫ Spatial Data Management Entity (SDME): Acts as the repository for heterogeneous 3D data 849 (Mesh, Point Cloud, Volumetric Video) and provides spatial indexing to discover assets 850 within a user's Area of Interest (AoI). +851 ⚫ Streaming Resource Entity (SRE): Monitors the operational health and resource utilization 852 (CPU/GPU load) of the streaming modules. +853 ⚫ Adaptive Streaming Entity (ASE): Performs multi-modal bitstream generation and 854 dynamically switches between Levels of Detail (LOD) or quality tiers. +855 ⚫ Streaming Delivery Control Entity (SDCE): Interprets adaptation commands from the 856 Orchestration Layer and configures the ASE for specific users and objects. +857 7.3.3. Orchestration Layer 858 The Orchestration Layer serves as the central intelligence hub, coordinating real-time 859 adaptation and resource management. It is managed by the Intelligent Orchestration Engine 860 (IOE), which comprises: +861 ⚫ State Information Aggregation Entity (SIAE): Aggregates and normalizes multi-modal 862 metadata from all layers to maintain a unified "global state" of the session. +863 ⚫ Priority Weight Calculation Entity (PWCE): Calculates per-user priority scores (𝑊𝑡𝑜𝑡𝑎𝑙) for 864 assets based on factors such as gaze direction, spatial distance (proximity), and activity 865 context. +866 + +![Figure 8. Functional architecture diagram of the overall MVQM 844](assets/images/figure_8_p23.png) + +XXX © IEC:202x – 25 – XXX © CEI:202x ⚫ Optimal Quality Decision Entity (OQDE): Balances priority scores against network 867 bandwidth (𝐵𝑙𝑖𝑚𝑖𝑡) and device capabilities to select the optimal LOD for each asset. +868 ⚫ Orchestration Command Dispatch Entity (OCDE): Distributes finalized adaptation 869 instructions to the execution entities across the system. +870 ⚫ State Prediction Entity (SPE): Forecasts future user behavior and network trends (50 ms to 871 200 ms horizon) to enable proactive pre-fetching and resource allocation. +872 ⚫ Policy Management Entity (PME): Manages service-level agreements (SLA) and establishes 873 global governance rules for the session. +874 7.3.4. Network Layer 875 The Network Layer ensures the prioritized delivery of HVA bitstreams across the communication 876 infrastructure. +877 ⚫ Network Information Entity (NIE): Performs real-time measurement of network Key 878 Performance Indicators (KPIs) such as available bandwidth, RTT, and jitter. +879 ⚫ Network Management and Control Entity (NMCE): Translates high-level orchestration 880 instructions into specific network-level QoS policies. +881 ⚫ Network Delivery Entity (NDE): Executes traffic classification (P0 to P3) and physical 882 resource allocation to forward bitstreams from the Data Source to the Client. +883 7.3.5. Client Layer 884 The Client Layer captures user interaction and reconstructs the integrated hybrid scene for final 885 display. +886 ⚫ Telemetry Reporting Entity (TRE): Reports the user's spatial coordinates, gaze vectors, and 887 the terminal's hardware profile (CPU/GPU, resolution) to the Orchestration Layer. +888 ⚫ Client Control Entity (CCE): Interprets orchestration commands to coordinate local sensing 889 frequencies and device-tier transitions. +890 ⚫ Client Stream Receiving Entity (CSRE): Manages the ingestion and jitter buffering of 891 multiple heterogeneous data streams. +892 ⚫ Client Hybrid Integration Entity (CHIE): Aligns disparate asset types (e.g., Mesh and Point 893 Cloud) within a shared 3D coordinate system using temporal synchronization markers. +894 ⚫ Unified Hybrid Rendering Engine (UHRE): Executes high-fidelity rendering of the integrated 895 scene using a unified Physically Based Rendering (PBR) pipeline and shared depth 896 management. +897 7.3.6. Operational Workflow 898 The MVQM system operates through a continuous Sensing-Decision-Action loop. Telemetry 899 from the TRE and NIE is processed by the SIAE and analyzed by the PWCE and OQDE to 900 generate adaptation commands. These commands are dispatched by the OCDE to the SDCE, 901 NMCE, and CCE, ensuring that the visual quality delivered to the user is optimized for their 902 current context, available bandwidth, and device performance. +903 (Editor’s Note) MVQM functions and control flow will be described more in detail in Part 3. +905 XXX © IEC:202x – 26 – XXX © CEI:202x Annex A 908 (informative) +909 + +910 Gap analysis with the existing standards 911 This annex provides a gap analysis between existing relevant standards and the present 912 document. The tables below summarize international standards related to metaverse 913 technologies, categorized by standards developing organizations such as ITU-T, ISO/IEC, IEEE, 914 IETF, and 3GPP. As shown in the tables, there are currently no international standards that 915 address the same or similar topics as MVQM (Management of Visual Quality in Metaverse 916 Systems) described in this document. +917 Table A.1 provides a list of metaverse-related deliverables developed by the ITU-T Focus Group 918 on the Metaverse (FG-MV). The source of the information is the ITU-T FG-MV official website: +919 https://www.itu.int/en/ITU-T/focusgroups/mv/Pages/deliverables.aspx As shown in Table A.1, 920 the existing deliverables primarily address aspects such as the definition and conceptual 921 modeling of the metaverse, terminology, and frameworks for specific application domains (e.g., 922 power systems, chemical industrial parks, and other domain-specific metaverse systems). +923 While the ITU-T FG-MV has developed a broad range of technical specifications related to the 924 metaverse ecosystem, none of these deliverables explicitly address the management of visual 925 quality within metaverse systems. The proposed standard on Management of Visual Quality in 926 Metaverse Systems (MVQM) introduces a distinct and complementary scope, focusing 927 specifically on methods, frameworks, and requirements for visual quality management. +928 Therefore, no overlap or duplication exists between the MVQM proposal and the deliverables 929 developed by the ITU-T Focus Group on the Metaverse. +930 Table A.1 – List of standards on metaverse (ITU-T) +931 + +| | SDO | | | WG | | | Standard | | | Title | | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | +| ITU-T FG-MV | | | WG1 | | | FGMV-01 | | | Exploring the metaverse: opportunities and challenges | | | +| ITU-T FG-MV | | | WG1 | | | FGMV-02 | | | Metaverse: an analysis of definitions | | | +| ITU-T FG-MV | | | WG1 | | | FGMV-20 | | | Definition of metaverse | | | +| ITU-T FG-MV | | | WG1 | | | FGMV-21 | | | Principles for building concepts and definitions related to metaverse | | | +| ITU-T FG-MV | | | WG1 | | | FGMV-24 | | | A framework for confidence in the metaverse | | | +| ITU-T FG-MV | | | WG1 | | | FGMV-25 | | | Near-term and long-term Implications for people in the metaverse | | | +| ITU-T FG-MV | | | WG1 | | | FGMV-32 | | | Overview of metaverse | | | +| ITU-T FG-MV | | | WG1 | | | FGMV-33 | | | Glossary for metaverse | | | +| ITU-T FG-MV | | | WG1 | | | FGMV-34 | | | Definitions of CitiVerse | | | +| ITU-T FG-MV | | | WG1 | | | FGMV-35 | | | Building a People-centred CitiVerse | | | +| ITU-T FG-MV | | | WG2 | | | FGMV-09 | | | Power metaverse: Use cases relevant to grid side and user side | | | +| ITU-T FG-MV | | | WG2 | | | FGMV-22 | | | Capabilities and requirements of generative artificial intelligence in metaverse applications and services | | | +| ITU-T FG-MV | | | WG2 | | | FGMV-27 | | | Guidelines for metaverse application in power system | | | +| ITU-T FG-MV | | | WG2 | | | FGMV-30 | | | Overview of the application requirements of metaverse on emergency management in chemical industrial parks | | | + +XXX © IEC:202x – 27 – XXX © CEI:202x + +| ITU-T FG-MV | WG2 | FGMV-36 | The future of travel in the metaverse: landscape and use cases | +| --- | --- | --- | --- | +| ITU-T FG-MV | WG2 | FGMV-37 | Landscape and use cases for the industrial metaverse | +| ITU-T FG-MV | WG2 | FGMV-38 | Framework and requirements for the construction of human-driven 3D digital human application system for metaverse | +| ITU-T FG-MV | WG2 | FGMV-39 | Use cases and requirements for virtual and real fusion coding in metaverse applications | +| ITU-T FG-MV | WG3 | FGMV-31 | Requirements, functional framework and capability of IoT for metaverse | +| ITU-T FG-MV | WG3 | FGMV-40 | Multimedia aspect of metaverse architecture | +| ITU-T FG-MV | WG3 | FGMV-41 | The reference framework of industrial metaverse | +| ITU-T FG-MV | WG4 | FGMV-28 | Requirements for the metaverse based on digital twins enabling integration of virtual and physical worlds | +| ITU-T FG-MV | WG4 | FGMV-29 | Reference model for the metaverse based on a digital twin enabling integration of virtual and physical worlds | +| ITU-T FG-MV | WG5 | FGMV-19 | Service scenarios and high-level requirements for metaverse cross-platform interoperability | +| ITU-T FG-MV | WG5 | FGMV-42 | Interoperability of identity of things across metaverse platforms | +| ITU-T FG-MV | WG5 | FGMV-43 | High-level interoperability architecture for crossplatform metaverse | +| ITU-T FG-MV | WG6 | FGMV-06 | Guidelines for consideration of ethical issues in standards that build confidence and security in the metaverse | +| ITU-T FG-MV | WG6 | FGMV-10 | Cyber risks, threats, and harms in the metaverse | +| ITU-T FG-MV | WG6 | FGMV-11 | Embedding safety standards and the user control of Personally Identifiable Information (PII) in the development of the metaverse | +| ITU-T FG-MV | WG6 | FGMV-12 | Children's age verification in the metaverse | +| ITU-T FG-MV | WG6 | FGMV-13 | Responsible Use of AI for Child Protection in the metaverse | +| ITU-T FG-MV | WG6 | FGMV-23 | Considering online and offline implications in efforts to build confidence and security in the metaverse | +| ITU-T FG-MV | WG6 | FGMV-44 | Security for things across metaverses in aspects of data processing and management | +| ITU-T FG-MV | WG6 | FGMV-45 | Challenges to achieving trustworthy metaverse | +| ITU-T FG-MV | WG6 | FGMV-46 | The essential components of trusted data use in building a trustworthy metaverse | +| ITU-T FG-MV | WG7 | FGMV-07 | Policy and regulation opportunities and challenges in the metaverse | +| ITU-T FG-MV | WG7 | FGMV-14 | Regulatory and economic aspects in the metaverse: Data protection | +| ITU-T FG-MV | WG7 | FGMV-47 | Economic Value Creation and Competition in metaverse | +| ITU-T FG-MV | WG8 | FGMV-03 | Guidelines to assess inclusion and accessibility in metaverse standard development | +| ITU-T FG-MV | WG8 | FGMV-04 | Requirements of accessible products and services in the metaverse: Part I – System design perspective | + +XXX © IEC:202x – 28 – XXX © CEI:202x Table A.2 provides a list of metaverse-related standards developed by ISO/IEC. These 933 standards address various technical aspects, including rendering technologies for visual 934 information constituting the metaverse, conceptual models and definitions of the metaverse, 935 metaverse systems for training and education, privacy protection, user interface design, and 936 signal compression and representation techniques for metaverse environments [4][5]. +937 The scope and objectives of these ISO/IEC standards are distinct from the visual quality 938 management functions addressed in MVQM. Therefore, there is no overlap between the 939 ISO/IEC standards and the MVQM standardization activities. On the contrary, several ISO/IEC 940 standards can be considered supportive or complementary to the MVQM framework, as they 941 provide foundational technologies or reference models that can facilitate the implementation of 942 MVQM functions within broader metaverse systems. +943 The list of ISO/IEC metaverse-related standards summarized in Table A.2 has been compiled 944 and adapted from the official ISO website (https://www.iso.org/). +945 Table A.2 – List of standards on metaverse (ISO/IEC) +946 + +| ITU-T FG-MV | WG8 | FGMV-05 | Requirements of accessible products and services in the metaverse: Part II – User perspective | +| --- | --- | --- | --- | +| ITU-T FG-MV | WG8 | FGMV-08 | Design criteria and technical requirements for sustainable metaverse ecosystems | +| ITU-T FG-MV | WG8 | FGMV-15 | Accessibility requirements for metaverse services supporting IoT | +| ITU-T FG-MV | WG8 | FGMV-16 | Accessibility in a sustainable metaverse | +| ITU-T FG-MV | WG8 | FGMV-17 | Guidelines and requirements on interpreting in the metaverse | +| ITU-T FG-MV | WG8 | FGMV-18 | Guidance on how to build a metaverse for all – Part I: Legal Framework | +| ITU-T FG-MV | WG8 | FGMV-26 | Requirements for communication between humanavatar languages in the metaverse | +| ITU-T FG-MV | WG8 | FGMV-48 | Guidance on how to build a metaverse for all: Part II - Survey | +| ITU-T FG-MV | WG8 | FGMV-49 | Metaverse Sustainability: Driving energy efficiency and GHG emissions reduction | +| ITU-T FG-MV | WG8 | FGMV-50 | Methodology on assessment of GHG emissions of metaverse | +| ITU-T FG-MV | WG9 | FGMV-51 | Standardization roadmap for metaverse | +| ITU-T FG-MV | WG9 | FGMV-52 | Metaverse standardization landscape for gap analyses | +| | SDO | | | SC | | | Standard | | | Title | | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | +| ISO/IEC JTC1 | | | SC29 | | | ISO/IEC TR 23090- 27:2025 | | | Information technology — Coded representation of immersive media — Part 27: Media and architectures for render-based systems and applications | | | +| ISO/IEC JTC1 | | | SC24 | | | ISO/IEC DIS 24931- 1 | | | Information Technology — Metaverse — Part 1: Concepts, definitions and terminology | | | +| ISO/IEC JTC1 | | | SC36 | | | ISO/IEC CD TR 25468 | | | Information technology — Learning, education, and training — Metaverse services for LET | | | +| ISO/IEC JTC1 | | | SC27 | | | ISO/IEC AWI 27573 | | | Privacy protection of user avatar and system avatar interactions in the metaverse | | | +| ISO/IEC JTC1 | | | SC35 | | | ISO/IEC DIS 24216- 1 | | | Information technology — User interface guidelines on avatars — Part 1: General | | | + +XXX © IEC:202x – 29 – XXX © CEI:202x Table A.3 provides a list of metaverse-related standards developed by IEEE and IETF. These 948 standards can be found through the IEEE Xplore Digital Library 949 (https://ieeexplore.ieee.org/Xplore/home.jsp). The identified standards primarily address topics 950 such as requirements for identity frameworks in metaverse systems, architectural models of the 951 metaverse, consumer AR/VR handheld-controller location technologies, and use cases for 952 metaverse applications. The scope of these standards is not directly related to the visual quality 953 management technologies that are being standardized within MVQM. Therefore, no overlap or 954 conflict exists between the IEEE/IETF standards and the MVQM standardization activities. +955 Table A.3 – List of standards on metaverse (IEEE/IETF) +956 Table A.4 provides a list of metaverse-related standard technologies developed by 3GPP (3rd 958 Generation Partnership Project). The listed standards have been referenced and compiled from 959 the official 3GPP specifications portal (https://portal.3gpp.org/#/55936-specifications). The 960 3GPP metaverse-related standards primarily address technologies and service architectures 961 for mobile metaverse systems, focusing on network connectivity, service enablement, and 962 mobile communication frameworks that support metaverse applications. These technologies 963 are outside the scope of MVQM, which focuses on the management of visual quality in 964 metaverse systems. Therefore, no overlap or conflict exists between the 3GPP standards and 965 the technical scope of MVQM. +966 Table A.4 – List of standards on metaverse (3GPP) +967 + +| ISO/IEC JTC1 | SC29 | ISO/IEC CD 23090- 39 | Information technology — Coded representation of immersive media — Part 39: Avatar representation format | +| --- | --- | --- | --- | +| ISO/IEC JTC1 | SC35 | ISO/IEC CD 24216- 1 | Information technology — User interface guidelines on avatars — Part 1: General | +| ISO/IEC JTC1 | SC29 | ISO/IEC 23005-x | Information technology — Media context and control | +| | SDO | | Committee/WG | | | Standard | | | Title | | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | +| IEEE | | | Digital Finance and Economy Standards Committee | | IEEE 3812.1 | | | IEEE Standard for General Requirements for Identity Framework for Metaverse | | | +| IEEE | | | Collaborative Activities Governance Board | | IEEE P3305 | | | IEEE Standard Adoption of Moving Picture, Audio and Data Coding by Artificial Intelligence (MPAI) Technical Specification MPAI Metaverse Model (MMM) Architecture--Version 1 | | | +| IEEE | | | Metaverse Standards Committee | | IEEE P3069 | | | IEEE Recommended Practice for Consumer AR/VR Handheld‑Controller Location Technology Based on Active Infrared Optics | | | +| IEEE | | | Metaverse Standards Committee | | IEEE P2048.101 | | | IEEE Standard for Augmented Reality on Mobile Devices--General Requirements for Software Framework, Components, and Integration | | | +| IETF | | | ICNRG (Interest-Based Communication) | | Draft | | | Metaverse and ICN: Challenges and Use Cases | | | +| SDO | Group | | Specification | | Title | +| --- | --- | --- | --- | --- | --- | +| | | | Number | | | +| 3GPP | S1 | 22.156 | | | Mobile Metaverse Services | +| 3GPP | S1 | 22.856 | | | Study on Localized Mobile Metaverse Services | + +XXX © IEC:202x – 30 – XXX © CEI:202x + +| 3GPP | S6 | 23.700-21 | Study on Application enablement architecture for mobile metaverse services | +| --- | --- | --- | --- | +| 3GPP | C3 | 29.437 | Service Enabler Architecture Layer for Verticals (SEAL); Metaverse Enablement Services; Stage 3 | +| 3GPP | S3 | 33.721 | Study on security aspects of 5G mobile metaverse services | + +XXX © IEC:202x – 31 – XXX © CEI:202x Annex B 970 (informative) +971 + +972 Relationship between MVQM and IEC TC110 standards 973 This annex provides a technical comparison between IEC 62977-2-x and MVQM for the purpose 974 of clarifying their respective scopes and avoiding potential misunderstandings regarding overlap. +975 It does not evaluate or supersede the technical validity of either standard [6][7]. +976 This annex provides an informative clarification of the relationship between the Management of 977 Visual Quality in Metaverse Systems (MVQM), standardized within IEC TC100, and standards 978 developed within IEC TC110, which address electronic display devices. The purpose of this 979 annex is to explicitly explain why MVQM does not overlap with, nor duplicate, the scope of 980 TC110 standards, and to clarify the complementary nature of the two technical domains. +981 B.1 Scope of IEC TC110 standards 982 IEC TC110 is responsible for the standardization of electronic display devices and their 983 associated optical and visual performance characteristics. Standards developed within TC110 984 primarily focus on: +985 +- Optical and electro-optical characteristics of display devices; +986 +- Measurement methods for luminance, chromaticity, contrast, resolution, and uniformity; +987 +- Definition of standardized viewing conditions and measurement environments; +988 +- Evaluation of display performance from specified viewing positions or viewing spaces. +989 In particular, standards in the IEC 62977 series address measurement methodologies and 990 conditions for assessing display quality, including the definition of qualified viewing spaces 991 (QVS) based on objective optical criteria. These standards treat the display device as the object 992 under test and aim to ensure reproducible and comparable measurement results across 993 different devices and laboratories. +994 B.2 Scope of MVQM within IEC TC100 996 MVQM addresses a fundamentally different problem domain. It focuses on the management of 997 visual quality at the system and service level in metaverse environments, where multiple users 998 interact with complex visual content over heterogeneous networks and devices. +999 The scope of MVQM includes: +1000 +- Management of visual quality for heterogeneous visual assets, such as geometry-based 1001 objects, point-based representations, volumetric content, and engine-based assets; +1002 +- Dynamic adaptation of visual data delivery based on user context, including avatar behavior, 1003 viewing direction, interaction state, and spatial relevance; +1004 +- Coordination of network, device, and platform resources to allocate visual quality efficiently; +1005 +- User-centric and context-aware orchestration of visual quality across distributed system 1006 components. +1007 MVQM does not define how display devices are measured, calibrated, or certified, nor does it 1008 specify optical performance metrics or viewing condition requirements for display hardware. +1009 XXX © IEC:202x – 32 – XXX © CEI:202x B.3 Fundamental differences between MVQM and TC110 standards 1011 The distinction between MVQM and TC110 standards can be summarized as follows: +1012 +- Object of standardization: +1013 ✓ TC110 standards standardize display devices and their measurable optical properties. +1014 ✓ MVQM standardizes system-level mechanisms for managing and adapting visual quality 1015 of content and services in metaverse environments. +1016 +- Nature of quality handling: +1017 ✓ TC110 focuses on objective measurement and evaluation of static display performance 1018 under controlled conditions. +1019 ✓ MVQM focuses on dynamic, real-time management of visual quality driven by user 1020 context, system state, and service requirements. +1021 +- Role of viewing-related concepts: +1022 ✓ In TC110 standards, viewing positions or viewing spaces are defined to support 1023 reproducible hardware measurements. +1024 ✓ In MVQM, user viewing direction or area of interest is treated as contextual input for 1025 adaptive quality decisions and is not associated with hardware performance evaluation. +1026 +- Standard outputs: +1027 ✓ TC110 standards produce measurement procedures, test conditions, and performance 1028 characterization methods. +1029 ✓ MVQM standards define conceptual models, requirements, and frameworks for adaptive 1030 visual quality management in operational systems. +1031 B.4 Complementary relationship 1032 MVQM and TC110 standards are complementary rather than overlapping. Information derived 1033 from TC110-compliant display measurements, such as display resolution or rendering capability, 1034 may be used as input parameters for MVQM decision-making. However, MVQM does not 1035 prescribe how such information is obtained or verified. +1036 In this sense, TC110 standards provide device-level characterization, while MVQM operates at 1037 a higher abstraction level to manage visual quality across users, content, networks, and 1038 platforms. The separation of concerns ensures that advances in display measurement 1039 technology and system-level visual quality management can evolve independently without 1040 duplication of standardization efforts. +1041 B.5 Summary 1042 This annex clarifies that MVQM does not overlap with standards developed in IEC TC110. While 1043 both domains address aspects related to visual quality, they do so at different layers and with 1044 distinct objectives. TC110 standards focus on the measurement and evaluation of display 1045 hardware, whereas MVQM addresses the adaptive management of visual quality in metaverse 1046 systems. The two standardization efforts are therefore orthogonal and complementary within 1047 the IEC framework. +1048 1049 + +1050 + +1051 XXX © IEC:202x – 33 – XXX © CEI:202x Annex C 1052 (informative) +1053 + +1054 Relationship between MVQM and ISO/TC159/SC4/WG2 standards 1055 This annex provides an informative clarification of the relationship between the Management of 1056 Visual Quality in Metaverse Systems (MVQM), standardized within IEC TC100, and standards 1057 developed within ISO/TC159/SC4/WG2, which address ergonomic requirements and human1058 centred evaluation of visual displays. +1059 The purpose of this annex is to clarify the respective scopes of MVQM and 1060 ISO/TC159/SC4/WG2 standards, to avoid potential misunderstandings regarding overlap, and 1061 to explain why MVQM does not duplicate or supersede existing ergonomic standards related to 1062 visual quality. This annex does not evaluate the technical validity of either standardization 1063 activity, but instead highlights their distinct objectives and complementary roles at different 1064 abstraction layers. +1065 Representative standards developed within ISO/TC159/SC4/WG2 include the ISO 9241 “300” +1066 subseries, which defines ergonomic requirements and evaluation methods for electronic visual 1067 displays [8]. +1068 C.1 Scope of ISO/TC159/SC4/WG2 standards 1069 ISO/TC159/SC4 addresses ergonomics of human–system interaction, with a particular focus on 1070 human-centred design principles and ergonomic requirements for interactive systems. Within 1071 this structure, WG2 focuses on electronic visual displays and visual presentation from an 1072 ergonomic perspective. +1073 Standards developed under ISO/TC159/SC4/WG2 primarily address: +1074 +- Ergonomic requirements related to visual comfort, visual fatigue, legibility, and perceptual 1075 quality of electronic visual displays; +1076 +- Human-centred evaluation and test methods for assessing visual display quality under 1077 defined viewing conditions; +1078 +- Guidance and recommendations intended to ensure safe, comfortable, and effective visual 1079 interaction between users and display devices. +1080 Representative examples include standards in the ISO 9241 series that define image quality 1081 requirements, visual performance evaluation methods, and ergonomic guidance for specific 1082 display technologies such as stereoscopic displays or head-mounted displays. +1083 These standards focus on the ergonomic characteristics of visual presentation at the display 1084 level, independent of application-layer service orchestration or network-dependent adaptation 1085 mechanisms. +1086 C.2 Scope of MVQM (IEC TC100) +1087 The MVQM standard developed under IEC TC100 addresses visual quality management in 1088 metaverse environments at the system and service level. +1089 MVQM focuses on: +1090 +- Coordinated management of heterogeneous visual data types (e.g. mesh, point cloud, 1091 volumetric video, game-engine assets); +1092 +- Adaptive delivery and orchestration of visual data across heterogeneous networks, devices, 1093 and user contexts; +1094 +- Dynamic quality adaptation based on system-level considerations such as network 1095 conditions, device capabilities, user behaviour, and service policies. +1096 XXX © IEC:202x – 34 – XXX © CEI:202x MVQM does not define ergonomic requirements for visual displays, nor does it specify human 1097 centred test methods or perceptual comfort criteria for visual presentation. Instead, it provides 1098 a conceptual and architectural framework for managing and adapting visual data delivery within 1099 complex multi-user metaverse systems. +1100 C.3 Fundamental differences and non-overlapping scopes 1101 Although both ISO/TC159/SC4/WG2 standards and MVQM relate to “visual quality,” their 1102 objects of standardization are fundamentally different. +1103 +- ISO/TC159/SC4/WG2 standards address: +1104 ✓ Ergonomic requirements for visual displays; +1105 ✓ Human visual comfort, fatigue, and perceptual suitability; +1106 ✓ Evaluation and test methods for assessing visual presentation quality at the display or 1107 user-interface level. +1108 +- MVQM (IEC TC100) addresses: +1109 ✓ System-level mechanisms for adaptive visual data delivery; +1110 ✓ Quality management and orchestration across networks, platforms, and devices; +1111 ✓ Coordination of visual quality adaptation in multi-user metaverse services. +1112 MVQM does not standardize display-level ergonomic requirements or visual comfort criteria and 1113 therefore does not overlap with the normative scope of ISO/TC159/SC4/WG2 standards. +1114 C.4 Complementary relationship 1115 The two standardization efforts are complementary rather than overlapping. +1116 Ergonomic requirements and evaluation outcomes defined in ISO/TC159/SC4/WG2 standards 1117 may be used as input parameters or constraints (e.g. device capability profiles or comfort 1118 related limits) within an MVQM-based system. However, MVQM does not prescribe, modify, or 1119 replace those ergonomic requirements. +1120 Conversely, ISO/TC159/SC4/WG2 standards do not address system-level orchestration, 1121 network-aware adaptation, or multi-user visual quality management in metaverse environments. +1122 Accordingly, MVQM and ISO/TC159/SC4/WG2 standards operate at distinct abstraction layers 1123 and address different aspects of visual quality, ensuring clear separation of scope and avoiding 1124 duplication of standardization efforts. +1125 C.5 Conclusion 1126 Based on the above analysis, MVQM under IEC TC100 does not overlap with standards 1127 developed by ISO/TC159/SC4/WG2. MVQM focuses on system-level visual quality 1128 management and adaptive delivery, whereas ISO/TC159/SC4/WG2 focuses on display -level 1129 ergonomic requirements and human-centred evaluation. +1130 The inclusion of this annex clarifies the scope boundary and demonstrates that MVQM 1131 complements, rather than duplicates, existing ISO ergonomic standards related to visual quality. +1132 1133 + +1134 + +1135 XXX © IEC:202x – 35 – XXX © CEI:202x Bibliography 1136 The following documents are cited for informational purposes only and are not normative 1137 references. They provide background, context, and supporting material relevant to the concepts 1138 discussed in this Technical Report. +1139 + +[1] ISO/IEC 23090-1, Information technology — Coded representation of immersive 1140 media — Part 1: Immersive media architecture, ISO/IEC, 2023. +1141 + +[2] ISO/IEC 23090-5, Information technology — Coded representation of immersive 1142 media — Part 5: Visual volumetric video-based coding (V3C) and video-based point 1143 cloud compression (V-PCC), ISO/IEC, 2021. +1144 + +[3] ISO/IEC 23090-12, Information technology — Coded representation of immersive 1145 media — Part 12: MPEG immersive video (MIV), ISO/IEC, 2022. +1146 + +[4] ISO/IEC DIS 24931-1, Information technology — Metaverse — Part 1: Concepts, 1147 definitions and terminology, ISO/IEC, 2025. +1148 + +[5] ISO/IEC WD 24931-2, Information technology — Metaverse — Part 2: Framework and 1149 architecture, ISO/IEC, (Work in Progress). +1150 + +[6] IEC 62977-2-1, Electronic displays — Part 2-1: Optical measurement methods, IEC, 1151 2018. +1152 + +[7] IEC 62977-2-x, Electronic displays — Part 2-x: Qualified viewing space (QVS) for 1153 electronic displays (Work in progress). +1154 + +[8] ISO 9241-300, Ergonomics of human-system interaction — Part 300: Introduction to 1155 electronic visual display requirements, ISO, 2008. +1156 1157 1158