MultiMoQ: Multi-Access Media-Over-QUIC for Robust Immersive Video Streaming

MultiMoQ: Multi-Access Media-Over-QUIC for Robust Immersive Video Streaming Yitong Li

Xinjiao Li

The Hong Kong University of Science and Technology (Guangzhou) Guangzhou, Guangdong, China yliop@connect.hkust-gz.edu.cn

The Hong Kong University of Science and Technology (Guangzhou) Guangzhou, Guangdong, China xli886@connect.hkust-gz.edu.cn

Ruonan Chai

Dirk Kutscher✉

The Hong Kong University of Science and Technology (Guangzhou) Guangzhou, Guangdong, China rchai327@connect.hkust-gz.edu.cn

The Hong Kong University of Science and Technology (Guangzhou) Guangzhou, Guangdong, China dku@hkust-gz.edu.cn

arXiv:2608.06102v1 [cs.NI] 6 Aug 2026

Abstract Live immersive video streaming, particularly 360° video, is increasingly adopted in applications such as virtual events, sports broadcasting, and remote education. Existing approaches struggle to support high-bitrate immersive streaming for large numbers of concurrent users, with coarse-grained delivery limiting responsiveness and insufficient support for coordinating concurrent tile streams. Media over QUIC (MoQ) has recently emerged as a promising solution for large-scale media delivery, yet it lacks robustness under bandwidth-constrained conditions, often resulting in playback stalls. To address these challenges, we present MultiMoQ, a multi-access tile streaming framework built on MoQ that redesigns its delivery mechanism for robust high-bitrate streaming across multiple access paths while supporting flexible tile scheduling and seamless access switching. We implement a fully functional prototype of MultiMoQ and evaluate it in network emulation under heterogeneous real-world network conditions, comparing against Dynamic Adaptive Streaming over HTTP (DASH) and standard MoQ. Results show that MultiMoQ increases goodput for enhancement tiles and base video and reduces enhancement-tile tail endto-end latency relative to DASH, while preserving audio continuity and avoiding the persistent stalls of standard MoQ. These transport gains translate into smoother viewport playback, and the ablation results further confirm the contribution of multi-access control to playback continuity.

CCS Concepts • Networks → Network protocol design; Application layer protocols; • Information systems → Multimedia streaming.

Keywords 360° video, immersive video streaming, Media over QUIC, tile-based video streaming, multi-access delivery

This work is licensed under a Creative Commons Attribution 4.0 International License.

Viewport /Tile adaptation

Viewport / Tile adaptation

Tile/Track scheduling

HTTP / DASH session

End-to-End streaming

Track management (Hang)

Segment/Object delivery

Media delivery over QUIC

Group delivery (MoQ-Lite)

TCP

QUIC/MPQUIC

QUIC

DASH

Pure QUIC

Media over QUIC

Figure 1: High-level comparison of DASH-, QUIC-, and MoQbased immersive streaming architectures.

1

Introduction

Live 360° video lets viewers explore an omnidirectional scene while it is captured and delivered. It supports concerts, sports broadcasts, virtual exhibitions, and remote education [1, 8, 12, 22, 29]. Unlike conventional video, it carries a high-resolution panoramic scene while each viewer selects a changing viewport. Live operation therefore requires timely and continuous delivery so that viewport changes and playback remain responsive under time-varying network conditions [29]. Prior work addresses parts of this problem. Viewport-adaptive systems reduce traffic by sending only tiles relevant to the current or predicted view, but commonly use DASH-style HTTP delivery [4, 19, 27, 32]. QUIC and multipath-QUIC designs improve transport efficiency and path utilization [11, 18, 23]. Multi-source, multicast, and edge-assisted systems distribute load across network resources [2, 15, 31]. However, these approaches do not jointly provide responsive live delivery, scalable fan-out, and robust coordination of concurrent tile streams under heterogeneous access conditions. Three challenges remain. First, low-latency playback requires finer-grained delivery than conventional segment mechanisms provide, especially as access quality changes. Second, direct client– server retrieval creates repeated upstream traffic when many users request high-bitrate content. Third, playback depends on several concurrent tile streams; instability in even a subset can create missing regions or freeze the reconstructed viewport. A viable design must address latency, robustness, and scalability together rather than optimizing one stream or path in isolation.

Li et al.

Bad Stable Good

BW (Mbps) 8–15 15–30 30–40

Prop. 25% 50% 25%

Ali Delay (ms) 11–14 10–13 9–13

Tencent Delay (ms) 15–20 15–18 14–18

Viewport-adaptive systems instead partition the panorama into spatial tiles. They send tiles in the current or predicted viewport at higher quality and reduce quality elsewhere [4, 19]. This saves bandwidth but turns one video into several media streams whose delivery must remain synchronized as the viewport and network change. Most deployed designs implement this adaptation through DASH segments [24, 27, 32]. DASH is widely supported, but its segment granularity limits how quickly a live session can react to access variation or a new viewport.

2.2

Media over QUIC

Media from source

Group1

Track

Track

Track

Group0

Output media stream

Group0 Group1

Relay

Frame0

Frame0

Frame1

Frame1

…

Server

Group Copy and Group deliver to Group all subscribers Group … Group Group

Track

Read group until finishing/aborting

…

An equirectangular projection (ERP) maps a spherical 360° scene to a rectangular video frame [29]. Sending the entire high-resolution ERP frame at uniform quality consumes substantial bandwidth, particularly for live content.

BW Cat.

…

2 Background 2.1 360° Video Streaming

Table 1: Campus network measurement: bandwidth/delay of Alibaba/Tencent CDN1

…

Fig. 1 summarizes the architectural tradeoffs. DASH tile streaming reduces unnecessary media traffic. Its segment requests respond coarsely and can generate repeated backhaul fetches. Pure QUIC designs improve end-to-end transport but retain direct client–server delivery, making fan-out difficult. Network-assisted designs use distributed resources but require stronger support at servers, edges, or the network. Media over QUIC (MoQ) [17] instead combines relay-assisted fan-out with object-level delivery. Our measurements in Section 2.3, however, show that standard MoQ remains unstable when it carries many high-bitrate tiles. We design MultiMoQ, a client-driven multi-access framework built on MoQ. Its first component redesigns MoQ-Lite group delivery with separate pending and active states, preserving in-flight transmission while still discarding stale media. Its second component lets each client monitor delivery quality, warm an alternate access, and switch individual tracks without exposing discontinuities to the application. Together, the components provide continuous multi-track delivery and timely access adaptation while retaining MoQ’s relay-assisted architecture. This division is deliberate. The lower layer handles continuity along the complete server–relay–client path, while the endpoint controller handles changes in access quality. A stable delivery layer is required before switching can improve timeliness without creating another media discontinuity. This paper makes the following contributions: • Empirical analysis of existing immersive streaming approaches. We identify distinct DASH and standard-MoQ bottlenecks under heterogeneous client conditions and connect them to their delivery architectures (Section 2.3). The analysis distinguishes delayed segment retrieval from freshness-driven group interruption. • Robust MoQ delivery redesign for concurrent tile streaming. We separate pending-group maintenance from active transmission and schedule groups using freshness and completion gaps (Section 3.2). The same queue separation applies at senders and receivers along the relay path. • Client-driven multi-access architecture for seamless tile handover. Per-track monitoring and make-before-break multiplexing switch accesses while maintaining one continuous application stream (Section 3.3). Clients can retain one access or warm a second according to observed delivery quality. • Prototype implementation and evaluation. We extend the Rust MoQ codebase and compare MultiMoQ with DASH and standard MoQ in a 96-client Mininet topology configured from real-world access measurements (Section 4). Transport measurements, an ablation, and reconstructed playback evaluate the two components from network to application output.

Video group

Audio group

Hang

Video

Audio

MoQ-Lite

Client

Figure 2: Overview of Media over QUIC.

Media over QUIC (MoQ) is a publish–subscribe framework for real-time media over QUIC or WebTransport [9, 17]. As Fig. 2 shows, a producer publishes named tracks that intermediate relays distribute to subscribers. Unlike a client issuing an independent HTTP request for every segment, many subscribers can share this relayassisted distribution tree, providing scalable fan-out. MoQ organizes each track into groups of media objects [17]. A track is a logical media stream, a group is a delivery and scheduling unit, and objects carry media data. This hierarchy supports finergrained transport than conventional segments and lets different immersive-video tiles use independent tracks. Independent tracks introduce a continuity requirement. Audio, base video, and enhancement tiles may progress at different rates when bandwidth varies; losing or delaying one track can still disrupt the combined viewport. MoQ must therefore coordinate fresh delivery with completion of in-flight groups.

MultiMoQ: Multi-Access Media-Over-QUIC for Robust Immersive Video Streaming

Figure 3: MoQ/DASH goodput.

2.3

Figure 4: MoQ stall time.

Motivation

We first compare DASH and standard MoQ using the measured access conditions in Table 1. The experiment serves 96 clients through a four-layer hierarchy of CDN proxies or MoQ relays (Section 4.1.4). Both baselines stream the same 4K, 30-fps ERP source, whose enhancement tiles average 2.35 Mbps. DASH retrieves 1-s segments through caching proxies; standard MoQ uses the current IETF architecture and 1-s groups without our modifications. Section 4.1.2 gives the complete setup. DASH goodput remains 20–40% below the encoding rate in the bad and stable conditions (Fig. 3). Standard MoQ approaches the target rate, but its average stall time is 29.1%, 15.9%, and 14.4% in the bad, stable, and good conditions, respectively (Fig. 4). Thus, DASH loses timeliness and throughput while standard MoQ loses delivery continuity. These different failure modes motivate an architectural rather than bitrate-adaptation change. DASH: uncoordinated segment requests create backhaul pressure at scale. DASH clients independently request HTTP segments [24]. In a tile-based session, each client requests multiple high-bitrate tracks and each cache miss triggers an upstream fetch. Concurrent misses therefore increase backhaul traffic and compete with downstream delivery. The segment unit also delays reactions until request or segment boundaries. Edge caching and collaborative delivery can reduce remote requests [14–16, 25], but they do not remove the coarse request granularity [19, 27]. As the client population grows, this model becomes difficult to sustain under a constrained shared cache and backhaul. MoQ: freshness-oriented delivery and tight cross-layer coupling hurt robustness. In the current MoQ-Lite design, each track maintains one active group; starting a new group may close or drop an older incomplete group [5]. This policy favors fresh live media, consistent with MoQ’s deadline-driven semantics [17]. However, replacing an incomplete group can create a gap even when useful objects are still in flight. The interaction with the Hang layer compounds this behavior. A standard MoQ-Lite receiver exposes one current group and replaces it when a newer group arrives. Hang must consume the current group before replacement, creating a race between lowerlayer freshness and upper-layer playback. Short-fragment audio is especially sensitive because groups arrive frequently. With many high-bitrate tile tracks, repeated replacement can interrupt several in-flight groups and propagate instability to the reconstructed viewport. The stalls in Fig. 4 show the resulting loss of continuity. A robust MoQ design must satisfy two requirements. It must separate freshness maintenance from active transmission so that 1 Bandwidth and latency measurements were collected across different locations and

