IEEE P2048.x™ Draft Standard for Virtual Reality Overlay Protocol (VROP)

IEEE Computer Society
Sponsored by the Standards Activities Board

Draft Version: D1.0
Date: 2025-01-18
Working Group: IEEE VR/AR Standards Working Group
PAR Approval: Pending

Title Page

IEEE P2048.x™/D1.0
Draft Standard for Virtual Reality Overlay Protocol (VROP)

Sponsor
Standards Activities Board
of the
IEEE Computer Society

Approved [Date]
IEEE-SA Standards Board

Abstract

This standard defines a message-based communication protocol for virtual reality (VR) overlay applications. The protocol enables interoperability between overlay applications and VR runtime systems, supporting multiple transport mechanisms, programming languages, and security models. Performance requirements for real-time VR applications are specified, including latency bounds and synchronization mechanisms.

Keywords

virtual reality, augmented reality, overlays, protocols, interoperability, real-time systems, message passing

Table of Contents

1. Overview
2. Normative References
3. Definitions, Acronyms, and Abbreviations
4. General Description
5. Protocol Architecture
6. Message Specification
7. Transport Mechanisms
8. Security Requirements
9. Performance Requirements
10. Conformance Testing
11. Annexes

1. Overview

1.1 Scope

This standard specifies:

• Message formats and semantics for VR overlay communication
• Transport mechanism requirements and options
• Security model and capability-based permissions
• Performance metrics and requirements
• Conformance criteria and test procedures

This standard does not specify:

• Specific VR runtime implementations
• Rendering techniques or graphics APIs
• Hardware requirements

1.2 Purpose

The purpose of this standard is to enable portable VR overlay applications that can operate across different VR platforms and runtime systems while maintaining performance suitable for real-time interactive use.

1.3 General Compliance

Implementations claiming conformance to this standard shall implement all mandatory requirements and may implement optional features as specified herein.

2. Normative References

The following referenced documents are indispensable for the application of this document:

• IEEE Std 2048™-2018, IEEE Standard for Virtual Reality and Augmented Reality: Immersive Video and Related Applications
• IEEE Std 1003.1™-2017, IEEE Standard for Information Technology—POSIX®
• IETF RFC 8949, Concise Binary Object Representation (CBOR)
• ISO/IEC 23090-2:2021, Information technology — Coded representation of immersive media

3. Definitions, Acronyms, and Abbreviations

3.1 Definitions

For the purposes of this document, the following terms and definitions apply:

3.1.1 overlay: A 2D or 3D visual element rendered within a VR environment that persists independently of the primary application content.

3.1.2 capability: A specific permission or feature that an overlay application may request from the runtime system.

3.1.3 transport: The underlying communication mechanism used to exchange protocol messages.

3.1.4 message latency: The time elapsed between message transmission and receipt, measured in microseconds.

3.2 Acronyms and Abbreviations

• API: Application Programming Interface
• IPC: Inter-Process Communication
• VR: Virtual Reality
• VROP: Virtual Reality Overlay Protocol
• WASM: WebAssembly

4. General Description

4.1 System Architecture

The VROP architecture consists of three primary layers:

1. Application Layer: Overlay applications using various programming languages
2. Protocol Layer: Message encoding, routing, and security enforcement
3. Transport Layer: Platform-specific communication mechanisms

4.2 Design Principles

The protocol design adheres to the following principles:

a) Minimal overhead: Message processing shall not exceed 100 microseconds b) Platform independence: Messages shall be portable across operating systems c) Language agnostic: Support for any programming language through serialization-agnostic design d) Secure by default: Capability-based security model with principle of least privilege e) Extensible: Version negotiation and backward compatibility

5. Protocol Architecture

5.1 Message Flow

