OE3DZW (Diskussion | Beiträge) |
OE3DZW (Diskussion | Beiträge) (fix many, many typos) |
||
| Zeile 7: | Zeile 7: | ||
===== Volle Vermaschung ===== | ===== 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. | + | 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 im Uplink bereitgestellt werden. |
===== Zentralisierte Lösung ===== | ===== Zentralisierte Lösung ===== | ||
| Zeile 15: | Zeile 15: | ||
===== Vernetzte Server ===== | ===== 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, | + | 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, die Bandbreite pro Server reduziert werden, wie auch die Ausfallssicherheit verbessert werden. Doch es entstehen auch Probleme, welche schon bei der Vermaschung auftraten. Wie wird sichergestellt, dass einheitlich gesendet wird? Ist eine volle Vermaschung zwischen den Server möglich oder wäre es besser ein Routing mit Hierarchien oder mit Routingprotokollen zu konfigurieren? Letztlich entsteht ein komplexes System, das wiederum aufgrund seiner 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 ===== | ===== 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 | + | 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 mehrerer Server. 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 ==== | ==== 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. | 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. | + | Dies kann erwünscht sein, doch die meisten heutigen Systeme für digitale Sprache sind anders aufgebaut. Nicht jeder spricht mit jedem, sondern es werden Teilmengen, oft als Gruppen bezeichnet, gebildet. |
===== Zieladressen zur Bildung von Gruppen ===== | ===== Zieladressen zur Bildung von Gruppen ===== | ||
| − | Wie im Artikel [[Digitale Sprache - Adressierung|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 | + | Wie im Artikel [[Digitale Sprache - Adressierung|Adressierung bei digitaler Sprache]] dargestellt, unterstützen alle digitale Systeme die Angabe von Zieladressen. Die Bezeichnungen der Zieladressen 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 bei den empfangenden Funkgeräten ausgewertet werden. |
| − | Doch was bedeutet hier "ausgewertet"? Am einfachsten am Funkgerät: Es entscheidet, ob die | + | Doch was bedeutet hier "ausgewertet"? Am einfachsten ist es am Funkgerät: Es entscheidet, ob die empfangenen Sprachdaten am Lautsprecher ausgegeben werden oder ob sie ignoriert werden. Der Repeater entscheidet darüber, ob die empfangene Sprachdaten am Sender ausgesendet werden und ob, ob diese Daten zu einem Server weitergeleitet werden. Der Repeater kann mitunter auch anhand der Zieladresse entscheiden, an welchen Server die Sprachdaten weitergeleitet werden. Und letztlich entscheidet der Server an welche anderen Server und an welche Repeater die Sprachdaten weitergeleitet werden. Wozu 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 in diesem Fall zwar an allen Repeatern ausgegeben, doch nur jene Funkgeräte geben die Sprache wieder, welche für diese Zieladresse konfiguriert sind, also bei allen Morse-Interessenten. |
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. | 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? ===== | ===== 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. | + | 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. Doch nach welchen Kriterien treffen diese Geräte Entscheidungen? |
====== Konventionen ====== | ====== 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. | 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. | + | Doch wie entstehen diese Konventionen? Meist dadurch, dass eine Gruppe - etwa Programmierer:innen 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 ====== | ====== 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 | + | 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 der Server funktioniert. |
====== Geht es nicht einfacher? ====== | ====== 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 mit diesem Wissen unterschiedliche Repeater nutzen. Dennoch es ist möglich, dass bestimmte TalkGroups an einem Repeater standardmäßig aktiv sind, auf anderen nicht | + | 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 mit diesem Wissen unterschiedliche Repeater nutzen. Dennoch 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 Zeitschlitze nutzen. Systeme also, die ähnlich, aber doch nicht ganz gleich funktionieren. |
====== Warum gibt es im DMR keine Modul, in Dstar aber schon? ====== | ====== Warum gibt es im DMR keine Modul, in Dstar aber schon? ====== | ||
| Zeile 50: | Zeile 50: | ||
==== Typische Vernetzungen ==== | ==== Typische Vernetzungen ==== | ||
| − | Meist sind Repeater Teil einer oder mehrere Gruppen. Sie erlauben | + | Meist sind Repeater Teil einer oder mehrere Gruppen. Sie erlauben es mitunter nur zeitweise Teil anderer Gruppen zu werden, diese Gruppe als dynamische Gruppen bezeichnet - im Gegensatz zu statischen Gruppen, welche immer vorhanden sind. Man kann sich darüberhin hinaus etwa mit einem Reflektor verbinden oder von diesem trennen. |
====== Brücken ====== | ====== 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. | + | 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. Genauso kommuniziert Dstar nur mit 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 von Technologien die Sprache von einem Codec auf einen anderen transkodiert werden. Dann muss eine Konvention gefunden werden, bei welche Adressen von Technologie A und bei welchen Adressen von 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 | + | Brücken werden auch zur Kopplung verschiedener Server-Systeme genutzt. Auch hier ist mitunter eine Konvention zu Adressen oder ein Adress-Mapping notwendig. |
==== Konkreter? ==== | ==== Konkreter? ==== | ||
Aktuelle Version vom 11. September 2023, 22:33 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 im Uplink 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, die Bandbreite pro Server reduziert werden, wie auch die Ausfallssicherheit verbessert werden. Doch es entstehen auch Probleme, welche schon bei der Vermaschung auftraten. Wie wird sichergestellt, dass einheitlich gesendet wird? Ist eine volle Vermaschung zwischen den Server möglich oder wäre es besser ein Routing mit Hierarchien oder mit Routingprotokollen zu konfigurieren? Letztlich entsteht ein komplexes System, das wiederum aufgrund seiner 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 mehrerer Server. 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. Nicht jeder spricht mit jedem, sondern es werden Teilmengen, oft als Gruppen bezeichnet, gebildet.
Zieladressen zur Bildung von Gruppen
Wie im Artikel Adressierung bei digitaler Sprache dargestellt, unterstützen alle digitale Systeme die Angabe von Zieladressen. Die Bezeichnungen der Zieladressen 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 bei den empfangenden Funkgeräten ausgewertet werden.
Doch was bedeutet hier "ausgewertet"? Am einfachsten ist es am Funkgerät: Es entscheidet, ob die empfangenen Sprachdaten am Lautsprecher ausgegeben werden oder ob sie ignoriert werden. Der Repeater entscheidet darüber, ob die empfangene Sprachdaten am Sender ausgesendet werden und ob, ob diese Daten zu einem Server weitergeleitet werden. Der Repeater kann mitunter auch anhand der Zieladresse entscheiden, an welchen Server die Sprachdaten weitergeleitet werden. Und letztlich entscheidet der Server an welche anderen Server und an welche Repeater die Sprachdaten weitergeleitet werden. Wozu 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 in diesem Fall zwar an allen Repeatern ausgegeben, doch nur jene Funkgeräte geben die Sprache wieder, welche für diese Zieladresse konfiguriert sind, also bei allen Morse-Interessenten.
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. Doch nach welchen Kriterien treffen diese Geräte Entscheidungen?
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:innen 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 der Server 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 mit diesem Wissen unterschiedliche Repeater nutzen. Dennoch 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 Zeitschlitze nutzen. Systeme also, die ähnlich, aber doch nicht ganz 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 es mitunter nur zeitweise Teil anderer Gruppen zu werden, diese Gruppe als dynamische Gruppen bezeichnet - im Gegensatz zu statischen Gruppen, welche immer vorhanden sind. Man kann sich darüberhin hinaus etwa 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. Genauso kommuniziert Dstar nur mit 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 von Technologien die Sprache von einem Codec auf einen anderen transkodiert werden. Dann muss eine Konvention gefunden werden, bei welche Adressen von Technologie A und bei welchen Adressen von 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 Konvention zu Adressen 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:
Diskussionen