time periods within the campus network using standard tools such as ping and curl.

a new group does not immediately disrupt an in-flight group. It must also adapt away from a degraded access before transport delay becomes playback lag, while presenting each tile as one continuous stream to the application. These requirements span different layers. Group lifetime and forwarding belong in MoQ-Lite along the relay path, whereas access selection and media cutover require endpoint knowledge of delivery quality and decoder progress. Treating both as one scheduling decision would couple relays to application state; MultiMoQ instead assigns each responsibility to the layer that observes the required signal.

3

MultiMoQ Design and Implementation MoQ-Lite Delivery Redesign Upstream

Pending queue

Select next group

Transmit groups

Active queue

Transmission watchdog

Freshness maintenance

Relay1 Server

Primary access Secondary access

Client

Relay2

Client-Driven Multi-Access Control

Primary access QoE-driven access switching

Tile multiplexer

Output media stream

Secondary access Decoder Seamless switching across accesses

Figure 5: MultiMoQ overview.

3.1

Overview of MultiMoQ

Fig. 5 shows MultiMoQ’s two components. The MoQ-Lite redesign (Section 3.2) separates buffered groups from active transmission and applies this behavior at each sender and receiver along the relay path. Client-driven multi-access control (Section 3.3) builds on the resulting stable delivery at the Hang and application layers. It monitors each track, warms an alternate path when needed, and multiplexes both accesses into one application-visible stream.

3.2

MoQ-Lite Delivery Redesign

MoQ-Lite [5] is MoQ’s transport-facing layer and the lowest layer that MultiMoQ changes. We modify its group-delivery path to address the freshness–continuity tradeoff in Section 2.3. The redesign preserves MoQ’s layered architecture, publish/subscribe semantics, and relay role (Section 2.2); it changes how groups wait for and enter transmission. Sender-side buffering. As Fig. 6 shows, a FIFO pending queue admits newly received groups2 . Periodic maintenance removes stale entries, and overflow eviction starts at the queue head. The active transmission state is separate: pending-queue admission, 2 The queue size is tunable; our prototype uses five entries.

Li et al.

Transmission

Sender Pending queue Group Group Group

Enqueue

• •

Select next group by score

• •

Evict stale groups Evict head groups on overflow

Active queue

Group Group Group

Enqueue

Group

To application Forward to next node

…

…

Freshness maintenance

Receive queue

At most one group is active per track!

Pending-queue control never modifies the active queue!

Hang layer consumes groups

Receiver

Aborted on expiry Delay eviction near completion

Each group is carried on a QUIC stream… • • •

Freshness maintenance

𝑠𝑐𝑜𝑟𝑒_𝑚𝑠 = 𝑤_𝑠𝑡𝑎𝑙𝑒 ∗ 𝑠𝑡𝑎𝑙𝑒_𝑚𝑠 + 𝑤_𝑔𝑎𝑝 ∗ 𝑔𝑎𝑝_𝑚𝑠 𝑔𝑎𝑝_𝑚𝑠 = max(0, 𝑠𝑒𝑞 − (𝑙𝑎𝑠𝑡_𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒𝑑 + 1)) ∗ 𝑔𝑟𝑜𝑢𝑝_𝑑𝑢𝑟𝑎𝑡𝑖𝑜𝑛_𝑚𝑠 Pick the minimum score candidate

Forward to downstream subscribers' Evict stale groups pending Evict head groups on overflow queues

• •

Figure 6: MoQ-Lite delivery redesign. expiration, and overflow handling never modify the active queue. A new group can therefore update the sender’s candidates without immediately aborting an in-flight group. Active transmission control. The sender scores each pending group to balance freshness against sequential completion. Always selecting the newest group minimizes age, but it can skip unfinished sequence numbers and leave gaps in the client timeline. Always selecting the oldest group preserves order but can deliver obsolete live media. For candidate 𝑔, Eqs. (1) and (2) combine these costs: score(𝑔) = 𝑤 stale · stale𝑔 + 𝑤 gap · gap𝑔 ,   gap𝑔 = max 0, seq𝑔 − (last comp + 1) · 𝑇𝑔 .

3.3

Client-Driven Multi-Access Control

MoQ-Lite/Hang decoupling. To remove the cross-layer race identified in Section 2.3, Hang consumes the receive queue and maintains its own pending and current group states (Fig. 7). It does not lose its current group merely because MoQ-Lite receives a newer one. A delivery progress watchdog instead monitors useful progress. If a current group remains blocked beyond the watchdog interval, Hang drops it and advances to the next pending group. This separates low-level arrivals from the upper-layer decision to abandon a group.

(1) (2)

Here, stale𝑔 is staleness in milliseconds, seq𝑔 is the group sequence number, last comp is the last completed sequence number on the track, and 𝑇𝑔 is group duration in milliseconds. The gap term expresses the playback time skipped if 𝑔 follows the last completed group. Experiments use 𝑤 stale = 1 and 𝑤 gap = 0.5 to favor freshness without ignoring continuity. The sender selects the minimum-score group. The selected group becomes the track’s only active group and uses a dedicated QUIC stream. At most one active group per track keeps group scheduling lightweight and leaves byte transmission to QUIC. Starting many groups in parallel under a constrained path could delay every group and leave only stale partial deliveries. In MultiMoQ, later arrivals remain in the pending queue until the current group completes, expires near its delivery deadline, or stops making progress. The transmission watchdog handles the latter cases and releases the active slot for another candidate. Receiver delivery. A freshness-maintained receive queue holds delivered groups instead of exposing one replaceable group. At a relay, each received group is copied to the pending queues of downstream subscribers and forwarded to the next node. At a client, the receive queue buffers groups until Hang consumes them. MoQ-Lite remains responsible for transport and forwarding, while media consumption stays in the higher layer.

