La gestione delle nuove reti - claudio cancelli · COVINO › GOTTA › NASUTO • La gestione...

NOTIZIARIO TECNICO TELECOM ITALIA › Anno 16 n. 1 - Aprile 2007 27

La gestione delle nuove reticon un diverso paradigma

GIUSEPPE COVINO

DANILO GOTTA

ANTONIO NASUTO

L’innovazione a livello di rete-servizi richiede nuovi paradigmi gestionalicapaci di offrire prestazioni e funzionalità di nuova generazione. I trend dimercato nella computer science promuovono soluzioni basate su un usopervasivo dei principi della Service Oriented Architecture, sulla componen-tizzazione del software e sull’Open Source. La gestione del prossimo futu-ro non potrà trascurare questi aspetti e Telecom Italia ha da poco avviatoun intenso e sfidante piano di ammodernamento delle proprie architettureOSS che tengono conto da un lato dei trend tecnologici e dall’altro degliobiettivi di semplificazione e razionalizzazione delle attuali implementazionisoftware.

1. Introduzione

La necessità di una maggiore integrazione delleprocedure gestionali ha spinto, nella seconda metàdegli anni ‘80, i gestori di reti TLC a cooperare nel-l’ambito degli organismi di normativa per la defini-zione di standard per la gestione delle reti. Si èvenuta così a sviluppare in ambito ITU-T la tema-t ica TMN (Telecommunicat ion ManagementNetwork) con l’obiettivo di definire gli standard perla gestione delle reti e dei servizi, nell’ottica diun’integrazione del le procedure gestional i inambienti tecnologicamente eterogenei (multi-capa-bility e multi-vendor). L’architettura funzionale dellaTMN nel corso degli anni è evoluta individuandodiversi livelli logici e sottosistemi funzionali peradattarsi a gestire la crescente complessità dellereti.

Questo modello viene tuttora sovente rappre-sentato con una piramide, dove alla base c’è la

gestione degl i elementi f is ici del la rete NML(Network Management Layer ) e a l l ’apice lagestione degli aspetti di business BML (BusinessManagement Layer). Questa rappresentazione, cheper la verità in questa precisa caratterizzazionepiramidale non si r itrova esplicitamente nelleRaccomandazioni ITU-T, ha avuto notevole diffu-sione sino ad essere identificata come “il veromodello TMN”. Il successo di questa figura è pro-babilmente dovuto alla capacità di evidenziare inmodo semplice i singoli livelli nei quali dovevanoessere svolte le funzionalità gestionali che mira-vano a coprire differenti ambiti e, nel contempo, dimettere in risalto l’interrelazione tra i livelli. Infatti,il percorrere la piramide dall’alto verso il bassometteva in evidenza i requisiti che il livello supe-riore imponeva al livello sottostante; mentre per-correrla dal basso verso l’alto evidenziava le fun-zionalità che il livello inferiore era in grado di offrireal livello superiore.

ARCHITETTURE

5 NNEM BRUNO 6-03-2007 15:24 Pagina 27

COVINO › GOTTA › NASUTO • La gestione delle nuove reti con un diverso paradigma

28 NOTIZIARIO TECNICO TELECOM ITALIA › Anno 16 n. 1 - Aprile 2007

Il modello TMN (figura 1), valido per gli alboridella gestione, ha presentato nel corso degli anni‘90 sino ai giorni nostri una serie di limiti e proble-matiche tra i quali: la proliferazione della numero-sità delle interfacce punto-punto tra i diversisistemi di gestione (a tutti i diversi livelli della pira-mide), la replicazione eccessiva delle logiche diarchiviazione dei dati (stesse informazioni su appli-cazioni - sistemi distinti), la molteplicità dei criteridi accesso alle applicazioni con interfacce uomo-macchina distinte per sistema a parità di processo.Inoltre, la crescente complessità delle reti e deiservizi offerti sta rendendo inadeguati i tradizionalisistemi di supporto alla gestione OSS (OperationSupport Systems). Si è venuta così a concretizzarela necessità di ripensare alle architetture gestionaliche nel corso degli ultimi anni ha condotto al con-solidamento di un nuovo framework architetturalechiamato NGOSS (Next Generation OperationSystem and Software - del TMF,www.tmforum.org), che partendo dalla TMN, neevolve l’architettura verso il superamento della tra-dizionale struttura piramidale. Lo scenario architet-turale di gestione aderente ai requisiti NGOSS defi-nisce l’evoluzione dei sistemi OSS e delle tecnolo-gie software per far fronte alla crescita a ritmimolto elevati del numero e dei volumi dei servizi,per sostenere la sempre maggiore complessità direti ed apparati di telecomunicazione, per favorirel’integrazione delle applicazioni best-in-class inmodo il più possibile semplice, per rendere isistemi facilmente scalabili, distribuibili e riconfigu-rabili per tenere il passo con scenari in continua erapida evoluzione e per poter adattare veloce-mente le interazioni tra i sistemi per supportare levariazioni dei processi aziendali. Nella architetturaNGOSS al livello massimo di astrazione, si pos-sono distinguere i seguenti sei elementi essenziali(figura 2):1. un’infrastruttura di comunica-

zione (BUS) a cui tutte le com-ponenti software si interfac-ciano, riducendo ad una l’inter-faccia per ogni OSS (è respon-sabile di recapitare i messaggial destinatario di cui ogni com-ponente non conosce la suacollocazione fisica);

2. una serie di FSC (FrameworkService Component) ossia dicomponenti che offrono servizia supporto della piattaforma,ad esempio la transazionalità,l’autenticazione, il logging;

3. un repository che offre servizidi registrazione, dove ogni fun-zionalità disponibile è docu-mentata. In questo modo i varicomponenti non hanno neces-sità di “conoscersi” l’uno l’altro,rendendo possibile un bassoaccoppiamento e quindi unlimitato costo di system inte-gration (oggi tra le voci di inve-

stimento più consistenti per chi adotta architet-ture gestionali tradizionali);

4. una serie di BAC (Business Aware Component)ossia di componenti che svolgono le vere e pro-prie funzioni di business (es. di assurance, diprovisioning, di traffic management);

5. un process engine che funge da orchestratoredelle componenti e che è programmabile sulla

BUSINESS MANAGEMENT

SERVICE MANAGEMENT

NETWORK MANAGEMENT

NETWORK ELEMENT MANAGEMENT

NETWORK ELEMENTS

TMN(Telecommunication Management Network)

FIGURA 1› Modello a piramide per la gestione degli anni ‘80 (ITU).

FSCProcess FlowEngine

Process DefinitionTool

FSC

Communications Technology Services

FSC FSC FSC

BAC BAC BAC BAC

NG OSSTM Framework

Registries

Process Flow

repository

processmodels

BACFSCOSS

===

Business Aware ComponentFramework Service ComponentOperation Support Systems

FIGURA 2› Framework di riferimento per le architetture OSS evolute (TMF).




base delle caratteristiche dei singoli processioperativi;

6. l’utilizzo di un modello informativo comune, adesempio il SID (Shared Information Data model).L’architettura NGOSS, ideata intorno al 2000, è

stata precursore del paradigma SOA (ServiceOriented Architecture) che da un paio di anni èconsiderata la scelta di riferimento per le architet-ture gestionali a basso accoppiamento, con bus dicomunicazione e con interazioni formalizzate con ilmeccanismo del la registrazione dei serviz i(publish-subscribe).

