Il packet radio

Attenzione: apre in una nuova finestra. PDFStampaE-mail



PACKET RADIO

Operare in  packet radio consiste nel trasmettere segnali digitali via radio. 
Per far ciò non occorrono apparecchiature particolarmente costose  basta possedere un Personal Computer ed, un TNC (terminal node controller) oppure un modem ed una radio.
In pratica il tnc e il modem sono quei apparecchi¬† che trasformano i dati ricevuti dal Computer in segnali digitali suddividendoli¬† in ‚Äúpacchetti‚Ä̬† e viceversa.¬†
Da questo termine, infatti si chiama anche trasmissione a ‚Äúpacchetti‚ÄĚ.¬†
Il protocollo di comunicazione usato è una versione, rivista  per i nostri scopi,  del protocollo X25 usato in campo professionale, chiamato AX25 dove la A sta per Amateur. 
Le differenze tra i due protocolli stanno:

  1. il campo di indirizzo è stato adattato in modo da accettare il  nominativo radio della stazione operante (CALL);

  2. aggiunta la possibilità di utilizzare un frame del tipo UI (Unnumbere Information),  in pratica pacchetti non numerati, dato che pacchetti sono numerati per dare la possibilità di ripristinare una sequenza inviata.

Ogni pacchetto contiene tutte quelle informazioni necessarie per giungere a destinazione, questa tecnica di trasmissione da la possibilit√† a pi√Ļ stazioni di operare sulla stessa frequenza senza che queste si interferiscono tra di loro.
Ognuno riceve ci√≤ che gli appartiene escludendo il resto praticamente abbiamo pi√Ļ canali logici su di una unica frequenza, e le velocit√† di trasferimento tra due stazione possono essere diverse. Generalmente¬†si usa la connessione con la velocit√† di¬† 1200 baud e 9600 baud¬† ma, con determinati tipi di apparati anche stabilire connessioni con¬† velocit√† di 38k4 baud e superiori.

73 de iw0urg Siro 

Il Protocollo AX25
AX.25 SPECIFICHE DEL PROTOCOLLO
LIVELLO 2

Ricavato da:
"AX.25 link-layer spec." de AK1A;
"AX.25 amteur packet radio link-layer protocol" de WB4JFI.
Traduzione di IW1AYD.

AX.25 link-layer protocol

Questo protocollo e' conforme alle raccomandazioni ISO 3309, 4335  (includendo DAD 1&2) e 6256 high-level data link control (HDLC) e usa della terminologia rintracciabile in questi documenti. Questo protocollo e' anche conforme alla ANSI X3.66, che descrive ADCCP, in modo bilanciato.
Questo protocollo e' scritto per poter lavorare egualmente bene in ambienti radioamatoriali sia half che full duplex.Questo protocollo permette che sia stabilito piu' di un collegamento al livello due (link layer) per apparecchiatura, sempre che questa lo permetta. 
Questo protocollo segue anche, in linea di principio, la raccomandazione CCITT X.25, con eccezioni
per quanto riguarda: estensione campo d' indirizzo; aggiunta delle Unnumbered Information (UI) frame. La maggior parte dei protocolli di link-layer a livello due danno per inteso che la comunicazione avvenga tra una grossa apparecchiatura, detta DCE o Data Circuit-terminating Equipment, collegata a diverse altre piu' piccole, dette DTE o Data Terminating Equipment . Una tale assegnazione di funzioni non e' auspicabile in un mezzo condiviso qual' e' il tipico canale radioamatoriale. AX.25 presuppone che tutti e due le terminazioni della linea siano bilanciate, ovvero elimina entrambe le classi di apparecchiature descritte. AX.25 considera una nuova classe di apparecchiature (devices) i DXE. Devices capaci di svolgere sia i compiti di un DCE che di un DTE in egual misura, bilanciati 

Struttura del pacchetto.

Le trasmissioni a livello due in Packet Radio (d' ora in poi P.R.) sono costituite da piccoli "blocchi", pacchetti (frames). 
Ogni frame e' l' insieme di parti piu' piccole unite in sequenze logiche univoche, detti fields (campi).

Primo bit  trasmesso.
+-----------------------------------------------------------------------+
! Flag ! Address ! Control ! FCS ! Flag !
+-----------------------------------------------------------------------+
! 01111110 ! 112/560 bits ! 8 bits ! 16 bit ! 01111110 !
+-----------------------------------------------------------------------+
Esempio di pacchetto U o S.
+------------------------------------------------------------------------+
!Flag ! Address !Control ! PID ! Info ! FCS ! Flag!
+------------------------------------------------------------------------+
!01111110! 112/560 Bits ! 8 bits ! 8 bits ! N*8 bits ! 16 bits ! 01111110!
+------------------------------------------------------------------------+
Esempio di pacchetto I.

Definizione di campo.

Ogni pacchetto e' formato da piu' campi. Ogni campo, field, e' composto da gruppi di otto bit, octets o bytes, e ha specifiche funzioni.


Flag Field.

Campo Flag. Dato che il P.R. e' un protocollo orientato al bit, l' unico modo per avvertire il corrispondente del termine di un pacchetto e della partenza di un altro, per evitare overrun e perdite di dati, e' l' invio di un campo di delimitazione per l' inizio e la fine di ogni frame. 
Questo campo viene chiamato FLAG field, consiste di un bit a 0 seguito da sei bit a 1 e di nuovo da uno 0, ovvero dal byte: 01111110 (7E esadecimale). 
Come si vedra' di seguito, vi sono dei meccanismi che eseguono il bit stuffing per evitare il ripetersi di questo ottetto "all' interno" di un frame, le uniche volte in cui questa sequenza e' non solo permessa ma valida sono l' inizio e la fine di ogni pacchetto valido. 
Esiste la possibilita' di utilizzare questo segnale come idle (mantenimento della portante modulata dal segnale), infatti il corrispondente ogni volta che termina di decodificare un byte cosi' composto attende il prossimo come inizio valido del pacchetto a seguire. 
Se il prossimo byte sara' di nuovo un flag viene mantenuto lo stato iniziale di attesa della parte utile del pacchetto, questo ciclo puo' esser ripetuto. 
Ecco che quindi viene utilizzato il FLAG iniziale ripetuto piu' volte per dare maggior margine di "assestamento" alle catene RTX analogiche.

Address Field.

Il campo d' indirizzamento, Address, viene usato per conoscere origine e destinazione di ogni singolo frame. Nella raccomandazione CCITT X.25, questo campo e' lungo al massimo un byte. Quindi permette al massimo 256 utilizzatori per ogni canale P.R. livello 2. 
Ancora, siccome alcuni bit di questo campo hanno altri usi, non sono tutti dedicati all' indirizzamento,
questo farebbe cadere il numero di utilizzatori contemporanei al livello di 30 per ogni canale. Entrambe le raccomandazioni HDLC e ADCCP permettono l'estensione del campo d' indirizzamento. Il protocollo amatoriale AX.25 prevede quindi, per comune decisione, l' estensione dell' ADDRESS field per permettere l' inserzione dei nostri nominativi, sia del destinatario (destination) che del mittente (source)in ogni pacchetto. 
Piu' avanti verra' descritto il modo con il quale questo elongamento viene ottenuto.


Control Field.

Il campo di controllo viene usato per identificare il tipo di frame e altri attributi della connessione a livello 2. 
E' lungo un byte.

Campo PID .

Protocol Identifier field: campo identificatore di protocollo. 
E' usato solo nei pacchetti d' informazione, identifica che tipo di livello 3 e' in uso, ammesso che ve ne sia uno. 
La sua decodifica ha questi valori:

M L
S S
B B
xx00xxxx Per usi futuri.
xx01yyyy AX.25 level 3 layer implementato
xx10yyyy AX.25 " " " " " " " "
11110000 Layer 3 non implementato.
11111111 Sequenza di ESCAPE, il prossimo byte sara' di PID.
Dove:
x. indica bit non importanti.
y. indica ogni possibile combinazione.


Information Field.

Campo d' Informazione. Questo e' l' unico campo del pacchetto che contiene le informazioni utili. Il resto dei campi introduce overhead, in quanto non trasporta informazioni degli utilizzatori ma "solo" dati di funzionamento del protocollo. Il field d' Informazione e' valido solo per  tre tipi di pacchetti: I frames, UI, frames e FRMR frames. 
Ovvero:
Information frames; Unnumbered Information frames; FRaMe Rejected frames. 
Il campo I puo' essere lungo sino a 256 bytes, comunque la sua lunghezza deve essere un multiplo pari di bytes, al minimo due bytes. 
Tutti i dati che inseriti all' interno vengono inseriti all' interno dell' I field vengono passati in modo "trasparente" dal mittente al destinatario lungo il link. 
Salvo per l' inserzione di un bit a 0 necessaria per evitare che un FLAG compaia all' interno del campo dati (bit stuffing).


Frame Check Sequence.

Campo di controllo del pacchetto, e' un numero composto espresso in 16 bit e viene calcolato sia dal destinatario che dal mittente di ogni pacchetto. Il mittente lo calcola e lo inserisce nel pacchetto a spedire, il destinatario lo ricalcola (in base ai dati ricevuti) e lo controlla con quello speditogli nel frame. Ha compiti di verifica dell' integrita' del pacchetto dopo la trasmissione attraverso il mezzo, viene calcolato secondo l' algoritmo suggerito nella raccomandazione ISO 3309 (HDLC).


Bit Stuffing.

Per assicurarsi che la sequenza di bits del campo di FLAG non compaia all' interno degli agli campi, questo invaliderebbe il pacchetto, prima che ogni singolo frame venga trasmesso, ne viene eseguita una scansione, con una finestra di cinque bits mobile lungo il pacchetto. Se all' interno della finestra vi sono piu' di cinque bits a 1 viene aggiunto, questo viene scoperto alla letture del quinto bit consecutivo a "1", tra il quinto e il sesto viene aggiunto uno "0". Si elimina cosi' la possibilita' che vi sia in un punto qualsiasi, partendo da un un bit qualsiasi dopo il byte di FLAG, il valore assegnato per il campo FLAG. Il ricevente arrivato al quinto bit consecutivo a "1" salta automaticamente il sesto bit, che sara' lo zero introdotto precedentemente, prima di passare i dati ai"livelli" piu' alti di gestione del pacchetto.


Bit Order of Transmission.

Ordine di trasmissione dei bit. Con l' eccezione dell' FCS (Frame Check Sequence), tutti gli altri campi di ogni pacchetto AX.25 vengono trasmessi partendo dal Least Significant Bit (LSB), bit meno significativo. In accordo con la pratica HDLC il campo FCS vede come primo bit trasmesso il Most Significant Bit, bit piu' significativo.


Frame Abort.

Termine trasmissione pacchetto, forzato. Se un pacchetto deve essere terminato prematuramente, devono essere trasmessi almeno quindici bit  consecutivi a "1", senza bit stuffing.


Invalid Frame.

Pacchetto non valido. Ogni pacchetto piu' corto di 136 bits, o non incluso nei campi di FLAG (un byte con valore binari"011111"), o non composta da byte allineati (bytes incompleti, numero di bits non divisibile per 8 senza resto), verra' considerata invalida da questo livello.


Address Field Encoding.

Codifica del campo d' indirizzo. Il campo d' indirizzo di tutti i pacchetti viene codificato con i nominativi dei radioamatori, sia mittente che destinatario. Se viene usato un ripetitore a livello 2, il suo nominativo sara' riportato sempre nel campo d' indirizzamento. AX.25 segue la forma prevista dal protocollo HDLC per elongare il campo d' indirizzamento, per farvi "entrare" tutti i dati a noi necessari.HDLC, per elongare il campo d' indirizzamento, prevede che il bit meno significativo di ogni byte se settato a "1" indichi che il byte successivo conterra' ancora un dato utile 
d' indirizzamento. Viceversa quando il bit sara' a zero, dara' il termine del campo. Questo bit viene chiamato "extender bit" (bit d' estensione). Per creare spazio all' e.b., i nominativi vengono shiftati di un bit a sinistra (vedi TRACE ON/OFF nella sua tipica visualizzazione a ottanta colonne).


