Docstoc

Rel_scient_linea2_completa

Document Sample
Rel_scient_linea2_completa Powered By Docstoc
					      Progetto di ricerca applicata CNR 5%
"Rete multimediale interattiva di accesso all'utente"




                      Linea 2:

   "SERVIZI MULTIMEDIALI INTERATTIVI
        SU RETE OTTICA PASSIVA"


                   Responsabile:

               Prof. Giancarlo Prati
          Scuola Superiore “Sant’Anna”
   di Studi Universitari e Perfezionamento, Pisa




         RAPPORTO SULL’ATTIVITA’
            DEL SECONDO ANNO




                   Gennaio 2001
  Premessa
  Questo rapporto riassume le attività svolte nel secondo anno dalle unità di ricerca coinvolte
nella Linea 2: “Servizi multimediali interattivi su rete ottica passiva” del Progetto di ricerca
applicata 5% "Rete multimediale interattiva di accesso all'utente".
  Hanno svolto attività le unità di: Marconi Communications, CSELT, Università di Parma,
Politecnico di Bari, e Università di Ancona. L‟unità della Fondazione “U. Bordoni” si è ritirata
dal progetto e non ha svolto attività.
  Con riferimento al documento di definizione del progetto, ed in particolare alla
pianificazione temporale ivi riportata, i temi oggetto di attività delle unità indicate a fianco di
ciascuno sono stati i seguenti:

  Tema 2.1 – Applicazione di teledidattica multimediale interattiva (UniPR)
  Tema 2.2 – Definizione del dimostratore
  Tema 2.3 – Progetto del sistema dimostratore (Marconi, CSELT, UniPR, UniBA, UniAN)
  Tema 2.4 – Progetto e realizzazione degli apparati (Marconi)
  Tema 2.5 – Soluzioni per l‟optical manteinence (CSELT, UniPR)
  Tema 2.6 – Integrazione del dimostratore (CSELT, Marconi, UniPR)
  Tema 2.7 - Dimostrazione (UniPR, CSELT, Marconi)

  L‟attività si è sviluppata a partire dalla situazione raggiunta alla conclusione del primo anno
nel quale è stata realizzata una prima versione del dimostratore (detta “di fase 1”).
  L‟attività del secondo anno del progetto è stata, in particolare, dedicata ai seguenti temi:
   verifiche protocollari teoriche e pratiche del funzionamento degli apparati di rete
      (escluse ONU e OLT in quanto la parte PON vera e propria, come si vedrà, non è
      ancora presente);
   configurazione degli stessi apparati e dei PC satelliti;
   misure di banda (intesa come velocità di trasmissione dei bit), cioè della bontà della
      rete ATM-ADSL in termini trasmissivi, e di qualità del servizio (QoS) in termini di
      accessibilità ed erogabilità (throughput);
   sviluppo di applicativi ad „hoc‟ per l‟erogazione e la fruizione dei servizi (sia di tipo
      diffusivo sia di tipo collaborativo)
definizione della struttura necessaria alla manutenzione ottica e sua integrazione sul
dimostratore.

Questo rapporto è costituito dalle seguenti relazioni:
Attività dell‟unità di Parma sui temi 2.2, 2.3, 2.5, 2.6 e 2.7 (Pagg. 1-42)
Attività dell‟unità di Parma sul tema 2.1 (Pagg. 43-50)
Attività dell‟unità di Ancona (Pagg. 51-58)
Attività dell‟unità di Bari (Pagg. 59-66)
Attività dell‟unità industriale CSELT sui temi 2.3 e 2.6
Attività dell‟unità industriale CSELT sul tema 2.5
Attività dell‟unità industriale Marconi Communications sui temi 2.3, 2.4 e 2.6

Le relazioni delle unità di Parma, Ancona e Bari hanno numerazione di pagine comune.
Le relazioni industriali hanno ciascuna la propria numerazione di pagine.

La prima relazione (Attività dell’unità di Parma) funge anche da introduzione generale.
        Progetto di ricerca applicata CNR 5%
  "Rete multimediale interattiva di accesso all'utente"

                        Linea 2:
 "Servizi multimediali interattivi su rete ottica passiva”




              Unità di ricerca della
      UNIVERSITA’ DEGLI STUDI DI PARMA


                Rapporto sull’attività del
                  SECONDO ANNO
                   relativa ai Temi:

      2.2 - “DEFINIZIONE DEL DIMOSTRATORE”
2.3 - “PROGETTO DEL SISTEMA DIMOSTRATORE”
2.5 – “SOLUZIONI PER L'OPTICAL MAINTENANCE”
    2.6 – “INTEGRAZIONE DEL DIMOSTRATORE”
                2.7 – “DIMOSTRAZIONE”


                   Hanno collaborato:

           Prof. Giorgio Picchi (Responsabile)
                   Ing. Piero Castoldi
                  Ing. Andrea Morelli
                      Ing. Ivo Neri
                   Sig. Marco Ghizzi
                   Sig. Filippo Cugini




     Dipartimento di Ingegneria dell’Informazione



                     Novembre 2000


                                                             1
1. - Obiettivi generali del progetto
   Obiettivo centrale del progetto (Linea 2) è la dimostrazione, tramite
una applicazione di teledidattica interattiva multimediale sviluppata "ad hoc", della
funzionalità di una rete ottica di accesso all'utente di tipo PON (Passive Optical
Network).
   Il test-bed previsto per il dimostratore è il Parco Area delle Scienze (Campus)
dell'Università degli Studi di Parma dove, su un‟estensione di circa 80 ettari, esiste
una rete in fibra ottica che raggiunge i numerosi edifici del parco fra i quali esistono
un centro per la produzione di materiali multimediali per la didattica e aule con
personal computer e workstation a disposizione di studenti e ricercatori.
   Le esigenze specifiche del progetto hanno in ogni caso richiesto un aggiornamento
della rete in fibra la cui realizzazione è già stata completata.
   L'infrastruttura del dimostratore sarà costituita da una rete ottica passiva (PON) con
una potenzialità di 60 utenti. La sperimentazione sarà ad ampio spettro, in quanto
consentirà sia di valutare le soluzioni adottate per l'infrastruttura ottica di tipo
innovativo, in termini di tecniche e di protocolli, sia di verificare la funzionalità e
l'efficacia dello strumento software che è da sviluppare per l'applicazione specifica
cui si fa riferimento.
L'applicazione da sviluppare ha come obiettivi: quello di rendere disponibile agli
studenti, con modalità del tipo "Video on Demand" (VoD), una lezione registrata su
videocassetta e memorizzata in un videoserver (VS) centralizzato, con video e audio
fruibile su personal computer o workstation, ed, eventualmente in contemporanea,
consentire la condivisione di un documento di esercitazione tra studente ed istruttore
in real-time, con finestre video e audio a due vie per l'immagine degli interlocutori. Il
dialogo interattivo tra docente e studente tramite lo strumento collaborativo permette
due tipi di attività didattica:
  1) Lezioni e seminari tenuti dal docente ad una platea che è limitata solo dalla
       vastità del parco Client, in questo caso il grado di interattività è basso e si pone
       ad un livello intermedio tra il VoD e quello propriamente collaborativo ed il
       docente si viene a trovare in un‟aula appositamente attrezzata per tale tipo di
       erogazione (Aula di Teledidattica);
  2) Esercitazioni, verifiche e spiegazioni per singoli studenti da parte del docente, in
       questo caso si ha un elevato grado di collaborazione tra i due ed il docente può
       rimanere nel proprio ufficio se questo è dotato di una stazione multimediale con
       una connessione dedicata a larga banda (anche in Ethernet) alla rete; la lezione
       individuale può anche diventare pubblica se altri Client si collegano
       (collaborando anch‟essi o semplicemente come auditori).
Si noti che, potendo tranquillamente coesistere tra loro, senza che vi sia alcun
problema, i servizi ai punti 1) e 2) e di VoD (mentre alcuni Client formano la platea
del seminario, altri possono dialogare con un docente nel proprio ufficio ed i
rimanenti possono usufruire del servizio di VoD), si ha un‟elevata eterogeneità dei
servizi che possono essere erogati simultaneamente.
   E' importante sottolineare che le soluzioni di infrastruttura potranno essere
applicate anche a contesti non necessariamente di teledidattica quali quelli
commerciali, di intrattenimento e di servizio all'utente.




                                                                                         2
2. – Definizione e progetto del dimostratore (Temi 2.2 e 2.3)

2.1 – Schema generico di una rete PON
  Una rete PON (il cui schema generico è riportato in figura 1) interagisce con i livelli
superiori della rete per mezzo di una OLT (Optical Line Termination) che è la “radice”
della rete ottica passiva. La OLT è collegata alle varie ONU (Optical Network Unit),
che sono le unità periferiche che convertono il flusso ottico in elettrico distribuendolo
in una rete locale (downstream) dalla quale raccolgono traffico che instradano, in
forma ottica, verso la OLT (upstream). Il collegamento fra la OLT e le ONU è
costituito da una rete ad albero completamente ottica ODN (Optical Distribution
Network) che non contiene elementi attivi come amplificatori o commutatori. Il
segnale ottico è distribuito dalla OLT alle ONU con un diramatore ottico (splitter) che
funziona come divisore di potenza. Il fatto di non contenere elementi attivi nella rete
elimina completamente i problemi di powering e migliora l‟affidabilità del sistema.
  La trasmissione downstream (dalla OLT alle ONU) avviene mediante multiplazione
a divisione di tempo (TDM – Time Division Multiplexing). La trasmissione upstream
(dalle ONU alla OLT) avviene mediante accesso multiplo a divisione di tempo (TDMA
– Time Division Multiple Access). Questo permette di gestire i flussi di dati trasmessi
dalle varie ONU alla OLT, e consente la allocazione dinamica degli spazi temporali
assegnati ad ogni utente.

                                                                            ONU 1

                 TDM
                                Splitter                                     ..
     OLT                                          ..                         ..
                                1xN
                                                  ..                         ..
                 TDMA                             ..                         ..
                                                  ..

                                                                            ONU N


                                            ODN




            OLT: Optical Line Termination
            ONU: Optical network Unit
            TDM: Time-Division Multiplexing
            TDMA: Time Division Multiple Access
            ODN: Optical Distribution Network


                          Figura 1 – Schema generico di una PON


                                                                                       3
  Come si legge nel documento di descrizione del progetto (p. 4), la rete PON da
realizzare sarà costituita da un ramo “radice” connesso ad una unità OLT e da due
rami terminali ottenuti mediante una diramazione ottica (splitting) ciascuno connesso
ad una ONU. Le due ONU saranno collocate in diversi edifici dove tuttora esistono
sale attrezzate con personal computer e workstation. Come accennato, il numero di
punti di lavoro (personal computer o workstation) serviti complessivamente dal
dimostratore è previsto in 60.


2.2 – Approccio alla definizione dell’architettura del dimostratore
   Analizzata la letteratura disponibile sul progetto di sistemi PON e ritenuto
opportuno capitalizzare l‟esperienza di Marconi Communications nella progettazione
e realizzazione di sistemi ed per il trasporto la distribuzione di servizi a larga banda,
si è individuata una soluzione in cui la rete PON è introdotta come elemento di
flessibilità in un sistema di rete di accesso (il DSLAM mod. MAT14, descritto nel
prossimo paragrafo) attualmente in produzione da parte di Marconi Communications.
Questa scelta consente di sfruttare un sistema industriale già disponibile per
l‟infrastruttura in cui la rete PON viene inserita ereditando interfacce standard sia
verso il lato videoserver sia verso il lato utenti con conseguente semplificazione
dell‟integrazione. Oggetto di specifica attività Marconi nell‟ambito del progetto è lo
sviluppo delle parti di interesse tecnologico (in particolare delle unità OLT e ONU)
necessarie a consentire l‟introduzione di una PON nel citato sistema di rete di
accesso.


2.3 – Il DSLAM di Marconi Communications
  Il sistema MAT14 è un DSLAM (Digital Subscriber Loop Access Module) ossia un
sistema che si colloca come interfaccia fra una rete di trasporto a larga banda di tipo
ATM (Asynchronous Transfer Mode) ed una rete di accesso di tipo ADSL
(Asymmetric Digital Subscriber Line) in grado i fornire servizi multimediali ad alta
velocità su doppino telefonico. Il sistema interfaccia i segnali a larga banda
trasportati dalla rete ATM, elabora le informazioni di instradamento e invia i segnali
sull‟appropriata interfaccia ADSL verso un apparato di terminazione (NT, Network
Terminator) situato presso l‟utente.
  Il MAT14 è un apparato modulare che può essere connesso alla rete ATM con una
o due interfacce di livello STM-1 (Synchronous Transfer Mode 1) ciascuna a
155,52 Mbit/s, mentre sul lato distribuzione può essere equipaggiato con un
massimo di 8 di unità da 6 linee ADSL ciascuna, per un totale di 48 linee ADSL.
  La connessione fisica sul lato ATM può avvenire sia in rame sia in fibra ottica. Più
oltre sarà chiarito come quest‟ultimo aspetto sia importante per la realizzazione del
dimostratore.
  L‟impiego tipico del DSLAM è illustrato in Figura 2.
  Il complesso del DSLAM utilizzato per le sperimentazioni in questa fase,
rappresentato nello schema di Figura 3, è costituito da quattro schede:




                                                                                       4
    Service                                                      Cavo di                NT
    Provider                                                     doppini
                                               DSLAM                                    NT
                   Rete                Interfacce   Interfacce
                   ATM                 STM-1        ADSL

                                                                                        NT
    Service                                                        Combinatore
    Provider              Rete
                          telefonica                                       Separatore    #




                     Figura 2 – Impiego tipico del DSLAM

      un Controller;
      una scheda 2xSTM-1;
      un MUX ADSL;
      una scheda 4xADSL line

 Segue una breve descrizione delle piastre nel DSLAM dal punto di vista funzionale.

Il controller memorizza le configurazioni delle schede contenute nel cestello
(quindi servirebbe ad inizializzarle all‟accensione del DSLAM) e potrebbe essere
impiegato per modificare tali configurazioni durante il normale funzionamento della
rete. Durante la fase di sperimentazione corrente, tuttavia, tale scheda non è stata
utilizzata e queste operazioni sono state svolte manualmente collegandosi alle
singole schede direttamente mediante la porta seriale di un PC.




                          Figura 3 – Il DSLAM MAT14


                                                                                             5
La scheda 2xSTM-1 svolge, in sostanza, alcune delle tipiche funzioni di uno switch
ATM, effettuando le operazioni necessarie alla gestione di traffico ATM. Dopo una
prima conversione opto-elettronica, l‟ATM abbandona il substrato fisico SONET e
s‟interfaccia a quello ADSL tramite un bus UTOPIA (Universal Test and Operations
Physical Layer Interface for ATM), cui vengono passati i pacchetti; su di essi
vengono svolte in successione le seguenti operazioni:
    un primo blocco si occupa di effettuare l'address reduction (il riconoscimento
       degli indirizzi e il cambio di etichetta), traffic monitoring (il monitoraggio del
       traffico affinché non vengano ecceduti i limiti negoziati) e policing (la politica di
       gestione dei parametri relativi alla classe di traffico);
    un secondo blocco è in grado di gestire, se e quando lo si riterrà necessario,
       tutto il complesso delle OAM;
    l'ultima funzione realizzata dal dispositivo prevede uno shaping del traffico, che
       si rende necessario per essere convogliato in canali ADSL, a più bassa velocità
       di trasmissione.
   Per effettuare queste operazioni bisogna, ovviamente, innanzi tutto riconoscere
che i pacchetti che arrivano al DSLAM siano effettivamente destinati ai PC come
traffico PON: per far ciò si utilizzano delle memorie CAME (Content Addressable
Memory), molto costose. Esse andrebbero replicate per ognuno dei blocchi elencati.
Per evitare che i costi lievitino, tuttavia, si adotta uno stratagemma che consente di
utilizzare memorie convenzionali più economiche: il primo blocco, in sintesi, è l'unico
ad interrogare un database basato sulle CAME che contiene le coppie [VPI, VCI]
(Virtual Path Identifier, Virtual Channel Identification) consentite, dopo di che si
procura di sostituire tale coppia dell'header ATM con dei valori ECI; nei successivi
blocchi vengono quindi utilizzate delle classiche RAM (Random Access Memory,
comuni memorie volatili) alle cui locazioni di memoria puntano gli ECI
precedentemente incapsulati nei pacchetti.
   La scheda 2xSTM-1 è in grado di gestire un traffico di dati a 155Mbps nelle due
direzioni; poiché però nelle trasmissioni cui la PON è orientata si ha
caratteristicamente un traffico sbilanciato, verso il videoserver la banda utile è di soli
10Mbps.
   In termini di configurazione, in tale dispositivo vengono dapprima attivati i canali
lungo i quali il traffico deve passare, quindi vengono instaurati i circuiti virtuali: le
etichette che vengono fornite via console devono ovviamente coincidere con quelle
pre-configurate allo switch e a ciascuna di esse viene associato un valore ECI
progressivo per gli utilizzi suddetti, secondo la tabella di Figura 4.




          Figura 4 – Matrice degli instradamenti relativa alla fase attuale


                                                                                          6
Il MUX ADSL, cui è demandato il compito del multiplexing statistico del traffico, si
occupa inoltre di programmare l‟indirizzo corretto di ogni porta fisica (la coppia PNE-
PNU, Port Number Esteso – Port Number UTOPIA: l‟indirizzamento del bus UTOPIA
è stato suddiviso in due livelli a passo diverso secondo una soluzione proprietaria
Marconi) in base alla tabella di Figura 4, in maniera tale da consentire d‟interfacciare
la prima scheda con quelle ADSL per mezzo dei 50 fili di UTOPIA.

Il Bus UTOPIA è un‟interfaccia parallela nata per standardizzare la connessione
tra dispositivi ATM, permettendo di indirizzare fino a 32 dispositivi diversi. UTOPIA
s‟inquadra nell‟ambito delle interfacce interne di sistema, a livello di chip o di scheda,
che consentono una maggiore interoperabilità tra apparati di produttori differenti. Più
precisamente, l‟ATM Forum ha sviluppato UTOPIA come un‟interfaccia data path tra
il livello fisico di ATM e il livello ATM stesso, che svolga le funzioni di gestione e
controllo, come si vede in Figura 5.




               Figura 5 – Configurazione di riferimento di UTOPIA
   Esso consente quindi ad ATM di interfacciarsi con una varietà di protocolli, velocità
e tipi di portante del livello fisico: nel caso del DSLAM in nostro possesso, ad
esempio, il livello fisico adotta una soluzione proprietaria dell‟unità industriale.
   Più in dettaglio, sono stati definiti due livelli di UTOPIA:
    il livello 1, basato su un data path a 8 bit, opera a 25MHz, supporta frequenze di
       segnalazione fino a 155Mbps (ATM Forum, 1994f) ed è “single-user”,
       consentendo la connessione con un solo livello fisico;
    il livello 2, basato su un data path 8-bit/16-bit, è in grado di operare con due
       frequenze di clock supplementari di 33 e 50MHz, consente bit-rate fino a
       622Mbps (ATM Forum, 1994g) e garantisce il supporto di livelli fisici multipli in
       connessione a multipli livelli ATM.
   Un‟area di sviluppo di tale standard riguarda l‟elaborazione dell‟HEC (Header Error
Check) della cella ATM; sebbene tale funzione sia considerata di pertinenza del
livello fisico, UTOPIA si occupa del trasferimento dell‟HEC ai livelli ATM per
permetterne l‟elaborazione. Mentre su di un 8-bit path viene spedita una singola
cella, su di uno a 16 bit vengono spediti due ottetti di cella ATM in parallelo. Una
caratteristica interessante è poi che la cella del livello 2 di UTOPIA è di 54 ottetti,
contenente due campi UDF (User DeFined) che trasportano l‟HEC.




                                                                                        7
  In questa breve descrizione dello standard UTOPIA, vale la pena di evidenziare
anche che, sebbene tale bus sia al momento definito solo tra il livello fisico e i
sottolivelli ATM, può essere esteso fino ad includere l‟interfaccia tra ATM e AAL.

  Tornando all‟analisi delle funzionalità del DSLAM, è quindi evidente che tra i tassi
per le interfacce che il secondo livello di UTOPIA supporta sono inclusi i 622Mbps e i
155Mbps SONET/SDH, di specifica pertinenza del progetto. Mediante esso, il MUX
smista il traffico sulle schede 4xADSL line (di cui, nella configurazione della fase
presente, ne esiste un solo esemplare).
  In tale dispositivo bisogna dapprima scegliere e attivare la scheda 4xADSL, quindi
configurare i circuiti virtuali: qui la scelta è fissa e la coppia [VP, VC] è
obbligatoriamente [0,32], poiché così imposto dalla cross-connessione direttamente
cablata all'NT, qualora esso venga sfruttato in modalità “transparent bridging” (il
nostro caso).
  Fisicamente la cross-connessione ATM avviene tra la scheda 2xSTM-1 e il MUX
ADSL; tuttavia si può pensare come switch ATM l'intera struttura dagli switch agli NT:
non esiste, infatti, nessun dispositivo che effettui tale operazione sulla base di una
tabella con le corrispondenze tra valori d‟ingresso e valori di uscita dei VC, bensì
solo una serie di istruzioni distribuite in vario modo – fisse o modificabili – ad ogni
nodo della catena di apparati costituenti la rete ATM. Ciò che distingue ogni singola
connessione, in realtà, è unicamente l'ECI che perciò, oltre alla sua funzione primaria
di puntatore alle singole celle per sfruttare RAM di basso costo al posto delle CAME,
serve anche per la cross-connessione.
  Le prime due schede, da un punto di vista funzionale, hanno anche il compito
fondamentale di concentrare il traffico di quante più linee ADSL possibili attraverso
un‟unica interfaccia verso la rete che le precede: abbiamo, infatti, già avuto modo di
sottolineare che le interfacce geografiche WAN (Wide Area Network) come la STM-1
sono una risorsa di fondamentale importanza per i gestori di reti di accesso.

Sulla Scheda 4xADSL line le celle vengono passate, a seconda dell'etichetta, alle
quattro linee ADSL, che dialogano con i rispettivi NT da cui si diparte il traffico
Ethernet. Tale scheda ha ovviamente anche il compito di terminare la linea ADSL di
ciascun utente.
  Per quanto riguarda la sua configurazione, le operazioni da svolgere consistono
essenzialmente nell‟attivazione delle linee e dei modem ADSL.


2.4 – Modifica del DSLAM per la realizzazione del dimostratore
  Normalmente il DSLAM è costituito fisicamente da un rack che accoglie più
schede-unità corrispondenti a diverse interfacce e/o funzioni. Nella realizzazione del
dimostratore la rete PON “si inserisce” praticamente nel DSLAM che viene perciò
suddiviso in più sottounità fisiche (subrack o sottotelai) collocate in luoghi diversi.
Le unità previste sono di due tipi:
- Unità OLT (o Subrack OLT), che alloggia le interfacce STM-1 del DSALM
   originario e la nuova scheda OLT (Optical Line Terminator), radice della PON.
   Questa unità deve essere connessa al videoserver mediante le previste
   interfacce STM-1 (al più due): come sarà illustrato più oltre nella soluzione



                                                                                      8
    prescelta ciò richiede l‟impiego di uno switch ATM fra il VS e l‟unità OLT.
-   Unità ONU (o Subrack ONU), che alloggia alcune interfacce ADSL del DSLAM
    originario e una nuova scheda ONU (Optical Network Unit), estremo della PON.
    Questa unità deve essere connessa alle stazioni di lavoro (PC o workstation)
    mediante le previste interfacce ADSL: ciò si realizza utilizzando un‟unità NT che
    si interfaccia in ADSL con l‟unità ONU ed ha sul lato utente un‟interfaccia
    Ethernet a cui può essere connessa sia una singola stazione, dotata di apposita
    scheda, sia un‟intera rete locale.

   Le unità ONU devono essere replicate tante volte quanti sono i rami terminali della
PON. Nel dimostratore in fase di realizzazione è prevista una PON a due rami,
pertanto le unità ONU impiegate saranno due.
   La situazione è schematizzata in Figura 6.
   Per migliore comprensione dello schema si precisa che la dicitura 2xOC-3 si
riferisce all‟interfaccia fisica di tipo ottico (SONET OC-3, già disponibile per il MAT14)
con cui l‟unità OLT sarà collegata allo switch ATM (vedi sotto); inoltre la dicitura
4xADSL si riferisce alla capacità di 4 linee ADSL (anziché di 6 linee come nel
prodotto commerciale) di cui sarà dotata ogni scheda sul lato utente dell‟unità ONU.



                                                                                             PC
                                    Subrack OLT               Subrack ONU               NT
    VS
                                                                             4xADSL
                            2xOC3




             switch
                                                               MUX
                                                        ONU
                                                  OLT




                                                                                             PC
              ATM
                                                                                        NT



                                                                                             PC
                                       PON                     Subrack ONU              NT
                                                                               4xADSL
                                                                MUX
                                                         ONU




                                                                                             PC
                                                                                        NT
                          DSLAM


                      Figura 6 – DSLAM e PON nel dimostratore

  Osservazione – Appare chiaro come la scelta del citato prodotto Marconi
Communications per costruirvi intorno il dimostratore limiti la velocità di informazione
verso il videoserver all‟equivalente di due flussi STM-1, ossia a 2 x 155 Mbit/s.
Tuttavia le unità OLT e ONU in fase di sviluppo non soffrono di questa limitazione:
esse, infatti, sono progettate in modo da gestire un flusso downstream di 622 Mbit/s
ed un flusso aggregato upstream di 155 Mbit/s, come richiesto dal loro impiego su
PON effettivamente operative per la distribuzione di servizi sul territorio.




                                                                                                  9
2.5 – Definizione dell’architettura di rete
  Il progetto e la definizione del dimostratore e dei servizi che vengono offerti su di
esso e la conseguente fase di ampliamento e/o adattamento dell‟infrastruttura
esistente per soddisfare le specifiche individuate ha portato ad ottenere la
distribuzione logistica delle componenti del dimostratore (video server, PC Client,
apparati e dispositivi di rete) e le loro interconnessioni riassunte nello schema di
Figura 7.




 Figura 7 – La distribuzione logistica all’interno del campus universitario di
    Parma degli apparati costituenti il dimostratore e le loro interconnessioni

  Occorre specificare che i due video server (VS) presenti nella Figura 7 non
indicano due elaboratori diversi, ma la stessa macchina che, durante il periodo
iniziale di configurazione, creazione ed ottimizzazione del database e di tutto il
sistema, verrà temporaneamente trattenuta nel laboratorio di reti ottiche della
Palazzina 2 per permettere agevoli e rapidi interventi anche in caso di spegnimento
della rete PON; in seguito il VS verrà finalmente collocato al Centro di Calcolo
Elettronico (CCE), ma manterrà un certo grado di accessibilità anche attraverso la
rete Ethernet del campus per permettere ulteriori modifiche (ad es. degli indirizzi IP
delle schede Ethernet collegate allo switch Fore).




                                                                                     10
  La definizione dell‟architettura di rete è stata ovviamente influenzata dalla scelta
del videoserver e dalla sua posizione fisica rispetto all‟unità OLT. Poiché la
collocazione prevista per tale unità è presso il Dipartimento di Ingegneria
dell‟Informazione, si è scelto di effettuare il collegamento con VS, distante un
chilometro, mediante l‟inserimento di uno switch ATM tra VS unità OLT e link ottico in
standard OC-3 fra lo switch ATM e l‟unità OLT.
  Questa soluzione ha il doppio pregio di essere adatta a future integrazioni con le
reti degli operatori delle telecomunicazioni e di essere realizzabile in tempi brevi
essendo basata su componenti commerciali di certa disponibilità. Tale scelta
presenta anche una certa flessibilità in quanto il funzionamento degli switch
disponibili sul mercato prescinde dalla natura di ciò che si trova a monte di essi,
perché accettano in ingresso dati con protocolli sia Ethernet sia Fast Ethernet: si può
quindi collegare in ingresso allo switch una macchina qualsiasi dotata di scheda di
rete Ethernet (VS di diverso tipo, Personal Computer, Workstation, ecc…) o una rete
locale (ad esempio una rete di VS che accedono a diverse parti dell‟archivio). Inoltre,
nel caso eventuale di sostituzione del VS, la scelta non sarebbe molto vincolata dalle
caratteristiche dello switch, infatti la possibilità di utilizzo con diversi tipi di VS è
garantita dalla compatibilità dell‟interfaccia Ethernet. La soluzione adottata offre
anche la possibilità di collegare alla rete di Campus (o direttamente agli uffici dei
docenti interessati all‟erogazione ed all‟interazione con gli studenti) gli ingressi Fast
Ethernet dello switch non dedicati al collegamento col VS.
     E‟ infine importante sottolineare come tale soluzione consenta un certo grado di
scalabilità, come previsto dagli obiettivi del progetto: lo switch può infatti fungere da
centro stella come collegamento verso altri alberi PON oppure consentire la
connessione di altri VS.
  Prima di giungere alla situazione finale descritta in Figura 7, sono necessari alcuni
passaggi intermedi per la verifica della compatibilità e della intercomunicabilità tra gli
apparati; in questa fase la struttura fatta oggetto di studio differisce da quella di
Figura 7 per tre aspetti fondamentali:
   le funzioni del videoserver vengono realizzate mediante un semplice desktop-PC;
   il numero dei Client è pari a due;
   la rete in fibra ottica passiva non è presente e tutto il complesso tra Switch e NT è
    collassato nel DSLAM.
  Con tali caratteristiche, lo schema dell‟infrastruttura utilizzata è quello di Figura 8.

  Passiamo ora ad analizzare le caratteristiche e le funzionalità dei dispositivi che
compongono tale rete, nonché le problematiche che il loro utilizzo ha comportato:
procediamo dal videoserver verso i Client.

Il Videoserver
  Componente fondamentale di una rete con le funzionalità previste è un videoserver
ovvero un elaboratore dotato di memoria di massa di memoria RAM e di potenza di
calcolo adeguate a consentire la memorizzazione e la gestione una quantità di ore di
lezione registrate sufficiente agli scopi della dimostrazione. Il videoserver deve anche
essere in grado di gestire i nuovi applicativi necessari alla realizzazione delle previste
funzionalità di teledidattica avanzata da svilupparsi nell‟ambito del progetto.




                                                                                        11
                 Figura 8 – Architettura di rete nella fase attuale

  Attualmente le funzioni di videoserver sono svolte da un Personal Computer (PC),
esso è dotato di due interfacce di rete: la prima permette l‟accesso alla rete Ethernet
10base2 (10 Mbps) del Campus, mentre la seconda serve a connetterlo allo switch
ATM. Per tale collegamento si è scelto l‟impiego di un protocollo Fast Ethernet a 100
Mbps: come è risaputo, il protocollo in questione è “full duplex” – a differenza di
Ethernet –, e quindi in grado di ridurre sensibilmente la probabilità di collisioni. Va
osservato come in questa fase esista un unico collegamento tra videoserver e
switch: questa scelta, se da un lato non consente di sfruttare appieno le capacità
garantite dal collegamento OC-3 che segue, dall‟altro semplifica notevolmente la
configurazione del videoserver, che in questa fase è ancora un PC (appartenente
alla classe Pentium III). È importante sottolineare che nel corso delle prove effettuate
(che verranno descritte approfonditamente in seguito) è emerso che i vincoli di
operatività non sono dovuti alla banda disponibile, ma ai limiti intrinseci di potenza di
calcolo delle stazioni fruitrici (Client) impiegate in tali sperimentazioni. Proprio per
tale motivo, ma anche a causa del numero limitato di NT in nostro possesso (i
modem ADSL commerciali non sono compatibili con la scheda 4xADSL del DSLAM
in dotazione), si è ritenuto opportuno svolgere innanzi tutto le verifiche di
compatibilità protocollare, che sono fondamentali per il proseguimento dell‟attività
progettuale, tralasciando momentaneamente la misura dei limiti di banda aggregata.
Ciò spiega da un lato la scelta di preferire un solo collegamento tra il PC-videoserver
e lo switch, dall‟altro, parallelamente, quella dell‟impiego di due soli Client.
  A maggior giustificazione della particolare soluzione adottata, va detto fin d‟ora che
sono stati riscontrati anche notevoli problemi di conflitto sia hardware sia software in
presenza di interfacce multiple di rete, in particolare quando devono essere utilizzate
sulla stessa rete. Anche le applicazioni impiegate, inoltre, hanno dimostrato di gestire
in maniera non ottimale la presenza di più schede di rete; in particolare i software
commerciali che sono stati utilizzati per le prime prove di compatibilità protocollare,



                                                                                       12
