CONFERENZE

Tele Management World (TMW)

Nizza, 16-19 Maggio 2005
Guido Bruno, Giuseppe Covino, Alberto Delpiano, Bruno Foresi, Andrea Pinnola, Enrico Ronco, Marco Ughetti (Telecom Italia Lab) 1. Introduzione Il Tele Management World stato organizzato dal TMF (TeleManagement Forum, www.tmforum.org), gi noto come Network Management Forum, che costituisce unorganizzazione no profit, cui aderiscono pi di 400 aziende fra gestori incumbent e new entrant , fornitori di apparati/soluzioni di gestione, system integrators , aziende di consulenza, ... . Il TMF ha lobiettivo di fornire le linee guida strategiche e le soluzioni pratiche per migliorare la gestione e lesercizio degli information and communications services. Il convegno, tenutosi a Nizza dal 16 al 19 Maggio 2005, costituisce, con una cadenza semestrale (alternativamente in Europa e negli Stati Uniti/Asia), levento pi significativo a livello mondiale sulla tematica della gestione delle reti e dei servizi. Ledizione TMW 2005 ha visto una partecipazione molto elevata sia in termini di iscritti (circa 2300 delegati) che di vendor (pi di 110). Ci, paragonato con i dati relativi alle presenze del periodo 2002-2004, pu senzaltro essere considerato come un indicatore significativo circa il generale miglioramento del business del settore. Si deve comunque sottolineare che la presenza di delegati dei Service Provider nordamericani non ancora paragonabile (come lo era alcuni anni fa) alla presenza della controparte europea. Relativamente alle principali ten-

denze emerse, senza dubbio laspetto fondamentale la necessit, per le Telco Company di avviare, potenziare e completare la predisposizione delle proprie piattaforme gestionali al Management delle NGN (Next Generation Networks) convergenti (reti multi-service, multi-protocol, IP-based, con livelli di QoS garantiti) attraverso ladozione e lattuazione di paradigmi tesi alla progressiva eliminazione degli Element Manager (EM), alla adozione sempre pi marcata di soluzioni java based, con esplicito riferimento anche allopen source . Ci implica la necessit di introdurre livelli di flessibilit e di apertura delle piattaforme di gestione finora non applicati se non addirittura ipotizzati. Al TMW stata ribadita da pi versanti la necessit di una maggiore apertura delle interfacce di rete a garanzia dellinteroperabilit. altres emerso, in modo pi netto rispetto al passato, che un ruolo importante in questo momento storico sar la standardizzazione, che dovr consentire la definizione di funzionalit ele-

mentari condivise, sulle quali potranno essere sviluppate soluzioni competitive gestionali. Infine, un argomento legato al precedente relativo allaspettativa sempre pi marcata che i gestori e i vendor ripongono sul TMF come fattore abilitante per conseguire tali obiettivi: in particolare il Forum deve continuare a rivestire un ruolo di facilitatore per questa trasformazione, privilegiando lo sviluppo prototipale di soluzioni technology specific in parziale discontinuit con il recente passato, nel quale sono stati predominanti lo studio e la formalizzazione di framework technology neutral. Larticolo riporta gli interventi pi significativi dei CTO intervenuti alla Conferenza e i maggiori risultati emersi nei vari ambiti della gestione e dei progetti dimostrativi Catalyst.

2. Interventi dei CTO La relazione di Stefano Pileri (CTO di Telecom Italia), ha posto enfasi sulla strategia di Telecom Italia, per il periodo 2005-2007,

BSS NGOSS Arch

Inventory

OSS Liv1

Inventory Mediation Inventory

Vendor dependent

EM

EM

EM

AG

AG

AG BSS EM NGOSS OSS

= = = = =

Access Gateway Business Support System Element Manager New Generation OSS Operation System and Software

FIGURA 1 Stato di intermediazione per una gestione di rete neutral vendor.

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

143