Non-Repeater Address-Field Encoding.

Codifica del campo indirizzo per frame non indirizzato o proveniente tramite un ripetitore.

+--------------------------------------------------------+
! Campo d' Indirizzo !
+--------------------------------------------------------+
! Indirizzo di destinazione ! Indirizzo del mittente !
+--------------------------------------------------------+
! A1 A2 A3 A4 A5 A6 A7 ! A8 A9 A10 A11 A12 A13 A14 !
+--------------------------------------------------------+

Se non viene usato un ripetitore a livello 2 la codifica viene dell' indirizzo e' la seguente: nominativo del mittente, chi spedisce; nominativo del destinatatrio, chi dovra' ricevere il pacchetto. Questi due nominativi sono gli unici necessari per un frame a livello 2, AX.25 link layer. Nel caso di due nominativi del tipo XXNYYY-N, avremo quattordici bytes (il trattino dell' SSID non viene trasmesso ma riaggiunto localmente) da usarsi per l' indirizzamento. Questi quattordici bytes massimi 
d' indirizzamento per il livello 2 sono a loro volta suddivisibili in due sottocampi, indirizzo mittente e indirizzo destinatario, lunghi a loro volta sette bytes ciascuno. L' ordine di trasmissione prevede ,temporalmente, prima il  sottocampo destinatario, poi il sottocampo del mittente; questo per dar agio al decodificante di comprendere, prima della fine di ogni frame, se questo e' indirizzato a lui. Quindi avremo il sottocampo destinatario nei bytes da A1 a A7, seguira' nei bytes da A8 a A14 il sottocampo mittente. 
Entrambi i sottoc. hanno la medesima configurazione, l' ultimo byte, il settimo per il destinatario e il quattordicesimo per il mittente, contengono la codifica per il Secondary Station IDentifier (identificatore secondario di stazione), SSID. Questo permette un uso piu' omogeneo del proprio nominativo per ogni stazione o digipeater o gateway che si intenda installare.


Destination Sub-Field Encoding.

Codifica del sottocampo di destinazione. Data l' eguaglianza di codifica tra i due sottocampi vedremo ora quella relativa al sottoc. destinatario.


+-------------------------------------+
! BYTES ! ASCII ! BIN.DATA ! HEX DATA !
+-------+-------+----------+----------+
! A1 ! I ! 01001001 ! 49 !
! A2 ! W ! 10101110 ! AE !
! A3 ! 1 ! 00110001 ! 31 !
! A4 ! A ! 01000100 ! 41 !
! A5 ! Y ! 01011001 ! 59 !
! A6 ! D ! 01000100 ! 44 !
! A7 ! -SSID ! CRRSSID0 ! nn !
+-------------------------------------+
! MSB 76543210 LSB !
! posizione bit !
+-------------------------------------+

Dove:

1> Il byte A1 e' il primo ad esser trasmesso , il bit 0 inizia la trasmissione (LSB), seguira' fino al bit 7 (MSB). Iniziera' il percorso quindi il bit 0 del byte A2 ... fino al termine.

2> Il bit 0 (LSB) di ogni byte e' il bit di estensione per l' indirizzo HDLC , settato a 0 in ogni byte salvo che nell' ultimo byte utilizzato per il campo d' indirizzamento. Li' sara' settato a uno, per dare il termine del campo, ovvero di tutti i sottocampi usati. 
Vedere paragrafo successivo.

3> I bit marcati "R" sono bit riservati, non usati nel presente protocollo. Utilizzabili in network locali. Vanno posti a 1, se non usati, come visto qui.

4> I caratteri del nominativo devono essere in alfabeto standard ASCII ed unicamente maiuscoli, viene quindi eseguito lo shift di un bit a sinistra per creare spazio al bit di estensione dell' indirizzo. Se il nominativo e' piu' corto dello spazio da occupare, 6 bytes (6 caratteri), viene riempito lo spazio mancante tra la fine del nominativo e SSID (che non viene mosso!) con degli spazi.

5> I bits nel byte riservato all' SSID sono intenzionalmente non caricati con una maschera prefissata. Viene lasciato al singolo il compito di utilizzarlo come meglio aggrada per estendere il protocollo.


Level 2 Repeater Address Field Encoding.

Se un pacchetto e' destinato a viaggiare attraverso uno o piu' digipeaters a livello 2 viene aggiunto un sottocampo d' indirizzamento che conterra' il/i nominativo/i del/i digipeater/s da usarsi. Questo abilita la condivisione di un canale da parte di piu' digi., cosa non possibile, o che comunque creava problemi, con protocolli precedenti. L' ultimo byte del sottocampo d' indirizzo, del mittente, avra' il bit in posizione zero, LSB settato a "1". Questo indichera' che seguono altri sottocampi d' indirizzo.
Allo stesso modo il primo sottocampo d' estensione, contenente il call del primo digipeater, nel caso di piu' digipeater, avra' il bit zero del byte A21 (14+7=21) posto a uno. Questo sempre per indicare che il prossimo byte e' di Extended Address Area (Area d' Estensione d' Indirizzo). Qui di seguito viene data la tabella esplicativa per il terzo sottocampo d' indirizzo. In questo caso il medesimo nominativo, dell' esempio precedente, viene usato come digipeater a livello 2.


