D-STAR ICOM Gateway

Aus Amateurfunk Wiki

Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

D-STAR Gateway Software von ICOM

Der Reiz des D-STAR Systems liegt in der weltweiten Vernetzung der Repeater untereinander. Man bedient sich hier dem Internet als Übertragungsmedium, aber es wäre auch jedes andere IP-basierte Netzwerk möglich (siehe Abschnitt Vernetzung). Nach der Veröffentlichung des offenen Standards für D-STAR suchte die JRRL einen Hersteller, der die passenden Funkgeräte und Repeater bauen würde und hier war ICOM der einzige kommerzielle Interessent. Mittlerweile gibt es jedoch auch freie Alternativen, die am Ende dieses Artikels kurz aufgelistet werden.


Gateway Version 1

Die erste Version der Gateway Software von ICOM kam 2005 heraus. Diese Version basierte auf dem Prinzip, das es zwar einen Trust-Server gab, jedoch jeder Gateway-Rechner die Veränderungen seiner Datenbank immer an alle anderen Gateway verteilt hat. Mit der wachsenden Anzahl der Gateways wuchs damit auch der Traffic und die Zeitspanne die benötigt wurde, die jeder Gateway brauchte um jeden anderen zu erreichen. Wenn dann noch ein Gateway einen Fehler hatte, dauerte die Rundumverteilung noch länger, da je fehlendem Gateway wieder ein neuer Timeout hinzu kam. Problematisch war es auch, wenn ein Gateway einige Tage nicht online war und dann wieder ans Netz kam, war sein Datenbankbestand natürlich nicht mehr aktuell und er verteilte munter alte Informationen über längst gelöschte Daten wieder im Netz. Dies Version 1 wird nach Informationen des Verfassers heute noch in Japan eingesetzt.


Gateway Version 2

Nachdem die Version 1 in einem weltweiten Netz immer mehr Probleme verursachte, kam 2008 die Version 2 - genannt G2 - heraus. In dieser Version bekam der Trust-Server nun die Aufgabe alle Synchronisationen der Datenbanken zentral zu verwalten. Jeder Gateway sendet nun seine Veränderungen an den Trust-Server und dieser gibt diese an alle anderen weiter. Der Nachteil bei dieser Methode ist nun, das der Trust-Server zum sogenannten Single-Point-of-Failure wird. Fällt er aus, werden keine Veränderungsmeldungen der Datenbanken mehr verteilt. Trotz dieses Nachteils, kann man aber weiterhin Funkverkehr über das Netz durchführen. Solange der Trust-Server nicht wieder online ist, werden Roaming-Informationen nicht verteilt und es können keine neuen Benutzer und Terminals registriert werden.


Repeater und Gateway Aufbau

ICOM Repeater

Die ICOM Repeater, um die es in diesem Artikel geht, bestehen aus Modulen für die verschiedenen Frequenzbänder 2m, 70cm und 23cm. In diesen Modulen stecken jeweils ein Sender, ein Empfänger und eine kleine Logik zur Verbindung mit dem Repeatercontroller. Mit einem Repeatercontroller und einem Funkmodul alleine hat man einen simplen, digitaltauglichen Umsetzer, wie man sie im Amateurfunk für andere Betriebsarten bereits kennt. Ein System aus Controller und zwei Modulen ermöglicht bereits eine weitere Funktion, dem Crossband-Repeating. Dabei können Benutzer z.B. auf 70cm mit anderen Nutzern auf 23cm usw. sprechen. Wirklich interessant wird es aber erst mit der Verbindung zu einem Gateway-Rechner.


Gateway PC

Beim Gateway PC handelt es sich um einen Standardrechner mit dem Betriebssystem Linux. ICOM empfiehlt in seiner Installationsanleitung die Distribution CentOS 5, jedoch gibt es auch Installationen auf z.B. Debian basierten Systemen. Bei der Version 1 setzte ICOM noch Fedora ein, welches wie CentOS auch aus der Schmiede der Firma Redhat stammt, jedoch eigentlich für Endanwender gedacht ist. CentOS dagegen ist als Serversystem ausgelegt und wurde somit in Version 2 quasi der Standard. Der Gateway-PC benötigt zwei Netzwerkanschlüsse (1*zum Repeatercontroller und 1*zum Internet), idealerweise 2,4 GHz Takt oder mehr, 512 MB RAM und eine ausreichend große Festplatte ab 10 GB. Die Installation eines solchen Gateway ist in einem eigenen Artikel beschrieben unter D-STAR_Gateway_Installation.


Datenbank, Benutzer und Terminals

Datenbank und Tabellen

Das ICOM G2 System baut auf der freien Datenbank PostgeSQL auf, die jedermann frei nutzen darf, sei es kommerziell oder privat. In dieser Datenbank werden die verschiedenen Bereiche in extra Tabellen gespeichert, welche dann nach Bedarf mit dem Trustserver automatisch synchronisiert werden. Folgende Tabellen kommen zum Einsatz:

G2 Tabellenstruktur
Tabelle Nutzung Einträge (*)
unsync_user_mng Hier stehen alle Nutzer drin, die sich auf diesem Gatway registriert haben. 898 Nutzer
unsync_multicast_mng Lokal gespeicherte Multicast Gruppen. Diese sind nur auf dem Gateway verfügbar, auf dem sie gespeichert sind. Will man Multicastgruppen auf mehreren Gateways nutzen, muss jeder Admin sie auf seinem Gateway selbst einrichten. 0 MC-Gruppen
unsync_mng Ein Admin könnte bei bestimmten Terminals eine Blockierung setzen, welche in dieser Tabelle gespeichert werden würde. 0 geblockte
unsync_gip So wie Terminals, könnte der Admin auch Gateways blockieren und dies würde in dieser Tabelle stehen. 0 geblockte
sync_rip Jedem registriertem Nutzer wird vom Trustserver ein 8-IP-Block zugewiesen und die sind hier gespeichert. 20992 IP-Blöcke
sync_mng Legt ein Nutzer ein Terminal (s.u.) an, wird dies hier gespeichert. In diesen Terminaleinträgen wird dann auch gespeichert, wer, wann, wo zuletzt die PTT gedrückt hat, damit man ihn/sie per Callsing-Routing rufen kann. Jeder US-Trust G2 Repeater hat hier Terminals (s.u.) für die angeschlossenen Repeater. 30114 Terminals
sync_gip In dieser Tabelle stehen die öffentlichen IP-Adressen aller Gateways, damit die Software Callsign-Routing Pakete dort hin senden kann. 1114 Gateways

(*) Zahlen von DB0HRF zur zur Info, um ein ungefähres Bild von der Datenmenge zu bekommen. Stand ist Nov. 2011.

Alle Tabellen mit dem Präfix unsync bleiben lokal auf dem Rechner. Die Tabellen mit sync am Anfang werden über den Trustserver mit allen Gateways weltweit synchron gehalten. Neue Terminals werden zum Trustserver gesendet, der diese dann wieder reihum verteilt und Änderungen gehen den gleichen Weg.

Gatewaybetreiber mit Nutzerregistrierungen sollten ihre Datenbank (DB) regelmäßig sichern. Zur DB gibt es verschiedene Tools und das Backup-Script erhält man unter [1]. Dieses Script wird dann von Cron automatisch immer einmal täglich gestartet und legt die Backup-Dateien im Ordner /home/postgres ab. Diese Dateien sollten dann aber auf eine externe Festplatte, oder über das Netzwerk auf einen anderen Computer gesichert werden. Bei DB0HRF zum Beispiel, werden diese Dateien per SCP auf dem Gateway von DB0WK gesichert. Mit den Werten aus der Tabelle oben als Beispiel, haben die Backups eine Größe von rund 2MB als Tar-GZip Archiv.


Benutzer Registrierungen

Um Callsign-Routing nutzen zu können, also das man selbst andere gezielt mit Rufzeichen erreichen kann und das man selbst erreicht werden kann, muss man sich im US-Trust-Netz einmalig auf einem Gateway anmelden und wenn man freigeschaltet ist, ein Standard-Terminal anlegen, ohne das kein Routing möglich ist.

Zum Registrieren und Terminal anlegen eignet sich prinzipiell jeder Gateway im US-Trust-Netz, jedoch bieten nicht alle Betreiber dieses an, sondern verweisen im günstigsten Fall auf einen Gateway in der Region, auf dem man sich anmelden kann. Bei unseren Funkfreunden in den USA ist es sogar so geregelt, das man sich nur auf einem Gateway in seiner Region anmelden kann. Bei uns in Europa gibt es eine solche strickte Regelung nicht, aber die Empfehlung einen Gateway in der Nähe zu wählen, gilt auch bei uns.

Was passiert wenn ein Gateway abgebaut wurde, oder vom US-Trust abgetrennt wurde vom Betreiber?

Das ist leider schon bei einigen Nutzern zum Problem geworden, denn an diesen Registrierungen und den gespeicherten Terminals kann der Besitzer der Rufzeichens nichts mehr ändern. In einigen Fällen ist eine "Reparatur" solcher alten Einträge aber bereits gelungen. Bei Problemen kann man sich hier z.B. an den Betreiber von DB0MYK oder an die Betreiber von DB0HRF wenden.

Besser wäre es, wenn Gatewaybetreiber mit Nutzerregistrierungen regelmäßig Backups machen, um im Fehlerfall den Gateway wieder auf den alten Stand bringen zu können. Und wenn ein solcher Gatewaybetreiber seinen Gateway aus dem US-Trust nehmen will, dann sollte er vorher alle seine Nutzer informieren, dann die Einträge alle sauber aus seiner DB löschen und die Nutzer müssen sich dann auf einem anderen Gateway selbst neu registrieren.

Will ein Benutzer seine Registrierung auf einen anderen Gateway übertragen, geht das auch nur durch löschen und neu registrieren. Zuerst werden die Terminals gelöscht vom Nutzer selbst oder dem Gatewaybetreiber und danach der Nutzereintrag vom Betreiber. Ein Nutzer kann seine Registrierung nicht selbst löschen.


Terminal und Routing

(Geht bald weiter hier) --Dh9fax 01:29, 16. Nov. 2011 (CET)


Allgemeine Hinweise

(Geht bald weiter hier) --Dh9fax 01:29, 16. Nov. 2011 (CET)

Persönliche Werkzeuge