Taktinen chat ja datastrategia TAK-ympäristössä: GeoChat, synkronointi ja kaistanleveys

Taktinen chat vaikuttaa petollisen yksinkertaiselta. Käyttäjä kirjoittaa lyhyen viestin, joukkuetoveri lukee sen ja päätökset seuraavat. Mutta TAK-ekosysteemissä kyseinen viesti on jäsennelty tapahtuma, joka kulkee samalla dataväylällä kuin kaikki sijaintiraportit ja karttatunnukset, radiolinkejä ja satelliittiyhteyksiä ylittäen, tavoittaakseen vastaanottajia, jotka ovat ehkä olleet offline-tilassa viimeiset kaksikymmentä minuuttia. Chatin saaminen toimimaan luotettavasti näissä olosuhteissa on datastrategiaongelma, ei käyttöliittymäongelma. Tässä artikkelissa tarkastelemme, miten taktinen chat toimii TAK:n sisällä — GeoChat-viestiformaatti, miten viestit tavoittavat offline-asiakkaat store-and-forward-synkronoinnin kautta, miten liitetiedostot irrotetaan reaaliaikaisesta väylästä ja miten koko asia pysyy kaistanleveyden rajoissa kiistanalaisella yhteydellä.

GeoChat: TAK-chatviesti CoT-tapahtumana

GeoChat on ATAK:n, WinTAK:n ja iTAK:n natiivi chatominaisuus. Sen keskeinen suunnitteluvalinta on, että chatviesti ei ole erillinen protokolla — se on Cursor on Target (CoT) -tapahtuma, sama XML- tai binäärikuori, joka kuljettaa kaiken muunkin TAK-väylällä. GeoChat-tapahtuma käyttää CoT-tyyppiä b-t-f ja sisältää viestin tekstin, lähettäjän kutsunimen ja UID:n, kohteen (yksittäinen UID, tiimi tai yleislähetys) sekä valinnaisen pisteen, joka ankkuroi viestin kartalla olevaan sijaintiin.

Tuo viimeinen ominaisuus tekee GeoChatista "geo". Käyttäjä voi pudottaa viestin tietylle koordinaatille — "kontakti, tämä rakennus" — ja vastaanottaja näkee sekä sanat että tarkan pisteen, jota ne kuvaavat, renderöitynä samalle kartalle kuin joukkojen sijainnit. Viesti ja sen tilakonteksti saapuvat yhtenä atomisena tapahtumana eikä lauseena, jonka lukijan täytyy kääntää koordinaateiksi.

Koska GeoChat kulkee CoT-väylällä, se perii väylän siirtoprotokollat ja toimitusprimitiivit ilman chat-spesifistä verkkokoodia. Paikallisessa meshissä ilman palvelinta chat on UDP-multicast — kaikki segmentin asiakkaat kuulevat sen. Reitittimen, federaatiorajan tai julkisen internetin yli chat on TLS-unicast TAK-palvelimelle, joka jakaa sen edelleen vastaanottajille. Sama viestiformaatti toimii käsiradiolinkin ja kuitupalvelimen kautta; vain sen alla oleva siirtoprotokolla muuttuu.

Osoittaminen: suoraviesti, tiimi ja yleislähetys

GeoChat-tapahtuma koodaa kohteensa niin, että verkko tietää, kenen pitäisi vastaanottaa se. Suoraviesti kohdistuu yksittäiselle vastaanottajalle UID:n perusteella ja toimitetaan vain kyseiselle asiakkaalle. Tiimiviesti kohdistuu nimetylle ryhmälle — ATAK:n käyttämille värikoodatuille tiimeille tai mukautetulle rooliryhmälle — ja tavoittaa kaikki tiimin jäsenet. Yleislähetys menee kaikille asianomaisella siirtoprotokollan tavoitettavilla. Osoitustieto on tapahtuman sisällä, joten palvelimen tehtävä on reitittää UID:n ja ryhmäjäsenyyden perusteella eikä tulkita viestin sisältöä. Tämä erottelu pitää palvelimen yksinkertaisena ja antaa saman reitityslogiikan palvella chattia, hälytyksiä ja mitä tahansa muuta osoitettua CoT-tapahtumaa.

