Unica

NOTIZIARIO TECNICO TELECOM ITALIA - Anno 12 n. 1 - Dicembre 2003 65

Gestione

Telecom Italia punta a UNICAUn solo data base per la gestione della Rete

DOMENICO CASTALDO

NICOLA IORIO

La gestione dei dati di rete ha sempre rappresentato una delle aree strategiche perun’azienda di telecomunicazioni, ma essa diventa uno dei fattori fondamentali disuccesso se si decide di incrementare il livello di automazione dei processi di provi-sioning, delivery, assurance e creation. Tale obiettivo è stato raggiunto dalla “nuovapiattaforma per la gestione delle reti e dei servizi a larga banda”, che rappresentauno dei progetti più significativi del piano sistemi [1], nel quale un secondo fattoredi successo è stata l’automazione integrata dalle diverse parti che compongono l’ar-chitettura sistemistica.L’articolo descrive i principali motivi che hanno portato alle scelte architetturali etecnologiche effettuate, le soluzioni adottate nell’ambito dei data base della rete, lefasi in cui lo sviluppo di tali soluzioni è stato suddiviso, le attuali e le future evo-luzioni che hanno consentito e progressivamente consentiranno di estendere la piat-taforma alla gestione di tutte le reti di Telecom Italia.

1. Introduzione

I servizi a larga banda e, più in generale, i servizidati sono quelli che più di altri hanno mostratoandamenti di crescita rilevanti nel corso degli ultimianni, e sono anche quelli sui quali maggiormente siè sviluppata la competizione tra le aziende del set-tore. Era quindi inevitabile che uno dei più signifi-cativi progetti del piano sistemi fosse finalizzato alladefinizione e alla realizzazione di una piattaforma digestione che, partendo dai sistemi esistenti, assicu-rasse l’evoluzione necessaria per agevolare il suc-cesso della competizione oggi presente nelle reti ditelecomunicazione.

All’interno della piattaforma le problematicherelative ai data base assumono un’importanza strate-gica poiché tutti i sistemi e i processi di commercia-lizzazione (TGU, Siebel, Pitagora, …), di controllo diprocesso (NSD-OM Engine), di disponibilità delleinformazioni (report), di attivazione del servizio (ser-

vice delivery), di mantenimento del servizio (serviceassurance) e di creazione della rete (network creation)dialogano con i data base della rete e hanno neces-sità dei dati in essi contenuti per garantirne il cor-retto funzionamento.

Da una situazione molto frammentata con unalto numero di data base di rete e di sistemi di for-nitura (provisioning) si è passati a un’architetturaobiettivo con un solo data base e un unico sistemadi provisioning per la gestione dei servizi della retedati. Il data base e il sistema di provisioning si chia-mano UNICA/D (Unique Network Inventory Co-opera-ting Automatisms/Dati) e rappresentano la prima fasedel programma che prevede la sostituzione - dopo laporzione relativa alla rete dati - delle attuali basidati e dei sistemi di provisioning della rete trasmis-siva, TIRKS/GAT (Trunk Integrated Record KeepingSystem/Gestione Automatata Trasmissione), di accesso,ACL/RR (Automazione Centri di Lavoro Registri diRete) e di commutazione, ACL/RC (Automazione

66 NOTIZIARIO TECNICO TELECOM ITALIA - Anno 12 n. 1 - Dicembre 2003

Castaldo - Iorio • Telecom Italia punta a UNICA - Un solo data base per la gestione della Rete.

Centri di Lavoro/Registri diCentrale).

Per attuare questo pro-gramma concorreranno sia isistemi esistenti - aggiornatiopportunamente - sia nuovisistemi basati su nuove piat-taforme tecnologiche. Alcompletamento di questaattività di rinnovamento deisistemi finora impiegati, siavrà che l’attuale piattaformadi gestione delle reti e deiservizi a larga banda diven-terà la piattaforma digestione delle reti e dei ser-vizi di Telecom Italia.

2. Situazione preesistente

Sembra opportuno analiz-zare dapprima gli aspetticaratteristici dell’architetturasistemistica iniziale.

Si è partiti da un’architet-tura sistemistica in cuiTIRKS/GAT è il sistema diinventario (network inventory)delle risorse di rete nei conte-sti TDM, ATM/FR, xDSL.

Il sistema svolge in coope-razione con altri sistemi,IDNM/SR (Integrated DataNetwork Manager/Servizi diRete), IDNM/SP (IntegratedData Network Manager/ServiceProvisioning), WRAP/WFM(Work Request AutomatismP r o d u c e r / W o r k F o r c eManagement), DAI (DeliveryAssistenza Impresa), CPC (CiscoProvisioning Center), SGF(Sistema Gestione Flussi),SGSDH-NM (Sistema GestioneSDH-Network Manager) eSIGRA/IT (Sistema InformativoGRAfico/Impianti Trasmissivi) un ruolo centrale nel-l’ambito del processo di service provisioning e networkcreation.

In figura 1 è mostrata la preesistente architetturasistemistica per i processi di service provisioning e didelivery nei contesti di risorse di rete sopra indicati.

In quest’architettura, nell’ambito dei servizixDSL gestiti (Alice, Smart, IBS, CVP, Wholesale, …)i sistemi di provisioning cooperanti sono:• TIRKS/GAT: progettazione dell’accesso su MUX

ADSL (A point) e dei circuiti della CDN perl’accesso dei CVP (Canale Virtuale Permanente);

• IDNM/SR: progettazione per la consegna ATM(Z point);

• IDNM/SP: individuazione consegna ATM (Zpoint) per servizi IBS (InterBusiness Services) egestione del livello IP;

• WRAP/WFM: gestione degli operatori sociali;• DAI: gestione degli operatori esterni (imprese);• CPC: delivery automatico su apparati ADSL

ed ATM.

Nell’ambito dei servizi svolti nella retePDH/SDH (CDN, Interconnessione, …) i sistemidi provisioning cooperanti sono invece:• TIRKS/GAT: progettazione dei circuiti CDN;• WRAP/WFM: gestione degli operatori sociali;• DAI: gestione degli operatori esterni (imprese);• GATEWAY/SGF: delivery automatico sui apparati

trasmissivi RED 4-4;• GATEWAY/SGSDH-NM: delivery automatico

sugli apparati trasmissivi SDH.Con questa architettura il processo di network

creation è gestito dai sistemi:

TLDPitagora(Special)

NSD

ACL/RCACL/RR

LIDOGTW

(SDH, SGF) WRAP, WFM IDNM/SP

Reportistica Configurazionedegli apparati

Mano d’operasociale

Provisioninglivello 2 & 3

ULLCDN ACCOGLIENZACDN OLOxDSL

TGU, OLBB,WAD, ...

Pitagora(Classic) Toscanini

Service Provisioning

DAI

Mano d’operadell'impresa

Provisioning livello 2

Configurazione degli apparati

IDNM/SR

CPC

FEPS/SCS

TIRKS

GAT

SIGRA/IT

ACL/RCACL/RR

CDNCPCDAI

FEPS/SCSGAT

GTWIDNM/SP

LIDONSD

OLBBOLOSDHSGF

SIGRA/ITTLDTGU

TIRKSULL

WADWFM

WRAPxDSL

========================

Automazione Centri di Lavoro/Registri di CentraleAutomazione Centri di Lavoro/Registri di ReteCircuiti Diretti NumericiCisco Provisioning CenterDelivery Assistenza ImpresaFacility Equipment Planning System/Scheduling Coordination SystemGestione Automatata TrasmissioneGaTeWayIntegrated Data Network Manager/Service ProvisioningLivello Integrato Dati OperazionaliNetwork Service DeliveryOrdini di Lavoro BroadBandOther Licensed OperatorSynchronous Digital HierarchySistema di Gestione FlussiSistema Informativo GRAfico/Impianti TrasmissiviTelegestione Linee DedicateTele Gestione UtenzaTrunk Integrated Record Keeping SystemUnbundling Local LoopWholesale ADSL DatacomWork Force ManagementWork Request Automatism Producerx Digital Subscriber Line

Figura 1 Architettura sistemistica iniziale.



• SIGRA/IT: progettazione degli apparati presentinelle sale di alta frequenza delle centrali tra-smissive e gestione degli ordini (ISAF) di appa-rato;

• TIRKS/GAT: delivery degli ordini per la proget-tazione da attuare sugli apparati.I sistemi FEPS (Facility Equipment Planning

System)/TIRKS e GAT gestiscono anche il provisio-ning infrastrutturale a fronte delle analisi delle esi-genze legate al traffico da instradare in rete.

3. Linee guida per la gestione sistemistica