+-------------------------------------+
! BYTES ! ASCII ! BIN.DATA ! HEX DATA !
+-------+-------+----------+----------+
! A15 ! I ! 01001001 ! 49 !
! A16 ! W ! 10101110 ! AE !
! A17 ! 1 ! 00110001 ! 31 !
! A18 ! A ! 01000100 ! 41 !
! A19 ! Y ! 01011001 ! 59 !
! A20 ! D ! 01000100 ! 44 !
! A21 ! SSID ! HRRSSID1 ! nn !
+-------------------------------------+
! MSB 76543210 LSB +
! posizione bit !
+-------------------------------------+
(Osservare il byte A21, bit 7 e 0)

Dove:

1> Il byte piu' in alto, A15, viene trasmesso per primo. Di quello e dei bytes successivi viene trasmesso per primo il bit in posizione 0, LSB.
2> Come per i campi d' indirizzo destinatario e mittente il bit in posizione 0 di ogni byte e' il bit che segnala l' estensione del campo d' indirizzamento, e' settato a 0 dappertutto salvo nell' ultimo byte, A21, dove e' a "1" per indicare la continuazione dell' indirizzo nel prossimo byte.

3> I bit denominati R sono sempre riservati.

4> Il bit denominato H, vale "0" se il pacchetto non e' stato ancora ripetuto dal digipeater specificato e "1" viceversa.


Control Field Format.

Formato del campo di controllo. Il campo di controllo e' responsabile dell' identificazione del tipo di pacchetto rappresentato, e' necessario per definire il tipo e l' uso delle informazioni presenti nei pacchetti.Permette il mantenimento del controllo degli eventi di link (collegamento-connessione) tra le stazioni.
La costruzione del campo di controllo di AX.25 e' ripresa dalla raccomandazione CCITT X.25 per operazioni bilanciate (LAPB), con in piu' l' aggiunta di un sottocampo di controllo ulteriore ripreso da ADCCP per permettere trasmissioni circolari e a stazioni non connesse.

Vi sono tre tipi principali di pacchetti in AX.25:
1) Information frame o I frame;
2) Supervisory frame o S frame;
3) Unnumbered frame o U frame .

Rispettivamente, I f. ... pacchetti d' Informazioni, S f. ... pacchetti di Supervisione del protocollo e U f. ... pacchetti d' informazione senza un bersaglio finale specifico. Il formato del control field e' il seguente:

+-------------------------------------+
! TIPO ! BIT CAMPO CONTROLLO !
! PACCHETTO ! M posizione L !
! ! 7 6 5 ! 4 ! 3 2 1 ! 0 !
+-------------+-------+---+-------+---+
! I frame ! N(R) !P/F! N(S) ! 0 !
+-------------+-------+---+-------+---+
! S frame ! N(R) !P/F! S S 0 ! 1 !
+-------------+-------+---+-------+---+
! U frame ! M M M !P/F! M M 1 ! 1 !
+--------------------------------------

Dove:

1> Il bit 0 (LSB) e' il primo trasmesso, il bit 7 e' l' ultimo.

2> N(S) e' il numero progressivo della sequenza di pacchetti trasmessi. Il bit 2 e' il meno significativo (LSB).

3> N(R) e' il numero progressivo della sequenza di pacchetti ricevuti . Il bit 6 e' il meno significativo.

4> S sono i bit usati in modo Supervisor.

5> M sono i bit usati in modo Unnumbered.

6> Il bit P/F e' il sottocampo di Poll/Final. La sua funzione verra' descritta piu' avanti.


Control Field Definitions.

Definizioni del campo di controllo.


Information Frame Control Field

Disposizione del campo di controllo per un pacchetto di tipo Informazione. Tutti i pacchetti di tipo I, ovvero con dati d' utente presenti, hanno il bit 0 del campo di controllo settato a "0". N(S) e' il numero del pacchetto nella sequenza di trasmissione, il numero del pacchetto che viene trasmesso. N(R) e' il numero di pacchetto che ci si aspetta di ricevere (numero ultimo pacchetto ricevuto + 1). La messa in sequenza di questi numeri verra' comunque meglio esposta piu' avanti.

Supervisory Frame Control Field.

Disposizione del campo di controllo per i pacchetti di Supervisione. I pacchetti di tipo S si distinguono per avere il bit 0 del campo di controllo a "1" e il bit 1 a "0". I pacchetti di tipo S permettono lo scambio d'informazioni specifiche al mantenimento del link (connessione, collegamento). Servono quindi per lo scambio di acknoweledge (RR), le richieste di ritrasmissione dei pacchetti di tipo I, piu' in generale sono i messaggi di servizio. Dato che i frame di tipo S non contengono campo dati, le sequenze di conteggio in ricezione e trasmissione non sono affette da questi pacchetti.

Unnumbered Frame Control Field.

Pacchetti d' informazione non numerati. Gli U frame hanno nel campo di controllo entrambi i bit 0 e 1 settati a "0". Sono responsabili dello scambio di alcuni messaggi di controllo al disopra dei compiti dei pacchetti di tipo S. Sono anche responsabili dell' instaurazione e caduta del collegamento (UA). I pacchetti di tipo U sono anche responsabile della ricezione e trasmissione di informazione al di fuori del normale controllo di flusso. I pacchetti di tipo U possono contenere o non contenere il campo dati.


Control Field Parameters.

Parametri del campo di controllo.


Sequence Numbers and Variables

Variabili e numeri di sequenza.A ogni pacchetto di tipo I sara' assegnato un numero in sequenza con gli altri che lo precedono e quelli che lo seguiranno dello stesso tipo (I). Questa numerazione va' da 0 a 7 (sottocampo di 3 bit), questo permette che vi siano fino a sette pacchetti in attesa di essere spediti.

Send State Variable V(S).

Variabile di stato per la trasmissione. La variabile di stato per la trasmissione e' una variabile interna e non viene mai trasmessa al corrispondente. Contiene il numero di sequenza da assegnare al prossimo pacchetto da trasmettere. Questa variabile viene aggiornata alla trasmissione di ogni frame.


Send Sequence Number N(S)

Numero di sequenza in trasmissione. Questo numero e' presente all'interno di ogni campo di controllo dei pacchetti di tipo I. Contiene il numero di sequenza del pacchetto che sta' per essere trasmesso. Giusto un istante prima della effettiva trasmissione di ogni pacchetto di tipo I ,N(S) viene aggiornato al valore di V(S) (che nel frattempo viene riaggiornato).


Receive Status Variable V(R)

Variabile di stato per la ricezione. Questa variabile contiene il numero di sequenza del prossimo pacchetto di tipo I da riceversi (vedi V(S) per la trasmissione). Questa variabile viene aggiornata ogni volta che venga ricevuto il pacchetto voluto, numerato correttamente (ovvero con N(S) trasportato dal pacchetto uguale alla V(R) corrente), senza errori.


Received Sequence Number N(R)

Numero di sequenza ricevuto. Si trova nei pacchetti di tipo I e S. Prima di ogni trasmissione questa variabile viene aggiornata al valore di V(R), viene cosi' resa implicita la conferma positiva a tutti i pacchetti, di tipo I, correttamente ricevuti fino a N(R)-1 incluso.


Poll/Final (P/F) Bit

Il bit di P/F puo' essere utilizzato in tutti i tipi di pacchetti. Viene usato in modo comando (poll, leggi richiesta-ricerca) per richiedere una risposta immediata. Nel pacchetto di risposta a quel comando lo stesso bit avra' il senso di response (leggi risposta, final leggi finale ... termine esecuzione del comando richiesto). Solo una condizione di poll alla volta, per DXE, puo' essere in attesa d' esecuzione remota.


Control Field Encoding.

Codifica del campo di controllo.


Information Frame Control Field

I pacchetti d' informazione, I, sono numerati sequenzialmente come dianzi detto. Questo e' necessario per mantenere traccia e controllo del passaggio di questi pacchetti attraverso i vari "stadi" del link (collegamento). Questo e' il formato del campo di controllo per questo tipo di pacchetti.

Control Field Bits
+-----------------------+
! 7 6 5 ! 4 ! 3 2 1 ! 0 !
+-------+---+-------+---+
! N(R) !P/F! N(S) ! 0 !
+-----------------------+


Supervisory Frame Control Field

Campo di controllo per i pacchetti di supervisione. Questo tipo di pacchetto viene usato in AX.25 solo come risposta a richieste fatte con altri tipi di pacchetti.

