MSF & SDC

Media Streaming Federation (MSF) and Supply & Demand Control (SDC) are two halves of one architecture, and this page holds both.

MSF is the federated substrate: the registry, the catalogue and the discovery APIs that establish what content exists, where it can be obtained, and which actors are permitted to see it. SDC is the control model that runs on top of it: what to deliver, when, over which pathway, and for how long.

They were documented separately for most of Phase 1, and the split did not survive contact with Phase 2. Every SDC decision resolves against an MSF registration, and every MSF pathway exists in order to be selected by an SDC decision — describing either one alone meant describing half of the other anyway.

This page is the architecture. Its realisation across four physical testbeds is the Grand Unified Testbed; the system-level context it sits in is the Architectural Blueprint.

The two-sided control model

Demand Controls decide what content to deliver, when, via which pathway, and for how long. Supply Controls act on those decisions — coordinating transmission, caching, and access-layer delivery.

The two halves are coupled through exactly two things: a content-selection signal (SC-Sel) travelling demand → supply, and a telemetry loop travelling supply → demand. That narrowness is the design rather than an accident of drawing. One signal crossing in each direction is what allows a transmission hop to be swapped — satellite for broadcast for 5G backhaul — without changing anything above it.

Why the names changed

Supply Control was adopted as the paired concept to Demand Control during Phase 2 shaping. Two earlier row labels were retired in the process: "Transmission Management" and "Exposure Gateway" are now sub-roles within Supply Control rather than peers of it. "HNR Transmission Abstraction Layer" became the Supply Control Abstraction Layer (SCAL).

Half	Sub-roles
Demand Control	Content Prediction · Content Popularity · Content Prioritisation · Content Selection
Supply Control	Supply Control Abstraction Layer · Transmission Scheduling · Network Capability Exposure · Edge Routing / Content Steering

Influencing Factors

Before anything enters the control flow, each side is driven by a set of factors.

Supply and Demand Factors — categories of supply and demand inputs Figure: Supply and demand factors. Supply factors (left) push into the system; demand factors (right) pull feedback back from the delivery infrastructure.

Supply factors push information into the system:

External factors — world events and time signals
Business factors — promotion, marketing, and campaign data
Content factors — metadata and scheduling constraints
Pathway factors — cost, bandwidth, and availability of delivery paths
Consumer factors — device types, resolutions, locality, and demographics

Demand factors pull information back from the delivery infrastructure:

Distribution factors — cache status and QoS signals from the network
Consumption factors — location and QoE/CMCD feedback from players

Control Architecture

Those factors are mapped across the full system by the five System Functions. Demand Controls occupy SF1–SF2; Supply Controls occupy SF3–SF5; Telemetry in SF5 closes the loop back into both Content Prediction and Content Popularity.

Two families of API carry the architecture, and they fire at different times. Registration APIs establish the space of possible deliveries. Demand APIs pick one out of that space and make it happen. Nothing can be selected that was not first registered.

Registration APIs — the federation half

Provided by HNR under WP 2.4.3. This is MSF proper: a registry that owns the Federation Catalogue and never exposes it raw.

Interactive

Figure: three actor roles, three role-projected views of one catalogue, and the Offering → Representation → Pathway hierarchy the views project. Opened in full, each actor role and the provider lifecycle are guided views.

Content Discovery API — answers what content exists. Partners and the platform retrieve the content catalogue from Content Delivery Infrastructure (CDI) endpoints.
Service Discovery Registry (SReg) — answers where content can be obtained. Services register their delivery endpoints here; Content Steering later acts on those registrations to route clients.

Service Discovery operates at two levels, and conflating them causes trouble later:

Capability registration — what a testbed or far edge declares it can do. For example, "the Arctic far edge can serve satellite-pushed CMAF at X latency with Y cache capacity." Registered once per capability change.
Stream registration — an individual stream bound to a registered capability. For example, "NewsChannel-1 is live on the Arctic far edge under enhanced manifest foo.mpd." Registered once per Selection cycle, out of Demand Control.

Service Discovery is not Content Steering. These are distinct components at different layers. Service Discovery registers available delivery endpoints; Demand Control determines which content should be supplied by which pathway; Content Steering acts on those registrations and decisions to guide clients to the most appropriate pathway.

Demand APIs — the control half

Called when demand drives supply. These are the mechanism by which a content-selection decision becomes an actual transmission. The diagram follows the path end to end in five lanes: the signals that inform a decision, the one box that takes it, the abstraction layers that dispatch it, the far edge it lands on, and the player that consumes it — with telemetry returning along the bottom to where the cycle began. The Supply Control lane is drawn as three SCALs, one per capability: steering, transmission — which wraps Fenix and FTA — and network exposure, which wraps the CAMARA API and reaches the operator's 5G network. Two pathways therefore reach the player, the far edge cache and the 5G network, and both are playout.