La necessità sia di contenere i costi di gestionesistemistica e operativa sia di garantire volumi diordini in continuo e progressivo aumento a costidecrescenti e sempre più competitivi, ha permessodi individuare le linee guida per lo sviluppo dellasoluzione per la gestione.

Nell’ambito della soluzione definita per conte-nerne i costi sono stati razionalizzati e reingegneriz-zati i data base della rete abbandonando tutte leapplicazioni caratterizzate da soluzioni tecnologicheobsolete e con alti costi di manutenzione.

La presenza di un bus (TIBCO) di comunica-zione e di un data layer comune, contenente leinformazioni sulla consistenza dei servizi e dellerisorse (logiche e fisiche) di rete, ha consentitod’altra parte una condivisione di un modello infor-mativo inter-dominio, neutrale rispetto alle singoletecnologie di rete e ha anche permesso di elimi-nare le interfacce dirette (peer-to-peer) presenti inprecedenza.

Nell’ambito della soluzione definita per conte-nere i costi operativi è stato minimizzato il numerodi sistemi e di basi dati differenti per la realizza-zione del provisioning dei servizi; allo stesso tempo,è stato massimizzato il livello di automatismo permigliorare i tempi di attraversamento della catenasistemistica.

La razionalizzazione del data layer rappresenta,poi, il punto di partenza (tutti i sistemi sono, infatti,consistenti) per permettere di migliorare la qualitàdei dati a vantaggio dei processi aziendali di forni-tura dei servizi ai clienti (network creation, provisio-ning) e di supervisione dei servizi forniti (assurance,performance).

Il progetto UNICA ha, infine, come obiettivo(miss ion) la r iduzione del le bas i dat i per lagestione delle reti ad un’unica base dati e delnumero di sistemi di provisioning a un unicosistema, realizzando, in tal modo, il massimolivello di automazione. Il nome del progetto e l’a-cronimo impiegato descrivono gli obiettivi perse-guiti.

4. Processo di provisioning nella nuova piattaforma per la gestione della rete a larga banda

Lo sviluppo della soluzione della piattaformaper il processo di provisioning dei servizi a larga

banda rappresenta l’ultima fase della realizzazionedel progetto per la nuova piattaforma nell’ambitodella rete dati (denominata BB2+)[2]. Nelle fasiprecedenti sono stati implementati i processi di ser-vice assurance, di gestione dei cartellini di disservi-zio (Trouble Ticket Management), di controllo dellaqualità del servizio e di controllo del livello di satu-razione delle risorse di rete (Network CapacityPlanning).

Gli sviluppi legati al processo di provisioninghanno tenuto conto dei sistemi di Telecom Italiache, attraverso una progressiva strategia di evolu-zione delle loro funzionalità, potevano integrarsinella nuova soluzione e, anche, della necessità diabbandonare sistemi con impostazione verticaleattraverso sistemi phase oriented; ciò ha dato luogo aun impatto sull’operatività corrente che è statonecessario minimizzare.

La soluzione ha, infatti, come obiettivo di:• sostituire le attuali soluzioni verticali (ad esem-

pio TIRKS/GAT, IDNM/SR, IDNM/SP) consistemi focalizzati sulle singole fasi del processo(phase oriented), in modo da garantire la massimaflessibilità alle soluzioni necessarie per realiz-zare ciascuna fase;

• preservare gli investimenti in corso sui sistemioggi in esercizio, fornendo una soluzione ingrado di integrare i nuovi componenti nel conte-sto processivo esistente (ad esempio: NSD-OM,WRAP);

• garantire un impatto minimo sull’operativitàmediante un elevato livello di automatismo, rea-lizzando il principio delle ripartenze automati-che a due livelli - per sistema e per piattaforma -nell’ambito della gestione degli errori (one bottonrestart);

• garantire tempi accettabili per la gestione dinuove offerte commerciali, gestendo l’associa-zione dinamica tra offerte commerciali e servizirealizzati in rete.La soluzione utilizza il solo sistema UNICA/D

per realizzare tutte le attività di provisioning xDSLcon un automatismo completo per tutti i servizigestiti dal livello ATM e con un automatismo quasicompleto per il livello IP (sono, infatti, ancoranecessarie attività di assegnazione iniziale effet-tuate manualmente, ora non risolubili in manieraautomatica). Questa soluzione consente di sostituirei quattro sistemi finora impiegati nella gestione(TIRKS, GAT, IDNM/SR, IDNM/SP) - tranne la com-ponente CDN per i servizi CVP ancora gestita conTIRKS/GAT - e di spostare l’analisi delle attivitàmanuali (permute) per ogni servizio da GAT aWRAP, garantendo l’inserimento automatico dellerichieste (work request) in questo sistema.

La soluzione implementata permette di garan-tire sistemi dedicati per ogni singola fase del pro-cesso: UNICA è, infatti, un sistema di solo provisio-ning e le altre funzionalità presenti sui sistemi sosti-tuiti sono allocate nei sistemi deputati a svolgerle.L’integrità del processo - in precedenza verticale - ègarantita mediante la gestione integrata della piat-taforma, realizzata da una struttura orizzontale consistemi cooperanti.



Si costituisce, così, il primo nucleo del data layerin UNICA razionalizzando le (quattro) basi dati pre-cedentemente separate. Sono, altresì, preservati ilmantenimento (NSD-OM) e la valorizzazione(WRAP) dei sistemi ora impiegati per il delivery.

La presenza di un solo sistema di provisioning(UNICA) con un elevato livello di automatismo con-sente di ottenere un’ottimizzazione delle attivitàoperative e l’estensione dell’automatismo anchealla gestione dei servizi non completati a causa dierrori minimizza gli impatti operativi. Infatti, risoltasu UNICA la condizione di errore (per la mancanzadi porte sul MUX ADSL, per l’indisponibilità dibanda in accesso o sul livello ATM, per la mancanzadi indirizzi IP, …), è possibile riavviare il provisio-ning del servizio dal modulo JOE (Joint OperativeEnvironment) di UNICA o attendere il riavvio auto-matico mediante i l modulo SAM (SearchingAutomatic Module) sempre di UNICA da parte delsistema stesso (si veda il riquadro riportato in que-sta stessa pagina). A fronte di tale riavvio l’interapiattaforma gestisce l’ordine automaticamente; que-sta impostazione è comune a ogni sistema dellapiattaforma: in altre parole, ripristinato un ordinebloccato su un sistema della piattaforma (primolivello), la gestione riprende in modo completa-mente automatico (secondo livello) sull’intera piat-taforma (one botton restart).

La presenza in UNICA di un catalogo di servizi(service catalogue) consente di gestire dinamica-mente l’introduzione di nuove offerte commercialiassociando i nuovi servizi ai profili di servizio esi-

stenti. A fronte di una nuova offerta per tali profili- analoghi ai servizi gestiti in rete - si ampliano itipi di risorse di rete, utilizzabili per la realizza-zione dell’offerta, oppure si definiscono nuovi pro-fili che sono utilizzati dalla service automation diUNICA in modo da permettere la realizzazione delservizio in rete. L’elemento strategico di successo èla corretta modellizzazione dei dati della rete,effettuata separando le offerte commerciali dai ser-vizi gestiti in rete.

Quest’impostazione ha consentito per tutte leofferte commerciali che utilizzano solo la rete ATM(180 da ottobre del 2003), l’utilizzo degli stessipassi operativi della service automation.

La figura 2 mostra l’architettura sistemisticadella piattaforma a larga banda per la componentedi provisioning xDSL in esercizio da ottobre del2003. La presenza del bus di comunicazioneTIBCO consente di eliminare le interfacce dirette(peer-to-peer) e, anche, di utilizzare la funzione didiffusione multipla (broadcasting) per tutte le fasidel processo che possono essere svolte in parallelo,con una drastica riduzione dei tempi di attraversa-mento end to end nella catena sistemistica e opera-tiva.

Le prestazioni della piattaforma hanno consen-tito di gestire un numero medio di richieste com-merciali pari a 6mila ordini al giorno con picchi di10mila al giorno e con un numero di ordini elabo-rati, automaticamente, di 1300 all’ora in UNICA e2200 ordini all’ora in CPC. La percentuale media diordini non elaborati completamente in maniera auto-

U-BROTHERS:JOE & SAM

I moduli di UNICA JOE (UniqueNetwork Inventor y Co-operatingAutomatisms Joint OperativeEnvironment) e SAM (SearchingAutomatic Module) completano lacomponente di Service Automation.

JOE è l’ambiente utilizzato dagli opera-tori per l’analisi e il restart della giacenza;consente, infatti, l’analisi “pesata” dellagiacenza presente e il recupero senzaalcun intervento manuale.