poiché l‟applicativo sviluppato “ad hoc” si è reso disponibile solo più tardi. Sono stati
rispettivamente impiegati: RealServer per ciò che riguarda i test delle funzionalità di
Video-on-Demand e Mbone (Multicast Backbone) Tool relativamente al servizio di
videoconferenza di qualità, integrata con strumenti collaborativi; essi hanno
manifestato capacità diverse, e non sempre corrette, nel gestire la presenza
contemporanea di più dispositivi di rete tra cui dover scegliere.
   Tutte queste problematiche, comunque, verranno poi più diffusamente approfondite
allorquando verrà descritta l‟attività di sperimentazione e configurazione della rete in
questione.
   Un elaboratore di caratteristiche adeguate a svolgere le funzioni di videoserver
esiste presso il CCE che si trova nel Campus dell‟Università di Parma. Si tratta di
una macchina ONIX Infinite Reality2 della ditta Silicon Graphics dotata di CPU a 8
processori MIPS R10000 195 MHz, di 1 Gbyte di RAM, di 60 Gbyte di spazio disco e
di un sistema operativo, di tipo Unix, IRIX 6.4; però la macchina è stata acquisita per
le esigenze di calcolo della comunità scientifica dell‟Università di Parma e non può
essere sottratta a tale funzione di servizio. Inizialmente, con l‟accordo dei
responsabili del Centro di Calcolo, si era comunque deciso di utilizzare tale macchina
come videoserver, pur interferendo in qualche misura con il servizio primario. La
scelta di utilizzare tale macchina come videoserver ha posto una serie di vincoli che
hanno influenzato alcuni importanti aspetti progettuali del dimostratore. I principali
vincoli imposti sono la collocazione fisica (non modificabile) della macchina e la
limitata disponibilità sul mercato di periferiche di rete adeguate agli obiettivi del
progetto.
   In seguito si è stata scartata l‟ipotesi di utilizzo come VS della stazione ONYX 2
Centro di Calcolo Elettronico per i seguenti motivi:
 la ONYX 2 elevati costi di aggiornamento, di manutenzione e di espansione. A
     titolo di esempio: acquisto ed installazione di una scheda a quattro porte Fast
     Ethernet (4x 100 Mbps), per supportare il traffico verso la nostra rete d‟accesso
     (2x o 3x Fast Ethernet) senza pregiudicare la connettività con la rete di Campus,
     ha un costo quasi pari all‟acquisto di una nuova macchina interamente dedicata
     agli scopi del progetto.
 la stazione è poco adatta ad un uso sperimentale per almeno due motivi: il data
     base (Media Base) di cui è dotata non permette sostanziali modifiche (è un
     Software commerciale “chiuso” di cui non vengono distribuite API) e non è
     semplice determinare l‟effettiva possibilità di sviluppare su di essa gli applicativi
     previsti dal progetto; gli interventi sulla configurazione software ed hardware
     devono essere molto limitati, in quanto la stazione è già utilizzata da un gran
     numero di utenti, con i quali occorrerebbe inoltre ripartirsi le risorse (in questo
     momento i dischi rigidi hanno in realtà poco più di 6GB di spazio libero).
 considerazioni di carattere generale sull‟opportunità di legare i servizi prodotti
     nell‟ambito del progetto ad una macchina di tipo molto particolare e, di
     conseguenza, di legarne il destino ad una stazione potente, ma non più nuova,
     per la quale si preannuncia già nel medio periodo l‟obsolescenza tecnologica,
     mentre è possibile sviluppare il tutto su una macchina di tipo standard.
   Preso atto di ciò si è già provveduto ad individuare il Server che verrà utilizzato
nella struttura finale ed è attualmente in corso la procedura di acquisizione; si tratta
di una macchina con le seguenti caratteristiche fondamentali:




                                                                                       13
 Scheda madre biprocessore con frequenze da 600 a 933 MHz, Front Side Bus
     133/100 MHz, memoria RAM espandibile fino a 4 GB, controller Ultra3/160 SCSI
     integrato, scheda LAN Fast Ethernet on-board;
 2 CPU INTEL Pentium III 800 (Fc-Pga), 133MHz;
 512 MB SDRAM;
 Controller RAID Ultra 160 32 bit, 100 MHz, 32MB;
 3 Hard Disk Ultra 160 SCSI 10.000 rpm da 18 GB ciascuno;
 Lettore DVD-ROM 16x (DVD) 40x (CD-ROM);
 2 schede di rete Fast Ethernet 10/100 Mbit/s PCI.
  E‟ bene sottolineare nuovamente il fatto che questa macchina, la quale, essendo
dedicata interamente agli scopi del progetto, garantisce una potenza di calcolo molto
superiore a quella disponibile (in condivisione) sulla stazione ONYX 2, costa
all‟incirca la stessa cifra che sarebbe stata spesa per l‟acquisto e l‟installazione della
sola scheda Ethernet su quest‟ultima.

Lo switch ATM
   Dispositivo successivo della catena di apparati è lo switch ATM: dal punto di vista
logico, nella nostra rete di accesso d‟utente, lo switch ATM svolge la funzione
primaria di concentrare e commutare il traffico proveniente dalle sorgenti erogatrici
verso la dorsale a banda larga che lo collega ai nodi di accesso.
   Un esame della disponibilità sul mercato di dispositivi adeguati ha portato
all‟individuazione di un apparato ATM utilizzabile in questa fase delle
sperimentazioni. Si tratta del modello AT-8208TR-100, prodotto da Allied Telesyn.
Tale componente è dotato, tra l‟altro, di 8 porte Fast Ethernet utilizzabili per il
collegamento al videoserver e di una sola porta con interfaccia ottica OC-3c (Optical
Carrier Level 3 [x51.84Mbps] concatenate) a 155Mbps cui connettere il ramo verso il
DSLAM (ovvero l‟OLT nella fase successiva). Sottoposto ad alcune prove di
compatibilità con il DSLAM MAT14 che hanno dato esito positivo, ha tuttavia
dimostrato di non essere in possesso dei requisiti ottimali per un suo impiego in vista
della realizzazione definitiva del dimostratore.
   Sia il DSLAM sia la OLT (Optical Line Termination), infatti, prevedono ben due
interfacce STM-1 (ovvero OC-3c) verso il videoserver; per sfruttare appieno tale
banda, quindi, i limiti riscontrati nello switch comportano innanzi tutto la necessità
dell‟utilizzo in parallelo di due esemplari di quest‟ultimo, ciascuno collegato al
videoserver tramite due connessioni in Fast Ethernet.
   È pur vero che in questa fase delle sperimentazioni, viste le esigenze primarie
sopra accennate, questo problema non si è posto, ed anzi lo switch in questione è
stato effettivamente utilizzato con successo. In previsione della sua integrazione in
uno schema definitivo, tuttavia, se da un lato l‟impiego di due switch ha il pregio di
rendere la connessione più resistente ad eventuali guasti (come verrà chiarito in
seguito, quest‟affermazione è vera solo in parte), dall‟altro è assai evidente
l‟inopportunità di questa scelta se si considerano sia le necessità di portare
un‟alimentazione supplementare e di configurare due dispositivi parallelamente sia la
complessità aggiunta alla rete. La robustezza ai guasti di un‟architettura a doppio
switch, inoltre, nel nostro caso è molto discutibile, in quanto è stato deciso l‟impiego
dell‟ATM senza la gestione della segnalazione (pur non escludendone a priori
l‟utilizzo per futuri ambiti di espansione del progetto). Ne consegue che l‟allocazione



                                                                                       14
statica delle risorse rende di fatto utile solo in parte la presenza di un secondo switch
dal momento che, in presenza di guasti, non è comunque possibile assicurare il
servizio a tutti gli utenti tramite un reinstradamento automatico delle richieste (per
quanto, magari, ad un livello di QoS più basso del normale), ma si continua a
garantire un “full service” solo a quel 50% di utenti che è staticamente collegato
tramite lo switch funzionante: nulla si può fare per gli altri che afferiscono al ramo in
cui si è verificato il problema.
   Lato videoserver. Lo switch può gestire le porte Ethernet configurando
complessivamente una VLAN: il traffico tra host di rami differenti viene correttamente
instradato mediante una funzionalità di “bridging virtuale”, basata sul ben noto
algoritmo-protocollo dello “spanning tree”. L‟AT-8208TR-100 è tuttavia in grado di
gestire anche più VLAN contemporaneamente con una funzionalità di “routing
virtuale” che consente di veicolare i flussi di dati tra VLAN differenti (ciascuna delle
quali ha associato un “virtual bridge” che ne mantiene l‟informazione sulla locazione
di ogni host). Ognuna di loro rappresenta una sottorete IP e non c‟è bisogno di
riconfigurare il dispositivo se una stazione di una LAN viene spostata su di un altro
ramo della stessa VLAN. Possiamo allora affermare che lo switch in questione è
dotato anche di una certa “intelligenza di livello 3”, il che renderà possibile, un
domani, la connessione con gestori di servizi diversi, pur appartenenti a reti distinte.
Si è inoltre recentemente valutata la possibilità di collegare a tale lato “nobile” della
rete gli uffici di quei professori che fossero interessati a svolgere esercitazioni
interattive con gli studenti: il loro PC viene così a svolgere la stessa funzione logica
del videoserver e la ricchezza di banda consente la coesistenza di più esercitazioni
contemporaneamente, garantendo parallelamente un‟elevata qualità del servizio che
non sarebbe possibile ottenere sulla normale rete di Campus. Questa possibilità è
ben evidenziata dallo schema dell‟infrastruttura finale riportato in Figura 7.
   Lato DSLAM. Impiego della tecnica di trasporto ATM, su supporto fisico SONET
(Synchronous Optical Network) OC-3c, per effettuare un “bridging” del traffico
Ethernet tra sorgente (VS o PC-Docente) e Client. I circuiti virtuali configurati nello
switch sono permanenti, assegnati in maniera statica una volta per tutte. Avendo
questi un significato locale, si potrebbe pensare di riutilizzare le stesse etichette per
instaurare VC su switch diversi, cambiando esclusivamente il VP: ciò non è possibile,
tuttavia, poiché lo switch impone l‟uso del solo VP 0 se usato in modalità “transparent
bridging”, e quindi, anche per maggiore chiarezza, sono stati utilizzati identificatori
differenti per ogni circuito virtuale instaurato sulla rete. Questa limitazione dello
switch nasconde un piccolo problema, che andrà risolto quando verranno iniziate le
sperimentazioni delle fase successiva; il progetto prevede, infatti, originariamente
che i VP vengano assegnati staticamente in base all'ONU: ad ogni ONU deve
corrispondere 1 VP. Per ciò che riguarda i VC, invece, essi vengono assegnati –
sempre staticamente – in base alla linea ADSL e allo slot della 4xADSL: viene
instaurato un VC per ogni NT impiegato, indipendentemente dal fatto che esso sia
collegato ad un solo PC-Client o ad una piccola rete locale.
   La configurazione dei circuiti virtuali conduce ad un ulteriore problema che
introduce l‟impiego dello switch AT-8208TR-100: esso, appartenente alla classe dei
Workgroup switch, può pilotare solo 16 circuiti virtuali. Pur considerando l‟impiego di
due switch di questo tipo, tale caratteristica si traduce chiaramente in un‟evidente
limitazione rispetto alle specifiche di progetto che prevedono un numero di postazioni




                                                                                       15
da servire pari almeno a 60 (e con la possibilità di essere espanso ulteriormente), a
dispetto dei 32 che una coppia di AT-8208TR-100 potrebbero coprire.
   Purtroppo i limiti d‟impiego di questa apparecchiatura Allied Telesyn non si fermano
solo al numero dei VPC (Virtual Path Connection) che possono essere configurati,
ma riguardano pure il livello fisico che tale dispositivo supporta per il trasporto di celle
ATM: l‟interfaccia ottica, infatti, è costituita da una scheda a sé stante il cui
trasmettitore è un semplice Led (Light Emitting Diode). Ciò comporta, ovviamente,
che la fibra utilizzata per connettere lo switch al DSLAM sia una bretella di tipo
multimodale, ma tale caratteristica è pure in evidente contrasto con la scelta
effettuata di utilizzare le fibre monomodali già esistenti nell‟area del Campus ed
ancora inutilizzate.
   Risulta quindi evidente che, volendo realizzare un dimostratore pienamente
rispondente alle specifiche previste dal progetto, per le fasi successive dovrà essere
individuato uno switch di maggiori potenzialità e, conseguentemente, di costo più
elevato (Marconi si è già attivata per individuare e procurare uno switch Fore adatto).
Pertanto le strutture studiate in questa prima fase, basate sullo switch Allied Telesyn,
devono considerarsi, nel senso detto, tutte preliminari.
   Terminiamo la descrizione delle problematiche e delle caratteristiche dello switch
accennando alla sua capacità di autoapprendimento ed alla sua gestione via remoto.
Circa la prima, quando un nuovo server viene connesso ad una delle porte Fast
Ethernet o ne viene sostituito uno (si pensi ad esempio al suddetto impiego del PC di
un professore impegnato in esercitazioni interattive), lo switch è in grado di
accorgersene: nel giro di qualche secondo, dopo un breve apprendimento assegna
ad esso uno dei VC precedentemente configurati – se disponibile –, ricostruisce lo
“spanning tree” e riprende ad instradare correttamente.
   Abbiamo poi voluto ricordare che tale switch può essere monitorato e configurato,
all'evenienza, anche via remoto; sebbene questa sia una caratteristica assai
comune, vale la pena di sottolinearne l‟importanza perché ciò risulterà
particolarmente comodo sullo switch che sarà sistemato al CCE (Centro di Calcolo
Elettronico), a maggior ragione in prospettiva di un allargamento dell'ambito del
progetto ad un contesto cittadino. La gestione remota (RMON, Remote Network
Monitoring) del dispositivo – via interfaccia web o console – viene effettuata
mediante l'uso di applicazioni basate sui consueti protocolli SNMP (Simple Network
Management Protocol); le MIB (Management Information Base) sono dedicate.
   In termini di configurazione, infine, le operazioni da svolgere riguardano
principalmente l‟allestimento di una VLAN sulle porte Fast Ethernet e dei VPC
all‟interfaccia ATM, creando un canale punto-punto (PTOP, Point to Point) per
ciascuno di essi: tali operazioni non presentano particolari difficoltà e devono essere
effettuate una sola volta.

Il DSLAM
  È il MAT14 della Marconi visto in precedenza. In seguito, nella fase di transizione
allo schema di Figura 7, verrà sostituito da tre blocchi:
- un blocco contenente una scheda 2xSTM-1 come interfaccia WAN (Wide Area
    Network) verso lo Switch ATM e l‟unità OLT verso la rete PON;




                                                                                         16
-   due blocchi identici contenenti, ciascuno: un‟unità OLT, una scheda 2xSTM-1, un
    multiplexer ADSL e tante schede 4xADSL quante sono le linee ADSL che si
    dipanano dal blocco.
  Le unità OLT e ONU non verranno integrate sull‟apparato DSLAM per scelta
dell‟unità industriale Marconi che ritiene più semplice ed efficace questa soluzione.
Un vantaggio non trascurabile di questa scelta è che l‟unità OLT indipendente, che
viene sviluppata, può essere vista come un embrione di un modem ottico ATM, che
può essere portato fino alla sede dell‟utente finale e non è più necessariamente un
apparato di centrale.

I Network Terminator (NT)
   Come il resto dei dispositivi intermedi, i NT sono unità che non possono essere
indirizzate a livello IP. Essi inoltre non devono né possono essere in alcun modo
configurate: ciò, d‟altronde, è giustificato dal fatto che tali apparati in una rete
d‟accesso per servizi “a larga banda” vengono installati direttamente nell‟abitazione
dell‟utente, al quale si vuole semplificare e facilitare la possibilità di interfacciarsi alla
rete (i NT sono spesso indicati anche come modem ADSL, in analogia con i comuni
modem in banda base), al limite senza suoi interventi diretti.
   I NT ricoprono sostanzialmente il ruolo di "confine di rete" e svolgono la funzione di
sniffing (sensing) del canale verso la Ethernet. Inoltre, tramite interrogazione basata
sui protocolli API (Application Process Invocation) dei PC, ogni NT è in grado di
riconoscere l‟indirizzo MAC del dispositivo cui si interfaccia, sia questo una nuova
rete o un nuovo PC.
   Sul lato opposto, invece, eseguono le operazioni di policing necessarie per evitare
che le trasmissioni eccedano i limiti della risorsa “banda”, e di shaping del traffico,
dovendo convertire il traffico Ethernet in ADSL, più lento.
   Per ciò che riguarda il livello fisico, quindi, svolgono la funzione di terminare le linee
ADSL lato utente; relativamente al livello di trasporto, invece, essi determinano la
cross-connessione ATM, intesa come precedentemente detto. Ogni NT, operando
nella funzionalità predefinita "transparent bridging", supporta un'unica coppia (VP,
VC) = (0,32): le cross-connessioni, infatti, non sono programmabili ma fisse,
fisicamente cablate all'interno dell‟apparato.
   Da un punto di vista più generale, per interfacciarsi ai PC i NT impiegati prevedono,
oltre all'uscita Ethernet che è stata sfruttata nell‟ambito delle prove in laboratorio, due
ulteriori porte ATM 25Mbps. E‟ bene sottolineare che rendere possibile una scelta
per il collegamento della stazione su cui si fruisce del servizio offerto sia molto
rilevante, soprattutto in prospettiva di ampliare il contesto del progetto ad un ambito
cittadino.
   Nel caso venga utilizzata l‟interfaccia Ethernet – così come avviene nel nostro caso
–, essi possono anche essere collegati a più PC per mezzo dell‟ausilio di un organo
di smistamento quale un HUB, realizzando di fatto una piccola LAN.
   I NT attualmente in uso sono prototipi Marconi, preso atto del fatto che lo sviluppo
e la commercializzazione di questi prodotti sono state abbandonate per scelte
strategiche dell‟azienda, si è iniziato a sondare il mercato alla ricerca di modem
ADSL (o addirittura piccoli router ADSL) che permettano di utilizzare completamente
il parco Client previsto. Attualmente sono oggetto di studio alcune possibili soluzioni
sia monocomponente sia ibride (alcuni Client serviti da un tipo di modem ed altri da



                                                                                           17
un tipo differente, in modo da ottenere una validazione con carattere di generalità per
il sistema), interamente composte da dispositivi commerciali.

I Client
   Terminiamo la rassegna della descrizione dei dispositivi componenti l‟architettura
della rete di accesso oggetto di sperimentazione in questa fase e delle loro
funzionalità, trattando l‟ultimo nodo di tale catena: i Client.
   Le stazioni impiegate sono costituite da Personal Computer che sono stati,
ovviamente, dotati di strumenti che permettano di sfruttare appieno le funzionalità
d‟interattività cui devono rispondere i servizi offerti e, di conseguenza, le applicazioni
sviluppate; per soddisfare tali esigenze è sufficiente l‟impiego di comuni webcam –
meglio se USB (Universal Serial Bus), la nuova interfaccia che velocizza il trasporto
dei dati, particolarmente utile per il flusso video se il compressore è software – e
microfoni per PC, nonché ovviamente l‟utilizzo di una scheda sonora collegata ad
una coppia di casse acustiche.
    I PC si collegano agli NT con una scheda Ethernet a 10 Mbps ed alla rete Ethernet
di Palazzina 2 (cavi coassiali con connettori BNC) attraverso una seconda scheda
dotata di connettore BNC. Per collegare direttamente un NT alla rete Ethernet di
Palazzina 2, senza utilizzare PC con doppia scheda di rete, viene utilizzato un HUB,
Ethernet 10 Mbit/s, con un connettore di tipo BNC e quattro di tipo RJ45 (tre di essi
rimangono liberi e possono essere sfruttati per l‟interconnessione con le schede di
rete di altrettanti PC); anche l‟HUB è un dispositivo intermedio (bridge) e non è IP
indirizzabile.
      Su ciascuno dei tre PC che si trovano in laboratorio si utilizza il sistema operativo
Windows NT 4.0 e sono già state installate e configurate due schede di rete, una
Ethernet/Fast Ethernet 10/100 Mbit/s (autoswitch) con connettore RJ45 (Winbond)
ed una Ethernet 10 Mbit/s con un connettore BNC ed un RJ45 (Kingston). Si è
determinato che, durante l‟utilizzo simultaneo delle due schede, per non avere
malfunzionamenti, devono essere soddisfatte due condizioni: le schede devono
avere indirizzi IP appartenenti a due sottoreti diverse e devono riferirsi a due
Gateway diversi (questo potrebbe significare che è necessario utilizzare l‟intelligenza
di terzo livello ISO/OSI dello switch, anche se ciò non era inizialmente previsto).
   Su una diversa partizione del disco fisso di uno di essi è stato installato il sistema
operativo Linux, in questo caso la versatilità e la configurabilità del sistema operativo
sono state di valido aiuto per ottenere un funzionamento ottimale delle interfacce di
rete. Per questo sistema operativo sono distribuiti gratuitamente diversi software per
le analisi di rete, in particolare dei pacchetti dal punto di vista protocollare
(lunghezza, tipo e composizione del pacchetto in transito) e del traffico (quantità di
dati scambiati tra destinazione e sorgente, durata dello scambio e tipo di
informazione inviata/ricevuta); in particolare tra i software provati sono stati ritenuti
molto interessanti i tools Ethereal e Ntop. In questo caso il PC funziona da sniffer
anziché da Client.




                                                                                        18
2.6 - Struttura fisica del dimostratore sul Campus
  La collocazione delle due ONU previste sarà rispettivamente presso la sede
scientifica della Facoltà di Ingegneria (pal. B del Centro Didattico di Ingegneria,
CEDI) e presso il citato CCE. Ciascuna ONU sarà situata in un locale laboratorio di
informatica dotato di un numero adeguato di PC o workstation.
     L‟unità OLT sarà collocata presso il laboratorio di Comunicazioni ottiche del
Dipartimento di Ingegneria dell‟Informazione (Sede Scientifica della Facoltà di
Ingegneria, Palazzina n. 2, area Telecomunicazioni) dove esiste la strumentazione
necessaria alle sperimentazioni previste dal progetto.
     Le scelte eseguite fanno sì che il videoserver (presso il Centro di calcolo) e la
OLT (presso il Dipartimento) si trovino ad una distanza di un migliaio di metri fra loro.
     Come detto, sul campus esiste una rete in fibra ottica che raggiunge i vari edifici
con fibre multimodali (quasi tutte già in uso) e monomodali (praticamente
inutilizzate).Mantenendo l‟idea originaria di utilizzare tali fibre per la realizzazione
della PON (collegamento di OLT e ONU), i vincoli imposti dalla collocazione del
videoserver e l‟esistenza di un‟interfaccia ottica OC-3 già disponibile per il DSLAM
hanno indotto a realizzare il collegamento fra il videoserver e l‟unità OLT in ottica
utilizzando alcune di tali fibre.



3. – Suddivisione in fasi della sperimentazione
    Si è previsto che la sperimentazione si articoli in più fasi allo scopo di giungere
alla configurazione finale del dimostratore secondo gradi di complessità crescente. In
tal modo è possibile affrontare gradualmente i problemi che si possono presentare e
sperimentare più agevolmente le funzionalità dei singoli componenti verificandone la
compatibilità protocollare. Vengono inoltre minimizzate le necessità di hardware ed i
conseguenti tempi di attesa per ordinazioni e consegne (o esecuzione dei lavori nel
caso del cablaggio in fibra).
    Nel dettaglio, sono previste due fasi ulteriormente suddivise in sottofasi per
rendere schematicamente omogeneo il lavoro.


3.1 Fase 1
  La fase 1 consiste nella sperimentazione del DSLAM privo della rete PON, ed in
particolare nella verifica della compatibilità protocollare con uno switch ATM e di
quest‟ultimo con il VS (o con un PC).
    La fase 1 è suddivisa in due sottofasi, come descritto più avanti.

  Le sperimentazioni relative alla fase 1 in corso presso il Dipartimento di Ingegneria
dell‟Informazione dell‟Università di Parma sono praticamente terminate. Esse si
svolgono su un sistema, schematizzato in figura 9, i cui componenti sono un DSLAM
(“di fase 1”) e due NT resi disponibili da Marconi Communications, uno switch ATM
della ditta Allied Telesyn e alcuni PC.



                                                                                       19
                                                                        PC
                                                  DSLAM            NT
                VS




                                                          4xADSL
                                          2xOC3
                                                  MUX
                           Switch                                       PC
                                                                   NT



             Figura 9 – Schema sintetico del dimostratore nella fase 1

     In questa configurazione il sistema ha permesso anche l‟avvio delle attività di test
dell‟applicativo di teledidattica di cui al Tema 2.1.
   Maggiori dettagli sulla struttura del sistema e sullo stato di avanzamento della
sperimentazione sono forniti nei successivi paragrafi e nel rapporto Marconi
Communications.

Prima sottofase della fase 1
     La prima sottofase è consistita nell‟attivazione del collegamento interamente
all‟interno del laboratorio in Palazzina 2 utilizzando come videoserver un PC dotato di
due schede di rete (di cui una Fast Ethernet da collegare allo switch); lo schema che
ne deriva è quello di Figura 8. Durante questa fase sono stati provati con successo
anche alcuni applicativi commerciali quali Microsoft Netmeeting e Real Server (con
Real Player).

Seconda sottofase della fase 1
  La seconda sottofase consiste nell‟utilizzo come videoserver della macchina
biprocessore attualmente in fase di acquisto e nella prova del collegamento in fibra
fra il CED e il Dipartimento. Questo passaggio consentirà di verificare l‟effettiva
capacità degli apparati di colloquiare attraverso una tratta in fibra di un chilometro e
di evidenziare gli eventuali problemi del nuovo nel cablaggio.
  Lo schema del collegamento relativo a questa sottofase è riportato in Figura 10.
Durante questa fase verranno inoltre impiegati e provati sul VS gli applicativi
sviluppati appositamente per il progetto nell‟ambito del Tema 2.1.


3.2. Fase 2
    La fase 2 consisterà nella sperimentazione del con la PON e le unità OLT e ONU
fornite da Marconi Communications, effettivamente operative. Come detto la OLT
sarà collocata in Palazzina 2, mentre le due ONU saranno collocate rispettivamente
in un laboratorio di Informatica del CEDI (Pal. B) ed in uno simile presso il Centro di
calcolo.
    Lo schema risultante è stato illustrato in figura 7. Dove sono riportate anche le
lunghezze approssimative dei collegamenti in fibra ottica tra i vari elementi della rete.



                                                                                       20
     Si ricorda che in questa fase la velocità di informazione (potenziale) sulla tratta
PON tra OLT e ONU sarà di 622 Mbit/s contro i 2 x 155 Mbit/s della 2 x STM-1 della
tratta tra switch e OLT nella fase precedente. Tuttavia il pieno sfruttamento delle
potenzialità delle unità OLT e ONU nel dimostratore dipenderà dalla effettiva
disponibilità di uno switch di caratteristiche adeguate.

    Nelle figure 7, 8 e 10 vengono riportati lo schema dei collegamenti e le velocità di
trasmissione relative ad ogni linea (sia in uplink sia in downlink). La lunghezza
indicata nelle figure 7 e 10 per il collegamento in fibra ottica è la distanza
approssimativa fra il CCE, dove ha sede il VS, ed il laboratorio in Palazzina dove si
trova il DSLAM; in realtà, come si è detto, durante la fase 1, le funzioni del VS
vengono svolte da un PC che si trova nello stesso laboratorio (Figura 8); la verifica
del funzionamento in queste condizioni permetterà di effettuare un confronto con il
caso in figura 10 e di notare le eventuali differenze di comportamento che dovessero
verificarsi.




Figura 10 - Schema del dimostratore relativo alla seconda sottofase della fase 1


4. – Verifiche effettuate (Tema 2.6)

4.1 Verifiche preliminari
   La primissima operazione in ordine cronologico svolta nell‟ambito dell‟attività di
sperimentazione e configurazione degli apparati, è consistita nella verifica che a
livello applicazione le prime versioni del software per il Video-on-Demand utilizzato
funzionassero correttamente. Tale verifica è stata effettuata in assenza del DSLAM e
dello Switch, poiché quest‟ultimo non è stato disponibile fin da subito: sono stati
perciò collegati direttamente due PC (Personal Computer) tramite un cavetto
invertente e si è proceduto alle operazioni di configurazione del software e di verifica
necessarie. Questa attività, di per sé e per ciò che riguarda gli scopi che l‟hanno
determinata, non risulta di particolare rilevanza; tuttavia vogliamo metterla qui in




                                                                                      21
rilievo per un concetto di fondo – assai importante – che essa nasconde, già in
precedenza accennato: vale a dire che l‟assenza del DSLAM non ha minimamente
inficiato i risultati delle operazioni effettuate, perché dal punto di vista delle
applicazioni – ma anche fino al livello IP (Internet Protocol) – tutta la rete di trasporto
ATM, dallo switch agli NT (Network Termination) che la terminano, è assolutamente
trasparente. Anche in seguito, quindi, essa non ha influito minimamente sulle
verifiche di funzionamento degli applicativi sviluppati.
   Questo primo breve test ha inoltre evidenziato fin da subito un problema che si è
poi manifestato in tutto l‟arco del periodo delle sperimentazioni: ci riferiamo ai conflitti
hardware e software che si sono riscontrati in presenza di più di una scheda di rete.
Abbiamo avuto modo di capire che essi sono legati essenzialmente a delle
imperfezioni dei sistemi operativi Windows nonché alle differenti progettazioni
hardware delle schede e/o realizzazioni dei rispettivi driver, che si interfacciano al
sistema in maniera evidentemente diversa, determinando diversi comportamenti e
reagendo diversamente alla medesima configurazione dei parametri di rete. In
particolar modo, se è evidente che, per funzionare correttamente, gli indirizzi IP delle
due schede devono appartenere a sottoreti differenti, non altrettanto può dirsi del
fatto che, configurate per riferirsi al medesimo gateway, solo una delle due – e
sempre la stessa – instrada correttamente i pacchetti. Vale osservare che questi
malfunzionamenti si verificano sotto Windows98 e Windows NT 4.0, non così invece
sotto Windows 2000 Professional e Linux.



4.2 Verifiche di compatibilità protocollare
   Dopo aver analizzato la problematica precedente, l‟architettura di rete alla quale si
è giunti è stata verificata dal punto di vista della compatibilità protocollare; nella
Figura 11 si riporta uno schema delle pile (stack) di “incapsulamenti” dei dati da
trasmettere sul canale fisico (cavo elettrico o fibra ottica) e dei “deincapsulamenti”
che vengono eseguiti al termine di ogni collegamento, in ogni passaggio attraverso i
vari apparati della rete di accesso d‟utente. Vale tuttavia sottolineare che per quanto
riguarda il DSLAM, la suddivisione logica in tre blocchi vuole rappresentarne la
suddivisione fisica in tre schede (se si esclude il controller che non svolge funzioni in
questa prima fase), ma questa scelta è del tutto arbitraria, poiché in realtà il DSLAM
è funzionalmente distribuito. Le singole schede presentano gradi di complessità
diversi e svolgono, vuoi in cascata vuoi in parallelo, più funzioni; inoltre alcune tra
queste sono legate a soluzioni proprietarie dell‟unità industriale Marconi, per cui un
maggior livello di dettaglio ci è comprensibilmente negato.
   Lo schema che segue è quello che si evince dalle caratteristiche e dalle
funzionalità di ciascun elemento della rete, nonché dalla teoria cui rispondono le
varie tecnologie impiegate; la verifica protocollare, perciò, da un lato ha reso
possibile verificare la corretta interoperabilità dei diversi dispositivi, dall‟altro ha
fornito la garanzia che le ipotesi avanzate fossero effettivamente rispondenti a realtà.
   Per svolgere questa essenziale attività si è dapprima appurato che, configurando
correttamente tutti gli apparati, ci fosse effettivamente traffico tra i nodi estremi della
rete: nel far ciò fortunatamente non si sono riscontrati problemi di incompatibilità
protocollare, anche se inizialmente si è reso necessario sostituire la scheda 4xADSL




                                                                                         22
