Technik

Diese Seite ist unseren Mitgliedern vorbehalten. Sofern Sie ein Mitglied sind, melden Sie sich bitte an und laden diese Seite dann erneut. Wenn Sie noch kein Mitglied sind, können Sie hier Mitglied werden.

MoWaS - Warnmeldungen

Das Bundesamt für Bevölkerungsschutz und Katastrophenhilfe (BBK) betreibt für die Bundesrepublik Deutschland das sog. modulare Warnsystem (MoWaS). An diesem Warnsystem sind die Länder und Kreise in der Bundesrepublik angeschlossen und können Warnmeldungen an die Bevölkerung veröffentlichen. Diese Meldungen werden danach mit möglichst wenig Zeitversatz über sogenannte Warnmultiplikatoren an die Bevölkerung verteilt. Die bekanntesten Wege zur Verteilung von Warnungen sind:

Sirenen
Cell-Broadcast
NINA-App
Lautsprecherdurchsagen der Feuerwehr
Radio und Fernsehen

Durch eine vertragliche Vereinbarung mit dem BBK wird auch der DARC e. V. in die Möglichkeit versetzt, die Warnmeldungen im Rohformat zu empfangen und zeitnah über die Wege der Funkamateure zu verteilen. Hierzu wird durch das Referat für Not- und Katastrophenfunk im DARC e. V. eine Infrastruktur betrieben, die eingehende Meldungen via Hamnet und auch via Internet z. B. an Relais verteilen kann. Hierdurch können z. B. Relaisbetreiber eingehende Meldungen automatisiert auf einem Relais ausgeben und so die mithörenden Funkamateure mit den aktuellen Warnmeldungen informieren. Weitere Möglichkeiten sind z. B. die Darstellung auf einer Karte im Hamnet oder die Verteilung z. B. via DAPNET oder in einem DMR-Netz.

Ablauf

Das gesamte System läuft vollautomatisch, da Warnmeldungen im Regelfall sehr zeitnah zugestellt werden müssen. Daher ist auch nur die vollautomatische Verteilung auf automatisch arbeitenden Stationen und ähnlichen Wegen vorgesehen. Eine Verbreitung durch einzelne Funkamateure, die die Meldungen dann z. B. per Sprache oder CW verteilen, ist nicht vorgesehen. Auf diesem Wege wäre keine zeitnahe Verteilung zu erreichen.

Der entwickelte Prozess gliedert sich in mehrere Schritte, wobei unterschieden werden muss zwischen Schritten, welche automatisiert auf Seite des Referats ablaufen und den Schritten, welche auf Seite der Verteilerstation stattfinden. Wir haben diese daher entsprechend markiert:

(Referat) Entgegennahme einer neuen Warnmeldung
(Referat) Verarbeitung der Warnmeldung
- Analysieren der Meldung
- Erstellen eines Kurztextes
- Erstellen einer Audio-Datei (WAV-Format) mit dem Kurztext
(Referat) Übertragen der Meldung auf die Systeme im Hamnet und Internet, welche die Meldungen verteilen
(Station) Empfang einer Benachrichtigung (via Hamnet oder Internet), dass eine neue Meldung vorliegt
(Station) Auswerten der Benachrichtigung
- ggf. Download der Audio-Datei
(Station) Verteilen der Meldung auf dem vorher definierten Weg

Mitmachen

Voraussetzung ist natürlich eine automatisch arbeitende Station oder ein anderweitiges Projekt, über das du die Warnmeldungen verteilen möchtest. Da der Vertrag zwischen dem BBK und dem DARC e. V. geschlossen wurde, musst du natürlich auch Mitglied im DARC e. V. sein, um Zugriff auf die Rohdaten der Meldungen zu erhalten. Des Weiteren muss deine automatisch arbeitende Station oder dein Projekt über das Internet oder Hamnet erreichbar sein, damit die Meldungen automatisch zugestellt werden können.

Damit eine Warnmeldung automatisiert versendet werden kann, musst du dir als erstes Gedanken darüber machen, auf welchem Wege du die Meldung an die Nutzer verteilen möchtest. Die einfachsten Wege sind hier sicherlich eine automatisierte Durchsage z. B. auf einem Relais oder die Verteilung als Textmeldung z. B. via DAPNET.

Nachdem du dies beschlossen hast, musst du dir überlegen, für welche Bereiche du alles Meldungen verteilen möchtest. Alle Warnmeldungen des BBK haben einen Regionalbezug und sind daher mit einem Regionalschlüssel kodiert. Die Regionalschlüssel sind alle nach demselben Muster aufgebaut und haben immer 12 Stellen. Eine Erklärung zum Regionalschlüssel findet sich z. B. in der Wikipedia. Auf der Karte von OpenGovTech kann man sich den Regionalschlüssel für die gewünschten Meldungsbereich heraussuchen. Ggf. ist dieser rechtsseitig noch mit der Ziffer 0 aufzufüllen, damit der Regionalschlüssel zwölf Ziffern lang ist. Sollte eine Station für mehrere Regionalschlüssel die Meldungen verteilen, die sich NICHT über einen übergeordneten Regionalschlüssel zusammenfassen lassen (z. B. mehrere Bundesländer) so muss diese Station sich für jeden Regionalschlüssel einmal registrieren. Eine Registrierung mit dem Regionalschlüssel 000000000000 (Deutschland) ist nicht empfehlenswert, da die Meldungen durch das BBK oftmals erst ab Ebene der Bundesländer geschlüsselt werden.

