Gateway Link 16 la Link 22: traducere și transmitere de mesaje

O imagine aeriană și maritimă de coaliție este rareori transportată pe o singură legătură. Participanții din aviația rapidă și apărarea aeriană își partajează pistele prin Link 16; grupurile maritime de sarcini și participanții de dincolo de orizont le partajează din ce în ce mai mult prin Link 22. În momentul în care ambele comunități trebuie să se vadă reciproc, ceva trebuie să stea între cele două rețele și să mute pistele — primind un mesaj J-series pe o legătură, reexprimându-l pentru cealaltă și retransmițând-ul astfel încât un contact raportat pe oricare parte apare, corect, pe ambele. Acel ceva este un gateway Link 16/Link 22, iar corectarea logicii sale de traducere și transmitere este una dintre cele mai exigente probleme din integrarea legăturilor de date tactice. Acest articol explică modul în care gateway-ul se alătură ambelor rețele, cum traduce între cele două medii J-series și cum transmite pistele fără a le duplica, pune în buclă sau pierde în tăcere.

De ce este nevoie de un gateway

Link 16 și Link 22 nu sunt standarde concurente, ci mai degrabă complementare, iar comparația dintre ele este tratată în detaliu în articolul despre Link 22 față de Link 16. Link 16 este calul de muncă de mare tempo, în linie de vedere, pentru imaginea aeriană: o structură TDMA precis temporizată pe terminale JTIDS/MIDS în banda 960–1215 MHz, livrând actualizări de pistă la câteva secunde participanților cu mișcare rapidă. Link 22 a fost proiectat ca succesorul modern dincolo de linia de vedere al vechiului Link 11, organizând terminalele într-un Super Network pe medii HF și UHF cu acces dinamic la mediu, potrivit pentru forțele maritime dispersate și acoperirea dincolo de orizont.

Deoarece cele două legături deservesc diferite raze de acțiune, medii și populații de platforme, operațiunile reale rulează frecvent ambele simultan. O navă de apărare aeriană pe imaginea aeriană Link 16 și o fregată care raportează prin Link 22 aparțin aceleiași forțe, iar comandanții lor au nevoie de o singură imagine coerentă. Gateway-ul este nodul care face acest lucru posibil: este o unitate pe ambele rețele simultan, iar singurul său scop este să mențină cele două imagini consistente prin traducerea și transmiterea pistelor pe care fiecare parte nu le poate auzi altfel.

Fundația comună: mesajele J-series

Motivul pentru care traducerea cross-link este posibilă este că atât Link 16, cât și Link 22 transportă aceeași familie de mesaje — catalogul J-series definit în familia de standarde MIL-STD-6016. O pistă aeriană J2-series pe Link 16 și o pistă aeriană J2-series pe Link 22 descriu aceeași entitate conceptuală cu aceleași câmpuri conceptuale: poziție, viteză, altitudine, identitate, IFF și număr de pistă. Traducerea este, prin urmare, în mare parte o remapare mai degrabă decât o reformatare completă, ceea ce este o simplificare semnificativă față de crearea unui pod între două familii de mesaje genuini diferite.

„În mare parte o remapare" nu înseamnă „trivial identic". Cele două medii de legătură diferă în trei niveluri pe care gateway-ul trebuie să le reconcilieze. În primul rând, stratul de încadrare și acces la mediu este complet diferit — sloturi de timp TDMA fixe pe Link 16 față de accesul dinamic la mediu Super Network pe Link 22 — astfel încât gateway-ul retransmite fizic, nu doar transmite biți. În al doilea rând, unele codificări de câmpuri, rezoluții sau convenții de unități diferă între definițiile Link 16 și Link 22 ale unor mesaje altfel echivalente, iar acele câmpuri trebuie repachetate, nu copiate. În al treilea rând, mesageria de management al rețelei — mesajele care guvernează participarea, temporizarea și responsabilitatea de raportare — este specifică legăturii, astfel încât gateway-ul trebuie să vorbească nativ dialectul de management al fiecărei părți.

Ce se transferă și ce trebuie repachetat