Da ricordare che Telecom Italia ha adottato talemodello di riferimento, implementando la propriaarchitettura di gestione per reti/servizi broadbandproprio su una architettura NGOSS (ricevendo perquesto a Dal las, i l “First Ever Operat ionalExcellence Award” internazionale, figura 3).

L’attuale architettura di gestione OSS è compo-sta da uno strato di EM (Element Manager), fornitedirettamente dai vendor di apparati di rete, da unostrato di OSS di livello 1 (dedicati all’interazioneverso la rete per supportare i processi di attiva-zione / configurazione, raccolta degli allarmi,gestione del traffico, ...), da uno strato di OSS dilivello 2 (gestione dei processi di provisioning, didiagnosi, di supervisione, di inventory, di workforce) e da un BUS di orchestrazione delle applica-zioni e da accessi da / verso i BSS.

2. Problemi nuovi e trend tecnologici attuali

La domanda lecita che ci si pone, soprattutto aseguito di un award, è se esistono ancora dei mar-gini di potenziamento dell’attuale architettura digestione di Telecom Italia, ovvero se l’adozionedella NGOSS ha e sta facendo emergere nuoveproblematiche che richiedono un nuovo saltogenerazionale di paradigma, cioè:• Il problema della gestione proprietaria degli

apparati di rete: nella situazione attuale, gliElement Manager sono sistemi proprietari dellostesso vendor dei nodi di rete e presentanointerfacce proprietarie per l’integrazione con gliOSS di livello 1. Questa situazione ha portatocome conseguenza la necessità di adattare lefunzioni di interfacciamento degli OSS versotutti i tipi di EM con aggravio di costi di systemintegration e di segmentazione delle compe-tenze. Lo snellimento indotto delle architettureNGOSS deve quindi “anche” ottemperare alprincipio di adozione di uno strato di media-zione tra apparati ed OSS che sia vendor-inde-pendet e governato dall’operatore.

• Il problema dalle verticalizzazioni gestionali dilivello superiore: la flessibilità introdotta dalparadigma NGOSS non ha risolto però il pro-blema di replicazione delle funzionalità gestio-nali in ciascuno dei prodotti commerciali (spe-

ServiceInventory

OrderGateway

Inventory Troubleshooting

NetworkAssurance

Usage &Performance

ServiceAssurance

RevenueAssurance

Testing

Std services/msg

Correlation

SQM NMS

Configuration

Diagnosis

Reporting

progettazione+ActivationNB e VAS

ProgettazioneBB

EMMarconi

EMSiemens

EMAlcatel

CEMEricsson

CEMAlcatel

CEMItaltel

EMLucent MSEM

Network

MESM CGR FAMA SGSDH-NM

CEMService

Node

Plan

ning

Des

ign

Delivery&

Hot Delivery

ServiceManagement

Trouble TicketManagement

Magazzini WorkForce

FieldAccess Reporting

BUS

BBCEMCGRDBREM

GEMGUIMOI

========

Broad BandCentro Esercizio ManutenzioneCentro Gestione REDData Base di ReteElement ManagerGestione MaterialiGraphic User InterfaceManodOpera di Impresa

MOSMSEM

NBNMS

SGSDH-NMSQMTTMVAS

WFM

=========

ManodOpera SocialeMulti System Element ManagerNarrow BandNetwork Management SystemsSDH Network ManagementService Quality ManagementTrouble Ticket ManagementValue Added ServicesWork Force Management

FIGURA 3› Architettura OSS convergente operativa in Telecom Italia.




cializzati sui singoli processi operativi) acquisitie introdott i nel l ’architettura OSS; questoaspetto genera la replicazione di funzioni similiper l ’ interazione con la rete, funzioni chepotrebbero essere messe a fattor comune inuno strato unico.

• Il problema del non coordinamento tra gli OSS:l’assenza di un coordinamento nelle richiestetra gli OSS e la rete fa sì che non vi sia un uti-lizzo ottimale delle risorse computazionali degliapparati dedicati alla gestione, mancando unostrato di mediazione univoco capace quest’ul-timo di filtrare e normalizzare la pressione infor-matica sulla rete.

• Il problema dell’allineamento tra configurazionereale della rete e dei servizi e quanto documen-tato negli (inventory): uno dei problemi che inci-dono maggiormento sulla corretta esecuzionedei singoli processi operativi è costituito dalparziale ma costante disallineamento tra veroinstallato in campo in termini di equipaggia-mento apparati e servizi di rete configurati e leinformazioni memorizzate negli inventory direte-servizio-cliente. Una delle soluzioni perridurre questo problema di allineamento è dioperare con dati memorizzati il più possibilevicino alla rete, appunto in un layer di interme-diazione, che sia capace di effettuare il disco-very delle configurazioni e mantenerne l’aggior-namento in tempo reale anche tramite ricezionedelle notifiche di rete (trap ed eventi). In questomodo sarà possibile garantire la riconciliazionedei dat i aff inchè i processi d Del ivery,Configuration, Assurance, Traffic e altri ancorapossano chiudere con successo ogni singolatransazione.

• Il trend sulla componentizzazione e flessibilitàdel software: consente alle aziende di proget-tare e rapidamente implementare complesseapplicazioni anche in situazioni di continuocambiamento tecnolo-g ico e d i bus iness.Tramite questo para-digma, si possono svi-luppare, migliorare e rin-novare le appl icazionicomponente per compo-nente e conseguente-mente la gest ione diquesti continui aggiorna-menti può avvenire contempi rapidi e miglioretestabi l i tà, senza lanecessità di dover inter-venire ad ampio spettrosu sistemi e applicazionigestionali di precedentegenerazione (figura 4).Infatti, uno degli obiettivipiù ambiziosi dell’inge-gner ia del software èquello di organizzare larealizzazione di sistemi inmodo analogo a quanto

ormai predisposto in altri settori industriali,dove la presenza di un mercato di parti (compo-nenti) standard riutilizzabili permette di aumen-tare la produttività, riducendone i costi. La filo-sofia dei componenti stà dando vita a duenuove figure di programmatori: il progettista dicomponenti e l’assemblatore di applicazioni. Ilprimo ha il compito di identificare e progettareoggetti software di uso comune, che possanoessere utilizzati con successo in contesti diffe-renti (produttori in concorrenza tra di loro pos-sono realizzare componenti compatibili, ma concaratteristiche prestazionali differenti, per cuil’acquirente può così orientarsi su un mercatoche offre una pluralità di scelte anche OpenSource, e decidere in base al proprio spendinge alle funzionalità disponibili). L’assemblatore diapplicazioni, d’altra parte, è un professionistaspecializzato in un particolare dominio applica-tivo, capace di creare programmi complessiacquistando sul mercato componenti standarde combinandoli con opportuni strumenti e lin-guaggi di programmazione.

• Il trend della SOA: è uno stile architetturalebasato sul concetto di servizio (proceduresoftware), e definisce una modalità di costru-zione delle applicazioni come composizione diservizi con caratteristiche ben specifiche orien-tate al riutilizzo e all’integrazione. La SOA non èuna rivoluzione, ma un’evoluzione architetturaleche investe tutti gli aspetti associati alla defini-zione di un OSS: architetturali, metodologici,processivi, organizzativi e tecnologici. La chiaveinnovativa della SOA è l’indipendenza dei ser-vizi, definiti da un’interfaccia specifica (adesempio tramite Web Services), che possonoessere orchestrati tramite un ESB (EnterpiseService Bus) per eseguire i propri compiti in unmodo standard, senza che il servizio abbiaconoscenza dell’applicazione chiamante e

