La gestione delle nuove reti con un diverso paradigma

Transcript

1 ARCHITETTURE La gestione delle nuove reti con un diverso paradigma GIUSEPPE COVINO DANILO GOTTA ANTONIO NASUTO L innovazione a livello di rete-servizi richiede nuovi paradigmi gestionali capaci di offrire prestazioni e funzionalità di nuova generazione. I trend di mercato nella computer science promuovono soluzioni basate su un uso pervasivo dei principi della Oriented Architecture, sulla componentizzazione del software e sull Open Source. La gestione del prossimo futuro non potrà trascurare questi aspetti e Telecom Italia ha da poco avviato un intenso e sfidante piano di ammodernamento delle proprie architetture OSS che tengono conto da un lato dei trend tecnologici e dall altro degli obiettivi di semplificazione e razionalizzazione delle attuali implementazioni software. 1. Introduzione La necessità di una maggiore integrazione delle procedure gestionali ha spinto, nella seconda metà degli anni 80, i gestori di reti TLC a cooperare nell ambito degli organismi di normativa per la definizione di standard per la gestione delle reti. Si è venuta così a sviluppare in ambito ITU-T la tematica TMN (Telecommunication Management Network) con l obiettivo di definire gli standard per la gestione delle reti e dei servizi, nell ottica di un integrazione delle procedure gestionali in ambienti tecnologicamente eterogenei (multi-capability e multi-vendor). L architettura funzionale della TMN nel corso degli anni è evoluta individuando diversi livelli logici e sottosistemi funzionali per adattarsi a gestire la crescente complessità delle reti. Questo modello viene tuttora sovente rappresentato con una piramide, dove alla base c è la gestione degli elementi fisici della rete NML (Network Management Layer) e all apice la gestione degli aspetti di business BML (Business Management Layer). Questa rappresentazione, che per la verità in questa precisa caratterizzazione piramidale non si ritrova esplicitamente nelle Raccomandazioni ITU-T, ha avuto notevole diffusione sino ad essere identificata come il vero modello TMN. Il successo di questa figura è probabilmente dovuto alla capacità di evidenziare in modo semplice i singoli livelli nei quali dovevano essere svolte le funzionalità gestionali che miravano a coprire differenti ambiti e, nel contempo, di mettere in risalto l interrelazione tra i livelli. Infatti, il percorrere la piramide dall alto verso il basso metteva in evidenza i requisiti che il livello superiore imponeva al livello sottostante; mentre percorrerla dal basso verso l alto evidenziava le funzionalità che il livello inferiore era in grado di offrire al livello superiore. NOTIZIARIO TECNICO TELECOM ITALIA Anno 16 n. 1 - Aprile

