Tactical Chat und Datenstrategie in TAK: GeoChat, Sync und Bandbreite

Tactical Chat wirkt trügerisch einfach. Ein Operator tippt eine kurze Nachricht, ein Teamkollege liest sie, Entscheidungen folgen. Doch im TAK-Ökosystem ist diese Nachricht ein strukturiertes Event, das auf demselben Datenbus wie jede Positionsmeldung und Kartenmarkierung läuft, Funk- und Satellitenverbindungen durchquert, die ohne Vorwarnung abbrechen, und Empfänger erreicht, die womöglich die letzten zwanzig Minuten offline waren. Den Chat dazu zu bringen, unter diesen Bedingungen zuverlässig zu funktionieren, ist ein Datenstrategie-Problem, kein UI-Problem. Dieser Artikel untersucht, wie Tactical Chat innerhalb von TAK tatsächlich funktioniert — das GeoChat-Nachrichtenformat, wie Nachrichten getrennte Clients über Store-and-Forward-Sync erreichen, wie Anhänge vom Echtzeit-Bus entkoppelt werden und wie man das Ganze auf einer umkämpften Verbindung innerhalb eines Bandbreitenbudgets hält.

GeoChat: die TAK-Chat-Nachricht als CoT-Event

GeoChat ist die native Chat-Fähigkeit in ATAK, WinTAK und iTAK. Seine prägende Designentscheidung ist, dass eine Chat-Nachricht kein separates Protokoll ist — sie ist ein Cursor on Target (CoT) Event, derselbe XML-oder-Binär-Envelope, der alles andere auf dem TAK-Bus trägt. Ein GeoChat-Event nutzt den CoT-Typ b-t-f und trägt den Nachrichtentext, das Callsign und die UID des Absenders, das Ziel (eine einzelne UID, ein Team oder All-Chat) und einen optionalen Punkt, der die Nachricht an einen Ort auf der Karte verankert.

Diese letzte Eigenschaft ist es, die GeoChat „geo" macht. Ein Operator kann eine Nachricht auf einem bestimmten Gitter ablegen — „Kontakt, dieses Gebäude" — und der Empfänger sieht sowohl die Worte als auch den genauen Punkt, den sie beschreiben, dargestellt auf derselben Karte wie die Einheitspositionen. Die Nachricht und ihr räumlicher Kontext kommen als ein atomares Event an, statt als ein Satz, den der Leser in Koordinaten übersetzen muss.

Weil GeoChat auf dem CoT-Bus läuft, erbt es die Transports und die Zustellungssemantik des Busses ohne jeglichen chat-spezifischen Netzwerkcode. Auf einem lokalen Mesh ohne Server ist Chat UDP-Multicast — jeder Client auf dem Segment hört ihn. Über einen Router, eine Föderationsgrenze oder das öffentliche Internet ist Chat TLS-Unicast zu einem TAK Server, der ihn an die Empfänger fächert. Dasselbe Nachrichtenformat funktioniert auf einer Handfunkgerät-Verbindung und auf einem Glasfaser-Backhaul; nur der Transport darunter ändert sich.

Adressierung: direkt, Team und All-Chat

Ein GeoChat-Event kodiert sein Ziel, sodass das Netzwerk weiß, wer es empfangen soll. Eine Direktnachricht zielt auf eine einzelne Empfänger-UID und wird nur an diesen Client zugestellt. Eine Team-Nachricht zielt auf eine benannte Gruppe — die farbcodierten Teams, die ATAK verwendet, oder eine benutzerdefinierte Rollengruppierung — und erreicht jedes Mitglied dieses Teams. Ein All-Chat-Broadcast geht an jeden, der über den relevanten Transport erreichbar ist. Die Adressierung lebt innerhalb des Events, sodass die Aufgabe des Servers darin besteht, nach UID und Gruppenzugehörigkeit zu routen, statt den Nachrichteninhalt zu interpretieren. Diese Trennung hält den Server einfach und lässt dieselbe Routing-Logik Chat, Alarme und jedes andere adressierte CoT bedienen.

