Quote:
Originariamente inviato da cristoff
Ahahah si penso ne vedremo delle belle, sapevo che c'erano vari intoppi ancora ma non sapevo precisamente quali. Mi sapresti dire qualcosa di specifico sui problemi di interworking riscontrati?. Comunque per ora non se ne parla proprio! Anche i vendor si dicono non ancora pronti.
|
Guarda, già il solo vectoring da solo è un bel casino. Non so se conosci la tecnica, comunque per chi non la conoscesse, le cose stanno più o meno così (più o meno eh! Ho testato alcuni di questi sistemi ma non sono il massimo esperto):
Immaginiamo un mini-DSLAM con 90 potenziali attacchi utente. Bisogna misurare il crosstalk tra tutte le coppie una ad una su tutte le altre. Sono 90*89/2= 4005 misure, e si tratta di misure di attenuazione in ampiezza e fase su tutto il range di frequenze del VDSL; in pratica 3950 punti di frequenza per ogni misura (uno per ogni portante). Dato che il crosstalk è il segnale (proprio in ampiezza e fase) che "scavalca" tra una coppia e l'altra, si deve conoscere istante per istante il valore del segnale trasmesso su ciascuna coppia disturbante (89 coppie) per cancellarlo su quella disturbata, e il calcolo va fatto su tutte le coppie con tutti i segnali contemporaneamente e frequenza per frequenza, in ampiezza e fase. Si combina il tutto in un bel matricione di f[A] ciascuna di 3950 valori complessi (parte reale e parte immaginaria) composto da 90 equazioni. Ovviamente da risolvere in tempo reale.
Se i mini-DSLAM nel cabinet sono due questi si devono comunicare reciprocamente il matricione, continuamente e in tempo reale, alla velocità di simbolo (circa 4kHz). Se entrambe i DSLAM avessero 90 attacchi utente, in teoria sarebbe un bel flusso di dati tra i due DSLAM ad un bit rate di quasi 3Gb/s. Poi ci sono alcuni espedienti per ridurre il numero di calcoli, ad esempio non fare i calcoli su tutte le portanti, o non tenere conto delle coppie non collegate, etc etc.
Questi espedienti e come effettuare i calcoli in modo efficiente fanno parte delle proprietà intellettuali dei diversi costruttori.
Se i due DSLAM sono dello stesso costruttore allora le cose sono più semplici, e c'è speranza che tra loro si capiscano, e conoscano bene anche tutti i trucchi per limitare lo scambio di dati a bitrate ragionevoli.
Perché invece si capiscano DSLAM di costruttori diversi, è necessario stabilire un protocollo di interfaccia standard. E tuttavia questo protocollo non deve lasciar trapelare "i segreti" dei vari costruttori (e i dati da scambiare, sia pur in forma molto elaborata, contengono anche i bit trasmessi dai singoli clienti). E ovviamente ogni costruttore mira ad un protocollo che semplifichi al massimo la sua vita e complichi al massimo quella dei concorrenti (è il libero mercato). Se si tiene conto del fatto che su questi argomenti, a questo livello, ci saranno al massimo due o tre esperti per costruttore che sappiano davvero come funzionino le cose dentro il loro DSLAM, dunque esagerando una trentina di persone al mondo che possano mettere becco a ragion veduta su come fare per bene il protocollo (non certo quelli di AGCOM
)... forse si può capire come stabilire uno standard funzionante per bene ed efficiente per un sistema vectoring multivendor, non sia una cosa tanto semplice :-)