Le principali funzioni disponibili sono:

• search: consente la ricerca con fil-tri diversi (TGU, TD, tipo diservizio, stato dell’ordine, data diinizio, data di fine e data dierrore, RO, codice di errore, …)

delle giacenze per analizzarne lecause;

• jump-find: per ogni ordine per-mette di saltare alla componenteWeb per l’analisi delle risorse daesso impegnate e comprenderegli interventi necessari per larimozione delle cause di blocco;

• resubmit: consente il riavvio inmodo manuale (anche multiplo)degli ordini con errori per il com-pletamento automatico dell’in-stradamento.

SAM è un modulo non visibile aglioperatori che effettua l’analisi con-giunta degli incrementi giornalieri direte e degli ordini errati per man-canza di risorse, e che riavvia auto-maticamente gli ordini con più altaprobabilità di successo.

Le principali funzioni disponibili sono:

• search: verifica la disponibilità di rete(porte di apparato, canali di gruppo)e ricerca la giacenza (per tipologia dierrore, centrali, …) relativa alleporte o ai canali disponibili;

• resubmit: riavvia automatica-mente gli ordini individuati chehanno la più alta probabilità disuccesso.

Gli U-BROTHERS offrono quindi iseguenti vantaggi:

• analisi delle giacenze per defi-nire le azioni necessarie all’atti-vazione (se urgenti) in un unicoambiente integrato (JOE);

• certezza di elaborazione automa-tica degli ordini bloccati percarenza di rete a fronte di incre-menti in analogia con l’automati-smo presente per gli ordini pro-gettati con successo (SAM).



matica (in errore) su UNICA èdel 5 per cento mentre suCPC è del 5 per cento (dati disettembre 2003).

Le aree di ulterioremiglioramento della solu-zione in esercizio sono rela-tive al processo di verifica ericonciliazione tra i dati pre-senti in rete e quelli disponi-bili nell’archivio di rete (pro-cesso di audit) ed alla ridu-zione dei tempi di ripristinodegli ordini bloccati.

In merito al processo diaudit è in esercizio un pro-cesso di allineamento deidati di UNICA tramite CPCdalla rete, in modo da garan-tire il successo della realizza-zione in rete (deliver y) diCPC del provisioning diUNICA. Questo processo hadecisamente migliorato lapercentuale di successo deldelivery, ma sono in essereazioni tese a integrare com-pletamente i due sistemiUNICA e CPC per miglioraree standardizzare le soluzioniadottate con impatti indirettianche sull’architettura dellapiattaforma per la compo-nente di controllo di pro-cesso, denominato OM(Order Manager).

Per ridurre i tempi rela-tivi agli ordini bloccati ,occorre intervenire solo suglistrumenti di indagine disponibili agli analisti per-ché la soluzione è one botton restart e il ritardodipende quindi solo dall’individuazione dei motividell’errore. Sono stati, perciò, già realizzati diversiinterventi e altri sono in essere; tutti gli interventimigliorativi sono il risultato della continua verificain campo della soluzione adottata.

5. Estensione della piattaforma di gestione dalle reti e dai servizi a larga banda alle reti outsourcing e Intranet

La piattaforma è risultata essere una soluzionevalida anche per la gestione delle reti outsourcing eIntranet. Questa estensione ha creato i presuppostiper una gestione integrata delle reti presenti inTelecom Italia e ha fatto nascere la necessità distandardizzare le soluzioni adottate per esportarlein contesti diversi e di preservare solo le caratteri-stiche specifiche non esportabili, gestendole nelmedesimo ambiente.

A titolo di esempio nell’ambito delle rete out-sourcing e a larga banda, il sistema UNICA ha messoa fattor comune: la base dati, il modello logico dei

dati ampliandolo sia in termini di nomenclatura(naming) sia di rappresentazione degli elementicomuni (il modello fisico diventerà comune nellafase di integrazione dei dati delle varie reti), lalogica dell’ambiente operativo integrato (JOE) el’ambiente Web di consultazione. In questo ambitoUNICA ha preservato le rispettive specificità: inJOE l’entità principale è la domanda commercialeper la larga banda e il router per l’outsourcing, l’am-biente Web (WebCustomer) per i clienti della reteoutsourcing è dedicato e configurabile in funzionedelle loro diverse esigenze.

La piattaforma di gestione delle reti outsourcingrealizza i processi di service delivery, audit, service assu-rance, trouble e di controllo della qualità del servizio.

Il processo di service delivery prevede l’inseri-mento manuale in UNICA solo dei dati non pre-senti in rete degli apparati (anagrafica dei router) eil completamento dei dati presenti in rete tramitela funzionalità discovery; tale funzionalità, attivatadalla richiesta di presa in carico effettuata inUNICA verso THOR (Topologic Hierarchic ObjectRetriever), “legge” i dati in rete dall’apparatoappena lo rileva. A valle della fase di discovery i datidi apparato sono convalidati dagli altri sistemi:


Wholesale

CRM

CDN-CVP

TIBCO

Pitagora(Special)

OrderManager

TIRKS

GAT

CPC

Configurazionedegli apparati

UNICA/D

Progettazione& inventory

WRAP, WFM


DAI


xDSL

CDN/CVPCPCCRMDAIGAT

TIRKSUNICA/D

WFMWRAPxDSL

==========

Circuiti Diretti Numerici - Canale Virtuale PermanenteCisco Provisioning CenterCustomer Relationship ManagementDelivery Assistenza ImpresaGestione Automatata TrasmissioneTrunk Integrated Record Keeping SystemUnique Network Inventory Co-operating Automatisms/DatiWork Force ManagementWork Request Automatism Producerx Digital Subscriber Line

Figura 2 Architettura sistemistica per il provisioning dell’accesso xDSL.



NNM (Network NodeManager) , DNS (DomainName Server), CW2K (CiscoWorks 2000) e CONCORD,della piattaforma e sono, poi,acquisiti da UNICA; sono,successivamente, generatiautomaticamente in UNICA icollegamenti di interconnes-sione tra i diversi apparati.

I l processo di audit , afronte di differenze in retedella consistenza del clientesia per apparati non noti (ondemand update) sia per varia-zione di dati su apparati giànoti (network automaticupdate), evidenzia in UNICAqueste variazioni, per con-sentirne l’acquisizione o ilrifiuto da parte dell’opera-tore; nel primo caso (presa incarico) si attiva il processoprecedente (per apparatinon noti).

Il processo di service assu-rance [2] consente la gestionecompleta - mediante isistemi CIC (Cisco InformationCenter) e NNM - della super-visione (sur veillance) suidomini della rete dati inmodo proattiva e reattiva inpresenza di allarmi.

Il processo di trouble per-mette di gestire in manieraintegrata i guasti, TTM (Trouble Ticket Management)sulla base dei reclami.

Il processo di controllo della qualità del servizio [2]consente la verifica, mediante i l sistemaCONCORD, della qualità fornita al cliente mediantela raccolta e le elaborazioni delle misure di traffico edelle prestazioni (performance).

La figura 3 mostra l’architettura sistemisticadella piattaforma per la gestione delle reti outsour-cing in esercizio da ottobre del 2003. La presenzadel bus di comunicazione TIBCO consente di elimi-nare le interfacce dirette (peer-to-peer) per una partedei sistemi presenti (linee continue sul bus).

La piattaforma di gestione delle reti Intranetrealizza i processi di network creation, service delivery,audit, service assurance, trouble, controllo della qua-lità del servizio e network capacity planning.

Il processo di network creation prevede l’inseri-mento manuale in UNICA solo dei dati di anagraficadegli apparati (router) e il completamento degli altridati previsti tramite discovery in rete; questa funzio-nalità è attivata dalla richiesta di presa in caricoeffettuata in UNICA verso THOR. A valle dell’ac-quisizione dei dati in UNICA, CPC acquisisce dalbus i dati di interesse.

Il processo di service delivery prevede l’inseri-mento manuale in CPC dei dati delle VPN (VirtualPrivate Network) per i servizi MPLS (MultiProtocol

Label Switching) e, successivamente all’attuazionedei servizi in rete, UNICA acquisisce via bus i datid’interesse.

Il processo di audit, a fronte di differenze in retedella consistenza sia per apparati non noti sia pervariazione di dati su apparati già noti, consiste nelmostrare in UNICA tali variazioni per consentirnel’acquisizione o il rifiuto da parte dell’operatore; nelcaso di acquisizione (presa in carico) si attiva il pro-cesso di network creation. Il processo di audit pre-vede anche la discovery dei servizi da parte di CPC(Cisco Provisioning Center) con il riallineamento inUNICA dei dati relativi ai servizi via bus.