Store-and-Forward-Sync: den Client erreichen, der offline war

Die schwierigste Annahme, von der man sich verabschieden muss, wenn man aus dem zivilen Messaging kommt, ist die kontinuierliche Konnektivität. Im Feld hält sie nie. Ein Funkgerät verlässt hinter einem Bergrücken die Reichweite; ein Gerät wird zum Stromsparen ausgeschaltet; eine Verbindung wird gesättigt und beginnt, Pakete zu verwerfen. Wäre der Chat „fire-and-forget" — einmal gesendet, an jeden zugestellt, der gerade zuhört —, würde jede dieser Lücken stillschweigend Nachrichten verschlucken, und ein Operator, der in den Empfangsbereich zurückkehrt, hätte keine Ahnung, was er verpasst hat.

Store-and-Forward löst dies. Der TAK Server unterhält eine Zustellungswarteschlange pro Client, die nach Client-UID indiziert ist. Wenn eine Nachricht an einen Empfänger adressiert ist, der gerade nicht erreichbar ist, hält der Server sie, statt sie zu verwerfen. Wenn dieser Client wieder verbindet, spielt der Server die in der Warteschlange befindlichen Nachrichten in der richtigen Reihenfolge ab, sodass der Operator alles nachholt, was während des Ausfalls gesendet wurde. Der Mechanismus ist für den Absender unsichtbar — er sendet einmal, und der Server übernimmt die Verantwortung für die letztendliche Zustellung.

Hier unterscheidet sich der Chat auch deutlich von der reinen Positionsmeldung. Eine Positionsmeldung, die dreißig Sekunden alt ist, ist wertlos und sollte veralten und verschwinden dürfen; das Abspielen alter Positionen bei der Wiederverbindung verstopft die Karte nur mit Geistern. Eine Chat-Nachricht hingegen kann eine Stunde später genauso wichtig sein. Die Datenstrategie behandelt die beiden also unterschiedlich: Positionsmeldungen erhalten kurze Stale-Zeiten und werden nicht abgespielt, während Chat ein Aufbewahrungsfenster erhält und bei Wiederverbindung abgespielt wird. Das Abstimmen dieser beiden Timer gegeneinander ist eine der zentralen Konfigurationsentscheidungen in einer TAK-Bereitstellung.

Reihenfolge und Deduplizierung beim Abspielen

Das Abspielen einer Warteschlange wirft zwei subtile Korrektheitsprobleme auf. Erstens die Reihenfolge: Nachrichten müssen in der Sequenz abgespielt werden, in der sie gesendet wurden, sonst liest sich ein Gespräch als Unsinn. Der Server bewahrt die Sendereihenfolge pro Warteschlange, und der Client stellt nach Zeitstempel dar. Zweitens die Deduplizierung: Wenn ein Client kurz wieder verbindet, einen Teil seiner Warteschlange empfängt und dann erneut abbricht, darf er dieselben Nachrichten nicht zweimal sehen, wenn er ein drittes Mal verbindet. Jedes CoT-Event trägt eine UID, sodass Clients jedes Event unterdrücken, dessen UID sie bereits dargestellt haben. Idempotente Zustellung — dieselbe Nachricht zweimal zugestellt hat denselben Effekt wie einmal zugestellt — ist das, was das Abspielen über eine flatternde Verbindung sicher macht.

Anhänge: den Echtzeit-Bus leicht halten

Der schnellste Weg, Tactical Chat zu ruinieren, ist, ein Multi-Megabyte-Foto durch denselben Kanal wie Text zu schieben. Der CoT-Bus ist für kleine, häufige Events gebaut; eine einzelne große Payload inline blockiert Positionsaktualisierungen und verzögert jede dahinter wartende Nachricht in der Warteschlange. TAK entkoppelt Anhänge daher vollständig von der Nachricht.