Application layer

OwnedA

OwnedB

Access-switching state machine CutoverB

RollbackA QoE-driven access switching Stream multiplexer

Hang Pending group

Hang

Current group

Deliver progress watchdog MoQ-Lite redesign Group0

Group1

Group2 … Primary access

Pending group

Current group

Deliver progress watchdog MoQ-Lite redesign Group0

Group1

Group2 …

Secondary access

Figure 7: Client-driven multi-access control.

Stream multiplexing. Each access has its own Hang instance, but MultiMoQ exposes one logical output per media track. The stream multiplexer applies make-before-break switching: the current access continues to deliver while the alternate subscription warms up.

MultiMoQ: Multi-Access Media-Over-QUIC for Robust Immersive Video Streaming

Cutover occurs only after the alternate stream reaches a decodersafe entry point, such as a keyframe. The multiplexer enforces monotonic output and a timestamp lead guard, which requires the new stream to advance beyond the last timestamp committed from the old stream. It briefly drains the old access after cutover before unsubscribing. Duplicate or late objects are not exposed, so the application observes a continuous track. QoE-driven switching. Each client runs a closed-loop controller per track. During startup, it records a latency baseline; during playback, it maintains a smoothed short-window latency estimate. A handover requires several signals to agree: relative and absolute increases over the baseline, a sustained upward trend, and confirmation in consecutive windows. This conservative trigger rejects transient jitter but responds when one access persistently degrades. A per-round limit on successful handovers also prevents many tile tracks from switching simultaneously. Per-track state machine. A track starts in OwnedA, with media delivered through the primary access. Persistent degradation moves it to WarmupB, which subscribes to and probes the secondary while retaining the primary. Once the alternate stream satisfies the lead and decoder-entry conditions, CutoverB commits its first accepted object and transitions to OwnedB. A timeout, error, or insufficient progress invokes RollbackA and retains the primary output. The application does not observe the failed attempt. Design effect. The delivery redesign and endpoint controller decouple path selection from media continuity. The controller can evaluate and change accesses while the application retains one ordered stream. Multi-access operation also need not add proportional backhaul load under MoQ’s relay-assisted fan-out. A secondary relay may already carry a requested tile for other clients; a new subscription can then reuse that relay distribution rather than starting another end-to-end retrieval. When the tile is absent, the additional subscription still follows standard MoQ relay behavior. The controller can also retain single-access delivery when the primary path remains adequate. Multi-access is activated per track during warmup or handover rather than imposed continuously on the entire session. This keeps the access decision local to the affected tile while the multiplexer preserves the session-wide media interface.

3.4

Implementation

We implement MultiMoQ3 as a layered extension of the Rust MoQ stack4 , which follows the IETF MoQ draft [17]. The prototype preserves the publisher–relay–client structure, publish/subscribe model, and QUIC transport. Pending/active scheduling and receive queues remain inside MoQ-Lite. Watchdogs, per-access Hang instances, the multiplexer, and the state machine run at client endpoints. Relays remain transport-facing forwarding nodes. Thus, MultiMoQ is an in-stack evolution of MoQ rather than a replacement transport. Existing publisher and relay roles remain intact, and the new access logic is confined to endpoints. The implementation therefore changes delivery control without requiring a new wire transport or a media-aware relay API.

4

Evaluation

We evaluate three questions. First, does MultiMoQ improve goodput, latency, and continuity across enhancement, base, and audio tracks? Second, which gains come from the MoQ-Lite redesign and which require client-driven multi-access control? Third, does MultiMoQ improve bottleneck delivery and latency jointly, and do these gains survive viewport reconstruction?

4.1

Experiment Setup

4.1.1 Media Sample. We used a 4K, 30-fps 360° ERP video. FFmpeg5 partitioned each frame into a 4 × 2 grid and packaged eight enhancement tiles, one base track, and one audio track as fMP4. The 2048 × 1024 base track was encoded at 6.08 Mbps, while each 1024 × 1024 enhancement tile was encoded at 2.07–2.46 Mbps. Audio used 48-kHz AAC-LC at 0.19 Mbps. Video totaled 24.44 Mbps. Keyframes occurred at roughly 1-s intervals, and we aligned both DASH-segment and MoQ-group boundaries with these intervals so that the baselines used the same media units and random-access points. 4.1.2 Evaluation Environment and Streaming Setup. Experiments ran in Mininet [13] on a 128-core Intel Xeon server with 256 GB RAM. MultiMoQ and standard MoQ used identical packaging, with one 1-s group of pictures (GOP) per MoQ group. The DASH baseline used tiled HTTP/2 over TCP [3], a dynamic Media Presentation Description, and 1-s segments aligned with the GOPs6 . The base track, enhancement tiles, and audio appeared as independent tracks in both systems. Each DASH client first fetched the initialization segment from its assigned CDN proxy and then requested the latest unseen media segment for every track. We disabled adaptive bitrate switching because the study isolates transport and delivery behavior rather than representation selection. Nginx reverse-proxy caches provided a shared 30-MB budget per proxy across concurrent clients7 . This constrained cache allowed concurrent tile requests to compete for the same edge capacity. 4.1.3 Baselines and Evaluation Metrics. We compared DASH, standard MoQ, the MoQ-Lite Redesign-only variant, and the full MultiMoQ. The redesign-only ablation includes the pending/active and receive queues but omits client-driven multi-access control, isolating the contributions of stable group delivery and access adaptation. We evaluate performance using four metrics: • Transport stall time: time that delivery blocks because insufficient media has arrived. • Goodput: useful media data delivered to the client per unit time. • End-to-end latency: elapsed time from source generation to client delivery. • Viewport quality: freeze behavior and the SSIM/VMAF fidelity of reconstructed viewports against the source. 4.1.4 Network Topology. Fig. 8 shows the common four-layer topology: one server, four root nodes, 16 leaf nodes, and 96 clients. Each 5 https://www.ffmpeg.org/