CONFERENZE
per ci che concerne lofferta convergente di servizi innovativi VAS (Value Added Service), nonch sullevoluzione prevista, sia a livello di architettura di rete che di piattaforma di gestione (OSS), per abilitare lofferta di servizi innovativi IP based. Relativamente allevoluzione della piattaforma di gestione stato evidenziato lintento di Telecom Italia di dotare la propria piattaforma di gestione di uno strato di Mediation che consenta un reale disaccoppiamento tra gli OSS best of bread dalle soluzioni proprietarie (Element Management) dei singoli costruttori di apparati di rete (figura 1). Limportanza e la rilevanza del messaggio (coniato con lo slogan softwaring the network) sono dati dal fatto che Telecom Italia risulta essere il primo gestore a dichiarare, in un evento di portata mondiale quale il TMW, la sua intenzione a procedere in questa innovativa direzione. La relazione di Mathew Bross (CTO di BT), ha presentato liniziativa 21 st Century Network che consiste in un programma di profonda trasformazione della rete di BT al fine di trasformarla in una Global Networked ICT Company. Sono evidenti alcune analogie con quanto presentato da Telecom Italia, ovvero: (a) mantenere quote di mercato esistenti ed allargare il business in ambiti contigui; (b) sfruttare le nuove tecnologie per fornire servizi sempre pi integrati e convergenti, facendo leva su una piattaforma di rete integrata e seamless (accesso in reme/fibra pi core IP-MPLS-WDM); (c) evolvere e trasformare i propri sistemi OSS sulla base di una roadmap nella quale siano contemplati ladozione di standard comuni, lacquisto di package COTS (Common Off The Shelf) e/o lo sviluppo integrato di soluzioni proprietarie (figura 2). Il programma 21 s t Century Network prevede un investimento totale di circa 10 miliardi di sterline (circa 2 miliardi di sterline per anno) fino al 2008, a valle del quale si attende una riduzione di OpEx dellordine di un miliardo di sterline per anno. Fattore comune allintroduzione dei due programmi stato laccento posto sulladozione di standard, utili per la generazione di nuove opportunit di mercato e alla riduzione di costi dintegrazione tra OSS. Per quanto riguarda gli standard adottati, OSS/J ha scelto il framework J2EE per limplementazione dellarchitettura di un OSS, motivandola con lampia offerta di tool sul mercato e con lelevato numero di sviluppatori software oggi presenti. Inoltre, con la pubblicazione delle specifiche di J2EE 1.4, OSS/J si focalizzata sullo sviluppo delle OSS/J Core API via Web-Services analoghe a quelle precedentemente definite tramite XML sul servizio di comunicazione JMS.

3. Soluzioni OSS/J Un importante settore di investigazione ed innovazione nel contesto degli OSS riguarda lallineamento tra i principi NGOSS (New Generation OSS), che sono indipendenti dalle tecnologie software e concernenti in particolare le architetture e la modellazione dei dati con il lavoro svolto nellambito del programma OSS/J del TMF, focalizzato sullimplementazione vera e propria dei principi NGOSS.

End user

~5.5k nodes

~2k nodes

~1k nodes

~300 nodes

~100 nodes

~15 nodes PSTN

Copper PSTN KStream DSL PDH SDH Access SDH VC-12 Access

Leased lines

ATM IP SDH VC-4 PDH

Fibre

PDH Access

Multi-service access

Converged core

Copper DSL Fibre & Copper

Class 5 Call Server WWW IP-MPLS-WDM Agg Box Content ISP ~100 nodes PDH PSTN SDH WDM = = = = Plesiochronous Digital Hierarchy Public Switched Telephone Network Synchronous Digital Hierarchy Wavelength Division Multiplexing

End user ATM DSL IP MPLS = = = =

~5.5k nodes AsyncrhonousForward Mode Digital Subscriber Line Internet Protocol Multi Protocol Label Switching

FIGURA 2 Evoluzione della rete di prossima generazione per BT (21st).

144

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

CONFERENZE
Per quanto riguarda la standardizzazione delle interfacce per il supporto alla definizione ed esecuzione di processi eTOM (enanched Telecom Operations Map) e per il supporto alla definizione/modifica del SID (Shared Information Data model), stata presentata una carrellata delle OSS/J Core API (Inventor y API, Service Activation API, QoS API, Service Qualit API, ). Di rilievo la disponibilit di Reference Implementations e di kit di test resi disponibili da OSS/J alla comunit (figura 3).
Connector Legacy Application EAI Legacy Application

JMS Bridge J2EE Application API Java upon JMS/IIOP/RMI XML upon JMS Any J2EE Compliant Java XML Application Server API API Java upon JMS/IIOP/RMI XML upon JMS API Connector Connector Native implementation

B2B Web Services enabled Application ebXML SOAP UDDI WSDL

