ilpuntotecnicoeadsl

Introduzione

Standardizzato nel 2009 e definito da esperti del settore come protocollo “miracoloso”, G.INP si prefigge di superare i limiti, ancora attuali, relativi ai tradizionali metodi di protezione dai rumori impulsivi, basati sulla codifica Reed-Solomon e sulla memoria di Interleaving.
È conosciuto anche con nomi differenti:

• G.998.4, dalla specifica ITU-T che lo descrive.
• PhyR, versione proprietaria sviluppata da Broadcom.
• Ritrasmissione (RTX), come viene solitamente chiamato dagli ISP.

Punti di forza

Non è un caso che venga considerato quasi indispensabile per raggiungere elevati valori di portante dati su rame: G.INP aumenta la stabilità delle linee xDSL grazie ad un maggior coding gain, diminuisce l’overhead, con conseguente aumento della portante ottenibile, e la latenza, allineandola pressoché ai livelli garantiti dalla modalità fastpath.

Segue un elenco dei vantaggi salienti:

• È applicabile a modulazione xDSL con incapsulamento sia ATM sia PTM (Ethernet). Attualmente in Italia è utilizzato ufficialmente soltanto in ambito VDSL.
• Supporta alti valori di INP (maggiori della soluzione basata su Reed-Solomon ed Interleaved) in grado di contrastare rumori impulsivi più lunghi (di solito fino a 10 ms).
• Non prevede più un delay fisso, al contrario dell’Interleaving, bensì soltanto Jitter che si manifesta in caso di evento di errore.
• La ritrasmissione sottrae banda al flusso dati soltanto durante gli eventi di errore, quindi in assenza di rumore impulsivo la linea non è penalizzata a priori.
• Introduce overhead fissi molto ridotti, consentendo, a parità di lunghezza rete di accesso e parità di rumore, un bitrate maggiore rispetto ad analoga linea con protezione Reed-Solomon (con un guadagno spesso superiore al 10%).
• Consente di diminuire i valori di SNRm nei profili utilizzati, che erano utilizzati impropriamente contro il rumore impulsivo per le linee instabili.
• Permette di coprire un ampio spettro di rumori impulsivi domestici, ad esempio:
  1. REIN: impulsi brevi ripetitivi a 100 Hz (spesso derivati da alimentatori AC/DC difettosi)
  2. SHINE: impulsi molto lunghi non ripetitivi (provenienti da utenze elettriche domestiche)

 

Broadcom afferma che tale tecnologia garantisce una resistenza ai rumori impulsivi fino a dieci volte superiore alla controparte interleaved, condizione che si traduce in un significativo miglioramento del BER (Bit Error Rate) residuo ed in una diminuzione dei pacchetti persi.

Certo è che, nonostante oggettivi vantaggi, esistono limiti al livello di protezione garantito da G.INP, il quale non può rappresentare una soluzione “universale” adatta ad ogni tipologia di rumore impulsivo.

Ad esempio come riportato in figura per la presenza costante di burst molto brevi e ripetitivi (esempio i REIN), la protezione sempre presente che RS + Interleaved offrono (penalizzando costantemente la linea) potrebbe essere più adatta di G.INP. Contrariamente, per impulsi lunghi e poco ripetitivi (es. SHINE, i più pericolosi) G.INP offre la migliore soluzione.

 

Come funziona?

 

Il buffer di ritrasmissione T memorizza in unità DTU (Data Transmission Unit) i dati trasmessi. Ogni DTU è controllata alla ricezione: per quelle corrotte dal rumore viene subito inviata una richiesta di ritrasmissione. Indipendentemente da questo meccanismo, tutte le DTU ricevute sono inserite in un buffer di ricezione R per riorganizzarle nella corretta sequenza temporale in caso di ritrasmissione: quando la DTU ritrasmessa arriva al buffer di ricezione viene sostituita alla DTU originaria (corrotta) che ancora era presente nel buffer R. Salvo ritrasmissioni multiple, il round trip time è di circa 4 ms (2 ms solo andata). La capacità totale di protezione ed il Jitter introdotto dipendono principalmente dalla profondità del buffer R: il tempo di attraversamento di tale buffer costituisce il delay introdotto dal sistema. È un parametro di configurazione del profilo di protezione e come tale costituisce un vincolo sulla capacità di protezione massima.