3 Source code: https://github.com/YitongLI2000/MultiMoQ-ACMMM2026.git.

6 https://dashif.org/dash.js/pages/usage/low-latency.html

4 https://github.com/moq-dev/moq.git.

7 Implementation based on https://github.com/TareqAlqutami/rtmp-hls-server.

Li et al.

root connected to four leaves; each leaf was the primary node for six clients and the secondary node for six others. MoQ used relays and DASH used CDN proxies at the same positions, so both baselines traversed the same hierarchy and fan-out. Primary-access links followed the measured bandwidth and delay distributions in Table 1. Fig. 15(a) shows the resulting per-leaf bandwidth assignment. Every secondary link used 30 Mbps, with delay drawn from the table’s Tencent-CDN range. All upper-layer backhaul links used 80 Mbps and 2 ms delay to represent a constrained shared delivery network [7]. Unless stated otherwise, every experiment used this topology.

Server Primary access

Secondary access

…

Root relays/CDN proxy …

Leaf relays /CDN proxy

…

4.3

Clients

4.4 Figure 8: Common four-layer topology for the MoQ and DASH evaluations.

4.2

Ablation Study

In Fig. 11(a), the redesign-only variant reduced standard MoQ’s 29.1%/15.9%/14.4% stall times to 0.15%/0.00%/0.00%. The MoQ-Lite redesign therefore accounts for most of the continuity improvement. Eliminating stalls, however, did not guarantee timely playback. Fig. 11(b) shows that redesign-only delivery still accumulated several seconds of runtime delay on a degraded access. Full MultiMoQ reduced the delay after switching to a better access at 𝑡 = 7.2 s. For a conservative comparison, the standard-MoQ trace uses its lowest-delay tile. Both variants use the same group-delivery redesign, so the postswitch divergence isolates client-driven access control. Fig. 12 shows the application-level effect. Multi-access control reduced the redesign-only freeze ratio from 4.62% to 1.09%, maximum freeze from 1.03 s to 0.50 s, and total frozen time from 2.03 s to 0.50 s. The traces cover 44 s and 46 s, respectively, so freeze ratio normalizes their durations. Together, Figs. 11 and 12 show that the redesign removed transport stalls while switching curtailed delay-related freezes.

Overall Transport Performance

Enhancement-Tile Performance. Fig. 9 compares the eight enhancement tiles under the bad, stable, and good access conditions. In the bad condition, MultiMoQ delivered 1.20 Mbps versus 0.66 Mbps for DASH and 0.72 Mbps for standard MoQ. Its goodput rose to 1.48 and 1.71 Mbps in the stable and good conditions, remaining above both baselines. Relative to DASH, MultiMoQ reduced p95 end-to-end delay from 3930/3062/2473 ms to 1130/936/956 ms across the three conditions. Standard MoQ had lower delay in the latter two conditions, but this result came with poor continuity: it stalled for 29.1% in the bad condition and above 14% otherwise. MultiMoQ’s corresponding stall times were 0.11%, 1.32%, and 1.03%. DASH also rarely stalled, but delivered lower goodput at much higher tail delay. MultiMoQ therefore retained MoQ’s timely object delivery without its persistent stalls. Audio and Base Track Robustness. Fig. 10 shows whether the same behavior holds for audio and fallback base video. Standard MoQ’s audio stall time was above 85% in every condition, whereas DASH and MultiMoQ remained near zero. Its base track also stalled about 45% in the bad condition; the other two systems again remained near zero. In the bad condition, MultiMoQ increased DASH base-track goodput from 1.69 to 2.65 Mbps. The corresponding gains were from 2.59 to 3.02 Mbps in the stable condition and from 2.49 to 4.16 Mbps in the good condition. Standard MoQ delivered more base-track goodput in the stable and good cases, but with poor audio continuity and severe bad-condition base-track stalls. The redesign thus benefited short audio groups and the base track in addition to enhancement tiles.

Multi-Track Delivery and Playback Analysis

Fig. 13 reports 96 client observations per system from one sharedtopology run, not independent repetitions. Let T contain video2– video9. The vertical coordinate is 𝐵𝑖 = 100 min𝑡 ∈ T 𝐺¯𝑖,𝑡 /𝑅𝑡 ; the horizontal coordinate is 𝐷𝑖 = max𝑡 ∈ T 𝐿¯𝑖,𝑡 . Here 𝐺¯𝑖,𝑡 and 𝐿¯𝑖,𝑡 are track 𝑡’s mean goodput and latency, and 𝑅𝑡 is its source encoding rate. These rates span 2.07–2.46 Mbps; normalization makes differently encoded tiles comparable. Thus, 𝐵𝑖 is the weakest track’s delivery percentage and 𝐷𝑖 its worst mean latency. Base video and audio are excluded, and the extrema can come from different tracks. From bad through stable to good access, MultiMoQ’s median 𝐵𝑖 rises through 39.4/52.5/60.5% while 𝐷𝑖 stays near 1 s. DASH provides moderate bottleneck delivery (22.4–39.1%) but 2.54–3.96 s latency; standard MoQ reaches 0.19–1.73 s but leaves 𝐵𝑖 at only 6.0– 12.8%. DASH therefore trades freshness for coverage and standard MoQ does the reverse. MultiMoQ shifts outcomes upward relative to both and leftward relative to DASH, giving the strongest joint balance. GStreamer8 decoded and composed the captured tiles into reencoded ERP video. Holding the source, client, and stable access condition fixed, we evaluated 21 matched viewports at seven timestamps and three yaw angles (−90◦ , 0◦ , and 90◦ ). Each 1280 × 720 viewport used a 100◦ × 100◦ field of view; we computed frame-level SSIM and 1-s clip-level VMAF against the source. Fig. 14 quantifies continuity. DASH had a 51.5% freeze ratio, 26 events, a 2.60-s maximum, and 22.67 s total frozen time. Standard MoQ had a 3.96% ratio, three events, a 0.93-s maximum, and 1.77 s total. MultiMoQ had one 0.50-s freeze and a 1.09% ratio. The transport-level continuity and latency improvements therefore remained visible after tile decoding and viewport composition. Fig. 15(b)–(c) quantifies this comparison. MultiMoQ’s SSIM values were concentrated near 1.0, with a mean of 0.990 and a minimum of 0.980. Its VMAF distribution shifted toward higher scores than