Wrapping and Adapters Strategies API B2B EAI J2EE JMS = = = = = Application Programming Interface Business to Business Enterprise Application Integration Java 2 Enterprise Edition Java Message Service

4. OSS Open Source: quali prospettive Per capire meglio come i prodotti Open Source possono impattare gli OSS importante innanzitutto suddividere una tipica architettura di OSS nelle sue componenti principali. Per quanto riguarda linfrastruttura (sistemi operativi, application server, web server, database, ...) e gli strumenti di sviluppo software, i tool Open Source appaiono maturi; lo dimostra la larga diffusione di sistemi operativi come Linux, web server come Apache e ambienti di sviluppo come Eclipse nelle grandi industrie. La presenza di tool open source nellambito delle componenti OSS invece molto scarsa. Anche nellarea delle interfacce OSS la presenza di tool non molto ampia: in questo caso pi importante la definizione di interfacce standard e la loro adozione da parte di tool COTS. I benefici delladozione dell Open Source sono molteplici: sviluppi rapidi, alta qualit per la presenza di un gruppo molto ampio di sviluppatori ed utilizzatori, la disponibilit dei sorgenti e la riduzione dei costi. Tuttavia emerge il fatto che sia conveniente il loro utilizzo in componenti architetturali comuni ai vari OSS: soluzioni proprietarie e quindi controllabili su componenti funzionali core degli OSS sono invece auspicabili (figura 4).

SOAP = Simple Object Access Protocol UDDI = Universal Description Discovery Integration WDSL = Web Services Description Languages ebXML = Electronic Business XML

FIGURA 3 Framework OSS/J.

I maggiori rischi che comporta quindi lutilizzo di tool Open Source riguardano: supporto: eventuali servizi a supporto degli sviluppatori sono a pagamento; warranty: non ci sono garanzie sulle tempistiche di correzione dei bachi; controllo: lo sviluppo di parti aggiuntive non in mano agli

utilizzatori; termini di licenza: il tipo di licenza del tool open source adottato impatta il tipo di rilascio del software che lo impiega, ossia si presentano diversi vincoli nell'utilizzo di tool open source in applicativi utilizzati per l'esercizio del business.

COTS Interfaces

COTS Interfaces

Open Source Interfaces & Adaptors

Open Source Interfaces & Adaptors

Open Source Tools

Open Source Tools

COTS OSS Components COTS Tools

COTS OSS Components

COTS OSS Components COTS Tools Open Source Infrastructure Open Source Interfaces & Adaptors

Open Source OSS Components

COTS Infrastructure

Open Source Infrastructure

COTS Infrastructure

No Open Source Mature OSS market

Open Source Tools & Infrastructure

Open Source OSS Components

COTS = Common Off The Shelf OSS = Operation System and Software

FIGURA 4 Framework Open Source per OSS.

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

145