Wenn ein Operator ein Foto, einen Videoclip oder ein Datenpaket an einen Chat oder eine Mission anhängt, wird die Datei auf den Enterprise-Dateispeicher des TAK Servers hochgeladen — den Content-Store hinter der Mission API —, und das Chat-Event trägt nur einen Content-Hash und eine URL-Referenz. Der Client des Empfängers erhält ein leichtgewichtiges Event, das sagt: „Hier ist ein Anhang, identifiziert durch diesen Hash, abrufbar unter dieser URL." Die eigentlichen Bytes werden über einen separaten HTTP-Kanal übertragen, bei Bedarf, nur wenn der Operator das Element öffnen möchte.

Zwei Eigenschaften lassen dies im Feld funktionieren. Erstens die content-adressierte Deduplizierung: Da der Store Inhalte per Hash indiziert, wird dasselbe Bild, das von zehn Personen geteilt wird, einmal gespeichert und einmal gegen die Bandbreite beim Upload gezählt. Zweitens die Wiederaufnehmbarkeit: Eine große Anhangübertragung, die durch einen Verbindungsabbruch unterbrochen wird, wird wiederaufgenommen statt neu gestartet, weil HTTP-Range-Requests dem Client erlauben, nur die fehlenden Bytes anzufordern. Keine der beiden Eigenschaften ist möglich, wenn die Datei inline in ein Echtzeit-CoT-Event gequetscht wird.

Bandbreitendisziplin auf umkämpften Verbindungen

Sobald Chat, Sync und Anhänge architektonisch getrennt sind, wird Bandbreitendisziplin zu einer Frage, jedes Element gegen die Realitäten der Verbindung abzustimmen. Der erste Hebel ist die Kodierung. Eine GeoChat-Nachricht, als CoT-XML ausgedrückt, ist typischerweise 400 bis 900 Bytes, und das meiste davon ist Envelope, nicht Nachrichtentext. TAK Server unterstützt eine protocol-buffer (protobuf) Kodierung von CoT, die ein typisches Event auf einige hundert Bytes komprimiert. Protobuf flottenweit zu aktivieren ist die einzige bandbreitenwirksamste Änderung mit der größten Hebelwirkung für chatlastigen Verkehr, vorausgesetzt, jeder Client kann sie aushandeln — gemischte Flotten fallen für die Clients, die die Binärform nicht dekodieren können, auf XML zurück.

Der zweite Hebel ist die Kadenz der Positionsmeldungen. Auf einer gesunden Verbindung ist eine Eigenmeldung pro Sekunde in Ordnung; auf einer gesättigten Verbindung ist sie der dominierende Bandbreitenverbraucher und verdrängt das Chat-Replay. Das Erhöhen des Eigenmeldungsintervalls — und die Nutzung der adaptiven Meldung von ATAK, die Meldungen verlangsamt, wenn ein Operator stationär ist — gibt die Verbindung für die Nachrichten frei, die Entscheidungen tragen. Ähnliche Disziplin gilt für MANET- und Mesh-Bereitstellungen, in denen der Verkehr jedes Knotens um geteilte Sendezeit konkurriert; dieselbe Budget-Logik pro Knoten, die das mobile Ad-hoc-Mesh-Networking regelt, gilt direkt dafür, wie viel Chat- und Positionsverkehr ein Segment aufrechterhalten kann.

Der dritte Hebel ist die Anhang-Richtlinie. Auto-Download sollte auf jedem Feld-Client hinter einer umkämpften Verbindung ausgeschaltet sein, sodass Anhänge als Hash-und-URL-Referenzen bleiben, bis ein Operator bewusst einen öffnet. Das verwandelt ein flottenweites Bandbreitenereignis — jeder lädt dasselbe Foto gleichzeitig herunter — in eine kleine Anzahl von On-Demand-Abrufen durch die Operatoren, die den Inhalt jetzt tatsächlich brauchen.

