Eventhub v3 as TA gateway

[frytg]

Should or could Eventhub be a TA traffic announcement gateway?

Specific sub-channel via MQTT vs. Pub/Sub with tokens and potentially longer round trips?

[frytg]

High-Level Idee

Aktuelles Setup im Eventhub: Anlieferung per HTTPS API an Eventhub Ingest, gehostet im ARD Online Cluster (GCP); Verteilung der Events über Pub/Sub.

High-Level Plan für Eventhub v3: Erweiterung durch redundantes MQTT Broker-Setup im ARD CN; Ergänzung von Control-Events (TA-Bit, Regio-Bit) und Text-Events (Radiotext) zur Ablösung vom zentralen ZI-Gateway; bisheriger Weg der Anlieferung bleibt zur Kompatibilität erhalten; KEINE Ergänzung von statischen EPG Informationen (diese sind im POC).

Vorteile durch MQTT

• Allgemeiner Überblick: https://www.perplexity.ai/search/high-level-erklarung-zum-mqtt-nQ0xnc8qRS2Y2JQ1luDK.Q
  • Mehr Infos: Wikipedia, mqtt.org
• Beim aktuellen Pub/Sub Push-Weg braucht jede LRA einen öffentlich erreichbaren HTTPS-Endpunkt an den die Events geschickt werden. Mit dem MQTT Broker dreht sich dieser Weg (Clients bauen die Verbindung zum Broker auf)
  • das erleichtert die Firewall Konfiguration in den Häusern
• Mit dem Protokoll sind wir Anbieter-unabhängig. Open Source Broker gibt es endlos, Client-Bibliotheken für alle gängigen Sprachen ebenso
• Durch bereits aufgebaute TCP-Connections wird einiges an Latenz eingespart (Lookups, Verbindungsaufbau, SSL-Handshakes); die Verlagerung ins ARD CN bringt auch nochmal kürzere Laufwege; außerdem ist man Internet-unabhängig

Anforderungen/ Entwicklungsleistung Eventhub v3

• Ergänzung des Datenmodells durch neue Event-Typen
  • Control-Event (z.B. de.ard.eventhub.v1.radio.control )
    • TA-Bit on/off
    • Regio-Blocking on/off
  • Radiotext de.ard.eventhub.v1.radio.text (siehe existierenden Prototyp mit hr)
  • (in Ergänzung zu bestehenden de.ard.eventhub.v1.radio.track.playing & de.ard.eventhub.v1.radio.track.next )
• MQTT Broker im redundanten Setup beim ARD Stern oder SWR innerhalb des CNs
• Datenvalidierung einkommender Events (Zulieferung weiterhin über HTTPS API und neu MQTT)
• Abstimmung mit dem zentralen Encoding zum direkten Andocken im CN

Nicht-Ziele

Der Eventhub wird NICHT…

• die Zeitsteuerung/ Zeitplanung übernehmen. Jede Anstalt und Welle muss mit einem eigenen System die Daten zuliefern + abnehmen und dabei entscheiden was gerade wo on air ist. Der Eventhub wickelt keine Schaltungen/ Übernahmen ab!
• die Integration in die Systeme der Häuser bereitstellen. Der Eventhub liefert eine generische, allgemein taugliche Schnittstelle, an die man sich eigenständig andockt.
• die EPG Daten vorhalten oder verteilen. Wir machen keine doppelte Datenhaltung, diese Inhalte liegen im POC)
• den UECP Datenstrom nachbauen, generieren, oder abbilden. Da sowieso Migrationsaufwand notwendig ist, bauen wir es lieber direkt modern auf, statt den Ist-Stand nachzubauen.

Zu Klären

• Hosting im ARD CN?
• Einbezug SWR SOC (senderelevanz)?
• Detailfragen (min/max MQTT Protokollversion, QoS-Levels, Datenvalidierung, etc.)?
• Redundanz von MQTT Brokern
• Security-Testing
• Interface zur Datenkontrolle?

[MalteSPI]

