Link 16 zu Link 22 Gateway: Nachrichtenübersetzung und -weiterleitung

Ein koalitionäres Luft- und Seebild wird selten über einen einzigen Link übertragen. Kampfjet- und Luftverteidigungsteilnehmer teilen ihre Tracks über Link 16; maritime Einsatzverbände und Überhorizontteilnehmer tun dies zunehmend über Link 22. Sobald beide Gemeinschaften einander sehen müssen, muss etwas zwischen den beiden Netzen sitzen und Tracks übertragen – eine J-Series-Nachricht auf einem Link empfangen, sie für den anderen neu formulieren und erneut übertragen, sodass ein auf einer Seite gemeldeter Kontakt korrekt auf beiden erscheint. Dieses Etwas ist ein Link 16/Link 22 Gateway, und dessen Übersetzungs- und Weiterleitungslogik korrekt zu gestalten ist eines der anspruchsvollsten Probleme der taktischen Datenfunk-Integration. Dieser Artikel erläutert, wie das Gateway beiden Netzen beitritt, wie es zwischen den beiden J-Series-Umgebungen übersetzt und wie es Tracks weiterleitet, ohne sie zu duplizieren, in Schleifen zu führen oder still zu verlieren.

Warum ein Gateway überhaupt benötigt wird

Link 16 und Link 22 sind keine konkurrierenden Standards, sondern vielmehr komplementäre, und der Vergleich zwischen ihnen wird im Artikel über Link 22 versus Link 16 ausführlich behandelt. Link 16 ist das Arbeitspferd mit hohem Tempo und Sichtverbindung für das Luftlagebild: eine präzise getaktete TDMA-Struktur auf JTIDS/MIDS-Terminals im 960–1215 MHz Band, die alle wenigen Sekunden Track-Updates an schnell bewegliche Teilnehmer liefert. Link 22 wurde als moderner Überhorizont-Nachfolger des älteren Link 11 konzipiert und organisiert Terminals in einem Super Network über HF- und UHF-Medien mit dynamischem Medienzugriff – gut geeignet für verteilte Seestreitkräfte und Überhorizontreichweite.

Da die beiden Links unterschiedliche Reichweiten, Medien und Plattformpopulationen bedienen, werden in echten Operationen häufig beide gleichzeitig betrieben. Ein Luftverteidigungsschiff im Link 16 Luftlagebild und eine Fregatte, die über Link 22 meldet, gehören zur selben Streitmacht, und ihre Kommandeure benötigen ein einziges kohärentes Lagebild. Das Gateway ist der Knoten, der dies ermöglicht: Es ist gleichzeitig eine Einheit in beiden Netzen, und seine einzige Aufgabe ist es, die beiden Lagebilder konsistent zu halten, indem es die Tracks übersetzt und weiterleitet, die jede Seite sonst nicht hören kann.

Die gemeinsame Grundlage: J-Series-Nachrichten

Der Grund, warum Cross-Link-Übersetzung überhaupt handhabbar ist, liegt darin, dass sowohl Link 16 als auch Link 22 dieselbe Nachrichtenfamilie übertragen – den J-Series-Katalog, der in der MIL-STD-6016-Normenfamilie definiert ist. Ein J2-Series-Lufttrack auf Link 16 und ein J2-Series-Lufttrack auf Link 22 beschreiben dieselbe konzeptuelle Entität mit denselben konzeptuellen Feldern: Position, Geschwindigkeit, Höhe, Identität, IFF und Track-Nummer. Die Übersetzung ist daher größtenteils eine Neuzuordnung statt einer vollständigen Neuformatierung, was eine bedeutende Vereinfachung gegenüber der Überbrückung zweier grundlegend verschiedener Nachrichtenfamilien darstellt.

„Größtenteils eine Neuzuordnung" bedeutet jedoch nicht „trivial identisch". Die beiden Link-Umgebungen unterscheiden sich in drei Schichten, die das Gateway in Einklang bringen muss. Erstens ist die Rahmungs- und Medienzugriffsschicht völlig unterschiedlich – feste TDMA-Zeitschlitze bei Link 16 gegenüber dynamischem Super-Network-Medienzugriff bei Link 22 – sodass das Gateway physisch neu überträgt und niemals nur Bits weiterleitet. Zweitens unterscheiden sich einige Feldkodierungen, Auflösungen oder Einheitenkonventionen zwischen den Link 16 und Link 22 Definitionen ansonsten äquivalenter Nachrichten, und diese Felder müssen neu verpackt, nicht kopiert werden. Drittens ist die Netzverwaltungsnachrichtenübermittlung – die Nachrichten, die Beteiligung, Timing und Meldeverantwortung regeln – linkspezifisch, sodass das Gateway den Verwaltungsdialekt jeder Seite nativ sprechen muss.

Was übernommen wird und was neu verpackt werden muss

