Grand Unified Testbed

Status: Draft — April 2026 · Updated 28 April 2026; phased test window timeline agreed at WP2.4 weekly

This page documents the Grand Unified Testbed — a single logical testbed that spans four underlying physical testbeds, unified by Strand 2 components and a shared component stack. It answers the question: for each testbed, which component fills each role in the delivery chain, and which components are shared across testbeds?

Planning

Agreed phased timeline

Phased approach agreed by all WP2.4 partners at the 28 April 2026 meeting with no objections.

Arctic Space DTE and ViaSat — already underway; changes expected to be minimal.

EBU test bed — third week of June (15–19 June 2026), subject to Thijs (Varnish) providing test case descriptions beforehand.

ViaSat (WP2.5) — targeting the latter half of the June–August window.

Unified integration test — early September 2026 (exact dates to be confirmed, dependent on MS3 milestone timing). EBU satellite capacity is only available in September, which is the primary driver of this window. FTA and Varnish API integration must be resolved before the full unified test can proceed.

IBC (mid-September) — demonstrable capability around IBC noted as a useful proof point. Format can be video, slides, reports, or a mimic setup. The goal is a comparison between broadband baseline, dynamic cache activation, and predictive satellite pre-population.

Further EBU windows — last week of October and second week of December (December slot pending confirmation from Maria at EBU on return from holiday).

MS3 milestone — timing remains unconfirmed as of 28 April 2026. If MS3 shifts, the September satellite window may need to adjust accordingly.

Three testing scenarios

The following three comparison scenarios are locked in. K6 will automate them.

Notable constraint

MS3 milestone timing remains unconfirmed as of 28 April 2026. The primary blocker for the full unified integration test is the FTA and Varnish API integration, which is unresolved. Varnish has indicated readiness to integrate in time for MS3 (September timeline). If MS3 shifts, the September satellite window may need to adjust accordingly.

Virtual Testbed Structure

The Grand Unified Testbed spans four underlying physical testbeds. The HNR Media Service Platform (MSP), operating under WP 2.1, bookends all of them: it provides the ingest streams at one end and the reference player with telemetry collection at the other. Everything between those bookends varies by testbed.

Architecture

Figure: Grand Unified Testbed — a virtual testbed spanning the physical testbeds. Columns are delivery-infrastructure variants; rows are abstract component roles. Purple italics in row headers denote conceptual sub-roles; cell content names concrete providers. ◆ marks components shared across testbeds; dashed outlines mark pending integrations or deliberately empty cells.

MSP bookending role (WP 2.1)

The MSP supplies three things common to every testbed:

• Streams in — packaged CMAF origin streams available to all delivery paths.
• Players out — the reference player Test Harness, used consistently for content consumption and result comparability.
• Telemetry — CMCD / CMSD signals fed back from players into Demand Control.

The four testbeds

The Baseline is the reference: it is the MSP operating over public internet unicast with no prediction, no prioritisation, and no satellite delivery. All other testbeds extend this by adding a delivery pathway and the WP 2.4 or WP 2.5 control plane components.

Testing Scope

The virtual testbed serves two distinct testing purposes, which must not be conflated.

Functional testing — cross-testbed. Because the shared components (HNR MSP Media Origin, Content Discovery, Service Discovery, Demand Control, SCAL, Content Steering, Test Harness) are the same software running across all testbeds, functional correctness can be verified once and asserted across the whole virtual testbed. A functional test result — does the component behave correctly? — is transferable between testbeds.

Non-functional testing — per testbed only. Performance, resilience, and load characteristics are measured independently within each testbed and cannot be compared across testbeds. Each testbed sits on a different underlying infrastructure — satellite link type, access technology, edge compute capability, and network topology all differ — and each imposes its own set of limiting factors. A latency measurement on the Arctic Space testbed reflects VSAT propagation and northern-Sweden edge compute; the same measurement on the Baseline testbed reflects public CDN edge behaviour. These are structurally incomparable. Non-functional results are therefore reported per testbed and interpreted against that testbed's own constraints, not against each other.

Axes

Columns — Testbeds