Câmpurile cu valoare ridicată ale conținutului — latitudine, longitudine, altitudine, curs, viteză, identitate și date IFF — se mapează curat în cazul comun, deoarece descriu realitatea fizică care nu se schimbă odată cu legătura care o transportă. Câmpurile care necesită atenție sunt cele relative la legătură: numărul pistei (atribuit per rețea, într-un spațiu numeric specific rețelei), responsabilitatea de raportare (care unitate „deține" pista pe această rețea) și indicatorul de calitate sau încredere a pistei (pe care fuziunea downstream îl folosește pentru a pondera pista). Acestea nu pot fi copiate verbatim; trebuie rederivate pentru rețeaua de destinație, ceea ce este exact locul în care apar cele mai multe erori de transmitere.

Alăturarea ambelor rețele și alinierea temporală

Înainte ca o singură pistă să poată fi transmisă, gateway-ul trebuie să fie un participant sănătos pe ambele rețele. Pe partea Link 16, aceasta înseamnă un terminal de clasa MIDS, un set de sloturi TDMA atribuite pentru transmitere, cheierea crypto corectă și sincronizare strânsă la referința de timp a rețelei. Pe partea Link 22 înseamnă un terminal Link 22 acreditat alăturat Super Network-ului, cu propria sa cheierea și propria sa temporizare a rețelei.

Alinierea temporală nu este o formalitate. Fiecare pistă J-series este semnificativă numai în raport cu un moment al măsurătorii, iar o imagine fuzionată corelează pistele din mai multe surse comparând stările lor marcate temporal. Dacă gateway-ul este slab sincronizat pe oricare parte, pistele pe care le injectează vor fi marcate temporal incorect față de pistele native pe rețeaua receptoare, iar stratul de fuziune receptor le va respinge fie ca vechi, fie, mai rău, le va corela greșit. Gateway-ul trebuie să disciplineze ceasul la referința de timp a rețelei Link 16 și să se alinieze la temporizarea rețelei Link 22, și trebuie să marcheze temporal fiecare pistă pe care o transmite cu un timp consistent cu referința rețelei de destinație, nu cu propriul ceas liber.

Pipeline-ul de traducere

În interiorul gateway-ului, fiecare pistă transmisă trece printr-un pipeline scurt și bine definit. Decodare: mesajul J-series primit este decodat utilizând decodoare generate programatic din tabelele de câmpuri MIL-STD-6016 — aceeași disciplină care se aplică oricărui consumator J-series, deoarece aritmetica bit-câmp codificată manual și pașii de cuantizare produc erori subtile de offset care apar luni mai târziu ca piste deplasate. Validare: fiecare câmp decodat este verificat față de intervalul său fizic; o poziție în afara pământului, o rază oblică negativă sau o viteză imposibilă indică un mesaj sursă malformat care trebuie înregistrat și eliminat, nu transmis. Mapare: starea entității validate este tradusă în mesajul J-series al legăturii de destinație, copiind câmpurile care se mapează direct și repachetând câmpurile a căror codificare diferă. Ștampilare și punere în coadă: mesajului i se dă un număr de pistă de rețea de destinație și responsabilitatea de raportare a gateway-ului, apoi este pus în coadă pentru transmitere la prima oportunitate de acces la mediu disponibilă.

Pe hardware modern, lucrul de decodare-mapare-codare costă doar câteva milisecunde cifră unică per mesaj; gateway-ul nu este limitat de calcul. Latența reală se află în intervalul coadă-la-transmitere, care este guvernat în întregime de accesul la mediu al legăturii de destinație — așteptarea sloturilor TDMA ale gateway-ului pe Link 16 sau a oportunității sale de acces la mediu pe Link 22.

Transmitere fără duplicare sau bucle

Cea mai dificilă problemă de corectitudine în orice gateway de transmitere este prevenirea duplicării, înmulțirii sau alimentării unei piste într-o buclă infinită. Trei mecanisme lucrează împreună pentru a preveni acest lucru.

Tabelul de transmitere. Gateway-ul menține un tabel indexat după unitatea de origine și numărul de pistă sursă, mapând fiecare pistă sursă la numărul de pistă de destinație care i-a fost atribuit. Când aceeași pistă sursă se actualizează, gateway-ul reutilizează același număr de pistă de destinație, astfel încât imaginea receptoare vede o singură pistă continuă în loc de o nouă pistă per actualizare. Această mapare stabilă este coloana vertebrală a transmiterii curate.

Rescrierea responsabilității de raportare. Fiecare pistă pe care gateway-ul o injectează într-o rețea este ștampilată cu gateway-ul ca unitate raportoare, nu reporterul original. Aceasta este ceea ce permite gateway-ului să își recunoască propriul output: când o pistă pe care a transmis-o pe Link 22 este auzită ulterior revenind spre Link 16, gateway-ul vede propria sa responsabilitate de raportare pe mesajul primit și suprimă re-transmiterea ei. Fără această regulă, două gateway-uri — sau chiar un singur gateway pe o topologie reflectivă — vor înmulți pistele fără limită.

Corelarea de identitate și cinematică. O singură aeronavă sau navă fizică poate apărea independent pe ambele legături dacă este auzită nativ de participanți pe fiecare. Dacă gateway-ul ar transmite naiv ambele, imaginea fuzionată ar arăta doi markeri pentru o entitate. Corelarea prin identitate Mode 5/Mode S, unde este disponibilă, le unește imediat într-o singură pistă; unde nu există o cheie de identitate comună, corelarea cinematică testează dacă două piste ar putea fi aceeași entitate pe baza poziției și vitezei consistente. Această corelare este aceeași disciplină de fuziune utilizată ori de câte ori mai multe surse alimentează o imagine, și este tratată mai larg în articolul despre standardele de interoperabilitate NATO.

Managementul numerelor de pistă între spații numerice

Link 16 identifică pistele printr-un număr de pistă octal de 5 cifre atribuit de unitatea raportoare, iar Link 22 are propriul său schema de numerotare a pistelor. Gateway-ul acoperă, prin urmare, două spații numerice distincte și trebuie să aloce numerele de pistă de destinație din propriul bloc alocat pe fiecare rețea, menținând în același timp o identitate stabilă a pistei interne care supraviețuiește pe ambele. Modelul recomandat este același utilizat în orice imagine operațională comună multi-rețea: păstrați un UUID de pistă intern stabil pentru fuziune, prezentați numărul de pistă operațional semnificativ per rețea pentru afișare și nu lăsați niciodată o coliziune de număr de pistă pe o rețea să elimine sau să îmbine două entități distincte. Conectarea a două rețele anterior separate este declanșatorul clasic al coliziunilor, iar gateway-ul trebuie să le rezolve fără a pierde piste din nicio imagine.

Clasificare, cheierea și ce deține o echipă software

Un gateway traversează limitele criptografice și de clasificare prin design. Fiecare legătură transportă trafic clasificat cheiat prin criptografie acreditată, iar gateway-ul deține material de cheierea pentru ambele. Software-ul de traducere nu slăbește acest lucru — operează pe conținut J-series deja decriptat în interiorul limitei acreditate — dar programul trebuie să se asigure că gazda gateway, stocarea sa și orice element cross-domain sunt acreditate la clasificarea datelor. Scurgerile printr-un gateway de legătură de date tactice sunt o cauză recurentă de incidente cross-domain, iar echipa de inginerie deține responsabilitatea de a face calea de date auditabilă.

Împărțirea muncii merită enunțată clar. Logica de traducere, transmitere, corelare și management al pistelor este inginerie software obișnuită, solicitantă dar realizabilă de o echipă capabilă. Piesele restricționate sunt terminalele acreditate (de clasa MIDS pentru Link 16, terminale Link 22 acreditate pentru Link 22), cheierea națională crypto și proiectarea rețelei care alocă gateway-ului sloturile și blocurile numerice. Acestea sunt aspecte de program și autoritate națională, interfațate printr-un procesor de legătură de date tactice și interfețe standard gazdă — același model de acreditare care guvernează standardele pe partea terestră, cum ar fi MIP4-IES.

Realizat corect, gateway-ul este invizibil: un contact maritim pe Link 22 apare pur și simplu pe imaginea aeriană Link 16, iar o pistă de avion rapid pe Link 16 apare pur și simplu pentru forța maritimă dincolo de orizont, fiecare cu identitatea corectă, eticheta temporală corectă și exact un marker.