CONFERENZE
5. NGN La tematica NGN (Next Generation Network) stata affrontata in tutte le sessioni in termini piuttosto generali, senza riferimenti circostanziati e rigorosi al framework NGN cos com declinato dagli standard bodies (ITU, IETC, ETSI). Il framework NGN stato liberamente interpretato ed utilizzato come spunto per affrontare in termini generali il tema della gestione dei servizi VoIP, Broadband, Value Added e per qualche digressione sulla tematica, in questo momento di grande forza attrattiva, della convergenza fissomobile. Molti interventi si sono concentrati sullelemento del cambiamento e su quanto questo renda necessario un nuovo approccio alla gestione, meno orientato alle specifiche tecnologie e fortemente indirizzato ad una visione end to end del servizio offerto al cliente. Uno stato di fatto che accomuna le piattaforme di gestione di molti Service Provider infatti la proliferazione di sistemi technology dependent, la coesistenza di sistemi legacy con soluzioni OSS pi recenti, la presenza di silos funzionali, la mancanza di Service/Network Inventory cross-tecnologia, una netta separazione fra OSS e BSS. La qualit del servizio offerto al cliente spesso compromessa da unimpostazione della gestione troppo focalizzata sulla rete e poco indirizzata ad una visione attenta di quanto percepito dal cliente. La necessit di orientare la gestione da una visione Network Centric ad una visione Service/Customer Centric , quindi, un driver di cambiamento fondamentale, Un altro aspetto di rilievo stata la constatazione (peraltro nota) che lOperatore, non sapendo quale sar la tipologia di servizi vincente (e la loro penetrazione nel mercato), si dovr dotare di Service Delivery Platforms e di Management Platform veramente flessibili. 6. Semplificazione dei processi Lean Process Nellambito delle iniziative del TMF stato costituito un Team (il Telecom Operation Benchmarking team, TOB team) con lo scopo di definire misure e KPI (Key Performance Indicator) utili a comparare e valutare le operation di tipo Lean (semplice, lineare). Lidea di base per cui stato costituito il Team definire una serie di misure in relazione alle quali un operatore possa capire se sufficientemente Lean nella gestione dei propri processi. Per fare ci gli operatori necessitano di misurare accuratamente le proprie performance e confrontare i propri risultati con i migliori nel settore. Lo scopo del TOB , quindi, quello di definire KPI appropriati per valutare la snellezza delle operation e individuare esempi di eccellenza nel settore. In particolare lobiettivo di fornire un report pubblicato regolarmente (Lean Operator Report) nonch un database aggiornato che possa essere interrogato su richiesta. I KPI individuati saranno specifici per le Lean Operation valutando le Line of Business o i Service Offering Level; non verranno invece definiti, ad esempio, KPI di prestazione della rete in quanto non ritenuti rilevanti per la definizione di Lean. 7. Billing & Revenue Assurance Si sottolineato la necessit di una implementazione adeguata per il supporto ai nuovi servizi dati, soprattutto se offerti con modalit di pagamento pre-paid. Le tradizionali soluzioni di billing e charging hanno infatti dei limiti insuperabili per il supporto di questa modalit (figura 5). Le soluzioni emergenti prospettano di gestire in modo efficiente i servizi dati (non la voce). Questa soluzione offre, inoltre, i seguenti vantaggi: si applica a soluzioni di rete multivendor, permette di applicare modelli di pricing, sia pre-paid che post-paid ed in grado di gestire anche i servizi per il content delivery. La societ RateIntegration ha un prodotto di valorizzazione e pricing denom i n a t o P r i c e M a k e r, c h e d i chiara di essere particolarmente flessibile, in grado di implementare rapidamente modelli di pricing molto complessi. La parte pi interessante stata la presentazione di tre case study di implementazione del prodotto: presso BT, integrato al prodotto di billing Geneva, di Convergys; presso TeleSonera, per il lancio di nuovi servizi;

Post-paid Pre-paid IN/Balance Mgr Mediation Billing Voice Rating No Usage reporting, Access control, Dialog mgt Data SMS Yes IP Post-Paid Yes IP Pre-Paid Yes

High granularity High granularity IP data (inc MMS) IP data (inc MMS) On and off-portal On and off-portal

VoluBill
Network D2CP

Internet Dialog mgt Dialog mgt

D2CP = Dialog Session MMS = Multimedia Message Service SMS = Short Message Service

FIGURA 5 Schema di riferimento per soluzioni di RA di nuova generazione.

146

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

CONFERENZE
presso iPass, fornitore di soluzioni di connettivit a livello mondiale. Azure ha presentato la propria indagine realizzata nel 2004 sul tipo di percezione che le aziende di telecomunicazione hanno della tematica di RA (Revenue assurance), Operator Attitudes to Revenue Assurance 2004. I principali risultati sono sinteticamente: La media delle perdite reali di fatturato decrementata complessivamente dal 13.7% del 2003 al 10.7% del 2004, segno inequivocabile che sul fronte delle RA generalmente tutti stanno operando efficacemente; Le maggiori cause di perdita di fatturato non sono cambiate dal 2003 e rimangono: un processo di gestione e procedure troppo inefficienti; lintroduzione di nuovi prodotti e lapplicazione di nuovi prezzi; la non correttezza o lincompletezza dei CDR prodotti dagli elementi di rete le frodi. La stima percepita delle perdite di fatturato, da parte degli Operatori intervistati, passa dal 2.4 % del 2003 al 1.87 del 2004. La soglia di perdita che si ritiene generalmente accettabile sotto l1%. Insomma, secondo tale report, gli Operatori affermano che la perdita di fatturato accettabile (valore percepito) sia intorno all1%, mentre invece la perdita reale misurata , tuttora, al di sopra del 10%. Sembra che generalmente gli Operatori Mobili abbiano perdite di fatturato superiori agli Operatori fissi e che gli Operatori pi grandi soffrano di perdite pi contenute rispetto agli Operatori di dimensioni pi piccole. Infine, sembra che gli Operatori dellEuropa Occidentale abbiano perdite di fatturato minori rispetto alla media globale. 8. Sessioni dimostrative: i Catalyst Con il termine Catalyst Projects sintendono le sessioni dedicate alla dimostrazione di prototipi e di sistemi e soluzioni organizzate da parte di pool di vendor/gestori per la soluzione pratica di problematiche concrete evidenziate dagli stessi gestori telecom (che ricoprono il ruolo di sponsor). zione di nuovi processi e la riduzione dei costi per lo sviluppo del sistema. Al progetto collaborano sia Service Provider (BT e COLT), fornitori di applicazioni (Tibco, Teleca, QinetiQ, ).