che non funzionava. In un secondo momento, quindi, è stato monitorato il traffico in
transito sulla rete: è possibile, infatti, configurare lo switch in maniera tale da
simulare su una porta non utilizzata quello in passaggio sulle altre – modalità che
prende il nome di “port mirroring” –, sia in trasmissione sia in ricezione, seppur
separatamente. Collegando tale porta ad un PC, sono stati impiegati alcuni pacchetti
software in ambiente Linux che hanno consentito di ricostruire parte dello stack dei
protocolli: esso effettivamente coincide con quello ipotizzato in precedenza e
schematizzato in Figura 11. Stessa operazione è possibile fare collegando un HUB
all‟uscita Ethernet dell‟NT e monitorando il traffico nel modo appena descritto. Va
altresì detto, però, che tale esperimento non è replicabile allorché il segnale utilizza
uno strato fisico ottico o quando viene trasmesso mediante l‟impiego della tecnologia
ADSL (Asymmetric Digital Subscriber Line), i casi di fatto più interessanti: non è
infatti possibile, in alcun modo, accedere ai segnali all‟interfaccia ottica dello switch o
all‟interno del DSLAM (se non con dispositivi accessori di monitoraggio ottico non in
nostro possesso) e neppure all‟interfaccia ADSL degli NT (servirebbe in tal caso una
sorta di HUB ADSL od un Router ADSL).




      VS      Switch      2xSTM1 MUX ADSL 4xADSL                     NT        PC
                           Figura 11 – Stack dei protocolli

  Assumendo comunque che lo schema visto possa ragionevolmente ritenersi
corretto anche nelle sue parti di più difficile controllabilità, si possono trarre delle
osservazioni interessanti: in primo luogo è importante notare che il livello IP e quelli
superiori (Transmission Control Protocol e livello applicazione) vengono raggiunti
solo ai terminali della rete, videoserver e PC; tutti i dispositivi intermedi servono solo
al trasporto dei dati (secondo livello ISO/OSI, International Standards
Organization/Open Systems Interconnection), ad eccezione dello switch che, come è
stato visto, è IP indirizzabile per permetterne una configurazione da remoto. Quello
che ancora una volta è il caso di sottolineare è che quindi questo livello non entra in
gioco nel transito dei dati sulla PON (Passive Optical Network); ovvero il DSLAM in
particolare in questa fase.
  Dalla figura 11 risulta altresì evidente la correttezza di una precedente
affermazione, secondo cui l‟utilizzo di ATM nell‟ambito del progetto è limitato alla
funzione di puro e semplice trasporto di traffico Ethernet.
  Rimane ancora da evidenziare che, come si evince da tale schema, un‟altra
caratteristica molto interessante consta nell‟integrazione del traffico TCP/IP con la



                                                                                        23
tecnica di trasporto ATM, scelta oggi ormai molto diffusa ma anche molto
controversa; tale connubio non è ottimale poiché non è “nativo”, infatti IP (e poi TCP)
e ATM non sono state definite e poi standardizzate con la prospettiva di essere
utilizzate l‟uno sull‟altra, ma sono bensì destinate a reti concettualmente molto
differenti, basate su filosofie radicalmente diverse.
   Al di là della convenienza o meno di tale scelta, vale la pena di spendere qualche
parola circa “l‟incapsulamento” delle PDU (Protocol Data Unit), che accanto al
problema della risoluzione degli indirizzi è un aspetto critico nel trasporto di un
qualunque livello rete su una rete come ATM. I blocchi funzionali che se ne
occupano sono lo switch e gli NT, che effettuano entrambi “bridging” secondo 802.1
e “mapping ATM” secondo RFC1483; i dispositivi intermedi hanno infatti solo il
compito del cambiamento di livello fisico e della cross-connessione ATM. L‟RFC1483
specifica proprio “l‟incapsulamento” del traffico multi-protocollo di reti interconnesse
per la trasmissione su ATM, facendo uso del livello AAL5 per supportare circuiti
virtuali permanenti (come nel nostro caso) e commutati. I metodi che possono essere
impiegati sono due:
     il VCMUX (VC based Multiplexing);
     “l‟incapsulamento” LLC-SNAP (Logical Link Control – Sub-Network Access Point).
   Il primo assume che ogni protocollo venga trasportato su un circuito virtuale
separato, e quindi identificato implicitamente ogni volta che si instaura un circuito
virtuale tra due stazioni ATM. Tale metodo è generalmente impiegato in reti ATM
private, in cui è veloce ed economica la creazione dinamica di un grande numero di
circuiti virtuali; esso consente inoltre un minore impiego della banda e una minore
elaborazione di overhead, non essendo aggiunta alcuna informazione addizionale al
Payload del PDU di AAL5 (ATM Adaptation Layer 5).
   Il secondo consente invece di “multiplexare” protocolli multipli su di un singolo
circuito virtuale, identificando poi il protocollo del PDU trasportato da un prefisso
anteposto a quest‟ultimo, in un header LLC. Il LLC è infatti il sottostrato di livello 2
usato nelle LAN con la funzione essenziale di discriminare tra diverse entità di livello
3, perciò un protocollo come IP viene incapsulato in una PDU LLC. Dato però che lo
spazio degli indirizzamenti LLC si è rivelato insufficiente, è stata definita
un‟estensione denominata SNAP e il sottostrato di livello 2 così ampliato viene
indicato come LLC-SNAP.
   Tale metodo di “incapsulamento” si fa preferire in quei casi in cui per una ragione o
l‟altra non sia conveniente avere un circuito virtuale separato per ogni protocollo
trasportato: tipica è la situazione in cui la rete ATM supporti solo circuiti virtuali
permanenti, oppure il suo “caricamento” dipenda pesantemente dal numero di circuiti
virtuali instaurati simultaneamente. In ragione di ciò, nell‟ambito di questo progetto si
è deciso di adottare la seconda alternativa, con il livello LLC-SNAP gestito come
FCS (Frame Check Sequence). Ad ogni modo vale osservare che è possibile
cambiare questa impostazione e utilizzare “l‟imbustamento” VCMUX dal monitor di
unità ADSL.
   Il Payload del PDU di AAL5 cambia poi a seconda che ad essere trasportato sia un
protocollo cosiddetto “bridged” piuttosto che uno “routed”: l‟header SNAP, infatti, nel
primo caso deve prevedere anche la specifica del tipo di media tramite un indirizzo
MAC del destinatario, un‟informazione addizionale circa il FCS della LAN e dei bit di
“padding” necessari ad allineare i campi che seguono alla dimensione del pacchetto.




                                                                                       24
Nel nostro caso, tuttavia, essendo trasportato il protocollo IP, il formato del payload
ricade nel secondo più semplice caso ed è del tipo:

                                 0xAA-AA-03
                   LLC
                                 (indica la presenza di un header SNAP)
                   OUI           0x00-00-00
                                 0x08-00
                   EtherType
                                 (specifica che segue un PDU IP)
                   PDU           (fino a 216, 9 ottetti)

  Complessivamente la lunghezza minima di un pacchetto prevede quindi 64 byte
Ethernet, 10 byte LLC, 8 byte di overhead AAL5 e 14 byte di “padding” AAL5 per
compatibilità con il payload SONET (Synchronous Optical Network, il livello fisico su
cui ATM si appoggia fino all‟interfaccia STM-1, Synchronous Transport Module 1,
155.52Mbps).



4.3 Attività di programmazione delle configurazioni
   Nell‟ambito dell‟attività di sperimentazione si è poi ben presto posta la necessità di
configurare più agevolmente i dispositivi in nostro possesso, specificatamente il
DSLAM: esso infatti è dotato di un controller in grado di memorizzare la
configurazione dell‟intero cestello, ma nella prima fase del progetto non è stato
possibile utilizzare tale scheda aggiuntiva. Ciò comporta che ogni qual volta viene
tolta l‟alimentazione al MAT14, esso perde completamente i dati che conteneva
relativi al suo funzionamento, e una volta riacceso deve di conseguenza essere
nuovamente riconfigurato. Inoltre, qualora si voglia modificare le impostazioni anche
di una sola piastra, le si deve mandare un segnale di “reset” che ne azzera lo stato e
per poi rieffettuare tutte le operazioni ad essa relative – ma il più delle volte deve
essere riconfigurato tutto il dispositivo nel suo complesso – “a mano”. Per ovviare a
tale inconveniente si è allora deciso di dotare il DSLAM di una procedura di
configurazione il più possibile automatica; a tal scopo è stata sviluppata una macro
che – tramite un file batch – viene passata ad un emulatore di terminale ed interroga
l‟operatore circa:
    l‟intenzione di modificare la configurazione preesistente o di effettuarne una
       nuova;
    il numero di canali da attivare;
    il numero dei circuiti virtuali che si intende instaurare;
   In seguito a ciò effettua automaticamente tutte le operazioni necessarie; compresa
la conversione dei valori decimali inseriti dall‟operatore negli esadecimali su cui si
basa la numerazione dei circuiti virtuali nel monitor di servizio del dispositivo. Tale
procedura si cura inoltre di creare un semplice file di testo che riassume lo stato
attuale delle configurazioni di ogni piastra ed è stata dotata di controlli di errore sui
valori che vengono inseriti, nonché di avvisi per operazioni potenzialmente distruttive.




                                                                                       25
   Inizialmente pensata in maniera tale da consentire una personalizzazione più fine
della configurazione, la macro sviluppata è stata poi ridimensionata negli obiettivi.
Innanzitutto, poiché in questa prima fase il DSLAM è dotato di una sola scheda
4xADSL, non c‟è alcun grado di libertà circa la configurazione dell‟ultima piastra, che
viene interamente attivata – sempre automaticamente – al termine delle operazioni
relative a quelle precedenti. In secondo luogo, osservando un documento dell‟unità
industriale Marconi che ha progettato il cestello, è apparso chiaro che la versione
definitiva degli apparati sarà accompagnata anche da una nuova versione del
software di monitor, poiché diversi saranno anche gli indirizzi hardware dei bus del
sistema. In ragione di ciò è apparso inutile dotare la procedura di configurazione di
una ridondanza di flessibilità che sarebbe stata introdotta solo in previsione futura,
quando però, con estrema probabilità, i parametri – nonché la lista e la sequenza
delle operazioni – da passare al DSLAM saranno modificati.
   Ciò nonostante, in vista delle fasi successive di sperimentazione in cui saranno
presenti anche le ONU, l‟OLT (Optical Network Unit, Optical Line Termination, le
unità che terminano la rete ottica passiva di distribuzione) e un maggior numero di
schede 4xADSL, sono state previste altre funzionalità oltre alle tre precedentemente
indicate, con cui arricchire la procedura di configurazione del cestello:
    l‟utilizzo di un‟interfaccia grafica più accattivante, che si traduce nell‟abbandono
       dell‟emulatore di terminale fin qui utilizzato, dalla scarsa programmabilità, per
       impiegare applicativi software, già individuati, che consentano di interfacciarsi
       con più comodi script in Visual Basic;
    la possibilità di salvare e richiamare velocemente l‟ultima configurazione
       nonché un certo numero di quelle “di particolare interesse”, vuoi per effettuare
       misure e sperimentazioni specifiche, vuoi per isolare e controllare lo stato di
       funzionamento di singoli canali o linee;
    una piena configurazione anche nella scelta delle schede 4xADSL e delle
       relative linee;
    lo sfruttamento delle funzioni di “watching” di linee e canali già previste dal
       monitor di sistema, al momento attuale consultabili solo via console.
   Senza voler entrare nel dettaglio delle singole operazioni da effettuare circa la
configurazione del DSLAM (alle variabili più importanti è già stato accennato durante
la descrizione dei blocchi del sistema), vale comunque la pena segnalare un
fastidioso inconveniente che si è spesso verificato: se uno dei canali di ricezione
della 2xSTM-1 è collegato tramite la bretella ottica allo switch durante l‟operazione di
configurazione, spesso quest‟ultima non va a buon fine. Ci è sembrato di capire che
il cestello soffra della limitazione per la quale, se si vuole che la suddetta procedura
abbia successo, questa stessa deve essere completata in totale assenza di traffico
(la fibra deve essere momentaneamente scollegata).


4.4 Prove di stabilità a lungo termine
  Del problema specifico appena accennato non soffre invece lo switch Allied
Telesyn; esso pure non necessita di essere riprogrammato ogni qual volta venga
spento, poiché memorizza i suoi dati in una EEPROM (Electrically Erasable
Programmable Read Only Memory), memoria non volatile. Tuttavia tale dispositivo
non è immune da difetti: nell‟ambito delle verifiche di funzionamento, infatti, gli



                                                                                       26
apparati della rete d‟acceso sono stati fatti oggetto anche di prove di stabilità a lungo
termine e lo switch ha manifestato la tendenza (sporadica ma concreta) a perdere
l‟intero firmware, in cui vengono salvate anche le informazioni di configurazione. Va
detto altresì che è possibile ricaricare il firmware predefinito della casa produttrice
tramite l‟ausilio di una semplice sessione di TFTP (Trivial File Transfer Protocol). Per
ciò che riguarda la configurazione delle porte Ethernet e dell‟interfaccia ATM, invece,
esiste una procedura (da effettuare preventivamente quando ancora l‟apparato
funziona correttamente) attivabile da console, tramite la quale esse possono essere
“salvate” in appositi file e trasferite ad una memoria esterna, in modo da poter
eventualmente ripristinare il firmware nel caso si verifichi la sua cancellazione.
   Le prove di stabilità a lungo termine hanno poi evidenziato problemi anche riguardo
ai NT attualmente in uso: in maniera del tutto casuale, con periodi di funzionamento
assai variabili (distribuiti quasi uniformemente tra un paio d‟ore e una settimana),
tanto l‟uno quanto l‟altro dei due apparati in nostro possesso ha dimostrato di essere
soggetto a improvvisi crolli di funzionamento. Volendo essere più precisi, si è notato
come in essi vengano meno solo le capacità di ricezione all‟interfaccia ADSL dal
DSLAM, mentre il traffico proveniente dall‟interfaccia Ethernet viene correttamente
“deincapsulato”, ritrasmesso verso il DSLAM e quindi ricevuto a destinazione. Nel
valutare tale comportamento abbiamo escluso che si tratti di un problema di cavi o di
linea ADSL (entrambi più volte modificati); va per altro sottolineato che gli NT hanno
dato prova di “scaldarsi” notevolmente e assai velocemente, e probabilmente è da
attribuirsi a tale fenomeno l‟effetto verificatosi, che risulta, tuttavia, assai curioso vista
la sua “asimmetria di manifestazione”. Per ristabilirne il corretto funzionamento,
inoltre, non è sufficiente riconfigurare tramite il monitor del DSLAM la linea ADSL cui
ciascuno è collegato, ma bisogna prima togliere alimentazione all‟NT che ha
presentato il malfunzionamento.


4.5 Verifiche sulla disponibilità di banda
  Sono quindi state svolte altre verifiche per valutare che la banda a disposizione per
ogni NT fosse effettivamente quella indicata nelle specifiche dell‟apparato industriale
utilizzato, ovvero circa 3.1 Mbps utili su 4.7 disponibili in downstream e 300 Kbps su
500 nella direzione di segnalazione opposta, come indicato in Figura 7. Per far ciò
abbiamo trasmesso file di diverse dimensioni e con diversi protocolli di trasporto –
direttamente tramite finestra windows e via FTP (File Transfer Protocol) –. I risultati
delle operazioni così effettuate hanno tuttavia condotto a dei risultati piuttosto
contraddittori e di difficile lettura e interpretazione: pur non oltrepassando mai in
entrambe le direzioni i valori indicati nel documento di specifica, è stato possibile
notare come mentre la trasmissione upstream sia costantemente attestata sui limiti
lordi del canale, quella downstream risulta sempre ben al di sotto anche di quelli
netti, ma con risultati qui invece assai incostanti pur ripetendo la stessa prova nel
volgere di un breve intervallo di tempo. Nel caso, poi, in cui entrambi i canali siano
occupati simultaneamente, l‟upload è addirittura più veloce del download, quasi fosse
privilegiato rispetto ad esso, pur rimanendo sempre nei valori consentiti.
  Dalle prove effettuate sugli applicativi multimediali interattivi (di cui si dirà in
seguito), ci si è allora resi conto che i comportamenti sconcertanti a volte incontrati
non erano però riconducibili alla disponibilità di banda o a malfunzionamenti degli



                                                                                           27
apparati di rete, quanto ai limiti intrinseci di potenza dei calcolatori impiegati come
Server e Client per tali misure. È difficile, tuttavia, individuare un particolare
componente causa di rallentamenti nella fruizione dei servizi multimediali trasportati;
si deve piuttosto pensare ad un insieme di concause legate principalmente a:
     disponibilità di memoria volatile (RAM);
     potenza del processore di calcolo, soprattutto dal momento che la decodifica
      dei formati impiegati per trasportare i filmati è di tipo software e ciò impegna a
      fondo la CPU (Central Processing Unit);
     velocità dei tempi di accesso, in lettura e scrittura, della testina del disco fisso:
      forse il vincolo più stringente, che ha reso necessario l‟acquisto di un hard disk
      di ultima generazione caratterizzato da un‟elevata rapidità di giro per il PC
      deputato a svolgere le funzioni di videoserver;
     non completa controllabilità dei processi attivi in ogni determinato momento
      sulle piattaforme Windows.
   Per le verifiche del Throughput tra Server e Client (End-to-End), in particolare per
ciò che riguarda il flusso downstream, è stato utilizzato un applicativo sviluppato in
Visual C++ che permette da un lato di generare pacchetti di dimensione fissa
(impostabile dall‟operatore) ad intervalli di tempo fissati (anch‟essi variabili
dall‟operatore) e dall‟altro di memorizzare i pacchetti arrivati e la distanza di
interarrivo di ciascuno rispetto al precedente (i dati generati hanno, inoltre, la
caratteristica di contenere una numerazione ordinale dei pacchetti; per cui a
ricevitore è possibile vedere esattamente l‟ordine di arrivo e quali pacchetti sono stati
persi). Per effettuare queste prove, si è utilizzato lo schema di Figura 12 in cui si nota
anche la presenza dello sniffer utilizzato per verificare la correttezza delle misure.
Queste prove hanno evidenziato che i pacchetti arrivano a destinazione già ordinati
(è inutile il riordino a livello TCP).

                Eth:10Mb/s           ADSL/ATM:500 kb/s           Eth:10Mb/s


       Client       HUB       NT       DSLAM
                                                          Switch              Server

       (elio)       Sniffer                                                   (Uranio)



                    (Cromo)



                Figura 12 – Schema per la valutazione del throughput

  Per il calcolo del Throughput medio (in bit per second, bps) si è utilizzata la
formula:
                             Dimensione pck [byte] * 8 [bit/byte]
                 Th medio =
                            Tempo di ritardo dal pck precedente [s]
dove “Dimensione pck” è la dimensione, in byte, dei pacchetti inviati e “Tempo di
ritardo dal pck precedente” indica: in trasmissione la distanza, fissa, tra l‟invio di due
pacchetti ed in ricezione il tempo che intercorre mediamente tra l‟arrivo di un



                                                                                         28
pacchetto e l‟arrivo del successivo. In Figura 13 è riportato, a titolo di esempio, il
risultato di una delle misure effettuate, relativo al caso di pacchetti di 1200 byte.
   Come si può vedere il throughput a ricevitore coincide con quello trasmesso fino al
raggiungimento della banda a disposizione dei dispositivi NT, che è pari a 537 Kbps,
dopo di che si ha una saturazione e si iniziano a perdere i pacchetti in eccesso. Si
noti anche che i NT non effettuano alcun controllo di flusso, ad esempio inibendo il
traffico a livello Ethernet, ma si limitano a trasmettere quello che possono perdendo il
resto.

                            4000                                                                                            120
                                                                     100%
                            3500
                                                                                                                            100

                            3000

                                                                                                                            80
    Throughput [kbit/sec]




                            2500


                            2000                          Throughput calcolato alla sorgente (lato client) [bit/sec]        60
                                                          Throughput valutato a destinazione (lato server) [bit/sec]
                                                          % pacchetti arrivati
                            1500
                                                                                                                            40

                            1000

                                                                                                                            20
                             500

                                           537 Kbps
                               0                                                                                            0
                                   0   5   10      15         20        25        30            35          40         45
                                                Tempo di ripetizione del pck [ms]



    Figura 13 – Throughput medio generato alla sorgente, throughput medio
   osservato a destinazione e percentuale di pacchetti giunti a destinazione in
                 funzione del tempo di ripetizione dei pacchetti


4.6 Prove d’interconnessione remota degli apparati
  In questa fase di lavoro è stato possibile effettuare anche alcune delle verifiche
sulle distanze massime che le tecniche impiegate consentono di raggiungere; il test-
bed è infatti geograficamente poco esteso e non si hanno le unità OLT e ONU, ma le
tratte ADSL (elettriche in doppino) ed ATM (ottica in STM1) sono state attivate e
prolungate ad arte per questi scopi, superando anche le limitazioni imposte dallo
switch Allied Telesyn, che non permette di utilizzare la fibra monomodale stesa sul
Campus, mediante l‟acquisto di un media converter che converte il segnale ottico
multimodale (STM1) dello switch in un segnale ottico monomodale.




                                                                                                                                  29
   La prova per avere una prima stima della distanza supportabile da un collegamento
ADSL senza che le prestazioni del sistema ne risentano è da mettere in relazione al
fatto che, in vista di un utilizzo in un ambito cittadino della rete d‟accesso allo studio,
il DSLAM sarà posto in una centralina telefonica e da tal punto dovrà essere coperto
tutto il rilegamento d‟utente (tipicamente dalla lunghezza di un chilometro circa)
tramite l‟ausilio della tecnica ADSL.
   Modificando leggermente l‟architettura della rete rispetto a quella dello schema di
Figura 8, sono state allora sfruttate le linee ADSL, installate tra le palazzine dei
Dipartimenti della Facoltà di Ingegneria, ottenendo una distanza totale di poco
superiore ai 700 metri, si è potuto in tal modo verificare che tale lunghezza non
comporta alcuna penalizzazione della banda a disposizione.
   Sulla tratta ottica si è pensato di utilizzare due delle coppie di fibre che uniscono il
CCE con la palazzina 2 del plesso di Ingegneria Scientifica in modo da ottenere un
percorso di andata e ritorno che, utilizzando il media converter, permette di
remotizzare lo switch rispetto al DSLAM (con una tratta di lunghezza doppia rispetto
a quella di Figura 7) senza spostare nessun apparato dal laboratorio; anche in
questo caso non si è osservata nessuna variazione (o peggioramento) rispetto al
caso di collegamento diretto (come in Figura 8). Sulla tratta ottica è stata fatta una
prova ulteriore: è stato posizionato un attenuatore ottico da 5 dB prima sulla fibra di
trasmissione da media converter a DSLAM e poi sulla sua gemella che trasmette i
dati nel senso opposto; il corretto funzionamento, riscontrato anche in questo caso,
degli apparati autorizza due affermazioni:
     con i componenti attuali vi sono ancora 5 dB che possono essere spesi in
      termini di link budget;
     il sistema è robusto rispetto ad un peggioramento improvviso del collegamento
      (es. infiltrazioni di umidità che, congelando, comprimono la fibra e ne
      aumentano l‟attenuazione), anche se questo è diverso sulle tratte upstream e
      downstream, fino ad un margine di 5 dB.
   Lo schema del collegamento ottenuto remotizzando il videoserver e lo switch ed
allungando la tratta ADSL in doppino è riportato in Figura 14.


    (Elio)
                                      Palazzina 2                                 (Uranio)

                        ~ 700 m             ~ 2 Km
                                                      Media                        Video
    Client    HUB      NT         DSLAM              Converter       Switch
                                                                                   Server



                    Palazzina B

                                                  CCE
                    Palazzina 1


     Figura 14 – Collegamento con tratte ottiche STM1 in fibra (in blu) ed
                        elettriche ADSL in doppino (in rosso)



                                                                                         30
4.7 Verifica delle funzionalità degli applicativi
   Altra classe di sperimentazione riguarda la verifica delle funzionalità degli
applicativi che si vuole realizzare nell‟ambito del progetto; tale attività, tuttavia, non è
stata limitata ad un preciso periodo temporale, ma si è protratta per tutta la durata
quest‟anno, dal momento che il software è stato oggetto di un continuo sviluppo. Si è
quindi posta la necessità di verificare di volta in volta le versioni rilasciateci, poiché
parecchie sono state le modifiche che sono state apportate.
   Per meglio interpretare tali sperimentazioni, prima di valutarle vale la pena di
analizzare con un maggior livello di dettaglio rispetto a quanto fatto finora, quali siano
le specifiche di funzionalità cui l‟applicativo deve rispondere, mantenendo la
suddivisione in livelli con cui esso è stato dapprima progettato e poi sviluppato.
L‟architettura dell‟applicativo si articola in tre livelli: un livello base, uno collaborativo
ed uno multimediale; per ulteriori chiarimenti si rimanda alla relazione sul primo anno
(pagg. 16-22).
   Per ciò che riguarda l‟attività di sperimentazione va detto preliminarmente che le
caratteristiche di multimedialità e di collaboratività sono state verificate
separatamente, mediante l‟utilizzo di due applicazioni distinte, pur sviluppate nei
termini previsti.
   Relativamente alle funzionalità di fruizione di filmati in modalità Video-on-Demand,
le verifiche effettuate hanno condotto a esiti soddisfacenti: è stato impiegato il client
Java suddetto che si interfaccia, tramite delle librerie proprietarie, al sistema di
streaming audio/video Realsystem G2, in maniera tale da sfruttarne anche
l‟integrazione nativa con Netscape. Il player utilizzato è dotato di semplici funzionalità
VCR (Video Cassette Recorder); la Figura 15 ne mostra l‟interfaccia grafica.




        Figura 15 – Client con funzionalità VCR per Video-on-Demand


                                                                                           31
   Gli unici problemi riscontrati sono legati esclusivamente a dei piccoli difetti dovuti al
fatto che l‟applicazione è tutt‟ora in fase di sviluppo: ci riferiamo in particolar modo
alla non ottimale gestione del “buffering”, che non consente ancora una perfetta
fluidità di visualizzazione quando si vogliano sfruttare le funzionalità di riavvolgimento
o avanzamento veloce.
   Abbiamo poi osservato, talora, livelli di qualità differenti su PC-client differenti: ciò
non è però legato a problemi di configurazione della rete, quanto ai vincoli di potenza
che, come è stato ben evidenziato in precedenza, può introdurre l‟uso di PC non
perfettamente adeguati alle caratteristiche multimediali che si vuole fruire. Il
videoserver, in particolar modo, deve essere localizzato su di una stazione molto
veloce, pena una drastica diminuzione delle prestazioni di tutto il sistema di
distribuzione, specie se il numero di utenti è elevato.
   Va infine rilevato che l‟applet Java utilizzato sfrutta il formato di compressione
RealMedia: questo, se da un lato garantisce una notevole flessibilità all‟applicazione,
dall‟altro ci ha costretti all‟impiego di un server Real che, nella sua versione base,
presenta notevoli limitazioni, sia riguardo il numero di client servibili, sia riguardo i
formati supportati. Più delle altre, quest‟ultima limitazione ha impedito di fatto una
piena utilizzazione e valutazione della banda, poiché per l‟unico formato fruibile (RM,
Real Media) il compressore alloca una banda di soli 150Kbps, più che sufficienti per
trasportarne l‟informazione ma non certo paragonabili con il tasso di segnalazione
che la tratta ADSL mette a disposizione in downlink.
   L‟impiego del formato MPEG, quando supportato, renderà possibile superare tale
inconveniente.
   Risultati più significativi, in tal senso, sono stati ottenuti mediante l‟impiego del tool
di videoconferenza Mbone.
   Le applicazioni audio e video su cui si basa, rispettivamente RAT e VIC (Robust
Audio Tool e Video Conferencing Tool), basano la comunicazione su comuni
protocolli: RTP, a livello applicazione per trasmissione real-time, e IP multicast, a
livello rete. La caratteristica che ne rende tuttavia particolarmente indicato l‟uso per le
sperimentazioni è la piena libertà di configurazione che essi lasciano in termini di:
    qualità (ovvero compressione) dell‟immagine;
    risoluzione dell‟immagine;
    scelta del formato di compressione per lo streaming video (noi abbiamo
        utilizzato specialmente l‟H261);
    criptaggio per la privacy delle informazioni;
    regolazione fine dei più svariati parametri audio;
    utilizzo della banda.
   nonché la ricchezza di informazioni relativamente allo sfruttamento di quest‟ultima
e ai tassi di perdita dei flussi di dati.
   Tali caratteristiche hanno permesso di eseguire misure interessanti per quanto
riguarda i limiti di banda della rete: è stato così verificato che se si eccedono i 3Mbps
in trasmissione verso un client da una postazione collegata tramite switch alla parte
“nobile” della rete, le percentuali di perdita dei pacchetti sono superiori al 50%. Ciò è
conforme alle attese, perché non viene fornita alcuna garanzia di ritrasmissione – e
d‟altronde non avrebbe senso in un‟applicazione real-time, né l‟ATM lo prevede – o
adattamento alle condizioni del canale quando vengano ecceduti i limiti di banda. Per
un maggior approfondimento si rimanda comunque alle valutazioni circa il controllo di
congestione successive.




                                                                                          32
   Circa il livello di qualità offerta dal servizio di videoconferenza, pur non essendone
possibili misure oggettive, ci si può basare su criteri di valutazione soggettiva: uno di
questi è il MOS (Mean Opinion Score), che ha condotto a risultati soddisfacenti.
Unico difetto dell‟applicativo in questione, che non è, vale la pena di ricordarlo, quello
sviluppato “ad hoc”, è il fastidioso ritardo con cui viene rilasciato il flusso audio
rispetto a quello video, problema risolto dalle ultime versioni che però hanno
l‟inconveniente di non essere ancora molto stabili.
   Come detto, il tool software Mbone è stato impiegato solo per le sperimentazioni
preliminari ma non se ne prevede l‟uso per il dimostratore finale: in funzione di
quest‟ultimo, infatti, è in via di sviluppo un altro applicativo che integra la seconda
funzionalità sopra segnalata, vale a dire la collaboratività. Le caratteristiche di questo
applicativo sono già state introdotte: la versione embrionale da noi sperimentata
integrava una lavagna virtuale, un editor collaborativo e un browser condiviso (Figura
16).




  Figura 16 - Prima versione dell'ambiente di apprendimento collaborativo

Le verifiche di funzionalità cui è stato oggetto, tuttavia, hanno condotto
all‟evidenziazione di problemi maggiori rispetto a quelli emersi con il client per la
fruizione interattiva di filmati. Nella fattispecie, si sono riscontrati malfunzionamenti in
relazione a:



                                                                                          33
 integrazione della funzionalità di videoconferenza di qualità, che non si è ancora
    resa possibile ed ha, anzi, costretto all‟impiego del tool Mbone di cui sopra;
 gestione degli interrupts hardware, per consentire una più fluida coesistenza dei
    flussi audio e video con l‟utilizzo delle finestre delle altre applicazioni
    collaborative, al momento attuale mutuamente esclusiva;
 il funzionamento dell‟applicativo in presenza di due schede di rete (anche legato
    all‟impiego di VIC e RAT), di fatto rende impossibile sfruttare a tutt‟oggi
    l‟applicazione di browsing collaborativo.
   L‟analisi sull‟integrazione degli applicativi multimediali interattivi nella rete è poi
stata svolta nuovamente modificando leggermente l‟architettura di quest‟ultima
rispetto a quella prevista (Figura 8) per questa fase. La soluzione qui adottata,
indicata in Figura 17, introduce un nodo di complessità ulteriore tramite l‟impiego di
un HUB Ethernet a valle del NT, lato Client: con esso, in sostanza, si viene di fatto a
creare una piccola LAN per cui la banda della linea ADSL connessa all‟NT non risulta
più dedicata ad un singolo PC, ma vi si concentra il traffico Ethernet di tipo
“broadcast” proveniente dai (e diretto ai) due PC connessi all‟HUB.




   Figura 17 - Introduzione di un HUB nella rete d’utente dell’architettura di
                               rete della prima sottofase

  Considerato l‟ampio e diffuso uso di questo componente, non è stato necessario
svolgere specifiche verifiche protocollari, perciò non è il caso di riproporre un nuovo
stack degli “incapsulamenti”, poiché esso non svolge nessuna operazione di
conversione; per lo stesso motivo il suo impiego non inficia le osservazioni fatte né
circa il “tunneling” sulla rete di trasporto intermedia, né circa il particolare uso di ATM.
Tali considerazioni ne hanno quindi suggerito l‟utilizzo allo scopo di verificare se si
possa adottare questa come ulteriore soluzione per ampliare il numero di stazioni
raggiungibili nell‟offerta del servizio che si vuol rendere disponibile; essa non
esclude, ovviamente, quella privilegiata che si basa direttamente sull‟aumento del
rapporto di diramazione (e conseguentemente del numero delle ONU), una volta che



                                                                                         34