+-------------------------------------+
! ! 7 6 5 ! 4 ! 3 2 ! 1 0 !
+-------------+-------+---+-----+-----+
!Receive ready! ! ! ! !
! RR ! N(R) !P/F! 0 1 ! 0 1 !
+-------------+-------+---+-----+-----+
!Re. not Ready! ! ! ! !
! RNR ! N(R) !P/F! 0 1 ! 0 1 !
+-------------+-------+---+-----+-----+
! Reject ! ! ! ! !
! REJ ! N(R) !P/F! 1 0 ! 0 1 !
+-------------------------------------+


Receive Ready (RR) Response

Letteralmente: pronto alla ricezione. Viene usato per i seguenti scopi:

1> Per indicare che chi trasmette RR e' pronto a ricevere pacchetti di tipo I;
2> Per inviare ACK (ackoweledge, letteralmente accordo) ai pacchetti di tipo I fin' ora ricevuti, includendo il frame N(R)-1;

3> Per ridare il via dopo una condizione di RNR allo scambio di dati precedentemente bloccato.

Occorre far notare come lo stato dell' altro componente terminale del link possa essere richiesto settando il bit di poll del sottocampo P/F.


Receive Not Ready (RNR) Response

Risposta di ricezione non possibile. Questo tipo d' indicazione viene usata per indicare al trasmettitore dei pacchetti, di tipo I, che il ricevitore e temporaneamente occupato e non puo' ricevere ancora altri pacchetti. Ai pacchetti fino a N(R)-1 viene dato ACK. Ogni altro pacchetto con numero di sequenza pari a N(R) o superiore, che sia anche gia' "sul" link, non riceve acknoweledge dopo la trasmissione del comando di RNR. La condizione di RNR puo' venir eliminata solo con l' invio di un UA, RR, REJ o di un SABM. Il bit di P/F puo' venir usato in un frame RNR per interrogare lo stato dell' altro partecipante al collegamento.


Reject (REJ) Response.

Responso di rifiuto. Il pacchetto di REJ viene usato per richiedere la ritrasmissione di frames di tipo I al trasmettitore, a partire dal numero N(R). Tutti i pacchetti gia' spediti con numeri di sequenza N(R)-1 o meno ricevono ACK.

Solo una condizione di REJ e' permessa per ognuna delle due direzioni di scambio. La condizione di REJ viene azzerata quando vengono ricevuti tutti i pacchetti di tipo I fino all' ultimo che ha causato l' inizio della condizione.

Come per le altre risposte di supervisione il bit di P/F puo' essere usato nel pacchetto di REJ.


Unnumbered Type Frame.

Pacchetto d' informazione non numerato. Questo tipo di frame puo' essere sia di comando che di risposta. Questo standard segue quanto piu' possibile X.25. L' unica deviazione da quest' ultimo protocollo e' l' aggiunta dei pacchetti non numerati d' informazione (UI) , presi dal protocollo ADCCP.
X.25 e' strutturato per lavorare in un ambiente full-duplex con una macchina principale (DCE) e potenzialmente piu' utilizzatori (DTE).

L' ambiente radioamatoriale P.R. differisce sostanzialmente da questo modello, almeno per quanto riguarda i due elementi citati. Non solo in campo amatoriale esistono reti half-duplex, ma solo in campo radioamatoriale esiste la specifica esigenza di condivisione delle risorse di un singolo canale da parte di apparecchiature "duali", DTE/DCE. Per questa ragione molti radioamatori hanno optato per uno standard che piu' facilmente di X.25 si adattasse alle nostre specifiche esigenze. X.25 e'stata facilmente modificata per raggiungere i nostri scopi.

Tipologia dei pacchetti UI.

+-------------------------------------+
!DESCRIZIONE! ! ORDINE DEI BIT !
!CAMPO DI !TIPO! !
!CONTROLLO ! ! 7 6 5 4 3 2 1 0 !
+-----------+----+--------------------+
!Set Async. ! ! !
!Balance !CMD ! 0 0 1 P 1 1 1 1 !
!Mode-SABM ! ! !
+-----------+----+--------------------+
!Disconnect ! ! !
! DISC !CMD ! 0 1 0 P 0 0 1 1 !
! ! ! !
+-----------+----+--------------------+
!Disconn.ed ! ! !
!Mode !RES ! 0 0 0 P/F 1 1 1 1 !
! DM ! ! !
+-----------+----+--------------------+
!Unnumberd ! ! !
!Acknowel.ge!RES ! 0 1 1 F 0 0 1 1 !
! UA ! ! !
+-----------+----+--------------------+
!Frame ! ! !
!Reject !RES ! 1 0 0 F 0 1 1 1 !
! FRMR ! ! !
+-----------+----+--------------------+
!Unnumbered ! ! !
!Information!R/C ! 0 0 0 P/F 0 0 1 1 !
! UI ! ! !
+-------------------------------------+
Tipi di campi di controllo per i pacchetti U.


Set Asynchronous Balanced Mode (SABM) Command.

Questo comando e' usato per porre due stazioni in collegamento asincrono in modo bilanciato, entrambi agiscono l' uno per l' altro come DCE e DTE. In questo tipo di pacchetto non e' permesso il campo Informazione. Ogni pacchetto "sul" link al momento della ricezione di questo comando resta privo di ACK. (SABM letteralmente ... comando per il passaggio in modo asincrono bilanciato).


Disconnect (DISC) Command.

Comando di disconnessione. E' usato per porre fine al collegamento, link, tra due stazioni. Non e' permesso il campo I, ogni pacchetto in attesa di  ACK restera' tale.


Disconnected mode (DM) Response.

Risposta di disconnessione. Viene inviato da ogni stazione che riceva un messaggio indirizzato a se stessa diverso da una SABM, mentre si trova disconnessa. Inviato per richiedere un comando di set del modo, o per indicare che al momento non c'e' possibilita' di connessione (BUSY). Il frame di DM non puo' avere campo d' Informazione. Una stazione che si trovi in uno dei due stati DCE o DTE rispondera' con un DM a ogni pacchetto che non sia un SABM con il bit P/F settato a "1".


Unnumbered Acknoweledge (UA) Response.
Risposta di conferma non numerata. UA viene trasmesso per dare l'accettazione di un pacchetto comandi di tipo U. Un comando ricevuto non viene processato prima dell' invio del frame di UA in risposta. Il campo I non e' permesso.


Frame Reject (FRMR) Response.

Risposta di rifiuto. Viene trasmessa per riportare all' altro lato (end) del collegamento (link) che per qualche ragione l' esecuzione di un comando o la ricezione di un pacchetto di tipo I, non puo' aver luogo e che l' errore non e' recuperabile reinviando di nuovo il frame che ha dato il via alla condizione. Questo succede, tipicamente, quando un pacchetto, senza errori di FCS, e' stato ricevuto nelle seguenti condizioni:

1> La ricezione di un pacchetto con campi invalidi o con comandi/responsi non implementati. 
2> La ricezione di pacchetto d' informazione con un campo dati piu' lungo del dovuto.
3> La ricezione di un pacchetto con N(R) fuori sequenza. Per esempio nel caso che un pacchetto che ha gia' avuto ACK venga ritrasmesso o N(R) sia comunque fuori sequenza rispetto a quanto atteso.
4> La ricezione di un pacchetto con il campo d' Informazione nonostante non sia del tipo atto a possederlo o la ricezione non  corretta, per lunghezza, di pacchetti di tipo U o S.

Quando viene inviato un pacchetto FRMR, viene aggiunto un campo d'informazione specifico. Questo campo, tre bytes, viene riempito con informazioni riguardanti la causa dell' FRMR. Il suo contenuto viene esposto qui di seguito:


+-------------------------------------------------+
! Information Field Bit !
!2 2 2 2 1 1 1 1 1 1 1 1 1 1 !
!3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 !
+--------+-+-+-+-+-----+-+-----+-+----------------+
! ! ! ! ! ! ! ! ! !Rejected Frame !
!0 0 0 0 !Z!Y!X!W! V(R)!C! V(S)!0! !
! ! ! ! ! ! ! ! ! !Control Field !
+-------------------------------------------------+

FRMR Frame Information Field.