I processi di service assurance, trouble e di controllodella qualità del servizio sono gestiti analogamenteall’applicazione outsourcing della piattaforma: congli stessi sistemi, tranne che per la qualità del ser-vizio che è gestita con STM (Sodalia Traff icManager) [2].

Il processo di network capacity planning [2] con-sente, mediante i sistemi STM, UNICA e DATI-PLAN (DATI PLANning), l ’analisi predittivamediante l’utilizzo di indicatori di prestazioni(performance) e della informazioni (report) integrate;a valle di tale analisi sono fornite le esigenze infra-strutturali di sviluppo di nuovi elementi di reteattraverso i sistemi DATIPLAN e ARES (ArchivioREti Speciali).

Service Delivery LAYER CENTRALE

Fault management

CIC

Impact

UNICA/D

TTM

Trouble ticket

Customer network inventory

Network Cliente

Probe NNM

LAYER PERIFERICO

NNM(Smile)

DNS(Smile)

THOR(Smile)

CONCORD(Smile)

CW2K(Smile)

Faultmanagement

Faultmanagement

Status &configuration polling

Performancemanagement

Configurationmanagement

CICCW2K

DNSNNM

THORTIRKS

TTMUNICA/D

========

Cisco Information CenterCisco Work 2000Domain Name ServerNetwork Node ManagerTopologic Hierarchic Object RetrieverTrunk Integrated Record Keeping SystemTrouble Ticket ManagementUnique Network Inventory Co-operating Automatisms/Dati

TIBCO

Figura 3 Architettura sistemistica per la gestione delle reti outsourcing.



La figura 4 presenta l’architettura sistemisticadella piattaforma per la gestione delle reti Intranetin esercizio da ottobre del 2003. La presenza delbus di comunicazione TIBCO consente di eliminarele interfacce dirette (peer-to-peer) per una parte deisistemi; le linee sono, infatti,continue sul bus.

Al momento (ottobre 2003)il numero di apparati gestitoper la componente outsourcingè di 43mila router, mentre perla componente Intranet è di9250 router.

In entrambe le applica-zioni - outsourcing e Intranet -della piattaforma di gestioneil ruolo del data base èancora una volta strategicoper i processi gestiti . Inentrambi i casi è stato utiliz-zato sempre UNICA comedata layer per garantire, afronte dell’allineamento coni dati di rete, la diffusionedello stesso allineamento,tramite la piattaforma, a tuttii sistemi interessati .L’automatismo non è ancoracompleto in quanto debbonoancora essere effettuatealcune operazioni di configu-razione manuale su alcunisistemi (NNM, CW2K, …) egiacché sono impiegateinterfacce dedicate per altrisistemi (TTM, DATI-PLAN,…).

La principale area dimiglioramento per entrambele applicazioni della piat-taforma riguarda la possibi-lità di rendere massimo l’uti-lizzo del bus di comunica-zione tra i sistemi per sostituire le interfacce peer-to-peer esistenti che richiedono riallineamenti dedicati.

6. Evoluzione della piattaforma di gestione verso le Reti PDH/SDH e la rete di accesso

Dopo aver verificato la flessibilità e l’adattabilitàdella piattaforma di gestione in contesti di retidiverse è stato naturale estendere la stessa architet-tura ai contesti di rete di trasporto PDH e SDH eall’accesso con l’obiettivo “storico” di sostituire conun unico data layer i sistemi TIRKS e GAT eACL/RR, cioè almeno trenta anni complessivi di sto-ria degli archivi dei dati di rete (network inventory)di Telecom Italia.

A tale scopo sono partiti due progetti parallelidenominati “Oltre TIRKS” ed “Oltre RR” con loscopo di analizzare la fattibilità dell’operazione, diindividuare per ogni ambito di rete la strategia di

sostituzione e specificare i nuovi sistemi da inse-rire in piattaforma (si vedano i due riquadri riportatia pagina 72).

L’evoluzione della piattaforma in tali contesti ha

preservato le linee guida definite sistemi phaseoriented e non verticali. Quest’attività non ha richie-sto una traslazione (porting) in una nuova tecnologiadelle funzionalità dei sistemi in oggetto, bensì un’a-deguata allocazione di queste prestazioni, relativeall’intero insieme dei processi aziendali, nei diversisistemi della piattaforma.

6. 1 Progetto “Oltre TIRKS”

Le analisi effettuate hanno portato a una strate-gia di sostituzione che si articola in quattro fasi:• isolare: tramite NSD effettuare l’isolamento di

TIRKS e GAT per ridurre il numero di sistemiinteressati alle fasi successive;

• sostituire: procedere alla sostituzione di TIRKS e GATtramite la componente T (Trasporto) di UNICA;

• automatizzare: realizzare la componente di serviceautomation di UNICA/T per gli ordini relativi allarete trasmissiva;

Service Delivery Provisioning Infrastrutturale

Capacity planning

DATIPLAN

Impact

CIC STM

Probe NNM

LAYER CENTRALE

LAYER PERIFERICO

Performance &SLA managementFault

management

ARESlink

MPLS configuration

CPC

LIDO

UNICA/D

TTM

Intranet

Trouble Ticket

Customer networkinventory

IDCNNM(Smile)

THOR(Smile)

DNS(Smile)

COSMOS

Planet INFO41

CRMx

Status polling (liv. 2)& measure collection

Status (liv. 3)& event polling

Configurationpolling

Faultmanagement

Configurationmanagement

ARESCIC

CPCCRMx

DATIPLANDNSIDC

LIDONNMSLA

THORTTM

UNICA/D

=============

Archivio REti SpecialiCisco Information CenterCisco Provisioning CenterCustomer Relationship Management xDATI PLANingDomain Name ServerIPnet Data CollectorLivello Integrato Dati OperazionaliNetwork Node ManagerService Level AgreementTopologic Hierarchic Object RetrieverTrouble Ticket ManagementUnique Network Inventory Co-operating Automatisms/Dati

as is

to be

TIBCO

Figura 4 Architettura sistemistica per la gestione delle reti Intranet.



• integrare: attuare l’integrazione di dati di tutte lecomponenti (T, D e RA) di UNICA per ottenereun unico data layer.

Nella fase isolare, la piattaforma si estende conl’inserimento del sistema GATEWAY e con l’amplia-mento delle funzionalità del sistema WRAP,entrambi collegati via TIBCO alla piattaforma.

Il sistema GATEWAY gestisce il deliver y siaverso il sistema SGSDH/NM per la rete SDH, siaverso SGF per la rete a maglia degli apparati RED4-4.

Il sistema WRAP gestisce, in questa fase, anchele richieste di permuta e di collaudo per i servizisulla rete trasmissiva SDH e PDH oltre che per iservizi xDSL.

Per entrambi i sistemi la soluzione è orientata aconsentire di svolgere tutte le attività, utilizzando

solo i sistemi GATEWAY e WRAP e non più GAT; intal modo tali sistemi, interfacciati a TIBCO, nonrisentiranno del cambiamento nella fase di transi-zione durante l’inserimento di UNICA/T.

La figura 5 presenta l’architettura sistemisticadella piattaforma per la fase isolare del progetto“Oltre TIRKS” in esercizio da ottobre di quest’anno.

Nella fase sostituire si allocano le prestazioni diTIRKS e GAT (secondo le linee guida) su diversisistemi; si introduce la componente T (Trasporto)del sistema UNICA per la gestione delle codifichedelle località, per il provisioning dei servizi in reteSDH e PDH e per il provisioning delle esigenzeinfrastrutturali.

Queste attività erano gestite, prima della fasesuddetta, r ispettivamente da SARA/IDB-RE(Sistema Acquisizione Richiesta Anagrafica/IntegrazioneData Base-REte), da TIRKS e dal modulo SCS(Scheduling Coordination System) di FEPS; SCS inol-trava anche la richiesta di incrementi delle infra-strutture, in base all’analisi dell’esigenza; nella fase

sostituire questo compito passa al sistema ART(Analisi della Rete di Trasporto) per la componenterelativa alla rete di trasporto PDH o SDH e alsistema ARES per quella ATM.

IL PROGETTO“OLTRE TIRKS”

Il progetto “Oltre Tirks” ha lo scopodi sostituire i sistemi TIRKS e GATcon un nuovo sistema chiamatoUNICA (Unique Network InventoryCo-operating Automatisms).

Il progetto si “salda” con il progettoNuova Piattaforma Sistemistica per lagestione della rete a larga banda(broadband) e costituisce la primaevoluzione verso tutte le reti gestiteda Telecom Italia.

