View Single Post
Old 26-04-2016, 16:19   #68817
ironmark99
Senior Member
 
L'Avatar di ironmark99
 
Iscritto dal: Jan 2015
Città: Torino
Messaggi: 1599
Quote:
Originariamente inviato da fk0 Guarda i messaggi
E' impossibile trasmettere una sequenza di dati con un sistema analogico senza avere una certa quantita' di errori casuali, e il 99% del payload ne e' affetto se non addirittura del 100%; singifica che se non abbiamo u nqualche tipo di correzione non saremmo in grado di ricevere quasi nulla o nulla di integro ...cut...
Dunque, tu parli essenzialmente di sistemi di trasmissione via etere, di cui so ben poco. Tuttavia alcune cose non mi tornano molto...
Rispetto al fatto che se non si inserisce un qualche tipo di correzione non si riceve nulla di integro, sono d'accordo solo parzialmente.

Come ben saprai anche tu il teorema di Shannon-Hartley ci dice una cosa molto diversa. In pratica ci permette, data la banda e il rapporto segnale rumore di un canale trasmissivo, di stabilire un bitrate al di sotto del quale esiste SICURAMENTE una codifica di canale (si parla di codifica, ossia di una tabella di associazione tra valore da trasmettere e simbolo trasmesso, senza alcuna correzione) che permette di avere una trasmissione con tasso di errore nullo.

Il problema è che il teorema non ci dice quale sia questa codifica ne' si occupa della complessità di calcolo, della quantità di memoria, del numero di simboli da memorizzare e della latenza che ne consegue, necessaria per realizzarla. Tuttavia è utile per stabilire un confine di bitrate al di sopra del quale SICURAMENTE non potremo che avere errori, mentre al di sotto del quale un metodo per avere una trasmissione libera da errori esiste. Allora il primo provvedimento da prendere è restare al di sotto di questo fatidico confine.

Stabilito questo primo punto, il teorema, grazie ad alcuni calcoli inversi, ci permette anche di stabilire quale tasso di errore ci possiamo aspettare con una codifica non ottima, e con un rapporto segnale rumore inferiore a quello minimo.

Nel VDSL la banda associabile ad una singola portante è 4000Hz. La spaziatura delle portanti è 4312.5Hz ma i 312.5Hz di differenza tra questi due valori servono a inserire un simbolo di sincronismo e un prefisso ciclico (ossia il CRC, il valore utile in ricezione a stabilire se il simbolo ricevuto è corretto ed eventualmente a scartarlo anche se non a correggerlo). Dunque fino a qui nessun overhead di correzione di errore. Dato che la codifica (subottima) utilizzata nel VDSL è il QAM, è possibile calcolare quale sia l'SNR minimo per avere un certo tasso di errore. L'SNR minimo è di 9.75dB per avere una probabilità di errore di 1E-7. Poiché un simile tasso di errore non sarebbe accettabile (a 100Mbit/s significherebbe avere circa 10 errori al secondo costanti) e dato che la probabilità di errore diminuisce (molto approssimativamente) di circa 1 ordine di grandezza ogni dB aggiuntivo di SNR, si aggiungono quei famosi 6dB di SNR di margine di cui si legge continuamente. Questo ci porta ad avere bisogno di circa 15.75 dB di SNR per una probabilità di errore di circa 1E-13 (in realtà è circa 1E-12, per diversi motivi, uno dei quali è che non tutto il rumore sul canale è gaussiano, ad esempio la diafonia non lo è completamente). Questo valore comporta la probabilità di avere 1 bit errato ogni 1E12 bit ricevuti ossia 1 bit ogni 1000Gbit (che a 100Mbit/s danno un errore ogni 10000 secondi). Si ha a questo punto che 6dB di margine garantiscono una probabilità di errore molto bassa, sufficiente a soddisfare i requisiti di una trasmissione di qualità secondo gli standard internazionali anche per l'HD video. Tutto ciò senza aver ancora introdotto alcun codice di correzione degli errori, e dunque nessuna ridondanza (a parte quella di sincronismo, che è però una ridondanza strutturale e non di codifica).