Ich ergänze mal mit einer konkreten Idee für die neuen Elemente, zunächst mal für die Steuerung von u.a. TA:

de.ard.eventhub.v1.radio.control:

Beispiel TA ein:

{
"event": "de.ard.eventhub.v1.radio.control",
"time": "2026-05-27T16:03:00+01:00",
"name": "TA",
"state": true,
"services": [
{
"type": "PermanentLivestream",
"externalId": "crid://swr.de/123450",
"publisherId": "248000",
"id": "urn:ard:permanent-livestream:49267f7d67be180d"
}
]
}

Und das Schema wäre dann wie folgt:

event > If set, it needs to match the URL event parameter [de.ard.eventhub.v1.radio.control] (wie gehabt)

time* > ISO8601 compliant timestamp | Timestamp from the source that changed the state of the control element (u.a. für Logging im Empfänger. Das Feld könnte natürlich auch start heißen (und es gäbe ein end dazu), nur würde sich dann das Generieren des Elements verkomplizieren, weil man im Generator nicht immer nur Zeitstempel und Status des Elements einstanzen muss, sondern auch noch, je nach Status, start oder end einfügen muss)

name* > String | Identifier for control element [e.g. TP, TA, EON, Regio] (hier gäbe es keine Beschränkung auf bestimmte Elemente, damit künftige Steuerungsfunktionen möglich sind. Mit dem alten ZI-Schema war man an der Stelle sehr begrenzt, dass könnte der Eventhub aufheben)

state* > Boolean | New state of the control element (es wäre auch ein integer-Wert denkbar, Boolean ist aber vermutlich die saubere Variante, wenn es ohnehin nur zwei Zustände geben kann)

services* > The playing stations unique Service-IDs. Do not include the Service-Type suffix. (wie gehabt)

[MalteSPI]

Radiotext / Dynamic Label (inkl. Plus-Features)

Für diese Technologien gibt es einige Vorgaben, die berücksichtigt werden sollten oder müssen:

1. Daten müssen zyklisch wiederholt werden, Radiotext ist selten bis nie statisch
2. Vorhandene Systeme sollten möglichst wenig umformen müssen (Felder Radiotext/DL+ sollten erhalten bleiben)
3. Unterscheidung Dynamic Label zu klassischem Radiotext (Länge) muss berücksichtigt sein
4. Kein Flooding des Eventhubs mit zu vielen einzelnen Elementen
5. Möglichst einheitliche Struktur für den Empfänger (der dann rausfiltert, was genutzt werden soll)

Hier ein Vorschlag für ein entsprechendes Element (data), welches diese Annahmen zusammenbringt.

de.ard.eventhub.v1.radio.data

{
"event": "de.ard.eventhub.v1.radio.data",
"start": "2020-01-19T06:00:00+01:00",
"cycle": "8",
"data": [
{
"type": "radiotext",
"id": "0",
"value": "Sie hören die ARD Popnacht"
}
{
"type": "dynlabel",
"id": "0",
"value": "Sie hören die ARD Popnacht"
}
{
"type": "rtdlplus",
"id": "32",
"description": "PROGRAM.Stationname long",
"value": "SWR 3"
}
{
"type": "rtdlplus",
"id": "4",
"description": "Interpret",
"value": "Coldplay"
}
{
"type": "rtdlplus",
"id": "1",
"description": "Titel",
"value": "Clocks"
}
{
"type": "rtdlplus",
"id": "36",
"description": "PROGRAM.Moderator",
"value": "Ben Streubel"
}
]
},
"services": [
{
"type": "PermanentLivestream",
"externalId": "crid://swr.de/123450",
"publisherId": "248000",
"id": "urn:ard:permanent-livestream:49267f7d67be180d"
}
]
}

Das Schema sähe so aus:

event > If set, it needs to match the URL event parameter [de.ard.eventhub.v1.radio.data] (wie gehabt)

start* > ISO8601 compliant timestamp (wie gehabt)