Adattivitàprocessiva

Ripartizionefunzionale

Integrazioneapplicativa

hw dedicato hw multi-cpu hw a basso costo

PARAMETRIZATION

hw in rete grid

PCAs* 2013TMN

1993 2003

NGOSS

AUTOMATION(Centralization,

“corporate” rules)

DISTRIBUTION(Decentralization,high end functional

systems)

COMPOSITION(team-and knowledgedriven corporation)

CRMTTM

Mainf

ram

e

3-tie

r Clie

nt/S

erve

r

Ente

rpris

e Se

rvice

s

Arch

itectur

e

CRMPCA

NGOSSTMNTTM

=====

Customer Relationship ManagementPersonal Communication AssistantNext Generation Operation System and SoftwareTelecommunication Management NetworkTrouble Ticket Management

FIGURA 4› La successione di snodi tecnologici dirompenti nel software e nell’hardware.




senza che l’applicazione abbiaconoscenza, o necessit i d iaverne, del servizio che effetti-vamente eseguirà l’operazione(figura 5). La validità di un’ar-chitettura SOA è basata suiseguenti standard e principi:- Standard: per operare in

ambienti multipiattaformautilizzando interfacce basatesu WSDL (Web ServicesDescription Language) conWeb Services Security;

- Granularità: per trovare unequilibrio nella scomposi-zione di una applicazione inmicro-servizi erogabil i daogni singola componentesoftware, al fine di evitare diavere una elevata specializ-zazione (poca riusabilità) ouna e levata genera l izzaz ione (e levatanumerosità);

- Dorsale ESB per pubblicare e orchestrare iservizi, per autenticare ed autorizzare insicurezza l’uso delle componenti, per tra-sformare i dati da una applicazione mittentead una destinataria e per supportare regoledi business e capacità di monitorare gli SLA(Service Level Agreement).

• Il trend del software ad agenti: sebbene lacomunità scient i f ica ne discuta ormai datempo, è solo dalla seconda metà degli anni‘90 che ha cominciato a trovare riscontri appli-cativi pratici un nuovo paradigma di svilupposof tware denominato “Agent Or ientedProgramming” (AOP). Tale paradigma nascedalla fusione di alcuni concetti derivanti daglistudi sull’intelligenza artificiale con la tecnolo-gia degli oggetti informatici distribuiti e pre-vede la realizzazione di un’applica-zione software come collezione dicomponenti, dette appunto agenti,capaci di essere:- autonome, ossia svolgere task lun-

ghi e complessi;- proattive, ossia prendere iniziative

anche senza uno stimolo esplicitoda parte di un utente;

- comunicative, ossia interagire traloro al fine di raggiungere l’obiet-tivo globale della applicazione.

• Il modello architetturale di una applica-zione realizzata con tecnologia adagenti è intrinsecamente peer to peer inquanto ogni agente è potenzialmente ingrado di iniziare una comunicazione conogni altro agente nel sistema. Per sfrut-tare appieno le potenzialità della tecno-logia ad agenti, varie aziende ICT hannodato vita a FIPA (Foundat ion forIntel l igent Physical Agents -www.fipa.org), una iniziativa internazio-nale non-profit con l’obbiettivo di pro-

durre specifiche per l’interoperabilità tra agentirealizzati da produttori diversi e con tecnologiediverse. Essendo focalizzate sugli aspetti di intero-perabilità, le specifiche FIPA non trattano la strut-tura interna di un agente, ma definiscono un lin-guaggio di comunicazione tra gli agenti detto ACL(Agent Communication Language) che si fonda suun paradigma di scambio di messaggi asincronobasato sui nomi degli agenti e consente quindilegami laschi (loosely-coupled) tra le componentidel sistema (gli agenti). Nessuna dipendenza dagliindirizzi di trasporto, nessuna dipendenza tempo-rale (il ricevitore di un messaggio potrebbe addirit-tura non esistere ancora al momento dell’invio diun messaggio) e interfacce dichiarative consen-tono agli agenti di entrare/uscire dal sistema, tro-varsi ed interconnettersi in modo dinamico tro-vando quindi riscontro negli aspetti chiave dellearchitetture di tipo SOA (figura 6).

Identification

Presentation

User

Client

BPELESBSOA

= Business Process Execution Language = Enterprise Service Bus= Service Oriented Architecture

ESB

Service 1

Service 2

Engine BPEL

SOAP

A B C

Codicesoftware

D

BC

BPEL

SE

2 3

4

JSR181

SE

JSR181

SE

BusinessProcesses

Services

Components

ExistingsApplications

Output: realizzazione SOA

Specifications

Realizationdecisions

FIGURA 5› Come predisporre soluzioni gestionali compatibili al paradigma SOA.

Prepara il messagio per A2

Legge il messaggio dalla inbox e lo processa

A1 A2

FIGURA 6› Schema di funzionamento di base della piattaforma ad agenti distribuiti Jade.




3. Un disaccoppiatore neutrale e un assistente in linea

I problemi riscontrati dalla adozione di soluzioniNGOSS “tradizionali” e le tendenze che sempre piùpromuovono modelli architetturali a componentiriusabili impongono quindi una rimodulazione dialcuni principi gestionali, che si riflettono anche ininnovative scelte che Telecom Italia sta attuando epromuovendo a livello internazionale. Le azioniprevedono di:1. Eliminare progressivamente la quantità e la

tipologia degli EM introducendo una piat-taforma Neutral Network EM (NNEM) capace diintermediare la rete con gli OSS di livello supe-riore in modalità multi-vendor e multi-domaindi rete;

2. Lavorare con dati “vicino alle applicazioni”sfruttando al contempo logiche di riallinea-mento automatico verso gli inventory al fine difacilitare la predisposizione di applicazioni realtime e di ridurre le eccezioni (e quindi di rilavo-razioni manuali);

3. Utilizzare principi basati sulla Service OpenArchitecture (SOA) per la composizione e l’or-chestrazione dei nuovi processi per la gestionedelle reti-servizi broadband;

4. Ridurre al minimo l’introduzione di sistemi conproprie logiche interne (in genere cablate) digestione processiva.;

5. Facilitare lo scambio informativo tra OSS eapplicazioni di gestione delle operation, al finedi creare un continuum elaborativo in grado diassicurare correttezza nei dati e flessibilità negliinterventi;

6. Adottare meccanismi di retroazione automa-tica/autonomica a tutti i livelli di gestione al finedi regolare le priorità di elaborazione dei variprocessi sulla base di specifici SLA di business;

7. Abi l i tare l ’esecuzionedelle applicazioni gestio-nali su infrastrutture Grida basso costo;

8. Definire le entità oggettodi gestione (in particolareper la configurazione, laattivazione e la diagnosi)tramite modelli informa-tivi standard affinchè ilformato di una entità siaunivocamente r icono-sciuta da qualsiasi appli-cazione indipendente-mente dal processo ope-rativo di riferimento.Le suddette azioni impon-

gono quindi l’introduzione didue nuove piattaforme elabo-rative, nel seguito chiamaterispettivamente WANTS eWIZARD, che attraverso l’a-dozione del paradigma acomponenti software dotated i propr ia in te l l igenza