2 process models Process Definition Tool TMN (Telecommunication Management Network) BUSINESS MANAGEMENT SERVICE MANAGEMENT NETWORK MANAGEMENT NETWORK ELEMENT MANAGEMENT NETWORK ELEMENTS FIGURA 1 Modello a piramide per la gestione degli anni 80 (ITU). Il modello TMN (figura 1), valido per gli albori della gestione, ha presentato nel corso degli anni 90 sino ai giorni nostri una serie di limiti e problematiche tra i quali: la proliferazione della numerosità delle interfacce punto-punto tra i diversi sistemi di gestione (a tutti i diversi livelli della piramide), la replicazione eccessiva delle logiche di archiviazione dei dati (stesse informazioni su applicazioni - sistemi distinti), la molteplicità dei criteri di accesso alle applicazioni con interfacce uomomacchina distinte per sistema a parità di processo. Inoltre, la crescente complessità delle reti e dei servizi offerti sta rendendo inadeguati i tradizionali sistemi di supporto alla gestione OSS (Operation Support Systems). Si è venuta così a concretizzare la necessità di ripensare alle architetture gestionali che nel corso degli ultimi anni ha condotto al consolidamento di un nuovo framework architetturale chiamato NGOSS (Next Generation Operation System and Software - del TMF, che partendo dalla TMN, ne evolve l architettura verso il superamento della tradizionale struttura piramidale. Lo scenario architetturale di gestione aderente ai requisiti NGOSS definisce l evoluzione dei sistemi OSS e delle tecnologie software per far fronte alla crescita a ritmi molto elevati del numero e dei volumi dei servizi, per sostenere la sempre maggiore complessità di reti ed apparati di telecomunicazione, per favorire l integrazione delle applicazioni best-in-class in modo il più possibile semplice, per rendere i sistemi facilmente scalabili, distribuibili e riconfigurabili per tenere il passo con scenari in continua e rapida evoluzione e per poter adattare velocemente le interazioni tra i sistemi per supportare le variazioni dei processi aziendali. Nella architettura NGOSS al livello massimo di astrazione, si possono distinguere i seguenti sei elementi essenziali (figura 2): 1. un infrastruttura di comunicazione (BUS) a cui tutte le componenti software si interfacciano, riducendo ad una l interfaccia per ogni OSS (è responsabile di recapitare i messaggi al destinatario di cui ogni componente non conosce la sua collocazione fisica); 2. una serie di FSC (Framework Component) ossia di componenti che offrono servizi a supporto della piattaforma, ad esempio la transazionalità, l autenticazione, il logging; 3. un repository che offre servizi di registrazione, dove ogni funzionalità disponibile è documentata. In questo modo i vari componenti non hanno necessità di conoscersi l uno l altro, rendendo possibile un basso accoppiamento e quindi un limitato costo di system integration (oggi tra le voci di investimento più consistenti per chi adotta architetture gestionali tradizionali); 4. una serie di BAC (Business Aware Component) ossia di componenti che svolgono le vere e proprie funzioni di business (es. di assurance, di provisioning, di traffic management); 5. un process engine che funge da orchestratore delle componenti e che è programmabile sulla Process Flow Engine BAC Business Aware Component FSC Framework Component OSS Operation Support Systems Process Flow BAC BAC BAC BAC Communications Technology s FSC FSC NG OSS TM Framework FSC FSC FSC FIGURA 2 Framework di riferimento per le architetture OSS evolute (TMF). Registries repository 28 NOTIZIARIO TECNICO TELECOM ITALIA Anno 16 n. 1 - Aprile 2007

3 Inventory Management Trouble Ticket Management Magazzini Field Access WorkForce Reporting Order Gateway Delivery & Hot Delivery Planning Inventory Reporting Design Trouble shooting Diagnosis BUS Network Assurance SQM Std services/ msg NMS Configuration Usage & Performance Correlation Assurance Testing Revenue Assurance progettazione +Activation NB e VAS Progettazione BB EM Marconi EM Siemens EM Alcatel CEM Ericsson CEM Alcatel CEM Italtel CEM Node EM Lucent MSEM MESM CGR FAMA SGSDH- NM Network BB CEM CGR DBR EM GEM GUI MOI Broad Band Centro Esercizio Manutenzione Centro Gestione RED Data Base di Rete Element Manager Gestione Materiali Graphic User Interface ManodOpera di Impresa MOS MSEM NB NMS SGSDH-NM SQM TTM VAS WFM ManodOpera Sociale Multi System Element Manager Narrow Band Network Management Systems SDH Network Management Quality Management Trouble Ticket Management Value Added s Work Force Management FIGURA 3 Architettura OSS convergente operativa in Telecom Italia. base delle caratteristiche dei singoli processi operativi; 6. l utilizzo di un modello informativo comune, ad esempio il SID (Shared Information Data model). L architettura NGOSS, ideata intorno al 2000, è stata precursore del paradigma SOA ( Oriented Architecture) che da un paio di anni è considerata la scelta di riferimento per le architetture gestionali a basso accoppiamento, con bus di comunicazione e con interazioni formalizzate con il meccanismo della registrazione dei servizi (publish-subscribe). Da ricordare che Telecom Italia ha adottato tale modello di riferimento, implementando la propria architettura di gestione per reti/servizi broadband proprio su una architettura NGOSS (ricevendo per questo a Dallas, il First Ever Operational Excellence Award internazionale, figura 3). L attuale architettura di gestione OSS è composta da uno strato di EM (Element Manager), fornite direttamente dai vendor di apparati di rete, da uno strato di OSS di livello 1 (dedicati all interazione verso la rete per supportare i processi di attivazione / configurazione, raccolta degli allarmi, gestione del traffico,...), da uno strato di OSS di livello 2 (gestione dei processi di provisioning, di diagnosi, di supervisione, di inventory, di work force) e da un BUS di orchestrazione delle applicazioni e da accessi da / verso i BSS. 2. Problemi nuovi e trend tecnologici attuali La domanda lecita che ci si pone, soprattutto a seguito di un award, è se esistono ancora dei margini di potenziamento dell attuale architettura di gestione di Telecom Italia, ovvero se l adozione della NGOSS ha e sta facendo emergere nuove problematiche che richiedono un nuovo salto generazionale di paradigma, cioè: Il problema della gestione proprietaria degli apparati di rete: nella situazione attuale, gli Element Manager sono sistemi proprietari dello stesso vendor dei nodi di rete e presentano interfacce proprietarie per l integrazione con gli OSS di livello 1. Questa situazione ha portato come conseguenza la necessità di adattare le funzioni di interfacciamento degli OSS verso tutti i tipi di EM con aggravio di costi di system integration e di segmentazione delle competenze. Lo snellimento indotto delle architetture NGOSS deve quindi anche ottemperare al principio di adozione di uno strato di mediazione tra apparati ed OSS che sia vendor-independet e governato dall operatore. Il problema dalle verticalizzazioni gestionali di livello superiore: la flessibilità introdotta dal paradigma NGOSS non ha risolto però il problema di replicazione delle funzionalità gestionali in ciascuno dei prodotti commerciali (spe- NOTIZIARIO TECNICO TELECOM ITALIA Anno 16 n. 1 - Aprile

4 cializzati sui singoli processi operativi) acquisiti e introdotti nell architettura OSS; questo aspetto genera la replicazione di funzioni simili per l interazione con la rete, funzioni che potrebbero essere messe a fattor comune in uno strato unico. Il problema del non coordinamento tra gli OSS: l assenza di un coordinamento nelle richieste tra gli OSS e la rete fa sì che non vi sia un utilizzo ottimale delle risorse computazionali degli apparati dedicati alla gestione, mancando uno strato di mediazione univoco capace quest ultimo di filtrare e normalizzare la pressione informatica sulla rete. Il problema dell allineamento tra configurazione reale della rete e dei servizi e quanto documentato negli (inventory): uno dei problemi che incidono maggiormento sulla corretta esecuzione dei singoli processi operativi è costituito dal parziale ma costante disallineamento tra vero installato in campo in termini di equipaggiamento apparati e servizi di rete configurati e le informazioni memorizzate negli inventory di rete-servizio-cliente. Una delle soluzioni per ridurre questo problema di allineamento è di operare con dati memorizzati il più possibile vicino alla rete, appunto in un layer di intermediazione, che sia capace di effettuare il discovery delle configurazioni e mantenerne l aggiornamento in tempo reale anche tramite ricezione delle notifiche di rete (trap ed eventi). In questo modo sarà possibile garantire la riconciliazione dei dati affinchè i processi d Delivery, Configuration, Assurance, Traffic e altri ancora possano chiudere con successo ogni singola transazione. Il trend sulla componentizzazione e flessibilità del software: consente alle aziende di progettare e rapidamente implementare complesse applicazioni anche in situazioni di continuo cambiamento tecnologico e di business. Tramite questo paradigma, si possono sviluppare, migliorare e rinnovare le applicazioni componente per componente e conseguentemente la gestione di questi continui aggiornamenti può avvenire con tempi rapidi e migliore testabilità, senza la necessità di dover intervenire ad ampio spettro su sistemi e applicazioni gestionali di precedente generazione (figura 4). Infatti, uno degli obiettivi più ambiziosi dell ingegneria del software è quello di organizzare la realizzazione di sistemi in modo analogo a quanto ormai predisposto in altri settori industriali, dove la presenza di un mercato di parti (componenti) standard riutilizzabili permette di aumentare la produttività, riducendone i costi. La filosofia dei componenti stà dando vita a due nuove figure di programmatori: il progettista di componenti e l assemblatore di applicazioni. Il primo ha il compito di identificare e progettare oggetti software di uso comune, che possano essere utilizzati con successo in contesti differenti (produttori in concorrenza tra di loro possono realizzare componenti compatibili, ma con caratteristiche prestazionali differenti, per cui l acquirente può così orientarsi su un mercato che offre una pluralità di scelte anche Open Source, e decidere in base al proprio spending e alle funzionalità disponibili). L assemblatore di applicazioni, d altra parte, è un professionista specializzato in un particolare dominio applicativo, capace di creare programmi complessi acquistando sul mercato componenti standard e combinandoli con opportuni strumenti e linguaggi di programmazione. Il trend della SOA: è uno stile architetturale basato sul concetto di servizio (procedure software), e definisce una modalità di costruzione delle applicazioni come composizione di servizi con caratteristiche ben specifiche orientate al riutilizzo e all integrazione. La SOA non è una rivoluzione, ma un evoluzione architetturale che investe tutti gli aspetti associati alla definizione di un OSS: architetturali, metodologici, processivi, organizzativi e tecnologici. La chiave innovativa della SOA è l indipendenza dei servizi, definiti da un interfaccia specifica (ad esempio tramite Web s), che possono essere orchestrati tramite un ESB (Enterpise Bus) per eseguire i propri compiti in un modo standard, senza che il servizio abbia conoscenza dell applicazione chiamante e Integrazione applicativa Ripartizione funzionale hw dedicato hw multi-cpu NGOSS hw a basso costo Mainframe AUTOMATION (Centralization, corporate rules) TMN CRM TTM PCAs* DISTRIBUTION (Decentralization, high end functional 1993 systems) tier Client/Server CRM Customer Relationship Management PCA Personal Communication Assistant NGOSS Next Generation Operation System and Software TMN Telecommunication Management Network TTM Trouble Ticket Management Enterprise s Architecture COMPOSITION (team-and knowledge driven corporation) FIGURA 4 La successione di snodi tecnologici dirompenti nel software e nell hardware. Adattività processiva hw in rete grid 2013 PARAMETRIZATION 30 NOTIZIARIO TECNICO TELECOM ITALIA Anno 16 n. 1 - Aprile 2007

5 senza che l applicazione abbia conoscenza, o necessiti di averne, del servizio che effettivamente eseguirà l operazione (figura 5). La validità di un architettura SOA è basata sui seguenti standard e principi: - Standard: per operare in ambienti multipiattaforma utilizzando interfacce basate su WSDL (Web s Description Language) con Web s Security; - Granularità: per trovare un equilibrio nella scomposizione di una applicazione in micro-servizi erogabili da ogni singola componente software, al fine di evitare di avere una elevata specializzazione (poca riusabilità) o una elevata generalizzazione (elevata numerosità); - Dorsale ESB per pubblicare e orchestrare i servizi, per autenticare ed autorizzare in sicurezza l uso delle componenti, per trasformare i dati da una applicazione mittente ad una destinataria e per supportare regole di business e capacità di monitorare gli SLA ( Level Agreement). Il trend del software ad agenti: sebbene la comunità scientifica ne discuta ormai da tempo, è solo dalla seconda metà degli anni 90 che ha cominciato a trovare riscontri applicativi pratici un nuovo paradigma di sviluppo software denominato Agent Oriented Programming (AOP). Tale paradigma nasce dalla fusione di alcuni concetti derivanti dagli studi sull intelligenza artificiale con la tecnologia degli oggetti informatici distribuiti e prevede la realizzazione di un applicazione software come collezione di componenti, dette appunto agenti, capaci di essere: - autonome, ossia svolgere task lunghi e complessi; - proattive, ossia prendere iniziative anche senza uno stimolo esplicito da parte di un utente; - comunicative, ossia interagire tra loro al fine di raggiungere l obiettivo globale della applicazione. Il modello architetturale di una applicazione realizzata con tecnologia ad agenti è intrinsecamente peer to peer in quanto ogni agente è potenzialmente in grado di iniziare una comunicazione con ogni altro agente nel sistema. Per sfruttare appieno le potenzialità della tecnologia ad agenti, varie aziende ICT hanno dato vita a FIPA (Foundation for Identification Specifications Realization decisions Output: realizzazione SOA User Presentation Business Processes s Components Existings Applications BPEL Business Process Execution Language ESB Enterprise Bus SOA Oriented Architecture Client ESB Engine BPEL 1 2 Intelligent Physical Agents - una iniziativa internazionale non-profit con l obbiettivo di produrre specifiche per l interoperabilità tra agenti realizzati da produttori diversi e con tecnologie diverse. Essendo focalizzate sugli aspetti di interoperabilità, le specifiche FIPA non trattano la struttura interna di un agente, ma definiscono un linguaggio di comunicazione tra gli agenti detto ACL (Agent Communication Language) che si fonda su un paradigma di scambio di messaggi asincrono basato sui nomi degli agenti e consente quindi legami laschi (loosely-coupled) tra le componenti del sistema (gli agenti). Nessuna dipendenza dagli indirizzi di trasporto, nessuna dipendenza temporale (il ricevitore di un messaggio potrebbe addirittura non esistere ancora al momento dell invio di un messaggio) e interfacce dichiarative consentono agli agenti di entrare/uscire dal sistema, trovarsi ed interconnettersi in modo dinamico trovando quindi riscontro negli aspetti chiave delle architetture di tipo SOA (figura 6). SOAP BC A B C FIGURA 5 Come predisporre soluzioni gestionali compatibili al paradigma SOA. A1 Prepara il messagio per A2 SE BPEL JSR181 SE Codice software JSR181 SE D Legge il messaggio dalla inbox e lo processa FIGURA 6 Schema di funzionamento di base della piattaforma ad agenti distribuiti Jade. A2 NOTIZIARIO TECNICO TELECOM ITALIA Anno 16 n. 1 - Aprile

6 3. Un disaccoppiatore neutrale e un assistente in linea I problemi riscontrati dalla adozione di soluzioni NGOSS tradizionali e le tendenze che sempre più promuovono modelli architetturali a componenti riusabili impongono quindi una rimodulazione di alcuni principi gestionali, che si riflettono anche in innovative scelte che Telecom Italia sta attuando e promuovendo a livello internazionale. Le azioni prevedono di: 1. Eliminare progressivamente la quantità e la tipologia degli EM introducendo una piattaforma Neutral Network EM (NNEM) capace di intermediare la rete con gli OSS di livello superiore in modalità multi-vendor e multi-domain di rete; 2. Lavorare con dati vicino alle applicazioni sfruttando al contempo logiche di riallineamento automatico verso gli inventory al fine di facilitare la predisposizione di applicazioni real time e di ridurre le eccezioni (e quindi di rilavorazioni manuali); 3. Utilizzare principi basati sulla Open Architecture (SOA) per la composizione e l orchestrazione dei nuovi processi per la gestione delle reti-servizi broadband; 4. Ridurre al minimo l introduzione di sistemi con proprie logiche interne (in genere cablate) di gestione processiva.; 5. Facilitare lo scambio informativo tra OSS e applicazioni di gestione delle operation, al fine di creare un continuum elaborativo in grado di assicurare correttezza nei dati e flessibilità negli interventi; 6. Adottare meccanismi di retroazione automatica/autonomica a tutti i livelli di gestione al fine di regolare le priorità di elaborazione dei vari processi sulla base di specifici SLA di business; 7. Abilitare l esecuzione delle applicazioni gestionali su infrastrutture Grid a basso costo; 8. Definire le entità oggetto di gestione (in particolare per la configurazione, la attivazione e la diagnosi) tramite modelli informativi standard affinchè il formato di una entità sia univocamente riconosciuta da qualsiasi applicazione indipendentemente dal processo operativo di riferimento. Le suddette azioni impongono quindi l introduzione di due nuove piattaforme elaborative, nel seguito chiamate rispettivamente WANTS e WIZARD, che attraverso l adozione del paradigma a componenti software dotate di propria intelligenza (espressa sotto forma di flussi procedurali semplici e leggeri tipo workflow) assegnabili in modo dinamico e senza fermo di sistema, su infrastrutture hardware fisicamente distribuite, sono in grado di attuare i principi cardini elencati, permettendo allo stesso tempo una considerevole contrazione dei tempi di system integration, di adeguamento funzionale e di completamento con successo dei processi di esercizio e manutenzione delle nuove reti (figura 7). 4. La piattaforma WANTS La soluzione Telecom Italia chiamata WANTS (Workflow and AgeNTS based platform) specifica una piattaforma ad alta flessibilità funzionale e scalabilità computazionale, basata su agenti software distribuiti con motori leggeri di workflow (ossia motori in grado di eseguire porzioni di processo ma dalle dimensioni così esigue di pochi kilobyte da poter essere eseguiti su qualsiasi sistema dotato di capacità elaborative, compresi i telefoni cellulari) e distribuibili su infrastrutture elaborative a bassissimo costo (blade workstation). L abbinamento tra agenti e worflow è risultato vantaggioso poiché permette di suddividere un processo di gestione in componenti elementari assegnando a ciascuno uno specifico compito (ad esempio la configurazione di particolari schede di un dato nodo di rete, la raccolta di segnalazioni di anomalia da un particolare DSLAM e così via) aumentando al contempo in modo significativo le prestazioni, grazie ad un infrastruttura dall alto parallelismo (migliaia di thread paralleli). Semplificando l architettura, si può supporre che esistano tanti agenti quanti sono potenzialmente i milioni di apparati di rete gestibili. Questi agenti svolgono le verie e proprie funzioni di FIGURA 7 Migrazione da un architettura NGOSS a quella innovativa di Telecom Italia. 32 NOTIZIARIO TECNICO TELECOM ITALIA Anno 16 n. 1 - Aprile 2007

7 OSS Workflow interno EM/NM by vendors EM ESB NNEM NM OSS SOA As-Is OSS Workflow interno mediazione intelligente di rete vendor-independent. Viene così a costituirsi un layer di intermediazione capace di crearsi una immagine di tutte le reti gestite: qualsiasi processo (e quindi OSS di livello superiore) non interagirà più direttamente con la rete ma con la sua immagine che, tramite criteri sofisticati di discovery e di ricostruzione delle configurazioni di nodo e di rete, sarà sempre allineata al vero installato (figura 8). Altri tipi di agenti, di livello gerarchicamente superiore, hanno il compito di coordinare gli agenti di mediation, in modo da fornire viste multi-dominio e svolgere funzioni di controllo. Infatti, oltre alle funzioni di mediation NNEM (in sostituzione degli EM per tutti i processi work-intensive, quali provisioning, assurance, troubleshooting, configuration management, performance,...), WANTS svolge funzioni proprie di OSS di livello 1, in particolare di attivazione dei servizi, di assurance (diagnosi dei guasti e ricezione degli allarmi) e di gestione delle configurazioni. Nell attuale versione di WANTS, tali funzioni sono state implementate per i DSLAM IP. Tutte le funzionalità, sia di mediation che di OSS di livello 1 sono fornite tramite le logiche programmabili a micro-workflow, che possono essere iniettati negli agent a runtime, consentendo di modificare il comportamento della piattaforma senza fermare il sistema. integration Local processing BUS di comunicazione EM/NM EM/NM Nodes Element Manager OSS Enterprise Bus Neutral Network EM Network Management Operation Support Systems Oriented Architecture Centralized Inventory OSS legacy NNEM Alligned Real Time Invetory To-Be Workflow esterno ESB di orchestrazione Nodes FIGURA 8 Confronto tra due realtà: NGOSS e gli OSS per gestire le esigenze del futuro. SOA WIZARD Storage I workflow sono scritti secondo lo standard internazionale XPDL ( mentre la mediazione di rete utilizza il modello informativo SID prodotto dal TeleManagementForum. Gli agenti (basati su soluzione opensource Java/JADE, in linea con le direttive FIPA) eseguono infatti workflow capaci di interagire con gli OSS e la rete in una modalità neutra rispetto al tipo di apparato (e quindi di vendor). Le caratteristiche principali di WANTS sono le seguenti (figura 9): architettura ad Agenti, organizzati su diversi livelli logici (consigliati un numero di tre: livello OSS Platform Agent Apple AA1 Master Apple MA1 PE 1 Agent Apple AA2 Creation & Control Environment SCCE PE 2 PE 2 Workflow Resource Proxy RP1 SID SID SID SID SID SID Resource Proxy RP1 PE 3 PE 3 PE 3 PE 3 Telnet adapter Resource Proxy RP2 Resource Proxy RPm Network Resource Proxy RP2 Resource Proxy RPm PE 3 PE 3 N_D1 N_D1 N_D1 N_D1 SNMP Telnet COP6A adapter adalpter adapter AA MDB OSS PE SCCE SID SNMP PE 1 PE 2 PE 3 MDB Agent application Model Data Base Operation Support Systems Process Engine Creation Control Environment Shared Information Data Simple Network Management Protocol FIGURA 9 Architettura funzionale della piattaforma WANTS. NOTIZIARIO TECNICO TELECOM ITALIA Anno 16 n. 1 - Aprile

8 di apparato, di rete e di servizio) per assicurare flessibilità (anche nella libera allocazione dei processi tra una modalità distribuita ed una centralizzata) e scalabilità delle funzioni, evitando al contempo la complessità di strutture troppo stratificate stile TMN. Ciò implica la definizione di un livello centralizzato (corrisponde ad uno o più Master Agent - MA), uno completamente distribuito (corrisponde agli Agent Application - AA) ed uno strato indipendente di RP (Resource Proxy) per il disaccopiamento della rete dalle funzioni gestionali e di controllo. Questa segmentazione fornisce anche diverse viste in base al livello di astrazione crescente (da RP a MA). ogni agente RP, oltre al disaccoppiamento, è responsabile anche della creazione, mantenimento e gestione della immagine (cache) della porzione di rete a lui assegnata e da lui gestita (può essere un singolo apparato oppure o una porzione di rete, ad esempio un dominio attestato ad un EM). L immagine è una rappresentazione della configurazione dell apparato secondo il modello informativo SID. interfacce verso OSS/BSS: moduli GW (Gateway), specializzati per processo, e deputati ad accettare comandi provenienti da OSS per l esecuzione funzionalità tramite micro workflow ed a restituire informazioni agli OSS/BSS (ad esempio allarmistica di rete) attraverso adattatori software che consentono al Gateway la comunicazione via protocolli di interfacciamento peer-to-peer o via Web s verso un BUS di comunicazione (nel caso di Telecom Italia ad esempio, il bus TIBCO). Creation & Control Environment (SCE): implementa le funzionalità per la creazione ed aggiornamento dei servizi gestionali forniti dalla piattaforma tramite disegno dei micro-workflow ed i moduli di controllo della piattaforma via Web. Un MDB (Model Data Base) memorizza tutte le descrizioni di workflow ed i modelli informativi delle informazioni trattate, sia relative agli apparati che ai servizi di rete, ad uso delle funzioni di disaccoppiamento degli RP. Il modulo ADEGUA (ADvancEd Global Usage Adaptive platform), realizza invece la funzionalità di governo elaborativo dell intera piattaforma hardware e software; dato che WANTS risulta una soluzione ad agenti distribuibili su infrastruttura hardware distribuita a basso costo, è necessario, tramite l utilizzo di speciali agenti detti Control Agent (CA), consentire alla piattaforma di adeguare ed adattare proattivamente e in tempo reale il proprio balancing computazionale attraverso l uso di algoritmi di autonomic computing. Il modulo è in grado di riallocare i processi eseguiti dai singoli agenti (a tutti i livelli) al variare delle priorità dei singoli processi operativi di Delivery, Assurance e Configuration gestiti (SLA che dipendono sia da concause momentanee che da nuove logiche di offerta) garantendo in questo modo l esecuzione ottimale di tutte le transazioni sia in caso di guasto/malfunzione della infrastruttura elaborativa che di down di sistema. Interfaccia verso i sistemi di rete (apparati, terminali e applicazioni): il PA (Protocol Adapter) è il modulo, all interno degli agenti RP, responsabile dell interfacciamento con la rete in base al protocollo gestionale offerto dagli apparati (es. SNMP, telnet, TL1). Ogni PA offre quindi, come servizi per i Resource Proxy, l esecuzione delle operazioni di base sull apparato (ad esempio nel caso di un SNMP, le operazioni di get e set). L architettura WANTS, su cui sono depositate diverse domande di brevetto Telecom Italia, così descritta permette di attivare un insieme di funzionalità di EM in grado di accogliere in unico strato di intermediazione le esecuzioni richieste da molti OSS distinti e afferenti a processi operativi di natura diversa tra loro La piattaforma WANTS per lo strato di intermediazione NNEM tra OSS e le nuove reti incorpora un primo insieme di funzionalità disponibili nella sua versione attualmente in esercizio per la attivazione e la configurazione dei nodi DSLAM IP multi vendor. La soluzione NNEM è in estensione funzionale affinchè possa essere adottata anche per i rimanenti processi gestionali (in particolare Fault, Trouble Shooting, Design e Configuration) applicabili al nuovo settore di rete di accesso NGN2 (figura 10). 5. La piattaforma WIZARD Se nel caso dello strato di disaccoppiamento NNEM, gli agenti equipaggiati a workflow permettono sia di istanziare una immagine virtuale della rete da gestire che di intermediare in modo semplice tutte le funzioni di comunicazione tra rete e OSS, nel caso della piattaforma WIZARD il medesimo principio può essere riutilizzato per far interagire in modo innovativo la rete e le applicazioni di gestione con i tecnici di Telecom Italia (sia essi residenti nei centri di help desk tecnico che infield). A tutti gli effetti la soluzione WANTS è un innovativo mediatore tra rete e OSS mentre WIZARD è un altrettanto innovativo mediatore tra persone, gli apparati della rete e l insieme delle applicazioni di supporto. In realtà l obiettivo dei WIZARD è da intendersi in una accezione molto più ampia, corrispondente a quella di aiutare le persone ad interagire con sistemi informatici e con l intero ambiente circostante. Gli ambiti di applicazione della piattaforma sono molteplici (figura 11): facilitare la comunicazione tra persone valorizzando l esperienza dei singoli; innescare un miglioramento continuo dei processi aziendali standardizzando le procedure operative senza ingessarle ma anzi rendendole esplicite e flessibili; orchestrare e riutilizzare servizi in vari contesti applicativi; fornire un interfaccia amichevole e guidata verso sistemi informatici, apparati e oggetti. 34 NOTIZIARIO TECNICO TELECOM ITALIA Anno 16 n. 1 - Aprile 2007

9 La piattaforma WIZARD consente di definire delle guide interattive (sulla falsariga dei Wizard windows di installazione) per procedure operative tramite un ambiente grafico di SCE ( Creation Environment, il medesimo adottato per WANTS) che consente di configurare dei workflow operativi (ad esempio le istruzioni di lavoro). In questo modo, delle procedure operative che richiedono sia interventi manuali che interventi su diversi OSS, sono tradotte in un formato comprensibile ad un assistente software (wizard) che non solo suggerisce le operazioni manuali da svolgere, ma si occupa del dialogo con i vari sistemi informatici automatizzando in questo modo e il più possibile un flusso processivo che oggi viene spesso delegato in modalità manuale alle singole persone. La soluzione FIGURA 10 Contesto di utilizzo dello strato NNEM basato su WANTS: dai DSLAM IP^alla NGN2. agente reattivo WANTS WIZARD agente agente autonomo agente robotico agente utile agente deliberativo agente intelligente agente mobile (intelligente, collaborativo) agente biologico artificial life agent agente collettivo... agente computazionale agente software virus agente (intelligente) collaborativo agente di interfaccia (intelligente, collaborativo) FIGURA 11 Gli agenti software come veicolatori di conoscenza e assistenza on line. WIZARD mette quindi a disposizione un ambiente per costruire applicazioni di supporto al personale tecnico, in cui la comunicazione tra persone e OSS (tra cui anche l NNEM) possa essere configurata tramite workflow: il punto caratterizzante è dovuto all interattività richiesta durante l esecuzione dei workflow, aggiungendo specifici agenti softawre JADE per l esecuzione di workflow interattivi e fruibili in modalità Web e direttamente su ufficio mobile dei tecnici (Nokia Communicator) (figura 12). L interazione guidata tra persone e sistemi informatici è importante in molti contesti: ad esempio i tecnici Telecom (in field o di back office) per la soluzione di problemi complessi richiedono spesso accesso a sistemi esterni, in cui la componente di interazione è fondamentale (risposta a quesiti, suggerimento di operazioni manuali da com- NOTIZIARIO TECNICO TELECOM ITALIA Anno 16 n. 1 - Aprile

10 FIGURA 12 La piattaforma WIZARD come soluzione per l assistenza ai tecnici di Telecom Italia. piere, ). Per questo motivo le componenti software fondamentali della piattaforma sono (figura 13): un agente WIZARD Gateway Agent (WGA), che svolge un ruolo di interfaccia fra la piattaforma e la console operativa. Questa console espone agli utente una serie di funzionalità che si traducono nell esecuzione di un workflow (es. cambio porta); un agente Gateway Agent (GW) che svolge il ruolo di interfaccia fra la piattaforma e la console Web di amministrazione della piattaforma; un agente chiamato ConFiguration Agent (CFA), responsabile delle operazione di startup e shutdown della piattaforma, nonché di gestione delle configurazioni di lancio della piattaforma; un agente detto MBD Agent (MDBA) che funge da interfaccia verso il repository di workflow di procedure operative utili ai tecnici (MDB); Performance DB CA CFA EM GW MDB MDBA Wizard Esecutor Container CA WCA WPA Log Console Operativa WGA Control Agent ConFiguration Agent Element Manager Gateway Model Data Base MDB Agent un Workflow Controller Agent (WCA) in grado di ricevere richieste di esecuzione di workflow dai WGA e, conseguentemente, attivare e controllare tali esecuzioni sui WPA; un WIZARD Performer Agent (WPA) che riceve le richieste di esecuzione di workflow da un WCA a cui notifica durante l esecuzione alcuni eventi per realizzare il requisito di interattività del workflow; un Logger Agent (Log): si occupa di memorizzare su Performance DB informazioni relative all esecuzione dei workflow. La prima applicazione basata sulla piattaforma WIZARD ad essere diffusa in esercizio ha l obiettivo di supportare l attività degli operatori di back office nell esecuzione dei passi previsti dalle procedure operative per l espletamento del cambio porta per clienti ADSL attestati su DSLAM. Nel caso specifico di WIZARD per il cambio porta, si prevede di utilizzare: 1. una comunicazione tramite chiamate remote a metodi EJB per l interazione con UNICA; 2. una comunicazione tramite Webs per l interazione con il sistema Control; 3. una comunicazione tramite messaggi JMS con il sistema Oreste/bus Tibco. In particolare Tibco metterà a disposizione in maniera permanente una coda JMS dalla quale il workflow di cambio porta preleva selettivamente il messaggio di propria competenza sulla base di un identificativo univoco. Prossimamente la soluzione WIZARD si interfaccerà anche con il sistema NEXT per eseguire alcuni passi del processo di diagnosi. La realizza- Agenti WADE Agenti Wizard Console di amministrazione Wizard Mini Container CFA GW MDBA FIGURA 13 Architettura funzionale della piattaforma WIZARD. MDB OSS OSS Workflow Workflow interno interno BUS di sincronizzazione EM/NM EM/NM by vendors Nodes NM Network Management OSS Operation Support Systems WCA Workflow Control Agent WGA Workflow Gateway Agent WPA Workflow Performer Agent Centralized Inventory 36 NOTIZIARIO TECNICO TELECOM ITALIA Anno 16 n. 1 - Aprile 2007

11 zione ha comportato la definizione dei workflow specifici per i processo di cambio porta DSLAM (figura 14). In un ottica evolutiva di breve termine, in cui la funzionalità di cambio porta su DSLAM sarà disponibile al tecnico in campo, la procedura guidata precedentemente descritta dovrà essere preceduta da un procedura guidata di verifica dell effettivo guasto della porta in oggetto (figura 15). Questa diagnosi preliminare comporta: verifiche e attività manuali sul permutatore su cui è attestato il cliente; verifiche e attività manuali sui filtri (splitter in centrale); verifiche e attività manuali sul DSLAM e sui cavi ad essi attestati; verifiche e attività su DSLAM tramite sistema di gestione NEXT. Un altro esempio di applicazione è il ripristino di una Portante - Rete Ericsson GSM che supporta il tecnico sia nell esecuzione passo-passo dell intervento, sia nell interazione con il sistema OMC, che costituisce l EM per le BTS di tecnologia Ericsson e che è al momento mediata da un operatore di back office. La procedura, invece, di sostituzione piastra di un Node B Rete Ericsson UMTS si presenta al momento semplicemente come un supporto che guida passo-passo il tecnico on field ; una sua evoluzione potrebbe prevedere l interazione diretta con l EM, semplificando ulteriormente l operatività del tecnico. La realizzazione ha comportato la definizione dei workflow specifici per i processo di ripristino della Portante di una BTS Ericsson e di sostituzione piastra di un Node B Ericsson. 6. Il controllo adattativo con ADEGUA ADEGUA (ADvancEd Global Usage Adaptive platform), utilizzato sia in WIZARD che in WANTS/NNEM, è l architettura di controllo prestazionale distribuita che consente di gestire in modo automatizzato la piattaforma ad agenti con lo scopo di garantirne le funzionalita e ottimizzarne le prestazioni, utilizzando meccanismi adattativi guidati sia da SLA che dal consumo delle risorse Start Verifica Parametri /input Parametri errati Abort utente Fine Operativa con errore End Scad. Timeout Fine op. inter. Oreste: attesa risposta Test esito Oreste Cliente Res. su DSLAM IP? Notifica esito OK ( ) End Fine Operativa in Validazione Parametri Oreste Non Disponibile Notif. Esito Oreste KO Richiesta Aggiornamento chiave tecnica Test esito ModifyTK End Fine Operatività con errore SC ModifyTK: Non disponibile SC Esito OK Test Tentativi e Tipo Errore Test Tentativi e Tipo Errore UNICA GetOldPort non disponibile Nuovo Tentativo Ricevuto esito KO da UNICA Dati incoerenti UNICA ChangePort non disponibile Nuovo Tentativo Ricevuto esito KO da Unica Stessa Piastra Alerta Stessa Piastra Oreste: Scaduto extra time Invia Notifiche KO Messaggio di Benvenuto Genera reqld cambio porta UNICA: Porta da dismettere Test UNICA old port Verifica Coerenza Dati UNICA UNICA: Cambio porta Test UNICA new port Test Nuova Scheda Visualizza Esito UNICA OK Oreste: attesa risposta Test esito Oreste Esito Oreste OK Cliente Res. su DSLAM IP? Cambio porta OK Fine Oper. Nuova Piastra Alerta Nuova Piastra Richiesta Aggiornamento chiave tecnica Test Esito ModifyTK SC Esito OK FIGURA 14 Workflow completo di assistenza automatica per il cambio porta. End End End Alerta Vecchia Piastra Oreste non Disponibile Esito Oreste KO SC ModifyTK non disponibile SC Esito KO Fine Operatività con errore Fine Operatività con errore informatiche. Il principale obiettivo di ADEGUA è quindi quello di introdurre funzionalità autonomiche nella gestione di piattaforme ad agenti, capaci di fornire all amministratore del sistema un insieme di caratteristiche tali da consentirgli di: gestire agevolmente un architettura distribuita sia in termini software che hardware; gestire automaticamente lo stato dei singoli agenti e server della piattaforma, grazie a funzionalità di controllo che permettono di riavviare gli agenti eventualmente in stato di failure o riposizionarli su server differenti nel caso si generino delle indisponibilità hardware; avere lo stato funzionamento non solo dei singoli server utilizzati dalla piattaforma, ma anche l esatto consumo di ogni componente applicativa e di ogni workflow eseguito dagli agenti; controllare il funzionamento end-to-end dei servizi forniti dalla piattaforma NNEM/WIZARD; definire degli SLA sui tempi di esecuzione dei End End NOTIZIARIO TECNICO TELECOM ITALIA Anno 16 n. 1 - Aprile

12 Notifiche chiave all interno della soluzione NNEM e WIZARD perchè permette di mascherare all amministratore la complessità legata al monitoraggio e controllo di una infrastruttura distribuita composta da migliaia di agenti. WorkFlow per il cambio porta Show Message Tecnico on-field workflow, ovvero sono realizzate delle opportune funzionalità di controllo che consentono di distribuire il carico di lavoro sugli agenti in modo da garantire che determinati servizi/workflow siano completati nei tempi prefissati dall amministratore secondo le logiche di business richieste; monitorare periodicamente lo stato di consumo prestazionale dei server in modo da consentire all amministratore di identificare proattivamente eventuali trend di crescita che portino alla saturazione delle risorse hardware dell architettura, o supportarlo nella individuazione di una migliore allocazione degli agenti sui server tale da garantire un maggiore livello prestazionale della piattaforma WANTS e WIZARD; analizzare l andamento storico dei consumi di risorse dell infrastruttura hardware e identificare eventuali trend di crescita nei consumi (ad esempio, impatti prestazionali introdotti dall aggiunta di nuovi servizi o maggiori volumi delle attività svolte dalla intera piattaforma controllata). L ambiente di controllo fornito dalle funzionalità di ADEGUA gioca un ruolo Tecnico back-office FIGURA 15 Dal workflow (eseguito da agenti) a come si presenta l assistenza sulla postazione di lavoro. 200 utenti web 7. Le prestazioni La soluzione NNEM è stata oggetto di innumerevoli prove prestazionali che hanno avuto l obiettivo non solo di identificare i benchmark prestazionali ottenibili, ma soprattutto di validare prestazionalmente l architettura basata su workflow ad agenti distribuiti. Le prove prestazionali sono state eseguite su un architettura NNEM identica a quella presente in esercizio (figura 16), con l unica differenza che si è usato un numero di server più limitato. In particolare si è fatto uso di hardware a low-cost, costo per unità tra i euro, composto da server HP Proliant DL145 dotato di due processori AMD Opteron 246 (tecnologia x86) a 2 Ghz e 4 Gbyte di RAM. I server utilizzati sono di tipo rackable ed è possibile allocarne su un RACK di dimensioni tradizionali fino a 42 unità. Si evidenzia l importanza del numero di server hardware su cui opera la piattaforma dal momento NNEM: architettura di esercizio 15 server HP Proliant DL 145 dedicati ad ospitare gli agenti NNEM 2 server HP Proliant DL 585 dedicati ad ospitare il DB Oracle RAC 10g 6000 diagnostiche servizio ora 4000 attivazioni IPTV ora VLAN esterna per accesso da DACON/lanet e DSLAM IP NNEM Neutral Network Element Manager wants01 DL 145 wants02 DL 145 wants15 DL 145 wantsdb02 -bk HP DL 585 wantsdb01 HP DL 585 VLAN interna 1gbit/sec per comunicazione tra i server HA F.C HA F.C Ruolo: SAN HW: MSA 1000 totale RAID 1 FIGURA 16 L ambiente per le prove di stress prestazionali di WANTS e WIZARD. 38 NOTIZIARIO TECNICO TELECOM ITALIA Anno 16 n. 1 - Aprile 2007

13 che essendo tutte le componenti di NNEM (almeno quelle prestazionalmente più pesanti) replicabili e distribuibili su più server, è possibile ad esempio raddoppiare i livelli prestazionali ottenibili semplicemente aggiungendo un server o più all architettura hardware di NNEM. Ad oggi per l ambito applicativo in cui viene utilizzato NNEM non si è ancora identificato il limite massimo di server supportabili dall infrastruttura che comunque si stima dell ordine delle centinaia. Fin dai primi test prestazionali sono stati subito evidenti i grossi benefici ottenibili da un architettura modulare e distribuita. Si pensi ad esempio che utilizzando già un solo server per gli agenti Resource Proxy è possibile ottenere un throughput di creazioni servizi/ora che può diventare il doppio o il triplo aggiungendo rispettivamente due o tre server per gli agenti Resource Proxy. Naturalmente questi sono valori Throughput - Attivazioni IPTV ora Numero Attivazione oraria di servizi IPTV all aumentare del numero di server che ospitano gli agenti Resource proxy Tempi medi di risposta (sec) Consumo CPU (%) Andamento medio dei tempi di risposta alle richieste dei flussi di Attivazione, Diagnostica e Apertura Pagine WEB Tempo durata Test - Minuti Attivazione Diagnostica Consumi di CPU sui server del Test Plant Apertura pagine WEB Tempo durata Test - Minuti Database WebServer NNEM - Agenti Ma NNEM - Agenti AA NNEM - Agenti RP (1) NNEM - Agenti RP (2) FIGURA 17 Indicatori di prestazione della piattaforma WANTS e WIZARD. limite raggiungibili nell ipotesi che gli apparati abbiano tempi di risposta nulli o che le richieste di attivazione si distribuiscano su un numero elevato di apparati, ad esempio apparati. Valori di provisioning così elevati sono nettamente superiori a quelli delle attuali architetture tradizionali che si attestano su valori di attivazioni all ora. Con una infrastruttura di laboratorio che ha coinvolto mediamente un numero limitato di server, da quattro a sei unità, è stato comunque possibile simulare situazioni di carico complesse che prevedevano la contemporaneità di flussi diversi, quali provisioning, troubleshooting e navigazioni web prodotte dagli operatori NNEM. Per dare un idea dei valori in gioco, (figura 17), si sono simultate con successo situazioni che prevedevano la contemporaneità di 4000 attivazioni orarie di servizi IPTV, 6000 richieste orarie di dignostica servizio (corrispondenti a interrogazioni apparato/ora) in presenza di oltre 200 utenti web attivi contemporaneamente (corrispondententi a interrogazioni http orarie). In tali condizioni di carico l architettura basata ad agenti distribuiti ha sempre permesso di garantire un buon livello prestazionale e soprattutto non ha evidenziato significativi effetti di degrado dovuti alla contemporaneità dei flussi di carico. In generale gli studi prestazionali sull architettura ad agenti stanno dando risulati molto positivi, si pensi che ormai nel test plant di laboratorio si utilizzano configurazioni che prevedono non meno di 4000 agenti con oltre servizi configurati e una concentrazione tra i agenti per server per un totale di oltre 5 milioni di porte fisiche. Analoghe performance si stanno ottenendo anche sul fronte WIZARD dove il connubbio architettura ad agenti e micro-motori di workflow stanno dando risultati estramente positivi in termini di flessibilità e scalabilità della soluzioni. Infatti l architettura WIZARD già a partire da tre-quattro ser- NOTIZIARIO TECNICO TELECOM ITALIA Anno 16 n. 1 - Aprile

14 ver permette di gestire diversi centinaia di cambi porta al minuto con altrettanti operatori connessi remotamente alla piattaforma. Gli studi prestazionali effettuati in questi anni hanno permesso di validare i modelli architetturali basati ad agenti anche per la realizzazione di applicazioni nell ambito degli OSS. In particolare si sottolinea come ormai tutti i vendor, quali HP, IBM e SUN stanno promuovendo architetture hardware più snelle basate su batterie di blade server piuttosto che i tradizionali supercalcolatori quali ad esempio gli HP SuperDome. La soluzione NNEM è abilitante all utilizzo di queste innovative infrastrutture che consentiranno di centuplicare le performance attualmente ottenibili dai sistemi tradizionali, favorendo nello stesso tempo l abbattimento dei costi infrastrutturali grazie all utilizzo di hardware low-cost. BSS GTW OSS liv-1 BSS EM NB GTW NGN2 OSS WCE OSS liv-2 OSS OSS SERVIZI BUS di ORCHESTRAZIONE PROCESSI OSS OSS OSS OSS FUNZIONI EM EM EM EM COMANDI Network F & M 2006 Business Support Systems Element Manager Narrow Band GateWay Next Generation Network 2 Operation Support System Workflow Creation Environment BSS GTW standard Iperflow SERVIZI Neutral Process Iperflow ESB di ORCHESTRAZIONE Self-Adapt WORKFLOW Neutral EM aperte AZIONI - ESPERIENZA NGN2 > 2010 FIGURA 18 Un nuovo paradigma: l esternalizzazione delle interazioni OSS-rete-servizi. Knowledge WCE 8. Evoluzioni e conclusioni Nell articolo sono state evidenziate le specificità e le innovazioni necessarie per garantire affidabilità, flessibilità, robustezza e adattabilità delle nuove architetture gestionali. Gli obiettivi riguardano essenzialmente la possibilità di ridurre lo spending degli OSS e degli EM, rendere più flessibile la riconfigurazione degli OSS al variare delle tecnologie di rete, ridurre progressivamente il numero di OSS specializzati, razionalizzare il numero delle funzionalità oggi diffuse e replicate in più di un OSS, permettere univocità ed omogeneità nei processi elaborativi (flussi di processo automatici), garantire allineamento degli inventory, correttezza nel recovery e real-time nella esecuzione e assicurare una vista end-to-end a livello di rete, di servizio e di cliente. L evoluzione delle attuali architetture di gestione (basate su infrastruttura applicativa e funzionale di tipo NGOSS) porterà alla messa a fattor comune delle logiche di accesso ai dati e di elaborazione, secondo criteri e funzionalità condivise su base processo. Le logiche (sotto forma a di workflow distribuibili dinamicamente sulle singole componenti SOA), renderanno possibili nuove forme di gestione della rete, dei servizi e del personale operativo, garantendo monitoraggio, coerenza informativa e tracciabilità processiva. La componentizzazione del sw (via workflow) e la parametrizzazione dei processi renderanno le attuali architetture OSS più flessibili, tali da ridurre gli elevati costi che oggi si concentrano primariamente nella system integration (figura 18). È prevedibile per il prossimo futuro che la gestione di milioni di oggetti in rete (apparati, router clienti, infrastrutture di casa-ufficio, terminali), tramite l adozione di paradigmi e di architetture OSS basate su componenti SOA ad agenti e micro-workflow distribuiti, richieda anche l adozione e quindi la sperimentazione, di sofisticati motori di ricerca, che come Google, siano in grado di recuperare in tempo reale l anagrafica della rete, i processi automatici, le procedure di lavoro e quindi tramite algoritmi semantici, correlare queste informazioni per generare ulteriori dati utili ai progettisti di Telecom Italia. giuseppe1.covino@telecomitalia.it danilo.gotta@telecomitalia.it antonio.nasuto@telecomitalia.it 40 NOTIZIARIO TECNICO TELECOM ITALIA Anno 16 n. 1 - Aprile 2007

15 ABBREVIAZIONI AA Agent Application ACL Agent Communication Language ADEGUA ADvancEd Global Usage Adaptive platform AOP Agent Oriented Programming BAC Business Aware Component BB Broad Band BML Business Management Layer BPEL Business Process Execution Language BSS Business Support Systems CA Control Agent) CEM Centro Esercizio Manutenzione CFA ConFiguration Agent CGR Centro Gestione Red CRM Customer Relationship Management DBR Data Base di Rete DSLAM Digital Subscriber Access Multiplexer EM Element Manager ESB Enterpise Bus FIPA Foundation for Intelligent Physical Agents FSC Framework Component GBE GigaBit Ethernet GEM Gestione Materiali GPON Gigabit Capable Passive Optical Network GW GateWay MA Master Agent MDB Model Data Base MDBA MBD Agent MOI Manodopera di Impresa MOS Manodopera Sociale MSEM Multi System Element Manager NAS Network Access Server NB Narrow Band NE Network Element NGN2 Next Generation Network 2 NGOSS Next Generation Operation System and Software NM Network Management NML Network Management Layer NMS Network Management Systems NNEM Neutral Network EM OADM Operation Administration Console OLT Optical Line Termination ONU Optical Network Unit OSS Operation Support Systems PA Protocol Adapter PCA Personal Communication Assistant PE Process Engine RP Resource Proxy SCCE Creation & Control Environment SGSDH-NM SDH Network Management SID Shared Information Data SLA Level Agreement SNMP Simple Network Management Protocol SOA Oriented Architecture SQM Quality Management TMN Telecommunication Management Network TTM Trouble Ticket Management TTM Trouble Management Ticket VAS Valued Added s WANTS Workflow and AgeNTS based platform WCA Workflow Controller Agent WCE Workflow Creation Environment WFL WorkFLow WFM Work Force Management WGA Wizard Gateway Agent WPA Wizard Performer Agent WSDL Web s Description Language WSS Web s Security NOTIZIARIO TECNICO TELECOM ITALIA Anno 16 n. 1 - Aprile

16 Giuseppe Covino si è laureato con lode in Ingegneria Elettronica al Politecnico di Torino nel 1995 con specializzazione in Informatica, nel 1996 è assunto al centro ricerche di Telecom Italia (CSELT) nell area Gestione di Rete. Fino al 1998 si occupa di diversi progetti Europei relativi alla gestione delle reti di accesso a larga banda e dal 1999 partecipa alla gara e al rollout per il dispiegamento della tecnologia ADSL in Telecom Italia. Dal 1999 guida la progettazione e realizzazione di alcuni OSS (SMALL per il provisioning ed il troubleshooting dei servizi, CANTO per il monitoraggio della qualità dei doppini) e dal 2000 fa parte di gruppi di lavoro del TeleManagementForum (Architetture, Modelli informativi, Interfacce gestionali) come rappresentante di Telecom Italia. Dal 2003 è responsabile del progetto di ricerca WANTS che ha portato alla realizzazione dello strato NNEM. Tiene frequenti corsi e presentazioni sulla gestione di reti e servizi e la loro evoluzione in ambito italiano (TILS, Politecnico di Torino) ed internazionale (eventi IIR e TMF). È co-autore di diverse domande di brevetto su architetture ed implementazioni di sistemi di gestione. Danilo Gotta si è laureato con lode in Scienze dell Informazione all Università di Torino nel Opera presso la struttura di innovazione di Telecom Italia (già TILAB e CSELT) dal 1993 dopo un esperienza di due anni nell ambito di sviluppo software per sistemi di modellizzazione a reti di code in un azienda francese (Simulog). Ha coordinato sia progetti software che progetti orientati al testing prestazionale di sistemi software, in particolare durante l allestimento dei sistemi di gestione per la rete SDH di Telecom Italia e la predisposizione di metodologia innovative per la misurazione delle prestazioni di applicazioni web e distribuite. Dal 2003 si è specializzato nella progettazione di una soluzione tesa a rendere adattive le capacità computazionali di sistemi distribuiti sia nel sw che nell hw (WANTS/ADEGUA). Infine dal 2006 è referente per la tematica WIZARD e delle logiche di potenziamento della piattaforma WADE. È autore di una decina di domande di brevetto su tematiche prestazionali e sull applicazione di tecnologie basate ad agenti e workflow ai contesti di gestione della rete e del knowledge management oltre che autore di pubblicazioni in ambito Computer Measurement Group. Antonio Nasuto si è laureato in ingegneria elettronica con specializzazione in Telecomunicazione presso l Università di Bologna. Dal 1997 ha avviato la sua collaborazione con CSELT (oggi TILab) ed ha inizialmente lavorato alla tematica di gestione di rete e dei servizi. Dal 2001 ha operato all inserimento in rete della nuova piattaforma di gestione ed in particolare si è specializzato sulle tecniche di monitoraggio e testing prestazionali degli OSS. Dal 2004 nell ambito dell area di OSS Innovation ha operato attivamente alla definizione di strumenti e tecniche per il controllo di applicazioni fortemente distribuite in ambienti blade server. In tale ambito ha ideato diversi brevetti e realizzato soluzioni innovative per il controllo delle performance. 42 NOTIZIARIO TECNICO TELECOM ITALIA Anno 16 n. 1 - Aprile 2007