8.2 Catalyst BAM

8.1 Catalyst BMP

L'obiettivo del catalyst BPM (Business Process Management - di fase 2) di dimostrare che, tramite l'utilizzo dei frameworks di maggiore diffusione del settore quali eTOM (processi), SID (dati) e NGOSS (architetture), integrati con i prodotti COTS , possibile modificare rapidamente e semplicemente i processi di business per rendere pi competitiva l'offerta di servizi di telecomunicazioni. Lo scenario su cui sono stati verificati i concetti l'implementazione del provisioning di servizi IP-VPN e la gestione dei processi per la fornitura del servizio di mobile TV. Sono state indentificate tre caratteristiche principali su cui la strategia del BPM deve basarsi: controllo e ripetibilit dei processi, tecnologie agili e di connettivit, persone che forniscano la conoscenza e l'innovazione. La metodologia iBMP (implementing BMP) comprende tutte queste caratteristiche, integrando il ciclo di vita definito in NGOSS con aspetti di business process ed adottando i migliori strumenti, tecniche, standard e frame work ad oggi disponibili. I potenziali benefici dell'adozione della metodologia iBPM sono l'integrazione tra i processi e gli OSS, maggiore chiarezza nella descrizione dei processi ed assegnazione delle responsabilit, la riduzione del costo delle applicazioni, il riutilizzo dei processi eseguibili, la riduzione dei tempi di introdu-

L'obiettivo del catalyst BAM (Business Activity Monitorino) ha lobiettivo di fornire una dimostrazione concreta della capacit di monitorare i processi impiegando gli standard del TMF. Lo scopo quello di fornire ad un Service Provider la c a p a c i t d i a g i re p ro a t t i v a mente nella identificazione di problemi al fine di evitare disservizi e violazioni di SLA nellambito dei processi monitorati. Nello showcase stato dimostrato il caso di un processo di fault management per una rete IP-VPN e la evidenziazione in tempo reale di problemi di processo con possibilit di drill down per identificare le componenti che hanno problemi. Limpiego di architetture e applicazioni conformi alla filosofia NGOSS agevola limplementazione di tale soluzione. Al progetto collaborano sia Service Provider (Vodafone e COLT), fornitori di applicazioni (ORM Vision, webMehtods) e Systems Integrator (ATOS Origin, Cognizant Tech Solution).

8.3 Catalyst Open OSS

Il Catalyst Open OSS promosso da: BT, Cable & Wireless, COLT, Covad, NTT, Group, QinetiQ, Vodafone, UK, Agilent Technologies, AutoMagic KB LLC, Budapest University of Technology and Economics, Cognizant, Invocom, Sun Microsystem, and University of Southampton. Esso rappresenta il primo passo di un disegno pi vasto chiamato Open OSS Iniziative (www.openossinitiative.org). Tale catalyst si prefigge di affrontare uno dei

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

147

