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 codificaReed-Solomon e sulla memoria di interleaving.
È conosciuto anche con nomi differenti:

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:

Fig. 1: Comparativa Interleaved/G.INP

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 fig. 1 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.

Fig. 2: Principio di funzionamentoIl 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 richiesta di ritrasmissione. Indipendentemente da questo meccanismo, tutte le DTU ricevute sono inserite nel buffer di ricezione R: se la DTU ritrasmessa arriva mentre la DTU originaria, ma corrotta, è presente nel buffer R, la prima sostituisce questa ultima. Salvo ritrasmissioni multiple, il round trip time è di circa 4 ms (2 ms per tratta). 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.

Per proteggere da SHINE/REIN il sistema garantisce ritrasmissioni multiple, in quanto è possibile che anche la DTU ritrasmessa sia corrotta dal rumore: ciò implica che il buffer R debba avere dimensione multipla di quello T (dipendentemente dalla dimensione di memoria del modem). I due buffer sono ottenuti riorganizzando la memoria di interleaving canonica e sono possibili due modalità di funzionamento: i dati in ricezione sono memorizzati nelbuffer R in ogni condizione oppure soltanto in caso di DTU errorata. Nel primo caso si ottiene un delay fisso sulla connessione. Nel secondo si ottiene soltanto un jitter quando interviene la ritrasmissione. Quest’ultima modalità è utilizzata da TIM. La ritrasmissione utilizza il FEC al ricevitore non per correggere le DTU, bensì per valutare se la DTU sia errorata ed ottenere il coding gain. Questo meccanismo produce ancora overhead, ma più basso (pochi punti percentuale in tutto) rispetto a quello del FEC tradizionale.

Fig. 3: Schema generico

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 interoperare 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:

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:

Fig. 4: Data Trasmission Unit

In fig. 4 e’ riportata la struttura della DTU con CRC.

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

Anche G.INP corregge gli errori con il meccanismo FEC, in effetti i due metodi sono equivalenti da questo punto di vista: il maggior numero di errori FEC con interleaved dipende dalla 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.

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 livellosoftware, ovvero tra client e server, come con TCP/IP. Ciò significa anche che, a differenza di quest’ultimo, tutto il traffico è protetto a priori³⁾.