Föderation und Chat-Reichweite

Die Chat-Reichweite endet nicht an einem Server. Wenn zwei oder mehr TAK Server föderiert sind, wird eine über die Grenze adressierte Chat-Nachricht zwischen Servern weitergeleitet und an Empfänger im fernen Netzwerk zugestellt — vorausgesetzt, die Föderationsrichtlinie erlaubt diese Gruppe und die sendende UID darf die Grenze überschreiten. So erreicht eine Nachricht von einem vorgeschobenen Team ein höheres Hauptquartier, das seinen eigenen Server betreibt, oder so nehmen die Operatoren eines Koalitionspartners an einem gemeinsamen All-Chat teil. Die datenstrategische Implikation ist, dass Store-and-Forward und Adressierung nun mehrere Hops umspannen: Ein Empfänger auf einem föderierten Peer, der offline ist, verlässt sich auf die Zustellungswarteschlange dieses Peers, nicht auf die des ursprünglichen Servers. Chat-Adressierungsgruppen so zu gestalten, dass sie sauber auf die Föderationsrichtlinie abbilden — statt sie willkürlich zu überschreiten —, hält die Reichweite vorhersehbar und verhindert, dass Nachrichten an Netzwerke durchsickern, für die sie nie gedacht waren.

Chat versus Mission-Data-Sync

Tactical Chat ist eine Hälfte der TAK-Datengeschichte; persistenter Data-Sync ist die andere. GeoChat ist flüchtig und konversationell — es beantwortet „was passiert gerade jetzt". Eine Data-Sync-Mission (eine Mission oder ein Data Package in der Terminologie des TAK Servers) ist ein persistenter, versionierter Container von Inhalten: Karten, Markierungen, Dateien und ein Änderungsprotokoll, das abonnierte Clients synchron halten. Sie beantwortet „was ist der aktuelle maßgebliche Zustand dieser Operation". Die meisten Bereitstellungen betreiben beides: Chat für schnelle Koordination, Missionen für das gemeinsame Lagebild und die Dokumentenverteilung, mit derselben Store-and-Forward- und Föderations-Infrastruktur darunter. Die Vertraulichkeit beider Datenflüsse hängt von der Transportsicherheit ab, die in unserem Beitrag über verschlüsseltes Messaging für den militärischen Feldeinsatz behandelt wird.

Alles zusammenfügen: eine Bereitstellungs-Datenstrategie

Eine kohärente Tactical-Chat-Strategie behandelt Messaging, Sync und Anhänge als drei Datenflüsse mit unterschiedlichen Prioritäten, die sich eine Verbindung teilen. Chat ist klein, latenzempfindlich und muss eine Trennung durch Store-and-Forward überstehen. Positionsmeldung ist volumenstark, entsorgbar und sollte veralten statt abgespielt zu werden. Anhänge sind groß, aufschiebbar und gehören auf einen separaten On-Demand-Kanal mit Deduplizierung und Wiederaufnehmbarkeit. Konfigurieren Sie den Server so, dass diese drei nicht destruktiv konkurrieren — protobuf-Kodierung überall, Chat-Warteschlangen pro Client mit sinnvoller Aufbewahrung, kurze Stale-Zeiten für Spuren und Anhang-Auto-Download am Rand deaktiviert.

Treffen Sie diese Entscheidungen richtig, wird Tactical Chat zu dem, was er sein sollte: eine zuverlässige, kostengünstige Koordinationsschicht, die weiterarbeitet, wenn die Verbindung schlecht ist, und Operatoren auf den neuesten Stand bringt, wenn sie zurückkehren. Treffen Sie sie falsch, wird der Chat zum ersten Opfer eines gesättigten Netzwerks — genau dann, wenn ein Team ihn am dringendsten braucht.