Un po' di storia
Il 25 agosto 1984 Brian Kantor [WB6CYT][1] presentò il seguente manoscritto all'incontro del Los Angeles Amatuer Packet Radio Group. Vi sono le considerazioni alla base della nascita di AMPRNET decretandone la nascita.
Premesse
La crescita delle comunicazioni digitali nel servizio radioamatoriale negli ultimi anni è stata a dir poco incredibile. Più di ogni altra cosa, la pronta disponibilità di comunicazioni digitali a pacchetto utilizzando sofisticati controllori di pacchetti come i dispositivi Vancouver [VADCG], Tucson [TAPR] e GLB ha introdotto le comunicazioni a pacchetto a molti radioamatori che altrimenti non sarebbero stati coinvolti nelle comunicazioni digitali. Oltre alla funzione di controllori di pacchetti come sofisticati sostituti delle telescriventi meccaniche, forniscono un mezzo per la creazione di sistemi di messaggistica e bacheche consentendo la connessione diretta ai personal computer.
Mentre un certo uso del packet radio è stato fatto sulle bande HF inferiori a 30 MHz a velocità di trasmissione dati inferiori, l'attività maggiore è attualmente su VHF-FM (in particolare 2 metri). Poiché la comunicazione VHF dipendente è limitata (al massimo) a un centinaio di miglia da una stazione domestica all'altra, il numero di stazioni che possono essere contattate tramite packet radio è alquanto limitato.
Poiché le trasmissioni digitali vengono convertite in e da segnali audio utilizzando la tecnologia modem standard, è possibile inviare trasmissioni a pacchetti tramite normali ripetitori vocali. Tuttavia, questa pratica presenta problemi sia tecnici che sociali, che la rendono poco saggia.
Tecnicamente, molti ripetitori vocali hanno caratteristiche di risposta audio che, sebbene non realmente evidenti con le trasmissioni vocali, introducono distorsioni significative che riducono l'affidabilità della ritrasmissione digitale. Inoltre, il codice Morse o gli identificatori vocali, i toni di telemetria della frequenza o dell'intensità del segnale e i segnali acustici di "superamento" possono essere confusi come segnali di pacchetto dai controllori di pacchetti meno sofisticati.
Socialmente, i toni stridenti del modem generati dalle apparecchiature a pacchetto sono estremamente fastidiosi per gli utenti voce, causando disturbi, interferenze e generale disappunto. Inoltre, molti controllori di pacchetti riconoscono solo i toni del modem a pacchetto, quindi non riconoscono che una frequenza è occupata quando è occupata da trasmissioni vocali e possono trasmettere disturbando una conversazione vocale esistente.
I ripetitori digitali, noti come digipeaters, forniscono un mezzo per ritrasmettere automaticamente i segnali dei pacchetti, ma poiché i pacchetti di riconoscimento devono essere restituiti dall'estremità lontana della connessione sul percorso di collegamento possibilmente multi-hop, la velocità effettiva di trasmissione è notevolmente ridotta. Inoltre, attualmente non esiste alcun controllo delle collisioni quando i segnali vengono ripetuti in formato digitale. Pertanto, in caso di collisione di pacchetti, gli attuali digipeater non sono in grado di rilevare la collisione e ritrasmettere il pacchetto distrutto dalla collisione. La stazione originaria deve quindi attendere la mancanza di riconoscimento dall'estremità lontana della connessione e inviare nuovamente il pacchetto. La ripetizione dei pacchetti inviati dalla stazione di origine può benissimo occupare grandi quantità della capacità di trasmissione disponibile di una rete.
La soluzione di rete
Riteniamo che la soluzione a questi problemi risieda in una rete dedicata per le comunicazioni a pacchetto, proprio come le reti a commutazione di pacchetto che spostano regolarmente milioni di caratteri di dati ogni giorno attraverso il paese e in tutto il mondo.
La rete è semplice. Ogni comunità (o area geografica) ha almeno un Packet Network Controller [PNC] che funge da gateway di rete che costituirebbe l'accesso alla rete a pacchetti per quell'area. Queste stazioni funzionerebbero automaticamente, senza operatore umano, e servirebbero a fornire connessioni per gli utenti locali e di rete. Ciascun PNC avrebbe almeno un PNC vicino e potrebbe stabilire connessioni logiche verso e attraverso i PNC adiacenti.
AMPRNET è strutturato come una rete di PNC, ciascuno dei quali ha uno o più PNC vicini a cui può connettersi tramite collegamenti radio. Ciascuno di questi PNC è connesso ad altri PNC e così via, finché tutti i PNC nella rete non sono raggiungibili tramite uno o più hop. Le connessioni tra PNC non adiacenti vengono effettuate facendo in modo che i PNC adiacenti trasmettano i pacchetti tra i due endpoint della connessione logica.
Ogni PNC ha una tabella di instradamento che descrive almeno un percorso verso ogni altro PNC accessibile. Utilizzando questa tabella, è possibile per qualsiasi PNC contattare qualsiasi altro PNC, possibilmente attraverso una serie di salti di relè intermedi. La tabella di instradamento viene creata e aggiornata dinamicamente man mano che la topologia della rete cambia con i nodi che entrano ed escono dal servizio.
La vista posteriore dell'utente
La connessione tramite la rete viene stabilita in due fasi distinte. Innanzitutto, un utente si connette al PNC locale. Abbiamo scelto l'uso del valore ssid (campo di identificazione secondaria della stazione) 14 (quattordici decimali) come designatore riservato per le stazioni PNC, quindi una connessione avviata (ad esempio) da un TNC TAPR potrebbe apparire come
COLLEGARE WB6CYT-14
che ordinerebbe alla tua stazione di connettersi al PNC gestito da WB6CYT. Sullo schermo verrà visualizzato il messaggio "connesso", seguito dal messaggio "rete pronta".
Successivamente, dovrai istruire il PNC a tentare di connettersi alla stazione che desideri chiamare. Per fare ciò è necessario conoscere l'identificativo del PNC che serve la sua zona. Quindi, ad esempio, per contattare Harold Price a Los Angeles, potresti chiedere al PNC di connetterti alla sua stazione a pacchetti tramite uno dei PNC di Los Angeles:
COLLEGARE NK6K@WB6YMH (il -14 è implicito qui)
supponendo che WB6YMH stesse operando con quel PNC. La rete si occuperà di stabilire la connessione e di tutto l'instradamento dei pacchetti necessari. Al termine della conversazione, la disconnessione da una delle due estremità causerà la chiusura anche della connessione virtuale sulla rete. Si noti che le connessioni possono essere interamente locali e coinvolgere solo il PNC locale; ciò fornisce una connessione ripetuta su area locale più affidabile rispetto all'attuale tecnologia digipeater.
Prevediamo che il PNC fornisca anche altri servizi. Tra quelli previsti ci sono
+ Chi è nell'elenco + Stato della rete + Server di data e ora + Monitoraggio della sicurezza del sito
Protocolli di rete
Sebbene esistano molte proposte per stabilire un protocollo standard per il collegamento di stazioni a pacchetto amatoriali, attualmente non esistono risultati sperimentali che dimostrino un chiaro vantaggio per una scelta rispetto ad un'altra.
Il protocollo scelto deve tenere conto di due diversi aspetti della rete. Innanzitutto c'è la questione del trasporto tra i nodi della rete e, in secondo luogo, il formato dei dati trasportati dalla rete. Questi non sono necessariamente risolti dalla stessa risposta.
Il protocollo di trasporto descrive il metodo scelto per trasportare i messaggi tra i nodi della rete. Mentre per una linea fissa sarebbe sufficiente un semplice collegamento seriale ASCII, per i collegamenti radio più comuni si dovrebbe scegliere un mezzo affidabile. Nella nostra ricerca, abbiamo scoperto che l’attuale implementazione del protocollo AX.25 (utilizzato da TAPR, VADCG, GLB e altri) sarebbe utile. Dispone di rilevamento e correzione degli errori, è efficiente e sia il software che l'hardware per il suo utilizzo sono prontamente disponibili. Per questi motivi abbiamo scelto di utilizzare il protocollo AX.25 per la maggior parte dei collegamenti radio nodo-nodo della rete.
Il protocollo di comunicazione AMTOR presenta anche alcune svantaggi netti per i collegamenti che si trovano sulle bande amatoriali HF. Nei casi in cui i collegamenti tra i nodi della rete debbano estendersi per grandi distanze, si potrebbe utilizzare il protocollo AMTOR e riteniamo sia adatto allo scopo.
Il formato dei messaggi trasportati dalla rete è indipendente dal protocollo di trasporto utilizzato. Poiché si prevede che i collegamenti svaniranno e subiranno interferenze e che i nodi falliranno, è saggio utilizzare un protocollo sufficientemente robusto da risolvere molti di questi problemi. Dopo approfondite ricerche in letteratura e considerando la base di software e sistemi già installati, abbiamo scelto il meccanismo Internet TCP/IP per il protocollo dei messaggi [2].
TCP/IP è progettato per funzionare con un sistema di trasporto inaffidabile e le sue prestazioni migliorano quando il sistema di trasporto sottostante è più affidabile. Incorpora meccanismi di riassemblaggio e riordino dei pacchetti in grado di far fronte ai pacchetti persi, ai pacchetti ricevuti fuori ordine e ai pacchetti duplicati. Poiché lo schema di instradamento di rete descritto di seguito ospiterà un nodo guasto instradandolo attorno fintanto che esiste un percorso tra i nodi di rete endpoint di una connessione, è stato un grande vantaggio scegliere il protocollo TCP/IP che utilizzasse correttamente tale funzionalità . _________________________
Riferimenti utili
- ↑ ARDC memorial https://www.ardc.net/in-memoriam-brian-kantor-wb6cyt-1953-2019/
- ↑ Una nota speciale per ringraziare Phil Karn, KA9Q per il suo suggerimento che TCP/IP potesse funzionare su AX.25 - Phil, è stata un'idea brillante e ha risolto un problema di cui discutevamo da qualche tempo