OE3DZW (Diskussion | Beiträge) |
OE3DZW (Diskussion | Beiträge) Markierung: 2017-Quelltext-Bearbeitung |
||
Zeile 60: | Zeile 60: | ||
Die Anleitung ist bewusst abstrakt gehalten um die dahinterstehenden Prinzipien zu erklären. Die konkrete Anleitung findet sich bei den jeweiligen Vernetzungssystemen wie IPSC2 oder XLX232. | Die Anleitung ist bewusst abstrakt gehalten um die dahinterstehenden Prinzipien zu erklären. Die konkrete Anleitung findet sich bei den jeweiligen Vernetzungssystemen wie IPSC2 oder XLX232. | ||
+ | Konkrete Informationen für die jeweilige Technologie findet sich in folgenden Artikeln: | ||
+ | * [[Adressierung bei DMR]], | ||
+ | * [[Adressierung bei Dstar]], | ||
+ | * [[Adressierung bei C4FM]] und | ||
+ | * [[Adressierung bei Tetra]] | ||
[[Category:Digitale Sprache]] | [[Category:Digitale Sprache]] |
Version vom 9. September 2023, 19:56 Uhr
Dieser Artikel beschreibt die Grundlagen der Vernetzung digitaler Systeme.
Er setzt allgemeines Verständnis der Adressierung bei digitaler Sprache voraus.
Grundidee der Repeatervernetzung
Jeder Repeater deckt nur eine bestimmtest Gebiet ab, möchte man dieses Gebiet erweitern oder unterschiedliche Gebiete erreichen, so ist eine Zusammenschaltung zwischen den Repeatern notwendig.
Volle Vermaschung
Die einfachste Form der Zusammenschaltung ist die direkte Zusammenschaltung der Repeater. Doch erfordert dies eine Verbindung von jedem Repeater zu jedem Repeater. Das ist in digitaler Form grundsätzlich möglich, doch wird die Wartung schnell kompliziert, etwa wenn ein zusätzlicher Repeater hinzukommt. In diesem Fall muss der zusätzliche Repeater bei allen bisherigen Repeatern eingetragen werden. Aber auch die Steuerung wird schnell kompliziert, etwa, wenn an zwei Repeatern gleichzeitig empfangen wird - wie wird sichergestellt, dass alle Repeater im Verbund idente Aussendungen machen? Ein weiteres praktisches Problem: Der jeweils empfangende Repeater muss seine Sprachdaten an alle vermaschten Repeater senden, bei vielen beteiligten Repeatern entstehen dabei hohe Bandbreiten. Diese müssen bei jedem Repeater bereitgestellt werden.
Zentralisierte Lösung
Alternativ dazu bietet es sich an, einen Server zu definieren mit dem alle Repeater verbunden sind. Auf allen Repeatern braucht lediglich ein Server eingetragen werden, der Server hat Überblick über die Situation auf allen Repeatern, stellt damit einheitliche Aussendungen sicher und eine Erweiterung bedarf nur der Konfiguration am neuen Repeater und einer zusätzlichen Eintragung am Server. Doch auch diese Lösung hat nicht nur Vorteile. Während bei einer vollen Vermaschung der Ausfall eines einzelnen Repeaters nur diesen betrifft, so hat ein Ausfall des Servers den Ausfall der gesamten Vernetzung zur Folge. Für hohe Betriebssicherheit ist damit Redundanz notwendig.
Mitunter kann auch diese Lösung ein Bandbreitenproblem bekommen, und zwar dann, wenn viele Repeater vernetzt werden. Zum Bandbreitenproblem kommt noch ein Latenzproblem. Auch wenn die Gesprächspartner benachbarte Repeater nutzen, wenn der Server in einem anderen Kontinent steht, dann verursacht die Übertragung zum Server merkliche Verzögerungen von mehreren 100ms.
Vernetzte Server
Wenn kein Server nicht optimal ist, ein Server auch nicht, könnte eine Vernetzung von mehreren Server eine Lösung sein? Ja, aber. Durch mehrere regionale Server, welche ggf. auch gegenseitig redundant sind, kann sowohl die Latenz, wie auch die Bandbreite pro Server reduziert werden, wie auch die Ausfallssicherheit verbessert werden. Doch es entstehen auch Probleme welche schon bei der vollen Vermaschung auftraten. Wie wird sichergestellt, dass einheitlich gesendet wird? Ist eine volle Vermaschung zwischen den Server möglich oder wäre es besser eine Routing mit Hierarchien oder mit Routingprotokollen zu konfigurieren. Letztlich entsteht ein komplexes System das nun wiederum aufgrund der Komplexität Probleme bereiten kann. Aber die Vernetzung von Servern hat einen anderen strategischen Vorteil: Nicht alle Beteiligten müssen sich auf genau eine Lösung einigen, es reicht aus, wenn die Schnittstellen zwischen den Netzen abgestimmt werden. Somit wird auch Innovation ermöglicht.
Reale Lösungen
In der Amateurfunkpraxis wird eine serverlose Lösung wenn überhaupt, fast nur bei der direkten Verbindung von ganz wenigen Repeatern, meist zwei Repeatern verwendet. Eine regionale ServerLösung ist der Standardfall, von außen betrachtet handelt es sich dabei oft um eine Vernetzung von Servern. Doch diese Server werden meist nicht von einer einzelnen Gruppe kontrolliert, sondern unterschiedliche Betreiber von Servern einigen sich auf ein Mindestmaß um Interoperabilität zu gewährleisten.
Mehr als nur ein Verbund
In der bisherigen Beschreibung wurde davon ausgegangen, dass eine Aussendung einer Funkamateur:in von allen anderen Amateur:innen des lokalen Repeaters gehört wird und auch auf allen zusammengeschalteten Repeatern weiterverbreitet wird. Eine solche Konfiguration hat den Vorteil, dass keinerlei Steuerung oder Konfiguration bei den Geräten notwendig ist. Alle Geräte senden an alle, alle Geräte empfangen alles.
Dies kann erwünscht sein, doch die meisten heutigen Systeme für digitale Sprache sind anders aufgebaut.
Zieladressen zur Bildung von Gruppen
Wie im Artikel Adressierung bei digitaler Sprache dargestellt, unterstützen alle digitale Systeme die Angabe von Zieladressen. Die Bezeichnungen variieren, etwa Talkgroup bei DMR. Doch um die Details geht es an dieser Stelle gar nicht. Entscheidend ist, dass die Amateur:in die Möglichkeit hat, im Funkgerät eine bestimmte Zieldresse zu konfigurieren. Der Repeater - oder der dahinterliegende Server - wertet die Zieladresse aus. Ebenso kann die Zieladresse beim Empfang in den anderen Funkgeräten ausgewertet werden.
Doch was bedeutet hier "ausgewertet"? Am einfachsten am Funkgerät: Es entscheidet, ob die empfangene Sprache am Lautsprecher ausgegeben wird oder ob sie ignoriert wird. Der Repeater entscheidet darüber, ob die empfangene Sprache auf der Ausgabe ausgegeben wird und ob, ob diese Sprache zu einem Server weitergeleitet wird. Der Repeater mitunter auch anhand der Zieladresse entscheiden, an welchen Server die Sprache weitergeleitet wird. Und letztlich entscheidet der Server an welche anderen Server und an welche Repeater die Sprache weitergeleitet wird. Wozu also diese vielen Entscheidungen? Die Zieladresse kann eine bestimmte geografische Region stehen. Der Server leitet an alle Repeater in der Region weiter. Oder die Zieladresse kann für eine bestimmtes Interesse - etwa für Morsen - stehen. Die Sprache wird zwar an allen Repeatern ausgegeben, doch nur jene Funkgeräte geben die Sprache wieder, welche für diese Zieladresse konfiguriert sind, also bei allen Interessenten von Morsen.
Dstar nennt die letztere Form der Adresse Modul. In Anleitungen wird Modul oft mit dem Wort "Raum" beschrieben, ähnlich den Räumen von manchen Chat-Systemen.
Was muss ich nun tun, um in Region X gehört zu werden?
Die Antwort ist leider nicht so einfach, auch nicht bezogen auf eine bestimmtes Übertragungsverfahren. Es ist ein Zusammenwirken von Geräten, Repeatern und Servern. Im Gerät wird eingestellt, welche Adressen bei der Aussendung übermittelt werden. Doch was Repeater und Server aus diesen Informationen machen ist deren Entscheidung.
Konventionen
Am Anfang stehen Konventionen, also Festlegungen, die auch anders getroffen werden hätten können. Die Talkgroup A steht für die Region B. Das Modul C steht für das Thema D. Der Reflektor E steht für die Sprache F. Diese Konventionen werden in Anleitungen kommuniziert, in Gerätekonfigurationen (sogenannten Codeplug) implementiert, die Steuerungen der Repeater und Server sorgen dafür, dass tatsächlich die Aussendung in der richtigen Region ankommt, dass am Thema oder an der Sprache interessierte Amateur:innen die Aussendung hören.
Doch wie entstehen diese Konventionen? Meist dadurch, dass eine Gruppe - etwa Programmierer einer Serversteuerung oder Betreiber eines Repeaters - einen Vorschlag machen, die Konvention aufstellen und diese dann von der Mehrheit der Amateur:innen akzeptiert wird. Dementsprechend ändern sich die Konventionen auch laufend, eine Dstar-Anleitung aus dem Jahr 2015 ist heute nur mehr sehr eingeschränkt brauchbar.
Wissen um die Rahmenbedingungen
Aus all dem ergibt sich auch: Das Wissen um die Technologie für digitale Sprache - etwa DMR - reicht nicht. Man muss wissen, wie der Repeater konfiguriert ist, man muss wissen, wie der Repeater vernetzt ist, man muss wissen, wie die Steuerung des Servers funktioniert.
Geht es nicht einfacher?
Doch, es ist in Wirklichkeit etwas einfacher. Nicht jeder Repeater hat seine eigene Konfiguration, nicht jede Serversteuerung funktioniert grundlegend anders. Beispielsweise nutzen viele DMR-Repeater in Österreich die Vernetzung von IPSC2, also eine bestimmte Steuerung des Servers. Kennt man diese, dann kann man unterschiedliche Repeater nutzen. Aber es ist möglich, dass bestimmte TalkGroups an einem Repeater standardmäßig aktiv sind, auf anderen nicht. Es also trotzdem Unterschiede gibt. Und es gibt auch andere Repeater-Steuerungen welche andere Konventionen bezüglich Zeitschlitzen nutzen. Systeme also, die ähnlich, aber nicht gleich funktionieren.
Warum gibt es im DMR keine Modul, in Dstar aber schon?
Die verschiedenen Technologien für digitale Sprache arbeiten mit unterschiedlichen Adressen. Die Adressen haben unterschiedliche Namen, bei der einen Technologie gibt es mehr, bei der anderen weniger Adressen. Mehr bedeutet mehr Flexiblität, aber auch mehr Komplexität und mehr Fehlermöglichkeiten. Mitunter reichen ganz wenige Adressierungsmöglichkeiten aus, um eine sinnvolle Nutzung zu ermöglichen.
Typische Vernetzungen
Meist sind Repeater Teil einer oder mehrere Gruppen. Sie erlauben oft dynamisch Teil anderer Gruppen zu werden. Man kann sich also mit einem Reflektor verbinden oder von diesem trennen.
Brücken
Die verschiedenen Technologien für digitale Sprache bilden grundsätzlich digitale Inseln. Es wird also von einem DMR-Gerät zu einem anderen DMR-Gerät kommuniziert. Dstart kommuniziert Dstar. Doch letztlich wird in allen Fällen digitale Sprache übertragen. Es liegt also Nahe zu versuchen die Systeme an den Servern zu verknüpfen, also beispielsweise Kommunikation zwischen DMR und Dstar zu ermöglichen. Dabei sind jedoch Hürden zu überwinden. Zuerst muss je nach Kombination die Sprache von einem Codec auf einen anderen Transkodiert werden. Dann muss eine Konvention gefunden werden, bei welche Adressen bei Technologie A und bei welchen Adressen bei Technologie B eine Zusammenschaltung erfolgt. Und letztlich müssen auch die Quell-Adressen, also zB DMR-ID (DMR) auf MYCALL (Dstar) umgesetzt werden. Server-Software, welche eine solche Zusammenschaltung bewerkstelligt wird als Brücke bezeichnet.
Brücken werden auch zur Kopplung verschiedener Server-Systeme genutzt. Auch hier ist mitunter eine Adress-Konvention oder ein Adress-Mapping notwendig.
Konkreter?
Die Anleitung ist bewusst abstrakt gehalten um die dahinterstehenden Prinzipien zu erklären. Die konkrete Anleitung findet sich bei den jeweiligen Vernetzungssystemen wie IPSC2 oder XLX232.
Konkrete Informationen für die jeweilige Technologie findet sich in folgenden Artikeln: