Satelliittiyhteys taktisissa kenttäsovelluksissa: SATCOM-integraatioarkkitehtuuri

Satelliittiviestintä ei ole enää takalinjan kapasiteetti. LEO-tähtijärjestelmät ovat pienentäneet päätelaitteet mahtumaan partiorepassaan, ja kaupallisten laajakaistapalvelujen lisääntyminen perinteisten kapeakaistaisiin sotilassatelliittijärjestelmien rinnalla tarkoittaa, että jalkautuneella ryhmällä voi teatterista riippuen olla käytettävissään kolme tai neljä erillistä satelliittiyhteyttä. Ohjelmistokehityksen haaste ei ole signaalin saanti – se on kenttäsovellusten rakentaminen niin, että ne käsittelevät SATCOM:a yhtenä kuljetusvälineenä muiden joukossa, mukauttavat toimintaansa käytettävissä olevan linkkibudjetin mukaan ja ylläpitävät tilannetietoisuuden väistämättömien aukkojen ajan. Tässä artikkelissa käsitellään arkkitehtuuriratkaisuja SATCOM:n integroimiseksi taktisiin kenttäsovelluksiin: tähtijärjestelmäkompromissit, kaistanleveyden suunnittelu CoT- ja verkkoliikenteelle, tallenna-ja-välitä-mallit, priorisointi, päätelaitekohtaiset integrointipisteet, kryptografia ja hybridivarayhteyssuunnittelu.

SATCOM-vaihtoehdot jalkautuneille joukoille: LEO-, MEO- ja GEO-kompromissit

Kolme taktisille käyttäjille käytettävissä olevaa kiertorataluokkaa tarjoavat perustavanlaatuisesti erilaisia kompromisseja latenssin, kaistanleveyden, päätelaitteen koon ja kattavuuden välillä. Geostationaariset (GEO) satelliitit 35 786 km korkeudessa tarjoavat jatkuvan kattavuuden kiinteällä lautasantennilla, mutta 500–600 ms:n edestakainen etenemisviive eliminoi reaaliaikaiset interaktiiviset sovellukset ja aiheuttaa mitattavan haitan TCP-suorituskyvylle: yksi kuittaamaton segmentti pysäyttää lähettäjän yli puoleksi sekunniksi, ja virittämätön TCP:n ruuhkaikkunahallinta toimii selvästi alle linkin teoreettisen kapasiteetin suurella latenssilla. GEO-järjestelmät, kuten Inmarsat BGAN, pysyvät operatiivisesti hyödyllisinä erä-SITREP-lähetyksille, tiedostosiirroille ja satelliittivälitteisille kartoille, mutta latenssiprofiili edellyttää sovelluskehittäjiä nimenomaisesti välttämään synkronisia pyyntö-vastaus-malleja yhteyden yli.

Maan kiertoradan (LEO) tähtijärjestelmät ratkaisevat latenssiongelman: Starlink-päätteet litteässä muodossaan tuottavat 20–40 ms:n edestakaisia vasteaikoja mahdollistaen interaktiivisen CoT:n, IP-puheen ja pieniviiveisen videon. Kompromissina on päätelaitteen virrankulutus, joka on 40–100 W kuluttajatason litteälle lautasantennille, sekä vaatimus seurata liikkuvaa satelliittia tai siirtyä satelliitista toiseen niiden ylittäessä taivaan. Keskimaan kiertoratan (MEO) ja Iridium-tähtijärjestelmä noin 780 km:n korkeudella toimivat eri tavalla: Iridium tarjoaa todellisen globaalin kattavuuden mukaan lukien napalueet, joissa GEO-satelliiteilla ei ole geometriaa, mutta kanavakapasiteetti on kapea – 2,4 kbps piirinkytkettyä kanavaa kohti 22 kbps:iin Iridium RUDICS:lla. Jalkautuneelle jalkaväelle, jolla ei ole muuta virtalähdettä kuin paristot, Iridium on usein ainoa toimintakykyinen vaihtoehto, ja ohjelmisto on arkkitehtuurisuunniteltava yhteyden ympärille, joka maksaa suuruusluokkia enemmän kilobittia kohti kuin mikään kaupallinen palvelu.

Taktisen sovelluksen käytännöllinen valintakriteeri ei ole se, mikä tähtijärjestelmä on teoriassa paras, vaan mitkä päätteet ovat yksikön laiteluettelossa. Ohjelmiston on abstrahoitava fyysinen yhteys kuljetuslityntäpinnan taakse, joka paljastaa hyötyliikenteen läpimenon, latenssin ja tavu-per-kustannus -arviot, jotta ylemmät kerrokset voivat mukauttaa toimintaansa saatavilla olevaan. Tehtävä, joka alkaa Starlinkillä ensimmäiset 48 tuntia, voi siirtyä pelkkään Iridiumiin generaattorin loputtua, ja sovelluksen tulisi heikentyä hallitusti eikä lakata toimimasta.

Kaistanleveyden budjetointi CoT:lle, SITREPille ja videolle satelliittiyhteydellä

Ensimmäinen askel SATCOM:n integroimisessa kenttäsovellukseen on realistisen kaistanleveyden budjetin rakentaminen kullekin operatiiviselle skenaariolle. CoT-sijaintiraportit ovat kompakteja: yksittäinen XML-sijaintitapahtuma yhdelle ATAK-asiakkaalle tiivistyy noin 200–500 tavuksi zlib-pakkauksen jälkeen, ja 30 sekunnin raportointivälillä 12 hengen ryhmä tuottaa noin 2–4 kbps:n ylöspäin suuntautuvan liikenteen. Tämä mahtuu mukavasti BGAN- tai Iridium RUDICS -istuntoon, mutta COP ei ole pelkkää sijaintidataa. Chat-viestit, SITREP-lomakkeet, kontaktiraportit ja sensorisyötteet kuluttavat kukin lisäkapasiteettia, ja alaspäin suuntautuva liikenne – TAK Server jakellessaan koottua COP:a kaikille asiakkaille – voi helposti ylittää ylöspäin suuntautuvan liikenteen kolmin- tai nelinkertaisesti suuren joukkojen kuvan ollessa käytössä.

Video on budjettia rikkova tekijä. Yksittäinen H.264-virta 640x480 resoluutiolla ja 15 kuvaa sekunnissa vaatii tyypillisesti 200–500 kbps hyväksyttävän laadun ylläpitämiseksi kohteiden tunnistamisessa. Iridium-yhteydellä video ei yksinkertaisesti ole mahdollista. BGAN Standard IP -istunnolla (tyypillisesti 492 kbps symmetrinen), yksittäinen pakattu virta on toteutettavissa mutta ei jätä tilaa muulle. Arkkitehtien on päätettävä, onko video määritetty ominaisuus vai opportunistinen lisäominaisuus, joka aktivoituu vain korkean kaistanleveyden yhteydellä (Starlink, sotilaslaajakaistapääte). Sovelluksen tulisi havaita käytettävissä oleva läpimeno käynnistyshetkellä ja säännöllisesti, säätää videoenkooderin bittinopeus mahtumaan budjetoituun osaan ja keskeyttää videolähetys automaattisesti, kun CoT- tai viestintäliikenne lähestyy linkin kapasiteettikattoa.

Binaarinen CoT-koodaus pienentää sijaintiraporttien kokoa edelleen 40–60 % pakattuun XML:ään verrattuna, ja protokollatason eräkäsittely – useiden lyhyiden viestien yhdistäminen yksittäiseen IP-pakettiin – vähentää merkittävästi viestikohtaista ylikuormaa suurella latenssilla yhteyksillä, joissa TCP-kuittauskierrot ovat kalliita. Molemmat optimoinnit ovat erityisen arvokkaita Iridiumilla, jossa jokaisella kilotavulla on merkittävä lähetysaikakustannus ja 24 tunnin partion linkkibudjetti voidaan mitata kymmenissä megatavuissa eikä gigatavuissa.

Tallenna-ja-välitä-mallit katkonaisille satelliittiyhteyksille

Satelliittinäkyvyys ei ole jatkuvaa monimutkaisessa maastossa toimiville jalkautuneille joukoille. Laaksossa liikkuva partio menettää Starlink-yhteyden heti, kun lautasantenni laskee alle vaaditun minimielevaatiokulman – tyypillisesti 25 astetta litteälle LEO-päätelaitteelle. Iridium-ohilennot ovat rajallisia: yksittäinen satelliitti näkyy noin 10 minuuttia, ja satelliittien välisen 30–90 sekunnin aikana yhteys ei ole käytettävissä. Kummassakin tapauksessa kenttäsovelluksen on käsiteltävä yhteyskatkot ilman tietojen menetystä eikä operaattorin toimia vaatien.

Tallenna-ja-välitä-malli ratkaisee tämän viestitasolla. Lähtevät viestit kirjoitetaan pysyvään paikalliseen jonoon (SQLite-tietokanta WAL-kirjauksella on luotettava valinta sulautetuille alustoille) ennen kuin sovellus yrittää lähetystä. Jos yhteys ei ole käytettävissä, viesti jää jonoon. Kun yhteys palautuu – olipa se sitten uuden satelliitin tuleminen näköetäisyydelle, partion nouseminen harjanteelle ja Starlink-geometrian saavuttaminen tai MANET-yhdyskäytävän tuleminen kantaman sisälle – jono tyhjenee prioriteettijärjestyksessä. Jokainen viesti sisältää CoT-vanhenemisaikansa, ja jonon purkamislogiikka tarkistaa ennen lähetystä, onko seinäkellon nykyaika ylittänyt vanhenemisajan: sijaintiraportti, joka vanhentui 10 minuuttia sitten, tulisi hylätä eikä syöttää COP:iin ajankohtaisena datana. Vastaanottavan TAK Serverin tulisi vastaavasti soveltaa vanhenemisajan suodatusta eikä hyväksyä viestejä iästä riippumatta.

Linkkibudjettitietoinen viestipriorisointi

Linkkikapasiteetin ollessa rajattu sovelluksen on tehtävä nimenomaisia päätöksiä siitä, mikä liikenne läpäisee ja mikä lykätään tai hylätään. Orgaanisesti kehittyneet ad hoc -prioriteettijärjestelmät, jotka perustuvat "kehittäjän oletuksiin", epäonnistuvat johdonmukaisesti kentällä, koska tehtävävaatimukset eroavat ajoneuvolla liikkuvan partion, kiinteän tarkkailuaseman ja ilmaisen komentoelementin välillä. Prioriteetin on oltava konfiguroitava parametri eikä käännösaikainen vakio.

Neliluokkainen järjestelmä sopii hyvin taktisiin realiteetteihin. Hätäliikenne – CASEVAC-pyynnöt, kontaktiraportit aktiivisesta tilanteesta ja joukkojensuojeluhälytykset – saa ehdottoman lähetyksen prioriteetin eikä sitä tulisi koskaan hylätä yhteyden tilasta riippumatta. Korkean prioriteetin liikenne kattaa rutiinimaiset komentajan sijaintipäivitykset, TAK Server -tilantarkistukset ja aikakrittiset SITREP-tiedot. Normaali liikenne on sinisten joukkojen vakioseuranta kaikille muille yksikön jäsenille. Taustaliikenne käsittelee kuvapaketit, karttaruutupäivitykset ja lokitiedostojen lataukset. Tokenämpäriajastin kullekin luokalle, jossa ämpärien koot on johdettu kaistanleveyden budjetista, varmistaa, että hätäliikenne saa osuutensa jopa silloin, kun taustaliikenne täyttää yhteyden. Kun läpimeno laskee alle budjetoidun kapasiteetin – havaitaan mittaamalla ACK-edestakaisia vasteaikoja odotettuun linkkilatenssin nähden – ajastin pienentää tokenien täyttötahtia normaalin ja taustan luokissa pitäen hätä- ja korkean prioriteetin tahdit vakioina.

Prioriteettikartoituksessa on otettava huomioon käytettävän yhteyden kustannusmalli. Kiinteähintaisella Starlink-istunnolla taustatiedonsiirrolle ei aiheudu lisäkustannuksia matalan taktisen aktiivisuuden aikana. Kilotavuittain laskutettavalla Iridium-yhteydellä taustaliikenne tulisi estää kokonaan, ellei operaattori nimenomaisesti aloita datasessiota. Kuljetusabstraktiokerroksen tulisi paljastaa kustannusherkkyysmerkin läpimenon ja latenssin rinnalla, jotta prioriteettiajastin voi soveltaa kustannustietoisia sääntöjä pelkän läpimenon sijaan.

Integrointi Iridium-, Starlink- ja laajakaistaisiin sotilassatelliitin SATCOM-päätteisiin

Jokainen päiteperhe tarjoaa erilaisen integrointipinnan. Iridium-modeemit paljastavat sarjaliitäntäisen AT-komentoliitin piirinkytketyille puheluille ja IP-pinon RUDICS- tai SBD (Short Burst Data) -palvelulle. SBD on erityisen tärkeä matalimman kaistanleveyden skenaarioissa: jokainen SBD-viesti sisältää enintään 340 tavua mobiililähetystä ja 270 tavua mobiilivastaanottoa, mikä tekee siitä sopivan pakatuille CoT-sijaintiraporteille ja lyhyille tekstiviesteille mutta ei useita kilotavuja vaativille sovelluksille. RUDICS-palvelu tarjoaa TCP/IP-istunnon enintään 22 kbps nopeudella, joka riittää CoT:lle ja chatille mutta edellyttää kurinalaista pakkausta ja eräkäsittelyä koko ryhmän palvelemiseksi. Integrointi vaatii modeemin tilasiirtymien nimenomaisen käsittelyn – AT+SBDI-komento käynnistää SBD-istunnon, ja sovelluksen on poultattava saapuvia viestejä, koska pysyvää TCP-pistorasiaa ei ole kuten laajakaistayhteydessä.

Starlink-integrointi on vertailun vuoksi yksinkertaista: pääte tarjoaa vakio-Ethernet-liitännän DHCP:llä, ja sovellus näkee sen tavallisena laajakaistayhteyspisteenä. Tekninen työ liittyy yhteydensiirtymien hallintaan ja käytettävissä olevan läpimenon oikeaan arvioimiseen. Starlinkin läpimeno vaihtelee satelliittigeometrian, esteiden ja verkkokuormituksen mukaan; sovelluksen tulisi mitata todellinen läpimeno eikä olettaa, että nimellinen 50–200 Mbps:n spesifikaatio pätee kaikissa olosuhteissa. Sotilasluokan Starlink-päätteet lisäävät salattua viestintää ja häirintäsuojauksen ominaisuuksia mutta paljastavat saman IP-liitännän päätekerroksen yläpuolisille sovelluksille.

Laajakaistaiset sotilassatelliitin SATCOM-päätteet (kattaen X-, Ka-kaistan ja UHF MILSATCOM -järjestelmät) integroituvat tyypillisesti modeemin kautta, joka tarjoaa IP-liitännän ajoneuvolle tai suojaverkkoon. Samat taktisten radioiden ohjelmistointegraatioihin liittyvät periaatteet pätevät tässä: sovelluksen ei tule olettaa taustalla olevaa siirtovälinettä vaan käsitellä modeemin IP-liitäntää abstraktina yhteysvälineenä mitatuin laatuparametrein. Jotkin sotilassatelliitin SATCOM-modeemit paljastavat laadun indikaattorit SNMP:n tai omistusoikeudellisten sovellusliittymien kautta; kun ne ovat käytettävissä, niiden tulisi syöttää linkkilaatua seuraavaa valvontaohjelmaa pelkkien TCP-tason mittausten sijaan.

Kryptografia ja todennus satelliittiyhteyksillä

Satelliittiyhteydet kulkevat avaruuden ja maajärjestelmien kautta, jotka eivät ole taktisen yksikön hallinnassa. Kaupallisilla LEO- ja GEO-palveluilla kulkeva liikenne siirtyy kaupallisten maa-asemien ja vertaisyhteyspisteiden kautta, jotka eivät ole sotilaallisen luokittelun valvonnassa, riippumatta päätelaitetoimittajan mahdollisesti soveltamasta linkkikerroksen salauksesta. Kenttäsovellusten on siksi sovellettava päästä päähän -salausta SATCOM-kerroksen yläpuolella, käsittelemällä satelliittiyhteyttä epäluotettavana siirtovälineenä samoin kuin kaupallista solukkoverkostoa käsitellään.

CoT-liikenteelle TAK Server -yhteyden kautta TLS 1.3 ATAK-asiakkaan ja TAK Serverin välillä tarjoaa luottamuksellisuuden ja palvelimen todennuksen. Molemminpuolinen TLS asiakassertifikaateilla tarjoaa vahvemman todennuksen kuin salasanapohjaiset lähestymistavat ja on oikea arkkitehtuuri taktisiin käyttöönotteihin. Sertifikaattien hallinta satelliittiyhteyksillä esittää käytännöllisen haasteen: sertifikaatin peruutustarkistukset ja OCSP-niittaus vaativat yhteyden, joka ei ehkä ole käytettävissä, ja uusien laitteiden sertifikaattien hankinta vaatii tavoitettavan PKI-päätepisteenä. Ratkaisuja ovat laitteiden sertifikaattien esilataus ennen käyttöönottoa, paikallisen PKI-palvelimen käyttö eteiskomentopaikalla tai offline-sertifikaattivalidointi ennalta ladatun CRL:n avulla. Taktisen viestinnän kryptografiset vaatimukset liittyvät suoraan SATCOM-välitteiseen CoT:iin: kuljetusvälinen muuttuu mutta avaintenhallinnan arkkitehtuuri ei.