CONFERENZE
p ro b l e m i c h e a ff l i g g o n o g l i standard, ossia la mancanza di prodotti e/o componenti che li implementano. In particolare, gli obiettivi delliniziativa sono: adottare lapproccio NGOSS per lo sviluppo di una sandbox di software Open source; rendere il software e la documentazione associate liberamente disponibile allindustria; fornire feedbacks sullesperienza acquisita durante limplementazione alle attivit di standardizzazione OSS; fornire ai ricercatori un veicolo per confrontarsi con i problemi reali dei Service Providers. Secondo questa iniziativa lo sviluppo di una sandbox che fornisce un ambiente OSS modulare realizzato con software open source, COTS e pacchetti sviluppati ad hoc la chiave per raggiungere tali obiettivi. La sandbox conterr, oltre alle tipiche funzionalit OSS anche altro software come il software Enterprise (application servers e database) e gli adaptors per lintegrazione verso standards e tools di sviluppo. Il software open source sviluppato sar rilasciato sotto la licenza Apache 2.0. Ci si aspetta che tale implementazione fornisca feedback significativi sullutilizzo di TMF-related standards quali: eTOM, SID, OSS/J. Tale iniziativa spera di realizzare componenti OSS utilizzabili nel giro di due, tre anni. Il Catalyst OpenOSS pu essere visto come il primo step delliniziativa Open OSS, tramite la realizzazione di una prima sandbox funzionante, relativamente a un semplice case study. Da un punto di vista tecnico il prossimo step dichiarato della OpenOSS Initiative quello della applicazione alla gestione di servizi in un ambiente IP mobile multimediale. In questo modo saranno affrontate le sfide implementative con cui gli operatori wireline e wireless devono fare i conti quando forniscono servizi multimediali basati su 3G, WiFi , WiMAX, DSL, ... . Da un punto di vista organizzativo si dichiara la volont e la necessit di cooperare con il TMF e con liniziativa OSS/J presentando i benefits dellapproccio open source. Inoltre, ritenuto fondamentale che vengano affrontati non solo semplici case studies ma anche casi reali allo scopo di testare e sviluppare OSS standard.
8.5 Catalyst Business Agility

8.4 Catalyst NGOSS/MDA

Il catalyst NGOSS/MDA (AT&T, BT Group Plc, QinetiQ; Sonic Software, AutoMagic KB, Tata Consultancy) cerca di rispondere alle esigenze degli operatori di integrare varie applicazioni OSS/BSS al fine di realizzare nuovi servizi in modo rapido, accrescere il riuso dellasset aziendale e aumentare la soddisfazione del cliente. La soluzione proposta di basarsi su un approccio model driven prendendo come riferimento la Model Driven Architecture (MDA) di OMG per mettere insieme diverse tecnologie, generando degli artefatti che semplificano il compito di sviluppare gli OSS di nuova generazione. Le tecnologie prese in considerazione sono: metodologia NGOSS; service-oriented architectures (SOAs); standard come OSS/J e i Web Services. Si evince che MDA for nisce strumenti per la gestione dei dati (in termini di verifica della sintassi, cattura della semantica per una successiva valid a z i o n e ) e l i n t e r p re t a z i o n e delle informazioni in differenti forme (ad esempio notifiche diverse). Infatti consente di costruire modelli e meta-modelli con una semantica associata molto ricca e di semplific a re l a t t i v i t d i t r a s f o r m a zione di modelli platform-independent in implementazioni platform-specific.

Il catalyst Business Agility (France Telecom, IBM, Ceon, Patni, Pantero, Covad Communication, e Internap;), si propone di dimostrare come lintegrazione di vari componenti OSS tramite un modello dati comune renda pi rapido e pi semplice il delivery dei servizi. Il modello scelto il SID (Shared Information/Data Model) sviluppato nellambito del programma NGOSS del TMF. Per quanto concerne la parte dintegrazione a livello di interfaccia sono state utilizzate le API di OSS/J (OSS through Java), di Multi-Technology Operations Systems Interface (MTOSI) e alcune API proprietarie. Lo scenario di riferimento del progetto lattivazione di nuovi servizi e la conseguente ge stione dellinventario. Esso stato specificato da France Telecom in due parti al fine di dimostrare due diversi utilizzi del SID e delle Inventory API OSS/J. In questo scenario il SID viene utilizzato come un mediation layer che consentirebbe al provider di automatizzare i processi manuali di rilevazione del tipo di ordinativo ricevuto e conseguente inoltro (ad esempio via email o fax) al partner. Infatti si possono definire e mantenere centralmente delle regole relative al trattamento degli ordinativi, aggiungere nuovi tipi di prodotti e nuovi partner per quelli gi esistenti aggiungendo nuovi modelli senza che i modelli esistenti debbano essere rivisti.

9. Modello informativo MTOSI Nel TMW, insieme alle molteplici presentazioni e dimostrazioni di prodotti e soluzioni prototipali, sono state anche effettuate alcune presentazioni e sessioni dimostrative relativamente alliniziativa MTOSI (Multi Technology Operations Systems Interface). MTOSI un GdL del TMF, nato nel 2003 come sotto-

148

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