si renderà disponibile la PON. Condizione necessaria, ovviamente, è che la
condivisione del medesimo collegamento ADSL non determini un decadimento
eccessivo delle prestazioni, o che la qualità del servizio non scenda al di sotto di
livelli accettabili: è stato indicato da chi ha sviluppato l‟ambiente collaborativo che
1Mbps di banda per ciascun PC dovrebbe essere più che sufficiente perché tale
condizione rimanga verificata. Questo valore dovrebbe quindi consentire anche la
connessione di tre PC all‟HUB; tuttavia le prove da noi svolte hanno evidenziato
come già l‟uso di due PC contemporaneamente introduca un tal numero di collisioni
sulla LAN Ethernet da saturare quasi i limiti di banda della tratta ADSL che segue e
riteniamo perciò di suggerire che non venga superato tale numero di PC collegati. A
margine di queste considerazioni vale forse ricordare una condizione più pragmatica,
e cioè che l‟impiego di un HUB necessita che esso venga collegato all‟NT per mezzo
di un cavo invertente, poiché essi appartengono alla stessa tipologia di apparato.



5. - Valutazioni tecniche
  Aggiungiamo ora alcune valutazioni circa aspetti di carattere generale non
precisamente riconducibili a nessuna delle parti analizzate in precedenza.


5. 1 Collegamenti ai nodi terminali della rete
  Circa i collegamenti ai nodi terminali dell‟architettura di rete considerata, può
essere fatta una considerazione di per sé forse banale, ma che non è facile mettere
a fuoco immediatamente pur essendo fondamentale per ben comprendere l‟ottica del
funzionamento della rete d‟accesso studiata.
  Entrambi i confini della rete si basano su dei collegamenti Ethernet/Fast Ethernet:
come già osservato, questa situazione è molto comoda perché ha consentito di
sviluppare il processo delle sperimentazioni inserendo via via elementi – intermedi
nella rete – di flessibilità (il DSLAM nella prima fase, la PON nella seconda) che
concettualmente non la modificano minimamente. Vale la pena osservare, però, che
ciascuno di questi rami non ospita tutto il traffico aggregato della rete PON, bensì
solo una porzione di esso. Volendo chiarire maggiormente questo concetto, si
consideri che ogni porta IP del VS è connessa direttamente ad un particolare
ingresso degli switch: il traffico instradato attraverso ciascuno dei collegamenti,
quindi, è assolutamente “privato”, e non certo condiviso da tutti. Ciò perché, pur
basandosi su un protocollo che fa uso del “broadcast”, l‟applicazione al videoserver
che deve rilasciare il filmato incontra dapprima il livello rete, nello scorrere dall‟alto la
pila dei protocolli: essa instrada perciò il traffico solo su una delle periferiche di rete
ed è poi compito solo di tale scheda occuparsi del livello Ethernet. Questo garantisce
che i pacchetti che arrivano agli switch attraversino un canale dalla banda
complessiva di 400 Mbps effettivi; viceversa sarebbe inutile impiegare quattro
collegamenti.
  Allo stesso modo, ogni NT trasmette alla piccola LAN cui è collegato,
comprendente al più 3 PC (al minimo un PC), solo il traffico ad essa destinato: se




                                                                                          35
così non fosse, verrebbe meno il concetto di rete dedicata e non ci sarebbe
differenza rispetto alla sottorete Ethernet di Campus.
  Tale soluzione permette da un lato di spezzare i “collision domain”, dall'altro di
garantire bit-rate ben più elevate di quelle consentite da connessioni Ethernet che
condividessero il traffico, moltiplicando – in pratica – per il numero dei collegamenti la
capacità di una singola linea 10baseT/100baseT.


5.2 Gestione del multicast
   Molti dei servizi che si vogliono rendere disponibili sono, come visto, di tipo
multicast; esso, però, pur essendo previsto dalle unità OLT e ONU e supportato dal
protocollo AAL5 (ATM Adaptation Layer 5), non viene gestito a tale livello. Poiché
non si ha nemmeno negoziazione dei parametri di traffico per i circuiti virtuali, il
multicast non viene neppure assicurato nella fase di setup delle connessioni (tramite
la request ADD PARTY) né viene gestito tramite un BUS (Broadband Unknow
Server: è un server supplementare che possiede connessioni con tutti gli host è può
simulare il “broadcast” spedendo un pacchetto su ciascuno di esse, una alla volta).
Sarà demandato all'applicazione, di volta in volta, il compito di provvedere a tale
servizio: per ciò che riguarda l‟applicazione collaborativa, tale specifica viene
soddisfatta basando quest‟ultima sull‟impiego del protocollo IP multicast. Si sta
inoltre valutando la possibilità di utilizzare il protocollo RSVP (Resource Reservation
Protocol) in previsione di interfacciare la rete di distribuzione PON con VLAN
differenti allo switch: esso permette a mittenti multipli di trasmettere a gruppi multipli
di riceventi (ad ogni gruppo viene assegnato un indirizzo di gruppo), consente a
riceventi individuali di cambiare canale liberamente ed ottimizza la banda eliminando
al tempo stesso le congestioni.
   In relazione invece alla modalità Video-on-Demand di fruizione di filmati, è allo
studio l‟opportunità di ritardare la visualizzazione di un video da parte di un Client
qualora altri facciano richiesta di accesso al medesimo filmato entro un limitato
intervallo di tempo. Tale operazione avverrà tramite procedure di “batching”. Si sta
valutando, tuttavia, se sia conveniente in termini di tempi di progetto sviluppare tale
tematica, considerata l'estrema improbabilità di richieste multiple di uno stesso video
(a meno che queste non siano previste espressamente in fase didattica).


5.3 Controllo di congestione
   Abbiamo già evidenziato come la classe di traffico ATM sia CBR (Constant Bit-
Rate): ciò comporta che non venga assicurato nessun controllo di congestione a
livello ATM. Anche il campo GFC (General Flow Control), pur presente nell‟header
ATM presso l‟interfaccia UNI (User Network Interface), non viene utilizzato. Sarà
demandato quindi al livello applicazione far sì che la richiesta di banda non ecceda i
limiti, oltre i quali il servizio non è più garantito e il flusso di comunicazione viene
meno. In realtà anche a livello di applicazione si può solo cercare di effettuare una
sorta di temporizzazione in modo da forzare una certa bit-rate, il tutto però in maniera
molto blando, poiché il sistema operativo non permette di avere accesso diretto ai
registri hardware. Non è possibile infatti pensare a un gestore, una sorta di



                                                                                        36
“supervisore” che mantenga il flusso aggregato nei limiti: non si riesce a gestire un
flusso se generato da applicazioni differenti, ma è possibile attribuire una priorità alle
applicazioni cercando di privilegiare quelle con richieste stringenti (perché usano
molta banda). Nonostante questi limiti, tuttavia, i risultati che si ottengono sono più
che soddisfacenti.
   Va da sé, ovviamente, che rimangono comunque sia la garanzia di un trasporto
“robusto” ed efficiente assicurata dal TCP (Transmission Control Protocol), sia gli
algoritmi classici di sensing, collision detecting e ritrasmissione (CSMA-CD, Carrier
Sense Multiple Access – Collision Detect) su cui è basata una trasmissione Ethernet
( tale è, infatti, il collegamento dal punto di vista di VS e Client).


5.4 Gestione degli errori
   Per quanto riguarda la gestione degli errori, infine, al contrario di quanto avviene
per il controllo di flusso e il multicasting, essa viene effettuata anche dai livelli più
bassi dello stack dei protocolli. Tale gestione, a livello ADSL, è già stata oggetto di
analisi: in particolare, essendo il traffico che si vuole trasportare intrinsecamente real-
time, oltre al FEC (Forward Error Correction, tipico per le trasmissioni cui è indirizzata
l‟ATM) viene anche utilizzato il processo di interleaving convoluzionale visto in
precedenza, dedicato per la classe di dati cosiddetta interleaved. Per quanto
riguarda l‟ATM, essa ha un campo di un byte (HEC, Header Error Control)
nell‟header, destinato alla rivelazione e alla correzione (100% su un bit, 90% su più
d‟uno) degli errori del solo header di cella; il livello AAL5, invece, presenta ben 32 bit
di checksum su tutto il messaggio che consentono di individuare celle mancanti,
messaggi persi o mal inseriti, supplendo così alla mancanza di numeri di sequenza
nelle celle. Un‟ulteriore controllo viene poi effettuato a livello LLC-SNAP (Logical Link
Control – Sub-Network Access Point), che prevede l'uso del FCS (Frame Check
Sequence), che è ridondante perché ATM garantisce intrinsecamente l‟ordine delle
celle. Accanto a questi, rimane comunque la gestione degli errori a livello
applicazione.



6. - Dimostrazione finale del primo anno (Tema 2.7)

6.1 Obiettivi della dimostrazione
  La prima fase delle sperimentazioni si è conclusa con una dimostrazione che ha
avuto lo scopo di:
  I) presentare i servizi che verranno attivati mostrando le funzionalità degli
      applicativi previsti dal progetto, per quanto essi fossero ancora in via di
      sviluppo;
  II) fare un esempio del grado di qualità del servizio (QoS, Quality of Service) che
      può essere garantito agli utenti mediante l‟impiego della rete di accesso
      progettata.




                                                                                        37
   Con tale dimostrazione, tuttavia, si è anche voluto dare particolare rilievo alla
capacità di interazione della rete di accesso sperimentata con altre tipologie di reti di
telecomunicazioni, consentita dalla particolare configurazione dell‟architettura
adottata.
   Più specificatamente è stata effettuata un‟integrazione con la rete satellitare (misto
a ISDN) del CNIT per la videoconferenza di qualità; è una rete satellitare che impiega
linee ISDN (Integrated Service Digital Network) dedicate per il trasporto dei segnali a
terra, nata allo scopo di allargare sessioni di videoconferenza al maggior numero
possibile di partecipanti.
   Essa, in accordo alla configurazione, raggiunge un bacino d‟utenza più ampio di
quanto non consenta una rete di accesso tradizionale quale quella del progetto, che
d‟altro canto mette a disposizione del singolo utente una capacità di banda
notevolmente superiore permettendo la fruizione di servizi più ricchi di contenuti
interattivi e multimediali.


6.2 Test-bed
  Per il test-bed della dimostrazione è stato individuata la Palazzina B del CEDI
(Centro Didattico di Ingegneria), pure all‟interno dell‟Area delle Scienze
dell‟Università degli Studi di Parma. Essa è stata impiegata poiché è dotata di
un‟aula attrezzata appositamente per la videoconferenza, nonché di una potente sala
regia che ha permesso una elaborazione di qualità dei segnali audio e video.


6.3 Architettura della rete
  Per quanto riguarda l‟infrastruttura della rete d‟accesso, la dimostrazione non ne ha
stravolto i contenuti, soprattutto relativamente alla parte d‟utente.
  Lo schema di Figura 18 mostra in dettaglio come sono stati distribuiti
logisticamente gli apparati e come sono stati realizzati i collegamenti.
  Come bene si evince da tale figura, le differenze fondamentali rispetto
all‟architettura studiata nella prima fase sono concentrate nel lato Server della rete di
accesso.
  La novità principale consta nell‟impiego di un router Cisco: collegato tramite un
protocollo Ethernet a 10Mbps allo switch ATM, è l‟elemento essenziale che consente
di interfacciare la rete di distribuzione con quella satellitare, tramite un collegamento
su 3 linee ISDN dalla capacità complessiva di 384Kbps con la stazione a terra
dell‟Università di Genova.
  Procediamo quindi per gradi analizzando le funzionalità degli altri dispositivi della
catena. Il calcolatore dell‟aula A1 è dotato di una telecamera semiprofessionale e di
una scheda di acquisizione video che consente di elaborarne l‟informazione.
Quest‟ultima è pure collegata ad un mixer audio-video che permette di integrare il
segnale della telecamera con quello proveniente, ad esempio, da un
videoregistratore. Il suddetto PC (Personal Computer), quindi, svolge il ruolo di nodo
centrale della videoconferenza, e consente di estendere a questa una funzionalità di
videolezione; collegato al router, mediante l‟impiego del tool software Mbone




                                                                                       38
(Multicast backbone) descritto precedentemente, esso ha trasmesso la
videoconferenza in una sessione multicast sia alla rete satellitare sia, tramite lo
switch, alla rete di accesso ADSL (Asymmetric Digital Subscriber Line). I client di
quest‟ultima, dotati di webcam, microfono e casse acustiche, permettono anche agli
utenti di tale rete “parallela” di intervenire interattivamente nella sessione di lavoro e
di dialogare anche con i nodi della rete satellitare.




   Figura 18 - Architettura di rete della dimostrazione finale del primo anno

   Sempre sulla stessa VLAN è poi collegato allo switch ATM il videoserver. In questa
configurazione di rete, le stazioni che erogano i servizi multimediali sono quindi
fisicamente distinte: nelle sperimentazioni effettuate nella prima fase, invece, pur
testando come detto separatamente le funzionalità di collaboratività e fruizione
interattiva multimediale dei filmati, è stato impiegato sempre lo stesso PC.
   Il resto della rete di accesso ricalca fedelmente la struttura studiata in precedenza,
pur prevedendo la localizzazione in un‟aula remota di un client, collegato ad un NT
tramite un cavo Ethernet della lunghezza necessaria. Tale aula, la A2 dello schema
precedente, vuole sostanzialmente rappresentare simbolicamente l‟aula virtuale in
cui possono essere pensati distribuiti gli studenti che usufruiscono dei servizi erogati.


6.4 Programma della dimostrazione
  La dimostrazione ha consentito di mostrare le funzionalità per cui la rete d‟accesso
è stata progettata.
  Nella prima parte ci si è soffermati soprattutto sull‟integrazione, interattiva, delle
due tipologie di servizi offerte. Si sono tenuti dapprima due brevi seminari interattivi
con l‟impiego di slide sia tradizionali sia in formato elettronico, uno dal nodo di
Firenze, uno dall‟aula di Videoconferenza A1 del CEDI, che hanno visto la



                                                                                       39
partecipazione di tutti i client della rete ATM/ADSL di Parma e della rete SAT/ISDN
ASI-CNIT. In un secondo momento è stata erogata una videolezione registrata.
   Tanto per la fruizione dei seminari quanto per quella della videolezione sono stati
utilizzati gli applicativi VIC e RAT (VideoConference Tool e Robust Audio Tool), di cui
si è già detto in precedenza; considerati i limiti stringenti di banda della rete ISDN (tre
linee), se ne è preferito l‟uso poiché consentono una regolazione fine dei parametri di
trasmissione, in particolar modo per ciò che riguarda la bit-rate. Va detto
incidentalmente, comunque, che la banda di tre linee ISDN consente il
raggiungimento di buoni livelli di qualità se ci si limita all‟offerta di un servizio di
videoconferenza che non preveda l‟impiego di ulteriori strumenti collaborativi.
   Oggetto della seconda parte della dimostrazione è stata invece la verifica dello
stato dell‟arte del progetto, che ha comportato:
    sessioni di Video-on-Demand lanciate dai Client con fruizione completamente
       asincrona delle videolezioni;
    esercitazione interattiva mediante l‟impiego di un ambiente collaborativo di
       teledidattica (video, audio, editor collaborativo, lavagna virtuale, navigazione
       condivisa) per erogare contenuti in formato ipermediale con esposizione e
       tutoraggio on-line da parte di un docente.
   Per quanto riguarda il primo dei due temi, come abbiamo già detto in precedenza le
videolezioni sono state erogate da un PC facente funzione di videoserver, collegato
con protocollo Fast Ethernet allo switch. Esse sono state fruite in due aule differenti,
con le quali si è voluto simulare la possibilità di accedere a contenuti didattici sia da
aule attrezzate appositamente allo scopo all‟interno del Campus universitario, sia da
postazioni remote quale ad esempio il PC di casa di uno studente, in previsione di un
successivo allargamento dell‟ambito di progetto della rete.
   In relazione all‟altra tematica, invece, un docente in aula A2 ha tenuto una breve
esposizione circa gli strumenti didattici che si vogliono rendere disponibili: collegando
il PC su cui ha lavorato ad un proiettore che ne mostrava le operazioni, si è voluto
dimostrare che è possibile tenere una lezione in una normale aula (interattiva per
definizione) in cui gli studenti siano privi di terminali, e contemporaneamente
permetterne l‟ascolto e la partecipazione attiva ad altri, geograficamente distribuiti e
localizzati remotamente in un‟aula virtuale (l‟aula attrezzata dello schema), dotati di
PC con comuni periferiche d‟interazione quali appunto webcam, microfono e casse
acustiche.
   Con la rappresentazione in Figura 19 si è voluto sottolineare l‟ampio spettro di
servizi erogabili:
   - ambiente di didattica collaborativa;
   - Video-on-Demand;
   - integrazione dello strumento di videoconferenza.
che come si è detto possono essere utilizzati simultaneamente ed in modo
diversificato da tutti i Client, permettendo lo svolgimento in parallelo di seminari e/o
lezioni e di sessioni di esercitazione o spiegazione a carattere individuale (o di
gruppo ristretto), senza pregiudicare la possibilità di fruire di videolezioni registrate in
modalità VoD.




                                                                                         40
           Figura 19 – I molteplici servizi erogabili e fruibili sulla rete

7. - Predisposizione per la diagnostica ottica (Tema 2.5)
   La tecnica di misura giudicata più opportuna per effettuare la diagnostica ottica
della rete in fibra è la metodologia OTDR (Optical Time Domain Reflectometry),
basata sulla misura nel tempo dell‟ampiezza del segnale riflesso, per scattering, dalla
rete in fibra ottica quando viene inviato in essa un impulso di potenza elevata.
   Tra le possibili configurazioni atte a realizzare un sistema di sorveglianza ottica per
reti PON ad albero, considerata la topologia in oggetto e la necessità di una
soluzione abbastanza generale da non porre vincoli troppo forti sull‟infrastruttura in
fibra, l‟unità industriale CSELT ha scelto lo schema di Figura 20; tale schema non
prevede fibre ausiliarie in quanto si utilizza per l‟impulso della misura OTDR una
lunghezza d‟onda (1625 nm) diversa da quella del segnale (1310 nm), quindi non
interferente con esso a patto di eliminarlo prima che arrivi alle unità ONU. Per
l‟inserimento e la derivazione del segnale ottico, usato per l‟indagine OTDR, si
impiegano componenti ottici passivi per sistemi WDM (Wavelength Division
Multiplexing), in particolare:
   - 2 filtri accoppiatori WDM, che sono dispositivi di diramazione 1x2 selettivi in
      lunghezza d‟onda, in grado di discriminare tra la lunghezza d‟onda di segnale (
      = 1310 nm) e la lunghezza d‟onda di diagnostica (m = 1625nm) e vanno
      posizionati su ciascuno dei due rami della PON;
   - 4 filtri elimina-banda a 1625 nm (per sopprimere l‟impulso OTDR), da
      posizionare prima delle ONU che costituiscono il filtro di blocco che annulla
      l‟effetto di disturbo dell‟impulso di diagnostica su ricevitori e trasmettitori;




                                                                                       41
  -    2 accoppiatori WIC (Wavelength Indipendent Coupler), che permettono di avere
       un uguale rapporto di splitting sui rami della rete sia per il segnale che per
       l‟impulso di diagnostica; questa non è comunque una condizione fondamentale
       in quanto per la misura OTDR è sufficiente conoscere il rapporto di splitting
       sulla frequenza a 1625 nm, anche se questo è diverso da quello del segnale.
   Tutti questi componenti sono in fase di acquisizione e si prevede di avere
l‟infrastruttura completa entro il Gennaio 2001. Su precisa indicazione dell‟unità
industriale CSELT si è provveduto, inoltre, a dotare tutti i dispositivi ottici di connettori
angolati, in modo da ridurre considerevolmente le riflessioni causate da essi
(generano picchi sulla traccia OTDR letta); purtroppo rimangono piani i connettori già
predisposti nei patch-panel dei rack, perciò occorrerà valutare il disturbo creato da
essi.




                   Figura 20 - Monitoraggio ottico sulla rete PON




                                                                                          42
           Progetto di ricerca applicata CNR 5%
     "Rete multimediale interattiva di accesso all'utente"


                           Linea 2:
    "Servizi multimediali interattivi su rete ottica passiva”




                 Unità di ricerca della
         UNIVERSITA’ DEGLI STUDI DI PARMA



                   Rapporto sull’attività del
                     SECONDO ANNO
                      relativa al Tema:


2.1 - “APPLICAZIONE DI TELEDIDATTICA MULTIMEDIALE
                   INTERATTIVA”



                      Hanno collaborato:

                   Prof. Giovanni Adorni
                    Prof. Dario Bianchi
                  Prof. Eduardo Calabrese
                    Prof. Agostino Poggi
                    Ing. Claudio Bergenti




        Dipartimento di Ingegneria dell’Informazione



                        Novembre 2000



                                                                43
1. Stato del Progetto

    Il progetto riguarda la sperimentazione di un‟infrastruttura di
comunicazione di tipo PON (Passive Optical Network) e la sua
integrazione con un sistema per l‟apprendimento a distanza in grado
di sfruttarne a pieno le potenzialità. Il sistema mette a disposizione
due modalità di fruizione:
  - Individuale: supporto di auto-istruzione ed auto-valutazione;
  - Di gruppo: supporto nella creazione di aule virtuali e gruppi di
discussione.
    Questo sistema è progettato mediante un‟architettura a tre livelli in
modo da renderlo scalabile ed adattabile alla capacità di banda
dell‟interconnessione a disposizione degli studenti e del docente. I tre
livelli vengono detti:
  - Livello base: supporta collegamenti attraverso un canale di
      comunicazione a banda stretta e consente agli studenti di fruire
      del servizio anche da casa. A questo livello si situano servizi di e-
      mail e bulletin board.
  - Livello collaborativo: supporta la modalità di fruizione di gruppo
      mettendo a disposizione degli studenti e dei docenti un‟aula
      virtuale fornita di un insieme di strumenti collaborativi. La
      richiesta di banda di questo livello è maggiore rispetto al livello
      base.
  - Livello multimediale: integra un servizio di video-on-demand con i
      servizi forniti dai livelli base e collaborativo. Questo consente ai
      docenti di arricchire la lezione a distanza con contenuti
      multimediali e può essere utilizzato dagli studenti per consultare
      lezioni pre-registrate.
    Il livello base è stato testato per tre anni accademici con gli
studenti dei Diplomi Universitari del Settore dell'Ingegneria
dell'Informazione e con gli studenti del Corso di Laurea in Ingegneria
Elettronica. A questi studenti è stato proposto del materiale didattico
relativo alla programmazione logica e al linguaggio Prolog. Un primo
prototipo del livello collaborativo è attualmente in fase di testing
proponendo agli stessi studenti di risolvere in gruppo un problema di
programmazione logica in Prolog. Questo primo prototipo consente
di rendere collaborative applicazioni sviluppate con Java che
utilizzano l‟interfaccia grafica AWT. Un secondo prototipo che
consente di integrare anche applicazioni che utilizzano l‟interfaccia
grafica Swing è in fase di realizzazione. Infine, il livello multimediale
è in fase avanzata di sviluppo ed attualmente consiste in un prototipo
di sistema di video-on-demand ad elevate prestazioni.

1.1 Livello Base
   Il livello base dell‟architettura è progettato per rendere il servizio
fruibile anche da studenti e docenti connessi attraverso un
collegamento a banda stretta su TCP/IP, ad esempio connessi da




                                                                              44
casa. Le funzionalità previste in questo livello sono intese ad offrire
allo studente la possibilità di:
   1. Fruire di materiale didattico in forma ipertestuale attraverso
      pagine Web direttamente accessibili da un Web browser.
   2. Utilizzare laboratori virtuali in modo individuale per sviluppare
      esercizi proposti dal docente senza doversi recare in
      laboratorio.
   3. Procedere ad una auto-valutazione attraverso dei test, con la
      possibilità di inviare i test svolti al docente per una valutazione.
   4. Comunicare con il docente e con gli altri studenti usando dei
      meccanismi tipo mailing list e bulletin board.
   Come esempio delle possibilità offerte da questo livello è stato
realizzato un intero corso di programmazione logica corredato di un
laboratorio virtuale, di test di auto-valutazione e di una mailing list. Il
sistema è completamente fruibile utilizzando un Web Browser in
modo facile ed uniforme e le funzionalità supportate lo rendono
interessante non solo per lo studio a distanza, ma anche come
strumento per arricchire e migliorare la didattica in campus. Il
sistema mette a disposizione del docente la possibilità di fornire corsi
comprendenti sia una parte teorica sia una parte pratica. La parte
teorica viene sviluppata attraverso ipertesti direttamente fruibili
attraverso un Web Browser, mentre la parte pratica è composta da
esercitazioni guidate. Ogni esercitazione è composta da un insieme
di esercizi proposti, le relative soluzioni ed una serie di suggerimenti
sulle prove da effettuarsi nel laboratorio virtuale.

1.2 Livello Collaborativo
   Il livello collaborativo nasce dall‟esigenza di mettere in
comunicazione docenti e studenti attraverso meccanismi semplici ed
immediati. In modo del tutto generale, un‟applicazione può essere
detta collaborativa se consente a due o più utenti di lavorare allo
stesso documento annullando la distanza che li separa. Non vi è
alcuna restrizione sul tipo del documento, questo può essere un
testo, un diagramma o un semplice schizzo su una lavagna. Le
applicazioni collaborative possono essere categorizzate in base al
grado di interattività che supportano in:
   1. Sincrone: ogni modifica apportata da un collaboratore ad un
       documento viene immediatamente proposta altri collaboratori.
       In questo modo, i collaboratori hanno la possibilità di apportare
       il proprio contributo allo sviluppo del documento permettendo
       contemporaneamente al gruppo di lavoro di verificare
       l‟evoluzione dello stesso.
   2. Asincrone: le modifiche apportate ai documenti vengono
       scambiate tra i collaboratori mediante strumenti quali le e-mail
       che non consentono interattività.
   Il livello collaborativo del sistema è formato da un insieme di
applicazioni collaborative sincrone completamente basate sulle
tecnologie del Web. In particolare, questo livello permette agli




                                                                              45
studenti ed ai docenti di condividere, durante le lezioni e le
esercitazioni, delle applicazioni per la video-scrittura, per il disegno e
per il browsing del Web. Sono in fase di realizzazione due framework
applicativi in grado di rendere collaborativi un‟applicazione scritta in
Java. Il primo si basa sulla possibilità di rendere collaborativi i
componenti dell‟interfaccia grafica AWT e viene chiamato CollAWT,
mentre il secondo consente di rendere collaborativi i componenti
dell‟interfaccia grafica Swing e viene chiamato CollSwing.
   La tecnica utilizzata da CollAWT per rendere collaborativa
un‟applicazione viene detta event broadcasting. Ai vari collaboratori
viene fornita una copia dell‟applicativo da condividere ed ogni evento
che viene generato sull‟interfaccia grafica di una di queste copie
viene replicato sulle altre copie. Questo consente alle interfacce
grafiche di tutte le copie di evolvere nel tempo in modo sincrono e di
proporre ai collaboratori la stessa vista del documento. In figura 1
viene riportato l‟architettura di principio di CollAWT.




        Figura 1 – Architettura di principio di CollAWT.

   Per supportare l‟invio degli eventi da una applicazione alle altre è
necessaria la presenza di un componente centrale nel sistema, detto
CollServer, che riceva informazioni da una applicazione e le replichi
su tutte le altre applicazioni registrate. CollServer non è solo
responsabile di replicare in modo affidabile gli eventi generati sulle
interfacce grafiche, ma è anche il punto centrale di sincronizzazione
di tutto il sistema. Infatti, CollServer deve gestire la sincronizzazione
tra gli eventi in modo da evitare conflitti. Questa funzionalità è stata
implementate attraverso una politica di floor control. Questa politica
prevede che nel sistema esista un oggetto logico detto floor, o token,
che qualifica il collaboratore che lo possiede a modificare il
documento. Il fatto che nel sistema esista un solo token e che questo
possa essere passato da un collaboratore ad un altro consente di
sincronizzare completamente la politica di accesso. Il token viene
gestito dal CollServer con lo scopo di assegnarlo e di revocarlo ai
collaboratori cercando di stimolare la produttività complessiva del
gruppo di lavoro. Ogni collaboratore può richiedere il token al
CollServer in modo da poter procedere a modificare il documento.




                                                                             46
Una volta operata la modifica, il collaboratore restituisce il token al
CollServer in modo che questi possa consegnarlo ad un altro
collaboratore. In ogni caso, il tempo in cui ogni collaboratore
possiede il token è limitato dal CollServer in modo da evitare il
fenomeno di discussion stairvation.
   Ogni interazione tra un collaboratore ed il CollServer viene
mediata dal CollClient. Questo è un‟applicazione di controllo che
permette di inviare messaggi al CollServer e di inviare messaggi
diretti agli altri collaboratori attraverso un servizio di chat interattiva. Il
servizio di chat permette ad ogni collaboratore di inviare dei
messaggi a tutti gli altri collaboratori o solo ad alcuni di essi. Per
snellire la comunicazione, l‟invio dei messaggi di chat non è vincolato
al possesso del token e quindi la chat può essere utilizzata in modo
molto naturale.

1.3 Livello Multimediale
    Il livello multimediale ha lo scopo di integrare un servizio di video-
on-demand con l‟ambiente collaborativo. In particolare, si è
sviluppato un servizio per la consultazione collaborativa di filmati in
cui al docente è affidato il compito di coordinare l‟attività di
consultazione, mentre gli studenti possono interagire tra loro e con il
docente attraverso gli strumenti collaborativi prima descritti. Viene
poi prevista dal sistema una terza categoria di utenti, detti ospiti, a
cui è data la possibilità di utilizzare il sistema in modalità di
consultazione. Questi possono solo richiedere la consultazione di un
filmato dalla loro postazione, ma non possono partecipare a lezioni o
esercitazioni. Comunque, questi utenti hanno un controllo completo
sulla fruizione dei filmati esattamente come in un tradizionale sistema
di video-on-demand.
    Il sistema realizzato si appoggia alle potenzialità di sviluppo offerte
dal Web essendo completamente implementato mediante l‟utilizzo di
pagine HTML e di applet Java ed è progettato appoggiandosi al
modello collaborativo descritto in precedenza. L‟unica differenza
rispetto a quel modello è che solo al docente viene consegnato il
token, in modo che solo lui possa pilotare la riproduzione dei filmati.
Per aumentare la flessibilità del sistema, poi, si è pensato di rilassare
questo vincolo dando al docente la possibilità di dare e revocare il
token anche agli studenti. In questo modo il docente mantiene pieno
controllo sul gruppo di lavoro, potendo sempre revocare il possesso
del token, pur offrendo la possibilità agli studenti di controllare la
riproduzione.
    Il sistema è stato sviluppato completamente in Java avvalendosi
delle possibilità offerte dalla libreria di sviluppo JMF (Java Media
Framework). Questa libreria mette a disposizione dello sviluppatore
un framework per lo sviluppo di player di contenuti multimediali.
Questi player possono ricevere i file multimediali sia attraverso
protocolli di streaming che protocolli reliable, ed il supporto di
sviluppo rende l‟applicazione indipendente sia dal protocollo di



                                                                                  47
trasmissione che dal formato di compressione dei file. In figura 2
vengono mostrate le possibilità offerte da un player realizzato con
JMF mettendo in evidenza come un unico applicativo possa essere
utilizzato per visualizzare filmati sfruttando diversi protocolli di
trasmissione e formati di compressione.
    L‟architettura di JMF è formata da tre livelli: il livello protocolli, il
livello player ed il livello applicativo. Il livello protocolli contiene tutti i
componenti necessari alla gestione dei protocolli di trasmissione e di
compressione dei filmati. Attualmente, JMF supporta:
    1. i formati di compressione: MPEG-1, MPEG-2, QuickTime, AVI;
    2. i protocolli di trasmissione: RTP, HTTP, lettura diretta da file;
    3. i protocolli di video conferenza più comuni.
    Comunque l‟architettura è estendibile ed è possibile integrare
codec e moduli di ricezione dati che utilizzano formati e protocolli
diversi da quelli ora elencati. Il livello player costituisce la parte
centrale di JMF in quanto è composta da un insieme di classi Java
che rendono semplice la creazione di player che utilizzino i codec ed
i protocolli di trasmissione messi a disposizione dal livello protocolli.
Queste classi non consentono solo la gestione degli eventi
multimediali di sincronizzazione ma anche di re-dirigere il filmato
verso un componente AWT di visualizzazione. Infine, il livello
applicativo è composto dalle classi e dai componenti applicativi che
consentono di utilizzare JMF all‟interno di una applicazione
complessa.




         Figura 2 – Finestra del client di video-on-demand.


                                                                                   48
    La possibilità di integrare JMF con codec e moduli di ricezione