direction: right
A: Application] --> B[Encode
C: Transport
D: Decode
E: Runtime
F: Response Path

B -> C
C -> D
D -> E
E -> F
F -> A

# Styles
A.style: {
  fill: "#f96"
  stroke: "#333"
  stroke-width: 2
}
B.style: {
  fill: "#9cf"
  stroke: "#333"
  stroke-width: 2
}
C.style: {
  fill: "#cf9"
  stroke: "#333"
  stroke-width: 2
}
D.style: {
  fill: "#9cf"
  stroke: "#333"
  stroke-width: 2
}
E.style: {
  fill: "#f96"
  stroke: "#333"
  stroke-width: 2
}
F.style: {
  fill: "#ccc"
  stroke: "#333"
  stroke-width: 1
  stroke-dash: 5
}

5.2 Protocol Layers

5.2.1 Message Layer

• Message structure and encoding
• Type safety and validation
• Correlation of requests and responses

5.2.2 Session Layer

• Connection establishment
• Capability negotiation
• State management

5.2.3 Transport Layer

• Platform-specific implementations
• Quality of service guarantees
• Flow control

6. Message Specification

6.1 Message Structure

All protocol messages SHALL conform to the following structure:

Message ::= SEQUENCE {
    msgType     INTEGER (0..65535),
    requestId   INTEGER (0..2^64-1) OPTIONAL,
    timestamp   INTEGER (0..2^64-1),
    payload     OCTET STRING
}

6.2 Message Types

Messages are categorized into functional groups:

6.2.1 Lifecycle Messages (0x0000-0x00FF)

• INIT (0x0001): Initialize protocol session
• SHUTDOWN (0x0002): Terminate protocol session
• CAPABILITY_QUERY (0x0003): Query available capabilities

6.2.2 Overlay Messages (0x0100-0x01FF)

• CREATE_OVERLAY (0x0100): Create new overlay
• UPDATE_OVERLAY (0x0101): Modify overlay properties
• DESTROY_OVERLAY (0x0102): Remove overlay

6.2.3 Rendering Messages (0x0200-0x02FF)

• SUBMIT_FRAME (0x0200): Submit rendered content
• FRAME_TIMING (0x0201): Timing synchronization

6.2.4 Input Messages (0x0300-0x03FF)

• INPUT_EVENT (0x0300): Controller/hand input
• HAPTIC_FEEDBACK (0x0301): Trigger haptic response

6.3 Message Encoding

Messages SHALL be encoded using a serialization format negotiated during transport initialization. Common formats include:

• MessagePack: Cross-language support, compact binary format
• Bincode: High performance, Rust-native
• JSON: Human-readable, debugging
• Protocol Buffers: Schema evolution, enterprise use

Constraints:

• Maximum message size: 1 MB
• String encoding: UTF-8
• Numeric types: IEEE 754 compliance

7. Transport Mechanisms

7.1 Required Transports

Conforming implementations SHALL support at least one of:

7.1.1 Shared Memory Transport

• Lock-free circular buffers
• Memory-mapped files
• Latency requirement: < 50 microseconds

7.1.2 Socket Transport

• Unix domain sockets (POSIX systems)
• Named pipes (Windows systems)
• Latency requirement: < 500 microseconds

7.2 Optional Transports

7.2.1 Direct Function Calls

• In-process plugins
• Zero-copy semantics
• Latency requirement: < 5 microseconds

7.2.2 Network Transport

• TCP/IP with optional TLS
• WebSocket for browser contexts
• Latency requirement: < 50 milliseconds

8. Security Requirements

8.1 Capability Model

Overlay applications SHALL declare required and optional capabilities:

Capabilities ::= SEQUENCE {
    required    BIT STRING {
        overlayCreate(0),
        inputReceive(1),
        gpuDirect(2)
    },
    optional    BIT STRING {
        networkAccess(0),
        fileSystem(1),
        audioOutput(2)
    }
}

8.2 Isolation Requirements

8.2.1 Process Isolation

• Overlay applications SHOULD run in separate processes
• Memory protection between applications SHALL be enforced
• Resource limits SHALL be configurable

8.2.2 Sandboxing

• WASM applications SHALL execute in isolated environments
• System call access SHALL be mediated
• Direct hardware access SHALL require explicit capability

8.3 Authentication

• Protocol sessions SHALL be authenticated using platform mechanisms
• Message integrity SHOULD be verified using HMAC-SHA256
• Encryption SHALL be available for sensitive data

9. Performance Requirements

9.1 Latency Requirements

Operation	Maximum Latency	Measurement Point
Message dispatch	100 μs	Application to runtime
Frame submission	1 ms	Texture ready to display
Input delivery	5 ms	Controller to application
Initialization	100 ms	Request to ready

9.2 Throughput Requirements

• Message rate: Minimum 10,000 messages/second
• Frame rate: Support for up to 144 Hz displays
• Concurrent overlays: Minimum 16 per application

9.3 Resource Constraints

• Memory per overlay: Maximum 100 MB (configurable)
• GPU memory: Maximum 500 MB total (configurable)
• CPU utilization: Maximum 10% for protocol overhead

10. Conformance Testing

10.1 Conformance Levels

10.1.1 Basic Conformance

• Implement all mandatory message types
• Support at least one transport mechanism
• Pass latency requirements for supported transports

10.1.2 Full Conformance

• Implement all message types including optional
• Support multiple transport mechanisms
• Implement complete security model

10.2 Test Suite Requirements

The conformance test suite SHALL verify:

• Message format compliance
• Timing requirement adherence
• Security boundary enforcement
• Error handling correctness
• Interoperability between implementations

10.3 Certification Process

1. Self-certification with test results submission
2. Third-party validation (optional)
3. Interoperability testing events
4. Continuous integration testing

11. Annexes

Annex A (Informative): Implementation Guidelines

A.1 Recommended buffer sizes for different use cases A.2 Platform-specific optimization techniques A.3 Common implementation pitfalls

Annex B (Normative): Message Schema

B.1 Complete message structure definitions (serialization-agnostic) B.2 Extension point specifications B.3 Version negotiation protocol

Annex C (Informative): Security Considerations

C.1 Threat model analysis C.2 Recommended cryptographic algorithms C.3 Platform-specific security features

Annex D (Informative): Performance Optimization

D.1 Lock-free data structure implementations D.2 Memory allocation strategies D.3 GPU synchronization techniques

Patent Notice

Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patents for which a license may be required by an IEEE standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention.

Participants

[List of working group participants to be added]

Bibliography

[1] Valve Corporation, "OpenVR API Documentation," 2015-2024.

[2] The Khronos Group Inc., "The OpenXR Specification," Version 1.0, July 2019.

[3] M. Abrash, "Latency – the sine qua non of AR and VR," Oculus Blog, 2013.

[4] W3C, "WebXR Device API," W3C Working Draft, 2024.

[5] L. Lamport, "Time, clocks, and the ordering of events in a distributed system," Commun. ACM, vol. 21, no. 7, pp. 558–565, 1978.