(espressa sotto forma di flussi procedurali semplicie leggeri tipo workflow) assegnabili in modo dina-mico e senza fermo di sistema, su infrastrutturehardware fisicamente distribuite, sono in grado diattuare i principi cardini elencati, permettendo allostesso tempo una considerevole contrazione deitempi di system integration, di adeguamento fun-zionale e di completamento con successo dei pro-cessi di esercizio e manutenzione delle nuove reti(figura 7).

4. La piattaforma WANTS

La soluzione Telecom Italia chiamata WANTS(Workflow and AgeNTS based platform) specificauna piattaforma ad alta flessibilità funzionale e sca-labilità computazionale, basata su agenti softwaredistribuiti con motori “leggeri” di workflow (ossiamotori in grado di eseguire porzioni di processoma dalle dimensioni così esigue di pochi kilobyteda poter essere eseguiti su qualsiasi sistemadotato di capacità elaborative, compresi i telefonicellulari) e distribuibili su infrastrutture elaborativea bassissimo costo (b lade workstat ion) .L’abbinamento tra agenti e worflow è risultato van-taggioso poiché permette di suddividere un pro-cesso di gestione in componenti elementari asse-gnando a ciascuno uno specifico compito (adesempio la configurazione di particolari schede diun dato nodo di rete, la raccolta di segnalazioni dianomalia da un particolare DSLAM e così via)aumentando al contempo in modo significativo leprestazioni, grazie ad un infrastruttura dall’altoparallelismo (migliaia di thread paralleli).

Semplificando l’architettura, si può supporreche esistano tanti agenti quanti sono potenzial-mente i milioni di apparati di rete gestibili. Questiagenti svolgono le verie e proprie funzioni di

FIGURA 7› Migrazione da un”architettura NGOSS a quella innovativa di Telecom Italia.




mediazione intelligente direte vendor-independent.Viene così a costituirsi unlayer di intermediazionecapace di crearsi una “imma-gine” di tutte le reti gestite:qualsiasi processo (e quindiOSS di livello superiore) noninteragirà più direttamente conla rete ma con la sua “imma-gine” che, tramite criteri sofisti-cati di discovery e di ricostru-zione delle configurazioni dinodo e di rete, sarà sempreallineata al vero installato(figura 8).

Altri tipi di agenti, di livellogerarchicamente superiore,hanno il compito di coordinaregli agenti di mediation, in mododa fornire viste multi-dominio esvolgere funzioni di controllo.

Infatti, oltre alle funzioni dimediation NNEM (in sostitu-zione degli EM per tutti i pro-cessi work-intensive, quali pro-visioning, assurance, trouble-shooting, configuration management, performance, ...),WANTS svolge funzioni proprie di OSS di livello 1, inparticolare di attivazione dei servizi, di assurance (dia-gnosi dei guasti e ricezione degli allarmi) e di gestionedelle configurazioni.

Nell’attuale versione di WANTS, tali funzioni sonostate implementate per i DSLAM IP.

Tutte le funzionalità, sia di mediation che di OSS dilivello 1 sono fornite tramite le logiche programmabili amicro-workflow, che possono essere iniettati negli agenta runtime, consentendo di modificare il comportamentodella piattaforma senza fermare il sistema.

I workflow sono scritti secondo lo standard interna-zionale XPDL (www.wfmc.org), mentre la mediazione direte utilizza il modello informativo SID prodotto dalTeleManagementForum.

Gli agenti (basati su soluzione opensourceJava/JADE, in linea con le direttive FIPA) eseguonoinfatti workflow capaci di interagire con gli OSS e la retein una modalità neutra rispetto al tipo di apparato (equindi di vendor). Le caratteristiche principali di WANTSsono le seguenti (figura 9):• architettura ad Agenti, organizzati su diversi

livelli logici (consigliati un numero di tre: livello

As-Is To-Be

OSSWorkflowinterno

OSSWorkflowinterno

OSS

SOA

NNEM WIZARD

OSS legacyintegration

Local processing Storage

Workflowesterno

Centralized Inventory

BUS di comunicazione ESB di orchestrazione

Alligned Real Time Invetory

EM/NM EM/NMEM/NM

byvendors

“0.000 Nodes“00.000.000 Nodes

EMESB

NNEMNM

OSSSOA

======

Element ManagerEnterprise Service BusNeutral Network EMNetwork ManagementOperation Support SystemsService Oriented Architecture

FIGURA 8› Confronto tra due realtà: NGOSS e gli OSS per gestire le esigenze del futuro.

PE3 PE3 PE3 PE3

PE1

PE1

PE2

PE3

PE2 PE2

PE3 PE3

ResourceProxy RPm

ResourceProxy RP2

ResourceProxy RP1

MasterApple MA1

SIDSID SID SID SID SID

AgentApple AA1

AgentApple AA2

Network

OSS Platform

ServiceCreation

&Control

Environment

SCCE

MD

B

N_D1 N_D1 N_D1 N_D1

ResourceProxy RPm

ResourceProxy RP2

Telnetadapter

SNMPadapter

Telnetadalpter

COP6Aadapter

ResourceProxy RP1

Workflow

AAMDBOSS

PESCCE

SIDSNMP

=======

Agent applicationModel Data BaseOperation Support SystemsProcess EngineService Creation Control EnvironmentShared Information DataSimple Network Management Protocol

FIGURA 9› Architettura funzionale della piattaforma WANTS.




di apparato, di rete e di servizio) per assicurareflessibilità (anche nella libera allocazione deiprocessi tra una modalità distribuita ed unacentralizzata) e scalabilità delle funzioni, evi-tando al contempo la complessità di strutturetroppo stratificate stile TMN. Ciò implica la defi-nizione di un livello centralizzato (corrispondead uno o più Master Agent - MA), uno comple-tamente distribuito (corrisponde agli AgentApplication - AA) ed uno strato indipendente diRP (Resource Proxy) per il disaccopiamentodella rete dalle funzioni gestionali e di controllo.Questa segmentazione fornisce anche diverseviste in base al livello di astrazione crescente(da RP a MA).

• ogni agente RP, oltre al disaccoppiamento, èresponsabile anche della creazione, manteni-mento e gestione della “immagine” (cache) dellaporzione di rete a lui assegnata e da lui gestita(può essere un singolo apparato oppure o unaporzione di rete, ad esempio un dominio atte-stato ad un EM). L’immagine è una rappresenta-zione del la conf igurazione del l ’apparatosecondo il modello informativo SID.

• interfacce verso OSS/BSS: modul i GW(Gateway), specializzati per processo, e depu-tati ad accettare comandi provenienti da OSSper l’esecuzione funzionalità tramite microworkf low ed a rest i tu i re informazioni agl iOSS/BSS (ad esempio allarmistica di rete) attra-verso adattatori software che consentono alGateway la comunicazione via protocolli diinterfacciamento peer-to-peer o v ia WebServices verso un BUS di comunicazione (nelcaso di Telecom Ital ia ad esempio, i l busTIBCO).

• Service Creation & Control Environment (SCE):implementa le funzionalità per la creazione edaggiornamento dei servizi gestionali forniti dallapiattaforma tramite disegno dei micro-workflowed i moduli di controllo della piattaforma viaWeb. Un MDB (Model Data Base) memorizzatutte le descrizioni di workflow ed i modelliinformativi delle informazioni trattate, sia rela-tive agli apparati che ai servizi di rete, ad usodelle funzioni di disaccoppiamento degli RP.