Die hochwertigen Nutzlastfelder – Breiten- und Längengrad, Höhe, Kurs, Geschwindigkeit, Identität und IFF-Daten – werden im Regelfall sauber übernommen, da sie physikalische Realität beschreiben, die sich nicht mit dem übertragenden Link ändert. Die Felder, die Aufmerksamkeit erfordern, sind die linkrelatierten: Track-Nummer (pro Netz vergeben, in einem netzspezifischen Nummernraum), Meldeverantwortung (welche Einheit den Track in diesem Netz „besitzt") und Track-Qualitäts- oder Konfidenzindikatoren (die die nachgelagerte Fusion zur Gewichtung des Tracks verwendet). Diese können nicht wortwörtlich kopiert werden; sie müssen für das Zielnetz neu abgeleitet werden, was genau der Entstehungsort der meisten Weiterleitungsfehler ist.

Beiden Netzen beitreten und Zeit ausrichten

Bevor ein einziger Track weitergeleitet werden kann, muss das Gateway ein gesunder Teilnehmer in beiden Netzen sein. Auf der Link 16 Seite bedeutet das ein MIDS-Klasse-Terminal, einen zugewiesenen Satz TDMA-Zeitschlitze zur Übertragung, korrekte Kryptoschlüsselung und enge Synchronisation mit der Netz-Zeitreferenz. Auf der Link 22 Seite bedeutet es ein zugelassenes Link 22 Terminal, das dem Super Network beigetreten ist, mit eigener Schlüsselung und eigenem Netz-Timing.

Zeitsynchronisation ist keine Formalität. Jeder J-Series-Track ist nur im Bezug auf einen Messzeitpunkt bedeutsam, und ein fusioniertes Lagebild korreliert Tracks aus mehreren Quellen durch Vergleich ihrer zeitgestempelten Zustände. Wenn das Gateway auf einer Seite lose synchronisiert ist, werden die injizierten Tracks relativ zu den nativen Tracks im empfangenden Netz falsch zeitgestempelt, und die empfangende Fusionsschicht wird sie entweder als veraltet ablehnen oder schlimmer noch, sie falsch korrelieren. Das Gateway muss seine Uhr auf die Link 16 Netz-Zeitreferenz synchronisieren und auf das Link 22 Netz-Timing ausrichten, und es muss jeden weitergeleiteten Track mit einer Zeit kennzeichnen, die mit der Referenz des Zielnetzes und nicht mit seiner eigenen freilaufenden Uhr übereinstimmt.

Die Übersetzungspipeline

Im Inneren des Gateways durchläuft jeder weitergeleitete Track eine kurze, klar definierte Pipeline. Dekodierung: Die empfangene J-Series-Nachricht wird mit Dekodern dekodiert, die programmatisch aus den MIL-STD-6016-Feldtabellen generiert wurden – dieselbe Disziplin, die auf jeden J-Series-Verbraucher zutrifft, da handkodierte Bitfeldoperationen und Quantisierungsschritte subtile Offsetfehler produzieren, die Monate später als versetzte Tracks auftauchen. Validierung: Jedes dekodierte Feld wird gegen seinen physikalischen Wertebereich geprüft; eine Position außerhalb der Erde, ein negativer Schrägbereich oder eine unmögliche Geschwindigkeit zeigt eine fehlerhafte Quellnachricht an, die protokolliert und verworfen werden muss, nicht weitergeleitet. Abbildung: Der validierte Entitätsstatus wird in die J-Series-Nachricht des Ziel-Links übersetzt, wobei direkt zuordenbare Felder kopiert und Felder mit unterschiedlicher Kodierung neu verpackt werden. Kennzeichnen und Einreihen: Die Nachricht erhält eine Zielnetz-Track-Nummer und die Meldeverantwortung des Gateways und wird dann für die Übertragung in der nächsten verfügbaren Medienzugriffsgelegenheit in die Warteschlange eingereiht.

Auf moderner Hardware kostet die Dekodierungs-, Abbildungs- und Kodierungsarbeit nur einstellige Millisekunden pro Nachricht; das Gateway ist nicht rechengebunden. Die eigentliche Latenz liegt in der Warteschlangen-zu-Übertragungs-Lücke, die vollständig vom Medienzugriff des Ziel-Links abhängt – dem Warten auf die TDMA-Zeitschlitze des Gateways auf Link 16 oder auf seine Medienzugriffsgelegenheit auf Link 22.

Weiterleitung ohne Duplikation oder Schleifen

Das schwierigste Korrektheitsproblem in jedem Weiterleitungs-Gateway ist die Verhinderung, dass ein Track dupliziert, vervielfacht oder in eine unendliche Schleife gespeist wird. Drei Mechanismen wirken zusammen, um dies zu verhindern.

Die Weiterleitungstabelle. Das Gateway führt eine Tabelle, die nach der ursprünglichen Einheit und der Quell-Track-Nummer indexiert ist und jeden Quell-Track auf die ihm zugewiesene Ziel-Track-Nummer abbildet. Wenn derselbe Quell-Track aktualisiert wird, verwendet das Gateway dieselbe Ziel-Track-Nummer, sodass das empfangende Lagebild einen kontinuierlichen Track statt eines neuen Tracks pro Update sieht. Diese stabile Zuordnung ist das Fundament einer sauberen Weiterleitung.

Überschreiben der Meldeverantwortung. Jeder Track, den das Gateway in ein Netz injiziert, wird mit dem Gateway als meldender Einheit und nicht dem ursprünglichen Melder gekennzeichnet. Dies ermöglicht dem Gateway, seine eigene Ausgabe zu erkennen: Wenn ein Track, den es auf Link 22 weitergeleitet hat, später als Echo in Richtung Link 16 gehört wird, sieht das Gateway seine eigene Meldeverantwortung in der eingehenden Nachricht und unterdrückt die erneute Weiterleitung. Ohne diese Regel werden zwei Gateways – oder sogar ein einziges Gateway in einer reflexiven Topologie – Tracks unbegrenzt vervielfachen.

Identitäts- und kinematische Korrelation. Ein einzelnes physisches Flugzeug oder Schiff kann unabhängig auf beiden Links erscheinen, wenn es nativ von Teilnehmern auf jedem Netz gehört wird. Wenn das Gateway naiv beide weiterleitete, würde das fusionierte Lagebild zwei Marker für eine Entität zeigen. Die Korrelation nach Mode 5/Mode S Identität, wo verfügbar, fasst diese sofort zu einem einzigen Track zusammen; wo kein gemeinsamer Identitätsschlüssel vorhanden ist, prüft die kinematische Korrelation, ob zwei Tracks basierend auf konsistenter Position und Geschwindigkeit dieselbe Entität sein könnten. Diese Korrelation ist dieselbe Fusionsdisziplin, die immer dann eingesetzt wird, wenn mehrere Quellen ein Lagebild speisen, und wird im Artikel über NATO-Interoperabilitätsstandards umfassender behandelt.

Track-Nummernverwaltung über Nummernräume hinweg

Link 16 identifiziert Tracks durch eine 5-stellige oktale Track-Nummer, die von der meldenden Einheit vergeben wird, und Link 22 hat sein eigenes Track-Nummerierungsschema. Das Gateway überspannt daher zwei getrennte Nummernräume und muss Ziel-Track-Nummern aus seinem eigenen zugewiesenen Block in jedem Netz vergeben, während es eine stabile interne Track-Identität aufrechterhält, die über beide hinweg erhalten bleibt. Das empfohlene Muster ist dasselbe, das in jedem Multi-Netz Common Operating Picture verwendet wird: eine stabile interne Track-UUID für die Fusion führen, die operativ bedeutsame netzspezifische Track-Nummer für die Anzeige präsentieren und niemals zulassen, dass eine Track-Nummern-Kollision in einem Netz zwei verschiedene Entitäten fallen lässt oder zusammenführt. Die Überbrückung zweier zuvor getrennter Netze ist der klassische Kollisionsauslöser, und das Gateway muss ihn auflösen, ohne Tracks aus einem der beiden Lagebilder zu verlieren.

Klassifizierung, Schlüsselung und was ein Software-Team verantwortet

Ein Gateway überschreitet konstruktionsbedingt kryptografische und Klassifizierungsgrenzen. Jeder Link überträgt klassifizierten Datenverkehr, der durch zugelassene Kryptografie geschlüsselt ist, und das Gateway hält Schlüsselmaterial für beide. Die Übersetzungssoftware schwächt dies nicht – sie arbeitet auf bereits entschlüsselten J-Series-Inhalten innerhalb der zugelassenen Grenze –, aber das Programm muss sicherstellen, dass der Gateway-Host, seine Speicher und alle Cross-Domain-Elemente für die Dateneinstufung zugelassen sind. Datenlecks über ein taktisches Datenfunk-Gateway sind eine wiederkehrende Ursache für Cross-Domain-Zwischenfälle, und das Engineering-Team trägt die Verantwortung, den Datenpfad auditierbar zu gestalten.

Die Aufgabenverteilung ist klar zu benennen. Die Übersetzungs-, Weiterleitungs-, Korrelations- und Track-Verwaltungslogik ist normales Software-Engineering, anspruchsvoll aber von einem kompetenten Team realisierbar. Die einschränkenden Teile sind die zugelassenen Terminals (MIDS-Klasse für Link 16, zugelassene Link 22 Terminals für Link 22), die nationale Kryptoschlüsselung und das Netzdesign, das dem Gateway seine Zeitschlitze und Nummernblöcke zuweist. Das sind Programm- und nationale Behördenangelegenheiten, die über einen taktischen Datenfunkprozessor und Standard-Hostschnittstellen angebunden werden – dasselbe Zulassungsmuster, das für bodenseitige Standards wie MIP4-IES gilt.

Gut umgesetzt ist das Gateway unsichtbar: Ein maritimer Kontakt auf Link 22 erscheint einfach im Link 16 Luftlagebild, und ein Kampfjet-Track auf Link 16 erscheint einfach für die maritime Überhorizontstreitmacht – jeweils mit der richtigen Identität, dem richtigen Zeitstempel und genau einem Marker.