8 https://gstreamer.freedesktop.org/

MultiMoQ: Multi-Access Media-Over-QUIC for Robust Immersive Video Streaming

Figure 9: MultiMoQ improves enhancement-tile goodput and tail delay while keeping stalls near zero.

Figure 10: MultiMoQ preserves audio and base-track continuity across network conditions.

(a) Freeze ratio (%)

(b) Frozen time (s)

4.62%

2

4 2

1

1.09%

0

Worst-track avg. goodput (% of source rate)

DASH

MultiMoQ

0.50

Total

Maximum

Figure 12: Playback ablation: freeze ratio and duration.

Standard MoQ

(a) Bad access

1.03

0.50

0 Redesign

Figure 11: Transport ablation: stall time and runtime delay.

2.03

MultiMoQ

(b) Stable access

(c) Good access

75

Better

50 25 0

0

1

2

3

4

5 0

1

2

3

4

5 0

1

2

3

4

5

Worst-track mean E2E latency (s)

Figure 13: Per-client delivery across eight tracks: minimum source-normalized mean goodput versus maximum mean latency. Fig. 13 treats all eight enhancement tiles symmetrically and is neither a main-tile nor a viewport-weighted metric. As a receiverside aggregate, it omits compositor-selected timestamps, sametimestamp coverage, base fallback, missing viewport area, and inter-tile synchronization; Fig. 15 separately measures sampled viewport fidelity. Figure 14: MultiMoQ has the lowest freeze ratio and shortest maximum freeze. both baselines, avoiding DASH’s low-score tail. The perceptual metrics therefore confirm that the transport gains preserve viewport fidelity in addition to playback continuity.

4.5

Discussion

The results expose two bottlenecks. The MoQ-Lite redesign stabilized concurrent tracks by preserving active groups, but redesignonly delivery still accumulated delay on a degraded access. The controller explains the runtime-delay and freeze reductions, while full MultiMoQ also strengthened the weakest enhancement track.

Li et al.

Figure 15: Access assignment and quality for 21 viewports: MultiMoQ shifts SSIM and VMAF toward higher scores. The baselines expose the corresponding tradeoff: DASH avoided most transport stalls by buffering and falling behind, whereas standard MoQ remained timely for received objects but lost concurrenttrack continuity. Robust immersive playback required both continuous group delivery and timely access adaptation; either mechanism alone left one failure mode unresolved. Our scope is bounded to Mininet, one 4K source, one hierarchical topology, measured access distributions, and fixed 1-s media units, with bitrate adaptation disabled. The results isolate transport and delivery under these conditions rather than every Internet deployment; representation selection remains complementary to MultiMoQ.

systems cache adaptive or live 360° content [14–16]. These architectures reduce pressure on one origin but require coordination at servers, edges, or the network. MultiMoQ retains MoQ’s relay-assisted fan-out, changes group delivery inside MoQ-Lite, and places multi-access decisions at the client. It does not require multicast or a new edge-coordination protocol. Consequently, network-assisted delivery and MultiMoQ address different control points. The former decides where content is placed or shared; the latter preserves group continuity and selects among accesses after relay distribution is available.

5

In this paper, we present MultiMoQ, a MoQ-based framework for robust immersive video streaming under heterogeneous network conditions. By combining more stable MoQ-based delivery with client-driven multi-access adaptation, MultiMoQ enables live highbitrate 360° streaming to remain both responsive and robust under varying access quality. Our implementation and evaluation show that this design improves end-to-end streaming performance and bottleneck delivery across concurrent enhancement tracks, translating into smoother playback and higher viewport fidelity than DASH and standard MoQ. The ablation further confirms the contribution of multi-access control to playback continuity. These results suggest that MoQ, when extended with stronger delivery stability and access adaptation, provides a promising foundation for scalable, high-quality live immersive streaming.

Related Work