La prima componente del progettoUNICA - chiamata UNICA/D - ha già

sostituito TIRKS/GAT e IDNM/SR,per la gestione del provisioning dellarete dati, e IDNM/SP, per lagestione della componente ATM(livello 2) e della componente IP(livello 3).

La seconda componente - chiamataUNICA/TD - è stata sviluppata persostituire TIRKS e GAT per lagestione della rete di trasporto SDHe PDH nel contesto della NuovaPiattaforma Sistemistica.

IL PROGETTO“OLTRE RR”

Il progetto “Oltre RR” persegue l’o-biettivo della sostituzione deisistemi ACL/RR, WebCAD, disegnidi Rete e l’archivio dell’accesso alarga banda ALBA con una nuovacomponente di UNICA chiamataUNICA/RA (Rete di Accesso).

Questo progetto costituisce un’ulte-riore evoluzione verso tutte le retigestite da Telecom Italia con il pro-getto Nuova Piattaforma Sistemisticaper la gestione della rete a largabanda (broadband).

Andando oltre e ampliando il puntodi vista anche alla gestione sistemi-stica della Rete di commutazione, èprevisto di realizzare successiva-mente la componente UNICA/RCper la gestione della Rete di com-mutazione, ultima fase pianificataper il progetto della nuova piat-taforma sistemistica relativa allagestione della reti di TelecomItalia.



Le attività di controllo del processo (ordertracking) svolte dal modulo GOC (Generic OrderControl) di TIRKS, nella fase sostituire, sono trasfe-rite al sistema OM (Order Manager).

Le attività di assurance, relative all’analisi dellasituazione in rete, mediante i dati forniti dalsistema GAT, sono allocate sul sistema LIDO (LivelloIntegrato Dati Operazionali) nel modulo LTR (LidoTransport Report).

Le attività di network creation di apparati e rac-cordi sono svolte da SIGRA/IT e WRAP (in prece-denza erano effettuate da SIGRA/IT e TIRKS/GAT)con l’acquisizione via bus in UNICA/T dei dati diinteresse: le attività realizzative per apparati e rac-cordi sono, quindi, attuate mediante l’invio alsistema WRAP delle relative richieste (work request).

Per quanto riguarda la piattaforma di gestione,come mostra la figura 6, nella fase sostituire sonoinseriti i sistemi: ART, ARES, LIDO e SIGRA/IT esono ampliate le attività del sistema WRAP. Lafigura 6 mostra l’architettura sistemistica della piat-taforma per la fase del progetto “Oltre TIRKS”.

La fase automatizzare massimizzail livello di automatismo del provi-sioning per migliorare i tempi diattraversamento della catena siste-mistica (linee guida). Questa faserichiede solo la realizzazione dellaservice automation in UNICA/T poi-ché la piattaforma è già automatiz-zata per le altre componenti.

La service automation è previstain due fasi: la prima richiede l’in-serimento manuale del ri lega-mento d’utente (local loop) ; laseconda consente l’individuazioneautomatica del percorso d’acceso,utilizzando l’integrazione tra lecomponenti della rete di accessoRA e del trasporto T (fase integra-zione). Il criterio seguito per l’auto-mazione della componente T èdescritto al punto successivo.

L’ultima fase integrare, del pro-getto “Oltre TIRKS”, mettendoassieme le componenti del datalayer (T e RA di UNICA), riduce almassimo i disallineamenti oggipresenti tra GAT ed ACL/RR suipercorsi di accesso. La disponibi-lità del data layer consente di rea-lizzare l’instradamento sul doppinodi abbonato direttamente in fase diprovisioning e non durante la rea-lizzazione (delivery); il completa-mento dell’instradamento nellafase successiva al provisioning è, almomento, la principale causa didisallineamento tra i dati.

6.2 Progetto “Oltre RR”

Le analisi effettuate hannodeterminato una strategia di sosti-

tuzione - analoga a quella del progetto “Oltre Tirks”- che si articola in tre fasi:• isolare - realizza, tramite l’allocazione su LIDO,

l’isolamento di tutti i sistemi che utilizzano idati di ACL/RR (ad esempio BDA, MK-Utenza,Toscanini, ACL-PS) per ridurre il numero disistemi interessati alle fasi successive;

• sostituire e automatizzare - procedere alla sostitu-zione di ACL-RR e di ALBA (Archivio LargaBAnda) tramite la componente RA di UNICA erealizzare la componente di service automation diUNICA/RA per la progettazione degli ordini rela-tivi alla fonia e all’ULL (Unbundling Local Loop);

• integrare - realizzare l’integrazione con la componenteT di UNICA in modo da completare la componentedi service automation per gli ordini del trasporto com-prensivi della terminazione d’utente (local loop).La fase isolare non utilizza la piattaforma, ma,

ereditandone il principio phase oriented, alloca sulsistema deputato LIDO (Livello Integrato DatiOperazionali) l’accesso ai dati di ACL/RR da partedei sistemi client. Tutti gli altri processi aziendali


ULL xDSL CDN OLO

NSD

TIRKSFEPS/SCS

GAT

LIDO GTW(SDH, SGF) WRAP, WFM DAI




ACL/RR

CDN

TLDPitagora(classic)CRMPitagora

(special)

ACL/RRCDNCRMDAI

FEPS/SCSGAT

GTWLIDONSDOLOSDHSGF

TIRKSTLDULL

WFMWRAPxDSL

==================

Automazione Centri di Lavoro/Registri di ReteCircuiti Diretti NumericiCustomer Relationship ManagementDelivery Assistenza ImpresaFacility Equipment Planning System/Scheduling Coordination SystemGestione Automatata TrasmissioneGaTeWayLivello Integrato Dati OperazionaliNetwork Service DeliveryOther Licensed OperatorSynchronous Digital HierarchySistema di Gestione FlussiTrunk Integrated Record Keeping SystemTelegestione Linee DedicateUnbundling Local LoopWork Force ManagementWork Request Automatism Producerx Digital Subscriber Line

TIBCO

Figura 5 Architettura sistemistica della fase “isolare” per il progetto “Oltre TIRKS”.



restano inalterati. La fase è in esercizio da ottobredi quest’anno.

Nella fase sostituire e automatizzare si allocano lefunzionalità di ACL/RR e di ALBA su sistemi adesse demandati. Si realizza un unico data layer per

la componente accesso (UNICA/RA); su questosistema si completano i dati di progettazione (atte-stazione coppie, attributi di protezione, …), si effet-tua il provisioning dei servizi di fonia e ULL insinergia con ACL/RC ed il provisioning dei serviziHFC. Queste stesse attività erano finora gestite,rispettivamente da: Disegno Rete e ACL/RR; ACL/RRe ACL/RC; ALBA.

Nella fase sostituire le attività di assurance, rela-tive all’analisi della situazione in rete mediante irendiconti (report) forniti dal sistema ACL/RR, sonoallocate sul sistema LIDO nel modulo LAR (LidoAccess Report), sulla componente grafica diUNICA/RA per una migliore usufruibilità delleinformazioni immagazzinate (ad esempio per manu-fatti e tubazioni) e sul sistema NavWeb impiegato

per attività quali , ad esempio, cambi coppia,gestione dei guasti, consultazione del numerotelefonico.

Nella fase sostituire il processo di realizzazionedella rete esterna (outdoor network creation) è gestito

dalla componente grafica diUNICA/RA ed è reso disponi-bile alla componente alfanu-merica quando il progettopassa in consistenza; è, così,possibile completare il pro-getto con i dati di dettaglioalfanumerici.

L’integrazione tra i datigrafici e quelli alfanumericinel data layer riduce al mas-simo i disallineamenti orapresenti nei sistemi DisegnoRete e ACL/RR.

Nell’ambito della piat-taforma di gestione (figura 7)nella fase sostituire e automa-tizzare si inseriscono: i lmodulo integratore (per TGU),i l modulo gateway (perACL/RC) e i l sistemaUNICA/RA, e si amplianoallo stesso tempo le attivitàdei sistemi: CRM, NSD,WRAP, DAI e LIDO.

La figura 7 presenta l’ar-chitettura sistemistica dellapiattaforma per la fase sosti-tuire e automatizzare del pro-getto “Oltre RR”. La figuramette in evidenza che il processodi provisioning per la fonia ègestito completamente dalla piat-taforma (CRM, integratore,UNICA/RA, gateway), mentre ilprocesso di delivery è parzial-mente gestito (solo per la compo-nente relativa ai sistemi WRAP,designer, DAI, NSD, CRM).