Nel G.INP il FEC non viene utilizzato per correggere la DTU (ossia il pacchetto di dati) corrotta ma solo per individuare quelle che contengono errore e calcolare il coding gain. La correzione avviene a tutti gli effetti ritrasmettendo l’intera DTU. Il numero di FEC indicati dal modem di fatto coincide col numero di ritrasmissioni avvenute. Il conteggio dei CRC invece mostra il numero di DTU che non è stato possibile correggere neppure con la ritrasmissione, e che dunque dovranno essere corrette dai livelli superiori (TCP o applicativo). Il fatto che la latenza resti bassa anche in presenza di molti FEC (e dunque ritrasmissioni) è dovuta al fatto che l’aumento di latenza di 4ms non è cumulativo per ogni ritrasmissione avvenuta, ma complessivo.

Ad esempio a 100Mbit/s le DTU sono circa 700/s (ogni DTU contiene 65byte di payload più alcuni byte di overhead) e virtualmente il meccanismo sarebbe in grado di correggere tutte le DTU errate, ma almeno due fenomeni lo impediscono.

Il primo dipende dal fatto che anche le DTU ritrasmesse, come detto prima, possono essere corrotte dal rumore durante la ritrasmissione (in caso di rumori particolarmente grandi), e in tal caso devono essere ritrasmesse nuovamente. Per limitare questa possibilità esse viaggiano su un canale riservato (bearer 1) sul quale la protezione dall’errore è data da un meccanismo più potente di correzione immediata (Extended Golay Code) al quale si devono i 4ms di latenza di questo canale.

Ciò porterebbe il ritardo di ritrasmissione al doppio del normale (8ms) e nel frattempo la DTU corrotta immagazzinata nel buffer di ricezione R potrebbe esserne già fuoriuscita (dipende dalla profondità del buffer) e a quel punto si avrebbe un CRC, ossia la presenza di una DTU non corretta. Ciò implica che il buffer R teoricamente dovrebbe avere dimensione multipla di quello T (dipendentemente dalla dimensione di memoria del modem). Poiché se il buffer R fosse dimensionato per contenere almeno 8ms di DTU, non si avrebbe il CRC ma soltanto un picco di latenza di 8ms. Questo raddoppiarsi della latenza dovuta alla ritrasmissione sarebbe comunque un fenomeno molto raro (dato che una doppia ritrasmissione non dovrebbe accadere se non in casi estremi), e che sposterebbe di pochissimo la latenza media.

Il secondo fenomeno che rende impossibile correggere tutte le DTU è che il bearer 1, su cui viaggiano le ritrasmissioni, sottrae banda al bearer 0 su cui viaggia il normale flusso dati. Se si dovessero ritrasmettere tutte le DTU (a causa di un rumore impulsivo davvero grave) in pratica si dimezzerebbe il bitrate del canale, portando l’overhead del meccanismo a valori troppo elevati (anche se sarebbe un overhead dinamico, presente solo in caso di disturbi davvero imponenti). Si preferisce dunque limitare il massimo possibile bitrate sostenibile dal bearer 1 ad una frazione del massimo bitrate del canale. Questa operazione di fatto limita il numero massimo di errori correggibili nell’unità di tempo.

 

 

Standard ITU-T G998.4