CONFERENZE
gruppo del team MTNM (Multi Technology Network Management), che ha come obiettivo la specifica di uninterfaccia standard ed aperta fra OS (Operations Systems) allo scopo di supportare il Service & Network Management. previsto che lo standard copra tutte le tecnologie di trasporto, dal livello 1 al livello 3 e anche servizi ed applicazioni quali VoIP. In particolare il GdL MTOSI ha adottato il modello informativo sviluppato in ambito MTNM per linterfaccia NMS-EMS e lo ha esteso con lintroduzione del concetto di Management Domain. Al momento le specifiche disponibili riguardano le aree dell Inventory Management e dell Alarm Management (retrieval & notification). Al TMW sono state fornite due dimostrazioni in stile Catalyst project dellutilizzo di MTOSI: Implementazione delle operations di getInventory tra il sistema di IM (Inventory Management) e gli EMS e tra il sistema di Service Assurance e il sistema di IM, ed implementazione delle operations di Get Alarm tra il sistema di Service Assurance e gli EMS. I sistemi utilizzati implementano gi linterfaccia MTNM v1.0, e ci, a detta delle aziende coinvolte nella dimostrazione, ha consentito una notevole semplificazione della problematica dellinterfacciamento fra i sis t e m i . Ta l e d e m o s t a t a realizzata con la partecipazione di Lucent, Telcordia e Siemens. Possibilit di far comunicare il sistema Nortel Optical N e t w o r k M a n a g e r a l p ro dotto di Inventory Management di Cramer, sviluppato dagli stessi fornitori. Un aspetto rilevante riguarda infine, le relazioni tra il SID ed altri modelli informativi e dati, in particolare MTNM e MTOSI all'interno del TMF e CIM i n a m b i t o D M T F. S u q u e s t i fronti, sono stati annunciati significativi progressi nell'attivit di mapping tra i vari modelli, che, tra l'altro, ha comportato la revisione di alcuni elementi del SID per migliorarne l'allineamento con MTNM e MTOSI. Va infatti ricordato come MTNM e MTOSI si ispirino allo stesso modello informativo. Tali mapping , di estremo interesse per valutare il grado di compatibilit o meno dei vari modelli, sono in corso di revisione. A questo proposito, va rilevato come il SID si stia gradualmente proponendo come una mappa informativa dei dati (analogamente a quanto l' eTOM per i processi), preparando la strada all'utilizzo di modelli dati specifici (per esempio MTOSI) per la fase di implementazione. Infatti, il SID presenta caratteristiche espressive molto potenti (pattern) ed la pi vasta copertura di domini tra i modelli informativi disponibili (dalla porta di un apparato al portafoglio di offerte commerciali), ma porta con s anche una complessit difficilmente gestibile nella sua interezza per la fase implementativa di un sistema o di una piattaforma di gestione.

ETSI

API

ABBREVIAZIONI

Application Programminig Interface ATM Asynchronous Transfer Mode BAM Business Activity Monitoring BPM Business Process Management BSS Business Support System COTS Common Off The Shelf CRM Customer Relationship Management DSL Digital Subscriber Line EMS Element Management System eTOM enhanced Telecom Operations Map

European Telecommunications Standards Institute FCAPS Fault, Configuration, Performance, Accounting, Security FCC Federal Communication Commission J2EE Java 2 Enterprise Edition JCP Java Community Project JMS Java Message Service KPI Key Performance Indicator MDA Model Driven Architecture MPLS Multi Protocol Label Switching MTNM Multi Technology Network Management MTOSI Multi Technology Operations Systems Interface NGOSS New Generation Operation Systems and Software NGN Next Generation Network OSS Operation System and Software OSS/J OSS through Java Initiative PDH Plesiochronous Digital Hierarchy PSTN Public Switched Tlephone Network RA Revenue Assurance SDH Synchronous Digital Hierarchy SID Shared Information Data Model SOA Srervice Oriented Architecture SOAP Simple Object Access Protocol SLA Service Level Agreement TMF TeleManagement Forum TMW TeleManagement World TOB Telecom Operations Benchmarking UDDI Universal Description Discovery Integration VAS Value Added Service VoIP Voice over IP WDM Wavelenght Division Multiplexing WDSL Web Services Description Languages VPN Virtual Private Network WFM Work Force Management

NOTIZIARIO TECNICO TELECOM ITALIA Anno 14 n. 2 - Dicembre 2005

149