Supply & Demand Control — from signal to playout

Supply & Demand Control — from signal to playout A data-flow diagram generated by Archify. 01 / Signals 02 / Demand Control 03 / Abstraction 04 / Transmission 05 / Consumption Popularity · Varnish · 01 / Signals · DC-Pop Popularity Varnish DC-Pop Prediction · Peach · 01 / Signals · DC-Pred Prediction Peach DC-Pred Content Disc. · HNR API · 01 / Signals Content Disc. HNR API Priority · DC-Pri · 02 / Demand Control Priority DC-Pri Selection · WP 2.4 · 02 / Demand Control Selection WP 2.4 SCAL · HNR entry · 03 / Abstraction · one door SCAL HNR entry one door Service Reg. · endpoints · 03 / Abstraction Service Reg. endpoints Fenix API · v3.3.0 · 04 / Transmission Fenix API v3.3.0 FTA API · DTH · TBC · 04 / Transmission FTA API DTH · TBC CAMARA · QoS · slice · 04 / Transmission CAMARA QoS · slice Steering · DASH-IF · 05 / Consumption Steering DASH-IF Far edge · per testbed · 05 / Consumption Far edge per testbed Player · emits Tel · 05 / Consumption Player emits Tel counts forecast titles DC-Pri order SC-Sel endpoints queue schedule QoS ask pathways pre-push broadcast slice playout steer view counts QoE reports Legend primary data async batch data store data flow

Two halves, one signal between them

  • • Demand Control decides what should move; Supply Control makes it move.
  • • SC-Sel is the only signal that crosses the boundary, and SCAL is the only entry point that accepts it.

Discovery is two components

  • • Content Discovery answers "what content exists?".
  • • Service Discovery answers "where should I get it?", at capability and stream level.
  • • Content Steering acts on what Service Discovery registered — it registers nothing itself.

Why the abstraction layer exists

  • • Only Arctic Space uses Fenix; other testbeds use FTA, and ViaSat exposes CAMARA.
  • • SCAL absorbs that difference so everything upstream stays testbed-agnostic.