L’ultima fase, integrare,del progetto “Oltre RR” ècontestuale alla medesimafase del progetto “Oltre

TIRKS” e descritta al punto precedente.

7. La soluzione UNICA

Nell’ambito della definizione della piattaforma,l’esigenza di un data base flessibile e aperto versotutti i componenti della piattaforma e di un moduloconfigurabile per la realizzazione della service automa-tion hanno di fatto definito la soluzione UNICA.

In questo caso occorreva realizzare un archivio direte (network inventory) dotato di un modulo di pro-gettazione automatico, attivabile mediante richiestecommerciali interne o esterne, che potesse costi-tuire anche un supporto alla progettazione manuale(human-system oriented). Il modulo doveva seguire


ProvisioningInfrastrutturale

Link trasmissivi

Link BB

ART

ARES

Apparati

SIGRA/IT

ULL

Pitagora(Special) CRM

GTW(SDH, SGF) UNICA/TD CPC WRAP, WFM DAI LIDO


Progettazioneed inventory




Reportistica

SCF

OrderManager

Pitagora(Classic) TLD

xDSL CDN OLO CDN

ARESARTBB

CDNCPCCRMDAI

GTWLIDOOLOSDHSGF

SIGRA/ITTLDULL

WFMWRAP

UNICA/TDxDSL

===================

Archivio REti SpecialiAnalisi Rete di TrasportoBroadBandCircuiti Diretti NumericiCisco Provisioning CenterCustomer Relationship ManagementDelivery Assistenza ImpresaGaTeWayLivello Integrato Dati OperazionaliOther Licensed OperatorSynchronous Digital HierarchySistema di Gestione FlussiSistema Informativo GRAfico/Impianti TrasmissiviTelegestione Linee DedicateUnbundling Local LoopWork Force ManagementWork Request Automatism ProducerUnique Network Inventory Co-operating Automatisms/Trasporto e Datix Digital Subscriber Line

TIBCO

Figura 6 Architettura sistemistica della fase “sostituire” per il progetto “Oltre TIRKS”.



regole configurabili in funzione dei tipi di serviziorichiesti.

Nella figura 8 sono mostrati i moduli della solu-zione UNICA implementatiper realizzare tali requisiti.

Il data base è compostodalla componente dellerisorse fisiche e logiche(resource inventor y), dallacomponente per accoglierela richiesta commerciale (ser-vice inventory), dalla compo-nente di modellizzazione delservizio (service catalogue),dalla componente di defini-zione delle regole di instra-damento (provisioning rules) edei nodi di attraversamentopredisposti per ciascuna tec-nologia di rete (routing rules).

Le prestazioni disponibilisono le funzioni per configu-rare il catalogo servizi e leregole di progettazione (crea-tor); le funzioni per effet-tuare la progettazione afronte di una richiesta (desi-

gner) e le funzioni di upload(non presenti in figura) delleregole da seguire nell’attra-versamento della rete (rou-ting rules), fornite dai sistemidi pianificazione.

Sono eseguiti manual-mente l ’aggiornamentodelle regole di routing e laconfigurazione dei nuoviservizi e delle regole di pro-visioning.

In UNICA, a fronte di unarichiesta commerciale, siinnesca il processo di serviceautomation (descritto nelriquadro di pagina 76): aseguito dell’ordinativo i lmodulo di UNICA designermemorizza la domanda com-merciale nel service inventory,in funzione del tipo diordine e del tipo di richiesta(attivazione, cessazione, .…);individua dal service cataloguele azioni da compiere perevadere la richiesta; legge leregole di provisioning e di rou-ting e assegna, infine, le risorselogiche e fisiche presenti nellabase dati (resource inventory).

La logica implementataprevede che a ogni offertacommerciale è associato unprofilo di servizio. Ogniazione da compiere per cia-scun profilo di servizio rap-

presenta un singolo passo (work flow) del flusso pre-visto. Ogni passo è composto da logiche elaborativee da accessi ai dati (xflow).


ULL

Pitagora(Special) ACL/IA

SOC/F NSD

SCFProcesscontroller

Fonia Fonia non migrataReportistica

Mano d’opera dell’impresa

Mano d’opera sociale

Piano lavori

LIDO

DAI

WRAP/WFM

DESIGNER

UNICA/TD(Gateway)ACL/RCUNICA/RA


trasporto/dati

Configurazione delnumero telefonico


accesso

CRM TGU(Integratore)

ACL/IAACL/RC

CRMDAI

LIDONSDSCF

SOC/FTGU

UNICA/RAUNICA/TD

ULLWFM

WRAP

==============

Automazione Centri di Lavoro/Impianti AbbonatoAutomazione Centri di Lavoro/Registri di CentraleCustomer Relationship ManagementDelivery Assistenza ImpresaLivello Integrato Dati OperazionaliNetwork Service DeliverySistema Controllo FlussiService Order Control/FoniaTele Gestione UtenzaUnique Network Inventory Co-operating Automatisms/Rete di AccessoUnique Network Inventory Co-operating Automatisms/Trasporto e DatiUnbundling Local LoopWork Force ManagementWork Request Automatism Producer

TIBCO

Figura 7 Architettura sistemistica del progetto “Oltre ACL/RR”.

Service ConfigurationEnvironment

Service ProvisioningEnvironment

Provisioningrules

Routingrules

Servicecatalogue Resource

inventoryService

inventory

• Order Type• Action Type• Flow Through

CR

EA

TO

R

DE

SIG

NE

R

Figura 8 Componenti della soluzione UNICA.



Oltre all’introduzione della flessibilità all’in-terno della service automation, un altro elementostrategico della soluzione è la modellizzazione deidati relativi alla rete gestita. La scelta nella model-lizzazione delle risorse logiche e dei servizi è stataorientata verso la separazione delle offerte commer-ciali dalla predisposizione del servizio in rete.Infatti, quest’ultima implementazione ha pilotato lamodellizzazione delle risorse logiche che rappre-sentano le componenti realizzate in rete a fronte diun determinato tipo di servizio: la modellizzazionedei servizi è stata guidata dalle offerte commerciali.

Quella delle risorse fisiche è stata guidata dallanetwork creation.

A fronte di n servizi sono stati così realizzati mprofili (con m<n) realizzando il primo livello di flessi-bilità (il profilo corrisponde al servizio in rete). Afronte di un profilo sono stati individuati i varipassi (work flow e xflow) dipendenti dalla modelliz-zazione delle risorse logiche (servizio in rete). Ipassi prevedono la valorizzazione on demand deiparametri necessari alla realizzazione del servizio(secondo livello di flessibilità); in tal modo il numerodei passi da implementare è molto inferiore

PROGETTAZIONEDI UN SERVIZIOUTENTE-UTENTE

Un esempio di service automation integrata tra UNICA/TD e RA

• Inserimento in UNICA dellarichiesta di servizio (fornita daOrder Manager).

• Attivazione della richiesta aUNICA/RA del percorso diaccesso in A-A’/Z-Z’ sulla basedell’indirizzo e del civico e asso-ciazione al servizio.

• In assenza del “percorso” diaccesso, inserimento di esso inUNICA/RA.

• Attivazione del processo di auto-routing di UNICA/TD per laricerca dei percorsi possibili traA’ e Z’ (forniti da RA) e presen-tazione della lista all’operatore.

• Scelta dell’operatore del per-corso idoneo.

• Attivazione in UNICA/TD delcontrollo di continuità elettrica,presentazione della lista dei rac-cordi da selezionare e segnala-zione della mancanza di conti-nuità elettrica

• Scelta dell’operatore dei rac-cordi idonei e inserimento daSIGRA/IT degli eventuali rac-cordi mancanti.

• Attivazione in UNICA/TD delcontrollo di continuità elettrica eiterazione delle attività 6) e 7)fino alla completa continuitàelettrica.

• Distribuzione verso i sistemidella catena di provisioning.

Nella tabella A sono riportate letipologie dei servizi gestiti nella retedi trasporto.

Tipologia di servizio Sistema mittente

OLO1 - OLO1OLO1 - OLO2 Pitagora

Utente - Utente Pitagora

RPVD

Utente - OLO1 Pitagora

Interconnessione Pitagora

Fattibilità

X

X

X

X

X

Attività Cliente

X

X

X

Passi

Tutti tranne 2 e 3

Tutti

Infrastrutturali ART/ARES Tutti tranne 2 e 3

Tutti

Tutti tranne 2 e 3

Punto-multipunto/Punto-punto

TLD (V<64 kbit/s no START)TLD (V<64 kbit/s START)

X X Tutti tranne 2 e 3

TuttiTutti tranne 2 e 3