In einem weiteren Schritt muss entschieden werden, wie die Meldungen die Station erreichen. Hierzu werden verschiedene Wege angeboten, wobei die Wege über das Hamnet allesamt unverschlüsselt laufen, während die Wege über das Internet verschlüsselt laufen.

HTTP/HTTPS-POST … hierbei wird eine Benachrichtigung (Format siehe weiter unten) über einen HTTP-POST Request an die Station übermittelt. Die Station muss hierfür einen Webserver laufen haben, welcher die Benachrichtigung entgegennimmt und verarbeitet.
FTP-PUSH … hierbei wird eine Benachrichtigung (Format siehe weiter unten) über eine FTP-Verbindung an die Station übermittelt. Die Station muss hierfür einen FTP-Server laufen haben, welcher die Benachrichtigung entgegennimmt und die weitere Verarbeitung anstößt.
SFTP-PUSH … hierbei wird eine Benachrichtigung (Format siehe weiter unten) über eine sichere FTP (sFTP nicht FTPS!)-Verbindung an die Station übermittelt. Die Station muss hierfür einen SSH- oder SFTP-Server laufen haben, welcher die Benachrichtigung entgegennimmt und die weitere Verarbeitung anstößt.

Ab dem Zeitpunkt eurer Registrierung (siehe nächster Abschnitt) erhaltet ihr automatisiert die Benachrichtigung über neue Warnmeldungen für euren Bereich. Diese Benachrichtigung muss ein Script von euch verarbeiten und dann z. B. ein Audio File von uns herunterladen und abspielen oder einen der vorgefertigten Texte versenden.

Wenn auf Seite der Station alle Voraussetzungen geschaffen wurden, dann kann die Station unter https://mowas.notfunk.radio registriert werden. Dort müssen alle Angaben gemacht werden, damit die Benachrichtigungen zugestellt werden können. Auf der Abschlussseite könnt ihr euch selbst eine Testmeldung zusenden, um die Implementation an der Station zu testen.

Benachrichtigungsformat

JSON Objekt der DARC-MoWaS-Benachrichtigung

Egal auf welchem der weiter oben beschriebenen Wege eine Benachrichtigung versendet wird, diese ist immer im JSON-Format und enthält mindestens das im Bild gezeigte Format. Die Felder sind wie folgt gefüllt:

id ⇒ Die vom MoWaS System vergebene ID der Warnung
date ⇒ Das Datum inklusive Uhrzeit und Zeitzone der Warnung
title ⇒ Der Kurztext der Warnmeldung
target ⇒ Ein Array aus Regionalschlüsseln, für welche diese Meldung bestimmt ist
url ⇒ Ein Objekt mit den URI für weitere Informationen
- audio ⇒ Ein Objekt, bestehend aus dem Array "internet" und dem Array "hamnet" in welchem die URI angegeben sind, über die ein Audiofile mit der Warnmeldung bereitgestellt wird. Dieses wird automatisch aus dem Titeltext erstellt und kann unter EINER der angegeben URI heruntergeladen werden. Die URI werden vom System in zufälliger Reihenfolge ausgeliefert, um eine Lastverteilung zu ermöglichen.
- xml ⇒ Ein Objekt, bestehend aus dem Array "internet" und dem Array "hamnet" in welchem die URI angegeben sind, über die das originale XML File im CAP-Format mit der Warnmeldung bereitgestellt wird. Die URI werden vom System in zufälliger Reihenfolge ausgeliefert, um eine Lastverteilung zu ermöglichen.

Die Datei kann weitere Felder enthalten, wenn dies z. B. für einzelne Dienste notwendig erscheint.

Referenzimplementierungen

Solltest du die Verarbeitung der DARC-MoWaS-Meldungen bereits für eine bestimmte Software geleistet haben, so teile uns dies doch bitte mit. Dann können wir diese hier aufführen und andere müssen das Rad nicht neu erfinden.

Regeln

Ganz ohne Regeln geht es leider nicht, insbesondere da der Vertrag mit dem BBK an einigen Ecken sehr klare Vorgaben macht. Wenn es daher die Notwendigkeit gibt, dass Texte angepasst oder modifiziert werden, so klärt das Bitte VORAB mit dem Referat für Not- und Katastrophenfunk des DARC e. V. ab. Wir schauen dann, ob und wie wir dies für euch realisieren können, damit wir hier nicht vertragsbrüchig werden.

Daher müssen wir uns bedauerlicherweise auch vorbehalten, eventuell Stationen vom Empfang auszuschließen, sofern diese sich über Regeln hinweg setzen.