Dove:
1> Il campo di controllo del frame rifiutato e' tolto pari pari dal pacchetto che ha provocato l' inizio della sequenza e qui inserito.
2> V(S) e' la variabile di sequenza per la trasmissione del dispositivo che invia FRMR, il bit 10 e' il LSB.
3> V(R) e' la variabile di sequenza per la ricezione del dispositivo che invia FRMR, il bit 14 e' il MSB.
4> Se W e' alto, "1", il campo di controllo ricevuto era invalido o non implementato.
5> Se X e' alto, "1", il pacchetto che ha provocato FRMR aveva un campo Informazione mentre non era permesso perche' era di tipo U o S. Il bit W deve essere settato in aggiunta a X.
6> Se Y e' settato a "1", il campo Informazione era piu' lungo di quanto permesso dal device ricevente che sta' riportando la condizione (quello che ha inviato FRMR appunto).
7> Se Z e' settato a "1", il campo di controllo ricevuto contiene un numero N(R) di sequenza invalido (per chi lo sta' ricevendo).
8> I bit 8, e da 20 a 23 sono settati a 0. Il bit 12 e' settato a "0" se il pacchetto ricevuto era un comando, a "1" se era un responso.


Unnumbered Information (UI) Frame.

Pacchetto d' informazione non numerato. Viene usato per trasferire informazioni tra i due lati del collegamento al difuori del normale controllo di scambio dati. Questo permette a campi d' informazione di "viaggiare" avanti e indietro attraverso il link non usando il normale controllo di flusso sequenziale . Salvo che, essendo questi frame non numerati non possono ricevere ACK. Se uno di questi pacchetti viene perduto non puo' essere recuperato in nessun modo.
Questo tipo di frame non e' previsto dal protocollo X.25, la sua struttura aggiunta viene ripresa da ADCCP per permettere il passaggio di informazioni "sul" link evitando d' interferire con i livelli superiori.


Link Error Recovery.

Vi sono diversi meccanismi, all' interno del protocollo, per recuperare gli errori dovuti al collegamento senza provocarne la caduta. Questi malfunzionamenti possono avvenire sia per problemi di DTE/DCE, da entrambi i lati, sia per problemi del mezzo/mezzi usati per stabilire il link.

Invalid Frame or FCS Error.

Se viene ricevuto un pacchetto invalido o con FCS invalido (Frame Check Sequence), viene "scaricata" (non visualizzata) e nessun altra azione viene intrapresa.

Device Busy Condition.

Condizione di apparecchiatura occupata. Quando un DTE/DCE diventa temporaneamente occupato per qualsiasi azione richiesta dall' altro DCE/DTE, inviera' un pacchetto RNR. Questo dara' all' altro lato del link l'informazione che il lato opposto del collegamento non ha la possibilita' di trattare altre frames di tipo I. Questo stato viene resettato, da chi lo ha iniziato, con un UA, RR, REJ o con un comando di SABM.

Send Sequence Number Error.

Se il numero di sequenza, N(S), trasportato da un frame di tipo I, anche se privo di altri tipi di errore non e' quello atteso, dopo la comparazione con la variabile di ricezione V(R), e occorso un errore nella sequenza di trasmissione. Il campo d' Informazione viene scaricato. Il ricevitore non dara' l' ACK per questo frame o ogni altro frame fino a che N(R) ricevuto non sara' pari a V(R) atteso. Il campo(i) di controllo del frame(s) di tipo I errato(i) viene(vengono) decodificato(i). Le funzioni di supervisione vengono eseguite, cio' fa' quindi cambiare lo stato del bit P/F nei frames ritrasmessi.


Rejected (REJ) Error Recovery.

Recupero dell' errore di rifiuto. REJ viene usato per richiedere la ritrasmissione di pacchetti, tipo I, a seguire un errore di sequenza nella numerazione dei frames. Solo una condizione di REJ puo' esistere per ognuno dei due lati, volta per volta. La condizione di REJ viene azzerata quando viene ricevuto il pacchetto I richiesto. Un dispositivo che riceva il comando di REJ azzerera' l' errore ritrasmettendo il frame di tipo I indicato con N(R) nel pacchetto di REJ.


Time-out Error Recovery.

Quando un pacchetto viene "perso" durate il suo viaggio nel mezzo, sia esso un singolo frame o l' ultimo di un gruppo, non c'e' modo di scoprire e riparare immediatamente questo errore. Il ricevitore si accorge di mancanze nei gruppi di dati ricevuti solo per differenze nei numeri di sequenza dei frames che lo trasportano e vengono ricevuti correttamente. Se il frame non ascoltato non ha frames successivi bisogna attendere il primo frame trasmesso successivamente per avere notizia dell' errore di sequenza. Per migliorare questa situazione il trasmettitore e' stato dotato di un timer (contatore) che da' l' indicazione "da quanto e' stato trasmesso l' ultimopacchetto": T1. Viene fatto partire al momento della trasmissione di ogni pacchetto e fermato all' arrivo dell' acknoweledge (conferma di avvenuta ricezione) relativo a quel pacchetto. Se l' intervallo tra la trasmissione del pacchetto e la ricezione dell' ACK supera un certo ammontare di tempo, si ha la ritrasmissione del pacchetto che non ha ricevuto conferma (rif. FRACK). Il timer, che si incrementa in funzione del tempo trascorso, viene comparato con un parametro caricato a priori. Questo parametro variera' in funzione del mezzo di trasmissione. Quanto visto occorre solo durante la fase di trasferimento informazioni tra un DXE e l' altro. Nella situazione di due DXE connessi, basso livello di scambio informazioni, viene mantenuta l' integrita' del link attraverso l' invio di pacchetti. Questa operazione si chiama polling. Il momento in cui inviare un pacchetto avente questa funzione viene deciso dallo scadere del timer T3. Quando T3 va' in time-out viene inviato un pacchetto RR o RNR con il bit di poll settato, comando, e iniziata la procedura di Waiting Ackoweledge (attesa ACK).


Rejection Error.

Errore di rifiuto. Questo tipo di errore puo' verificarsi quando un pacchetto error-free (senza errori) ha uno dei problemi seguenti: 
1> Campi di controllo o di risposta invalidi.
2> Formato del pacchetto invalido.
3> N(R) invalido, perche' non atteso di quel valore.
4) Il campo d' Informazione e' piu' lungo di quanto il device accetti.

Quando avviene questo errore, non vengono piu' accettati pacchetti di  tipo I (salvo per l' utilizzo del bit P/F) fino a che non venga risolta la situazione. La condizione d' errore e riportata al corrispondente trasmettendogli un pacchetto di risposta FRMR.


Primary/Secondary versus Balanced Operation.

Comparazione tra operazioni bilanciate e non. Esistono due classi principali di connessione a livello di link. La prima, LAP Link Access Procedure non e' bilanciata il servizio reso considera il DCE master e il DTE slave (DCE primario, l' altro lato DTE secondario). La seconda, LAPB Link Access Procedure Balanced nella quale entrambi i "lati" della connessione sono uguali per richieste di connessioni e altri comandi. Potenzialmente esiste solo un DCE e molti DTE, ma entrambi i lati possono scambiarsi comandi. (Semplicisticamente, due potenziali corrispondenti possono in ogni momento connettersi e diventare alternativamente, quasi nello stesso momento dato il simplex, inviarsi comandi e risposte ... mentre tutti gli altri in ascolto sono solo DTE ...)

Primary/Secondary (LAP) Operation.

Operazioni di tipo primario da/a secondario.LAP e' un vecchio tipo di procedure per il controllo di connessione, dove la maggior parte d'intelligenza veniva supposta presente in grossi mainframe ,computer (DCE), mentre gli utilizzatori avevano a disposizione piccole quantita' d'intelligenza locale (DTE). Dato che il controllo di ogni network richiede molte attivita' di mantenimento puro rispetto alla quantita' d' informazione scambiate, era giusto far compiere la maggior parte delle operazioni di antenimento al piu' potente mainframe e avere giusto quel minimo di risorse e intelligenza necessarie a sostenere in modo molto meno sofisticato il link da parte dei terminali.

Balanced (LAPB) Operation.

LAPB e' una versione leggermente modificata di LAP. Quest' ultimo e' stato modificato per permettere operazioni bilanciate dai due lati del link. Nella versione ufficiale di X.25 vi e' sempre un solo DCE e potenzialmente molti DTE ma i due operano in maniera uguale piuttosto che in modo master/slave (primario/secondario). LAPB viene usato per l' Amateur Radio Packet Network. Anche nel caso vi sia un network controller (oggetto di supervisione instradamento  reindirizzamento) le procedure di link bilanciato migliorano l'operativita'.


Connection Operation.

Pensando a un network amatoriale e' certamente la miglior soluzione  quella di avere un livello 2 in grado di esser trasferito attraverso tutti i vari mezzi a rf a noi disponibili. Per esempio basti pensare al tipo di collegamento piu' semplice tra due stazioni, o allo stesso ma effettuato attraverso un network controller. Ovviamente in quest' ultimo caso il network c. sara' da considerarsi il DCE e le due stazioni che per tramite suo stabiliscono il link saranno considerate DTE. Quindi il device che ricevera' la richiesta di connessione va visto in quel momento come DTE (basso livello). Questa semplicissima regola elimina ogni ambiguita' che altrimenti potrebbe impedire il buon funzionamento della rete stessa. 