The columns are variants of the delivery infrastructure, not geographical testbeds per se. They differ by what sits between the origin and the far edge.

Rows — Component Roles

The rows are abstract component roles in the delivery chain, not concrete products. Multiple concrete implementations can slot in under one role.

Matrix

Each cell names the providers filling the role on that testbed. The role header lists the conceptual sub-roles (what the component does); providers within a cell are listed together without per-sub-role pairing — the concept/provider split is maintained by the row-header / cell-content separation. Shared components (◆) span multiple testbeds.

Shared components (joined or banded cells in the diagram):

• HNR MSP Media Origin — single component across all four testbeds (row A).
• HNR Content Discovery API + HNR Service Discovery Registry — both shared across all four testbeds (row B), sitting side by side in the same layer; Content Discovery answers "what content exists?"; Service Discovery answers "where should I get it?" at capability and stream registration levels.
• Supply Control Abstraction Layer (SCAL, HNR) — horizontal band across all active testbeds (row D); one HNR-owned entry point that Demand Control calls regardless of whether the downstream hop is Fenix, FTA or CAMARA.
• Content Steering band (HNR) — horizontal band across all active testbeds (row D, below the transmission hop); HNR-owned DASH-IF steering and edge routing. Every testbed terminates through it.
• Test Harness (HNR) — single component across all four testbeds (row F).
• Peach + Varnish + HNR (Demand Control) — intended across testbeds 2–4 as three distinct elements (Peach for prediction, Varnish as popularity signal source, HNR for prioritisation / selection / cache population); not exercised on Baseline.

Cells currently empty or pending:

• Demand Control on Baseline is deliberately unused — the Baseline scenario is "no prediction, no prioritisation, unicast CDN only".
• Supply Control on Baseline is empty — direct CDN has no orchestration layer.
• FTA Supply Control depends on Tele's integration plan.

Feedback Loops

The chain is not strictly top-to-bottom. Two explicit feedback paths close the loop between consumption signals and the discoverable catalogue.

Content Selection → Content Discovery (registration)

Demand Control's Content Selection output is not just an instruction to Supply Control — it is also registered back into Content Discovery. The registration establishes the chosen service/stream as a discoverable, addressable endpoint with its enhanced delivery path (e.g. far-edge-backed URL, steered manifest, prioritised transmission slot).

The effect is that clients hitting the Content Discovery API see a selection-enriched catalogue rather than a static list. A stream selected for satellite push on Arctic Space appears in Discovery with its far-edge routing hints; a stream that has not been selected is discoverable only via the baseline path.

Consumption signals → Demand Control

Varnish status codes and player telemetry (CMCD, CMSD) feed back into Demand Control's Popularity and Prediction sub-roles, shaping the next Selection cycle.

Diagram treatment

• A dashed feedback arrow runs from Demand Control (Selection) up to Content Discovery, labelled "registers services / streams".
• A second dashed feedback arrow runs from Content Consumption (Test Harness / far edge) up to Demand Control, labelled "popularity / telemetry signals".
• Feedback arrows use a different line style from the primary downward flow so the loops read as return paths rather than alternative forward paths.

Umbrella Naming — Demand Control / Supply Control

Supply Control is adopted as the paired concept to Demand Control. Demand Control decides what should move; Supply Control actions it via network and satellite APIs. "Transmission Management" and "Exposure Gateway" are retired as row labels; they become sub-roles within Supply Control.

Demand Control — sub-roles

• Content Prediction
• Content Popularity
• Content Prioritisation
• Content Selection

Supply Control — sub-roles

• Supply Control Abstraction Layer (SCAL, HNR) — the single HNR-owned entry point for Demand Control. Drawn as a horizontal band spanning all active testbeds so that upstream components (Demand Control, Service Discovery) remain testbed-agnostic. Supersedes the earlier name "HNR Transmission Abstraction Layer".
• Transmission Scheduling — Fenix API (Arctic Space), FTA API (FTA strands); called from beneath SCAL.
• Network Capability Exposure — CAMARA (5G private network, WP 2.5). Sandwiched between SCAL above and the Content Steering band below, i.e. Demand Control → SCAL → CAMARA → Content Steering.
• Edge Routing / Content Steering (HNR) — DASH-IF content steering and traffic redirection (WP 2.4.3). Drawn as a second horizontal band spanning all active testbeds, below the transmission hop, so every path terminates through HNR steering before reaching the far edge.

