Taktinen mesh-verkko, joka toimii varuskunnassa, on ratkaistu ongelma. Vaikea kysymys on mitä tapahtuu kun vastustaja alkaa häiritä, kun reletsolmut tuhoutuvat ja kun joukot siirtyvät maastoon joka katkaisee radiolinjat. Sotilaallisten mesh-verkkojen vikasietoisuus on insinöörityön ala, jossa MANET-infrastruktuuri suunnitellaan heikkenemään hallitusti — menettäen ensin ei-kriittisen liikenteen, ohjaten automaattisesti kuolleiden solmujen ympäri ja palautuen ilman operaattorin toimenpiteitä kun olosuhteet paranevat.
TAK-pohjaisilla yhteisillä operatiivisilla kuvilla toimiville ohjelmistotiimeille vikasietoisuus ei ole radiomyyjän ongelma. Jokainen arkkitehtuuripäätös — reititysprotokolla, store-and-forward -puskurin koko, topologiasuunnittelu, valvonnan instrumentointi — määrää pitävätkö TAK-paikat virtaamassa verkkorasituksessa vai sammuuko COP juuri sillä hetkellä kun komentajat tarvitsevat sitä eniten.
Uhkamalli: mikä todella heikentää taktista mesh-verkkoa
Ennen vikasietoisuuden suunnittelua tarvitaan rakenteellinen uhkamalli. Neljä heikentymiskategoriaa ohjaavat lähes kaikkia vikasietoisten MANET-suunnittelupäätösten tekemistä.
Pistehäirintä kohdistuu mesh-radion käyttämään tiettyyn taajuuteen tai kanavaan. Se on vastustajalle energiatehokkain häirintatekniikka — kapeakaistainen lähetin voi saturoida yksittäisen kanavan suhteellisen vaatimattomalla teholla. Pistehäirintä torjutaan tehokkaasti taajuushyppelyllä, koska häiritsijä hyökkää mesh-radioon vain sen kanavan käyttöajan murto-osalla.
Pyyhkäisyhäirintä siirtää häiritsijää taajuuskaistan yli pysähtyen lyhyeksi aikaa kullekin kanavalle. Hitaasti hyppivää radiota vastaan pyyhkäisyhäirintä voi osua jokaiselle kanavalle ennen kuin radio siirtyy pois siltä. Nopeasti hyppivien sotilaallisten aaltomuotojen, jotka toimivat sadoissa hypyissä sekunnissa, kohdalla kanavakohtainen viipymisaika putoaa alle symbolikeston ja häirinnän tehokkuus romahtaa.
Sulkuhäirintä täyttää laajan taajuuskaistan samanaikaisesti vaatien merkittävästi enemmän lähetystehoa, mutta kykenee heikentämään kaikki kanavat kerralla. Se on havaittavissa (esiintyy kohinatason nousuna koko kaistalla) ja vaatii suuria, energiaa kuluttavia lähettijöitä — mikä tekee siitä vastustajan kyvyn, jolla on havaittava logistinen signatuuri. Sulkuhäirintä on skenaario, jota pelkät taajuushypyt eivät voi täysin voittaa; se vaatii solmujen fyysistä hajottamista häiritsijän tehokkaan säteen sisällä olevan mesh-osuuden vähentämiseksi.
Reaktiivinen häirintä kuuntelee lähetystä ja vastaa välittömästi häirintäpulssilla. Se on tehokkain häirintatekniikka — häiritään vain kun lähetys havaitaan — ja vaikein torjua, koska kiinteät hyppykuviot voidaan oppia. Reaktiivisen häirinnän torjuminen vaatii satunnaistettuja hyppysekvenssejä TRANSEC-suojauksella ja lähetysten ajallista hajottamista.
Elektronisten uhkien lisäksi: solmujen tuhoaminen (reletlaitteisto tuhottu suoralla tai epäsuoralla tulella) on tilastollisesti yleisin mesh-verkon heikkenemisen syy aktiivisissa konflikteissa. Maastomaskaus — joukot astuvat rakennuksiin, ylittävät harjanteet, liikkuvat tiheässä kaupunkirakenteessa — tuottaa tilapäisiä jakaumia, jotka muistuttavat reititysprotokollien näkökulmasta solmujen tuhoutumista. Erottaminen jakautuneen-mutta-elävän solmun ja tuhotun solmun välillä määrää yrittääkö mesh uudelleenyhdistymistä vai reitittääkö se pysyvästi uudelleen.
MANET-reititysprotokollat rasituksessa: OLSR vs BATMAN vs AODV
Reititysprotokollien käyttäytyminen solmukadon yhteydessä on yksi tärkeimmistä vikasietoisuusmuuttujista, ja protokollien väliset erot ovat riittävän suuria ollakseen operatiivisesti merkittäviä.
OLSR (Optimized Link State Routing, RFC 3626 / OLSRv2 RFC 7181) on proaktiivinen: jokainen solmu ylläpitää täydellistä topologiakarttaa, jota HELLO- ja TC-viestit (Topology Control) päivittävät jatkuvasti. Solmun epäonnistuessa naapurisolmut havaitsevat HELLO-viestien puuttumisen naapurin pidätysajan sisällä ja poistavat linkin topologiataulukoistaan. TC-propagointi jakaa päivitetyn topologian mesh-verkon läpi. Koska jokainen solmu tuntee jo täydellisen topologian, vaihtoehtoisen reitin laskeminen on välitöntä topologiataulukon päivityksen jälkeen. 20 solmun mesh-verkossa oletusarvo-OLSR-ajastimilla (hello-intervalli 2s, naapurin pidätysaika 6s) reitin konvergenssi solmukadon jälkeen kestää 4–8 sekuntia.
BATMAN (Better Approach To Mobile Adhoc Networking) on myös proaktiivinen, mutta jakaa reititystiedot eri tavoin. Jokainen solmu tallentaa vain parhaan seuraavan hypyn kohti jokaista määränpäätä, joka johdetaan Originator Message (OGM) -vastaanottolaadusta. Solmun epäonnistuttua naapurisolmut lakkaavat vastaanottamasta sen OGM-viestejä; parhaan-seuraavan-hypyn tietueet kyseiseen kohteeseen vanhenevat ja korvataan seuraavaksi parhaalla polulla kun OGM-viestejä kertyy muista suunnista. Konvergenssi 20 solmun verkossa kestää 5–10 sekuntia oletusasetuksilla.
AODV (Ad-hoc On-Demand Distance Vector) on reaktiivinen: se löytää reitit vain kun paketti on lähetettävä. Tämä eliminoi proaktiivisen ohjausliikenteen kokonaan, mutta lisää reitin löytämisviiveen (tyypillisesti 1–3 sekuntia pyyntö/vastaus-syklille 10-hypyn verkossa) jokaisella uudella virralla. TAK-sijaintiraportoinnille — jossa jokainen CoT on käytännössä uusi lyhyt virta — AODV:n reitin löytämisen ylikuorma kertyy merkittäväksi toimituslatenssiksi. AODV on harvoin oikea valinta vikasietoiselle TAK-infrastruktuurille.
Käytännön ohjeistus: Komppanian tason TAK mesh -verkoille (enintään 50 solmua) OLSR virittetyillä hello-intervalleilla tarjoaa parhaan konvergenssi-kuorma-suhteen. Pataljoonan tason käyttöönotoille (50–200 solmua) BATMANin pienempi ohjauksen ylikuorma on suositeltavampi. Kummassakin tapauksessa mittaa konvergenssiaikaa empiirisesti erityisellä radiolaitteistollasi ennen hyväksymiskriteerien asettamista — toimittajien ilmoittamat konvergenssiajat mitataan usein rajoittamattomilla langallisilla testilaitteistoilla eikä kaistanleveydeltään rajoitetuilla taktisilla radioilla.
Taajuushyppely ja hajaspektri: miten FHSS/DSSS vaikeuttaa häirintää
Frequency Hopping Spread Spectrum (FHSS) vaihtaa lähetystaajuutta monta kertaa sekunnissa kaikkien synkronoitujen solmujen jakaman pseudosatunnaisen jakson mukaan. Yhdelle kanavalle kohdistuvalle pistehäiritsijälle FHSS tarkoittaa, että vain murto-osa 1/N kaikista lähetyksistä (N on hyppykanavien lukumäärä) tulee häirityksi. 50 kanavan välillä hyppelevä radio antaa pistehäiritsijälle vain 2% osuma-asteen per lähetys.
Avainparametri on hyppynopeus suhteessa symbolikestoon. Sotilasradiot toimivat sadoissa tai tuhansissa hypyissä sekunnissa. 1 000 hypyssä/sekunti 1ms symboleilla radio on kullakin kanavalla enintään yhden symbolin verran per hyppykäynti. Pyyhkäisyhäiritsijän on viivyttävä riittävän kauan kullakin kanavalla koko symbolin sieppaamiseksi — 1 000 hypyssä/sekunnissa häiritsijän on pyyhkäistävä 1 000 kanavaa/sekunnissa kun kullakin kanavalla on 1ms signaalia. Tämä on operatiivisesti erittäin vaikeaa ilman hyppysekvenssin tuntemista.
Direct Sequence Spread Spectrum (DSSS) ottaa erilaisen lähestymistavan: taajuushyppelyn sijaan datasignaali kerrotaan suurnopeuisella pseudosatunnaisella koodilla, joka levittää sen laajalle kaistanleveydelle. Prosessointihyöty — levitetyn kaistanleveyden suhde dataan — määrää häirintämarginaalin. Radio, jolla on 20 dB prosessointihyöty, voi vastaanottaa oikein vaikka häiritsijä olisi 100× vahvempi kuin haluttu signaali samalla kaistalla.
TAK-kuljetusintegraatiolle: sekä FHSS että DSSS toteutetaan kokonaan radion laitteistossa ja firmware:ssa. TAK Server, ATAK ja WinTAK kommunikoivat radion kanssa standardin IP-rajapinnan (Ethernet tai USB) kautta eivätkä ole tietoisia hajaspektrikerroksesta. Mesh-verkossa toimivat sovellukset eivät vaadi muutoksia hyötyäkseen FHSS/DSSS-suojauksesta — vikasietoisuus on sovellustasolla läpinäkyvää.
Ainoa sovellustason huoli on synkronointi: FHSS-radiot vaativat aikasysynkronointia hyppysekvenssin kohdistuksen ylläpitämiseksi. Jos solmun kello ajautuu merkittävästi, se menettää synkronoinnin mesh-verkon kanssa ja näyttää muille solmuille kuin olisi epäonnistunut. Jokaisen mesh-solmun synkronointitilan valvonta — saatavilla radion hallinta-APIn kautta Silvus StreamCasterissa ja Persistent Systems MPU5:ssa — on olennainen osa vikasietoista mesh-valvontapinoa.
Store-and-forward yhteyskatkosoperaatioille
Mikään mesh-rakenne ei voi taata 100% yhteyttä kiistanalaisessa ympäristössä. Käytännön kysymys on mitä tapahtuu TAK-datalle kun mesh-verkko on jakautunut — kun eteensijoitettu elementti menettää yhteyden TAK Serveriin minuuteiksi tai tunneiksi ennen jakautuman parantumista.
TAK Server -replikointi on päämekanismi pitkien yhteyskatkoksien käsittelyyn. Eteensijoitettu TAK Server -instanssi (toimii kannettavalla tietokoneella tai kovakäyttöisellä laskentasolmulla paikallisen mesh-radion kanssa) ylläpitää omaa CoT-tapahtumien tietokantaa. Kun yhteys ylemmän tason TAK Serveriin katkeaa, eteensijoitettu TAK Server jatkaa CoT:n vastaanottamista ja palvelua kaikille yhdistetyille ATAK/WinTAK-solmuille paikallisessa mesh-segmentissä. Yhteyden palautuessa kaksi TAK Server -instanssia replikoivat tapahtumatietokantansa kaksisuuntaisesti — jokainen katkoksen aikana tuotettu CoT synkronoidaan molemmille puolille.
Tämä arkkitehtuuri tarkoittaa, että eteensijoitetut elementit säilyttävät täydellisen tilannetietoisuuden paikallisesta mesh-segmentistään katkoksen aikana, ja ylempi esikunta saa takaisin eteensijoitetun elementin toiminnan täydellisen historian kun yhteys palautuu. Kriittiset konfiguraatioparametrit ovat: replikointiväli (kuinka usein yhteydessä olevat TAK Serverit vaihtavat tilaa — tyypillisesti 30–60 sekuntia), CoT-vanhenemisaika (kuinka kauan TAK Server säilyttää jäljittämättömän jäljen ennen sen vanhenemista — tulisi asettaa runsaasti, 90–300 sekuntia, yhteyskatkosoperaatioille) ja tapahtumatietokannan säilytysaika.
CoT-viestin puskurointi päätepisteissä käsittelee lyhyemmät yhteyskatkot yksittäisen laitteen tasolla. Kun ATAK- tai WinTAK-laite ei tavoita TAK Serveriä tai mesh-vertaista, se puskuroi lähtevät CoT-viestit paikalliseen jonoon. Yhdistymisen yhteydessä se tyhjentää jonon järjestyksessä. Puskurin mitoittaminen on suunnittelupäätös: 10 minuutin yhteyskatkos 1 CoT/sekunti per laite 20 laitteen verkossa tuottaa 12 000 puskuroitua viestiä, jotka on tyhjennettävä yhdistymisessä ilman äskettäin palautuneen yhteyden ylikuormittamista.
Topologiasuunnittelu: rengas vs tähti vs täysi mesh
Fyysinen topologia — miten reletsolmut on sijoitettu ja yhdistetty — määrää mesh-verkon vikatilat ja takuut TAK-jälkien toimittamisesta.
Tähtitopologia (kaikki solmut reitittävät keskusreleen kautta) on heikoin vikasietoisuusprofiili: napa on yksittäinen vikapiste. Navan tuhoaminen jakaa jokaisen lehtitsolmun samanaikaisesti. Tähtitopologiat syntyvät käytännössä kun yhdellä ajoneuvoasennetulla releellä on hallitseva RF-peitto ja kaikki muut solmut reitittävät oletuksena sen kautta. Tämä malli tulisi arkkitehtuurisesti kieltää miltä tahansa vikasietoisuuskriittiseltä mesh-segmentiltä.
Rengastopologia (solmut yhdistetty silmukaksi) tarjoaa kaksi erillistä polkua minkä tahansa solmuparin välillä — myötäpäivään ja vastapäivään renkaassa. Yksittäisen solmun tai linkin tuhoaminen muuttaa renkaan linjaksi, mutta ei eristä yhtäkään selviytyvää solmua. Rengastopologiat ovat käytännöllisiä lineaarisiin operaatioihin: saattuereitteihin, käytäväetenemisiin, lineaarisiin puolustusasemiin.
Täysi mesh (jokainen solmu yhdistetty kaikkiin tavoitettavissa oleviin naapureihin) tarjoaa maksimaalisen redundanssin — enintään N-1 riippumatonta polkua minkä tahansa parin välillä N-solmun verkossa — mutta on saavutettavissa vain kun kaikki solmut ovat samanaikaisesti radiokantaman sisällä. Pienille, maantieteellisesti tiiviille yksiköille (ryhmä avoimessa maastossa) täysi mesh on saavutettavissa ja tarjoaa parhaan vikasietoisuuden. Joukkuetasolla radioalue ja maasto tekevät täydestä meshista fyysisesti mahdottoman; osittainen mesh suunnitelluilla redundanteilla linkeillä on realistinen tavoite.
Käytännön suunnitteluprosessi: jokaiselle kriittiselle solmulle (TAK Server, komentopaikka, runsasliikenteinen rele) tunnista vähintään kaksi riippumatonta RF-polkua jokaiseen muuhun kriittiseen solmuun, käyttäen erilaisia reletreittejä ja mahdollisuuksien mukaan eri taajuuskaistoja. Dokumentoi suunniteltu topologia verkkokaaviona vikakohtausannotaatioilla.
Virranhallinta: solmujen leposyklit ja aurinkolataus
Vikasietoisuus ja virranhallinta ovat jännitteessä. Akkua säästääkseen sammutettu mesh-solmu vastaa reititysprotokollien näkökulmasta tuhottua solmua. Insinöörityön haaste on kentällä tapahtuvan kestävyyden pidentäminen ilman tarpeettomien jakautumisten aiheuttamista.
Duty-cycling — vuorottelemalla radio-aktiivisia ja -lepoaikoja — voi pidentää akun käyttöikää 2–5-kertaiseksi lepoosuudesta riippuen. 50% käyttösykli (30 sekuntia aktiivinen, 30 sekuntia lepo) noin kaksinkertaistaa akun keston. Rajoitteena on reititysprotokollakonfiguraatio: OLSR:n naapurin pidätysajan on oltava riittävän pitkä, jotta nukkuvat naapurit eivät tule ilmoitetuiksi kuolleiksi ennen heräämistä. 30 sekunnin leposyklin osalta 20 sekunnin hello-intervalli ja 80 sekunnin naapurin pidätysaika estää väärät naapuri-kuollut-ilmoitukset samalla kun todellisilta solmuvirheiltä toipuu 2–3 minuutissa.
TAK-jälkien toimitus duty-cyclingin aikana: nukkuva solmu ei voi vastaanottaa CoT-viestejä lepoaikansa aikana. Vierekkäiset solmut, jotka toimivat releinä, puskuroivat viestit nukkuville naapureille ja toimittavat ne heräämisellä. Tämä edellyttää, että mesh-radion firmware tukee naapuritietoisuutta lepoaikatauluista — ominaisuus, joka on Silvus StreamCasterin firmware:ssa, mutta ei kaikissa commodity MANET -toteutuksissa.
Aurinkolataus kiinteille reletsolmuille eliminoi akun tyhjenemisongelman kiinteän, mahdollisesti kohteeksi otettavan sijaintisignatuurin hinnalla. Harjanteelle tai rakennuksen katolle asennettu aurinkoenergialla toimiva rele voi toimia toistaiseksi, mutta sen kiinteä sijainti ja paneelin visuaalinen signatuuri luovat hyödyntämisriskin. Kentälle sijoitettavien mesh-solmujen akkukemia: litiumrautafosfaatti (LiFePO4) on suositeltavampi kuin litiumkobalttioksidi (LiCoO2) kenttäkäyttöön, koska LiFePO4 on termisesti vakaa laajemmalla lämpötilavälivälillä (−20°C–+60°C käytössä), kestää enemmän lataussyklejä eikä koe termistä karkaamista lävistyksen yhteydessä.
Valvonta ja itseparannus: mesh-verkon tilan esittäminen TAK-operaattoreille
Vikasietoinen mesh-verkko, joka heikkenee hiljaa, on operatiivisesti vaarallinen — komentajat luottavat COP:iin eivätkä välttämättä tiedä sen olevan puutteellinen. Valvontainfrastruktuurin on esitettävä mesh-verkon tila operaattoreille saman TAK-käyttöliittymän kautta, jota he jo käyttävät.
Suositeltu arkkitehtuuri: mesh-valvontademoni toimii jokaisessa TAK Server -solmussa, kyselee radion hallinta-APIa 30 sekunnin välein ja julkaisee CoT-sensorviestejä kun linkkikynnysarvot ylitetään. RSSI alle −85 dBm kriittisellä linkillä laukaisee keltaisen hälytyksen; RSSI alle −95 dBm tai pakettihäviö yli 30% laukaisee punaisen hälytyksen, joka renderöidään TAK-karttakerroksena. Solmun katoaminen (ei hallinta-API-vastausta 3 peräkkäiseen kyselyyn) tuottaa CoT-hälytysmarkerin solmun viimeiseen tunnettuun sijaintiin.
Automaattinen reitin uudelleenlaskenta hoidetaan reititysprotokollalla itsellään (OLSR tai BATMAN) ilman operaattorin osallistumista. Valvontakerroksen tehtävä on vahvistaa, että uudelleenlaskenta on tapahtunut ja vaihtoehtoinen reitti toimii riittävästi — mesh-verkko, joka on reitittänyt epäonnistuneen solmun ympäri, mutta toimii nyt 7-hyppyisellä polulla, jolla on 40% pakettihäviö kullakin hypyllä, on teknisesti yhteydessä, mutta operatiivisesti heikentyneenä ja vaatii operaattorin huomiota.
Jakautumisapahtumien havainnointi on korkein-prioriteetti valvontatoiminto. Jakautuminen — jossa mesh-verkko jakautuu kahteen tai useampaan erilliseen segmenttiin — tarkoittaa, että osa COP:ista on näkymätön toiselle osalle. Havainnointi vaatii valvontaa jakautuman ulkopuolelta: solmu, joka näkee molemmat segmentit (esim. UAV-rele tai satelliittiyhteyden yhdyskäytävä), voi havaita jakautuman havaitsemalla, että tietyt solmutunnukset lakkaavat näkymästä replikointivirrassa.
Kenttätestimetodologia: solmupoistot, RF-injektio ja COP-heikentymisen mittaus
Yksikään vikasietoinen mesh-suunnitelma ei ole validoitu ennen kuin se on testattu realistisissa heikentymistilanteissa. Kenttätestit tulisi noudattaa rakenteellista protokollaa, joka suoritetaan ennen operatiivista käyttöönottoa.
Solmupoistotestit ovat suorin validointi. Sammuta yksittäisiä reletsolmuja yksi kerrallaan täyden TAK COP:in ollessa käynnissä ja mittaa: (1) aika solmun sammuttamisesta OLSR/BATMAN-reitin uudelleenkonvergointiin, (2) aika reitin uudelleenkonvergenssista TAK-jälkien toimittamisen jatkumiseen poistetun solmun kaukaisella puolella, (3) prosenttiosuus CoT-viesteistä, jotka häviävät katkosaikaikkunan aikana. Toista jokaiselle topologian reletsolmulle. Odotusarvot hyvin konfiguroidulle OLSR-mesh-verkolle: konvergenssi 8 sekunnin kuluessa, TAK-toimituksen palautuminen 15 sekunnin kuluessa, viestihäviö alle 5% store-and-forward käytössä.
RF-häirintäinjektio käyttää kalibroitua RF-signaalilähdettä tai laajakaistaista kohinalähdettä häirinnän simulointiin hallituilla tehotasoilla. Testi etenee kolmessa vaiheessa: (1) perusviivamittaus (CoT-toimitusnopeus, RSSI, reititystaulukon vakaus) ennen häirintää, (2) mittaus häirinnän ollessa aktiivisena (samat mittarit injektion aikana), (3) palautumismittaus (aika perustasoon palautumiseen häirinnän poistamisen jälkeen). Dokumentoi häirintätaso, jolla CoT-toimitusnopeus heikkenee alle 80% — tämä on nykyisen konfiguraation häirintämarginaali.
COP-heikentymispisteytys tarjoaa operatiivisen mittarin testituloksille. Määrittele COP-pisteet TAK Serverissä tietyllä hetkellä näkyvien odotettujen jälkien osuutena, laskettuna testaikkunan yli. Pisteet 1,0 tarkoittaa kaikkien jälkien olevan ajankohtaisia; 0,5 tarkoittaa puolten jälkien vanhentuneen tai puuttuvan. Piirrä COP-pisteet ajan mukaan jokaisen testitapahtuman alusta (solmupoisto, häiritsijän aktivointi) heikentymis- ja palautumiskäyrän tuottamiseksi. Heikentymiskäyrän alainen pinta-ala (häviävät jälkiminuutit yhteensä) on tehtävän vaikuttavuusmittari, jota käytetään konfigurointivaihtoehtojen vertailuun.