diversi da quelli supportati dalla libreria è stata utilizzata nel progetto
per realizzare un client di video-on-demand in grado di ricevere
filmati ad elevata qualità dal video server WebForce MediaBase di
Silicon Graphics. Infatti, si è sfruttata la possibilità di integrare con
JMF il formato di compressione RealMedia ed il protocollo di
trasporto PNM per sfruttare a pieno le possibilità di trasmissione del
video server.

2. Avanzamento nell’Ultimo Semestre

   Il lavoro dello scorso semestre si è concentrato principalmente nei
livelli collaborativo e multimediale. Per quanto riguarda il livello base,
infatti, è stato soltanto arricchito il materiale didattico e sono stati
corretti alcuni problemi riscontrati nel software di auto-valutazione.
   Per quanto riguarda il livello collaborativo è stata iniziata la
progettazione e la realizzazione del prototipo della libreria CollSwing.
Questo prototipo è basato sulla stessa architettura di CollAWT ma si
rivolge ai componenti dell‟interfaccia grafica Swing. Attualmente sono
stati realizzati i seguenti componenti collaborativi:
   1. Browser Web;
   2. Lavagna di disegno;
   3. Text editor.
   Questi componenti sono stati integrati in un sistema di gestione
del floor realizzato partendo dal quello realizzato in precedenza per
CollAWT. In figura 3 viene mostrata la finestra di CollSwing.
   I componenti di CollSwing sono poi stati integrati in all‟interno di
una scrivania condivisa che li consente a tutti i collaboratori di avere
un ambiente di lavoro comune uniforme.




     Figura 3 – Finestra del prototipo realizzato di CollSwing.



                                                                              49
   Per quanto riguarda il livello multimediale, in quest‟ultimo
semestre sono stati corretti alcuni problemi riscontrati nel client di
video-on-demand dovuti principalmente allo stato ancora non
definitivo della libreria JMF. Inoltre è stato realizzato un sistema di
video-conferenza integrato con CollSwing. In figura 3 e visibile il
componente di video-conferenza e stato integrato con la scrivania
condivisa offerta da CollSwing.




                                                                          50
       Progetto di ricerca applicata CNR 5%
 "Rete multimediale interattiva di accesso all'utente"



                       Linea 2:
"Servizi multimediali interattivi su rete ottica passiva”




            Unità di ricerca della
    UNIVERSITA’ DEGLI STUDI DI ANCONA




               Rapporto sull’attività del
                 SECONDO ANNO




                    Novembre 2000



                                                            51
La rete Internet ormai ha una diffusione così capillare, che
anche i fornitori di servizi vengono a trovarsi nelle stesse
condizioni di accesso in cui sono tutti gli utenti. Cioè, nella
prospettiva di una rete PON con terminazioni lato utente di tipo
ONU, vi saranno ONU a cui sono connessi solo utenti
(tipicamente in numero elevato), e ONU a cui sono connessi
alcuni fornitori di servizi. Questo scenario sottintende una
minor rilevanza della distinzione tra trasmissioni upstream e
downstream.
Durante la prima parte del primo anno di ricerca è stato
analizzato il modello FSAN, che impiega una sola lunghezza
d'onda a divisione di tempo, con velocità di cifra upstream di
155 Mbit/s e downstream di 622 Mbit/s. Sono state eseguite
simulazioni che hanno condotto alla conclusione che questa
struttura non è in grado di supportare la prevista crescita dei
servizi offerti.
Più precisamente sono state sviluppate simulazioni del
comportamento di una rete sottoposta a carichi crescenti di
traffico multicast. Si è ipotizzato che i pacchetti IP fossero
suddivisi in celle ATM, e si sono considerati anche sorgenti e
destinatari posti entro la rete di trasporto, cioè dietro la OLT.
E' stato messo a punto un algoritmo, denominato DVMA-CC
ottimizzato per connessioni multicast su reti ottiche [1]. E' stata
effettuata una simulazione considerando una rete con 20 nodi
debolmente magliata.
Le prestazioni dell'algoritmo DVMA-CC sono state confrontate
con quelle di algoritmi alternativi per mezzo di un software di
simulazione sviluppato ad hoc, ipotizzando diverse condizioni
operative e valutando l'effetto di una coesistenza in rete di
traffico unicast e multicast. In particolare,sono stati presi in
considerazione gli algoritmi Dijkstra, DVMA e DVMA-CC.
La rete a 20 nodi considerata, avente un grado di connessione
medio pari a 3.2, ricalca approssimativamente la mappa
autostradale italiana (nodi in Aosta, Torino, Milano, Trento,
Udine, Trieste, Venezia, Verona, Genova, Piacenza, Bologna,
Firenze, Ancona, Perugia, Pescara, Roma, Bari, Napoli,
Cosenza, Taranto). Le simulazioni hanno avuto per oggetto la
valutazione delle prestazioni degli algoritmi in esame, applicati
ad una rete con capacità trasmissiva di 10 Gbit/s. In rete, oltre
al traffico multicast, è presente un traffico di sotto-fondo unicast.
Nel corso delle simulazioni il carico unicast è stato fatto variare
da un valore minimo del 10% fino a un valore massimo
dell'80%. Il problema più vincolante si pone tuttavia nella rete di
accesso, in cui, come anticipato, il modello FSAN, che prevede
flussi a 155-622 Mbit/s su una sola lunghezza d'onda, non
consente di smaltire il traffico. Essa si comporta come una sorta
di collo di bottiglia per l'intera rete.




                                                                        52
Nel seguito è stato allora preso in considerazione un modello
con più lunghezze d'onda, in tecnica TDMA-WDM. Si possono
adottare fino a 16 lunghezze d'onda. Sono stati considerati
diversi tipi di protocollo per l'accesso multiplo, riservando
sempre un canale per la gestione e il controllo della rete. Nella
OLT vi sono ricevitori e trasmettitori non accordabili per tutte le
n lunghezze d'onda. In una ONU in generale vengono usati un
trasmettitore e un ricevitore entrambi accordabili. Talvolta è
necessario un trasmettitore o una coppia trasmettitore-ricevitore
a lunghezza d'onda fissa per il canale di controllo.
Sono stati impiegati come riferimento i protocolli slotted-ALOHA
e CSMA, diversamente combinati nel canale di controllo e nei
canali di informazione.

L‟uso di appropriati protocolli diventa una prerogativa
essenziale nelle reti in WDM, al fine di permettere sia una
efficace ed elegante utilizzazione della banda totale disponibile
nella fibra ottica sia per risolvere i problemi di instradamento, di
prenotazione e di collisione che potenzialmente esistono fra
pacchetti spediti da diverse sorgenti. È usuale fare una
distinzione fra:
Collisione di canale (o di messaggio), quando due sorgenti
tentano di usare la stessa lunghezza d‟onda per trasmissioni
simultanee;
Collisione di ricevitore (o di destinazione), quando il numero di
messaggi che simultaneamente arrivano al nodo destinazione
eccede la capacità di ricezione del nodo stesso, ad esempio nel
caso in cui un nodo sia fornito di un solo ricevitore, può ricevere
e rivelare con successo al massimo un pacchetto alla volta.
Fra i vari tipi di protocolli esistenti in letteratura, i quali possono
essere suddivisi in base al modo in cui la banda viene
assegnata ai vari canali, nel seguito di questo lavoro verranno
descritti in dettaglio alcuni protocolli ad allocazione dinamica del
tipo Random Access Protocols with Pretransmission
Coordination. In particolare tali protocolli verranno applicati al
flusso upstream che caratterizza le reti PON, il quale
rappresenta il tema centrale di tale lavoro.
Rispetto ai protocolli originali quelli presentati nei successivi
capitoli presentano delle piccole varianti, che permettono di
adattarli alla topologia della PON ed alla struttura NIU delle
ONU e della OLT.
Per unifornità di notazione si fa presente che il numero di ONU
verrà indicato in seguito con N; inoltre, considerando di dividere
la banda in W+1 lunghezze d‟onda, 0, 1, 2,…, W , la
lunghezza d‟onda 0 sarà usata per indicare il canale di
controllo (il quale ha come scopo quello di trovare la soluzione
ottima per la coordinazione della trasmissione fra ONU e OLT,
soprattutto quando il traffico varia in modo dinamico), mentre le



                                                                          53
lunghezze d‟onda 1, 2,…, W, saranno usate come canali
dati. I particolari di utilizzo delle lunghezze d‟onda verranno
descritti in seguito. In generale risulta essere WN.
Facendo riferimento alla notazione standard, si suppone inoltre
che la struttura NIU della OLT sia di tipo FTW+1-FRW+1, cioè
che ci siano trasmettitori fissi e ricevitori fissi in numero pari alle
lunghezze d‟onda utilizzate dalla rete: i ricevitori fissi sono
accordati sulle lunghezze d‟onda del flusso upstream (seconda
finestra), mentre i trasmettitori fissi sono accordati sulle
lunghezze d‟onda del flusso downstream (terza finestra).
Viceversa per le ONU l‟uso di ricevitori e trasmettitori multipli
implica un sensibile aumento dei costi, quindi la scelta migliore
è quella di adottare un sistema base di tipo TT-TR, con
trasmettitori accordabili e ricevitori accordabili in grado di
spaziare su tutte le lunghezze d‟onda.
Sono state effettuate un numero di simulazioni tale da
consentire l'analisi della rete in ogni suo aspetto, mettendo a
confronto le risposte fornite dopo aver sottoposto la rete a
diversi input. Particolare attenzione è stata posta al
raggiungimento della condizione di fairness, alla prestazione in
termini di percentuale di pacchetti spediti e di ritardi, al
throughput. Le conclusioni che sono emerse dall'analisi dei
risultati sono le seguenti:
- Utilizzo flessibile della banda disponibile nella fibra ottica;
- Possibilità di ottenere una equa occupazione di tutte le
    lunghezze d'onda a disposizione della rete (condizione di
    fairness);
- Raggiungimento di ottime prestazioni riguardanti la
    percentuale di pacchetti spediti per particolari topologie ed
    in particolari condizioni di carico;
- Bassi ritardi di trasmissione dei pacchetti nel caso di utilizzo
    di un numero adeguato di lunghezze d'onda;
- L'efficienza del protocollo New Reservation ALOHA dipende
    dall'efficienza del canale di controllo; l'aspetto più critico
    risulta essere la lunghezza della fibra ottica che va dalle
    ONU allo splitter;
- Possibilità di upgrade di reti PON senza pesanti interventi
    nella struttura di rete già esistente.
Le simulazioni svolte hanno permesso di valutare sia quale è il
comportamento generale della rete PON, sia in quale maniera
le potenzialità della tecnica WDM vengono sfruttate utilizzando
il protocollo New Reservation ALOHA. Inoltre si può capire in
che modo ed in che misura le relazioni che intercorrono fra i
vari parametri consentono di raggiungere determinate
prestazioni.
Particolare attenzione è stata posta al concetto di fairness,
importante per stabilire una equa utilizzazione dei canali
disponibili nella fibra ottica. A questo proposito può essere



                                                                          54
messo in risalto un aspetto che è emerso dalle simulazioni
svolte del quale si deve tener conto in una eventuale fase di
progettazione della rete. Dai grafici riportati risulta evidente che
in alcune situazioni particolari non tutte le lunghezze d'onda
disponibili nella fibra ottica vengono utilizzate. Si tratta di un
fatto di fondamentale importanza se si considera
l'equipaggiamento degli apparati trasmettitore-ricevitore da
installare nelle ONU e nella OLT. Infatti fornire le ONU di laser e
ricevitori accordabili su un range di lunghezze d'onda superiore
a quelle che poi saranno effettivamente utilizzate e,
analogamente, fornire la OLT di laser e ricevitori fissi in numero
superiore alle reali esigenze, porterebbe ad un'inevitabile
spreco di risorse messe a disposizione della rete con
conseguente aumento dei costi. Per contro, eventuali canali
non utilizzati dalla totalità delle ONU, potrebbero essere messi
a disposizione di utenti con particolari esigenze di traffico ed
essere utilizzati come canali dedicati.
I risultati di tutto questo lavoro saranno pubblicati su una rivista
specializzata nel corso del prossimo anno.
In parallelo è stata condotta una analisi dei dispositivi fotonici
con i quali sarebbe possibile effettuare instradamenti di
pacchetti dati a diverse lunghezze d'onda entro la rete PON [2].
Si tratta di autoinstradamenti possibili disponendo di
componenti che sfruttano solitoni spaziali indotti da opportune
non linearità ottiche.
In alternativa, si possono considerare dispositivi in cui una
lunghezza d'onda è impiegata come segnale di controllo [3]. In
questo modo, sfruttando l'effetto noto come four-wave mixing,
la lunghezza d'onda del segnale utile viene instradata verso la
terminazione di uscita di una opportuna matrice di
commutazione.
Allo scopo di registrare indirizzi o informazioni utili per
l'instradamento a livello ottico, o anche solo di memorizzare
temporaneamente pacchetti di informazione molto brevi, sono
stati studiati modelli di registri a scorrimento completamente
ottici [4].
La memorizzazione ottica impone l'utilizzo di nuovi materiali e di
fenomeni fisici idonei allo scopo. Tra essi, alcuni si basano sulla
così detta eco fotonica stimolata. Sfruttando l'interazione tra
luce e materia, è possibile conseguire una modulazione della
popolazione dei livelli energetici, in funzione del dato di
ingresso. Entro un certo tempo dalla formazione del reticolo,
dipendente dal materiale, il dato immagazzinato può essere
utilizzato, riletto ed, eventualmente, cancellato.
La lettura sequenziale di più celle di memoria disposte in
cascata, suggerisce dunque la possibilità di realizzare un
registro a scorrimento completamente ottico, le cui
caratteristiche funzionali sono del tutto analoghe a quelle del




                                                                       55
corrispondente componente elettronico. Una promettente
finalizzazione della memorizzazione ottica è rinvenibile
nell'estrazione diretta dell'indirizzo di destinazione dal flusso
dati in ingresso ad un nodo di biforcazione, ai fini
dell'instradamento completamente ottico del pacchetto.

Il secondo anno di ricerca è iniziato cercando di svolgere una
rassegna sulle prospettive delle tecnologie fotoniche più
promettenti [5]. Infatti molte pubblicazioni internazionali si
riferiscono a modelli puramente teorici, la cui fattibilità
industriale è ancora molto difficile da dimostrare.
Svolgendo questa rassegna, si è constatato come sarebbe
massimamente importante, dal punto di vista della strategia
della ricerca italiana, poter avviare un progetto nazionale sulla
fotonica [6].
A questo punto si è ripresa l'analisi dei servizi multicast, che
appaiono quelli più critici, anche in termini di ritardo
interdestinazione per la consegna dei pacchetti. Come all'inizio
dell'anno precedente, si sono considerati i seguenti PON come
code di una più ampia rete di trasporto. E' stata imposta una
serie di requisiti in termini QoS, e si è cercato di minimizzare nel
contempo il costo totale di connessione [7].
L'attraversamento di ciascun nodo è stato tenuto in conto
tramite l'introduzione di un ritardo che corrisponde al tempo di
attesa in coda del pacchetto considerato. Questo processo
scaturisce dal fatto che il numero delle lunghezze d'onda, e dei
time slot su ciascuna lunghezza d'onda, è limitato lungo ogni
ramo della rete, per questioni di contenimento dei costi.
L'algoritmo di instradamento multicast può fornire utili vantaggi
nel contenere il numero di risorse disponibili in una rete di
trasporto - accesso su cui sia stata adottata una multiplazione
TDM - WDM.
In particolare, il segmento su rete PON acquisterà la
caratteristica tipica dell'accesso ad un canale comune,
soprattutto per l'eventuale lunghezza d'onda riservata ai segnali
di controllo. La modalità di trasmissione sarà dunque di tipo
TDMA-WDM. Si sono allora confrontate le prestazioni di diversi
algoritmi di instradamento, alcuni più orientati alla
minimizzazione dei costi di connessione, altri più specifici per
conseguire risultati in termini di QoS [8].
In luogo della divisione di tempo (TDM), si può poi considerare
una divisione di codice (CDM). Il sistema, nell'ambito della
PON, acquisirebbe così la caratteristica CDMA-WDM. Sono allo
studio tecniche di modulazione e codifica combinate, le quali
sfruttano un dominio bidimensionale costituito dall'insieme delle
lunghezze d'onda e dall'insieme dei codici a spettro allargato
che sono disponibili per una modulazione di intensità ottica. E'




                                                                       56
stato necessario organizzare la rete su due strati, per quanto
riguarda le lunghezze d'onda [9].
E' stato messo a punto un metodo per progettare reti ottiche
WDM organizzate su più strati; l'originalità del metodo consiste
nell'aver messo a punto un modello analitico anziché dover
procedere con una serie di simulazioni. Tale modello analitico
prende in considerazione valori variabili del numero di utenti e
di lunghezze d'onda in ciascuna ONU. Vengono ricavate
espressioni in forma chiusa per la capacità di trasmissione e il
numero ottimo di canali, a valle e a monte di una OLT.
Si è ottenuto il progetto di una rete interamente ottica, in cui
lunghezze d'onda e sequenze di codice possono essere
continuate attraverso una OLT facendo restare il segnale in
opportuno formato ottico. Questo modello richiede solo la
verifica della fattibilità tecnologica di particolari componenti
passivi da installare presso le ONU.
Esse dovrebbero emettere una sola sequenza di codice
(caratteristica della ONU), ma adattarsi in ricezione alla
sequenza di codice inviata dal nodo trasmittente.
E' stato considerato il caso di 4 lunghezze d'onda e sequenze di
15 sottointervalli temporali. In questo modo si possono servire
fino a 8 ONU per ciascuna OLT. Si tratta di una topologia
particolarmente idonea per PON con un basso numero di ONU,
ciascuna delle quali caratterizzata da una elevata esigenza di
connettività (ad esempio 2 Gbit/s).




                                                                   57
                             Bibliografia
[1] A. Amorini, A. Borella, G. Cancellieri: "Algoritmo DVMA-CC
   per    connessioni multicast su reti ottiche", Atti del Convegno
   Fotonica 99, Trento 2-4 giugno 1999, p. 433-436

[2] F. Chiaraluce, E. Gambi, P. Pierleoni: "Design of an all-optical
   wavelength router based on spatial solitons", J. Lightwave
   Technol., 17, 1670-1681, 1999

[3] A. Bartoli, F. Chiaraluce, E. Gambi, P. Pierleoni: "Interazione di
   solitoni spaziali a tre colori", Atti del Convegno Fotonica 99,
   Trento 2-4 giugno 1999, p. 379-382

[4]      G. Bruschi, F. Chiaraluce, E. Gambi, P. Pierleoni:
      "Modellizzazione di un registro a scorrimento completamente
      ottico", Atti del Convegno Fotonica 99, Trento 2-4 giugno 1999, p.
      73-76

[5] G. Cancellieri, C.G. Someda:" Vision and prospectives on
   technologies", Proceedings del International Forum on Optical
   Transport Networks 2000, Taormina 5-6 ottobre 2000, p. 57-61

[6] G. Cancellieri: "Importanza di un Progetto Nazionale sulla
   Fotonica", Alta frequenza - rivista di elettronica, 12 , p. 54-58,
   2000

[7] A. Borella, G. Cancellieri: "Improving the cost/performance ratio
   in multicast communication" , Proc. NOC 2000, Stuttgart, 6-9
   giugno 2000, p. 187-190

[8] A. Borella, G. Cancellieri: "Remote time alignment of interactive
   services through efficient multicast algorithms", Proc.
   IEEE.ECUMN, Colmar 16-18 Ottobre 2000, p. 239-24

[9] A. Borella, G. Cancellieri, F. Chiaraluce: "Design techniques of
   twolayer architectures for WDM optical networks", accettato per la
   pubblicazione su International J. Of Communication




                                                                           58
         Progetto di ricerca applicata 5%
 “Rete Multimediale interattiva di accesso all’utente”




                        Linea 2:

“Servizi multimediali interattivi su rete ottica passiva”




      Unita’ di ricerca del Politecnico di Bari




             Relazione sulle attività del

                  SECONDO ANNO



                    Novembre 2000




                                                            59
Obiettivo della ricerca
  Il progetto di ricerca dell'unità operante presso il Dipartimento di Elettrotecnica ed
Elettronica del Politecnico di Bari ha riguardato lo studio e la parziale
sperimentazione in laboratorio di alcuni aspetti inerenti i servizi multimediali a larga
banda (Video on Demand Interattivo, Teledidattica Interattiva, ecc.)
  L'obiettivo della ricerca è stato quindi la caratterizzazione dei suddetti servizi
multimediali studiandone le prestazioni in ambienti di reti eterogenee e proponendo
delle opportune soluzioni in termini di protocolli, di architetture di rete, di apparati di
utente e architettura dei “server” e dei “client”, in modo da garantire i requisiti di
qualità tipici delle applicazioni multimediali.
  In particolare, la ricerca si è sviluppata seguendo tre temi tra loro strettamente
interconnessi:

  - Strategie di schedulazione in sistemi di distribuzione video
  - Sistemi d’utente e server
  - Stima della banda aggregata e relativi algoritmi di controllo di ammissione

   Per quanto attiene il primo tema, Strategie di schedulazione in sistemi di
distribuzione video, l‟obiettivo è stato quello di ottimizzare l‟utilizzo delle risorse del
sistema (banda, capacità del server, memoria, ecc.), allo scopo di massimizzare gli
utenti serviti con i consueti vincoli di Qualità del Servizio (QoS). Allo scopo, in
letteratura erano già presenti delle proposte basate su tecniche di Batching,
Buffering, Patching, ecc. Per ognuna di queste tecniche, sono state proposte dei
miglioramenti e ne sono stati analizzati gli aspetti quantitativi sia attraverso modelli
analitici, sia tramite strumenti di simulazione ad eventi.
   Sinteticamente, nella tecnica di Batching le richieste degli utenti per lo stesso
video, emesse entro un breve intervallo temporale (tempo di batch), vengono
accorpate e servite con un unico flusso video sfruttando un protocollo multicast. E‟
evidente che alcuni utenti sono costretti ad attendere prima di inziare a ricevere il
video richiesto. Simile alla precedente è la tecnica di Buffering, in cui il flusso video
trasmesso dal server viene memorizzato in memoria centrale da cui si dipartono
svariati flussi per i vari utenti a tempi diversi purché entro l‟intervallo di batch. In
questo caso non c‟è attesa ma deve essere disponibile una grande quantità di
memoria ad alta velocità
   Per le suddette tecniche di Batching/Buffering è stato impostato un modello di
prestazioni basato sulla teoria delle reti di code che permette di esprimere i parametri
di prestazione (numero medio di flussi, percentuale di riduzione delle risorse, ecc.) in
funzione dell‟intervallo di batch e della intensità delle richieste da parte degli utenti. I
risultati ottenuti dal modello analitico sono stati validati tramite simulazione ad eventi
sviluppando idonee procedure di simulazione.
   I risultati ottenuti mostrano che il risparmio in termini di banda trasmissiva sono
consistenti e possono raggiungere valori elevati              (50%-60%), ovviamente in
dipendenza dell‟intervallo di batch.
   Sempre nell‟ambito di questo primo tema, la tecnica di patching consiste nel
catturare dai flussi già presenti spezzoni di filmato da memorizzare nel buffer degli
utenti, recuperando dal server gli spezzoni mancanti. In questo ambito sono stati
sviluppati dei miglioramenti agli algoritmi già presenti in letteratura, adattandoli al



                                                                                         60
contesto studiato tenendo presente i vincoli di semplicità e implementabilità degli
algoritmi stessi. Inoltre, è stato proposto e analizzato un algoritmo originale di
controllo di ammissione, operazione indispensabile in contesti di servizi a qualità
garantita.
  Per quanto attiene il secondo tema, Sistemi d’utente e server, sono stati
considerati diversi aspetti. In particolare, sono state analizzate le prestazioni del
protocollo TCP/IP considerando sia modelli analitici sia effettuando delle misure
sperimentali in laboratorio. Inoltre, e‟ stato sviluppato un prototipo di laboratorio di un
sistema di Video on Demand (VoD), caratterizzandolo in termini di prestazioni tramite
misure sperimentali.
  Nello specifico, e‟ stato sviluppato un modello analitico per valutare le prestazioni di
differenti implementazioni del protocollo TCP/IP nei sistemi d‟utente e nei servers. Il
modello, basato sulla teoria delle reti di code, permette di analizzare gli effetti delle
diverse scelte implementative (Single copy, Two copy, ecc.) sulle prestazioni globali
del sistema. I risultati ottenuti dal modello analitico sono stati confrontati con misure
sperimentali già presenti in letteratura.
  Sempre nell‟ambito di questo secondo tema è stato impostato un prototipo di
laboratorio di Video on Demand (VoD). Le caratteristiche principali della scelte
progettuali effettuate sono l‟indipendenza dalla piattaforma, la semplicità d‟uso, e la
modularità per future espansioni. Per l‟implementazione sono state utilizzate
tecnologie Java, HTTP, RTP, ecc., sfruttando gli ambienti di lavoro ormai standard
nell‟ambito di Internet. In particolare, il prototipo sviluppato è costituito da svariati
moduli di cui particolare rilievo assumono il modulo “Server” e il modulo “Client” oltre
ai moduli che implementano il protocollo di comunicazione tra il server ed i vari
“Client”. Il sistema può essere caratterizzato introducendo specifici parametri quali ad
esempio il buffer del “Client”, la soglia di inizio della decodifica da parte del “Player”,
ecc. Specifiche misure effettuate nel suddetto prototipo di laboratorio hanno
permesso di scegliere il valore ottimale dei parametri stessi adattandoli al contesto in
considerazione.
  A titolo di esempio nella figura seguente viene riportato una schermata tipica del
“Client”.




                                                                                        61
   Il terzo tema affrontato considera la Stima della banda aggregata e relativi
algoritmi di controllo di ammissione in sistemi di distribuzione video. In
particolare, si suppone di distribuire video memorizzato, codificato tramite algoritmi
standard a bit rate variabile (MPEG, ecc.) Nello studio affrontato, vengono proposti
vari algoritmi originali per la stima della banda aggregata necessaria per trasmettere
un dato numero di flussi video. Ciascun flusso video e‟ caratterizzato, in termini di
banda occupata, dalla sua distribuzione marginale, approssimata da un istogramma
ricavato da tracce video reali. A titolo di esempio, in Figura 1 si rappresenta il bit rate
dei primi 15000 frames del film “Star Wars”




        Figura 1a – 15000 frames del film “Star Wars” codificato con MPEG-1.


  Risulta evidente dalla figura, l‟estrema variabilità del bit rate richiesto. Questo
aspetto non permette un uso ottimale delle risorse di banda disponibile in rete. Allo
scopo di attenuare il suddetto problema, in letteratura, sono state proposte tecniche
di smoothing che sfruttando un buffer utente permettono di ridurre la variabilità del bit
rate. In figura 1b viene riportato il risultato dell‟applicazione dei suddetti algoritmi di
smoothing al filmato “Star Wars”.




   Figura 1b – 15000 frames del film “Star Wars” con smoothing (buffer = 256 KB).


  Si evince che la variabilità del bit rate è notevolmente ridotta come del resto si può
osservare nelle figure 2a e 2b.




                                                                                         62
     Figura 2a – Distribuzione del bit rate per il film “Star Wars” senza smoothing.




       Figura 2b – Distribuzione del bit rate per il film “Star Wars” con smoothing
                                   (buffer 256 KB).


  Un problema significativo in tali sistemi risulta la stima della banda aggregata
necessaria per il dimensionamento della infrastruttura di rete e per il controllo di
ammissione.
  Il gruppo di ricerca del Politecnico di Bari ha proposto vari algoritmi originali per
valutare la banda aggregata richiesta da N flussi video omogenei (ossia con le
stesse caratteristiche statistiche) e non omogenei. Nel caso di flussi omogenei, si
dimostra la seguente relazione statistica tra banda aggregata richiesta  e la banda
disponibile S.
                                                                                       
                                                                                       
                                                                       
                                          h                                  K

                          p(  s)
                                                                                      ni
                                                                                   pi 
                                                                       N!
                                                                                   ni! 
                                          jN
                                                 nnn2 ...n K  N j
                                                    1                        i 1
                                                                                        
                                                 1 2 n2 ... KnK                     
  dove, n1, n2, …, nK, indicano il numero di flussi che sfruttano il bit rate r1, r2, … ,rK ;
con  = n1r1+ n2r2 + … + nKrK ; n1+ n2+…+ nK = N; h =  s r1  . Indicando con a il
termine in parentesi, la precedente equazione può essere scritta:
                                              h      
                                p(   s )  a jN 
                                              jN    
                                                     



                                                                                            63
  I valori di a possono essere ricavati tramite semplici soluzioni iterative, una delle
quali è la seguente.
                                                    K 1


                                                           ( N 1)i                      j 1,...,( K 1) N
                 p1a j                                     j       - 1 pi1 a ji where 
                                                    i 1
                                                                                         a ji  0; j i  0
con la condizione iniziale a0 = p1 N. I risultati ottenuti tramite i modelli analitici, allo
scopo di validarne l‟efficacia, sono stati confrontati con i risultati ottenuti tramite
simulazione. In Fig. 3 viene riportato un esempio di tali risultati considerando
istogrammi con crescente livello di complessità in termini di numero di barre.
Dall‟analisi dei risultati, si evince che il modello analitico è leggermente conservativo
e, come ovvio, i risultati ricavati utilizzando un istogramma più preciso sono più
coerenti con i risultati di simulazione.
                                                    50
                                                    45
                       Aggregate Bandwidth (Mb/s)




                                                    40
                                                    35
                                                    30
                                                    25
                                                    20                                                Simulation
                                                                                                      Histograms - 5 bins
                                                    15
                                                                                                      Histograms - 10 bins
                                                    10                                                Histograms - 15 bins
                                                     5                                                Histograms - 20 bins

                                                     0
                                                           10   20   30   40      50      60     70    80      90      100
                                                                               Number of Streams

      Fig. 3 – Banda Aggregata per il film Star Wars con prob. di perdita di 10 -5 .
  Modelli e risultati simili sono stati ricavati nel caso di flussi non omogenei, ossia
con caratteristiche statistiche differenti. In particolare,
                                                                                        N             M       Km
                                                                                                                      m pmr n
                                                                                       
                                                    h                                                                                mr

           P (   s )  a j N con a jN                                                    N!
                                             j N                              n11 ...n MkM  N     m1     r 1
                                                                                                                             nmr !
                                                                          n11r11 ...n MkM rMkM  Λs

  Anche in questo caso sono state ricavate formule iterative simili al caso omogeneo.
A titolo di esempio, si riportano i risultati ottenuti considerando tre filmati (Star Wars,
Asterix e Mr Bean) da cui ricavare gli N flussi trasmessi.




          Fig. 8 – Banda Aggregata per i tre films con prob. di perdita di 10-6.




                                                                                                                                          64
  Anche in questo caso, dall‟analisi dei risultati, si evince che il modello analitico è
leggermente conservativo e i risultati ricavati utilizzando un istogramma più preciso
sono più coerenti con i risultati di simulazione, anche se ad un certo punto si
raggiunge una saturazione, ad esempio i risultati ottenuti con 15 e 20 barre
dell‟istogramma sono praticamente simili.




                                                                                      65
Principali Pubblicazioni Scientifiche
[1] P. Camarda, F. Pipio, G. Piscitelli; “Performance Evaluation of TCP/IP Protocol
     Implementations in End Systems” IEE Proceedings - Computers and Digital
     Techniques.Vol.146, N.1, Gennaio 1999.

[2] G. Boggia, P. Camarda, M. Mongiello, P.L. Mazzeo "Multicast Distribution for
     Video on Demand Services" ICCT2000, Beijing, China, August 21-25, 2000.

[3] G. Boggia, P. Camarda, M. Tortorici "Admission Control for Distribution of
     Smoothed Video Using Patching Algorithms” International Workshop on QoS in
     Multiservice IP Networks (QoS-IP 2001), Roma, Gennaio 2001.

[4] G. Boggia, P. Camarda, D. Striccoli “Aggregate Bandwidth Estimation in Video
     Distribution Systems” in corso di pubblicazione.

[5] G. Boggia, P. Camarda, M. Tortorici "Multi Source Connection Admission in
     Video Distribution Systems exploiting Patching Algorithms” in corso di
     pubblicazione.

[6] G. Boggia, P. Camarda, M. Tortorici "Optimal Bandwidth Utilization in VoD
     Systems exploiting Patching Algorithms” in corso di pubblicazione.

[7] G. Boggia, P. Camarda, D. Striccoli “Modeling Statistical Admission Control in
     Video Distribution Systems” in corso di pubblicazione.




                                                                                      66
                               Deliverable contrattuale



              L'integrazione delle funzionalità ATM nei sistemi PON




Data di redazione:      22 novembre 2000
Riservatezza:           CONFIDENZIALE
Numero di pagine:       121
AUTORI:                 Marco POLANO (IN/DI)
                        Giancarlo LASAGNA (IN/DI)
REVISORE                Angelantonio GNAZZO (IN/DI)
APPROVAZIONE:           Alberto BROSIO (IN/DI)


Executive summary

ll presente deliverable contrattuale, che si colloca all‟interno del progetto P13
“Evoluzione della rete di accesso” ed in particolare nel Task 1 relativo al Progetto
MURST “Servizi multimediali interattivi su rete ottica passiva”, costituisce la
relazione sull‟attività svolta nel secondo anno di Progetto nel sottotema
“ATM/TDM/TDMA su PON”.
Nei sistemi PON sono state standardizzate le funzioni di “transmission convergence”
per l‟inserimento delle celle nella struttura di trama, sia nella trasmissione verso gli
utilizzatori, con tecnica a divisione di tempo (Time Division Multiplexing, TDM), sia in
direzione opposta, con tecnica Time Division Multiple Access (TDMA) per consentire
l‟accesso multiplo agli utilizzatori.
L‟introduzione in tale piattaforma d‟ulteriori funzioni ATM per la fornitura di servizi di
qualità controllata e l‟allocazione dinamica delle risorse va valutata individuando, nel
quadro dei possibili scenari di servizi evoluti per reti di accesso “full services”, le
soluzioni più efficaci in base alla richiesta e al tipo di servizio.
In questo documento, partendo da un‟analisi delle caratteristiche di sistemi PON con
tecnica TDM/TDMA disponibili sul mercato, sono discussi gli aspetti legati
all‟integrazione ottimale dei servizi su tali sistemi.




                                                                                        67
Indice del documento

1   Introduzione
2   Sistemi PON commerciali
    2.1 FMX-AP - Fujitsu
        2.1.1 Descrizione generale
        2.1.2 Architettura, apparati e sistema di gestione
        2.1.3 Sviluppi previsti
    2.2 Sistema iFLX-FSP - Marconi-BBT
        2.2.1 Descrizione generale
        2.2.2 Servizi
        2.2.3 Architettura, apparati e sistema di gestione
        2.2.4 Sviluppi previsti
3   Evoluzioni dello standard G.983
    3.1 WDM
    3.2 Allocazione dinamica della banda
    3.3 Robustezza del sistema nei confronti di guasti della rete ottica
4   Integrazione dei servizi video multicast nei sistemi PON
    4.1 Scenario ATM End-to-End
        4.1.1 Lo “User Plane”
        4.1.2 Il “Control Plane”
    4.2 Scenario IP End-to-End
        4.2.1 Lo “User Plane”
        4.2.2 Il “Control Plane”
5   Conclusioni
6   Bibliografia
7   Elenco degli acronimi e delle sigle




                                                                           68
1 Introduzione
      L‟obiettivo del progetto di ricerca triennale finanziato dal MURST “Servizi
multimediali interattivi su rete ottica passiva” è la dimostrazione della funzionalità alla
teledidattica di una rete ottica di accesso all'utente di tipo PON (Passive Optical
Network) da realizzare nella rete cablata con fibra ottica sull'Area delle Scienze
dell'Università degli Studi di Parma.
      L‟esperimento di teledidattica previsto nel Progetto fa uso di un video server,
situato presso il CED (Centro Elaborazione Dati) e di un certo numero di terminali
video, distribuiti nel CED stesso e presso la Facoltà di Ingegneria. Il video server e i
terminali saranno collegati tra loro per mezzo di una PON a due fibre, una per la
trasmissione verso i terminali e l‟altra per la trasmissione verso il video server.
      Obiettivo dell‟attività del sottotema 2.3.5 (ATM/TDM/TDMA su PON) è la
definizione delle modalità per l‟integrazione della tecnica ATM (Asynchronous
Transfer Mode), su una rete PON, basata sulla condivisione del mezzo trasmissivo
con l‟impiego di tecniche di multiplazione e di protocolli di accesso a divisione di
tempo (TDM/TDMA).
     Il presente rapporto, che espone l‟attività svolta nel secondo anno, tratta le
problematiche connesse con l‟introduzione di funzioni ATM orientate al servizio, quali
la gestione del traffico multicast e l‟allocazione dinamica delle risorse, nei sistemi
operanti su reti PON con tecnica TDM/TDMA.
      Nei sistemi per l‟accesso ATM-PON sono state standardizzate [1] le funzioni di
“transmission convergence” per l‟inserimento delle celle nella struttura di trama, sia
nella trasmissione verso gli utilizzatori, con tecnica a divisione di tempo (Time
Division Multiplexing, TDM), sia in direzione opposta, con tecnica Time Division
Multiple Access (TDMA) per consentire l‟accesso multiplo agli utilizzatori. Lo
standard di riferimento è la raccomandazione ITU-T G.983.1, in cui vengono indicati i
requisiti e le specifiche seguenti:
   Livello fisico: topologia, distanza, tipo di fibra, modello di riferimento della rete
    ottica, ...
   Physical Media Dependent layer (PMD): modulazione, livelli di potenza,
    maschera del segnale, ...
   Transmission Convergence layer (TC): Scrambling/Descrambling delle celle,
    delimitazione delle celle, codifica di linea, generazione dell‟HEC, ...
   Protocollo di ranging.
    Nella stessa raccomandazione non sono invece trattati i seguenti aspetti in
quanto maggiormente legati al servizio:
   Gestione della qualità del servizio.
   Allocazione dinamica delle risorse di banda.
   Gestione del traffico multicast.




                                                                                         69
       L‟integrazione di tali funzioni si rivelerebbe particolarmente utile ad esempio in
applicazioni quali la teledidattica e più in generale nella realizzazione di reti “full
services”. La tecnica ATM può essere utilizzata per dare una soluzione anche a
queste problematiche, come specificato ad esempio dalle raccomandazioni relative
alla gestione del traffico [3] e [6]. Tuttavia l‟applicazione di tali normative nel contesto
dei sistemi PON richiede un‟attenta valutazione al fine di integrare in modo ottimale
le funzioni sopra indicate, individuando, nel quadro dei possibili scenari di servizi
evoluti per reti di accesso “full services”, le soluzioni più efficaci in base alla richiesta
e al tipo di servizio.
      Sulla base di queste considerazioni, è stata condotta un‟analisi delle soluzioni
esistenti, benché parziali e/o proprietarie, adottate nei sistemi PON disponibili sul
mercato, per valutare in che misura le funzioni suddette fossero già state oggetto di
integrazione da parte dei costruttori. In particolare sono descritte le caratteristiche
funzionali di due sistemi PON, uno che utilizza la tecnologia VDSL per il
collegamento dell‟utente con doppini in rame, il secondo è invece orientato
all‟architettura FTTH e quindi pensato per il collegamento diretto dell‟utente in fibra. I
due sistemi sono stati scelti in quanto, oltre a rappresentare due differenti
architetture (FTTH e FTTCab), implementano alcune caratteristiche di maggior rilievo
per le tematiche sviluppate nel presente lavoro, collocandosi rispettivamente alle due
estremità delle possibili tipologie di prodotto per reti PON (pura conformità alla G.983
nel primo caso e non conformità alla norma stessa, con inserimento di alcune
funzioni ATM evolute, nel secondo):
Fujitsu FMX-AP (conforme alla G.983)
        Supporto di classi di servizio ATM di tipo CBR, UBR e GFR.
        Funzionalità di UPC e Traffic Shaping in direzione upstream.
        Capacità di bilanciare le risorse di banda in rete per connessioni di tipo
         GFR.
        Supporto di servizi di telefonia con meccanismi di emulazione di circuito
         ATM.
        Meccanismi di monitoraggio delle connessioni a livello ATM.
Marconi iFLX2500 (sistema non conforme alla G.983)
        Architettura di distribuzione video su ATM con funzionalità di multicast.
        Utilizzo di tecnica VDSL per il collegamento tra ONU e utente.
        Supporto di servizi di telefonia con meccanismi proprietari.
      Dopo aver descritto le caratteristiche salienti dei due sistemi PON presi in
esame, vengono presentate le evoluzioni dei sistemi PON in ambito normativo, in
particolare legate all‟incremento di prestazioni in termini di: capacità di banda,
gestione della stessa e robustezza del sistema nei confronti di guasti.
     Oltre alla G.983.1, recentemente è stata approvata una seconda
raccomandazione denominata G.983.2 che specifica in modo dettagliato gli aspetti di
gestione relativi al modello informativo delle ONU per applicazioni FTTH e il canale di
comunicazione di gestione fra OLT ed ONU.



                                                                                          70
     Nel seguito si citerà la raccomandazione G.983 intendendo fare riferimento ad
entrambe le raccomandazioni G.983.1 e G.983.2. Ove necessario sarà specificata la
raccomandazione a cui ci si riferisce.

2 Sistemi PON commerciali
2.1 FMX-AP - Fujitsu
2.1.1Descrizione generale

     Il sistema Fujitsu FMX-AP è nato con l‟obiettivo di sviluppare un prodotto con
caratteristiche conformi alla specifica per architetture FTTH redatta dagli operatori di
FSAN nel 1998. Tale specifica è stata creata per evidenziare i requisiti comuni degli
operatori coinvolti in termini di dimensionamento del sistema, standard utilizzati,
condizioni ambientali, ecc. Il risultato di tale attività è stato la creazione di un
documento di specifiche comuni chiamato “Common Technical Specification” (CTS),
che è stato discusso con alcuni costruttori interessati nello sviluppo della tecnologia
PON. L‟interesse di tali costruttori per la specifica comune risiede nella possibilità di
occupare diversi mercati con un‟unica famiglia comune di prodotti. La Fujitsu è stata
uno dei costruttori che si sono dimostrati maggiormente motivati nel recepire le
specifiche del CTS FTTH mediante lo sviluppo del sistema FMX-AP.
     La prima versione di tale sistema per architetture FTTH, disponibile dalla fine
del 1999, è conforme alla specifica G.983.1 e recepisce molte delle indicazioni della
raccomandazione G.983.2.
2.1.2 Architettura, apparati e sistema di gestione

    Il sistema è attualmente composto da tre elementi: OLT, ONT ed element
manager che vengono di seguito descritti.
OLT
       L‟OLT è l‟apparato collocato in centrale che consente da un lato di collegare gli
apparati in rete d‟accesso, e dall‟altro d‟interfacciarsi con la rete di trasporto. La OLT
consente di realizzare architetture FTTx (per ora solo FTTH) con topologia di rete
ottica ad albero (PON) o punto-punto e può essere equipaggiata in modo misto sia
con interfacce PON G983.1, sia con interfacce punto-punto di tipo STM-1. Verso la
rete di trasporto sono disponibili interfacce ATM su STM-1 e su STM-4. Sono inoltre
presenti un‟interfaccia per il collegamento all‟element manager e una interfaccia per
la sincronizzazione. Attualmente non sono disponibili interfacce per servizi NB. Le
seguenti tabelle riassumono le caratteristiche delle interfacce disponibili e quelle
dell‟interfaccia PON:




                                                                                       71
                    UNI          NNI    Sincronismo      Interfaccia
                                                        di gestione
                PON           STM-1    2Mbit/s HDB3     10 BaseT
                G983.1        400m     G.703
                0-20km        40km
                10-30km
                STM-1         STM-4    2Mbit/s sine     (gestione in
                30km          400m     wave G.703       banda non
                                                        disponibile)
                                       Da interfaccia
                                       NNI
                Tabella 1: Interfacce della OLT nel sistema FMX-AP

                Standard          G.983.1
                Topologia         PON con fattore di splitting 1:32
                Distanza          0-20km e 10-30km
                Schema             Upstream: 155Mbit/s (Burst
                trasmissivo         Mode TDMA)
                                   Downstream: 155Mbit/s (TDM)
                Caratteristich    1 fibra con WDM
                e ottiche         upstream 1.31m; downstream
                                  1.55m
                Allocazione       Fissa
                Banda
         Tabella 2: Caratteristiche dell‟interfaccia PON del sistema FMX-AP

Nel seguito vengono elencate le funzioni di livello ATM della OLT:
 Capacità di commutazione di 2.4Gbit/s per porta fino ad un massimo
  complessivo di 20Gbit/s.
 Cross-connessione sia del livello VP che di quello VC.
 Massimo numero di connessioni pari a 4096 per interfaccia NNI e 256 per
  interfaccia UNI.
 Capacità di trattare le classi di servizio UBR (senza garanzie), CBR (con
  garanzia sul PCR e sulla CDV) e GFR (con garanzia sul MCR).
 Funzioni di bandwidth sharing su connessioni verso la rete di trasporto
  mediante classe GFR e code separate per ciascun VC.
 Funzionalità UPC e traffic shaping nella direzione upstream.
 Funzionalità di OAM secondo la specifica I.610 incluso il performance
  monitoring.

La composizione dello shelf della OLT consente il seguente equipaggiamento:




                                                                              72
   40 interfacce di linea (sia UNI che NNI). Sia le interfacce NNI che quelle PON/UNI
    possono essere configurate in ridondanza 1+1. La ridondanza sulle interfacce
    PON prevede una doppia via fino al primo livello di splitting; quella sulle interfacce
    SDH è in conformità allo standard ITU-T G.783 Annex A.
   1 scheda SEM-IF. Comunica con l‟element manager, s‟interfaccia con le schede
    di controllo, raccoglie alcuni allarmi (per es. quelli relativi all‟armadio e alla
    ventilazione), immagazzina le informazioni di configurazione delle schede e del
    cestello.
   schede SVCONT per il controllo dello shelf, raccolta allarmi dalle altre schede,
    comunicazione intra-shelf fra schede, controllo delle funzioni di protezione,
    controllo delle interfacce di linea.
   1 scheda di OAM per la gestione e il controllo delle ONU. Comunica con le ONU
    mediante un canale di gestione sulla PON (OMCC).
   schede per la gestione del bandwidth sharing e il supporto delle connessioni GFR
    (supporta EPD/PPD).
   schede per l‟input del clock in protezione 1+1. Genera la sincronizzazione per il
    cestello.
   6 schede di multiplazione in protezione 1+1 per la raccolta del traffico dalle
    interfacce.
 2 schede di commutazione in protezione 1+1 con matrice 8x8 (2.4Gbit/s per
  porta).
  Le schede di commutazione gestiscono fino a 3 schede di multiplazione.
ONT
       L‟ONT è l‟apparato che termina la fibra a casa del cliente ed è quindi utilizzato
in configurazione FTTH. Funzionalmente la NT è composta da una interfaccia di
terminazione della rete di accesso, due interfacce di utente (dette line-cards) e una
componente di multiplazione dei flussi di traffico provenienti dagli utenti e diretti verso
la rete (o viceversa di de-multiplazione). Attualmente sono disponibili i seguenti tipi di
line-card: Ethernet 10/100BaseT, ATM Forum 25Mbit/s, ATM su STM-1 (mono e
multi modo) e E1 in circuit emulation su ATM (4 linee per line-card). Nel caso
dell‟interfaccia Ethernet la ONT è in grado di terminare il protocollo PPPTP
consentendo perciò l‟uso di un indirizzo IP pubblico all‟interno di una rete del cliente
con indirizzamento privato. La tabella seguente riporta le pile di protocolli utilizzate
nel caso d‟interfaccia di utente 10BaseT.




                                                                                        73
             Terminale               ONT                 OLT       ISP
             IP                                                  IP
             PPP             PPP           PPP                   PPP
             PPPTP/L2T       PPPTP/L2      AAL5                  AAL5
             P               TP
             Private IP      Private IP
             MAC             MAC           ATM                   ATM
             10BaseT         10BaseT       PON      PO     PH    PHY
                                                    N      Y
          Tabella 3: Protocolli utilizzati nella ONT con interfaccia 10BaseT

Element Manager
     La gestione del sistema FMX-AP è integrata nella soluzione per la gestione di
svariate teconologie di accesso proposta da Fujitsu e si chiama FLEXR EM/AC.
L‟element manager consente di avere una visione dell‟intera rete gestita e di
esaminare lo stato, l‟equipaggiamento e la collocazione di ciascun elemento. Per
quanto riguarda la gestione del sistema FMX-AP sono disponibili le funzioni di: fault
management and localisation, equipment provisioning and pre-provisioning
management, inventory management, service provisioning management,
performance management.
      L‟Interfaccia d‟utente è basata su web browser e consente due diverse viste,
una per il monitoring del cestello della OLT e una per il monitoring delle connessioni
ATM. L‟utente è in grado di effettuare le singole cross-connessioni (tra le varie
componenti del sistema) oppure di determinare solo gli estremi della connessione
desiderata; in questo caso il sistema effettua automaticamente le cross-connessioni
interne che si rendono necessarie.
2.1.3 Sviluppi previsti

      La Fujitsu ha rilasciato, nel corso di alcune presentazioni, la seguente roadmap
relativa agli sviluppi futuri del prodotto :

           metà            PON asimmetrica 622/155
           2001            interfaccia STM-16
           e oltre         Supporto ad anelli SDH
                           Interfaccia nxE1 nella OLT
                           IP layer-2 switching
                           Packet over SONET/SDH
                           VB5.2
                           SVC support

           Non          Interfacce OLT:
           specificat    STM-1 NNI 40km, 80km
           o             STM-4 NNI 400m, 40km, 80km
                         STM-1 elettrica
                         E1, E3, DS3




                                                                                    74
In particolare si fa notare che in futuro è prevista l‟integrazione di funzionalità di IP
switching e di segnalazione a livello ATM. Tali funzioni potrebbero contribuire in
maniera significativa ad un uso ottimale delle risorse della rete, pur mantenendo la
capacità di fornire elevate prestazioni in termini di QoS. Questo obiettivo potrebbe
essere raggiunto sia mediante una maggiore integrazione della rete con il mondo IP,
a cui la maggior parte delle applicazioni si riferiscono, sia attraverso la capacità della
rete di assegnare le risorse in maniera dinamica.
2.2.Sistema iFLX-FSP - Marconi-BBT
2.2.1 Descrizione generale

       Il sistema iFLX è basato sulla tecnologia PON ATM sviluppata dalla BroadBand
Technologies ed è pensato per architetture FTTCab/Building. La tecnologia PON
utilizzata non è conforme allo standard ITU-T G983.1. Gli utenti vengono collegati al
sistema per mezzo dei normali doppini telefonici utilizzando sistemi di tipo VDSL.
2.2.2 Servizi

     Il sistema iFLX è in grado di trasportare i seguenti tipi di servizio: accesso dati
veloce, video digitale diffusivo e interattivo e servizi a banda stretta (POTS/ISDN).
      I servizi di accesso dati sono trasportati in tecnica ATM con connessioni aventi
classe di servizio equivalente alla UBR. In direzione upstream c‟è una forma
elementare di controllo della banda che consiste nel fissare il cell rate massimo
consentito. In downstream non esiste alcun controllo della banda. In entrambe le
direzioni non sono presenti funzioni di policing e di traffic shaping.
      I servizi video digitali sono forniti per mezzo di un‟architettura denominata
Digital Video simile alla soluzione DVB proposta in DAVIC e possono essere sia di
tipo broadcast che di tipo interattivo (ad es. VOD). Quando un set-top box richiede un
canale, invia un messaggio di segnalazione al sistema. Il sistema iFLX dopo aver
verificato i diritti di accesso, provvede a commutare il flusso video digitale verso
l‟utente. In questo modo solo i canali che sono effettivamente utilizzati raggiungono
gli utenti realizzando così un‟ottimizzazione nell‟uso della banda. I flussi video sono
codificati in MPEG2 e trasportati in ATM.
      Il sistema è in grado di fornire servizi video e dati fino a 1000 utenti, con un
massimo di 384 canali video. È da osservare che questi due servizi condividono le
risorse del sistema, in particolare sia la banda sul collegamento PON, sia le
interfacce lato rete.
      I servizi a banda stretta sono trasportati in maniera trasparente dalla OLT fino
alla ONU per mezzo di canali E1 a 2Mbit/s. La rete di trasporto viene collegata
mediante una interfaccia STM-1 attraverso cui possono essere forniti 63 tributari E1.
Ogni interfaccia PON può poi trasportare al massimo 6 flussi E1 e ogni ONU può
estrarne fino a 4. I flussi E1 vengono portati sulla trama PON in modo proprietario
con un‟allocazione fissa della banda. In questo caso quindi la banda riservata per i
servizi narrowband non è condivisa con quelli broadband.
2.2.3 Architettura, apparati e sistema di gestione

       Il sistema si compone delle seguenti parti: la OLT, le ONU, le NT o set-top box,
il sistema di controllo locale (LEM) e il Video Administration Module (VAM).



                                                                                        75
OLT
      La OLT, chiamata iFLX shelf, viene collocata in centrale e provvede alle
funzioni di interconnessione fra rete di trasporto e reti di accesso PON. Più in
dettaglio l‟iFLX shelf provvede alle seguenti funzioni: controllo del sistema,
commutazione ATM, multiplexing dei servizi a banda stretta e a banda larga sulle
interfacce PON (e inversamente demultiplexing), distribuzione dei servizi broadcast,
connessione al terminale di controllo locale e al sistema di gestione dei servizi video
VAM.
      La OLT dispone di 16 interfacce PON lato accesso e 16 interfacce STM-1 lato
trasporto di cui 12 sono solo monodirezionali in ricezione. Le 16 interfacce di
trasporto sono condivise fra i servizi dati e quelli video e non prevedono
configurazioni in protezione. Ci sono poi 2 interfacce STM-1 in protezione 1+1 per il
collegamento della telefonia e 2 interfacce per il collegamento del LEM, una di tipo
10BaseT e una di tipo RS232. Le caratteristiche della interfaccia PON sono riassunte
nella seguente tabella:

                 Standard         no
                 Topologia        PON con fattore di splitting 1:4
                 Distanza         0-11km
                 Schema            Upstream: 51.84Mbit/s (Burst
                 trasmissivo        Mode TDMA)
                                   Downstream: 1.036Gbit/s
                                    (TDM)
                 Caratteristich   2 fibre, una per l‟upstream e una
                 e ottiche        per il downstream
                 Banda ATM        downstream:        1.62Mcelle/s
                                  (680Mbit/s)
                                  upstream:39.5Kcelle/s (16Mbit/s)
                                  condivisa fra servizi video e dati
                 Banda per        16.384 Mbit/s
                 telefonia
        Tabella 4: Caratteristiche dell‟interfaccia PON del sistema iFLX-FSP

       L‟iFLX shelf ha le seguenti funzioni di livello ATM: capacità di connessione a
livello VC punto-punto, capacità di multicasting per servizi video, supporta
connessioni PVC e SVC con segnalazione UNI3.1.
L‟equipaggiamento dell‟iFLX shelf in termini di schede è il seguente:
   1 Shelf Control Processor (SCP) che presiede alle funzioni di controllo,
    configurazione e diagnostica dell‟intero shelf. Fornisce inoltre le funzioni
    d‟interfacciamento e comunicazione con il LEM e mantiene una copia del
    database di provisioning e del software di sistema.
   Telephony Signal Processor (TSP) in configurazione ridondata. Forniscono le
    funzioni di cross-connessione dei flussi E1 tra l‟accesso e il trasporto e
    l‟interfaccia lato rete per i servizi a banda stretta.



                                                                                     76
   ATM Network Interface (ANI). Forniscono 4 interfacce UNI di cui 1 bidirezionale e
    3 unidirezionali (solo in ricezione) di tipo STM-1 singolo modo.
   16 Optical Line Units (OLU). Forniscono l‟interfaccia PON e provvedono alla
    multiplazione dei flussi broadband e narrowband.
 1 Digital Broadcast Processor (DBP). Comunica con il VAM per scambiare i dati
  di provisioning dei canali video e delle permission dei set-top box. Mantiene una
  copia locale del database relativo ai servizi video.
ONU
      La ONU, chiamata iFLX node, è l‟elemento del sistema che termina il
collegamento ottico della PON. Alla ONU sono collegati fino a 32 doppini dei singoli
utenti su cui l‟informazione viene trasmessa con il sistema VDSL in overlay al
segnale telefonico. Il segnale VDSL trasporta le informazioni di utente per i servizi
video e dati in tecnica ATM. I servizi a banda stretta sono invece accessibili
attraverso 4 interfacce E1 G703.
La ONU può essere equipaggiata con i seguenti tipi di schede:

   1 Optical Common Controller (OCC). La OCC termina l‟interfaccia PON, controlla
    la temporizzazione e distribusce il traffico ATM alle altre schede della ONU.
    Inoltre multipla/demultipla il traffico broadband e quello narrowband.
   1 Telephony Drop Interface Card (TDIC). È richiesta solo se si forniscono servizi
    a banda stretta e fornisce 4 interfacce E1 G703. Non è gestita dal‟iFLX shelf che
    non può quindi rivelarne eventuali condizioni di guasto o di allarme.
   Fino a 4 Video Transmitter/Receiver (VTR). Forniscono le interfacce VDSL e
    sono disponibili in due versioni: chip set Lucent con bit rate di linea pari a
    51.84Mbit/s down e 1.62Mbit/s up; chip-set Savan con bit rate di linea pari a
    13Mbit/s sia down che up.
La Tabella 5 riporta in dettaglio le caratteristiche dei due tipi di VDSL utilizzati.




                                                                                        77
                               VTR con chip-set           VTR con chip-set
                                   Lucent                      Savan
             N. interfacce            8                          2
             per scheda
             Bit rate in linea upstream: 1.62Mbit/s   upstream: 13Mbit/s
                               downstream:            downstream:
                                         51.84Mbit/             13Mbit/s
                               s
             Modulazione       upstream: QPSK         upstream: QAM
                               downstream: CAP16      downstream: QAM
             Allocazione       6 – 30 MHz             1.1 – 8 MHz
             spettrale         (upstream          +   (upstream       +
                               downstream)            downstream)
             Lunghezza         300m (UTP cat5)        1km (0.4mm)
             collegamento      600m (RG6 coax)
             N.     terminali 6                       1
             per drop
        Tabella 5: Caratteristiche delle interfacce VDSL nel sistema iFLX-FSP

La ONU puo‟essere fornita in due versioni, iFLX Node-16 e Node-32. Nel primo caso
il cestello puo‟ ospitare fino a quattro schede:
   1 OCC-16 (obbligatoria)
   1 TDIC
   Fino a 2 VTR
Lo slot per la scheda TDIC non e‟ compatibile con la VTR, quindi se la telefonia non
viene trasportata sulla PON, il numero di drop VDSL e‟ comunque limitato a 16.
Il cestello della ONU-32 puo‟ contenere le seguenti schede:
        1 OCC-32 (obbligatoria, diversa dalla OCC-16)
        1 TDIC (che puo‟ essere sostituita con una VTR)
        Fino a 3 ulteriori VTR
In questo caso si possono avere 24 drop VDSL più la telefonia, oppure 32 drop
VDSL senza telefonia.
NT e set-top box
     Sia le NT che i set-top box sono le terminazioni di rete che vengono installati
presso l‟utente e si collegano alla ONU per mezzo di una interfaccia di tipo VDSL.
       La NT dispone di una interfaccia d‟utente 10BaseT e consente di gestire una
sola connessione ATM per l‟accesso dati con velocità dipendente dal tipo di VDSL
utilizzato (nel caso del chip-set Savan si possono raggiungere circa 7Mbit/s nelle due
direzioni up e down). La NT è disponibile in due differenti versioni a seconda del tipo
di VDSL utilizzato.




                                                                                     78
     Il set-top box, prodotto dalla Samsung, consente di accedere ai programmi TV
broadcast e dispone anche di una porta 10BaseT per la fornitura del servizio dati. La
velocità consentita è circa 1Mbit/s in direzione upstream e 8-9Mbit/s in direzione
downstream. Il VDSL utilizzato è quello della Lucent.
     Per entrambi i dispositivi l‟interlavoro fra ethernet ed ATM è realizzato con un
semplice incapsulamento RFC1483 in modalità bridge e la connessione può solo
essere instaurata in modalità permanente.
LEM e VAM
     In passato il sistema utilizzava un terminale di controllo basato su protocollo
TL1 che consentiva di effettuare le operazioni di gestione e configurazione del
sistema. Attualmente è in fase di sviluppo un nuovo terminale chiamato LEM che è
basato su SNMP. Una sua prima versione consente la configurazione, il
provisioning del sistema e una semplice verifica sulla presenza di allarmi. Non sono
ancora implementate funzioni relative alla raccolta degli allarmi, diagnostica e
performance monitoring.
     Il VAM è l‟applicazione di gestione dei servizi video e consente il controllo di
300 iFLX shelf e di 192.000 terminali d‟utente. Esso può essere collegato ai vari
cestelli iFLX solo sfruttando connessioni ATM permanenti. Le sue funzioni principali
sono:
        provisioning dei canali video in ingresso agli iFLX shelf
        associazione fra canali video e sorgenti ATM
        abilitazione all‟accesso dei canali per ciascun CPE
        provisioning o pre-provisioning dei set-top box.
        raccolta statistiche e allarmi
      Inoltre provvede al mantenimento e al backup (automatico o manuale ) del
database (contenuto sia nel VAM stesso che nelle schede DBP di ciascun iFLX
shelf) relativo ai dati di configurazione del servizio video.
       L‟accesso a ciascun canale può essere fornito con diverse opzioni: accesso
illimitato, accesso promozionale (per es. soltanto alcune ore del giorno), pay-per-
view, accesso in una finestra temporale specifica per ciascun terminale.
2.2.4 Sviluppi previsti

    La Marconi ha previsto per il futuro di sviluppare interfacce PON a standard
G983.1 integrate nel sistema iFLX2500.

3 Evoluzioni dello standard G.983
     L‟attività di FSAN, che aveva a suo tempo prodotto il testo della
raccomandazione ITU-T G.983.1, è recentemente ripresa, con l‟obiettivo di studiare e
specificare i seguenti aspetti delle PON ATM non trattati dall‟attuale
Raccomandazione:
        1. Impiego della tecnica WDM per un migliore utilizzo del flusso dati
            downstream.



                                                                                   79
        2.    Allocazione dinamica della banda upstream.
        3.    Protezione in caso di guasto alla rete di distribuzione ottica.
        4.    Incremento del fattore di splitting (attualmente 1:32).
        5.    Incremento del bit rate upstream (attualmente 155.52 Mb/s).
      I primi tre argomenti sono allo studio attualmente, mentre i rimanenti verranno
trattati verosimilmente nel corso del 2001. Le specifiche che saranno prodotte
diverranno in seguito proposte di raccomandazione da presentare in ITU-T.
       L‟obiettivo di tali specifiche è quello di aumentare le potenzialità delle interfacce
PON a standard G.983.1 e quindi incrementarne l‟applicabilità in diversi ambiti di
utilizzo. Nel seguito vengono spiegate le problematiche e le proposte in discussione
sugli argomenti 1, 2 e 3.
3.1 WDM
      FSAN sta attualmente studiando la possibilità di aggiungere delle lunghezza
d‟onda a quelle già esistenti nelle PON ATM utilizzanti una singola fibra per i due
versi di trasmissione, allo scopo di fornire servizi addizionali, ad esempio di tipo video
o dati.
      Attualmente la G.983.1 riserva la gamma di lunghezza d‟onda 1260nm~1360nm
per l‟upstream e quella 1480nm~1580nm per il downstream.
      Il requisito degli operatori FSAN è di destinare solo una parte della gamma
downstream al normale funzionamento delle ATM-PON (Basic Band), riservando
alcune lunghezze d‟onda per la fornitura di nuovi servizi (Enhancement Band), come
indicato nella Figura 1. Per la enhancement band sono in fase di valutazione il
trasporto di canali video con differenti tipi di modulazione, oppure canali digitali
(optical leased line).
 Downstream     Basic Band                    Enhancement Band                        Future L Band
        202.3THz
                                  Guardband                       Guardband
               ATM-PON                                                             Reserved for
                                                                                   allocation by ITU-T



     ~1480                                                                                          
     1                        2                3              4                5                          6

Figura 1: Suddivisione della gamma di lunghezze d‟onda nella direzione downstream
      Nella seguente tabella è riportata la prima bozza di proposta per l‟allocazione