Store-and-forward-synkronointi: offline-asiakkaan tavoittaminen

Vaikein olettamus hylättäväksi siviiliviestinnästä siirtyessä on jatkuvan yhteyden olettamus. Kentällä se ei koskaan pidä paikkansa. Radio menee kantaman ulkopuolelle harjanteen taakse; laite sammutetaan akun säästämiseksi; yhteys kyllästyy ja alkaa pudottaa paketteja. Jos chat olisi "lähetä ja unohda" — lähetetään kerran, toimitetaan kaikille, jotka sattuvat kuuntelemaan — jokainen näistä aukoista nielaisi viestit hiljaisesti, ja kantaman ulkopuolelta palaavalla käyttäjällä ei olisi aavistustakaan, mitä hän oli jäänyt paitsi.

Store-and-forward ratkaisee tämän. TAK-palvelin ylläpitää asiakaskohtaista toimitusjonoa, joka on nimetty asiakkaan UID:n mukaan. Kun viesti on osoitettu vastaanottajalle, joka on tällä hetkellä tavoittamattomissa, palvelin pidättää sen hylkäämisen sijaan. Kun asiakas yhdistyy uudelleen, palvelin toistaa jonossa olevat viestit järjestyksessä, joten käyttäjä saa kaiken poissaolonsa aikana lähetetyn. Mekanismi on lähettäjälle näkymätön — he lähettävät kerran, ja palvelin ottaa vastuun lopullisesta toimituksesta.

Tässä chat eroaa myös jyrkästi raa'asta sijaintiraportoinnista. Kolmekymmentä sekuntia vanha sijaintiraportti on arvoton ja sen pitää antaa vanhentua ja kadota; vanhojen sijaintien toistaminen uudelleenyhdistymisen yhteydessä vain täyttää kartan haamuilla. Chatviesti sen sijaan voi olla yhtä tärkeä tunti myöhemmin. Joten datastrategia kohtelee näitä kahta eri tavalla: sijaintiraporteille asetetaan lyhyet vanhentumisajat eikä niitä toisteta, kun taas chatille annetaan säilytysikkuna ja se toistetaan uudelleenyhdistymisen yhteydessä. Näiden kahden ajastimen virittäminen toisiaan vastaan on yksi TAK-deployoinnin keskeisistä konfigurointipäätöksistä.

Järjestys ja deduplikointi toistossa

Jonon toistaminen tuo mukanaan kaksi hienovaraista oikeellisuusongelmaa. Ensimmäinen on järjestys: viestit on toistettava siinä järjestyksessä, jossa ne lähetettiin, tai keskustelu on käsittämätön. Palvelin säilyttää lähetysjärjestyksen jonoa kohden ja asiakas renderöi aikaleiman mukaan. Toinen on deduplikointi: jos asiakas yhdistyy hetkellisesti uudelleen, vastaanottaa osan jonosta ja katkeaa sitten jälleen, sen ei pidä nähdä samoja viestejä kahdesti yhdistyessä kolmatta kertaa. Jokainen CoT-tapahtuma kantaa UID:tä, joten asiakkaat tukahduttavat minkä tahansa tapahtuman, jonka UID:n ne ovat jo renderöineet. Idempotentti toimitus — sama viesti toistettuna kahdesti tuottaa saman vaikutuksen kuin kerran toistettuna — tekee toistosta turvallista epävakaalla yhteydellä.

Liitetiedostot: reaaliaikaisen väylän pitäminen kevyenä

Nopein tapa pilata taktinen chat on työntää usean megatavun kuva samaa kanavaa pitkin kuin teksti. CoT-väylä on rakennettu pienille, tiheille tapahtumille; yksi suuri kuorma suoraan välitettynä pysäyttää sijaintipäivitykset ja viivästyttää jokaista jonossa olevaa viestiä sen jälkeen. Siksi TAK irrottaa liitetiedostot kokonaan viestistä.