Viewport-adaptive streaming. Viewport-adaptive systems partition a panorama into tiles, predict the viewer’s orientation, and vary quality spatially or temporally to reduce bandwidth [4, 19, 20, 27, 32]. OMAF- and CMAF-based systems extend this approach to standards-compliant low-latency streaming [6, 10, 26]. These techniques decide which media to deliver, whereas MultiMoQ changes how concurrent selected tiles are transported. Most prior systems still request segments or chunks over DASH-style HTTP, whose delivery granularity limits responsiveness to network variation. These selection techniques are complementary to MultiMoQ. A viewport predictor or representation controller can choose the tile set before MultiMoQ schedules the resulting tracks across accesses. Their prediction and quality-allocation policies remain unchanged by our transport design. QUIC-based transport. QUIC and multipath-QUIC systems apply cross-layer scheduling and packet or path selection under dynamic conditions [11, 18, 23]. Other systems run DASH or end-to-end 360° pipelines over QUIC and HTTP/3 [21, 30]. This work improves transport efficiency and path use, but generally retains a direct client– server architecture. MultiMoQ instead operates within MoQ’s relay tree and coordinates path changes with per-track media continuity. The distinction is architectural: multipath transport schedules packets within an end-to-end connection, while MultiMoQ switches application-visible media subscriptions across relay-assisted accesses. It also maintains decoder-safe, monotonic output across a switch rather than exposing independent path streams to the player. Network-assisted delivery. Multi-source and distributed-node systems divide tiles across sources [28, 31]. Multicast and collaborative systems share delivery across users [2, 25], while edge-assisted

6

Conclusion

MultiMoQ: Multi-Access Media-Over-QUIC for Robust Immersive Video Streaming

References [1] Lemonia Argyriou, Daphne Economou, and Vassiliki Bouki. 2017. 360-degree interactive video application for cultural heritage education. In iLRN 2017 Coimbra! Verlag der Technischen Universität Graz, Graz, Austria, 297–304. doi:10.3217/978-3-85125-530-0-44 [2] Yanan Bao, Tianxiao Zhang, Amit Pande, Huasen Wu, and Xin Liu. 2017. MotionPrediction-Based Multicast for 360-Degree Video Transmissions. In 2017 14th Annual IEEE International Conference on Sensing, Communication, and Networking (SECON). IEEE, Piscataway, NJ, USA, 1–9. doi:10.1109/SAHCN.2017.7964928 [3] Mike Belshe, Roberto Peon, and Martin Thomson. 2015. Hypertext Transfer Protocol Version 2 (HTTP/2). RFC 7540. doi:10.17487/RFC7540 [4] Xavier Corbillon, Gwendal Simon, Alisa Devlic, and Jacob Chakareski. 2017. Viewport-adaptive navigable 360-degree video delivery. In 2017 IEEE International Conference on Communications (ICC). IEEE, Piscataway, NJ, USA, 1–7. doi:10. 1109/ICC.2017.7996611 [5] Luke Curley. 2026. Media over QUIC - Lite. Internet-Draft draft-lcurley-moq-lite03. Internet Engineering Task Force. Work in Progress. https://datatracker.ietf. org/doc/draft-lcurley-moq-lite/03/ [6] Yago Sanchez de la Fuente, Gurdeep Singh Bhullar, Robert Skupin, Cornelius Hellge, and Thomas Schierl. 2019. Delay impact on MPEG OMAF’s tile-based viewport-dependent 360 video streaming. IEEE Journal on Emerging and Selected Topics in Circuits and Systems 9, 1 (2019), 18–28. [7] Made Harta Dwijaksara, Muhammad Hafizhuddin Hilman, Chankyun Lee, and Wonhyuk Lee. 2024. Rate adaptation technique for media streaming over quic with limited backhaul. IEEE Access 12 (2024), 139028–139041. [8] Omar Eltobgy, Omar Arafa, and Mohamed Hefeeda. 2020. Mobile streaming of live 360-degree videos. IEEE Transactions on Multimedia 22, 12 (2020), 3139–3152. [9] James Gruessing and Spencer Dawkins. 2023. Media Over QUIC - Use Cases and Requirements for Media Transport Protocol Design. Internet-Draft draftietf-moq-requirements-02. Internet Engineering Task Force. Work in Progress. https://datatracker.ietf.org/doc/draft-ietf-moq-requirements/02/ [10] Miska M Hannuksela and Ye-Kui Wang. 2021. An overview of omnidirectional media format (OMAF). Proc. IEEE 109, 9 (2021), 1590–1606. [11] Liekun Hu and Changlong Li. 2025. STORM: a Multipath QUIC Scheduler for Quick Streaming Media Transport under Unstable Mobile Networks. In 2025 USENIX Annual Technical Conference (USENIX ATC 25). USENIX Association, Boston, MA, 851–866. https://www.usenix.org/conference/atc25/presentation/ hu-liekun [12] Aden Kittel, Michael Spittle, Paul Larkin, and Sharna Spittle. 2023. 360 VR: Application for exercise and sport science education. Frontiers in Sports and Active Living 5 (2023), 977075. [13] Bob Lantz, Brandon Heller, and Nick McKeown. 2010. A Network in a Laptop: Rapid Prototyping for Software-Defined Networks. In Proceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks (Monterey, California) (HotNets-IX). Association for Computing Machinery, New York, NY, USA, 1–6. doi:10.1145/1868447.1868466 [14] Chen Li, Tingwei Ye, Tongyu Zong, Liyang Sun, Houwei Cao, and Yong Liu. 2025. Coffee: Cost-effective edge caching for live 360 degree video streaming. Computer Networks 269 (2025), 111461. [15] Anahita Mahzari, Afshin Taghavi Nasrabadi, Aliehsan Samiei, and Ravi Prakash. 2018. FoV-Aware Edge Caching for Adaptive 360 Video Streaming. In Proceedings of the 26th ACM international conference on Multimedia. Association for Computing Machinery, New York, NY, USA, 173–181. doi:10.1145/3240508.3240680 [16] Pantelis Maniotis and Nikolaos Thomos. 2021. Tile-based edge caching for 360° live video streaming. IEEE Transactions on Circuits and Systems for Video Technology 31, 12 (2021), 4938–4950. [17] Suhas Nandakumar, Victor Vasiliev, Ian Swett, and Alan Frindell. 2026. Media over QUIC Transport. Internet-Draft draft-ietf-moq-transport-17. Internet Engineering Task Force. Work in Progress. https://datatracker.ietf.org/doc/draft-ietf-moq-

