ArNet
Un protocollo che implementa i livelli datalink (ISO/OSI 2), rete (ISO/OSI 3) e trasporto (ISO/OSI 4) per lo scambio di piccoli blocchi di dati (da 4 a 1024 byte) tra piccoli gruppi di nodi (massimo 256), connessi da un mezzo fisico trasmissivo condiviso. Pensato per essere utilizzato con Armando47
Diversamente dai sistemi a layer, il trasporto dei dati in arNet viene caratterizzato da delle features liberamente combinabili.
arNet si preoccupa SOLO (e non sempre) di:
- addressing
- routing
- #Controllo di Errore
- ordering
- media access control
- #Framing
altre features vanno implementate altrove: datagram/virtual circuit transport, crittografia...
i nodi possono essere terminali o router
il MAC - routing si basa su due livelli di indirizzo:
- un indirizzo del terminale, valido tra i terminali che condividono il canale fisico
- un indirizzo del segmento, che identifica il canale fisico
Framing
um pacchetto arNet e' composto da:
- un #Start Block di 8 simboli
- l'header, composto da uno o piu #Header Block da 4 byte ognuno
- il payload, zero o piu #Payload Block da 4 byte ognuno
la lunghezza dell'intero messaggio sara sempre 4 + (header_size * 4) + (payload_size * 4) bytes
minimo: 4 bytes
massimo: 4 + (2^8) * 4 + (2^4) * 4 = 1092 bytes
Controllo di Errore
per resistere agli errori di trasmissione, gli header e i dati passano attraverso un #FEC ed un #Interleaver.
FEC
algoritmo di FEC: Hadamard code
la latenza minima al netto del FEC e' data dal blocco di crittazione (16bytes).
anche la granularita della protezione di errore FEC e' data dal blocco di crittazione (16bytes): e' inutile tentare di preservare l'integrita di blocchi di dati piu piccoli di 128bit, il danneggiamento anche di un solo bit si ripercuoterebbe sul contenuto di tutto il blocco di crittazione.
se si perde anche un solo bit del segnale al netto del FEC vanno persi 16 caratteri.
questo e' tendenzialmente male pensando all'uso con messaggi di testo, i linguaggi naturali hanno una loro ridondanza a livello di parola considerevole. per applicazioni non di testo questo vantaggio non esiste, anche se per messaggi molto piu piccoli di 16byte l'overhead dato dal padding e' comunque considerevole.
d'altra parte dimensioni di blocco crittografico piu piccole implicherebbero minore sicurezza (anche se in realta il tutto sarebbe proporzionale alla quantita di dati trasferiti con una determinata chiave). crittare il codice FEC (n = 128bit, se si usano input k di 8 bit) sembrerebbe allettante dato che si allineerebbe al blocco crittografico, ma:
- crittograficamente e' un inganno, dato che i codici fec trasmessi sono comunque sempre 256 dal punto di vista della ripetitivita sarebbe equivalente ad usare una cifratura con dimensione blocco di 1byte. troppo poco.
- dal punto di vista del FEC e' un inganno, decrittando un blocco danneggiato si avrebbe un codice fec danneggiato in maniera complessa, perdendo il vantaggio della ortogonalita del codice di hadamard.
alla luce di questo forse ha senso considerare dei block codes diversi da quello di Hadamrd, che e' non-ottimale per k maggiore di 7 [1].
la dimensione del blocco FEC * numero di caratteri del blocco AES sarebbe quindi:
- 2^(8-1) * 16 = 2048 bit nel caso di FEC con input a 8 bit.
- (2 * 2^(4-1)) * 16 = 256 bit nel caso di FEC con input a 4 bit (ogni carattere 2 input).
prendendo il secondo caso, con un alfabeto di 16 toni per simbolo, quindi 4 bit, la latenza sarebbe di 64 simboli, che a 32 simboli per secondo farebbe 2 secondi per 16 caratteri.
la cosa migliore da fare e' rassegnarsi a questa latenza di blocco e cercare di fare uno spreading piu efficiente possibile, vedi interleaving.
letture:
- http://www.ece.ualberta.ca/~hcdc/Library/ErrorContrClass/DecodingBasic.pdf
- https://en.wikipedia.org/wiki/FX.25_Forward_Error_Correction
Interleaver
i possibili problemi 'descrivibili' del path di trasmissione sono:
problemi di spettro:
- interferenze coerenti (toni sovrapposti a uno dei nostri bin)
- errori della risposta in frequenza (equalizzazione..)
entrambi comportano il danneggamiento sistematico di una o piu determinate lettere dell'alfabeto in ogni simbolo
problemi nella sequenza di simboli:
- disturbo impulsivo prolungato su tutto lo spettro
- disturbo impulsivo ciclico su tutto lo spettro
che comportano la perdita di piu simboli contigui o la perdita sistematica di un determinato simbolo.
per mitigare questi problemi puo essere conveniente una qualche forma di interleaving sia in tempo che in frequenza/fase.
prendiamo il caso di un blocco da 256 bit formato da 4 sottoblocchi quadrati da 64bit -> 16 simboli*16 toni contenenti ognuno 4 caratteri.
con un hadamard code, si possono correggere fino ad 1/4 dei bit del codice.
prendiamo come casi peggiori possibili
- la perdita sistematica di 1 bit del simbolo
- la perdita di un intero sottoblocco
questo significa che in ogni sottoblocco si possono danneggiare (non contemporaneamente) fino a:
- 4 simboli
- 4 toni ?
il sistema piu rudimentale e' l'interleaving elicoidale, ad esempio una rotazione nel senso della sequenza combinata con una rotazione nel senso del simbolo. l'incremento sarebbe di un bit/simbolo in senso verticale e di un sottoblocco + un simbolo in senso orizzontale
uint8_t InterleaveBlock(uint8_t *InData, int16_t *DataMatrix, uint8_t *ModulationSymbolsBuffer){ uint8_t BitPos, SymbolOffset, BitOffset; for (uint8_t FECBlock = 0; FECBlock < HadamardCodesPerInterleaverBlock; FECBlock++){ BlockEncodeChar(DataMatrix, InData[FECBlock]); for (uint8_t FECBit = 0; FECBit < HadamardCodeSize; FECBit++){ BitPos = (FECBlock * HadamardCodeSize) + FECBit; BitOffset = BitPos % BitsPerModulationSymbol; SymbolOffset = ((FECBit * HadamardCodeSize) + FECBlock) % SymbolsPerInterleaverBlock; ModulationSymbolsBuffer[SymbolOffset] |= (DataMatrix[FECBit] & 0b1) << BitOffset; // printf("%u,%u,%u\n", SymbolOffset, BitOffset, BitPos); } // printf("\n in FEC: "); // printbuf(DataMatrix, HadamardCodeSize, 8); } }
che produce una disposizione [2], dove il colore e' l'ordine dei bit in ingresso (dal blu al rosso), la x e' il tempo e la y il simbolo in uscita
i parametri rilevanti da passare all'interleaver sono:
- dimensione della costellazione
- numero di simboli per interleaver block
http://cgit.brokenbydesign.org/cgit.cgi/armando.git/plain/interleaver.c
Soft-Decision
nella catena di demodulazione si possono ottenere diversi indici di affidabilita
- rapporto tra il tono di picco e la media degli altri toni
- valore del picco carattere nella trasformata di hadamard
una cosa MOLTO carina da fare (dato che siamo in uno dei pochi casi in cui le risorse di calcolo sono ben piu grandi della banda) e' avere una qualche strategia di soft-decision pilotata dai valori in uscita dalla fft, magari triggerata da differenze tra l'energia nei bin inferiori a una data soglia.
Controllo di Flusso
vedi #Global Routed Transport Header
Start Block
indica l'inizio di una trasmissione. precede sempre un #Header Block.
questo riferimento deve avere autocorrelazione tendente a zero, essere abbastanza lungo (raro) da evitare false partenze, abbastanza corto da non creare overhead. viene usato per la sincronizzazione di simbolo e per l'equalizzazione.
lunghezza 8 simboli. alternando simboli alla frequenza/fase 0 e simbolo all'estremo opposto della costellazione di simboli (frequenza massima/fase +180).
letture:
- http://www.ece.ualberta.ca/~hcdc/Library/NagKhaSchBur06.pdf
- http://www.argreenhouse.com/society/TaCom/papers99/32_5.pdf
- https://en.wikipedia.org/wiki/Gold_code
Indirizzamento
Lo spazio di indirizzamento di arNet e' composto di 4 sottolivelli da 2^8 indirizzi ognuno.
un nodo ha un indirizzo del tipo L0 xx L1 yy L2 zz L3 ww (brevemente xx.yy.zz.ww)
durante l'invio il mittente ha bisogno di specificare solo i livelli dell'indirizzo del destinatario sono differenti dai propri. questo incoraggia una topologia di rete che imiti la struttura dell'indirizzamento (ad esempio una rete ad albero), minimizzando il la complessita delle strategie di routing.
Accesso multiplo al mezzo condiviso
La mancanza di controllo di collisione e la scarsa larghezza di banda per i quali e' progettato arNet impongono uno schema di accesso al mezzo che minimizzi le collisioni e le ritrasmissioni.
ci sono due scenari:
Reservation mode
richiede la presenza di un router sul canale, e organizza una multiplazione deterministica a divisione di tempo e - se disponibile - divisione di frequenza (canale).
Contention mode
Header Block
sono una serie di almeno 1 blocchi con dimensione sempre 4 bytes (1 Data Block) che precedono sempre una serie di zero o piu blocchi dati.
il primo blocco e' chiamato default header ed e' sempre presente.
i blocchi header successivi sono indicati dall' header type
i blocchi header subiscono tutti block-coding -> #Interleaver
Default header
E' l'header di base, sta all'inizio di ogni messaggio e si occupa dell'instradamento locale e dell'ordinamento dei pacchetti. Dev'essere implementato su ogni nodo.
4b (protocol) | 8b (src) | 8b (dst) | 4b (header_size) | 8b (payload_size) |
campi:
- protocol numero di protocollo. arNet = 0x1
- header_size numero di header da 4 byte che seguono il default header.
- payload_size dimensione del blocco dati che segue in multipli di 4byte
- src indirizzo del mittente
- dst indirizzo del destinatario
il multicast e' semplicemente un indirizzo di ricezione secondario sui client
src e dst sono significativi solo sul canale fisico, e' normale che ci siano client omonimi su due canali diversi
l'indirizzo 0 e' broadcast.
Segment Access Advertisement Header
il pacchetto viene mandato esclusivamente dai router per istruire i nodi che sono nel segmento di rete sul proprio indirizzo globale e sulle regole di accesso al canale
il routing e' un instradamento tra segmenti diversi. ogni segmento ha un indirizzo e un livello.
tutti i nodi che ricevono il pacchetto e vogliono aderire al router devono memorizzare queste impostazioni.
i nodi fanno il possibile per non trasmettere durante la trasmissione del SAAH.
i router presenti sul segmento devono concordare sulle informazioni contenute in questo pacchetto e trasmetterlo a turno.
4b (htype) | 8b (segaddr) | 8b (timeframe) | 8b (beacon_period) | 4b (reserved_window) |
- htype tipo header 0x1
- timeframe_size dimensione timeframe del segmento in multipli di 16byte trasmessi al bitrate corrente.
- beacon_period il prossimo SAAH verra spedito dopo questo periodo misurato in timeframe_size, non necessariamente dallo stesso router.
- segaddr indirizzo del segmento di rete
- reserved_window l'offset del primo slot libero sul canale di default. i client che non hanno prenotato uno slot attenderanno almeno reserved_window*timeframe prima di trasmettere.
il tempo di riferimento del segmento viene resettato all'inizio dello start block di ogni SAAH inviato dal router
letture:
- https://en.wikipedia.org/wiki/Time-division_multiplexing
- https://en.wikipedia.org/wiki/Time_division_multiple_access
- https://en.wikipedia.org/wiki/Dynamic_TDMA#Dynamic_TDMA
- https://en.wikipedia.org/wiki/Scheduling_algorithm
Global Routed Transport Header
viene usato dai nodi per mandare dati in maniera routed (ossia tra nodi che stanno su un segmento potenzialmente diverso).
4b (htype) | 4b (ttl) | 2b (seglevel) | 8b (segsrc) | 8b (segdst) |
- htype tipo header 0x2
- ttl numero di hop massimi di routing. viene decrementato ad ogni hop.
- seglevel livello gerarchico del segmento.
- segsrc id del segmento di rete del mittente.
- segdst id del segmento di rete del destinatario.
- i client ignorano i messaggi con segaddr diverso dal proprio
- i router invece li inoltrano
letture:
- http://nms.lcs.mit.edu/papers/hbhfc-sensys04.pdf
- http://hondo.informatik.uni-freiburg.de/pubs/MANET-trade_offs.pdf
Slot Reservation Request Header
4b (htype) | 8b (src) | 8b (dst) | 5b (queue_size) | 2b (fecn) | 2b (becn) | 1b (slotresreq) | 1b (repeatreq) |
TODO
Richiesta di prenotazione slot.
- fecn forward congestion notification. il nodo ha la coda di output piena e ha bisogno di trasmettere prima possibile. da 00 normale a 11 congestionato.
- becn backward congestion notification. il nodo ha la coda di input piena e chiede che gli si mandino i dati piu tardi possibile. da 00 normale a 11 congestionato.
- slotresreq prenotazione di slot tempo/canale. il nodo non trasmette dati e fanno fede per la prenotazione i valori del suo default header.
- repeatreq richiesta di ripetizione del pacchetto da parte del router.
Slot Reservation Reply Header
4b (htype) | 8b (src) | 8b (dst) | 2b (channel) | 5b (timeframe_offset) | 5b (window_size) |
Il router risponde alle prenotazioni di slot tempo/canale con questo header.
- htype tipo header 0x2
- src nodo che deve trasmettere
- dst nodo che deve ricevere
- channel canale sul quale si devono collocare i due nodi
- timeframe_offset momento nel quale va avviata la transazione in tempo*bloccodati
- window_size durata massima della transazione in blocchi dati
CRC Header
per avere conferma che il messaggio e' stato trasportato senza essere danneggiato
4b (htype) | 2b (crctype) | 1b (ackreq) | 1b () | 24b (crc) |
- htype tipo header 0x3
- crctype tipo crc (0x0000 = CRC-24 di OpenPGP)
- ackreq il nodo chiede la conferma con un ack
- crc valore crc di TUTTO il blocco dati
Timing Header
4b (htype) | 11b (date) | 17b (time) |
- htype tipo header 0x5
- date days from epoch
- time seconds of day
Global Routing Advertisement Header
TODO il pacchetto viene mandato esclusivamente dai router ad altri router per descrivere la topologia della rete
Payload Block
sempre 4 bytes di dati
subisce: cifratura -> block-coding -> interleaving
letture:
https://en.wikipedia.org/wiki/Communications_protocol
Cifratura
algoritmo di cifratura: AES-256 (blocco 128 bit, chiave 256 bit)
la chiave e' composta di 64 caratteri esadecimali
il blocco crittato e' sempre di 16byte
- http://www.literatecode.com/aes256 sembra ok, volendo si puo ottimizzare qualcosa per i 16bit
- http://libtom.org/?page=features&newsitems=5&whatfile=crypt se non e' troppo grosso, e' il piu portabile
- http://gladman.plushost.co.uk/oldsite/AES/
- http://axtls.sourceforge.net/
- http://www.matrixssl.org/
- http://polarssl.org/
- http://www.yassl.com/yaSSL/Products-cyassl.html
Letture
- http://www.cc.gatech.edu/~sakhshab/evoarch.pdf
- https://savannah.nongnu.org/projects/lwip/
- https://en.wikipedia.org/wiki/UIP_%28micro_IP%29
- http://www.canfestival.org/
- http://sourceforge.net/projects/opensourcehdlc/
- https://en.wikipedia.org/wiki/High-Level_Data_Link_Control
- http://www.isode.com/whitepapers/stanag-5066.html
- http://www.isode.com/whitepapers/messaging-protocols-for-hf-radio.html
- http://wireless.nmsu.edu/hf/papers/ies02.pdf
- https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1605761
- http://stackoverflow.com/questions/321423/parsing-binary-data-in-c