AREDN (Amateur Radio Emergency Data Network)

AREDN Grundlagen

Eine Einführung von Timm Schunck, DL4FLY

Vorwort

In einem typischen Notfunk-Szenario übergibt der Absender eine Nachricht an einen Funkamateur der diese in einem Radiogramm aufnimmt. Die Nachricht wird dann über VHF/UHF oder Kurzwelle via Sprechfunk übertragen. Teilweise wird das handschriftliche Formular ein weiteres Mal abgeschrieben und per Email (Pactor/Packet) weitergeleitet. Das Formular gelangt dann zum Empfänger. Im schlechtesten Fall muss die per Email versendete Nachricht nochmals abgeschrieben werden damit sie ausgehändigt werden kann.

Dieses Vorgehen entspricht nicht den Erwartungen der behördlichen Anwender. Diese erwarten eine kontinuierliche Weiternutzung der für sie gewohnten Medien, namentlich E-Mail, Telefon und ähnliche Web-basierten Werkzeuge, abhängig ihrer Funktion in der Organisation.

Doch was ist AREDN? (sprich: Arden)

AREDN ist ein vermeshtes Funknetzwerk welches in den Amateurfunkbändern betrieben wird. Es ist ein Hochgeschwindigkeits-Netzwerk mit Datenraten bis zu 54 Mbps, entwickelt, um ein TCP/IP Medium bereitzustellen wenn andere Netzwerk-Infrastruktur bereits ausgefallen ist. Obwohl es technisch möglich ist, ist es nicht als Alternative zu einem konventionellen Internetzugang gedacht.

AREDN wurde vom AREDN-Entwicklungsteam als Weiterentwicklung der preisgekrönten BBHN Firmware (Broadband Hamnet) für LINUX-basierte WIFI und WISP (Wireless Internet Service Provider) Geräte geschrieben. AREDN wurde Anfang August 2018 von der ARRL dafür ausgezeichnet. AREDN ersetzt die Herstellerfirmware der Geräte mit folgenden Hauptkomponenten:

1. OpenWRT, ein OpenSource wireless Routing Framework auf dem eigene Entwicklungen aufgesetzt werden können

2. OLSR (Optimized Link State Routing Protocol), ein IP Routing Protokoll, optimiert für dynamische Ad-Hoc Netzwerke

3. Web-basierte Oberfläche zur Konfiguration

4. Automatische gerätespezifische TCP/IP Konfiguration basierend auf der MAC Adresse des Gerätes.

Das primäre Ziel des Projektes ist es, Funkamateure zu aktivieren ein Teil des Netzwerkes zu werden, Firmware auf den Geräten zu installieren und zu nutzen.

Das zweite Ziel des Projektes ist es Standards und Services für den Notfunkeinsatz dieser Technologie zu entwickeln. AREDN ermöglicht so einen hohen Datendurchsatz verbunden mit einfachem Aufbau einer Standard TCP/IP Struktur. Daher verhält sich AREDN wie ein lokales, drahtgebundenes Heimnetzwerk. Somit sind gängige Services wie Telefonie, E-Mail, Webserver, Kameras, Chat, etc. einfach umzusetzen.

Unterschied zum stationären Hamnet

Klassisches Hamnet: Routen werden geplant, jeder Link auf einer anderen Frequenz, zentrale Vergabe von IP-Adressen ist erforderlich. Beim Installieren muss darauf geachtet werden, welches Endgerät als Accesspoint und welches als Station arbeiten soll.

Bei ARDEN arbeiten alle Knoten auf der gleichen Frequenz. Nur bei mehreren Link-Routern an einem Standort kann es erforderlich sein, einzelne Punkt-zu-Punkt Strecken auf eine andere Frequenz zu legen

Vorteil: Jeder sieht jeden.

Weiterhin ist das Netzwerk als Ad-Hoc Netzwerk ausgelegt, das bedeutet, jeder kann sich mit jedem verbinden. Eine ausgeklügelte Logik im OLSR findet Verbindungen zwischen verschiedenen Nodes und bewertet die Qualität der Verbindung („Cost of Link“). Werden Pakete übertragen wird der jeweils "günstigste" Weg gewählt. Fällt ein Streckenteil aus, so wird eine Alternative geroutet.

Das bedeutet für den Einsatz im Notfunk: Schneller Aufbau auf einer Standardfrequenz, Set and Forget. Einstecken, hinstellen, der Rest erfolgt automatisch. Werden an einem Knoten Services wie z.B. VoIP-Telefonie oder ein Webserver/Emailserver betrieben, so werden diese Dienste im Netz automatisch bekannt gegeben und sind ab sofort netzweit erreichbar. Auch sind so Ringstrukturen und Querverbindungen einfach realisierbar.

Das wäre mit klassischer Technik nur sehr aufwändig umzusetzen. Beispielsweise genügt die Sekundärstrahlung eines Nodes um einen zweiten, auch 50m entfernt, zu verbinden, obwohl beide Spiegel von einander weg zu anderen Gegenstellen zeigen.