Kun käyttäjä liittää kuvan, videoleikkeen tai datapaketin chattiin tai missioon, tiedosto ladataan TAK-palvelimen enterprise-tiedostojakoon — Mission API -sisältövarastoon — ja chatti- tai missiiotapahtuma sisältää vain sisältötiivisteen ja URL-viitteen. Vastaanottajan asiakas saa kevyen tapahtuman, jossa lukee: "tässä on liitetiedosto, tunnistettu tällä tiivisteellä, ladattavissa tästä URL:sta." Varsinaiset tavut siirtyvät erillisellä HTTP-kanavalla, pyydettäessä, vain kun käyttäjä päättää avata kohteen.

Kaksi ominaisuutta saa tämän toimimaan kentällä. Ensimmäinen on sisältöosoitteinen deduplikointi: koska varasto avainnataa sisällön tiivisteen perusteella, kymmenen ihmisen jakama sama kuva tallennetaan kerran ja lasketaan kerran kaistanleveyteen latauksessa. Toinen on jatkettavuus: suuren liitetiedoston siirto, jonka yhteyskatko keskeyttää, jatkuu eikä aloita alusta, koska HTTP-aluepyynnöt antavat asiakkaan pyytää vain puuttumia tavuja. Kumpikaan ominaisuus ei ole mahdollinen, jos tiedosto ujutetaan suoraan reaaliaikaiseen CoT-tapahtumaan.

Kaistanleveyskuri kiistanalaisilla yhteyksillä

Kun chat, synkronointi ja liitetiedostot on arkkitehtuurillisesti eroteltu, kaistanleveyskuri on kunkin virittämistä yhteyden realiteetteja vasten. Ensimmäinen vipuvarsi on koodaus. GeoChat-viesti CoT XML:nä on tyypillisesti 400–900 tavua, ja suurin osa siitä on kuori, ei viestin runko. TAK-palvelin tukee CoT:n protokollapuskuri (protobuf) -koodausta, joka pakkaa tyypillisen tapahtuman muutamaan sataan tavuun. Protokollapuskurin käyttöönotto koko flootassa on yksittäinen suurin kaistanleveyden parannus chat-raskaassa liikenteessä, kunhan kaikki asiakkaat pystyvät neuvottelemaan sen — sekaflootit palaavat XML:ään asiakkaiden osalta, jotka eivät pysty dekoodaamaan binäärimuotoa.

Toinen vipuvarsi on sijaintiraporttikadenssi. Terveellä yhteydellä yhden sekunnin itseraportointiväli on hyvä; kyllästyneellä yhteydellä se on kaistanleveyden hallitseva kuluttaja ja syrjäyttää chatin toiston. Itseraportointivälin kasvattaminen — ja ATAK:n mukautuvan raportoinnin käyttö, joka hidastaa raportteja paikallaan olevan käyttäjän kohdalla — vapauttaa yhteyttä päätöksiä sisältäville viesteille. Sama kuri koskee MANET- ja mesh-deployointeja, joissa jokaisen noden liikenne kilpailee yhteisestä radiotaajuudesta; sama nodea kohden laskettu budjetti, joka säätelee mobiilia ad-hoc-mesh-verkottumista, pätee suoraan siihen, paljonko chat- ja sijaintiliikennettä segmentti voi kestää.

Kolmas vipuvarsi on liitetiedostopolitiikka. Automaattinen lataus pitää olla pois käytöstä kaikilla kiistanaalaisen yhteyden takana olevilla kenttäasiakkailla, jotta liitetiedostot pysyvät hash-ja-URL-viitteinä, kunnes käyttäjä avaa jonkin niistä tahallisesti. Tämä muuntaa koko flootan kaistanleveystapahtuman — kaikki lataavat saman kuvan samaan aikaan — pieneksi joukoksi pyydettäessä tapahtuvaksi haetuiksi toimilla niiden käyttäjien toimesta, jotka tarvitsevat sisällön juuri nyt.