Todennustunnisteet ja istuntoavaimet on mitoitettava linkkibudjetin mukaan. TLS-kättely Iridium RUDICS -yhteydellä 22 kbps:lla kuluttaa noin 8 kilotavua dataa ja kestää 3–5 sekuntia, mikä on hyväksyttävää istunnon alussa mutta kohtuutonta, jos sovellus todentaa jokaisen viestin uudelleen. Istunnon jatkaminen TLS-istunnon lippujen avulla vähentää merkittävästi uudelleenyhdistymisen ylikuormaa yhteyksillä, joissa on usein lyhyitä katkoksia: 256 tavun istuntolippu korvaa täyden sertifikaattivaihdon pienentäen uudelleenyhdistymisajan alle yhteen sekuntiin jopa kapealla yhteydellä.

Hybridi-reititys: MANET, SATCOM ja solukkoverkkovarayhteys

Yksikään yhteys ei kata kaikkia operatiivisia skenaarioita, ja kestävin arkkitehtuuri käsittelee SATCOM:a, MANET-verkkoyhteyksiä ja solukkoyhteyksiä hybridi-reititysverkon vertaisina eikä ensisijaisena yhteysvälineenä ja manuaalisena varamenettelynä. Reitityskerros seuraa jokaista liityntäpintaa jatkuvasti pisteyttäen ne yhdistetyillä läpimenon, latenssin, pakettihäviön ja tavu-per-kustannus -mittareilla. Kun aktiivisen liityntäpinnan pisteet laskevat alle kynnyksen – tai kun liityntäpinta raportoi fyysisen kerroksen viasta – reititin ottaa käyttöön seuraavaksi parhaan käytettävissä olevan liityntäpinnan ja muodostaa TAK Server -yhteyden uudelleen uuden polun kautta.

Istunnon jatkuvuusvaatimus on tekninen haaste hybridi-reitityksessä. CoT-tilaus TAK Serverille on tilainen: palvelin seuraa, mikä asiakas on tilannut minkäkin syötteen, ja uuden IP-osoitteen kautta tuleva uudelleenyhdistyminen (joka voi tapahtua siirryttäessä Starlinkistä solukkoverkkooon) on muodostettava tilaus uudelleen vaatimatta operaattorilta manuaalista navigointia asetusvalikon läpi. TAK-asiakaskerroksessa toteutettava jatkuu-uudelleenyhdistämistoiminto – tilauksen tilan paikallinen tallentaminen ja sen toistaminen uudelleenyhdistymisen yhteydessä – ratkaisee tämän. Palvelinpuolen vastine on lyhyt suoja-aika ennen kuin asiakasta pidetään irrotettuna, mikä antaa asiakkaalle aikaa uudelleenyhdistyä uuden yhteyden kautta ilman, että palvelin lähettää lähtöilmoituksen kaikille muille asiakkaille.

Ympäristöissä, joissa kaikki ulkoiset yhteydet ovat samanaikaisesti poissa käytöstä – GPS-eston ja viestiliikenteen häirintäympäristössä, jossa sekä SATCOM että solukkoverkko ovat häirinnän kohteena – MANET-verkko tarjoaa viimeisen varayhteyskerroksen. CoT:n monilähetys UDP:llä verkon sisällä toimii jatkuvasti niin kauan kuin solmujen välillä on vähintään yksi radiopolku, tarjoten paikallista tilannetietoisuutta ryhmälle jopa silloin, kun yhteys ylempiin johtoportaisiin ei ole mahdollinen. Reitysohjelmiston tulisi havaita täydellinen ulkoinen eristyneisyys ja siirtyä nimenomaisesti paikalliseen tilaan sen sijaan, että jatketaan viestien jonouttamista yhteydelle, jonka ei odoteta palautuvan tehtäväikkunan aikana.