Interactive

Figure: Supply & Demand Control as a data flow, in five lanes. SC-Sel is the only signal that crosses from demand to supply, and a SCAL is the only entry point that accepts it — one for each of steering, transmission and network exposure. Opened in full, it isolates the signals, the decision, the boundary, the far edge and the feedback loop as guided views.

Supply Control Abstraction Layer (SCAL, HNR) — the single HNR-owned entry point. Demand Control calls SCAL; SCAL calls the appropriate testbed-specific transmission interface downstream.
Fenix API (Arctic Space DTE) — satellite transmission scheduling. POST /streams returns an ID; a queued state when bandwidth is insufficient is the mechanism exercised directly by the "can the satellite keep up with demand?" scenarios. Spec v3.3.0.
FTA API (EBU-DTH) — DTH broadcast scheduling for the EBU testbed. Swagger specification pending.
CAMARA APIs (ViaSat DTV, WP 2.5) — 5G network capability exposure (QoS, slicing). Sits between SCAL and Content Steering rather than upstream of a transmission hop, which makes ViaSat structurally unlike the other two satellite paths.

Of the three SCAL-compliant component areas, only Content Steering is native. Transmission Management (Fenix, FTA gStream) and the Exposure Gateway (CAMARA) are reached through sidecars, because those interfaces are partner-owned and were not designed against SCAL.

Why an abstraction layer at all. Only Arctic Space uses Fenix; the other testbeds use FTA, which is the more industry-stable interface. Rather than the programme picking one and making every upstream component speak it, HNR owns an abstraction so that Demand Control and Service Discovery stay testbed-agnostic. The cost is real and worth naming: Fenix v3.3.0 requires a shaping decision at request time, so Demand Control has to decide early enough for SCAL to schedule — the abstraction hides the interface, not the deadline.

Demand Controls (SF1–SF2)

The decision-making half. They determine which content to deliver and produce the content-selection signal (SC-Sel) passed to the supply side.

Component	Role
Service Discovery	Discovers available services (CDIs) and registers them via SReg. Answers where content can be obtained.
Content Discovery	Retrieves the content catalogue from CDIs. Answers what content exists.
Business Rules / Decision Logic	Applies business rules to derive content selection parameters (DC-Params).
Content Selection	Selects content using those parameters and the priority signals; emits SC-Sel to Supply Controls.
Content Prioritisation	Ranks content by priority (DC-Pri) to resolve contention between candidates.
Content Prediction (Peach)	Predicts future demand (DC-Pred) to enable proactive caching and transmission scheduling. †
Content Popularity (Varnish signal)	Measures current demand (DC-Pop) to inform prioritisation and prediction.

† Content Prediction calls SCAL independently of the Cache Population Component. Deduplication logic inside SCAL is what prevents two duplicate transmissions of the same title.

Supply Controls (SF3–SF5)

Supply Controls receive SC-Sel from the demand side and coordinate actual delivery to the player. They are organised in two horizontal bands — SCAL above and Content Steering below — with the testbed-specific transmission hops between them.

Component	Role
SCAL (HNR)	Single HNR-owned entry point. Abstracts every downstream transmission path behind one testbed-agnostic call.
Transmission Scheduling	Fenix API (Arctic Space) and FTA API (EBU). Called beneath SCAL through a sidecar.
Network Capability Exposure	CAMARA on the ViaSat private 5G network (WP 2.5). Sandwiched between SCAL above and Content Steering below.
Content Steering (HNR)	DASH-IF steering and traffic redirection (WP 2.4.3). Directs the player to the appropriate pathway and edge, acting on endpoints registered via SReg. Spans every active testbed; every path terminates through it.
Far Edge Cache	Caches content at the far edge to serve the access network. Varies per testbed.
Access Network	Delivers content to the player over the final access segment.
Player	Receives content; emits telemetry (Tel) back into SF5.

Feedback Loops

The chain is not strictly one-directional. Two loops run backwards through it, and both matter to how the system behaves.

Selection → Content Discovery. A selection decision is not only passed to Supply Control; it is also registered back into Content Discovery. That registration is what makes the chosen service or stream discoverable at an addressable endpoint on the enhanced delivery path — a far-edge-backed URL, a steered manifest, a 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 far-edge routing hints; a stream that has not been selected is discoverable only over the baseline path.

Consumption → Demand Control. Varnish status codes and player telemetry (CMCD, CMSD) feed back into Content Popularity and Content Prediction, shaping the next Selection cycle.

Both loops are drawn as dashed returns rather than solid forward edges, so that a reader does not mistake a return path for an alternative way forward.