Un primo provvedimento per correggere gli errori residui è l'uso del Trellis code modulation. L'overhead legato al trellis code è di 1 bit ogni due portanti (effettivamente utilizzate). Dunque considerando utilizzate tutte le 4096 portanti del profilo 17a, si avranno 2048 bit di overhead per simbolo. La frequenza di ripetizione del simbolo NETTO è 4kHz, dunque l'overhead del trellis code risulta 8192kbit/s. In compenso il Trellis ci da il vantaggio di guadagnare 4.2dB sul SNR minimo necessario e dunque i 15.75 dB si riducono a 11.55dB minimi per avere 6dB di margine sul tasso di errore di 1E-7. Un simile guadagno di SNR permette di aggiungere almeno 1 bit su ciascuna portante utilizzata, a fronte del suo utilizzo di 1 bit ogni due portanti, e dunque l'impiego del Trellis si ripaga da sé, con l'aggiunta di un guadagno di altrettanto bitrate, oltre alla correzione d'errore che introduce, sufficiente ad annullare il BER residuo dovuto al rumore gaussiano.

Purtroppo il rumore gaussiano non è l'unico elemento a generare errori nella trasmissione. Ben più imprevedibili e dannosi sono i disturbi impulsivi, ossia quei picchi di tensione e corrente indesiderati derivanti dal mondo elettromagnetico circostante che si accoppia alla nostra linea, grazie alla sua "imperfezione". Per proteggere il nostro canale da tali disturbi possono essere impiegati due metodi diversi e tra loro alternativi:
  • INP e delay
  • G.INP (ossia la ritrasmissione a livello fisico) detto anche PHY-R
Per poter attivare questi metodi è necessario l'uso di un ulteriore codice di correzione dell'errore: il Reed-Solomon code. L'overhead che deriva dall'impiego di questo codice varia in funzione del valore di INP e delay richiesti, ossia in funzione del numero di simboli che si desidera poter correggere nell'unità di tempo stabilita dal delay. Il calcolo è:

(2 * INP)/(delay * 4000)

Per un valore tipico di INP/delay di 2/8 avremo che l'overhead del Reed-Solomon coding è pari a (2 * 2)/(8E-3 * 4E3) = 4/32 = 1/8 = 12.5% che è un overhead piuttosto alto! Si noti infatti che, poiché la durata temporale di un simbolo è di circa 250uS, 1ms di trasmissione contiene 4 simboli. La configurazione a INP2 e delay 8ms equivale a richiedere che sia inserito l'overhead di 4 simboli ogni 32, da cui l'hoverhead di 1 a 8 simboli. In compenso il Reed-Solomon coding ci fornisce ulteriori 2.5dB di guadagno sul SNR minimo necessario. Tuttavia i guadagni dati dal Trellis e dal Reed-Solomon non si sommano tra loro in modo lineare e il guadagno complessivo netto diventa di soli 5.5dB, portando l'SNR minimo necessario su ciascuna portante ad avere un margine di 6dB al tasso di errore di 1E-7 a 10.25dB.

Il vantaggio di utilizzare la ritrasmissione è che il numero di simboli di hoverhead che risulta necessario inserire è estremamente più basso (l'esatta quantità di hoverhead introdotta dipende dalle scelte del fornitore di servizi) a parità di protezione, ma il suo impatto può essere valutato intorno a 1/10 - 1/15 rispetto a quello precedentemente descritto. A parità di impatto di overhead si possono ottenere quindi protezioni da 10 a 15 volte più alte che con l'INP/delay tradizionale. Ciò accade poiché non è necessario calcolare il simbolo corretto a partire dallo stream di dati ricevuto (e quindi non è necessario inserire l'iformazione necessaria a ricalcolarlo); la correzione avviene infatti grazie alla ritrasmissione dei simboli trovati errati. Inoltre la latenza, che col meccanismo di INP/delay tradizionale esiste per tutti i simboli (e il ping minimo ottenuto è pari dunque al delay richiesto), con la ritrasmissione esiste solo in presenza di simboli errati, e dunque in assenza di disturbi impulsivi il ping è simile a quello di un fastpath (ossia di un sistema senza protezione da disturbi). Tutto ciò si traduce nel fatto che la protezione equivalente mostrata dai nostri modem si aggira intorno al valore di 60 simboli, con un ritardo minimo.

Spero con ciò di aver risposto alle tue domande.

P.S.Tutto ciò, ovviamente salvo errori ed omissioni!!
P.S. Ragazzi... voi mi obbligate a disossidare il cervellino con le vostre domandine facili facili. Mi tocca andare a rileggere e rinfrescare i miei appunti e le mie vecchie esperienze. Grazie per tenermi in allenamento il neurone...
__________________
Il mio PC autocostruito e raffreddato ad acqua: http://irom.eu/w --- Qui tutti i miei interventi su HU --- Modem reader: qui l'installer e qui l'help on line --- Qui il simulatore VDSL v3.0
ironmark99 è offline   Rispondi citando il messaggio o parte di esso