Realisierung von Alarmdurchsagen im DAB-System:
Zitat aus
viewtopic.php?p=1559636#p1559636
Georg A. hat geschrieben: ↑Do 10. Sep 2020, 12:09
Als einziges DAB-Ensemble (EDIT: in München empfangbar) gabs laut Dabmon im Bundesmux beim DLF ein Announcment:
Code: Alles auswählen
Start Ende Ensemble-ID Cluster Cluster-Services Typ Announcement-Subchannel
2020-09-10 11:00:03 2020-09-10 11:20:03 10bc 0xfe Alarm 10 = Dlf (10bc/d210 )
Aber wo soll denn in den Announcement-FIGs eigentlich das ominöse "Test-Bit" sein? Oder meinen die das ASu-Feld, wo drinnen steht, ob das Announcement den Dienst unterbrechen darf?
Ich weiß jetzt, wie der im Deutschlandfunk erwähnte aber nicht im Detail beschriebene Test-Alarm im Bundesmux signalisiert worden ist. Wie man oben sieht, war die Alarmdurchsage an den Cluster-Identifier (Cluster Id oder kurz „Cluster“) „0xFE“ adressiert. Ein echter Alarm wäre an den Cluster „0xFF“ adressiert worden.
Ich werde jetzt nicht mit allen Details beschreiben wie Durchsagen im DAB-Ensemble organisiert werden. Ich gehe nur auf das ein, was für Alarmdurchsagen benötigt wird.
Ein Cluster definiert allgemein eine Gruppe von Audiodiensten, an die bestimmte Typen von Durchsagen adressiert werden können. Der Cluster „0xFF“ steht für „alle“ Audiodienste des Ensembles. Und der DAB-Standard ETSI_EN_300401 sagt, dass ausschließlich Alarmdurchsagen an diesen Cluster adressiert werden. Durch Einträge in FIG 0/18 (FIG = Fast Information Group) kann zudem jeder Service (Dienst) mit weiteren Clustern verknüpft werden, die von Durchsage-Subchannels des derzeit eingestellten Ensembles adressiert werden. Bis zu 7 solcher Cluster je Service sind möglich. FIG 0/25 liefert entsprechendes für Durchsagen in anderen Ensembles. Bis zu vier je Service sind hier möglich. Der Cluster „0xFF“ ist gemäß Vereinbarung schon mit allen Audiodiensten verknüpft und wird nicht durch FIG 0/18 oder FIG 0/25 definiert. Bei der Alarmierung kann jedoch auch der Cluster „0xFE“ eine Rolle spielen. Darauf komme ich unten zurück. Und dieser Cluster oder OE-Cluster (OE = Other Ensemble) kann durchaus durch FIG 0/18 bzw. FIG 0/25 definiert werden.
[Übrigens: Die durch FIG 0/18 und FIG 0/25 definierten Cluster-Id bzw. OE-Cluster-Id haben jeweils eigene Namensräume.]
Zum Umschalten auf eine Durchsage wird ein Signal „Announcement switching“ in FIG 0/19 gesendet. FIG 0/19 verknüpft einen Cluster mit jenem Sub-Channel, in dem die Durchsage geliefert werden soll. FIG 0/19 gilt für Durchsagen, die auf einem Sub-Channel des derzeit eingestellten Ensembles gegeben werden. Mit dem OE Announcement Switching FIG 0/26 kann auf Durchsagequellen eines anderen Ensembles hingewiesen werden.
Laut Clause 6.4.1 in EN_300401 sind Alarmdurchsagen nur gültig, wenn in der Ensemble Information FIG 0/0 das Al flag (Alarm flag, Alarm-Statusbit) gesetzt ist. Ist es nicht gesetzt, soll der Empfänger an den Cluster „0xFF“ gerichtete Durchsagen ignorieren. Meiner Ansicht nach ist zu erwarten, dass der DAB-Empfänger den Benutzer anhand des Zustands des Alarm-Statusbits darüber informiert, ob Alarmdurchsagen in dem gewählten Ensemble unterstützt werden. Aus der Zustandsbeschreibung des Bundesmux bei dabmon.de geht nicht hervor, ob dort das Alarm-Statusbit gesetzt ist. Ich meine, es müsste dauerhaft gesetzt sein. Jedenfalls musste es wenigstens zu jener Zeit gesetzt gewesen sein, als die Durchsage erfolgt ist.
Unterbunden werden darf das Umschalten zu gültigen Alarmdurchsagen nicht. Das ist weder eine Option für den Benutzer noch für einen der Anbieter im Ensemble.
Nun war bei dem Test neulich die Durchsage des DLF an den Cluster „0xFE“ und nicht „0xFF“ adressiert. Genau dies wird in der ETSI Technical Specification TS_103176 "Digital Audio Broadcasting (DAB); Rules of implementation; Service information features“ im Anhang G als Vorgehen zum Signalisieren eines Testalarms vorgeschlagen. Damit verbunden ist lediglich die Einschränkung, dass dann der Cluster „0xFE“ nicht zum Adressieren von sonstigen Durchsagen verwendet werden soll. Und diese Bedingung war wohl erfüllt. Jedenfalls ist die Spalte unter Cluster Services oben in dem Beispiel leer, das heißt es wurde kein einziger Service explizit diesem Cluster zu geordnet. Das oben erwähnte Alarm-Statusbit soll auch während des Testalarms gesetzt sein.
Normale DAB-Empfänger sollen den Testalarm nur dann auswerten, wenn sie dem Benutzer eine Option bieten, ihn zu unterdrücken.
Literatur und Zitate zu DAB-Announcements:
ETSI en_300401v020101p Radio Broadcasting Systems;
Digital Audio Broadcasting (DAB) to mobile, portable and fixed receivers
Bestimmung (clause) 6.4.1: Ensemble information
Alarm flag (Bit13) in the FIG 0/0:
Al flag (Alarm flag): this 1-bit flag shall be used to signal that the ensemble supports the provision of alarm announcements, as follows:
0: alarm announcements shall not interrupt any service;
1: alarm announcements shall interrupt all services.
Alarm announcements require careful management, since when support is enabled using the Al flag, the alarm announcements signalled with FIG 0/19 or FIG 0/26 shall interrupt all services carried in the ensemble (see clause 8.1.6).
Bestimmung (clause) 8.1.6: Announcements
Announcement Support Feature FIG 0/18
Announcement switching FIG 0/19
OE Announcement support FIG 0/25
OE Announcement switching FIG 0/26
(„OE“ = Other Ensemble)
ETSI TS_103176v020401p
Technical Specification "Digital Audio Broadcasting (DAB); Rules of implementation; Service information features“.
Kapitel 7 erläutert wie Anbieter und Empfängerhersteller die Announcementfunktion zu implementieren haben.
ETSI TS 101 756 V2.2.1 (2017-08) „Digital Audio Broadcasting (DAB); Registered Tables“
Bestimmung (Clause) 5.9: Announcement Types
In Tabelle 14 ist Bit0 für den Announcement-Typ „Alarm“ definiert. Dieses Bit wird jedoch praktisch nicht verwendet. In den Announcement-Support-Mitteilungen FIG 0/18 und FIG 0/25 soll Bit0 auf 0 gesetzt bleiben.
Anhang B hilft mit Übersetzungen der Announcement-Typen für zahlreiche Sprachen.