Federaatio ja chatin tavoitettavuus

Chatin tavoitettavuus ei pysähdy yhteen palvelimeen. Kun kaksi tai useampaa TAK-palvelinta on federoitu, eri rajoja ylittävä chatviesti välitetään palvelinten välillä ja toimitetaan etäverkon vastaanottajille — edellyttäen, että federaatiopolitiikka sallii kyseisen ryhmän ja lähettävä UID saa ylittää rajan. Näin etummaisesta joukkueesta tuleva viesti saavuttaa ylemmän johtoportaan, jolla on oma palvelin, tai koalitiopartnerin käyttäjät osallistuvat yhteiseen yleislähetykseen. Datastrategiavaikutus on, että store-and-forward ja osoittaminen kattavat nyt useita hyppyjä: federoituun vertaiseen kuuluva offline-vastaanottaja luottaa kyseisen vertaisen toimitusjonoon, ei lähtöpalvelimen jonoon. Chatin osoitusryhmien suunnitteleminen niin, että ne vastaavat selkeästi federaatiopolitiikkaa — eivät ylitä sitä satunnaisesti — pitää tavoitettavuuden ennakoitavana ja estää viestejä vuotamasta verkkoihin, joihin ne ei koskaan ollut tarkoitettu.

Chat verrattuna missioiden datansynkronointiin

Taktinen chat on toinen puoli TAK:n datatarinasta; pysyvä datansynkronointi on toinen. GeoChat on ohimenevää ja keskustelumuotoista — se vastaa kysymykseen "mitä tapahtuu nyt." Datansynkronointimissio (Mission tai Data Package TAK-palvelimen termein) on pysyvä, versioitu sisältösäiliö: karttoja, tunnuksia, tiedostoja ja muutosloki, jonka tilaajaasiakkaat pitävät synkronoituina. Se vastaa kysymykseen "mikä on tämän operaation nykyinen auktoritatiivinen tila." Useimmat deployoinnit käyttävät molempia: chat nopeaan koordinointiin, missiot yhteisen kuvan ja asiakirjajakelun tarpeisiin, samalla store-and-forward- ja federaatioinfrastruktuurilla alla. Molempien virtojen luottamuksellisuus riippuu siirtoturvallisuudesta, jota käsitellään artikkelissamme salatusta viestinnästä sotilaskäyttöön kentällä.

Kokonaisuuden kokoaminen: deployoinnin datastrategia

Johdonmukainen taktinen chatstrategia kohtelee viestintää, synkronointia ja liitetiedostoja kolmena erillistä prioriteettia omaavana virtana, jotka jakavat yhden yhteyden. Chat on pieni, viiveelle herkkä ja sen on selvittävä katkoksista store-and-forwardin avulla. Sijaintiraportointi on suurivolyymista, hävitettävää ja sen pitäisi vanhentua eikä toistua. Liitetiedostot ovat suuria, lykättävissä olevia ja kuuluvat erilliselle pyydettäessä ladattavalle kanavalle deduplikoinnin ja jatkettavuuden kera. Konfiguroi palvelin niin, etteivät nämä kolme kilpaile tuhoisasti — protobuf-koodaus kaikkialla, asiakaskohtaiset chatijonot järkevällä säilytyksellä, lyhyet vanhentumisajat jäljille ja liitetiedostojen automaattinen lataus pois käytöstä reunassa.

Saa nämä päätökset oikein ja taktisesta chatista tulee sen, mitä sen pitäisi olla: luotettava, kustannustehokas koordinaatiokerros, joka toimii edelleen yhteyden ollessa huono ja päivittää käyttäjät, kun he palaavat. Saa ne väärin ja chatista tulee ensimmäinen uhri kyllästyneessä verkossa — juuri silloin, kun tiimi tarvitsee sitä eniten.