TLD (V<64 kbit/s no START)TLD (V<64 kbit/s START)

ARESARTOLO

RPVDTLD

=====

Archivio REti SpecialiAnalisi Rete di TrasportoOther Licensed OperatorReti Private Virtuali DatiTelegestione Linee Dedicate

Tabella A Matrice di sintesi del flusso di service automation, integrata traUNICA/TD e RA.

UNICA/RA UNICA/RA

ZA

Percorso accesso(Local Loop)

Percorso accesso(Local Loop)

Sede cliente A(Centrale di attestazione)

Sede cliente Z(Centrale di attestazione)

UNICA/T

RETETRASMISSIVA

UNICA/RAUNICA/T

==

Unique Network Inventory Co-operating Automatism/Rete di AccessoUnique Network Inventory Co-operating Automatism/Trasporto

Figura A Servizio utente-utente.



rispetto a quello dei profili o dei servizi in rete. Se,ad esempio, più servizi richiedono un accesso adapparati diversi, impostando in base alla richiesta ivalori relativi al tipo di apparato, alla porta e allacaratteristica (facility) di accesso, si effettua un solopasso, invece, di eseguire più passi dedicati al tipodi servizio richiesto.

La scelta nella modellizzazione rende il datalayer costituito da due parti fisicamente distintema integrate: una copre le funzioni di service e cata-log inventory; l’altra soddisfa le esigenze di resourceinventory. Si riduce, così, l’impatto conseguentealle nuove esigenze di modello legate ad altretipologie di rete e si ottiene la flessibilità necessa-ria per rendere la soluzione UNICA esportabile indifferenti contesti di rete: larga banda, TDM(includendo la componente in rame della rete diaccesso), il trasporto SDH e DWDM, l’Intranet,l’outsourcing.

Per garantire la condivisione del modello infor-mativo, la soluzione UNICA ha sfruttato in tutte leapplicazioni della piattaforma in esercizio (largabanda, Intranet e outsourcing) le potenzialità delmiddleware TIBCO per la comunicazione fra gliapplicativi, per la transcodifica di formato fra i datie, anche, per l’allineamento reciproco dei data baselocali e di quelli del data layer a fronte di operazionidi aggiornamento.

Il meccanismo di allineamento via bus nel pro-cesso di audit è stato l’elemento fondamentale permigliorare la qualità dei dati presenti in UNICA; ilprocesso di audit, sia per richieste puntuali sia percampagne di verifica, consente, infatti, di mante-nere allineati i dati del data layer con quelli presentiin rete, in modo da ottenere e mantenere un’elevataqualità dei dati immagazzinati.

Il prodotto di mercato utilizzato per la realizza-zione del progetto UNICA è il prodotto XPERCOMdi Granite Systems. Esso descrive la rete di teleco-municazione (nodi e collegamenti) mediante seiclassi di oggetti (siti, apparati, segmenti, collega-menti, cavi, clienti) e consente le opportune perso-nalizzazioni mediante l’introduzione di attributi online (user defined attributes) o la caratterizzazione dioggetti (user defined classes) già predisposti; nel database sono presenti pochi vincoli ed essi sono indi-pendenti dalle applicazioni (data base aperta e fles-sibile).

XPERCOM (versione Xng) nella soluzioneUNICA ha fornito il data base e le funzionalitànecessarie per la gestione (componente client) eper la consultazione Web (XngWeb). Per raggiungeregli obiettivi assegnati a UNICA il prodotto XPER-COM è stato arricchito da moduli: JOE, SAM eWebCustomer (indicati precedentemente). L’insiemedi queste componenti rappresenta la soluzioneUNICA per il provisioning delle reti di TelecomItalia nell’ambito della nuova piattaforma digestione.

La soluzione UNICA , anche disponendo diun’ambiente Web-based nativo (XngWeb), non ne pre-vede l’utilizzo come ambiente di data query & repor-ting della piattaforma perché le funzionalità diaccesso di navigazione e di reporting di questo

ambiente sono utilizzate solo nell’ambito delle atti-vità di provisioning (in accordo con il principio phaseoriented), mentre l’ambiente di operational data sto-rage della piattaforma è esterno al data layer ed èindividuato nel sistema LIDO. Il sistema è alimen-tato mediante il bus TIBCO con i dati presenti neldata layer ed è utilizzato da tutte le funzioni azien-dali che hanno necessità di informazioni relative aiservizi ed alle risorse disponibili in rete.

8. Evoluzioni future

Oltre alle aree di miglioramento già analizzate,sono allo studio altre evoluzioni della piattaforma,orientate a due linee di potenziale sviluppo: esten-sioni ad altri domini o contesti e, in secondo luogo,spinta verso la massima integrazione tra le varieistanze presenti. Il data layer eredita queste evolu-zioni e aggiunge a queste esigenze l’estensione del-l’obiettivo della qualità dei dati in tutte le applica-zioni della piattaforma.

La soluzione di piattaforma si presta sia a possi-bili estensioni ad altri domini di rete e sia - per lasua portabilità - a contesti simili extranazionali.

Per quanto riguarda altri campi di gestione èstato deciso di portare nel contesto di piattaforma ildominio di commutazione. Sarà, perciò, necessario(linee guida) allocare nell’ambito della piattaformale funzionalità oggi realizzate con la catena sistemi-stica in esercizio e, in particolare, con il sistemaACL/RC previsto per la gestione della rete di com-mutazione. Il sistema, che sostituirà l’attuale archi-vio della rete di commutazione ACL/RC e le relativecaratteristiche di gestione, sempre in una logicaphase oriented, sarà UNICA/RC.

Il data layer si completa, quindi, con l’integra-zione della rete di commutazione con le altre com-ponenti (TD e RA) concludendo così l’attività diinnovazione degli archivi di rete, che costituisce unaltro obiettivo della piattaforma, mediante la solu-zione UNICA.

In merito all’estensione in contesti extranazio-nali, è stato avviato l’adattamento della piat-taforma nell’ambito del progetto operatore euro-peo per la Francia (dove è già operativo), perl’Olanda e la Germania per la gestione della retedi commutazione, per la rete a larga banda e per iltrasporto e per i servizi di fonia e di larga banda. Iprocessi gestiti sono quelli di commercializzazione,delivery, assurance e creation; il data layer utilizzato èUNICA.

Un altro obiettivo riguarda l’opportunità di ren-dere massimo il livello di integrazione per le diffe-renti applicazioni (outsourcing, Intranet, larga banda,trasporto, accesso, commutazione) della piattaformain modo da evitare di dover riaffrontare le proble-matiche risolte nell’ambito di una singola applica-zione nel caso di processi operativi trasversali a piùapplicazioni. Occorre, infatti, superare l’attualelimite delle applicazioni isolate (stand alone).

Richieste in tal senso sono già evidenti: l’inte-grazione, ad esempio, per la componente di provi-sioning tra le applicazioni della piattaforma outsour-



cing e quella per la larga banda, al fine di garantireun processo di fornitura del servizio per i clientioutsourcing completamente integrato e monitorabileda estremo a estremo (end-to-end). Questa richiestacomporta l’integrazione nel data layer dei dati pre-senti, rafforzando ancora di più l’esigenza di unostrato dati unico per le reti gestite.

Le attuali soluzioni (ottobre del 2003) richie-dono allineamenti opportuni e dedicati per i datirelativi alle diverse applicazioni della piattaforma. Èperciò necessario superare questo limite, cioè pas-sare da applicazioni isolate della piattaforma a unaloro integrazione a spirale. In questo modo sonomesse a fattor comune tutte le componenti dellediverse applicazioni (nucleo) e sono preservate lesingole specificità (bracci) non integrabili.

In merito all’obiettivo della qualità dei dati - l’e-lemento centrale per il data layer e per la piat-taforma - sarà necessario estendere il processo diaudit alle nuove applicazioni, utilizzando i prodottidi mercato COTS (Commercial Off The Shelf) che,effettuando discovery di rete, consentano di metterein evidenza le differenze esistenti tra il contenutodell’archivio di rete e la reale situazione presente inrete. Sarà, infatti, possibile avere evidenza ed effet-tuare gli interventi di bonifica necessari al manteni-mento della qualità dei dati.

9. Conclusioni

Un tema più volte dibattuto riguarda la necessitàdi innovare le soluzioni tecnologiche impiegate nel-l’architettura sistemistica di supporto ai processi diprovisioning, delivery, assurance e creation.