transport/17/ [18] Sohee Park and Samir R Das. 2024. Cross-Layer Scheduling in QUIC and Multipath QUIC for 360-Degree Video Streaming. In 2024 IEEE Wireless Communications and Networking Conference (WCNC). IEEE, Piscataway, NJ, USA, 1–6. doi:10.1109/WCNC57260.2024.10571146 [19] Feng Qian, Bo Han, Qingyang Xiao, and Vijay Gopalakrishnan. 2018. Flare: Practical Viewport-Adaptive 360-Degree Video Streaming for Mobile Devices. In Proceedings of the 24th Annual International Conference on Mobile Computing and Networking (New Delhi, India) (MobiCom ’18). Association for Computing Machinery, New York, NY, USA, 99–114. doi:10.1145/3241539.3241565 [20] Giuseppe Ribezzo, Giuseppe Samela, Vittorio Palmisano, Luca De Cicco, and Saverio Mascolo. 2018. A DASH Video Streaming System for Immersive Contents. In Proceedings of the 9th ACM Multimedia Systems Conference. Association for Computing Machinery, New York, NY, USA, 525–528. doi:10.1145/3204949. 3208107 [21] Felipe Rosa, Simone Ferlin, Anna Brunstrom, and Bruno Kimura. 2025. End-toEnd 360 Video Streaming over HTTP/3: Architecture and Implementation. In Proceedings of the 2025 Applied Networking Research Workshop. Association for Computing Machinery, New York, NY, USA, 9–16. doi:10.1145/3744200.3744784 [22] Rabia Shafi, Wan Shuai, and Muhammad Usman Younus. 2020. 360-Degree Video Streaming: A Survey of the State of the Art. Symmetry 12, 9 (2020), 1491. doi:10.3390/sym12091491 [23] Cong-Xi Song, Biao Han, and Jin-Shu Su. 2024. 4d-map: Multipath adaptive packet scheduling for live streaming over quic. Journal of Computer Science and Technology 39, 1 (2024), 159–176. [24] Thomas Stockhammer. 2011. Dynamic Adaptive Streaming over HTTP: Standards and Design Principles. In Proceedings of the second annual ACM conference on Multimedia systems. Association for Computing Machinery, New York, NY, USA, 133–144. doi:10.1145/1943552.1943572 [25] Liyang Sun, Yixiang Mao, Tongyu Zong, Yong Liu, and Yao Wang. 2020. FlockingBased Live Streaming of 360-Degree Video. In Proceedings of the 11th ACM Multimedia Systems Conference. Association for Computing Machinery, New York, NY, USA, 26–37. doi:10.1145/3339825.3391856 [26] Mikko Uitto and Antti Heikkinen. 2020. Exploiting and Evaluating Live 360 Low Latency Video Streaming Using CMAF. In 2020 European Conference on Networks and Communications (EuCNC). IEEE, Piscataway, NJ, USA, 276–280. doi:10.1109/EUCNC48522.2020.9200954 [27] Mengbai Xiao, Chao Zhou, Viswanathan Swaminathan, Yao Liu, and Songqing Chen. 2018. BAS-360: Exploring Spatial and Temporal Adaptability in 360-degree Videos over HTTP/2. In IEEE INFOCOM 2018 - IEEE Conference on Computer Communications. IEEE, Piscataway, NJ, USA, 953–961. doi:10.1109/INFOCOM. 2018.8486390 [28] Xiufeng Xie and Xinyu Zhang. 2017. POI360: Panoramic Mobile Video Telephony over LTE Cellular Networks. In Proceedings of the 13th International Conference on emerging Networking EXperiments and Technologies. Association for Computing Machinery, New York, NY, USA, 336–349. doi:10.1145/3143361.3143381 [29] Abid Yaqoob, Ting Bi, and Gabriel-Miro Muntean. 2020. A survey on adaptive 360 video streaming: Solutions, challenges and opportunities. IEEE Communications Surveys & Tutorials 22, 4 (2020), 2801–2838. [30] Shou-Cheng Yen, Ching-Ling Fan, and Cheng-Hsin Hsu. 2019. Streaming 360 Videos to Head-Mounted Virtual Reality Using DASH over QUIC Transport Protocol. In Proceedings of the 24th ACM Workshop on Packet Video. Association for Computing Machinery, New York, NY, USA, 7–12. doi:10.1145/3304114.3325616 [31] Xinjing Yuan, Lingjun Pu, Jianxin Shi, Qianyun Gong, and Jingdong Xu. 2022. Muster: Multi-source streaming for tile-based 360 videos within cloud native 5g networks. IEEE Transactions on Mobile Computing 22, 11 (2022), 6616–6632. [32] Chao Zhou, Mengbai Xiao, and Yao Liu. 2018. ClusTile: Toward Minimizing Bandwidth in 360-degree Video Streaming. In IEEE INFOCOM 2018 - IEEE Conference on Computer Communications. IEEE, Piscataway, NJ, USA, 962–970. doi:10.1109/INFOCOM.2018.8486282

Related documents

• Safety and Privacy in Immersive Extended Reality: An Analysis and Policy Recommendations#679011
• WP2 — Trayectorias de recuperación funcional en espondiloartropatía#122305
• EgoGazeLite: On-Device Egocentric Gaze Prediction for Token-Efficient Multimodal LLM Video Input#616766
• EgoGazeLite: On-Device Egocentric Gaze Prediction for Token-Efficient Multimodal LLM Video Input#616266
• Amplifying robotics capacities with a human touch: An immersive low-latency panoramic remote system#128271