Why the abstraction layer: only Arctic Space uses Fenix; other testbeds use FTA, which is more industry-stable (per Thijs). Rather than picking one, HNR owns an abstraction so the upstream Demand Control and Service Discovery components remain testbed-agnostic.

Content Discovery vs. Service Discovery

• Content Discovery answers "what content exists?" — titles, channels, catalogue entries.
• Service Discovery answers "where should I get it?" — edge location selection and service endpoint registration. It operates at two levels:
  • Capability registration — a testbed or far edge declares what it can do (e.g. "Arctic far edge can serve satellite-pushed CMAF with X latency and Y cache capacity"). Registered once per capability change.
  • Stream registration — an individual stream or asset is bound to a registered capability (e.g. "stream NewsChannel-1 is live on the Arctic far edge with enhanced manifest foo.mpd"). Registered per Selection cycle out of Demand Control.
• Service Discovery overlaps with content steering at the manifest/redirect layer but is upstream of it: steering picks among registered endpoints; Service Discovery is what registers them.

Diagram Intent

The matrix diagram is rendered as a grid with testbeds across the top and component roles down the side. Horizontally joined or merged cells mark components shared across testbeds (HNR MSP Media Origin, Test Harness). Row B (Discovery) spans the full width and is split internally — Content Discovery API on the left, Service Discovery Registry on the right, separated by a dividing line within the same shared band.

Within row D (Supply Control), two horizontal HNR-owned bands span the active testbeds:

• the upper band is the Supply Control Abstraction Layer (SCAL);
• the lower band is Content Steering.

Between the two bands, each testbed column shows its testbed-specific transmission hop (Fenix, FTA or CAMARA). CAMARA sits in the 5G column, sandwiched between the two HNR bands.

Within row C (Demand Control), each active testbed cell shows three distinct elements — Peach, Varnish, HNR — rather than being collapsed into a single provider badge, mirroring the elements in the Demand Controller architecture diagram.

Visual conventions:

• HNR-owned components use an indigo / brand accent.
• Partner-owned components use a neutral green.
• Pending or unresolved cells use a dashed outline with a "TBC" label.
• Deliberately empty cells are greyed out with an em dash.
• A legend at the foot of the diagram summarises ◆ shared components and dashed = pending.

Open Areas

The following areas need to be worked through before the strategy can be considered complete.

Purpose

To be developed. This section should cover:

• Variations by testbed — what each testbed brings that the others do not: the transmission systems used (satellite link type, DTH broadcast, VSAT backhaul), far-edge variants, and the specific demand/supply control features exercised.
• Coverage — which combinations of delivery pathway × control feature are tested, and which are intentionally out of scope.
• Use cases — the user scenarios validated by the approach, and how they map to test scenarios.
• Notes from Walid — additional context on DTH, DTV, and DTE characteristics and their implications for the test strategy.

Implementation

To be developed. This section should cover how the virtual testbed approach is put into practice: tooling, orchestration, test harness configuration, and any shared infrastructure decisions.

Timeline

To be developed. This section should address:

• Whether the approach can be executed within the programme schedule.
• Constraints — dependencies between testbeds, partner integration readiness, and any limiting factors on parallelism.

Open Thoughts

• Use-case-driven test scenarios. Different use cases should be validated against this approach; these validations directly inform which test scenarios are exercised across the virtual testbed.
• Comparison scope. Comparison between the Baseline and the three extended testbeds (EBU-DTH, Arctic Space DTE, ViaSat DTV) is valid and meaningful. Direct comparison between the three extended testbeds is not appropriate — each sits on a structurally different underlying infrastructure with different limiting factors, so results cannot be attributed to the delivery path alone.

Further Reading

• Architectural Blueprint — system architecture, functional design, and technology standards
• Programme Structure — strand and work package structure
• Testbeds — how each testbed realises the logical architecture
• E2E Scenarios — end-to-end service scenarios validated against this architecture