N.B.: Vi sono diverse modifiche minori riguardo a protocollo ufficiale X.25. Queste sono state inserite solo dove era assolutamente necessario per permetterne il funzionamento nei nostri mezzi a rf condivisi. Dato che X.25 e' stato disegnato per lavorare con un DCE che parli con piu' DTE, non potrebbe lavorare propriamente dove si tratta invece di diversi DCE collegati a diversi DTE sul medesimo canale.


LAPB Procedures.

Quanto segue descrive le procedure usate per il set-up, la connessione, il mantenimento, lo scambio d' informazioni e la disconnessione di un link bilanciato tra un DTE e DCE e viceversa. Queste procedure sono prese da X.25 salvo le necessarie modifiche.


Address Field Operation.
Modalita' d' utilizzo del campo d' indirizzamento e dei sottocampi medesimi. Tutti i pacchetti devono contenere il campo d' indirizzamento, costruito secondo le specifiche gia' dette. Tutti i pacchetti devono avere in questo campo l'indirizzo di destinazione e quello del mittente, nell'ordine come scritto. Questo permette la condivisione (sharing) del canale da parte di piu' links. L' indirizzo di destinazione e' sempre l' indirizzo della stazione che riceve il pacchetto, mentre l' indirizzo del mittente e' l' indirizzo di chi trasmette il pacchetto. L' indirizzo di stazione puo' essere di gruppo o club, se le operazioni da punto a multipunto sono permesse. Circa l' utilizzo di indirizzi diversi dai nominativi radioamatoriali sono in corso ulteriori studi.


Command/Response Procedure.

Procedura Comandi/Responsi. AX.25 liv. 2 versione 2.0 implementa l' informazione di Comando/Responso nel campo d' Indirizzo. Vengono usati due bit per mantenere la compatibilita' verso le versioni piu' basse. I due bit sono nei sottocampi d' indirizzo mittente e destinatario, il settimo bit dei byte A7 e A14. Un device funzionante a revisione due puo' verificare se il corrispondente ha pure implementato il livello due tramite il controllo dei due bit 7 del byte di SSID. Se entrambi i bit sono a zero o a uno, il corrispondente stara' usando il vecchio protocollo. La nuova versione avra' uno dei due bit sempre settato a uno, dipendentemente dal fatto che il frame di comando o di risposta a un comando. La codifica e' qui di seguito riportata.

+----------------------------------------------------------------+
! Tipo di pacchetto ! Dest. SSID C-bit ! Mitt. SSID C-bit !
+----------------------------------------------------------------+
! Versione precedente ! 0 ! 0 !
! Versione precedente ! 1 ! 1 !
! Risposta (V 2.0) ! 1 ! 0 !
! Comando (V 2.0) ! 0 ! 1 !
+----------------------------------------------------------------+

Dato che tutti i pacchetti sono da considerarsi di risposta o di comando ogni device avra' uno dei due bit settato a uno. L' uso dell' informazione di comando/risposta permette di usare anche i pacchetti di tipo S per questo scopo. Mantenendo cosi' un corretto controllo del link durante la fase di scambio informazioni.


Poll/Final (P/F) Bit Functions.

Il prossimo frame ritornato da un device che abbia ricevuto un SABM o un comando DISC con il bit P settato a uno sara' un UA o un responso di DM con il bit F settato sempre a 1.
Il frame ritornato in risposta a un pacchetto di tipo I con il bit P a uno , ricevuto durante la fase di trasferimento informazioni, sara' un RR, RNR o una risposta di REJ con il bit F settato a uno.
Lo stesso per un pacchetto di comando Supervisory, sempre inviato durante lo scambio d' Info. frames. Il bit P viene settato congiuntamente alla condizione di recupero del
time-out di T1.
Quando non e' usato il bit di P/F e' a zero.


