Supply & Demand Control

The 5G-EMERGE content delivery architecture is governed by a 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 a content-selection signal and a telemetry feedback loop.

Influencing Factors

The factors diagram shows what drives decisions on each side before they enter the control flow.

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

The control diagram maps these factors across the full system, organised by the five System Functions (SF1–SF5).

Figure: Supply and Demand Control architecture. Demand Controls occupy SF1–SF2; Supply Controls occupy SF3–SF5. Telemetry (SF5) closes the feedback loop into both Content Prediction and Content Popularity.

Two families of APIs are at the heart of this control model.

Registration APIs — provided by HNR (WP 2.4.3). They establish the space of possible deliveries before any demand signal fires:

Figure: Service and Content Registry and Discovery. External providers register and bind streams; the catalogue is served via the Content Discovery API; the Media Streaming Service resolves delivery endpoints via the Service Discovery Registry.

• 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.

Demand APIs — called when demand drives supply. They are the mechanism by which a content-selection decision becomes an actual transmission:

Figure: Supply and Demand Control. Demand Control aggregates four input signals to produce Selection and Ranking; Supply Control executes those decisions across Content Steering, Transmission Management, and Exposure Gateway. The Exposure Gateway feeds network state back to Demand Control.

• 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 for the Arctic Space testbed. Called from SCAL.
• FTA API (EBU-DTH) — DTH broadcast scheduling for the EBU testbed. Called from SCAL. Swagger specification pending.
• CAMARA APIs (ViaSat DTV, WP 2.5) — 5G network capability exposure (QoS, slicing) for the ViaSat testbed. Sits between SCAL and Content Steering in the ViaSat column.

Demand Controls (SF1–SF2)

Demand Controls are the decision-making half. They determine what content to deliver and produce the content-selection signal (SC-Sel) passed to the supply side.

Telemetry (Tel) from SF5 feeds back into both Content Prediction and Content Popularity, closing the demand-side learning loop.

Service Discovery vs Content Steering — these are distinct components at different layers. Service Discovery (Demand side, Registration API) registers available delivery endpoints. Content Steering (Supply side) acts on those registered endpoints to route clients to the most appropriate one. They are not interchangeable.

Supply Controls (SF3–SF5)

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

Further Reading

• Architectural Blueprint — system-level architecture and System Function definitions
• Grand Unified Testbed — how these components map across testbeds
• Testbeds — testbed-level realisation of the Supply Controls