Lo standard afferma che la struttura del frame DTU è definita in modo tale da essere trasparente alla posizione dei buffer di ritrasmissione. La coda può essere inserita a qualsiasi livello della struttura del transceiver e deve inter-operare con un altro dispositivo in cui sia posizionata ad un altro livello. Il protocollo è simile a quello Alpha-Layer con gestione ACK/NACK delle DTU ricevute. Il pacchetto RRC (Retransmission Return Channel) è formato da 3 byte e riporta le informazioni sul numero di DTU corrette ricevute.

Sono stati definiti inoltre parametri di controllo aggiuntivi:

• ETR: Expected Throughput, è la banda passante (data rate) disponibile in show time assumendo piena protezione contro il rumore impulsivo con i parametri impostati
• SHINEratio: la perdita di data rate nell’intervallo di 1 secondo dovuta ai rumori SHINE attesi dall’operatore.
• INP_min_REIN: minimo INP desiderato contro i REIN.
• NET_rate: data rate in show time in assenza di rumore impulsivo.
• Altri…

 

Data Trasmission Unit, per gli amici DTU

La DTU è sincronizzata con un numero intero di RS codeword, e contiene un numero di simboli DMT compresi tra 0.5 e 4.
Per definizione contiene:

• un numero intero di celle ATM o di pacchetti PTM
• 1 byte identificatore di sequenza (SID)
• 1 byte di Time Stamp (TS)
• W byte di Overhead di CRC (il valore suggerito in normativa è 1 byte, ma può anche essere minore o assente)
• V byte di padding (a discrezione del Vendor)

Nella figura è riportata la struttura della DTU con CRC.

 

Qualche riflessione: G.INP versus Interleaved

Capacità di correzione

Con modulazione G.INP attiva si rileva di frequente una netta diminuzione degli errori di trasmissione, rispetto alla modalità interleaved. Come si spiega?

Il maggior numero di errori FEC con interleaved dipende dall’efficienza di G.INP e da un differente metodo di calcolo: varia la lunghezza delle code word usate, variano altri parametri, quindi con G.INP gli errori “sembrano” meno numerosi non risultando “sparpagliati” come in interleaved. D’altronde sapendo che con la ritrasmissione l’INP equivalente passa da 2 a 54-56 simboli, possiamo immaginare che l’organizzazione del rilevamento dei simboli errati sia in un qualche modo differente.
INP corregge gli errori localmente grazie all’overhead introdotto, ma ha dei limiti sugli errori adiacenti, ed è per questo che esiste la memoria di Interleaving (che introduce il delay), nella quale blocchi adiacenti di errori vengono “sparpagliati” e resi non più consecutivi. Perciò una singola catena di errori appare come un insieme di errori indipendenti. Al contrario con G.INP lo “sparpagliamento” non avviene (niente memoria di Interleaving, niente più delay) poiché tutto il simbolo viene ritrasmesso, e molte catene di errori sono interpretati come un singolo errore.

Tempi di risposta (latenza)

Grazie ad Interleaving delay configurato a 0 una linea con G.INP attivo offre valori di latenza paragonabili ad una linea in fastpath. Persino in presenza di errori di trasmissione, e relativo Jitter di ritrasmissione, la latenza rimane potenzialmente minore a quella di una linea in interleaved grazie al già citato valore di round trip time, ben inferiore ai 45-50 ms mediamente impiegati dal protocollo TCP/IP. Il tempo di ritrasmissione è così ridotto poiché la correzione avviene a livello fisico tra DSLAM e modem, e non a livello software, ovvero tra client e server, come nei livelli superiori dello stack TCP/IP. Ciò significa anche che, a differenza di quest’ultima eventualità, tutto il traffico è protetto a priori, sia TCP che UDP (quest’ultimo per la sua natura connection-less non prevede ritrasmissioni di datagrammi errorati).

Copyright 2017 Tutti i diritti riservati.
Il presente articolo non può essere copiato, modificato, distribuito, con alcun mezzo senza l’esplicita autorizzazione dell’autore e dello staff de ilpuntotecnico.com