LAPB Connection Establishment.
Quando un device (sia DCE che DTE) voglia stabilire una connessione con un altro device, dovra' trasmettere un pacchetto di comando di SABM al device voluto e far partire un contatore di time-out, T1 (time-out timer). 
Se l' altro device e' presente ed e' abilitato trasmettera' a sua volta al richiedente un pacchetto di responso UA e, nello stesso istante, rimettera' a zero entrambe le variabili di stato interne (V(R) e V(S)). Dall' altro lato la ricezione di un pacchetto di responso UA causera' nel device richiedente la connessione il fermo del contatore T1 e l' azzeramento delle stesse variabili di stato.
Se l' altro lato non risponde prima che T1 arrivi al suo valore di time-out, il richiedente, allo scadere di T1, reinviera' un pacchetto di comando SABM e fara' ripartire T1. Questo riprovarci nel tentativo di stabilire la connessione continuera' fino all' esaurimento del numero di tentativi possibili. Questo numero e' immagazzinato nella variabile N1; il valore di N1 e' variabile in funzione della frequenza del canale di link (HF,VHF o piu'), del tipo di operazioni a partire (terra-terra o terra-spazio; piu' semplicemente file transfer o semplice QSO), della velocita' di comunicazione. Questa variabile (N1) verra' vista meglio successivamente.


Information Transfer.

Trasferimento d' informazioni. Quando la connessione e' gia' stata stabilita con le modalita' gia' prese in considerazione, entrambi i devices sono abilitati a ricevere, trasmettere e processare pacchetti di tipo I,S o U.


Sending of I Frames.

Trasmissione pacchetti tipo I. Quando una delle due stazioni ha delle Informazioni da trasmettere le inserira' e le trasmettera' in pacchetti di tipo Information con N(S), numero di sequenza all' interno del sottocampo N(S) del campo di Controllo, pari al valore corrente della variabile di stato V(S). Quando il pacchetto verra' trasmesso V(S) verra' incrementata di uno.

Una qualsiasi delle due stazioni non trasmettera' piu' pacchetti di tipo I, se la sua variabile di stato in trasmissione e' uguale all' ultimo N(R) ricevuto dall' altro lato piu' sette (ovvero non vi possono essere piu' di sette pacchetti mancanti di acknoweledge per parte, lungo il percorso). Se tenta di trasmettere ancora pacchetti di tipo I la "finestra" di controllo del flusso dati sara' superata e ne nascera' una situazione d' errore.

Se un device e' in condizione di busy (non disponibile, utilizzabile), puo' continuare a inviare I frames all' altro device purche' questo non sia a sua volta non disponibile per lo scambio.

Se un device e' nello stato di frame-rejection (ha inviato REJ), non inviera' pacchetti di tipo I.


Receiving I Frames.

Se un device riceve pacchetti di tipo I validi (con FCS corretto e con il numero di sequenza in TX uguale alla sua variabile di stato per la ricezione presente) e non e' in condizione di non disponibilita', accettera' il pacchetto ricevuto. Incrementera' quindi la sua variabile di stato per la ricezione di uno, ed eseguira' una delle seguenti funzioni:
1> Se c'e' un pacchetto di tipo I da trasmettere potra' trasmetterlo con N(R) eguale alla sua nuova V(R) dando anche l' ACK (acknoweledge). Alternativamente , potra' trasmettere prima un pacchetto di RR con N(R) sempre uguale a V(R), per inviare ACK, quindi trasmettere il pacchetto di tipo I.
2> Se non vi sono frames di tipo I in attesa di esser trasmessi, il device che ha appena ricevuto si limitera' ad inviare un frame di RR con N(R) uguale a V(R).

Se il device non e' disponibile (si trova in stato di busy), potra' ignorare ogni frame di tipo I ricevuta e limitarsi a riportare il suo stato di busy.

Se esiste la condizione di device non disponibile, l' altra stazione che ricevera' un responso in tal senso dovra' eseguire un poll (ricerca, per cambio di stato in questo caso) verso il corrispondente, periodicamente fino a quando lo stato della prima stazione da busy passi a ready.

La ricezione di pacchetti di tipo I con il campo informazione di lunghezza zero verra' riportata al livello superiore senza trasferimento del campo d' informazione.

Quando venga ricevuto un pacchetto di tipo I con FCS corretto, ma il suo numero di sequenza in trasmissione (N(R)) non sia pari al numero di sequenza in ricezione (V(R)) , il frame sara' scaricato e verra' inviato un pacchetto di REJ contenente il numero di sequenza in ricezione atteso, quello dell' ultimo frame ricevuto correttamente, piu' uno (con base 8 pero'!). Ogni frame fuori sequenza verra' trattato in questo modo. La variabile di stato per la ricezione del corrispondente e il bit di poll, scritti nel pacchetto fuori sequenza ricevuto, vengono esaminati prima della cancellazione, daranno (eventualmente) luogo agli interventi previsti per l'altro senso di comunicazione.


Receiving Ackoweledgment.

Ogni volta che vengano ricevuti pacchetti di tipo I o S correttamente, anche se in condizioni di non disponibilita', N(R) del pacchetto ricevuto viene controllato per verificare se contiene ACK per pacchetti , di tipo I, gia' trasmessi e in attesa di conferma. Quindi se il pacchetto attuale riporta ACK per pacchetti in questo stato T1 viene resettato. Se T1 viene resettato e vi sono ancora pacchetti in attesa di conferma (oustanding sent frames), T1 uno stesso verra' fatto ripartire . Se T1 arrivera' al time-out  verra' dato l' avvio alla procedura di ritrasmissione.


Receiving Reject.

Quando si riceva un pacchetto di REJ, la stazione trasmittente I frames a cui si riferisce il REJ dovra' settare la sua variabile di stato per la trasmissione con il valore riportato dal pacchetto di REJ nel suo campo di Controllo. A questo punto il device ritrasmettera' tutti i pacchetti in attesa al prossimo occasione disponibile conformandosi alle seguenti regole: 
1> Se il device non sta' trasmettendo al momento, e il canale e' libero, potra' iniziare la ritrasmissione immediatamente.
2> Se il device sta' operando in ambiente full-duplex (f.-d. environment) e sta' trasmettendo pacchetti S o U, terminera' la trasmissione di questi e poi passera' alla ritrasmissione dei pacchetti di tipo I richiesti.
3> Se il device sta' operando in ambiente full-duplex e trasmettendo frames di tipo I, quando ricevera' il pacchetto di REJ, abortira' il frame corrente e iniziera' la ritrasmissione dei pacchetti di tipo I richiesti.
4> Il device potra' terminare il frame di tipo I in corso, o inviarne anche altri della sequenza corrente a patto che non si superi la finestra di controllo del flusso (flow control window) gia' vista, pari a massimi sette pacchetti in attesa di ACK.

Se il device riceve il pacchetto di REJ con anche il bit di poll settato, rispondera' con un pacchetto di RR o RNR che abbia il bit di final settato (Poll/Final bit vedi Control Field).


Receiving an RNR Frame.

Ricezione di un pacchetto Receiver-Not-Ready. Ogni volta che viene ricevuto un pacchetto RNR, il device potra' trasmettere o ritrasmettere tutti i pacchetti del tipo I che abbiano il numero di sequenza in trasmissione eguale a quello che riporta il numero di sequenza in ricezione trasportato dal pacchetto RNR. Se il timer T1 va' in time-out dopo la ricezione di un frame RNR, verra' eseguita una procedura di attesa conferma (attesa dell' acknoweledgement). Il bit di poll puo' venir usato in unione ai pacchetti di tipo S per testare lo stato della stazione non disponibile . Nessun altro tipo di pacchetto potra' essere trasmesso se non un Supervisory, fino al momento della ricezione di un pacchetto che indichi il cambio stato dell' altra apparecchiatura fino ad allora busy.


Sending a Busy Indication.

Trasmissione dell' indicazione di apparecchiatura non disponibile. Ogni volta che un device entra nella condizione di non disponibilita' (busy), deve indicarlo al corrispondente. Lo fara' inviando un pacchetto di risposta RNR alla prossima opportunita'. Mentre un device si trova nella condizione di busy puo' ricevere e processare pacchetti di tipo S, se questi avranno il bit di poll settato a uno il device rispondera' con un pacchetto di RNR e il bit di final settato pure a uno alla prossima opportunita' possibile. Per dimostrare di aver eliminato la condizione di busy il device dovra' inviare un pacchetto di tipo RR o REJ riportanti il numero di sequenza in ricezione (N(R)) eguale al valore della variabile di ricezione (V(R)) corrente. Questa possibilita' di diversa indicazione dipende dalla buona o cattiva ricezione dell' ultimo pacchetto.


Waiting Acknoweledgement.

Ogni apparecchiatura (device) dovra' mantenere al suo interno un variabile di conteggio per la ritrasmissione, questa sara' posta a zero ogni volta che venga ricevuto un ACK per un pacchetto di tipo I (anche quando si ricevano pacchetti di tipo UA o RNR, o quando frames di tipo I o S trasportino numeri di N(R) piu' alti dell' ultimo N(R) ricevuto, a significare che altri pacchetti di tipo I hanno avuto ACK).

Ogni volta che il timer T1 va' in time-out, il device deve entrare in una sequenza di recupero della condizione (recovery routine), la variabile di conteggio delle ritrasmissioni verra' incrementata di uno e un' altra variabile interna (X) verra' posta al valore corrente della variabile di stato per la trasmissione.

Il device fara' quindi ripartire il timer T1, impostera' la sua variabile di stato per la ricezione all' ultimo numero di sequenza ricevuto e ritrasmettera' i corrispondenti pacchetti di tipo S o I con il bit di poll settato a uno. 
La condizione data dalla routine di recupero e ripartenza del timer T1 viene resettata quando il device riceve un pacchetto di tipo S valido e con il bit di F settato a uno.

Se il device riceve un pacchetto di tipo S valido e con il bit final settato a uno e N(R) all' interno dell' intervallo tra la variabile di stato per la trasmissione e la variabile interna X ,caricata all' inizio della routine di recupero per T1, la condizione viene resettata e la variabile di stato per la trasmissione N(R) viene impostata con il valore di N(R) ricevuto.

Se un device riceve un pacchetto del tipo visto nel paragrafo precedente ma con il bit di final a zero, non viene inizializzato il timer T1. Il sottocampo N(R) viene utilizzato lo stesso per reimpostare la variabile di stato per la trasmissione. Il device potra' recuperare l' ultima frame di tipo I (anche se questa ha gia' ricevuto ACK) impostare il bit di poll a uno e ritrasmetterla se il timer T1 non e' andato di nuovo in time-out nel frattempo.

Quando la variabile di conteggio delle ritrasmissioni raggiungera' il valore N2 (Retry, numero tentativi di riesecuzione funzione), il device iniziera' le procedure di reset del link piu' avanti descritte.


Link Disconnetting.

Durante la fase si scambio informazioni, entrambi le apparecchiature possono iniziare la disconnessione inviando un pacchetto DISC. Il device inviante fara' quindi partire il suo timer T1 e attendera' una risposta. Se non arriva una risposta valida prima dello scadere di T1, verra' reinviato DISC e T1 ripartira'. Questo sempre fino al valore di N2 volte, il device che richiede DISC entrera' direttamente in stato di disconnessione.

Quando viene ricevuto un pacchetto DISC, il ricevente deve restituire un pacchetto di responso UA (Unnumbered Ack.) e entrare in stato di disconnessione.


Disconnected State.

Dopo aver trasmesso un frame DISC e ricevuto un frame UA, o inviando un frame UA dopo aver ricevuto un frame DISC, il device entrera' nello stato di disconnessione.

In questo stato ogni apparecchiatura puo' iniziare la procedura di partenza del link con ogni altro device (link set-up). Puo' quindi rispondere a un SABM e stabilire una connessione, o puo' reagire al SABM con l' invio di un pacchetto con il responso DM.

Ogni stazione che riceva un comando di DISC mentre gia' si trova in stato di disconnessione inviera' comunque un pacchetto di risposta DM.

Ogni device che riceva un frame di comando diverso da SABM o da UI (Unnumbered Info.) con il bit di poll settato a uno, rispondera' con un frame di DM con il bit di final settato a uno. Ogni altro campo sara' ignorato.

Quando un device e' entrato nello stato di disconnessione in seguito a una condizione d' errore interno o esterno (presumibilmente indotto dall'altro end), lo segnalera' inviando un frame di responso DM piuttosto che un frame di comando DISC. Verra' fatto partire T1, se andra' in time-out prima della ricezione di un SABM o di un DISC, verra' fatto ripartire T1 e reinviato DM. Questo sempre fino al valore di N2 ritrasmissioni, superato il quale il device restera' in stato di disconnessione e nessun' altra azione verra' intrapresa.


Resetting Procedure.

La procedura viene utilizzata per reinizializzare in entrambe le direzioni di flusso dopo un errore non recuperabile. Questa procedura di reset viene utilizzata solo durante la fase di trasferimento informazioni del protocollo AX.25.

Un device potra' richiedere un reset inviando un pacchetto di SABM. Una stazione che riceva un frame di SABM da un altra stazione alla quale era connessa inviera' a sua volta un frame di UA indietro alla prima buona occasione. Entrambi i device azzereranno le loro variabili di stato per la ricezione e la trasmissione. Ogni condizione di busy eventualmente esistente viene eliminata.

E' possibile iniziare la procedura di disconnect invece che quella di reset.

Uno dei due device potra' inviare un frame di responso DM richiedendo all' altro l' inizio della procedura di reset del link, dopo aver trasmesso DM in device passera' in disconnect state.

Un device puo' richiedere l' inizio della procedura di reset del link inviando un pacchetto di responso FRMR.

Dopo aver trasmesso FRMR, il device entrera' in stato di pacchetto rifiutato (frame rejeted state). Questa condizione verra' eliminata quando il device che ha trasmesso FRMR ricevera' un SABM o un comando DISC dall'altro capo. Ogni altro pacchetto di comando ricevuto causera' la ritrasmissione di FRMR con il medesimo campo d' Informazione gia' inviato.

Il device che trasmette FRMR fara' nel contempo partire il timer T1. Se non avra' ricevuto i pacchetti gia' detti, al time-out del contatore ritrasmettera' FRMR e fara' ripartire T1, come descritto in "Waiting Acknoweledgement". Se FRMR verra' trasmesso N2 volte senza successo, il device passera' il link sara' resettato.


Rejection Conditions.

Condizioni per il rifiuto di pacchetti. Un device puo' iniziare la procedura di reset del link quando un pacchetto che sia valido come FCS e campo d' indirizzamento ma durante lo fase di scambio pacchetti di tipo I questo abbia uno o piu' dei seguenti problemi:

1> Il pacchetto porta un comando o un responso non conosciuto al ricevente;
2> Il campo d' informazione e' piu' lungo di 256 bytes.

Un device iniziera' sempre la procedura di reset quando riceva responsi  di DM o FRMR durante la fase di scambio informazioni.

Un device iniziera' sempre la procedura di reset ogni volta riceva un frame di UA o un non sollecitato pacchetto di responso con il bit di final settato a uno.


Collision Recovery.

Recupero delle collisioni.

Collision Recovery in a Half Duplex Environment.

Recupero delle collisioni in ambiente half-duplex. Collisione di pacchetti di ogni tipo in questo ambiente vengono gestite essenzialmente grazie a T1 e alla variabile di ritrasmissione N2. Non vengono intraprese altre speciali misure.


Collision in a Full Duplex Environment.

Collisioni in ambiente full-duplex. Non si tratta in realta' di vere collisioni, ma hanno molto piu' a che fare con un device che non riesce a seguire il ritmo di due canali realmente contemporanei.


Collision of Unnumbered Commands.

Collisioni di pacchetti di Comando non numerati. Se i comandi inviati da entrambi i lati sono uguali, entrambi i devices invieranno un pacchetto di UA alla prima buona occasione e sempre entrambi entreranno nello stato indicato.
Se si tratta di comandi Unnumbered differenti inviati nel medesimo tempo, entrambi i device entreranno nello stato di disconnessione e trasmetteranno un pacchetto DM alla prima opportunita'.


Collision of a DM with a SABM or DISC.

Collisione di DM con SABM o DISC. In questo caso viene trasmesso da uno dei due lati un frame, non sollecitato dall' altro, di DM. Puo' avvenire una collisione tra il DM e un SABM o un DISC. Per prevenire la cattiva interpretazione di un simile DM, tutti i frames di DM non trasmessi su richiesta del corrispondente verranno spediti con il bit di final a zero. 
Viceversa tutti i frames SABM o DISC avranno il bit di poll a uno, non vi potra' quindi essere nessuna confusione tra un DM richiesto o non richiesto.


Connectionless Operation.

Operazioni in stato di disconnessione. Tra le possibilita' d' operazione ve n'e' una che non e' veramente fattibile al livello due. Questo modo definito "a tavola rotonda" (roundtable) implica che diversi radioamatori siano impiegati assieme nella stessa discussione. L' unico modo per simularlo durante una connessione e' che ognuno sia connesso a tutti i membri del gruppo. Questo vuol dire un pacchetto separato trasmesso da ognuno per ogni altro ogni volta che si debbano scambiare informazioni. Ovviamente non e' un sistema praticabile. La via che molti OM entusiasti del P.R. hanno scelto per simulare questo approccio e' al di fuori della connessione in AX.25 , ma usa la costruzione del pacchetto tipica di AX.25. Il protocollo permette dei pacchetti di tipo speciale denominati UI (Unnumbered Information). E' auspicabile che quando si svolgono operazioni di questo tipo tutti i corrispondenti indirizzino i loro pacchetti a un nome-nominativo prescelto. Cosi' con i comandi di monitor sara' possibile escludere il normale traffico.
Questa mancanza di operazioni stile roundtable e' un problema del livello due, si suppone che il livello 3 possa risolvere piu' elegantemente il problema. Per ora il modo indicato appare un accettabile ripiego.

Tenete ben in mente che questo modo e' in assenza di connessione, tutti i meccanismi di recupero per i pacchetti eventualmente persi che si basano sulla flow window sono assenti. Se un pacchetto viene perso non ne esiste traccia in nessun luogo e perso senza speranza. Questo in particolare per collisioni di frames UI, un pacchetto di tipo Ui che collida con un altro pacchetto di tipo qualsiasi non e' piu' recuperabile.


List of System Defined Parameters.

Lista dei parametri di sistema definiti.

Timers

E' raccomandato l' uso di tre timer per il mantenimento dell' integrita'
di un link in AX.25.

Il primo timer , T1, viene usato per dare la sicurezza in caso di attese per responsi a riceversi che questa non si prolunghi oltre un certo limite di tempo dopo la trasmissione di un pacchetto. Questo timer non puo' essere espresso in tempo assoluto, dato che il tempo necessario per trasmettere un
pacchetto vari molto in funzione della velocita' di trasmissione stessa usata dal livello 1. T1 deve essere almeno doppio rispetto al tempo necessario per trasmettere un frame di lunghezza massima al corrispondente dall' altro lato del link, questo da' un certo margine, sempre al corrispondente, per dar tempo di processare quanto eventualmente vi sia da eseguire/decodificare prima di trasmettere una risposta.

Il secondo timer, T2, da' il ritardo tra la ricezione di un pacchetto di tipo Information valido e la trasmissione del pacchetto di risposta collegato. Questo ritardo puo' essere necessario per permettere al DXE ricevente di stabilire se esistono altri pacchetti, dopo il primo appena ricevuto. Se vengono ricevuti piu' pacchetti un DXE puo' attendere e dare ACK complessivamente, fino a un massimo di un ACK valido per sette pacchetti, piuttosto che ad ogni singolo frame. T2 non e' mandatorio ma la sua implementazione e' raccomandata per migliorare l' efficenza del canale.
Resta da notare che in un canale full-duplex l' ACK non deve essere ritardato piu' di K/2 pacchetti per avere la massima velocita' di trasferimento.

il terzo timer, T3, viene fatto partire quando T1 non e' in uso per essere sicuri che un pacchetto di Supervisory sia inviato periodicamente sul link per mantenerlo quanto piu' costantemente sotto controllo (wakeup or keep alive timer). La raccomandazione e' che ogni qualvolta non vi siano pacchetti di tipo I o pacchetti con il bit di poll settato in attesa di ACK (durante la fase di trasferimento d' informazioni), vengano inviati dei pacchetti di RR o RNR con il poll bit settato a uno. Questo ad ogni scadere di T3, il cui valore e' definito localmente. La temporizzazione di T3 dipende drammaticamente dalle diverse costanti d' uso del livello 1, per questa ragione e' ancora soggetto ad ulteriori studi.


Maximum Numbers of Retryes N(2).

Massimo numero di tentativi per la ritrasmissione, ogni volta che T1 va' in time-out subisce una variazione dinamica dal valore predefinito. Varia molto in funzione delle costanti d' uso per il livello 1, tipicamente vale 16.


Maximum Number of Bytes in an I Field N(1).

Il massimo numero di bytes (octets) permesso nel campo d' Informazione e' di 256 (0-255). Possono esserci solo campi d' informazione con numero pari di bytes.


Maximum Number of I Frames Outstanding (K)

Il massimo numero di pacchetti in attesa di conferma e' sette. Puo' essere ridotto in ogni momento per migliorare le caratteristiche di particolari trasferimenti.

Released By Sergio Centroni, I1TMH @ I1TMH. 

We use cookies to improve our website and your experience when using it. Cookies used for the essential operation of the site have already been set. To find out more about the cookies we use and how to delete them, see our privacy policy.

I accept cookies from this site.

EU Cookie Directive Module Information