• Il modulo ADEGUA (ADvancEd Global UsageAdaptive platform), realizza invece la funziona-lità di governo elaborativo dell’ intera piat-taforma hardware e software; dato che WANTSrisulta una soluzione ad agenti distribuibili suinfrastruttura hardware distribuita a bassocosto, è necessario, tramite l’utilizzo di specialiagenti detti Control Agent (CA), consentire allapiattaforma di adeguare ed adattare proattiva-mente e in tempo reale il proprio balancingcomputazionale attraverso l’uso di algoritmi diautonomic computing. Il modulo è in grado diriallocare i processi eseguiti dai singoli agenti (atutti i livelli) al variare delle priorità dei singoliprocessi operativi di Delivery, Assurance eConfiguration gestiti (SLA che dipendono sia daconcause momentanee che da nuove logiche diofferta) garantendo in questo modo l’esecu-

zione ottimale di tutte le transazioni sia in casodi guasto/malfunzione della infrastruttura elabo-rativa che di down di sistema.

• Interfaccia verso i sistemi di rete (apparati, ter-minali e applicazioni): il PA (Protocol Adapter) èil modulo, all’interno degli agenti RP, responsa-bile dell’interfacciamento con la rete in base alprotocollo gestionale offerto dagli apparati (es.SNMP, telnet, TL1). Ogni PA offre quindi, comeservizi per i Resource Proxy, l’esecuzione delleoperazioni di base sull’apparato (ad esempionel 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 funzio-nalità di EM in grado di accogliere in unico strato diintermediazione le esecuzioni richieste da moltiOSS distinti e afferenti a processi operativi dinatura diversa tra loro

La piattaforma WANTS per lo strato di interme-diazione NNEM tra OSS e le nuove reti incorporaun primo insieme di funzionalità disponibili nellasua versione attualmente in esercizio per la attiva-zione e la configurazione dei nodi DSLAM IP multivendor. La soluzione NNEM è in estensione funzio-nale affinchè possa essere adottata anche per irimanenti processi gestionali (in particolare Fault,Trouble Shooting, Design e Configuration) applica-bili al nuovo settore di rete di accesso NGN2(figura 10).

5. La piattaforma WIZARD

Se nel caso dello strato di disaccoppiamentoNNEM, gli agenti equipaggiati a workflow permet-tono sia di istanziare una immagine virtuale dellarete da gestire che di intermediare in modo sem-plice tutte le funzioni di comunicazione tra rete eOSS, nel caso della piattaforma WIZARD il mede-simo principio può essere riutilizzato per far intera-gire in modo innovativo la rete e le applicazioni digestione con i tecnici di Telecom Italia (sia essiresidenti nei centri di help desk tecnico che in-field). A tutti gli effetti la soluzione WANTS è uninnovat ivo mediatore tra rete e OSS mentreWIZARD è un altrettanto innovativo mediatore trapersone, gli apparati della rete e l’insieme delleapplicazioni di supporto. In realtà l’obiettivo deiWIZARD è da intendersi in una accezione molto piùampia, corrispondente a quella di aiutare le per-sone ad interagire con sistemi informatici e conl’intero ambiente circostante. Gli ambiti di applica-zione della piattaforma sono molteplici (figura 11):• facilitare la comunicazione tra persone valoriz-

zando l’esperienza dei singoli;• innescare un miglioramento continuo dei pro-

cessi aziendali standardizzando le procedureoperative senza “ingessarle” ma anzi renden-dole esplicite e flessibili;

• orchestrare e riutilizzare servizi in vari contestiapplicativi;

• fornire un interfaccia amichevole e “guidata”verso sistemi informatici, apparati e oggetti.




La piattaforma WIZARDconsente di definire delleguide interattive (sulla falsa-riga dei Wizard windows diinstallazione) per procedureoperative tramite un ambientegrafico di SCE (ServiceCreation Environment, ilmedesimo adottato perWANTS) che consente diconfigurare dei workf low“operativi” (ad esempio leistruzioni di lavoro). In que-sto modo, delle procedureoperative che richiedono siainterventi manuali che inter-venti su diversi OSS, sonotradotte in un formato com-prensibile ad un assistentesoftware (wizard) che nonsolo suggerisce le opera-zioni manuali da svolgere,ma si occupa del dialogocon i vari sistemi informaticiautomatizzando in questomodo e il più possibile unflusso processivo che oggiviene spesso delegato inmodalità manuale alle sin-gole persone. La soluzione

WIZARD mette quindi adisposizione un ambienteper costruire applicazioni disupporto al personale tec-nico, in cui la comunica-zione tra persone e OSS (tracui anche l’NNEM) possaessere configurata tramiteworkflow: il punto caratteriz-zante è dovuto all’interatti-vità richiesta durante l’ese-cuzione dei workf low,aggiungendo specif ic iagenti softawre JADE perl ’esecuzione di workf lowinterattivi e fruibili in moda-lità Web e direttamente suuff icio mobile dei tecnici(Nokia Communicator)(figura 12).

L’interazione guidata trapersone e sistemi informa-tici è importante in molt icontesti: ad esempio i tec-nici Telecom (in field o diback office) per la soluzionedi problemi complessirichiedono spesso accessoa sistemi esterni, in cui lacomponente di interazione èfondamentale (r isposta aquesit i , sugger imento dioperazioni manuali da com-

FIGURA 10› Contesto di utilizzo dello strato NNEM basato su WANTS: dai DSLAM IP^alla NGN2.

WANTS

WIZARD

agente agente collettivo

agentecomputazionale

agente software

virus

...

“agente utile”

agentedeliberativo

agente reattivo

agente intelligente

agente mobile(intelligente, collaborativo)

agente (intelligente)collaborativo

agente di interfaccia (intelligente, collaborativo)

agente biologicoagente

autonomo

agente roboticoartificial life agent

FIGURA 11› Gli agenti software come veicolatori di conoscenza e assistenza on line.




piere, …). Per questo motivo le componentisoftware fondamentali della piattaforma sono(figura 13):• un agente WIZARD Gateway Agent (WGA), che

svolge un ruolo di inter-faccia fra la piattaformae la console operativa.Questa console esponeagli utente una serie difunzionalità che si tradu-cono nell’esecuzione diun workflow (es. cambioporta);

• un agente GatewayAgent (GW) che svolge ilruolo di interfaccia fra lapiattaforma e la consoleWeb di amministrazionedella piattaforma;

• un agente chiamatoConFigurat ion Agent(CFA), responsabile delleoperazione di startup eshutdown del la piat-taforma, nonché digestione delle configura-zioni di lancio della piat-taforma;

• un agente detto MBDAgent (MDBA) che fungeda interfaccia verso i lrepository di workflow diprocedure operative utiliai tecnici (MDB);

• un Workflow Controller Agent (WCA) in grado diricevere richieste di esecuzione di workflow daiWGA e, conseguentemente, attivare e control-lare tali esecuzioni sui WPA;

• un WIZARD Performer Agent (WPA) che ricevele richieste di esecuzione di workflow da unWCA a cui notifica durante l’esecuzione alcunieventi per realizzare il requisito di interattivitàdel workflow;

• un Logger Agent (Log): si occupa di memoriz-zare su Performance DB informazioni relativeall’esecuzione dei workflow.La prima applicazione basata sulla piattaforma

WIZARD ad essere diffusa in esercizio ha l’obiet-tivo di supportare l’attività degli operatori di backoffice nell’esecuzione dei passi previsti dalle pro-cedure operative per l’espletamento del cambioporta per clienti ADSL attestati su DSLAM. Nelcaso specifico di WIZARD per il cambio porta, siprevede di utilizzare:1. una comunicazione tramite chiamate remote a

metodi EJB per l’interazione con UNICA;2. una comunicazione tramite WebServices per

l’interazione con il sistema Service Control;3. una comunicazione tramite messaggi JMS con

il sistema Oreste/bus Tibco. In particolare Tibcometterà a disposizione in maniera permanenteuna coda JMS dalla quale il workflow di cambioporta preleva selettivamente il messaggio dipropria competenza sulla base di un identifica-tivo univoco.Prossimamente la soluzione WIZARD si inter-

faccerà anche con il sistema NEXT per eseguirealcuni passi del processo di diagnosi. La realizza-

FIGURA 12› La piattaforma WIZARD come soluzione per l’assistenza ai

tecnici di Telecom Italia.

OSSWorkflowinterno

OSSWorkflowinterno

MDB

CFA

Agenti WADE

Agenti Wizard

PerformanceDB

GWWGA

Console diamministrazioneConsole Operativa

Wiz

ard

Min

i Con

tain

er

MDBA

Centralized Inventory

BUS di sincronizzazione

EM/NM EM/NM

byvendors

“0.000 Nodes

CA

WCA

WPA

Log

Wiz

ard

Esec

utor

Con

tain

er

CACFAEMGW

MDBMDBA

======

Control AgentConFiguration AgentElement ManagerGatewayModel Data BaseMDB Agent

NMOSSWCAWGAWPA

=====

Network ManagementOperation Support SystemsWorkflow Control AgentWorkflow Gateway AgentWorkflow Performer Agent

FIGURA 13› Architettura funzionale della piattaforma WIZARD.




zione ha comportato la defi-nizione dei workflow speci-fici per i processo di cambioporta DSLAM (figura 14).

In un’ottica evolutiva dibreve termine, in cui la fun-zionalità di cambio porta suDSLAM sarà disponibile altecnico in campo, la proce-dura guidata precedente-mente descr i t ta dovràessere preceduta da un pro-cedura guidata di verificadell’effettivo guasto dellaporta in oggetto (figura 15).Questa diagnosi preliminarecomporta:• verifiche e attività manuali

sul permutatore su cui èattestato il cliente;

• verifiche e attività manualisui filtri (splitter in cen-trale);

• ver i f iche e att iv i tàmanuali sul DSLAM e suicavi ad essi attestati;

• ver i f iche e att iv i tà suDSLAM tramite sistemadi gestione NEXT.Un al t ro esempio di

applicazione è il “ripristinodi una Portante - ReteEricsson GSM” che sup-porta il tecnico sia nell’ese-cuzione passo-passo del-l’intervento, sia nell’intera-zione con il sistema OMC,che costituisce l’EM per leBTS di tecnologia Ericssone che è al momento mediatada un operatore di backoffice. La procedura, invece,di “sostituzione piastra di unNode B – Rete Ericsson UMTS” si presenta almomento semplicemente come un supporto cheguida passo-passo il tecnico “on field”; una suaevoluzione potrebbe prevedere l’interazione direttacon l’EM, semplificando ulteriormente l’operativitàdel tecnico. La realizzazione ha comportato la defi-nizione dei workflow specifici per i processo diripristino della Portante di una BTS Ericsson e disostituzione piastra di un Node B Ericsson.

6. Il controllo adattativo con ADEGUA

ADEGUA (ADvancEd Global Usage Adaptiveplatform), ut i l izzato s ia in WIZARD che inWANTS/NNEM, è l’architettura di controllo presta-zionale distribuita che consente di gestire in modoautomatizzato la piattaforma ad agenti con loscopo di garantirne le funzionalita’e ottimizzarne leprestazioni, utilizzando meccanismi adattativi gui-dati sia da SLA che dal consumo delle risorse

informatiche. Il principale obiettivo di ADEGUA èquindi quello di introdurre funzionalità autonomichenella gestione di piattaforme ad agenti, capaci difornire all’amministratore del sistema un insieme dicaratteristiche 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 fun-zionalità di controllo che permettono di riavviaregli agenti eventualmente in stato di failure oriposizionarli su server differenti nel caso sigenerino delle indisponibilità hardware;

• avere lo stato funzionamento non solo dei sin-goli server uti l izzati dalla piattaforma, maanche l’esatto consumo di ogni componenteapplicativa e di ogni workflow eseguito dagliagenti;

• controllare il funzionamento end-to-end dei ser-vizi forniti dalla piattaforma NNEM/WIZARD;

• definire degli SLA sui tempi di esecuzione dei

VerificaParametri

/inputStart

End

End

Parametrierrati

Abortutente

Fine Operativacon errore

Fine Operativain Validazione

Parametri

Messaggio diBenvenuto

Genera reqldcambio porta

UNICA: Portada dismettere

Ricevuto esitoKO da UNICA

Test UNICAold port

Test UNICAnew port

VisualizzaEsito UNICA OK

Test NuovaScheda

Test esitoOreste

Test esitoOreste

OresteNon Disponibile

Oreste:attesa

risposta

Scad. TimeoutFine op.

inter.

Fine Operativitàcon errore

Esito OresteOK

Cliente Res.su DSLAM IP?

Cliente Res.su DSLAM IP?

SC ModifyTKnon disponibile

Test EsitoModifyTK

SC ModifyTK:Non

disponibile

RichiestaAggiornamentochiave tecnica

Notifica esitoOK (EMAIL) SC Esito OKTest esito

ModifyTK

RichiestaAggiornamentochiave tecnica

Oreste:Scaduto

extra time

Invia NotificheKO

Datiincoerenti

NuovoTentativo

Ricevuto esitoKO da Unica

StessaPiastra

Alerta StessaPiastra

Alerta NuovaPiastra

Oreste nonDisponibile

Esito OresteKO

SC Esito KO

SC Esito OKCambio portaOK Fine Oper.

Notif. Esito Oreste KO



Oreste:attesa risposta

Alerta VecchiaPiastra

NuovaPiastra

Test Tentativie Tipo Errore

UNICAChangePort

non disponibileUNICA:

Cambio porta

Verifica Coerenza

Dati UNICA

Nuovo Tentativo

Test Tentativie Tipo Errore

UNICAGetOldPort

non disponibile

End

End

End End

End

End

FIGURA 14› Workflow completo di assistenza automatica per il “cambio porta”.




workflow, ovvero sono realizzate delle oppor-tune funzionalità di controllo che consentonodi distribuire il carico di lavoro sugli agenti inmodo da garant i re che determinat iservizi/workflow siano completati nei tempiprefissati dall’amministratore secondo le logi-che di business richieste;

• monitorare periodicamente lo stato diconsumo prestazionale dei server inmodo da consentire all’amministra-tore di identificare proattivamenteeventuali trend di crescita che portinoalla saturazione delle risorse hardwaredell’architettura, o supportarlo nellaindividuazione di una migliore alloca-zione degli agenti sui server tale dagarantire un maggiore livello presta-zionale della piattaforma WANTS eWIZARD;

• analizzare l’andamento storico deiconsumi di risorse dell’infrastrutturahardware e identificare eventuali trenddi crescita nei consumi (ad esempio,impatti prestazionali introdotti dall’ag-giunta di nuovi servizi o maggiorivolumi delle attività svolte dalla interapiattaforma controllata).L’ambiente di controllo fornito dalle

funzionalità di ADEGUA gioca un ruolo

chiave all’interno della solu-zione NNEM e WIZARD per-chè permette di mascherareall’amministratore la com-plessità legata al monitorag-gio e controllo di una infra-struttura distribuita compo-sta da migliaia di agenti.

7. Le prestazioni

La soluz ione NNEM èstata oggetto di innumere-voli prove prestazionali chehanno avuto l’obiettivo nonsolo di identificare i bench-mark prestazionali ottenibili,ma soprattutto di validareprestazionalmente l’archi-tettura basata su workflowad agent i d ist r ibui t i . Leprove prestazional i sonostate eseguite su un’archi-tet tura NNEM ident ica aquella presente in esercizio(figura 16), con l’unica diffe-renza che s i è usato unnumero di server più limi-tato. In particolare si è fattouso di hardware a low-cost,costo per unità tra i 2.000 -3.000 euro, composto daserver HP Proliant DL145dotato di due processori

AMD Opteron 246 (tecnologia x86) a 2 Ghz e 4Gbyte di RAM. I server uti l izzati sono di tiporackable ed è possibile allocarne su un RACK didimensioni tradizionali fino a 42 unità.

Si evidenzia l’importanza del numero di serverhardware su cui opera la piattaforma dal momento

WorkFlow per il

cambio porta

Tecnico back-office

Tecnico on-field

Show Message

Notific

he

FIGURA 15› Dal workflow (eseguito da agenti) a come si presenta l’assistenza sulla postazione di lavoro.

6000diagnosticheservizio ora

200 utenti web

VLAN

est

erna

per

acc

esso

da D

ACO

N/l

anet

e D

SLA

M IP

VLAN

inte

rna

1gb

it/se

cpe

r co

mun

icaz

ione

tra

i se

rver

4000attivazioniIPTV ora

HA F.C

HA F.C

Ruolo: SAN

HW: MSA 1000totale RAID 1

wants01 DL 145

wants02 DL 145

wantsdb02 -bkHP DL 585

wants15 DL 145

wantsdb01HP DL 585

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

NNEM = Neutral Network Element Manager

FIGURA 16› L’ambiente per le prove di stress prestazionali di WANTS e WIZARD.




che essendo tutte le componenti di NNEM (almenoquelle prestazionalmente più pesanti) replicabili edistribuibili su più server, è possibile ad esempioraddoppiare i livelli prestazionali ottenibili sempli-cemente aggiungendo un server o più all’architet-tura hardware di NNEM. Ad oggi per l’ambito appli-cativo in cui viene utilizzato NNEM non si è ancoraidentificato il limite massimo di server supportabilidall’infrastruttura che comunque si stima dell’or-dine delle centinaia.

Fin dai primi test prestazional i sono statisubito evidenti i grossi benefici ottenibi l i daun’architettura modulare e distribuita. Si pensi adesempio che utilizzando già un solo server per gliagenti Resource Proxy è possibile ottenere unthroughput di 5.400 creazioni servizi/ora che puòdiventare il doppio o il triplo aggiungendo rispet-t ivamente due o t re server per g l i agent iResource Proxy. Naturalmente questi sono valori

limite raggiungibili nell’ipotesi che gli apparatiabbiano tempi di risposta nulli o che le richiestedi attivazione si distribuiscano su un numero ele-vato di apparati, ad esempio 1.000-2.000 appa-rati. Valori di provisioning così elevati sono netta-mente superiori a quelli delle attuali architetturetradizionali che si attestano su valori di 2.000-3.000 attivazioni all’ora.

Con una infrastruttura di laboratorio che hacoinvolto mediamente un numero limitato di ser-ver, da quattro a sei unità, è stato comunquepossibile simulare situazioni di carico complesse

che prevedevano la contemporaneità di flussidiversi, quali provisioning, troubleshooting enavigazioni web prodotte dagli operatori NNEM.Per dare un idea dei valori in gioco, (figura 17), sisono simultate con successo situazioni che pre-vedevano la contemporaneità di 4000 attivazioniorarie di servizi IPTV, 6000 richieste orarie didignostica servizio (corrispondenti a 36000 inter-rogazioni apparato/ora) in presenza di oltre 200utenti web attivi contemporaneamente (corri-spondententi a 400.000 interrogazioni http ora-rie). In tal i condizioni di carico l’architetturabasata ad agenti distribuiti ha sempre permessodi garant i re un buon l ive l lo prestaz ionale esoprattutto non ha evidenziato significativi effettidi degrado dovuti alla contemporaneità dei flussidi carico.

In generale gli studi prestazionali sull’architet-tura ad agenti stanno dando risulati molto posi-

tivi, si pensi che ormai nel test plant di laborato-rio si utilizzano configurazioni che prevedono nonmeno di 4000 agenti con oltre 300.000 serviziconfigurati e una concentrazione tra i 1000-1500agenti per server per un totale di oltre 5 milioni diporte fisiche.

Analoghe performance si stanno ottenendoanche sul fronte WIZARD dove i l connubbioarchitettura ad agenti e micro-motori di work-flow stanno dando risultati estramente positivi intermini di flessibilità e scalabilità della soluzioni. Infattil’architettura WIZARD già a partire da tre-quattro ser-

Numero Attivazione oraria di servizi IPTVall’aumentare del numero di server che ospitano

gli agenti Resource proxy

Andamento medio dei tempi di risposta allerichieste dei flussi di Attivazione, Diagnostica

e Apertura Pagine WEB

Consumi di CPU sui server del Test Plant

Tempo durata Test - Minuti

Tempo durata Test - Minuti

Attivazione Diagnostica

Database

Apertura pagine WEB

Thro

ughp

ut -

Attiv

azio

ni IP

TV o

ra

Tem

pi m

edi d

i ris

post

a(s

ec)

Con

sum

o C

PU (

%)

14.000

765432

10080604020

0

1

1 2 3 4 5 6 7 8 9 10 11

1 2 3 4 5 6 7 8 9 10 11

012.000

10.000

8.000

6.000

4.000

2.000

01 2 3

NNEM - Agenti MaNNEM - Agenti RP (1)

WebServerNNEM - Agenti AANNEM - Agenti RP (2)

FIGURA 17› Indicatori di prestazione della piattaforma WANTS e WIZARD.




ver permette di gestire diversi centinaia di cambi portaal minuto con altrettanti operatori connessi remota-mente alla piattaforma.

Gli studi prestazional i effettuati in questiann i hanno permesso d i va l idare i mode l l iarchitetturali basati ad agenti anche per la rea-lizzazione di applicazioninell’ambito degli OSS. Inpar t ico lare s i sot to l ineacome ormai tutti i vendor,qua l i HP, IBM e SUNs tanno p romuovendoarchitetture hardware piùsnelle basate su batteriedi blade server piuttostoche i tradizionali supercal-colatori quali ad esempiogli HP SuperDome.

La soluz ione NNEM èab i l i tan te a l l ’u t i l i zzo d iqueste innovat ive in f ra-s t ru t tu re che consent i -ranno d i centupl icare leperformance attualmenteottenibili dai sistemi tradi-z iona l i , favorendo ne l los tesso tempo l ’abbat t i -mento dei costi infrastrut-turali grazie all’util izzo dihardware low-cost.

8. Evoluzioni e conclusioni

Nell’articolo sono state evidenziate le specifi-cità e le innovazioni necessarie per garantire affi-dabilità, flessibil ità, robustezza e adattabilitàdelle nuove architetture gestionali. Gli obiettiviriguardano essenzialmente la possibilità di ridurrelo spending degli OSS e degli EM, rendere piùflessibile la riconfigurazione degli OSS al variaredelle tecnologie di rete, ridurre progressivamenteil numero di OSS specializzati, razionalizzare ilnumero delle funzionalità oggi diffuse e replicatein più di un OSS, permettere univocità ed omoge-neità nei processi elaborativi (flussi di processoautomatici), garantire allineamento degli inven-tory, correttezza nel recovery e real-time nellaesecuzione e assicurare una vista end-to-end alivello di rete, di servizio e di cliente.

L’evo luz ione de l le a t tua l i a rch i te t ture d igestione (basate su infrastruttura applicativa efunzionale di tipo NGOSS) porterà alla messa afattor comune delle logiche di accesso ai dati edi elaborazione, secondo criteri e funzionalitàcondivise su base processo. Le logiche (sottoforma a di workflow distribuibili dinamicamentesulle singole componenti SOA), renderanno pos-sibili nuove forme di gestione della rete, dei ser-vizi e del personale operativo, garantendo moni-toraggio, coerenza informativa e tracciabilità pro-cessiva. La componentizzazione del sw (v iaworkflow) e la parametrizzazione dei processirenderanno le attuali architetture OSS più flessi-

bili, tali da ridurre gli elevati costi che oggi siconcentrano primariamente nella system integra-tion (figura 18).

È prevedibile per il prossimo futuro che lagestione di milioni di oggetti in rete (apparati,router clienti, infrastrutture di casa-ufficio, termi-

nali), tramite l’adozione di paradigmi e di archi-tetture OSS basate su componenti SOA ad agentie micro-workflow distribuiti, richieda “anche” l’a-dozione e quindi la sperimentazione, di sofisticatimotori di ricerca, che come Google, siano ingrado di recuperare in tempo reale l’anagraficadella rete, i processi automatici, le procedure dilavoro e quindi tramite algoritmi semantici, corre-lare queste informazioni per generare ulterioridati utili ai progettisti di Telecom Italia.

[email protected]@[email protected]

BSS

OSS liv-1

OSS liv-2OSS

OSS

EM EM EM EM

Network F & M2006

SERVIZI

SERVIZI

AZIONI - ESPERIENZA

WORKFLOW

PROCESSI

FUNZIONI

COMANDI

OSS OSS OSS

OSSService Service

Neutral Process

Neutral EM

standard

aperte

Knowledge

Self-Adapt

Iperflow

Iperflow

WCE

ESB di ORCHESTRAZIONEGTW

BSS

GTW

NGN2

> 2010

BUS di ORCHESTRAZIONE

BSSEMNB

GTWNGN2

OSSWCE

=======

Business Support SystemsElement ManagerNarrow BandGateWayNext Generation Network 2Operation Support SystemWorkflow Creation Environment

FIGURA 18› Un nuovo paradigma: l’esternalizzazione delle interazioni OSS-rete-servizi.




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 Service Bus

FIPA Foundation for Intelligent Physical Agents

FSC Framework Service 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

— ABBREVIAZIONI

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 Service Creation & Control Environment

SGSDH-NM SDH Network Management

SID Shared Information Data

SLA Service Level Agreement

SNMP Simple Network Management Protocol

SOA Service Oriented Architecture

SQM Service Quality Management

TMN Telecommunication Management Network

TTM Trouble Ticket Management

TTM Trouble Management Ticket

VAS Valued Added Services

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 Services Description Language

WSS Web Services Security




Danilo Gotta si è laureato con lode inScienze dell ’ Informazione all ’Università diTorino nel 1990. Opera presso la struttura diinnovazione di Telecom Italia (già TILAB eCSELT) dal 1993 dopo un’esperienza di dueanni nel l ’ambito di svi luppo software persistemi di modellizzazione a reti di code in unazienda francese (Simulog). Ha coordinatosia progetti software che progetti orientati altesting prestazionale di sistemi software, in

particolare durante l’allestimento dei sistemi di gestione per larete SDH di Telecom Italia e la predisposizione di metodologiainnovative per la misurazione delle prestazioni di applicazioniweb e distribuite. Dal 2003 si è specializzato nella progettazioned i una so luz ione tesa a rendere adat t i ve le capac i tàcomputazionali di sistemi distribuit i sia nel sw che nell ’hw(WANTS/ADEGUA). Infine dal 2006 è referente per la tematicaWIZARD e delle logiche di potenziamento della piattaformaWADE. È autore di una decina di domande di brevetto sutematiche prestazionali e sull’applicazione di tecnologie basatead agenti e workflow ai contesti di gestione della rete e delknowledge management oltre che autore di pubblicazioni inambito Computer Measurement Group.

Giuseppe Covino si è laureato con lodein Ingegneria Elettronica al Politecnico di Torinonel 1995 con specializzazione in Informatica, nel1996 è assunto al centro ricerche di TelecomItalia (CSELT) nell’area “Gestione di Rete”. Finoal 1998 si occupa di diversi progetti Europeirelativi alla gestione delle reti di accesso a largabanda e dal 1999 partecipa alla gara e al rolloutper il dispiegamento della tecnologia ADSL inTelecom Italia. Dal 1999 guida la progettazione

e realizzazione di alcuni OSS (SMALL per il provisioning ed il trouble-shooting dei servizi, CANTO per il monitoraggio della qualità deidoppini ) e dal 2000 fa parte di gruppi di lavoro delTeleManagementForum (Architetture, Modelli informativi, Interfaccegestionali) come rappresentante di Telecom Italia. Dal 2003 èresponsabile del progetto di ricerca WANTS che ha portato allareal izzazione del lo strato NNEM. Tiene frequent i corsi epresentazioni sulla gestione di reti e servizi e la loro evoluzione inambito italiano (TILS, Politecnico di Torino) ed internazionale (eventiI IR e TMF). È co-autore di diverse domande di brevetto suarchitetture ed implementazioni di sistemi di gestione.

Antonio Nasuto si è laureato in ingegneriaelettronica con special izzazione inTelecomunicazione presso l ’Università diBologna. Dal 1997 ha avviato la suacollaborazione con CSELT (oggi TILab) ed hainizialmente lavorato alla tematica di gestione direte e dei serviz i . Dal 2001 ha operatoall’inserimento in rete della nuova piattaforma digestione ed in particolare si è’ specializzatosul le tecniche di monitoraggio e test ing

prestazionali degli OSS. Dal 2004 nell’ambito dell’area di OSSInnovation ha operato attivamente alla definizione di strumenti etecniche per il controllo di applicazioni fortemente distribuite inambienti blade server. In tale ambito ha ideato diversi brevetti erealizzato soluzioni innovative per il controllo delle performance.


La gestione delle nuove reti - claudio cancelli · COVINO › GOTTA › NASUTO • La gestione...

Documents

Transcript of La gestione delle nuove reti - claudio cancelli · COVINO › GOTTA › NASUTO • La gestione...