cycle* > Int | Shows the cycle time of transmitted data in seconds (Dieser Wert gibt an, in welchen Abständen die Quelle neue Daten (also z.B. eine neue Info im Radiotext/DL) bereitstellt, damit Empfänger beurteilen können, ob sie alle Events empfangen haben.)

data* > The radio data blocks

{
type* > String | Type of transmitted data (radiotext, dynlabel, rtdlplus) (an dieser Stelle wird über die Typenbezeichnung für einen Empfänger sichtbar, welche Daten in diesem Array-Element übermittelt werden. Es braucht die Unterscheidung zwischen Radiotext und DL beim Text wegen der unterschiedlichen Längen, bei den Plus-Diensten entfällt diese Unterscheidung)

id* > Int | ID of mapping table (Um eine eindeutige Zuordnung vornehmen zu können, wird eine ID für jedes Element gesendet. Diese ist 0, wenn es sich um Radiotext / DL für die klassische einzeilige Ausgabe handelt. Bei den Plus-Diensten gibt es bereits 63 Felder, die anhand einer Mappingtabelle den IDs von 1 fortlaufend zugeordnet werden können. Für Empfänger ist dieses Routing so einheitlich und die Fehlerwahrscheinlichkeit gering, weil Zahlenwerte ausgewertet werden)

description > String | Description of data field (Dieses Feld könnte optional dazu dienen, die bereits bestehende Beschreibung der RT/DL+-Felder mit zu übergeben. Durch die ID ist allerdings bereits ein Mapping möglich. Für künftige Anpassungen könnte es aber sinnvoll sein, auch einen sprechenden Namen für ein Feld mitzusenden, entweder zu Testzwecken oder aber auch für Sonderlösungen, wenn man für eine Übertragung nicht mit den klassischen Feldern arbeiten möchte)

value* > String | Data from source (In diesem Feld werden die eigentlichen Daten übermittelt)
}

services* > The playing stations unique Service-IDs. Do not include the Service-Type suffix. (wie gehabt)

Diese Variante wäre eine Möglichkeit, wie man die Dienste Radiotext, Dynamic Label und die zugehörigen Plus-Dienste in ein Element des Eventhubs überführen könnte. Dadurch, dass im Array "data" beliebig viele Einträge übergeben werden können, lassen sich alle möglichen Kombinationen der Daten übermitteln. So ist es auch möglich, nur klassisch eine Zeile Text zu übergeben, ebenso können beliebige Daten in die Felder der Plus-Dienste geschrieben werden.
Für die Quellen braucht es für diese Form der Übermittlung nur eine weitere Ausgabe, die z.B. als MQTT die Daten an den Eventhub übergibt, parallel zum klassischen RDS oder DL-System. Die Empfangsseite kann die Events ebenfalls auf einfache Weise zerlegen (Array "data" durchlaufen) und filtern, weil man anhand der ID entscheiden kann, welche Inhalte übernommen werden sollen. So wird erreicht, dass sich der Empfang auch ähnlich wie bei den ZI-Daten verhält, wo über UECP auch immer alles übermittelt wurde und die Empfangsseite entscheiden konnte, welche Inhalte auch übernommen werden sollen.
Durch den zyklischen Versand der Events mit allen Inhalten wird auch ein Flooding des Eventhubs verhindert, weil zunächst an der Quelle gebündelt wird und nicht dauerhaft Daten übergeben werden (hier unterscheiden sich ZI-Daten dann vom Eventhub, denn diese werden kontinuierlich gesendet, enthalten aber neben TA, was ja im Eventhub anders geführt werden würde, auch eher in dem Kontext nutzlose Daten wie CT o.ä., die nur auf Grund der Quellenkonfiguration übermittelt werden. Dies entfällt im Eventhub sinnvollerweise, dennoch kann der volle Umfang an Begleitdaten angeboten werden.

[frytg]

Projektplan ist abgeschlossen und zur Abstimmung im NP.
Weitere Planung der Integration und Schemas in #824 und https://swrlab.github.io/ard-eventhub/context-rfc/eventhub-v3-connect/