delle bande.




                                                                                                          80
                             Basic Band        Enhancement Band   Future L band       Memo
                             (nm)              (nm)               (nm)
 Tx   For Digital use       1480-1500 nm         1540-1565 nm
                                                                  Further study
      For Video use         1480-1500 nm        1550-1560 nm


 Rx    Filter characteristics is as follows:                                      (*) Depends on
                                                                                  transmission format
                                Isolation >=20dB at 1540 nm                       and number of
                                Isolation >=30dB(*) at 1550nm                     channels




    I limiti della banda L, oggetto di futura standardizzazione da parte di ITU-T, non
sono ancora rigidamente fissati, per cui la soluzione proposta non causa conflitti di
competenza. All‟interno della „Enhancement Band‟ si conta di utilizzare la tecnica
DWDM, con una spaziatura di 200GHz tra le lunghezze d‟onda (G.959.1).
      Lo svantaggio della soluzione proposta è l‟impossibilità di utilizzare le attuali
sorgenti a 1510 nm, forse le più diffuse attualmente sul mercato, per la „Basic Band‟.
Il costo dei laser a 1490 nm, benché più alto rispetto a 1510 nm, è ripartito tra 32 (o
64 in futuro) utenti, mentre il costo dei filtri ottici incide sulla singola ONU. Il vero
problema è che lo sviluppo delle nuove sorgenti a costi sostenibili è strettamente
legato alle quantità prodotte, cioè al numero di sistemi WDM-PON installati.
       La prima proposta di raccomandazione G.983.WDM è stata presentata all‟ITU-T
all‟inizio di Novembre e dovrebbe essere finalizzata per la prossima riunione.
3.2 Allocazione dinamica della banda
     Nei sistemi odierni, i „grant‟ che consentono alle ONU di occupare uno slot nella
trama upstream vengono assegnati in modo fisso e periodico alle varie ONU, in
funzione della banda assegnata. In questo modo tutta la banda assegnata ad una
ONU è riservata in modo esclusivo per essa, anche se non utilizzata. I meccanismi di
allocazione dinamica (DBA) consentono invece di riallocare la banda non utilizzata
da una ONU, o da un suo sottoinsieme, ad altre ONU in maniera flessibile e
dinamica.
       Una prima classificazione dei meccanismi di DBA consente di individuare due
schemi. Un primo schema consiste nell‟implementare un processo in grado di
monitorare lo stato delle code di trasmissione all‟interfaccia PON delle ONU. Il
monitoraggio è effettuato dall‟OLT che mediante un opportuno meccanismo riceve da
tutte le ONU lo stato delle loro code (ad esempio il livello di riempiento). In questo
modo l‟informazione relativa alla banda necessaria in ciascuna ONU è concentrato a
livello di OLT dove avviene l‟assegnazione degli slot della trama upstream.
       Un secondo schema consiste invece nel monitorare a livello di OLT il livello di
utilizzo della banda allocata a ciascuna ONU. La OLT alloca ciclicamente una banda
minima prefissata a ciascuna ONU secondo lo schema attualmente utilizzato.
L‟allocazione avviene sulla base di un certo numero di slot per periodo di allocazione
T. Quando una ONU non ha traffico sufficiente a riempire gli slot allocati, invia delle
celle idle (le celle idle sono definite nella raccomandazione [2]) che poi vengono



                                                                                                        81
scartate dalla OLT. L‟OLT può contare il numero di celle idle ricevute per ciascun
periodo T e determinare così il rapporto fra banda allocata e banda utilizzata.
Quando tale rapporto supera una soglia prefissata, la banda allocata viene
aumentata così da evitare o ridurre lo stato di congestione che potrebbe prodursi
nella ONU.
       Mentre il primo tipo di schema comporta la stesura di una nuova specifica per
l‟interfaccia fra ONU e OLT, il secondo schema è applicabile anche ai sistemi
esistenti senza comportare modifiche alle ONU e all‟interfaccia PON in quanto il
meccanismo è implementato interamente nella OLT. Nonostante il secondo schema
sia un‟opzione interessante per migliorare sistemi già in campo, esso presenta
notevoli svantaggi in termini di efficienza rispetto al primo. Per questo motivo lo
sforzo di FSAN è orientato alla stesura di una specifica per il primo tipo di
meccanismo, pur non escludendo la possibilità di utilizzare anche il secondo ove sia
conveniente.
      Come primo risultato FSAN ha redatto un elenco di requisiti sulle caratteristiche
richieste al nuovo sistema di allocazione di banda. Come base di partenza sono stati
definiti i seguenti termini:
        Transmission Container: normalmente viene indicato con l‟acronimo
         TCONT ed è definito come un „tubo virtuale‟ che consente la trasmissione
         trasparente di traffico ATM appartenente a diverse connessioni e/o classi
         di servizio. Ad ogni ONU capace di reagire ai meccanismi di DBA possono
         corrispondere 1 o più TCONT.
        Banda fissa: è quella banda interamente riservata e allocata ciclicamente
         allo scopo di ottenere una bassa variazione nel ritardo delle celle (CDV).
         Nel caso in cui un flusso di traffico sia configurato a banda fissa e non
         abbia celle da inviare, la banda viene occupata mediante l‟invio di celle
         idle.
        Banda garantita: questa è la banda che viene garantita nel caso in cui la
         coda corrispondente al TCONT abbia delle celle da inviare, tali da
         occupare una certa banda massima specificata.
        Banda addizionale: può essere chiamata anche banda non garantita ed è
         assegnata solo quando c‟è un surplus di banda non utilizzata da altri
         TCONT.
     Combinando in maniera diversa queste tipologie di assegnazione della banda
sono stati al momento definiti cinque tipi di TCONT:
        TCONT1: Banda fissa, allocata ciclicamente.
        Il TCONT1 è adatto al trasporto di flussi di traffico appartenenti a qualunque
        classe di servizio ATM. È tuttavia particolarmente indicato per la classe CBR
        e quindi per fornire servizi di tipo Circuit Emulation, ad esempio per il
        trasporto di flussi E1, oppure per la classe rt-VBR normalmente utilizzata per
        il trasporto di flussi video diffusivi.
        TCONT2: Banda garantita.
        Il TCONT2 è indicato per le classi di servizio nrt-VBR o per qualunque
        servizio avente solamente requisiti di garanzia sulla banda e non sul ritardo



                                                                                        82
        (ad esempio la classe di servizio ABT definita dalla raccomandazione ITU-T
        I.356).
        TCONT3: Banda garantita e banda addizionale.
        Il TCONT3 è impiegabile efficacemente per classi di tipo nrt-VBR, GFR, ABR,
        UBR+.
        TCONT4: Solo banda addizionale.
        Questo Transmission Container è indicato solamente per il trasporto di
        traffico di tipo UBR

        TCONT5: Banda fissa, garantita e addizionale.
        Il TCONT5 è indicato sia per traffico con requisiti real-time, sia per traffico
        con requisiti non real-time aventi la necessità di avvalersi di banda
        addizionale. Questo TCONT in particolare può essere utilizzato in quelle
        ONU in cui, per ragioni di costo, si desideri utilizzare un solo TCONT per tutti
        i tipo di traffico, rimandando la prioritizzazione dei diversi flussi ad uno
        scheduler integrato nella ONU stessa.
     Al momento ci sono diverse proposte relative all‟implementazione del DBA da
parte di diversi costruttori (Fujitsu, Hitachi, Lucent, Mitsubishi, NEC, Quantum Bridge
e Terawave). I meccanismi proposti, pur essendo diversi tra loro, si basano tutti su
alcuni dei seguenti elementi:
        Divided slot: la G.983.1 definisce degli slot particolari per la trama
         upstream in cui più ONU posso trasmettere. I 56 byte dello slot vengono in
         questo caso suddivisi in minislot ciascuno dei quali utilizzato da una ONU.
         La G.983.1 già prevede la possibilità di allocare i minislot senza
         specificarne l‟utilizzo. In Figura 2 è illustrato il formato di un divided slot
         come rappresentato dalla G.983.1.
        Mini slot: i mini slot definiti dalla G.983.1 non hanno una lunghezza
         prefissata. Tuttavia i primi due byte sono definiti come preambolo e
         consentono alla OLT di riconoscere i minislot di diverse ONU all‟interno
         del divided slot (si veda la Figura 2). L‟informazione trasmessa nel
         payload del minislot si riferisce alla lunghezza delle code e può essere
         espressa in modo esplicito, mediante l‟indicazione della lunghezza della
         coda in celle ATM, o in modo indiretto mediante dei bit che segnalano il
         riempimento oltre determinate soglie prefissate.
        Grant: i grant sono i permessi che la OLT concede alle ONU di trasmettere
         in un certo slot della trama upstream. Il meccanismo di identificazione dei
         grant è definito nella G.983.1 e consente di assegnare differenti tipi di
         grant alla medesima ONU. Questo consente alla OLT di avere il controllo
         sulle diverse code (corrispondenti ai TCONT) nella ONU, specificando
         quale di esse ha il permesso di inserire una cella in upstream. La G.983.1
         attualmente dà la possibilità di avere 256 tipi di grant differenti per
         interfaccia PON. Questo valore è da alcuni ritenuto insufficiente nel caso
         in cui ci siano molte code per ONU e il numero delle ONU per PON venga
         incrementato a più di 32.




                                                                                      83
        Piggyback: un alternativa all‟uso dei divided slot e mini slot è quello di
         sfruttare il campo VPI delle celle ATM per inserire l‟informazione sullo
         stato delle code. Questo metodo tuttavia implica l‟associazione implicita di
         ciascuna ONU ad un unico valore di VPI e quindi limita il numero di
         connessioni per ONU a circa 65000, massimo numero di VCI indirizzabili
         in una cella ATM.
        PLOAM: anche le celle di PLOAM possono essere utilizzate, in alternativa
         o in combinazione con altri metodi, per trasferire le informazioni
         necessarie tra ONU e OLT. Il loro svantaggio consiste nella lentezza del
         meccanismo che, se utilizzato da solo, porterebbe a tempi di risposta del
         DBA eccessivamente lunghi.
        Celle idle: come spiegato in precedenza la OLT può decidere come
         allocare la banda avvalendosi del fatto che le celle idle vengono
         trasmesse quando le code sono vuote.

                                          Upstream frame


                                                          upstream slot
                     1             2                             k                 53


                                                     Divided slot
                     ONU x                 ONU y               ONU z

                                          minislot
                                                 minislot payload, 1 to 53 bytes
                         3 upstream
                         overhead bytes



                             Figura 2: Formato del divided slot
     Attualmente sono in fase di studio i benefici ottenibili e i costi associati alle
diverse proposte. In particolare si sta tentando di raggiungere un compromesso
riguardo ai seguenti parametri:
        Complessità di implementazione. Dipende per esempio dal numero di
         meccanismi utilizzati per riportare la lunghezza delle code, dal numero di
         code per ciascuna ONU, dalla quantità di informazioni che la OLT deve
         processare per stabilire l‟allocazione della banda, ecc.
        Efficienza nell’utilizzo della banda upstream. L‟efficienza dipende dalla
         capacità del meccanismo DBA di allocare la banda effettivamente
         necessaria a ciascuna ONU.
        Rapporto fra banda upstream e banda utilizzata dal meccanismo DBA. Le
         diverse soluzioni comportano uno „spreco‟ di banda dovuta al fatto che è
         necessario trasferire dell‟informazione fra ONU e OLT che non appartiene
         al traffico utente.
        Tempi di risposta del DBA, ovvero il ritardo tra richiesta di banda da parte
         delle ONU e l‟effettiva allocazione della stessa.




                                                                                        84
        Variazione di ritardo (CDV) introdotta sulle celle ATM. La CDV introdotta
         sul traffico dipende da come vengono allocati i grant. Quanto più essi
         vengono assegnati in modo equispaziato, tanto più bassa sarà la CDV.
      Le simulazioni dei differenti meccanismi proposti, che sono attualmente in corso
di studio, avranno come obiettivo quello di dimostrarne la validità nei confronti dei
parametri citati
3.3 Robustezza del sistema nei confronti di guasti della rete ottica
    Nell‟Appendice D della Raccomandazione G.983.1 sono già definiti due tipi di
commutazione, automatica e forzata come nei sistemi SDH, e quattro configurazioni:
        Tipo A: Protezione della sola fibra dalla OLT fino al primo splitter.
        Tipo B: Doppia fibra e doppia interfaccia PON della OLT fino al primo splitter.
        Tipo C: Doppia ODN e doppia interfaccia PON sia nella ONU che nella OLT.
        Tipo D: Come Tipo C, con doppia protezione dello splitter.
      La G.983.1 sancisce che il meccanismo di protezione è opzionale, e non
definisce nessun protocollo di commutazione, consigliando di utilizzare le celle
PLOAM per l‟implementazione.
     È da notare che in nessun caso è prevista la protezione completa della OLT,
terminando la ODN per esempio in un‟altra centrale.
     Per quanto riguarda le protezioni di Tipo A e Tipo B i meccanismi proposti sono
abbastanza simili, e non implicano lo sviluppo di nuovi protocolli tra OLT e ONU. La
funzione di commutazione è implementata solo nella OLT, il che aumenta
leggermente il tempo di rilevamento del guasto.
     La protezione di Tipo C è senz‟altro la più costosa, perché richiede la
duplicazione dell‟interfaccia PON di tutte le ONU. Dal punto di vista realizzativo, la
proposta predominante è quella di utilizzare il LOS (Loss Of Signal) per la rilevazione
del guasto, e di ridefinire il messaggio PST (PON Section Trace) nella G.983.1 per il
trasporto dei byte K1/K2, già usati per la commutazione nei sistemi SDH
(Raccomandazione ITU-T G.783). La definizione del protocollo di commutazione è
ancora attualmente in discussione in FSAN.
      Un altro elemento in discussione per la protezione di Tipo C è la possibilità di
tenere la ODN di protezione in standby (1:1), o di utilizzarla per extra-traffico (1+1). In
altre parole l‟utente protetto ha una possibilità di allocazione di banda fino a due volte
quella di un utente non protetto in condizioni normali, che si dimezza in caso di
guasto su un ramo della ODN.
     Infine per quanto riguarda i tempi di commutazione attualmente sono stati
specificati due requisiti, uno opzionale più stringente di 50ms e uno più lasco pari a
500ms.




                                                                                        85
4 Integrazione dei servizi video multicast nei sistemi PON
      Pur concepita nella sua formulazione originale come un‟architettura orientata
essenzialmente ai servizi ATM, la piattaforma FSAN può diventare la base per il
supporto di un vasto portafoglio di servizi. Questa flessibilità risulta particolramente
interessante nello scenario odierno, in cui il servizio principale, e nella maggior parte
delle implementazioni anche l‟unico, che gli utenti finali richiedono (in aggiunta ai
servizi di intranet aziendale) è la connessione ad Internet veloce.
      Nella Figura 3 sono riportati [1] i principali elementi di rete di una possibile
architettura per il broadcating video su un‟infrastruttura PON basata sul solo ATM: la
NT termina la tratta trasmissiva su rame in tecnologia VDSL e trasforma i dati dal
formato della rete di accesso al formato per il trasporto all‟interno della casa.
Attualmente due tipi di interfaccia sono utilizzati per la NT: la prima è orientata ad un
servizio ATM trasparente con bit rate di 25.6 Mbit/s, la secondo è un‟interfaccia
Ethernet 10/100BaseT. Questo paragrafo illustra il modo in cui l‟architetture proposta
supporta i suddetti scenari.

                       Service             Head End                    Cabinet/          Home
                       Node                Node                        Kerb


                                                                                  VDSL
                       ATM                 OLT                         ONU               NT


                       VSU


                      NTE - Network Termination Equipment
                      OLT - Optical Line Termination
                      ONU - Optical Network Unit
                      VDSL - Very high-speed Digital Subscriber Line
                      VSU - Video Streaming Unit


                              Figura 3: Elementi di rete
4.1 Scenario ATM End-to-End
Lo scenario ATM per il servizio di video broadcast è descritto nel documento [7]. In
esso vi sono descritte due opzioni per la fornitura di connettività ATM End-to-End:
1. connessione e terminazione diretta dell‟xDSL e ATM in un Set Top Box.
2. Utilizzo della NT per terminare la linea xDSL e per le funzionalità di OAM
   dell‟ATM; connessione del STB attraverso una interfaccia ATMF25.

La divisione di funzioni tra la NT e il STB descritta nello scenario 2 permette di
separare la interoperabilità del livello fisico dalla architettura del protocollo SDVB.
Dato che l‟xDSL, e in particolare il VDSL, sono tecnologie di trasmissione nuove, i
test di interoperabilità sono necessari tra i vari costruttori, al fine di garantire un CPE
universale. Quindi, terminare l‟xDSL nella NT potrebbe accelerare la fornitura di STB
universali.




                                                                                                86
                          ATM              ATM                e.g. 3 channel
                    STM1 Multicast        Multicast              decoding            Video/
                                                                                     Audio
         ATM                                            VDSL
                            OLT            ONU                    STB
                                                                                     PC
         VSU                       DSLAM
                                                                    10/100BT
                    STM4

Figura 4: Architettura video End-to-End per distribuzione video digitale con NT
integrata nel STB

                                                                       e.g. 3 channel
                                                                         decoding
                        ATM              ATM                                      Video/
                  STM1 Multicast        Multicast                 ATM25           Audio
         ATM                                                                   STB
                                                      VDSL
                           OLT          ONU                   NTE
                                                                               PC
         VSU                                                    10/100BT
                  STM4         DSLAM

Figura 5: Architettura video End-to-End per distribuzione video digitale con NTe STB
                                      separati

4.1.1 Lo “User Plane”
La Video Streaming Unit (VSU) genera un certo numero di video stream MPEG, ad
es. 100 da 6 Mb/s ognuno, e trasmette i dati ad una interfaccia ATM STM/OC-12.
Per semplificare la connessione, tutti i VC che trasportano video stream possono far
parte dello stesso VP. I VC sono configurati come PVC unidirezionali. I dati codificati
in MPEG dei video sono trasportati direttamente su AAL5/ATM.
Il sistema complessivo OLT/ONU può essere considerato come un‟unica entità
equivalente ad un DSLAM. Finché il DSLAM non ha ricevuto almeno una richiesta di
zapping da almeno una CPE, scarta le celle di tutte le connessioni video.


            STB                  NT                 DSLAM                       VSU

            MPEG                                                                MPEG
             AAL5                              VC Multicast                     AAL5
             ATM               ATM            ATM      ATM                       ATM
            ATM25          ATM25 VDSL         VDSL     SDH                       SDH



               Figura 6: Pila di protocolli tra STB e unità di video stream
4.1.2 Il “Control Plane”
Il protocollo usato per lo zapping è un sottoinsieme di quello definito in DAVIC 1.1
(DSM-CC-CCP). Si utilizza solo la parte relativa allo zapping iniziato dall‟utente, e
consiste di due messaggi:
1. Program Select Request (dal STB o NT al DSLAM)



                                                                                              87
2. Program Select Confirm (dal DSLAM al STB)


                     STB                NT                           DSLAM



                                              DSM-CC CCP
                                              ProgramSelectRequest
                                              - IP multicast group      DSLAM performs
                                                                        Multicast Setup

                                             DSM-CC CCP
                                             ProgramSelectConfirm
                                             - VPI/VCI




                  Figura 7: Flusso messaggi tra STB e NT/DSLAM

Il STB richiede il passaggio ad un nuovo canale televisivo. Il DSLAM stabilisce la
connessione multicast dall‟interfaccia della VSU a quella che ha richiesto lo zapping.
In particolare le richieste di zapping passano trasparentemente attraverso la ONU e
sono elaborate dalla OLT. Questa, mediante un opportuno meccanismo di
comunicazione, configura le varie ONU per la corretta distribuzione del segnale.
4.2 Scenario IP End-to-End
      Utilizzando l‟interfaccia ATMF25 tra NT e STB, l‟architettura sopra descritta
offre una soluzione conforme agli standard esistenti. Tuttavia, l‟interfaccia ATMF25
oggi non è largamente utilizzata.
      Questo può portare a costi più elevati e ad una barriera per l‟implementazione
dal lato CPE. Inoltre, usando l‟interfaccia ATMF25 si arriva ad una separazione della
rete domestica tra ATM (audio/video) ed Ethernet (accesso ad Internet) come
mostrato in Figura 5.
      Quindi può risultare vantaggioso distribuire tutti i contenuti via Ethernet/IP
nell‟ambiente di rete domestica. A causa dell‟elevata banda e della QoS richiesta
dalle applicazioni video è necessario utilizzare la 100BaseT. Siccome la Ethernet ha
una elevata penetrazione di mercato questo può portare a minori difficoltà per
l‟implementazione di un STB.




                                                                                          88
                                                                       e.g. 3 channel
                                                                          decoding
                       ATM             ATM                                        Video/
                 STM1 Multicast       Multicast                                   Audio
         ATM                                                                STB
                                                  VDSL
                        OLT            ONU                  NTE
                                                                            PC
         VSU
                 STM4        DSLAM                                100BT

Figura 8: Architettura per distribuzione video digitale che utilizza Ethernet/IF lato CPE



I paragrafi seguenti si basano sulle assunzioni qui riportate:
   L‟unità di video streaming VSU genera un certo numero di PVC ATM, ognuno dei
    quali contiene solo un video stream MPEG con UDP e IP come livelli di rete.
   Sia il STB che il PC (o gli altri terminali dati) sono connessi all‟NT tramite un hub
    con una singola interfaccia 100BaseT.
   Il protocollo di livello 2 per l‟accesso ad Internet del CPE è esclusivamente
    PPPoE.
   Il protocollo di zapping per il/i STB è IGMP.
  La unità di video streaming non richiede scambio di informazioni con il CPE o la
   OLT sui canali video.
4.2.1 Lo “User Plane”

      Il VSU genera un certo numero di video stream MPEG, ad es. 100 stream di 6
Mb/s l‟uno, e trasmette i dati alla interfaccia ATM STM-4/OC-12. Per semplificare la
gestione della connessione, tutti i VC che trasportano video stream possono far parte
di un singolo VP. I VC sono configurati come PVC unidirezionali. I dati del video
codificato in MPEG sono trasportati in UDP/IP su AAL5/ATM. Fino a che il DSLAM
non ha ricevuto una richiesta di zapping da una qualsiasi CPE, scarta tutte le celle di
tutte le connessioni video.
      I dati video sono inviati dalla NT al STB in IP multicast. Questo semplifica il
trasporto dei dati video a più utenti. L‟IP multicast utilizza la classe D degli indirizzi
IP, rappresentata nella                                 Figura 9.


       Class D      1   1   1     0                   multicast group ID
                            Figura 9: Formato di indirizzo IP di classe D

      Un indirizzo IP di gruppo multicast viene convertito in indirizzo Ethernet
mappando i 23 bit di ordine inferiore, che identificano il gruppo multicast, in un blocco
di indirizzi multicast Ethernet (si veda la Figura 10).




                                                                                           89
                                                            These 5 bits in the multicast group ID are
                                                            not used to form the Ethernet address



                                     0               7 8                 15 16                  23 24           31

                                     1 1 1 0

                                                                 32-bit Class D IP address
                                                                            low-order 23 bits of multicast
                                                                         group ID copied to Ethernet address


     0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 1 0 1 1 1 1 0 0

                                               48-bit Ethernet address




  Figura 10: Mappaggio di una classe D di indirizzi IP multicast in indirizzi Ethernet
                                    multicast


      E‟ lasciata al cliente (cioè al STB) la responsabilità di filtrare i frame Ethernet
che non gli appartengono.
La pila di protocolli utilizzati è mostrata in Figura 11.

               STB                    NT                      DSLAM                                      VSU

               MPEG                                                                                      MPEG
                UDP            IP Multicast                                                               UDP
                 IP            IP        IP                 VC Multicast                                   IP
              Ethernet      Ethernet ATM                   ATM      ATM                                   ATM



              Figura 11: Pila di protocolli tra STB e unità di video streaming

4.2.2 Il “Control Plane”

     Dopo l‟accensione di un STB, esso richiede un indirizzo IP alla NT generando
un messaggio di richiesta “bootp-Request”. Il messaggio di risposta “bootp-Reply”
viene generato dalla NT.




                                                                                                                     90
                     STB                                    NT                                DSLAM
                                bootpRequest



                                bootpReply
                                - IP address STB



                                IGMP Report
                                - IP multicast group                   DSM-CC CCP
                                                                       ProgramSelectRequest
                                                                       - IP multicast group        DSLAM performs
                                                                                                   Multicast Setup

                                                                      DSM-CC CCP
                                                                      ProgramSelectConfirm
                                                                      - VPI/VCI




                       Join/
                      Leave                            Interworking
                      Group                             DSM-CC                                DSM-CC
                                                   IGMP
                      IGMP                               CCP                                   CCP
                        IP                         IP    AAL5                                  AAL5
                     Ethernet                   Ethernet ATM                                   ATM



                 Figura 12: Flusso di messaggi tra STB e NT/DSLAM

      La selezione di un canale video viene effettuata mandando un messaggio IGMP
di tipo “Host Membership Report” attraverso la modalità broadcast della Ethernet.
Tale messaggio contiene un indirizzo IP multicast che specifica il canale video. La
relazione tra l‟indirizzo IP multicast usato da STB/VSU e il relativo VPI/VCI è
conosciuta dal DSLAM e da tutti gli elementi interessati (STB, VSU e NT) in virtù di
uno scambio di informazioni ed un accordo comuni. Grazie a questi meccanismi, la
NT sa che una entità nella Ethernet locale ha fatto richiesta di unirsi ad uno specifico
gruppo multicast, cioè ha richiesto uno specifico canale video. La NT manda un
messaggio DSM-CC “ProgramSelectRequest” al DSLAM, che realizza la
connessione multicast corretta attraverso la rete.
     La NT periodicamente controlla se vi sono host che appartengono ancora ad un
certo gruppo multicast oppure no. Usando un sistema di query e di report, la NT
mantiene aggiornata una tabella dei gruppi multicast in cui vi sono utenti provenienti
da un qualunque CPE collegato alla sua interfaccia Ethernet.
      La NT supporta tanti gruppi IP multicast quanti sono i VC video configurati
dall‟operatore.

5 Conclusioni
      Nel presente documento sono state descritte due piattaforme d‟accesso in
tecnologia PON attualmente disponibili in commercio. Tali soluzioni sono
rappresentative di come sta evolvendo l‟offerta commerciale di tali prodotti e in
particolare consentono di fare le seguenti affermazioni:
        I sistemi PON commerciali stanno evolvendo verso lo standard G.983;



                                                                                                                     91
        Nei sistemi orientati all‟architettura FTTH sono attualmente presenti
         maggiori funzioni di livello ATM con distinzione di classi di servizio e
         possibilità di monitoraggio dei flussi di traffico a vari livelli (ad esempio
         mediante le funzioni descritte nello standard I.610). Ciò è probabilmente
         dovuto al fatto che questi sistemi sono per ora orientati all‟offerta di servizi
         ad utenza affari, con esigenze di qualità e garanzie del servizio più elevate
         di un‟utenza residenziale.
        I sistemi orientati all‟architettura FTTCab puntano all‟utilizzo della
          tecnologia VDSL per il collegamento finale all‟utente.
        La distribuzione video su sistemi FTTCab non solo è realizzabile ma
         sembra essere un‟alternativa in grado di competere con i tradizionali
         sistemi di distribuzione video su cavo.
        I sistemi esaminati prevedono un meccanismo per il trasporto di servizi di
          telefonia tradizionale. Questo evidenzia che i sistemi PON si propongono
          sempre più come piattaforma unica per tutti i servizi.
      A tali considerazioni è da aggiungere che sempre un maggior numero di
costruttori dichiara l‟intenzione di voler adottare la tecnologia PON per realizzare
interfacce sui propri apparati di accesso. Le capacità dei sistemi attualmente
disponibili e in particolare dell‟interfaccia G.983 sono tuttavia considerate insufficienti
per un loro impiego in un‟eterogeneità di situazioni (ad esempio in casi in cui con la
stessa piattaforma s‟intenda fornire servizi di tipo residenziale e di tipo affari). In
particolare la banda upstream è insufficiente, specialmente se si considera servizi
quali: interconnessione di LAN, video-conferenza, tele-lavoro, comunità virtuali, ecc.
A tale limitazione è da aggiungere la mancanza di uno standard per quanto riguarda
aspetti di gestione della qualità del servizio, allocazione dinamica delle risorse di
banda, gestione del traffico multicast. Di alcuni di questi temi, che sono attualmente
in discussione in FSAN, è stata presentata una panoramica, evidenziando le
problematiche e accennando alle soluzioni attualmente proposte. In particolare per il
tema relativo alla gestione del traffico multicast è stata presentata un ipotesi di
soluzione che consente di integrare le funzioni delle PON con quelle ATM ed IP in
modo da distribuire in maniera efficace servizi di tipo video diffusivo.

6 Bibliografia

[1]   P. Bradley, M. Calzavara, “Trasporto dell‟ATM sulle PON in modalità
      TDM/TDMA”, Documento CSELT DPC 1999.04034.
[2]   ITU-T Raccomandazione I.361, “B-ISDN ATM layer specification”, Febbraio
      1999.
[3]   ITU-T Raccomandazione I.356, “B-ISDN ATM layer cell transfer performance”,
      Marzo 2000.
[4]   ITU-T Raccomandazione G.983.1, “High Speed optical access systems based
      on Passive Optical Network (PON) techniques”, Ottobre 1998.
[5]   ITU-T Raccomandazione G.983.2, “The ONT Management and Control
      Interface Specification for ATM-PON”, Aprile 2000.




                                                                                        92
[6]   ATM Forum Specifica AF-TM-0121.000, “Traffic Management Specification
      Version 4.1”, Marzo 1999.
[7]   FSAN gruppo SCP, “Full Services Access Network Requirements
      Specification”, Agosto 1998




                                                                         93
7 Elenco degli acronimi e delle sigle


AAL5         ATM Adaptation Layer 5
ADSL         Asymmetric Digital Subscriber Line
ANI          ATM Network Interface
ATM          Asyncronous Transfer Mode
CBR          Constant Bit Rate
CDV          Cell Delay Variation
CPE          Customer Premise Equipment
CTS          Common Technical Specification
DAVIC        Digital Audio-Visual Council
DBA          Dynamic Bandwidth Assignment
DBP          Digital Broadcast Processor
DSLAM        Digital Subscriber Line Access Multiplexer
DSM-CC       Digital Storage Media Command and Control
DSM-CC-      Digital Storage Media Command and Control - Channel Change
CCP          Protocol
DSU          Digital Subsciber Unit
DVB          Digital Video Broadcasting
DWDM         Dense Wavelength Division Multiplexing
EPD          Early Packet Discard
ETSI         European Telecommunications Standards Institute
FSAN         Full Service Access Network
FTTCab       Fiber To The Cabinet
FTTH         Fiber To The Home
GFR          Guaranteed Frame Rate
IGMP         Internet Group Multicast Protocol
IP           Internet Protocol
L2TP         Level 2 Tunneling Protocol
LEM          Local Element Manager
MCR          Minimum Cell Rate
MPEG         Motion Picture Expert Group
NNI          Network-Network Interface
NT           Network Termination
NTE          Network Termination Equipment
OAM          Operation Administration and Maintenance
OCC          Optical Common Controller
OLT          Optical Line Termination
OLU          Optical Line Unit
OMCC         Optical Management Control Channel
ONT          Optical Network Termination
ONU          Optical Network Unit
PCR          Peak Cell Rate
PLOAM        Physical Layer OAM
PON          Passive Optical Network
PPD          Partial Packet Discard




                                                                          94
PPPoE   PPP over Ethernet
PPPTP   PPP Tunneling Protocol
PVC     Permanent Virtual Channel
SCP     Shelf Control Processor
SDVB    Switched Digital Video Broadcast
STB     Set-Top Box
SVC     Switched Virtual Channel
TCONT   Transmission Container
TDIC    Telefony Drop Interface Card
TRA     Terminazione di Rete d‟Accesso
TSP     Telephony Signal Processor
UBR     Unspecified Bit Rate
UDP     User Datagram Protocol
UNI     User-Network Interface
UPC     User Parameter Control
VAM     Video Administration Module
VBR     Variable Bit Rate
VC      Virtual Circuit
VDSL    Very high bit-rate Digital Subscriber Line
VOD     Video On Demand
VP      Virtual Path
VSU     Video Streaming Unit
VTR     Video Transmitter/Receiver
WDM     Wavelength Division Multiplexing




                                                     95
                                       CSELT
                                Deliverable contrattuale



            Sperimentazione in laboratorio della manutenzione ottica




Data di redazione:       27 ottobre 2000
Riservatezza:            CONFIDENZIALE
Numero di pagine:        121
AUTORI:                  Angelantonio GNAZZO (IN/D/I)
                         Pier Giorgio RICALDONE (IN/D/P)
