|
|
| (447 intermediate revisions by 5 users not shown) |
| Line 1: |
Line 1: |
| == Device crittografico tascabile ==
| | [[Category:Telecom]] |
| | [[File:Aardvark2 (PSF).png]] |
| | ''modem tascabile'' |
|
| |
|
| device piccolo ed economico per lo scambio di messagi di testo cifrati su canali audio.
| | modem piccolo, economico e a basso consumo per la comunicazione digitale a bassa velocita' su canali rumorosi half-duplex con banda passante da 1Hz a 5khz. |
|
| |
|
| == externals ==
| | {{Special:PrefixIndex/{{FULLPAGENAME}}/}} |
|
| |
|
| | == Caratteristiche del mezzo trasmissivo == |
|
| |
|
| * lcd (grafico? 4x20 caratteri) | | * sempre broadcast |
| * keypad 4x3 | | * banda 1 Hz - 5 kHz |
| * jack audio in | | * puo avere SNR infimi |
| * jack audio out | | * e' half-duplex |
| * ptt | | * puo' avere tempi di commutazione R/T lunghi |
| * mini-usb ? | | * non ha meccanismi di collision detect |
| | * puo' non essere possibile la rilevazione di canale occupato |
| | * puo' presentare condizioni di terminale nascosto |
| | * puo contenere uno o piu' canali |
|
| |
|
| | esempi di mezzi fisici usabili possono essere: |
| | * radio(pmr, cb, vhf, hf) |
| | * rame |
| | ** RS485 |
| | ** Powerline |
| | * ottico |
| | ** fibra |
| | ** in aria |
| | * acustico |
| | * idroacustico |
| | * induzione magnetica |
| | * neutroni |
| | * neutrini |
| | * onde gravitazionali |
| | * piccioni, topi, cani, blatte |
|
| |
|
| == internals == | | == Caratteristiche == |
| | === Alimentazione === |
| | 3.3v DC |
|
| |
|
| | === Porte audio === |
| | input e output sbilanciati standard consumer line-level −10 dBV con impedenza 10kohm |
|
| |
|
| * processore: dspic33fj128gp802
| | === Modulazione === |
| * codifica audio: MFSK
| |
| **https://en.wikipedia.org/wiki/Olivia_MFSK
| |
| **http://www.w1hkj.com/downloads/fldigi/fldigi-3.21.41.tar.gz
| |
| * Sincronizzazione simbolo: TBD
| |
| * FEC: [[Hadamard code]]
| |
| * algoritmo di cifratura: AES-256
| |
| **http://www.literatecode.com/aes256 sembra ok
| |
| **http://gladman.plushost.co.uk/oldsite/AES/
| |
| **http://axtls.sourceforge.net/
| |
|
| |
|
| la latenza minima al netto del FEC e' data dal blocco di crittazione (16bytes).
| | Implementa squalsiasi combinazione di ASK, PSK, e FSK, con costellazioni di dimensione da 2 a 16, frequenza massima 5khz (campionamento a 20khz). |
|
| |
|
| 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.
| | Il symbol rate va da 1 a 1200 baud/s |
|
| |
|
| se si perde anche un solo bit del segnale al netto del FEC vanno persi 16 caratteri.
| | === UART === |
| | 2 seriali UART 9600N1 con livelli TTL 3.3v |
|
| |
|
| 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.
| | === GPIO === |
| | | 8 GPIO con acquisizione analogica e output PWM |
| 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 [http://www.math.unl.edu/~djaffe2/papers/sevens.html].
| |
| la cosa migliore da fare e' rassegnarsi a questa latenza di blocco e cercare di fare uno spreading piu efficiente possibile.
| |
| | |
| 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.
| |
| | |
| == indice di affidabilita == | |
| | |
| 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
| |
| | |
| == sincronizzazione simbolo e blocco ==
| |
| | |
| il primo blocco e' preceduto da un simbolo o un blocco di start
| |
| questo riferimento deve avere autocorrelazione tendente a zero, essere abbastanza lungo (raro) da evitare false partenze, abbastanza corto da non creare overhead.
| |
| | |
| == path di trasmissione ==
| |
| | |
| | |
| 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 determinata lettera del 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.
| |
| | |
| == Interleaving ==
| |
| | |
| per mitigare questi problemi puo essere conveniente una qualche forma di interleaving sia in tempo che in frequenza.
| |
| | |
| prendiamo il caso di un blocco da 256 bit formato da 4 sottoblocchi quadrati da 64bit -> 16 simboli*16 toni contenenti ognuno 4 caratteri.
| |
| sarebbe ottimale anche per eventuali caratteri di controllo.
| |
| | |
| 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
| |
| | |
| [http://ciapini.contaminati.net/wiki/images/Interleaver.png]
| |
| [http://ciapini.contaminati.net/wiki/images/Interleaver8.png]
| |
| | |
| == Soft-Decision ==
| |
| | |
| 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.
| |
| | |
| == blocco header ==
| |
| | |
| Modalita':
| |
| | |
| '''punto-punto (non routed)'''
| |
| | |
| {|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
| |
| |style="color:red" 1b (cast)
| |
| ||1b (rout)
| |
| ||8b (src)
| |
| ||8b (dst)
| |
| ||6b (blk)
| |
| ||8b (cnt)
| |
| |}
| |
| | |
| '''punto-punto (routed)'''
| |
| {|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
| |
| |1b (cast)||1b (rout)||8b (src)||8b (dst)||4b (ttl)||1b (prio)||1b(FCN)||8b (seq)
| |
| |}
| |
| | |
| '''broadcast/multicast (non routed)'''
| |
| {|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
| |
| |1b (cast)||1b (rout)||8b (src)||4b (grp)||4b(flg)||6b (blk)||8b (cnt)
| |
| |}
| |
| | |
| '''broadcast/multicast (routed)'''
| |
| {|style="color:green; background-color:#ffffdd;" cellpadding="10" cellspacing="0" border="1"
| |
| |1b (cast)||1b (rout)||8b (src)||4b (grp)||4b(flg)||4b (ttl)||1b (prio)||1b(FCN)||8b (seq)
| |
| |}
| |
| | |
| campi:
| |
| * '''cast''' 0 unicast / 1 multicast.
| |
| * '''rout''' routing. i pacchetti routed hanno dimensione fissa di 1 blocco controllo (4byte) + 1 blocco dati (16byte), i pacchetti non-routed hanno un blocco controllo seguito da 1 a 64 blocchi dati da 16 byte.
| |
| * '''blk''' dimensione del blocco dati in multipli di 16byte
| |
| * '''src''' indirizzo del mittente
| |
| * '''dst''' indirizzo del destinatario
| |
| * '''cnt''' contatore incrementale dei pacchetti inviati dal nodo
| |
| * '''seq''' sequenza incrementale dei pacchetti inviati dal nodo
| |
| * '''ttl''' numero di hop massimi di routing
| |
| * '''pri''' priorita
| |
| * '''fcn''' forward congestion notification
| |
| * '''grp''' indirizzo del gruppo destinatario
| |
| * '''flg''' flag
| |
.png)
modem tascabile