Dopo la completa diffusione di TIRKS , inTelecom Italia si pose la necessitàdi far evolveretecnologicamente le logiche innovative di processointegrate, acquisite con questo sistema. Furonofatti alcuni tentativi (ALBA nell’ambito della“nuova piattaforma di rete” per la gestione del pro-getto per l’accesso Socrate (1995-96); ALBA nel-l’ambito del “progetto architetturale operativo” perla gestione delle reti per il trasporto SDH e PDH(1998). Erano, infatti, già chiare le esigenze didover andare oltre per fronteggiare le necessitàfuture, ma quelle soluzioni visionarie (secondo l’ac-cezione positiva corrente di tale termine) non tro-varono il consenso necessario.

Nel 2001 la piattaforma di gestione per la largabanda ha raccolto, come obiettivo iniziale, quelpatrimonio di idee, consolidato nel tempo, appli-candolo nel nuovo contesto di rete e ha rappresen-tato il punto di partenza per estendere la soluzioneai contesti di rete in cui tali idee erano inizialmentematurate.

Oggi è diffusa la convinzione che sistemi tec-nologicamente avanzati, uniti a un elevato tasso diautomatismo delle catene sistemistiche e all’uti-lizzo di piattaforme integrate, consentano di otti-mizzare il processo produttivo. I fattori fondamen-tali di successo per questo obiettivo sono l’integra-zione dei dati tra i processi aziendali e la qualitàdei dati.

Questi ultimi fattori - l’integrazione e la qualitàdei dati - rappresentano quotidianamente un obiet-tivo fondamentale, necessario per il raggiungimentodegli obiettivi di business nell’ambito di ogni pro-cesso operativo.

Conoscere sia la consistenza della rete per sti-mare il patrimonio aziendale, sia il livello di satu-razione della rete per fare interventi di amplia-menti mirati a tener bassi i costi di investimento,sia anche i “percorsi” liberi in rete per far ribalta-menti in caso di guasto, sono solo tre esempi per iquali è necessario avere a disposizione i dati intempo reale.

Nondimeno è fondamentale assicurare un ele-vato livello di qualità dei dati per evitare analisi econclusioni imprecise. Numerose sono state le cam-pagne di bonifica delle banche dati aziendali concosti non trascurabili; tuttavia, la qualità dei dati èprogressivamente degradata nel tempo. È stato,quindi, necessario avviare campagne periodiche diaggiornamento con i relativi costi.

Nell’ambito della piattaforma la soluzione aquesto problema è il processo di audit della retemediante prodotti che consentano di effettuarecampagne di monitoraggio o rilevamenti puntuali eche, al tempo stesso, aggiornino il data layer a frontedi modifiche della rete, dando evidenza agli opera-tori delle differenze via via rilevate.

La nuova piattaforma di gestione ha già rag-giunto per la rete a larga banda, outsourcing eIntranet gli obiettivi sia di integrazione dei dati traprocessi sia della qualità dei dati. Con essa si èavviata l’azione per raggiungerli nei restanti conte-sti di rete e per mantenere sotto costante osserva-zione la qualità dei dati in modo da evitarne qua-lunque degrado nel tempo.

[1] Orlando, S. ; Dragoni, L.; Bagnasco, E.:Evoluzione architetturale e tecnologica degliOSS. «Notiziario Tecnico Telecom Italia»,Anno 11, n. 2, settembre 2002, pp. 75-84.

[2] Orlando, S. ; Ior io , N. ; Pietropaolo, R. ;Pinnola, A.; Versini, R.: Gestione delle reti e deis er vizi broadband . «Notiziar io TecnicoTelecom Italia», Anno 11, n. 2, settembre2002, pp. 85-102.



Nicola Iorio si è laureato in IngegneriaElettronica presso il Politecnico di Torino. Hainiziato la sua attività presso lo CSELT (oggiTelecom Italia Lab) occupandosi dellagestione della rete e partecipando agliorganismi di standardizzazione in ambitoITU, ISO e TeleManagement Forum. È poipassato a operare nell’ambito dei Sistemidella Rete di Telecom Italia, dove haricoperto la responsabilità della FunzioneData Administration e successivamente

Sistemi di Delivery e Wholesale. Dalla fine del 1997 all’iniziodel 2000 ha operato per Telecom Italia allo start-up diRetevision in Spagna, come coordinatore dei Sistemi diGestione di Rete. Oggi è responsabile della Funzione Service &Network Provisioning & Delivery di Telecom Italia Information

Technology.

Domenico Castaldo si è laureato nel 1988 inFisica presso l’Università di Napoli. Nel 1989ha iniziato la sua attività in Telesoft (oggiTelecom Italia Information Techonology). Inquesta società si è occupato di data base per lereti di telecomunicazione e di sistemi diprovisioning di Telecom Italia, sia per progettinazionali (introduzione e diffusione di TIRKS,creazione del sistema ALBA nell’ambito dellarete Socrate) sia internazionali (ARDER per lepartecipate Retevision e Auna in Spagna). Dal

2000 opera nell’ambito dei Sistemi della Rete di Telecom Italia,dove ha assunto il ruolo di responsabile dello sviluppo dei sistemidi Service Provisioning delle reti PDH e SDH e ha curato ladefinizione dell’architettura sistemistica per la componente diservice provisioning e base dati della nuova piattaforma. In taleambito ha ideato la soluzione UNICA per il superamentoprogressivo dei network inventory; è ora responsabile anche delsistema UNICA di Service provisioning della rete Dati e cural’estensione della nuova piattaforma di gestione al contesto deiServizi PDH/SDH.

ACL/IA Automazione Centri di Lavoro/Impianti Abbonato

ACL/PS Automazione Centri di Lavoro/Prodotti e Servizi

ACL/RC Automazione Centri di Lavoro/Registri di Centrale

ACL/RR Automazione Centri di Lavoro/Registri di Rete

ALBA Archivio Larga BAndaARES Archivio REti SpecialiART Analisi Rete di TrasportoATM Asynchronous Transfer ModeBB BroadBandBDA Base Dati AziendaleCDN Circuiti Diretti NumericiCDN-CVP Circuiti Diretti Numerici per Canale

Virtuale PermanenteCIC Cisco Information CenterCOTS Commercial Off The ShelfCPC Cisco Provisioning CenterCRM Customer Relationship ManagementCRMx Customer Relationship Management xCVP Canale Virtuale PermanenteCW2K Cisco Works 2000DAI Delivery Assistenza ImpresaDATIPLAN DATI PLANningDNS Domain Name ServerDWDM Dense Wavelenght Division

MultiplexerFEPS/SCS Facility Equipment Planning System/

Scheduling Coordination SystemGAT Gestione Automatata TrasmissioneGOC Generic Order ControlGTW GaTeWayHFC Hybrid Fiber CoaxIBS InterBusiness ServicesIDB/RE Integrazione Data Base/REteIDC IPnet Data CollectorIDNM/SP Integrated Data Network Manager/

Service ProvisioningIDNM/SR Integrated Data Network Manager/

Servizi di ReteIP Internet ProtocolJOE Joint Operative EnvironmentLAR Lido Access ReportLIDO Livello Integrato Dati OperazionaliLTR Lido Transport ReportMPLS MultiProtocol Label SwitchingNNM Network Node ManagerNSD Network Service DeliveryOLBB Ordini di Lavoro BroadBandOLO Other Licensed OperatorOM Order ManagerPDH Plesynchronous Digital HierarchyRA Rete di AccessoRPVD Reti Private Virtuali DatiSAM Searching Automatic ModuleSARA Sistema Acquisizione Richiesta

Anagrafica

SCF Sistema Controllo FlussiSCS Scheduling Coordination SystemSDH Synchronous Digital HierarchySGF Sistema di Gestione FlussiSGSDH/NMSistema di Gestione SDH/Network

ManagerSIGRA/IT Sistema Informativo GRAfico/

Impianti TrasmissiviSOC/F Service Order Control/FoniaSLA Service Level AgreementSTM Sodalia Traffic ManagerT TrasportoTD Trasmissione DatiTLD Telegestione Linee DedicateTDM Time Division MultiplexerTGU Tele Gestione UtenzaTHOR Topologic Hierarchic Object RetrieverTIRKS Trunk Integrated Record Keeping

SystemTTM Trouble Ticket ManagementULL Unbundling Local LoopUNICA/D Unique Network Inventory Co-opera-

ting Automatisms/DatiUNICA/RA UNICA/Rete di AccessoUNICA/RC UINCA/Rete di CommutazioneUNICA/TD UNICA/Trasporto e DatiVPN Virtual Private NetworkWAD Wholesale ADSL DatacomWFM Work Force ManagementWRAP Work Request Automatism ProducerxDSL x Digital Subscriber Line

Unica

Documents

Transcript of Unica