REVISIONE:               Giuseppe GALLIANO (IN/D/P)
APPROVAZIONE:            Alberto BROSIO (IN/D/I)



Executive summary
ll presente rapporto costituisce la relazione finale sull'attività svolta sul tema della
manutenzione ottica del secondo anno del progetto di ricerca triennale MURST dal
titolo " Servizi multimediali interattivi su rete ottica passiva", inserita nel Progetto P13
“Evoluzione della rete di accesso”, Task 1 “Sistemi e tecnologie per l‟accesso FTTx”.
L‟obiettivo del progetto è la dimostrazione della funzionalità alla teledidattica di una
rete ottica di accesso all'utente di tipo PON (Passive Optical Network) da realizzare
nella rete cablata con fibra ottica sull'Area delle Scienze dell'Università degli Studi di
Parma.
In questo documento vengono riportati i risultati sperimentali di prove di
manutenzione ottica nello scenario di impiego della PON per la teledidattica (2 rami
come richiesto dall‟università) e con 4 rami per una futura evoluzione.




                                                                                          96
Indice del documento

1   Introduzione
2   Generalità sulle PON
3   Descrizione generale della PON per il campus dell’Università di Parma
    3.1 Impiego della PON per teledidattica
    3.2 Predisposizione della PON per la diagnostica ottica
4   Attività sperimentale
    4.1 PON 1x2
    4.2 Analisi delle tracce OTDR
    4.3 PON 1x4
5   Conclusioni
6   Bibliografia
7   Elenco di sigle, acronimi e simboli




                                                                            97
1 Introduzione
      L‟obiettivo del progetto di ricerca triennale finanziato dal MURST “Servizi
multimediali interattivi su rete ottica passiva” è la dimostrazione della funzionalità alla
teledidattica di una rete ottica di accesso all'utente di tipo PON (Passive Optical
Network) da realizzare nella rete cablata con fibra ottica sull'Area delle Scienze
dell'Università degli Studi di Parma.
      L‟esperimento di teledidattica previsto nel Progetto fa uso di un video server,
situato presso il CED (Centro Elaborazione Dati) e di un certo numero di terminali
video, distribuiti nel CED stesso e presso la Facoltà di Ingegneria. Il video server e i
terminali saranno collegati tra loro per mezzo di una PON (Passive Optical Network)
a due fibre, una per la trasmissione verso i terminali e l‟altra per la trasmissione
verso il video server.
      Nel primo anno di attività CSELT è stato impegnato nella definizione e
progettazione del dimostratore e nella progettazione del sistema per la manutenzione
ottica [1,2]. Nel secondo anno sono stati acquisiti e caratterizzati i componenti
necessari alla sperimentazione in laboratorio: il presente rapporto considera i risultati
sperimentali di laboratorio nell‟impiego della PON per la teledidattica, cioè con
rapporti di diramazione 1x2, e con quattro rami per una eventuale futura evoluzione
dell‟architettura di rete.

2 Generalità sulle PON
      Una PON (Figura 2.1) interagisce con i livelli superiori della rete per mezzo di
una OLT (Optical Line Termination). La OLT è collegata alle varie ONU (Optical
Network Unit) per mezzo di una rete ad albero completamente ottica ODN (Optical
Distribution Network). La PON non contiene elementi attivi come amplificatori o
commutatori e il segnale ottico è distribuito dalla OLT alle ONU con un diramatore
ottico (splitter) che funziona come divisore di potenza. Il fatto di non contenere
elementi attivi nella rete elimina completamente i problemi di alimentazione
(powering) nella ODN e migliora l‟affidabilità del sistema. La ODN può essere in
generale a una fibra (trasmissione bidirezionale) o a due fibre (una fibra per ogni
direzione).




                                                                                         98
                          Figura 2.1 – Schema di una PON.
      La trasmissione downstream (dalla OLT alle ONU) avviene mediante
multiplazione a divisione di tempo (TDM – Time Division Multiplexing). La
trasmissione upstream (dalle ONU alla OLT) avviene mediante accesso multiplo a
divisione di tempo (TDMA – Time Division Multiple Access). Questo permette di
gestire i flussi di dati trasmessi dalle varie ONU alla OLT, e consente la allocazione
dinamica degli spazi temporali assegnati ad ogni utente.
      A seconda dell‟estensione della fibra verso il terminale dell‟utente si possono
individuare diverse configurazioni definite dalla posizione relativa tra ONU e
terminale. Nel caso della configurazione FTTH (Fibre To The Home) la fibra
raggiunge l‟utente. Nel caso FTTB/C (Fibre To The Building/Curb) il segmento finale
(drop) dalla ONU fino alla terminazione di rete NT dell‟utente è realizzato mediante
una linea d‟utente digitale DSL (Digital Subscriber Line) su doppino di rame. Esiste
infine la configurazione FTTCab (Fibre To The Cabinet) in cui la ONU è alloggiata in
un armadio della rete di telecomunicazioni. Le tecniche DSL più diffuse solo la
tecnica ADSL (Asymmetric Digital Subscriber Line) che può raggiungere, a seconda
della distanza, frequenze di cifra di alcuni Mb/s nel verso downstream, mentre la
frequenza di cifra upstream può arrivare fino a 640 kb/s, e la tecnica VDSL (Very
high speed Digital Subscriber Line) ad esempio con frequenze di cifra downstream e
upstream coincidenti e limitate a circa 13 Mb/s.

3 Descrizione generale della PON per il campus dell’Università di Parma
      La rete PON che sarà costruita all‟Università di Parma è destinata alla
teledidattica in un‟area limitata, almeno inizialmente, al campus dell‟Università
stessa. Nel dimostratore il videoserver sarà collegato alla OLT per mezzo di una
tratta in fibra ottica, non considerata in questa relazione. Più terminali video saranno
collegati alla medesima terminazione di rete NT di una ONU tramite cavi in rame.



                                                                                      99
     La realizzazione di tale rete potrebbe anche consentire di sperimentare ulteriori
soluzioni di trasmissione. Per esempio, il rapporto di diramazione e la lunghezza dei
rami in fibra potrebbero essere portati più vicini a valori tipici di una PON per
telecomunicazioni.
    Sono stati individuati allo scopo e studiati alcuni possibili scenari per il
dimensionamento della ODN [1].
     Nel primo scenario la ODN collega la OLT a due ONU, in modo da soddisfare le
attuali necessità di teledidattica nell‟ambito dell‟Università.
    Il secondo scenario prevede l‟aggiunta di rami in modo da avere una ODN
compatibile con quelle utilizzate nelle PON per rete di accesso.
     Il terzo e il quarto scenario aggiungono ai primi due la possibilità della
diagnostica completamente ottica della ODN.
      Sul campus esiste una rete in fibra ottica che raggiunge i vari edifici con fibre
sia multimodali che monomodali. Le lunghezze delle tratte sono state fornite
dall‟Università di Parma, insieme con la localizzazione delle infrastrutture di
interesse.
3.1 Impiego della PON per teledidattica
      Questa è la rete passiva che, alla fine dei lavori, rimarrà come infrastruttura
fissa per la teledidattica nel campus dell‟Università di Parma. Si prevede che ci
saranno due ONU, almeno inizialmente, e perciò non è necessario che il rapporto di
diramazione sia maggiore di 2. Tuttavia potrebbe essere conveniente predisporre la
rete fin dall‟installazione per un numero maggiore di ONU.
       Sia per la sperimentazione più generale sulla PON per applicazioni in ambito
metropolitano, sia per la PON per la teledidattica, la flessibilità offerta dalla
connettorizzazione dei diramatori e degli altri dispositivi potrebbe essere preferibile
all‟utilizzo di giunti a fusione.
3.2 Predisposizione della PON per la diagnostica ottica
     Le azioni di manutenzione per una rete ottica sono definite nella
raccomandazione ITU-T L.25 e divise in due principali categorie: azioni di
manutenzione preventiva (da eseguirsi, quando possibile, prima dell‟insorgere di un
guasto) e azioni di manutenzione correttiva (da compiersi a guasto avvenuto).
        Le azioni di manutenzione preventiva consistono nel rilevare degradazioni di
fibre/componenti ottici che, pur non pregiudicando il funzionamento immediato della
rete, possono con il tempo e se sottovalutate, comportare guasti più seri: tipico è
l‟infiltrazione di acqua nelle muffole di giunzione delle fibre.
     L‟aspetto specifico, e di grande importanza pratica della manutenzione
preventiva che si è deciso di analizzare in questo progetto, consiste nel rilevare la
degradazione della linea ottica, ed in caso di guasto localizzare il punto dell‟evento.




                                                                                    100
       L‟analisi del problema e il progetto di un sistema per la sperimentazione sulla
manutenzione ottica sono oggetto del rapporto annuale sul sottotema “Soluzioni per
l‟optical maintenance/ sperimentazioni in laboratorio” [2].
      La tecnica di misura giudicata più opportuna per effettuare la diagnostica ottica
della rete in fibra è la metodologia del “backscattering” mediante un OTDR (Optical
Time Domain Reflectometry), basata sulla misura del segnale retrodiffuso dalla linea.
      Tra le configurazioni possibili per realizzare un sistema di sorveglianza ottica
per reti PON ad albero, considerata la topologia in oggetto e la necessità di una
soluzione abbastanza generale che non ponga vincoli troppo forti sull‟infrastruttura in
fibra, si è scelto lo schema di Figura 3.1, che non prevede fibre ausiliarie, e che si
affida all‟impiego di componenti ottici passivi abbastanza economici per l‟inserimento
e la derivazione del segnale ottico usato per l‟indagine OTDR.




                 Figura 3.1 – Monitoraggio ottico sulla fibra di servizio

    La configurazione di Figura 3.1, proposta per rapporti di diramazione maggiori o
uguali a 8, richiede l‟inserimento, su ogni ramo della PON, di un dispositivo di
                          o in lunghezza d‟onda, in grado di discriminare tra la
                                                                                m =


in alternativa, l‟inserimento della
diramatore. Si è anche valutato che sull‟interfaccia ottica della OLT e della ONU è
necessario inserire un filtro di blocco per annullare l‟effetto della lunghezza d‟onda di
diagnostica sui rispettivi ricevitori.



                                                                                      101
4 Attività sperimentale
       A fronte di quanto esposto nei paragrafi precedenti, come prima misura si è
caratterizzato spettralmente l‟OTDR a 1625 nm. La misura è stata effettuata
utilizzando un analizzatore di spettro ottico inviando il segnale opportunamente
attenuato dell‟ OTDR, per due valori di larghezza dell‟impulso. In particolare la Figura
4.1 mostra lo spettro a 1625 nm utilizzando un impulso di 1 µs ed un impulso di 10
ns. Come si può notare, lo spettro è abbastanza ampio (10÷20 nm) in linea con
quanto dichiarato nelle specifiche del costruttore.




                      Figura 4.1 – Spettro dell’ODTR a 1625 nm

      Avendo deciso di realizzare in laboratorio un sistema di sperimentazione
flessibile con connettori ottici, invece di utilizzare giunti a fusione, si poneva il
problema della scelta del tipo di connettore ottico da utilizzare: piano o angolato.
Benché dal punto di vista trasmissivo di un segnale numerico e con frequenze di cifra
fino a 1 Gb/s la scelta, dal punto di vista tecnico e non economico, possa essere
indifferente, l‟utilizzo di un sistema OTDR che usa un segnale analogico può porre
dei vincoli.
      In Figura 4.2 viene riportata una traccia OTDR di una generica PON 1x2 con
connettori piani. Come si può notare, oltre alle riflessioni tipiche (dopo 1 km di fibra
dove è posizionato il diramatore, dopo 1 km dal diramatore per un ramo e dopo circa
4 km dal diramatore sul secondo ramo), compaiono anche due picchi “fantasma”
lungo la traccia. Questi picchi in realtà sono dovuti a doppie riflessioni, ed non
corrispondono a nessun evento fisico.
     Inoltre a differenza dell‟uso di connettori piani, con quelli angolati si riescono a
misurare con l‟OTDR anche tratte piuttosto brevi (usando impulsi di misura di breve
durata).




                                                                                      102
   Figura 4.2 – Traccia di un OTDR di una rete ottica 1x2 dove sono stati utilizzati
                 connettori ottici piani per connettere i vari componenti.
Si rilevano i picchi dopo 1 km di fibra dove è posizionato il diramatore, dopo 1 km dal
   diramatore per un ramo e dopo circa 4 km dal diramatore sul secondo ramo. Si
         possono inoltre notare anche due picchi “fantasma” lungo la traccia.

      Per ovviare ai problemi sopra esposti, si possono utilizzare connettori ottici
angolati: l‟effetto che se ne ricava è mostrato in Figura 4.3. In questo caso le
riflessioni nel punto di congiunzione dei componenti sono minori, ed in aggiunta non
compaiono più i picchi fantasmi.




          Figura 4.3 – Come figura 4.2 ma utilizzando connettori angolati.




                                                                                    103
4.1 PON 1x2
     La Figura 4.4 mostra lo schema della PON a due rami realizzata in laboratorio,
e comprendente i componenti passivi utilizzati per la sperimentazione della
manutenzione ottica. La lunghezza di fibra dei due rami risulta essere piuttosto breve
(500 m e 1400 m): tale scelta è stata effettuata in modo da simulare l‟infrastruttura
presente a Parma.
      Le perdite aggiuntive per ciascun ramo (oltre ai 3 teorici del diramatore)
dovrebbero essere di circa 0.5 dB, ma a causa dei connettori, del WDM ed del filtro
inseriti nella catena (mediamente 0.4 dB per ogni elemento utilizzato in questa
sperimentazione), l‟attenuazione risulta essere di circa 6 dB per ogni ramo. Nella
figura sono anche mostrati i valori di potenza ottica (a 1310 nm) nei vari punti della
rete.




Figura 4.4 – Schema della PON 1 x2 realizzata in laboratorio per la sperimentazione
                            della mautenzione ottica
      Nello schema di Figura 4.4, si può notare anche la presenza di una fibra di
lancio posizionata tra OTDR e il WDM utilizzato per inserire la lunghezza d‟onda di
monitoraggio a 1625 nm. Con tale fibra si ottiene il vantaggio di poter misurare con
l‟OTDR anche l‟attenuazione del sistema WDM + accoppiatore WIC (Wavelength
Independent Coupler). Inoltre, in caso di forte riflessione del connettore iniziale della
rete, non si avrebbero disturbi nella misura nel punto di separazione dei due rami. La
Figura 4.5 mostra la traccia dell‟ OTDR della rete di Figura 4.4 (senza la fibra di
lancio) mentre nella Figura 4.6 viene inserita la fibra di lancio di 1 km.




                                                                                      104
  Figura 4.5 – Traccia OTDR della rete mostrata in Figura 4.4 senza fibra di lancio.




  Figura 4.6 – Traccia OTDR della rete mostrata in Figura 4.4 utilizzando la fibra di
                                      lancio.

       L‟attenuazione del filtro a 1625 nm (>45 dB) garantisce inoltre la separazione
tra il canale trasmissivo e quello di monitoraggio.
4.2 Analisi delle tracce OTDR
     L‟OTDR visualizza la traccia di attenuazione con il metodo di backscattering di
una fibra ottica al variare della distanza dall‟origine applicando la relazione:

                                        1           P    
                                   A    10  log  X
                                                     P    
                                                           
                                        2            O   

     in cui:
     PX = potenza retrodiffusa nel punto di distanza x dall‟origine



                                                                                    105
     PO = potenza retrodiffusa all‟origine.
       Il fattore ½ tiene conto del fatto che il segnale ottico di backscattering percorre
la fibra sia all‟andata che al ritorno.
      Nel considerare l‟attenuazione complessiva di una rete PON, così come è vista
dall‟OTDR, occorre tener conto che in ciascun punto della traccia la potenza
complessiva è data dalla somma dei contributi di backscattering provenienti dai
diversi rami. Nel caso di un accoppiatore 1 x 2 la potenza incidente (relativa al
segnale di backscattering), che si suppone pari a 1, si divide metà per parte, per cui
si ha un segnale di ritorno per ciascun ramo pari a 0.25 (0.5 all‟andata moltiplicato
per 0.5 al ritorno).
      Sull‟OTDR viene visualizzata la traccia come somma di due fattori:
l‟attenuazione con la distanza dovuta alla fibra e quella dovuta al rapporto di
partizione dell‟accoppiatore che secondo l‟esempio citato è pari a:

                                                         0.52  0.52 
                                Aaccoppiatore  5  log
                                                                     
                                                                      
                                                              1      



      L‟attenuazione con la distanza della sola fibra è di circa 0.2 dB/km @1550 nm e
di circa 0.37 dB/km @1310 nm per le fibra SM.
     In base a quanto detto sopra, nel caso di una PON a due rami (1x2) si
vedrebbero sullo schermo dell‟OTDR, lungo la traccia, due “step” pari a 1.5 dB, uno a
distanza dall‟origine dove è piazzato l‟accoppiatore e l‟altro in corrispondenza del
termine del primo ramo della rete (vedi Figura 4.7).
     Per ogni singolo ramo l‟attenuazione del salto (cioè il valore dello “step”)
sarebbe in questo caso pari a 3 dB (vedi Figure 4.8 e 4.9).
      Naturalmente queste sono valutazione teoriche: in pratica, nel caso di PON a
due rami, il rapporto di diramazione non sarà esattamente 0.5 in quanto occorre
considerare anche l‟attenuazione intrinseca dell‟accoppiatore e quella dei connettori
di ingresso e di uscita dall‟accoppiatore. Il fattore di accoppiamento per ciascun ramo
risulterà quindi inferiore.
     Nelle Figure 4.10, 4.11 e 4.12, è simulata la presenza di un punto di
attenuazione concentrata (ad esempio un pessimo giunto a fusione o uno stress
concentrato sulla fibra). Per la simulazione è stato introdotto, alla distanza del giunto,
un coefficiente di partizione proporzionalmente ridotto rispetto a quello che si ha nel
punto di diramazione.




                                                                                       106
                                                   PON a 2 rami

                           2.0
                           1.0
                           0.0
                          -1.0
          livello in dB



                          -2.0
                          -3.0
                          -4.0
                          -5.0
                          -6.0
                          -7.0
                          -8.0
                                 0   500    1000         1500         2000     2500    3000
                                           distanza dallo strumento in metri



 Figura 4.7 – Simulazione della traccia di “backscattering” di una rete PON a due
rami: fibra 1 di 500 metri e fibra 2 di 1400 metri. Fibra di lancio di 1000 metri prima
                                 dell’accoppiatore 1x2.




                                                   PON a 2 rami

                           2.0
                           1.0
                           0.0
                          -1.0
          livello in dB




                          -2.0
                          -3.0
                          -4.0
                          -5.0
                          -6.0
                          -7.0
                          -8.0
                                 0   500    1000         1500         2000     2500    3000
                                           distanza dallo strumento in metri



Figura 4.8 – Simulazione della traccia di “backscattering” di una rete PON a due rami: fibra 2 di 1400
                                 metri interrotta all’accoppiatore 1x2




                                                                                                   107
                                         PON a 2 rami

                 2.0
                 1.0
                 0.0
                -1.0
livello in dB




                -2.0
                -3.0
                -4.0
                -5.0
                -6.0
                -7.0
                -8.0
                       0   500    1000         1500         2000     2500   3000
                                 distanza dallo strumento in metri



Figura 4.9 – Simulazione della traccia di “backscattering” di una rete PON a due
            rami: fibra 1 di 500 metri interrotta all’accoppiatore 1x2.




                                         PON a 2 rami

                 2.0
                 1.0
                 0.0
                -1.0
livello in dB




                -2.0
                -3.0
                -4.0
                -5.0
                -6.0
                -7.0
                -8.0
                       0   500    1000         1500         2000     2500   3000
                                 distanza dallo strumento in metri



Figura 4.10 – Simulazione della traccia di “backscattering” di una rete PON a due
 rami: attenuazione di circa 1 dB sulla fibra 2 a 1125 metri dall’accoppiatore 1x2.




                                                                                   108
                                         PON a 2 rami

                 2.0
                 1.0
                 0.0
                -1.0
livello in dB




                -2.0
                -3.0
                -4.0
                -5.0
                -6.0
                -7.0
                -8.0
                       0   500    1000         1500         2000     2500   3000
                                 distanza dallo strumento in metri



Figura 4.11 – Simulazione della traccia di “backscattering” di una rete PON a due
 rami: attenuazione di circa 1 dB sulla fibra 1 a 250 metri dall’accoppiatore 1x2.




                                         PON a 2 rami

                 2.0
                 1.0
                 0.0
                -1.0
livello in dB




                -2.0
                -3.0
                -4.0
                -5.0
                -6.0
                -7.0
                -8.0
                       0   500    1000         1500         2000     2500   3000
                                 distanza dallo strumento in metri



Figura 4.12 – Simulazione della traccia di “backscattering” di una rete PON a due
 rami: attenuazione di circa 1 dB sulla fibra 2 a 350 metri dall’accoppiatore 1x2.




                                                                                   109
PON 1x4
       In prospettiva di una futura evoluzione dell‟architettura della PON installata a
Parma, nei laboratori CSELT è stata realizzata una PON a quattro rami, come
indicato in Figura 4.13, con lo scopo di verificare sperimentalmente che anche con 4
rami è possibile utilizzare la configurazione per la manutenzione ottica con l‟OTDR
posizionato a monte del diramatore. La lunghezza delle quattro fibre è mostrata
sempre in Figura 4.13: la lunghezza di circa 12 km è stata scelta nell‟ipotesi di dover
utilizzare la rete anche al di fuori dell‟Area delle Scienze dell‟Università.
    Come diramatore è stato utilizzato un accoppiatore in fibra fusa 2 x 4. Tutti i
connettori della PON sono del tipo FC/APC.




Figura 4.13 – Schema della PON 1x2 realizzata in laboratorio per la sperimentazione
                            della mautenzione ottica

      Le Figure 4.14 e 4.15 riportano la traccia di attenuazione dell‟intera rete alle
lunghezze d‟onda di 1310 nm e 1550 nm; come fibra di lancio è stata utilizzata una
fibra lunga circa 1400 metri.
      Nelle Figure 4.16 e 4.17 è illustrata, come esempio, la risposta dell‟OTDR nel
caso di interruzione all‟origine (cioè al diramatore) rispettivamente della fibra 2 e
della fibra 4.
     La Figura 4.18 riporta la traccia di attenuazione dell‟intera rete alle lunghezze
d‟onda di 1625 nm.




                                                                                    110
Figura 4.14 –
                ns.




Figura 4.15 –         so 300
                ns




                          111
Figura 4.16 –
            ns. Fibra uscente dal ramo 2 interrotta all’origine.




Figura 4.17 –
                 uscente dal ramo 4 interrotta all’origine.



                                                                   112
         Figura 4.18 –                                                         300 ns.



Conclusioni
      In questo rapporto sono state presentate le misure sperimentali di
manutenzione ottica su una rete PON, realizzata in laboratorio, nello scenario di
teledidattica utilizzato dall‟università di Parma con diramazione di 2 fibre, e nello
scenario di una possibile futura evoluzione a quattro rami.
       Dal punto di vista tecnico non sono stati riscontrati particolari problemi:
l‟inserimento di componenti passivi per realizzare il monitoraggio ottico comporta un
aumento di attenuazione di meno di 1 dB per ogni ramo, a patto di utilizzare,
nell‟infrastruttura definitiva, giunti a fusione rispetto a connettori ottici, anche se
questi ultimi danno più flessibilità alla rete.
       È inoltre importante utilizzare una fibra di lancio tra l‟OTDR e la rete ottica: con
tale fibra si ottiene il vantaggio di poter misurare con l‟OTDR anche l‟attenuazione del
sistema WDM + accoppiatore WIC.
      Si è potuto constatare che l‟inserzione dell‟OTDR a monte del diramatore,
anche con quattro rami in uscita, non pone particolari problemi di dinamica ed analisi
delle tracce dell‟OTDR stesso: a tale proposito è stata anche presentata, a titolo di
esempio, un‟analisi di come interpretare le tracce viste sull‟OTDR a fronte di una
eventuale attenuazione concentrata su uno dei rami della rete che si sta
monitorando.



                                                                                         113
Bibliografia

[1]   M. Calzavara et al., “Contributo al dimensionamento del dimostratore di PON
      per il campus dell'Università di Parma”, Documento CSELT DPC 1999.04470.
[2]   A. Gnazzo, M. Calzavara, P. Bradley, “Manutenzione ottica per la PON: studio e
      progetto del sistema per la sperimentazione in laboratorio”, Documento CSELT
      DPC 1999.04220.

Elenco di sigle, acronimi e simboli

ATM Asynchronous Transfer Mode
BER Bit Error Rate
CED Centro Elaborazione Dati
CSELT Centro Studi e Laboratori Telecomunicazioni
DFB   Distributed Feedback Buried heterostructure
LED   Light Emitting Diode
MURST Ministero dell‟Università e della Ricerca Scientifica
NT    Network Termination
ODN Optical Distribution Network
OLT   Optical Line Termination
ONU Optical Network Unit
OTDR Optical Time Domain Reflectometer
PON Passive Optical Network
TDM Time Division Multiplexing
TDMA Time Division Multiple Access
WIC   Wavelength Independent Coupler




                                                                                 114
PROGETTO DI RICERCA APPLICATA 5%
  “Rete multimediale interattiva di accesso all‟utente”


            --------------------
Linea 2 – “Servizi multimediali interattivi su
            rete ottica passiva”

            --------------------
           RELAZIONE ATTIVITA’ INDUSTRIALE
                SECONDO ANNO




                                                          115
La seguente relazione ha lo scopo di illustrare quanto svolto da Marconi
Communications nel secondo anno di attività nell‟ambito del progetto di ricerca
applicata 5% “Rete multimediale interattiva di accesso all‟utente”.

Marconi Communications è coinvolta nella linea di ricerca 2 “Servizi multimediali
interattivi su rete ottica passiva”. In particolare le sono stati assegnati i seguenti punti:




sottotema 3.4: problemi di trasmissione sul canale di ritorno

tema 4: progettazione e realizzazione degli apparati

sottotema 5.3: soluzioni per l‟optical maintenance

sottotema 6.2: installazione e integrazione degli apparati


  Segue una sintesi delle attività svolte e dei principali risultati ottenuti nel secondo
anno di lavoro.



1) sottotema 3.4: problemi di trasmissione sul canale di ritorno.

  Nel secondo anno di attività sono stati oggetto di studio i seguenti punti:

   a) analisi delle tecniche adottate per la ricezione di segnali provenienti da diverse
      ONU

   b) studio del jitter che puo‟ essere introdotto dalla trasmissione a burst



a) In particolare sono stati studiati i problemi relativi a ranging, phase recovery e
   level recovery.

    Riguardo al ranging e‟ stata studiata la procedura che consente, tramite
    l‟hardware implementato, di definire la distanza delle singole ONU dalla OLT. E‟
    in fase di stesura il software che consentirà l‟esecuzione automatica del ranging
    senza l‟intervento dell‟operatore.

    Per il level recovering si è ottimizzata la circuiteria (in termini di valori dei
    componenti) presente sul ricevitore upstream al fine di adeguare la risposta del
    circuito alle necessità del dimostratore.




                                                                                         116
   Il circuito di phase recovering e‟ stato oggetto di prove prolungate per la difficoltà
   del test. Sono state apportate modifiche al circuito presente sulla seconda
   versione dei prototipi per migliorarne il comportamento e aumentarne la stabilità
   in funzione dell‟uscita del precedente stadio di level recovery.


b) Relativamente al possibile jitter introdotto dalla trasmissione a burst, si è studiata
   la “qualità” del segnale trasmesso dalla ONU.
   Si è posto l‟accento sulle problematiche relative all‟accensione del laser e alla sua
   prepolarizzazione prima di ogni slot assegnata alla ONU per la trasmissione delle
   celle upstream.
   Le osservazioni hanno portato alla conclusione che con un opportuno anticipo
   dell‟accensione e della prepolarizzione del laser non viene introdotto nessun jitter
   aggiuntivo a quello eventualmente presente sul clock estratto dal segnale
   downstream ricevuto.
   Comunque saranno condotte prove più esaustive quando sarà a disposizione il
   sistema finale.



2) tema 4: progettazione e realizzazione degli apparati.

a) Progettazione e realizzazione hardware

   Si è proceduto al testing del secondo giro di prototipazione al fine di verificare la
   validità delle modifiche introdotte rispetto alla prima versione.
   I risultati ottenuti sono stati un miglioramento del segnale ottico downstream, un
   aumento della sensibilità del ricevitore downstream e un aumento della dinamica
   sul ricevitore upstream.


b) Progettazione e realizzazione software

   Lo sviluppo del software è stato diviso in due sezioni: una relativa alle necessità
   di controllo delle singole schede con la stesura di driver di basso livello, e una
   relativa alla gestione del sistema con la stesura di routine ad alto livello.

   In prima istanza sono stati sviluppati i driver di basso livello per la gestione delle
   parti controllate tramite microprocessore, quali convertitori DAC e ADC,
   scrittura/lettura registri di configurazione, programmazione e configurazione
   FPGA.

   Successivamente si è passati allo studio delle funzioni a più alto livello per il
   controllo automatico delle schede, quali il controllo automatico della potenza dei
   LASER in entrambi i trasmettitori e la taratura dell‟APD nel ricevitore upstream.




                                                                                      117
c) Integrazione del sistema.

   L‟integrazione del sistema è stata suddivisa nelle seguenti parti:

            - sistema PON escluso DSLAM
            - sistema PON incluso DSLAM

   In una prima fase è stato integrato il sistema PON senza la parte DSLAM. In tale
   configurazione è stato possibile testare tutte quelle funzionalità proprie della parte
   di trasporto di celle ATM non legate al contenuto delle celle stesse.

   Particolare attenzione è stata dedicata alle parti critiche del ricevitore upstream:
   equalizzazione di livello, recupero della fase, procedura di ranging.

   I risultati ottenuti sono stati soddisfacenti, per cui si è passati alla seconda fase di
   integrazione: sistema PON + DSLAM

   Questa nuova configurazione è stata ottenuta inserendo le schede del sistema
   PON in cestelli DSLAM e realizzando una rete uguale a quella del dimostratore.

   Tale configurazione ha evidenziato problemi di integrazione riguardante il traffico
   ATM. Tali problemi sono dovuti principalmente alla mancanza di buffer per le
   celle ATM nelle interfacce tra le parti DSLAM e le parti PON che limitano la
   capacità di trasmissione in termini di banda. Questo ha portato ha rivedere lo
   studio del sistema proposto: mantenere la seconda versione delle schede PON
   ma in un apparato configurato diversamente.

   È stato deciso di sviluppare un sistema PON “stand-alone” che realizzi tutte le
   funzionalità richieste e che metta a disposizione verso il resto della rete delle
   interfacce standard. In questo modo si possono concentrare gli sforzi e le risorse
   solo sulle parti di interesse per il progetto PON e utilizzare per il completamento
   della rete apparati disponibili senza doverli adattare alle nostre esigenze.

   La nuova struttura proposta per il dimostratore è la seguente.




                                                                                        118
                                                                     NT       PC


                                          ONU        DSLAM

                                                                     NT       PC


VS         SW        OLT


                                                                     NT       PC
                                          ONU        DSLAM


                                                                     NT       PC




        Il sistema DSLAM può essere quindi un qualsiasi apparato che realizzi un
        funzioni di mapping di linee ADSL su interfacce STM-1/OC-3.



     3) sottotema 5.3: soluzioni per l‟optical maintenance

        Per quanto riguarda la nostra parte del dimostratore si intende come optical
        maintenance l‟insieme di funzionalità che consentono al sistema di reagire alle
        perturbazioni che potrebbero causare malfunzionamenti o degrado delle
        prestazioni, come ad esempio aumento della temperatura sulla fibra o degrado
        dei componenti ottici.
        A tal proposito sono state definite procedure di monitoraggio del sistema da
        implementare via software per mezzo di parti hardware dedicate.

     4) sottotema 6.2: installazione e integrazione degli apparati

        A causa dei nuovi sviluppi avviati per la realizzazione del sistema finale non si è
        ancora proceduto all‟installazione del sistema presso il Campus dell‟Università di
        Parma.
        In laboratorio abbiamo proceduto all‟integrazione del sistema basato sul sistema
        Marconi MAT14 in modo da poter condurre test sull‟hardware e sul software
        finora disponibili (ovviamente con le limitazioni di cui al punto 2-c).




                                                                                        119

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:12
posted:1/6/2012
language:Italian
pages:121