MS3 Component Matrix

Status: Draft — April 2026 · Working spec for the 20 April 2026 MS3 technical review

This page specifies a matrix diagram covering WP 2.1, WP 2.4 and WP 2.5 as a unified front. It answers the question: for each testbed, which component fills each role in the delivery chain, and which components are shared across testbeds?

Figure: MS3 testbed × component matrix. 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.

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 Media Origin — single component across all four testbeds (row A).
• HNR Content Discovery API — single component across all four testbeds (row B).
• HNR Service Discovery Registry — single component across all four testbeds (row B'); internally holds two registration levels (capability + stream).
• 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 Phoenix, 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.
• HNR Test Harness — 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 — Phoenix 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 Varnish uses Phoenix; other testbeds use FTA, which is more industry-stable. 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 Media Origin, Content Discovery API, Service Discovery Registry, Test Harness).

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 (Phoenix, 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.

Related Pages

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