You are on page 1of 0

NOTIZIARIO TECNICO TELECOM ITALIA - Anno 11 n.

2 - Set t embre 2002 75


Gestione
rete
Evoluzione architetturale
e tecnologica degli OSS
SAVERIO ORLANDO
LAURA DRAGONI
ENRICO BAGNASCO
Dopo un periodo durato oltre un lustro, durante il quale gli interventi effettuati
sono stati indirizzati sostanzialmente alla manutenzione della piattaforma rea-
lizzata nella prima met degli anni Novanta, nel corso del 2001 sono state getta-
te le basi per un profondo rinnovamento degli OSS (Operational Support System)
di rete.
Sono stati, infatti, progettati e sono in avanzato stato di realizzazione interventi
sia di rivisitazione architetturale sia di innovazione tecnologica che modificheran-
no sostanzialmente la situazione preesistente.
Questo articolo definisce lo scenario aziendale e di mercato nel quale questa inno-
vazione maturata e identifica le principali direttrici di intervento (Piano
Sistemi), larchitettura a tendere e le nuove tecnologie introdotte. I pi significativi
progetti che costituiscono il Piano Sistemi sono trattati su uno specifico articolo che
compare su questo numero [1] e su altri che compariranno nel prossimo numero del
Notiziario Tecnico.
1 . I n t ro d u z i o n e
Nel corso degli ultimi anni, la liberalizzazione del
mercato delle telecomunicazioni ha sostanzialmente
modificato lo scenario nel quale gli operatori erano
abituati a misurarsi con i clienti.
In un mercato estremamente competitivo lesi-
genza di attrarre nuovi clienti stimola la prolifera-
zione di nuove offerte e linnovazione dei servizi.
Questo approccio non prerogativa esclusiva dei new
entrants ma richiesta anche agli operatori tradizio-
nali sia per attuare le pi appropriate politiche di
retention dei propri clienti sia per compensare, con
ri cavi aggi unti vi da servi zi a maggi ore val ore
aggiunto, le inevitabili perdite di fatturato e di mar-
gini causati dalla migrazione di clienti verso altri
operatori e dalle riduzioni tariffarie.
In questo scenario aumentano, anche, le aspetta-
tive in termini di qualit del servizio e, conseguente-
mente, gli operatori devono predisporsi a una
migliore e pi personalizzata gestione del cliente,
CRM (Customer Relationship Management). Il cliente si
attende tempi di fornitura del servizio pi rapidi e
comunque certi, tempi di riparazione dei guasti pi
tempestivi e un rapporto pi chiaro e professionale
con il proprio fornitore di servizi di telecomunica-
zione: definizione e rispetto degli SLA (Service Level
Agreement), trasparenza degli addebiti, supporto tec-
nico deccellenza, nonch, eventualmente, la possi-
bilit di un controllo diretto del proprio servizio.
Negli stessi anni abbiamo assistito allesplosione
delle tecnologie a supporto dei servizi dati che
hanno introdotto unulteriore fattore di dinamicit
nelle offerte di nuovi servizi.
Queste nuove tecnologie evidenziano, peraltro,
unobsolescenza sconosciuta nel mondo tradizionale
delle telecomunicazioni. Basti pensare che la tecno-
logia PDH (Plesyochronous Digital Hierarchy) ha domi-
nato il mondo del trasporto per oltre venti anni men-
tre la tecnologia ATM (Asynchronous Transfer Mode),
76 NOTIZIARIO TECNICO TELECOM ITALIA - Anno 11 n. 2 - Set t embre 2002
O rla n d o - D ra go n i - B a gn a sc o Ev oluz ione archit et t urale e t ecnologica degli OSS
diffusa a partire dalla met degli anni Novanta,
oggi gi ritenuta superata.
Se poi si considera la vita media di una centrale
di commutazione o di un sistema di trasmissione, si
arriva tranquillamente a dieci o pi anni mentre la
vita utile di un router difficilmente supera i quattro o
cinque anni.
Tutta questa dinamicit e competitivit si riflette
sui processi di business che sono diventati a loro
volta vieppi sofisticati e, al contempo, estrema-
mente dinamici.
In questo scenario gli OSS hanno guadagnato
unimportanza senza precedenti e sono divenuti uno
degli elementi focali per il raggiungimento degli
obiettivi di business: essi costituiscono, infatti, sia
un punto di snodo per una rapida riconfigurazione
delle offerte e dei processi sia uno strumento essen-
ziale per garantire quei livelli di efficienza richiesti
non solo dai clienti ma anche dal conto economico
della propria azienda.
2 . S cen ari o p reesi sten te
La piattaforma degli OSS ora in campo stata
prevalentemente sviluppata nel corso della prima
met degli anni Novanta e ha costituito linfrastrut-
tura abilitante per limplementazione dei CSOT
(Centro Supervisione Organizzazione Territoriale) e dei
CCA (Current Cost Account) e ha portato, quindi, a un
significativo salto di qualit nella gestione della rete.
Tuttavia, mentre i sistemi oggi in esercizio garan-
tiscono una sostanziale copertura sui problemi legati
alla supervisione degli elementi di rete, solo nel
dominio del trasporto SDH e nellambito della
gestione dinamica del traffico di fonia ci si spinti
sino allintroduzione del livello di network manage-
ment. Anzi, nel dominio della commutazione la man-
canza di questo livello ha, nel corso del tempo,
costretto a inserire caratteristiche funzionali tipiche
del network management allinterno dei CEM che,
essendo stati inizialmente progettati per svolgere
funzioni di element manager, e, non essendo architet-
turalmente posizionati a un livello adeguato, mal si
adattano a svolgere questi compiti.
I nuovi domini delle reti dati e broadband, realiz-
zati successivamente, non disponevano di sistemi di
gestione al di l di alcuni mediation device nati per la
gestione di reti enterprise e assurti, poi, al ruolo di ele-
ment managers a causa dellesplosiva crescita delle
reti pubbliche e della sostanziale impreparazione
dei costruttori di router e dei nodi ATM ad affron-
tare il tema della gestione di queste reti, pi com-
plesse architetturalmente e pi estese sia da un
punto di vista del numero di nodi sia da un punto di
vista geografico rispetto alle reti enterprise.
Sostanzialmente, i sistemi di supervisione e di fault
management preesistenti erano stati dunque indiriz-
zati alla gestione dei singoli domini e, allinterno di
tali domini, erano stati orientati quasi esclusiva-
mente agli elementi di rete e alle parti componenti
ad esse relative. A causa delle caratteristiche verti-
cali delle applicazioni erano, quindi, limitate le fun-
zionalit di gestione network oriented e del tutto ine-
sistenti quelle service oriented, il che
peraltro comprensibile se si pensa che in
passato i servizi si richiudevano esclusiva-
mente allinterno di un unico dominio
(voce o trasporto).
Anche le caratteristiche funzionali di
provisioning e di delivery sono state realiz-
zate su sistemi dedicati (sistemi verticali)
per dominio o addirittura per servizio,
riflettendo in parte quella che era la netta
separazione tra i tecnici della rete di
accesso e della rete di trasporto a livello
organizzativo e in parte, addirittura, la
segmentazione della clientela.
La presenza di architetture verticali e
replicate un fattore comune alla maggior
parte degli operatori tradizionali nel
mondo ed identificata in letteratura con
il termine management stovepipes, come
mostrato in figura 1.
Da un punto di vista degli automati-
smi, solo la catena dei servizi di fonia ha garantito
un certo livello di automatismo mentre tutti gli altri
domini di rete sono caratterizzati da continui travasi
di dati da un sistema al successivo che dovevano
essere svolti dagli operatori.
I limiti di integrazione tra i vari sistemi hanno
caratterizzato sia lambito della progettazione e della
network creation sia la sfera del network inventory
costituito da quattro diversi sistemi, uno per ciascun
dominio di rete, scarsamente integrati tra loro e poco
integrati con gli ambienti di service provisioning.
Le caratteristiche funzionali di dispacciamento
automatico e di gestione dei reclami e dei guasti erano
state, infine, sviluppate per il dominio dei servizi
forniti dalla RTG (Rete Telefonica Generale) e dalla
ISDN mentre per gli altri servizi il dispacciamento
avveniva mediante fax o con altri quick hits mentre la
consuntivazione era effettuata off line.
Non era, invece, disponibile un sistema di
gestione del personale addetto, basato su criteri di
efficienza e sulla misura e il monitoraggio dei livelli
di produttivit dei centri di lavoro.
Fault
Billing
Ordering
Customer
Care
Provisioning
Management stovepipes
Rete telefonica tradizionale
Rete IP/ ottica
Altre reti
Font e: K. Willet t s, Board of Direct ors
TeleManagement Forum Chairman.
Billing
Figura 1 Management stovepipes: le architetture verticali oggi impie-
gate dagli operatori tradizionali.
NOTIZIARIO TECNICO TELECOM ITALIA - Anno 11 n. 2 - Set t embre 2002 77
O rla n d o - D ra go n i - B a gn a sc o Ev oluz ione archit et t urale e t ecnologica degli OSS
Da un punto di vista tecnologico la
piattaforma prevalentemente basata
su architetture mainframe o su archi-
tetture client/server di prima genera-
zione.
Il pur limitato livello di integra-
zione tra i diversi sistemi ha, nel
tempo, privilegiato architetture di tipo
peer-to-peer utilizzando protocolli OSI
o, nel caso del l i nterazi one tra
ambienti di tipo mainframe e mini,
applicazioni costruite intorno al pro-
dotto MQ-Series dellIBM. Queste
architetture sono caratterizzate da un
significativo livello di stratificazione
di sistemi e, conseguentemente, da un
elevato numero di interfacce: questi
due aspetti hanno, naturalmente, con-
siderevoli impatti sui costi di manu-
tenzione e sullevoluzione ad esse
relative.
Quasi sempre, comunque, la moda-
lit di interazione realizzata di tipo
batch e solo raramente di tipo transa-
zionale, facendo pagare un tributo non
secondario allefficienza, soprattutto
in termini di tempi di lavorazione
degli ordinativi, di configurazione o di
variazione dei servizi per i clienti.
Unaltra caratteristica peculiare dei sistemi costi-
tuenti la piattaforma preesistente quella di essere
stati sviluppati e fatti evolvere su specifiche di
Telecom Italia (approccio make) con tutte le implica-
zioni legate a questo approccio: costi di acquisizione
elevati, tempi di realizzazione e di introduzione in
esercizio lunghi con la difficolt conseguente nel
garantire un adeguato time-to-market.
Dopo la realizzazione iniziale della piattaforma,
nel corso degli anni, gli interventi effettuati sono
stati quasi sempre di mantenimento (straordinario
stato ad esempio leffort per garantire la compatibilit
con lanno 2000) o di manutenzione evolutiva per
gestire nuove tecnologie, nuovi servizi o nuove orga-
nizzazioni e processi. Questa situazione ha favorito
tra laltro il moltiplicarsi di innumerevoli tool svilup-
pati autonomamente in differenti ambiti operativi
per sopperire allimpossibilit strutturale di svilup-
pare le stesse caratteristiche funzionali sulle applica-
zioni core ma senza questi strumenti molte funzioni
operative sarebbero state impossibili o inefficienti.
In conclusione la piattaforma progettata nei primi
anni Novanta ha svolto egregiamente il compito a
essa assegnato per oltre un decennio; ma la rapida
evoluzione dello scenario di mercato descritto prece-
dentemente ne ha messo in luce linadeguatezza e la
necessit di un intervento sostanziale di reingegne-
rizzazione architetturale, tecnologica e funzionale.
3 . E v o lu zi o n e arch i tettu rale e tecn o lo gi ca
Lo scenari o di busi ness i n cui si muove
Telecom Italia caratterizzato da diversi elementi
che devono essere tenuti in attenta considerazione
perch il Gruppo mantenga la leadership di mercato:
lallungamento della catena del valore, con la nascita
di nuovi attori (content provider, service provider,
network provider). Questo fattore implica lesi-
genza di definire nuovi processi B2B (Business-to-
Business) e di aggiungere le applicazioni informa-
tiche a supporto ad essi relative;
una significativa evoluzione delle tecnologie di rete,
con enfasi sulle reti a pacchetto, caratterizzate sia
da una velocit di introduzione in rete, sia da una
riduzione del tempo medio di vita mai rilevata in
precedenza. Inoltre, tali tecnologie sono caratte-
rizzate da unalta componibilit per la creazione
di servizi complessi. Questo richiede soluzioni
gestionali integrate e flessibili, in luogo delle tra-
dizionali architetture verticali e monolitiche, che
consentano di rendere il pi possibile trasparente
levoluzione delle tecnologie di rete alla sfera
della gestione;
una sensibile crescita della domanda sia di nuovi
servizi di rete broadband sia di servizi personaliz-
zati e di gestione (quali ad esempio, classi di ser-
vizio differenziate, profili dei clienti personaliz-
zabili, visibilit sulla qualit del servizio, hot-bil-
ling, customer network management).
Loperatore si deve, quindi, dotare di soluzioni
gestionali che offrano adeguate caratteristiche fun-
zionali per la gestione del servizio e del cliente.
La piattaforma di gestione degli anni Novanta non
consentiva di garantire il soddisfacimento dei sud-
detti requisiti; si , perci, deciso di sostituirla
seguendo le indicazioni del TMF (TeleManagement
Forum), adottando sia il suo framework architetturale
NGOSS (New Generation Operations Systems and
Software) [2] (figura 2), sia il suo modello dei processi
Workflow progressivo
BAC
FSC FSC FSC FSC FSC
BAC BAC
NGOSS
TM
Registry
Modello dei dati
condiviso NGOSS
TM
Architettura NGOSS
TM
BAC
Ambiente di
definizione dei
processi
Motore di
workflow
Servizi di comunicazione
Technology
Network
Service
Service Plan
Invoice
Custom
er
Catalog
BAC
FSC
NGOSS
=
=
=
Business Aware Component
Framework Service Component
New Generation Operations Systems and Software
Figura 2 Framework NGOSS.
78 NOTIZIARIO TECNICO TELECOM ITALIA - Anno 11 n. 2 - Set t embre 2002
O rla n d o - D ra go n i - B a gn a sc o Ev oluz ione archit et t urale e t ecnologica degli OSS
eTOM (enhanced Telecommunication
Operation Map) [3] (figura 3).
Larchitettura NGOSS si basa
su alcuni principi volti a garantire:
linteroperabilit tra le compo-
nenti in un ambiente distribuito
attraverso uninfrastruttura di
comunicazione comune (commu-
nications technology services);
la separazione dei flussi di pro-
cesso e le regole di business
dalle componenti applicative;
la condivisione dei dati (shared
data model);
la definizione chiara delle carat-
teristiche funzionali offerte
dalle componenti applicative.
Una delle scelte strategiche
poste alla base della nuova piat-
taforma di gestione riguarda lado-
zione massiccia di pacchetti com-
merciali, COTS (Commercial Off-
The-Shelf systems), col passaggio
qui ndi dal l appr occi o make a
quello buy&integrate. Ladozione di
soluzioni COTS una tendenza
evidente anche a livello interna-
zionale, che ha portato alla nascita
e allo sviluppo di una mercato di
componentware OSS, con lafferma-
zione di aziende quali, ad esem-
pi o, Gr ani t e, Mi cr omuse,
Syndesis, fino a pochi anni fa sconosciute o quasi
inesistenti.
A livello mondiale [4] il 38 per cento degli
investimenti per lOSS 2001 (stimati a 38 miliardi
$) stato indirizzato verso prodotti COTS, con
una previsione di crescita dellordine del 49 per
cento nellanno 2005 (quando stimato che il
totale si approssimer ai 49,6 miliardi $, pari a un
CAGR (Compound Annual Growth Rate) del 14 per
cento sui quattro anni).
Il fenomeno pi evidente in Nord America,
come mostrato nella figura 4.
3.1 Da unarchitettura stovepipe a unarchitettura
bus-based
Larchitettura in fase di realizzazione utilizza un
bus di comunicazione di tipo publish-subscribe che
garantisce una rapida ed economica integrazione
degli OSS che compongono la soluzione, secondo i
ETOM
Il fram ew ork eTOM ( en han ced
Telecommunicat ions Operat ions
Map
TM
), sviluppato nellambito del
Tel eMa n a gem en t For u m , un
modello processivo che ha lobiet-
tivo di formalizzare e rappresen-
tare, su diversi livelli di dettaglio,
tutti i processi necessari ad un
I CS P ( I n f or m a t i on a n d
Com m u n i c a t i on s S er v i c e
Prov ider). Il principale ruolo del
framework di costituire una linea
guida comune, condivisa a livello
internazionale sia per i Gestori,
che possono derivare indicazioni
sulla strutturazione dei propri pro-
cessi, sia per le aziende normal-
mente coinvolte in relazioni di
business con i Gestori stessi.
I l framework composto da tre
macro-aree processive:
Op erat i on s , che comprende
tutti i processi direttamente
coinvolti nel soddisfacimento
dei requisiti del cliente;
S t r a t egy, I n f r a s t r u c t u r e &
Product, che comprende tutti i
processi di defi ni zi one ed
implementazione delle strate-
gie aziendali, oltre ai processi
di gestione del ciclo di vita di
prodotti e infrastrutture;
Ent erprise Management , che
comprende tutti i processi che
svolgono un ruolo di supporto
ai processi di business ed ope-
rativi dellazienda.
I l modello eTOM costi tui sce la
naturale evoluzione del framework
TOM ( Tel ec om m u n i c a t i on s
Operations Map), che formalizza i
soli processi afferenti alla gestione
e allesercizio di reti e servizi.
Il framework eTOM (versione 3.0)
stato ufficialmente approvato dal
TMF nel giugno di questanno.
Cus t omer
Operat i ons St rat egy, Infrast ruct ure & Product
Strategy
& Commit
Product
Lifecycle
Management
Infrastructure
Lifecycle
Management
Fullfillment Operations
Support &
Readiness
Assurance Billing
Customer Relationship Management
Service Management & Operations
Resource Management & Operations
(Application, Computing and Network)
Supplier/ Partner Relationship Management
Marketing & Offer Management
Enterprise
Management
Strategic &
Enterprise
Planning
Stakeholder &
External Relations
Management
Disaster Recovery,
Security & Fraud
Management
Brand Management,
Market Research
& Advertising
Financial &
Asset
Management
Research &
Development
Technology
Acquisition
Enterprise Quality
Management, Process
& IT Planning &
Architecture
Human Resources
Management
Service Development & Management
Resource Development & Management
(Application, Computing and Network)
Supply Chain Development
& Management
Font e: TeleManagement Forum, dicembre 2001.
Figura 3 Modello eTOM (enhanced Telecommunication Operation Map).
NOTIZIARIO TECNICO TELECOM ITALIA - Anno 11 n. 2 - Set t embre 2002 79
O rla n d o - D ra go n i - B a gn a sc o Ev oluz ione archit et t urale e t ecnologica degli OSS
dettami dellEAI (Enterprise Application Integration)
(figura 5).
Larchitettura a bus permette di rendere dispo-
nibile in real time il dato prodotto da un particolare
modulo applicativo a tutti gli altri moduli che
hanno necessit di prenderne conoscenza o di ela-
borarlo ulteriormente. Tecnicamente il dato
messo a disposizione attraverso un processo di
pubblicazione sul bus a cura del modulo che lo
ha prodotto e attraverso un successivo processo di
lettura da parte di tutti gli altri moduli connessi al
bus che devono utilizzarlo.
Per consentire questa modalit di funziona-
mento uno dei moduli che si affaccia sul bus, il
work flow, di vitale importanza in quanto assurge a
ruolo di regista del processo gestito. In sostanza il
work flow detta i tempi agli altri moduli applicativi,
indicando sequenze di elaborazione e di acquisi-
zione dei dati dal bus, gestisce il controllo (monito-
ring) del processo tenendo traccia delle eccezioni e
dei log e fornendo i messaggi necessari di alert agli
operatori.
Queste caratteristiche sono enfatizzate, in parti-
colare, nellarchitettura NGOSS (New Generation
Operations Systems and Software); le componenti
appl i cati ve BAC (Busi ness Aware Component s),
mostrate in figura 2, offrono i servizi (contratti) uti-
lizzati dal process flow engine per realizzare il pro-
cesso di business delloperatore. La stessa infra-
struttura NGOSS realizzata mediante componenti
FSC (Framework Service Component) che devono
poter i nteroperare con l e di verse tecnol ogi e
Europa
31
30
11
49
10
15
26
28
Nord Ameri ca
Integratori di sistema
Fornitori di software
Fornitori di apparati
Funzioni IT interne
Figura 4 Ripartizione percentuale del mercato OSS in
Europa e nel Nord America.
ENTERPRISE
APPLICATION
INTEGRATION
LEAI ( En t er p r i s e Ap p l i c a t i on
Integration) un concetto nato e
sviluppato nel contesto delle appli-
cazioni informatiche aziendali. In
generale pu essere definito come
larte di legare tra loro le applica-
zioni di un'impresa, la gestione
della produzione con la gestione
degli stock , il portale di relazione
tra i clienti e il sistema di pianifi-
cazione delle risorse, ...
L'adozione di meccanismi di con-
divisione di file tra gli applicativi
aziendali, sebbene possa costituire
una prima, semplice e immediata
realizzazione dei concetti dell'EAI,
non risponde tuttavia ai requisiti
propri delle interazioni in tempo
reale comportando un significativo
aumento del numero di interfacce
necessarie all'integrazione.Una
risposta pi adeguata alle esigenze
dell'EAI rappresentata dal con-
cetto di bus informatico, giunto a
una maturit commerciale negli
ul ti mi anni . L'i ntegrazi one di
applicazioni eterogenee richiede
unicamente la realizzazione della
sola interfaccia da esporre verso il
bus, nel rispetto delle specifiche
proprie di ciascuna piattaforma,
con l'ulteriore significativo vantag-
gio rappresentato dalla totale tra-
sparenza dell'ampli amento e/o
sosti tuzi one delle appli cazi oni
stesse.
Si st emi l egacy
Le archit et t ure legacy
non possono suppor t are
la velocit del mercat o
nell' era di Int ernet
Sol uzi oni EAI
Information Bus
APPL
A
APPL
B
APPL
C
APPL
D
APPL
E
Gestione workflow
Integrazione delle applicazioni
Mapping e trasformazione
dei dati
EAI =Enterprise Application Integration
Figura 5 Larchitettura Enterprise Application Integration
consente il passaggio dalle stov epipes alle archi-
tetture integrate.
80 NOTIZIARIO TECNICO TELECOM ITALIA - Anno 11 n. 2 - Set t embre 2002
O rla n d o - D ra go n i - B a gn a sc o Ev oluz ione archit et t urale e t ecnologica degli OSS
software, di sistema operativo o di DB (Data Base)
adottate dalloperatore
1
.
Questo meccanismo particolarmente potente in
quei processi aziendali che traggono beneficio da
unimpostazione legata alle transazioni in contrappo-
sizione con le impostazioni di elaborazione differite
nel tempo e fuori linea (di tipo batch). facile indi-
viduare i vantaggi e le potenzialit evolutive che
derivano da questimpostazione per i processi di ser-
vice provisioning sino ad oggi gestiti quasi esclusiva-
mente con trasferimenti di tipo batch e con innume-
revoli fasi di operativit manuali: possibilit di ren-
dere completamente automatico il processo (flow-
through degli ordinativi), drammatica riduzione della
durata dello svolgimento e dei costi del personale,
possibilit di promuovere la commercializzazione di
servizi in modo self-provisioning via Internet.
Benefici analoghi derivano da questarchitettura
in fase di produzione dei rendiconti per i gestori dei
processi e per il management. Per monitorare i
livelli di servizio erogati, siano essi di service provi-
sioning o di service assurance, o gli andamenti della
produzione, soprattutto in fase di lancio di nuove
offerte, i manager delle diverse funzioni aziendali
hanno bisogno di dati in near real time mentre gli
operatori di customer care devono conoscere in qual-
siasi momento lo stato di lavorazione di un ordina-
ti vo o l o stato di sol uzi one di un recl amo.
Larchitettura a bus permette di rendere disponibili
ai sistemi di registrazione, linformazione (ad esem-
pio, i cambiamenti di stato di un reclamo o di un
ordinativo, la correlazione di vari allarmi per indivi-
duare lallarme padre) nel momento stesso in cui
il modulo applicativo preposto al trattamento dei
dati in quella specifica fase del processo ha comple-
tato lelaborazione.
Nonostante tutti i vantaggi fin qui indicati, larchi-
tettura a bus non risulta essere particolarmente indi-
cata al momento per trasferire grandi quantit di dati
da un sistema allaltro. I processi pi importanti che
utilizzano questo tipo di trattamento dei dati sono
quelli di billing e di analisi del traffico che prevedono
con cadenza periodica il trasferimento dei file conte-
nenti i CDR (Call Data Record) dagli EM (Element
Manager) di rete ai sistemi di immagazzinamento
(datawarhouse) del traffico e ai sistemi di fatturazione.
In questi ambiti si potrebbe adottare una strate-
gia conservativa, che consiste nel mantenere una
doppia interconnessione, una verso il bus e una tra-
dizionale, per quei sistemi che devono trasferire o
ricevere i CDR, oppure una strategia innovativa, che
consiste nel rivedere i criteri di generazione e di tra-
sferimento dei dati di billing passando da una moda-
lit file transfert a una record transfert.
Questo sistema innovativo sarebbe ben gestito
dallarchitettura a bus e sembra, peraltro, rispondere
allesigenza di nuove prestazioni richieste dal mer-
cato, ad esempio quelle di hot billing, da Enti esterni,
quali lautorit giudiziaria o di pubblica sicurezza, o
da funzioni interne alle societ, quali marketing e
vendite.
In pratica sar necessario, per, perseguire un
approccio di tipo misto a causa degli impatti che
questa modalit innovativa avrebbe sui costi per
introdurla nel dominio della commutazione.
Da quanto brevemente si esposto, appare evi-
dente la scelta della architettura a bus in risposta a
uno degli obiettivi primari della nuova piattaforma di
gestione, e cio la vision integrata da estremo a
estremo (end-to-end) della rete e la relazione di essa
con i servizi offerti. I diversi element manager e i
gestori di dominio diventano quindi dei tributari di
informazione (relativa, ad esempio, agli allarmi, le
misure, la tassazione, il traffico) verso la piattaforma
stessa, oltre che gli esecutori dei comandi elemen-
tari verso gli elementi di rete da essa pilotati (quali,
ad esempio, lapprovvigionamento, la fornitura).
4 . P ri n c i p a l i a re e d i i n t e rv e n t o
Al di l degli interventi strutturali di rivisitazione
architetturale e tecnologica, la strategia evolutiva
tracciata dal nuovo Piano Sistemi ha indirizzato anche
le aree funzionali prioritarie sulle quali intervenire. I
criteri utilizzati per individuare queste aree si pos-
sono ricondurre sostanzialmente ai seguenti punti:
benefici in termini di efficienza e di efficacia con-
seguibili con la copertura o con linnovazione di
quella specifica area funzionale, di quel processo
o di quel segmento di rete;
grado di copertura della specifica tecnologia di
rete o della funzione o del processo analizzati, da
parte degli OSS preesistenti;
costi per lo sviluppo di ciascun nuovo criterio fun-
zionale e costi di esercizio degli OSS candidati a
essere sostituiti;
flessibilit delle applicazioni preesistenti in ter-
mini di adattabilit a nuove modalit operative e
a nuovi servizi, in termini di apertura verso lam-
biente circostante degli OSS con particolare rife-
rimento alla nuova architettura e alle nuove tec-
nologie;
livello di obsolescenza degli OSS preesistenti.
4.1 Gestione delle reti e dei servizi broadband
Larea delle reti e dei servizi broadband stata
individuata come quella con maggiore priorit, in
quanto tutti i processi di gestione risultavano sostan-
zialmente non coperti.
Le reti erano in effetti cresciute come estensione
nellambito delle reti pubbliche di tecnologie pro-
gettate per lambito enterprise. Anche se gradual-
mente, la tecnologia e larchitettura interna dei nodi
(switch ATM, router, NAS, ) stata adattata per
essere utilizzata in un ambiente di rete proprio di un
tier 1 operator, come Telecom Italia. Lo stesso non
valeva per gli EM impiegati a supporto di essi e,
addirittura, alcuni di questi nodi non disponevano
neanche di un EM.
(1)
Nellarchitettura NGOSS, anche la componente di framework
bus deve essere definita attraverso uninterfaccia (contratto), in
modo da permettere alloperatore di adottare diverse tecnologie
mediante differenti soluzioni con i pacchetti commerciali COTS.
NOTIZIARIO TECNICO TELECOM ITALIA - Anno 11 n. 2 - Set t embre 2002 81
O rla n d o - D ra go n i - B a gn a sc o Ev oluz ione archit et t urale e t ecnologica degli OSS
Linterazione uomo-macchina era possibile solo
utilizzando modalit poco evolute (ad esempio,
Telnet
2
), spesso con operativit locali al nodo e sicu-
ramente senza possibilit di avere viste sul PC pi o
meno sintetiche a livello di dominio e, men che
meno, a livello di servizi. Questi ultimi, pi di quelli
commercializzati nei domini tradizionali della com-
mutazione e del trasporto, sono caratterizzati da una
marcata trasversalit a pi domini tecnologici (per
esempio, la configurazione e la gestione di un servi-
zio ADSL coinvolgono laccesso ADSL ma anche il
trasporto ATM e la terminazione IP).
In tale scenario e con lesplosione delle quantit
di questi nuovi servizi aperti al pubblico non stato
difficile riconoscere lurgenza degli interventi fina-
lizzati ad automatizzare la catena di provisioning end
to end dei servizi e di quelli finalizzati alla documen-
tazione degli apparati e dei servizi. Nello stesso
tempo lenfasi posta dal mercato sulla qualit del
servizio e sulla sua misurabilit (service level agree-
ment) ha consigliato di introdurre criteri funzionali di
supervisione e di gestione dei guasti che ponessero
ancora lenfasi sulla proattivit e sulla gestione per
servizio piuttosto che per dominio tecnologico o per
apparato di rete.
La complessit delle logiche di instradamento
del traffico, proprie delle reti a pacchetto, limpossi-
bilit del controllo dinamico del consumo di banda e
la sensibile crescita di servizi e del numero di clienti
ha reso, infine, indispensabili strumenti di perfor-
mance monitoring e capacity management.
Intorno a queste esigenze nata lidea della
nuova piattaforma di gestione delle reti broadband; si
tratta, quindi, di unarchitettura che integra tutte le
caratteristiche prima descritte tramite una infrastrut-
tura a bus di comunicazione tra i moduli e grazie a
un modello di dati unico, inserito su un data base a
sua volta unico per tutti i domini tecnologici coin-
volti nella fornitura dei servizi.
4.2 Network inventory
Nellambito dellarchivio della rete (network
inventory) lo scenario era caratterizzato da una seg-
mentazione dei sistemi per ciascun dominio di rete:
accesso (ACL/RR - Automazione Centri Lavoro Registri
di Ret e), trasporto (GAT - Gest i one Aut omat at a
Trasmissione), commutazione (ACL/RC - Automazione
Centri Lavoro Registri di Centrale). Un primo tentativo
di innovazione era stato avviato nellambito del pro-
getto SOCRATE ed era sostanzialmente abortito
con esso, lasciando la prima versione di quello che
doveva essere lArchivio LArga BAnda come comple-
mento, per la documentazione dellaccesso in fibra,
ACL/RR, dedicato al solo accesso in rame.
I vari domini delle reti dati erano sostanzial-
mente documentati su vari data base locali in forma
non strutturata e, quindi, non direttamente utilizza-
bile dai diversi OSS. In attesa di realizzare la solu-
zione obiettivo, si provveduto al recupero dei
domini dei dati pi importanti nel data base GAT
che era quello che meglio gestiva i modelli e le codi-
fiche specifiche riguardanti le reti e i servizi broad-
band.
Tutti questi sistemi sono caratterizzati da una
elevata obsolescenza tecnologica, da scarsa flessibi-
lit e da una modesta integrazione con i sistemi di
supporto ai processi che li alimentano.
Si deciso, cos, di avviare un progetto finaliz-
zato a documentare tutti i domini di rete allinterno
di un unico ambiente costruito su tecnologie allo
stato dellarte e in grado di documentare non solo
gli elementi fisici della rete ma anche quelli logici,
quindi non solo network inventory ma anche service
inventory, customer network inventory e, infine, service
catalog.
Questultimo archivio costituisce un elemento
abilitante per gestire in maniera efficiente il pro-
cesso di provisioning di tipo flow trough e soprattutto
per introdurre quegli elementi di flessibilit nellin-
troduzione di nuovi servizi o di funzioni innovative.
4.3 Datawarhouse
Nel corso del tempo lorganizzazione della rete
ha sempre pi assunto le caratteristiche di una fab-
brica che realizza, come in una catena di montaggio,
prodotti di telecomunicazione, linee ISDN ovvero
accessi ADSL, e servizi di assistenza tecnica sui
medesimi prodotti.
Sono stati attuati piani di efficienza finalizzati a
ridurre i costi di produzione ed a minimizzare le
scorte, garantendo comunque tempi di produzione
in linea con le richieste di mercato e, comunque,
sempre pi sfidanti.
Per gestire i processi che presiedono al funziona-
mento della fabbrica stato necessario approntare
ambienti di analisi dei dati di produzione, di consi-
stenza e di trend del consumo delle scorte e della
qualit del servizio offerto al cliente.
stato, qui ndi , deci so di real i zzare tre
datawarhouse tecnici allinterno dei quali conservare
e integrare i dati prodotti dai sistemi operativi che
gestiscono i processi.
Il primo di questi, LIDO (Livello Integrato Dati
Operazionali), mantiene i dati di consistenza della
rete, memorizza gli stati di lavorazione degli OL
(Ordinativi Lavoro) del processo di provisioning e
delivery e i relativi parametri di qualit, SLA (Service
Level Agreement), KPI (Key Performance Indicator).
Lambiente LIDO stato anche strutturato con
caratteristiche di ODS (Operational Data Storage) a
supporto delle operativit di alcuni sistemi che
devono accedere in tempo reale ai dati di consi-
stenza di rete, quali, ad esempio, TTM (Trouble Ticket
Management).
Il secondo datawarehouse, denominato N@utilus,
mantiene i dati prodotti dal processo di assurance:
network e customer trouble ticket; attivit dei tecnici;
(2)
Telnet un protocollo semplice di terminale remoto che fa parte
della suite di protocolli TCP/IP. Esso permette a un utente di una certa
postazione di stabilire una connessione con un server di unaltra
postazione e di inviare i caratteri digitati direttamente alla macchina
remota. Telnet trasporta, anche, loutput dalla macchina remota al ter-
minale dellutente.
82 NOTIZIARIO TECNICO TELECOM ITALIA - Anno 11 n. 2 - Set t embre 2002
O rla n d o - D ra go n i - B a gn a sc o Ev oluz ione archit et t urale e t ecnologica degli OSS
elaborazioni degli stessi dati per misurare gli indici
di qualit del servizio di service assurance (SLA,
KPI); dati di qualit tecnica della rete (ad esempio,
tassi di guasto).
Il terzo, infine, denominato Ulisse, raccoglie i
dati di traffico e le misure dai network elements e pro-
duce analisi sugli stessi dati per monitorare il cor-
retto funzionamento della rete e per supportare il
processo di network analysis teso a un corretto
dimensionamento della rete.
Tutti questi ambienti, per il compito cui sono
preposti, devono essere alimentati con una periodi-
cit non molto bassa, in alcuni casi anche pi volte
al giorno e, in prospettiva, in near real time. Per que-
sto motivo opportuno che anche i datawarehouse
siano allocati sul bus.
4.4 Gestione della forza lavoro e dei reclami
Gli interventi nellarea dei sistemi di gestione
dei trouble ticket (allarmi e reclami) e della forza
lavoro sono stati dettati sia da un obiettivo di effi-
cienza sia dalla necessit di disporre di strumenti
flessibili, sempre meno dipendenti da unorganizza-
zione in continua evoluzione.
Il punto di partenza era costituito da un insieme
di sistemi specializzati per tipologia di intervento:
NSCLGRA (Nuovo Sistema Centro di Lavoro Gestione
Reti Accesso) ed ACL/IA (Automazione Centri Lavoro
Impianti Abbonato) per la rete di accesso, ACL/RE
(Automazione Centri Lavoro Rete) per commutazione
e trasmissione, ACL/PS (Automazione Centri Lavoro
Prodotti Servizi) per la componente prodotti e ser-
vizi ed erano costruiti sul concetto di filiera verti-
cal e. Ogni si stema era i nfatti vi sto come un
insieme monolitico anche se costituito da blocchi
funzionali distinti e offriva praticamente tutti i sin-
goli servizi, dallaccoglienza agli spostamenti dei
tecnici (sociali o di impresa), con minime intera-
zioni tra le componenti omologhe delle singole
catene.
Il modello finale propone invece uno scenario di
sistemi modulari specializzati per processo, forte-
mente orientati allintegrazione e alla sinergia orga-
nizzativa.
Il passaggio da sistemi ad hoc a quelli trasversali
di processo ha permesso, facilitando e in alcuni casi
comportando, modifiche organizzative rilevanti.
Lesempio pi significativo rappresentato dal CLU
(Centro di Lavoro Unico) allinterno del quale proprio
grazie al WFMS (Work Force Management System) sono
confluiti i tecnici provenienti dai centri di lavoro
preesistenti (COR, COP, CPF, PS) ognuno con il
proprio skill, ma con la possibilit di acquisire nuove
competenze per operare su un dominio di rete pi
ampio, a vantaggio di una accresciuta sinergia ed
efficienza.
In questottica sono stati messi a punto sistemi
orientati spiccatamente a processi come il TTMS
(Trouble Ticket Management System) strumento unico
per lanalisi e la diagnosi dei guasti e dei reclami, il
gi citato WFMS e il FAS (Field Access System) per la
gestione della forza lavoro e il dispacciamento auto-
matico delle attivit ai tecnici, la RPA (Rilevazione
Presenze Attivit) per la rilevazione delle presenze
del personale tecnico, il GEM (GEstione Materiali)
per la gestione delle scorte e dei materiali e N@uti-
lus, datawarehouse fondamentale che, grazie a indica-
tori, rendiconti e correlazioni molto strette permette
di verificare lefficacia e lefficienza delle soluzioni
di processo, di sistema e organizzative adottate.
5 . P o ssi b i l i u l t e ri o ri e v o l u z i o n i
La nuova piattaforma di gestione basata, dun-
que, sulle caratteristiche architetturali definite nel-
lambito del TMF con la iniziativa NGOSS. In par-
ticolare, nelle soluzioni NGOSS pi innovative,
come sar chiarito con il caso fine grain pi avanti,
sono spi nte al l i mi te l e capaci t cosi ddette
plug&play delle componenti software, o, in altre
parole, la capacit di autodichiarazione e di auto-
configurazione.
In questi contesti sperimentali trovano applica-
zione e verifica tecnologie software emergenti,
qual i , ad esempi o, JINI
TM
3
, Web Servi ces
4
,
JavaSpaces
5
. Viene, inoltre, effettuato un assessment
delle potenzialit ed applicabilit al contesto carrier-
class tipico di un gestore, tenendo conto delle pro-
blematiche dellinterazione di esse con le soluzioni
proprietarie OS/OSS legacy, destinate a rimanere
attive anche nel prossimo biennio.
La quantit di risorse di rete che devono essere
gestite continuano a crescere in misura significativa
e le reti attuali sono costituite da un insieme di reti
di vecchia generazione, di reti di nuova generazione,
da ser ver host - qual i , ad esempi o server DNS
(Domain Name Server) - e da applicazioni di rete - ad
esempio funzionalit di gestione offerte da un
sistema RADIUS (Remote Access Dial In User Service) -
che rappresentano i caposaldi (building blocks) attra-
verso cui realizzare i servizi che devono rispondere a
nuovi obiettivi di business espressi in termini di
rapidit nel fornire le risposte alla clientela in modo
efficiente, modulare ed economico.
Una possibile risposta alla domanda, come pos-
sibile gestire la molteplicit di elementi di rete, di
regole di business e, nel contempo, dominare la
quantit di informazioni necessarie per gestire la
complessit che cos si determina, viene dallapplica-
zione delle tecniche di self-management, ovvero dalla
distribuzione dellintelligenza in rete, attraverso cui
(3)
JINI
TM
una architettura software di tipo open, basata su Java,
che consente di sviluppare applicazioni network-centric fortemente
adattabili ai cambiamenti.
(4)
Un Web Service un'interfaccia che descrive una collezione di
operazioni, accessibili attraverso una rete mediante la messaggistica
XML (eXtensible Markup Language).
(5)
Il modello di programmazione di JavaSpace basato sull'utilizzo
di spazi di oggetti, i server JavaSpace. In questo modo i componenti di
un'applicazione distribuita possono comunicare e coordinarsi attra-
verso apposite funzioni primitive di lettura e scrittura su uno spazio.
NOTIZIARIO TECNICO TELECOM ITALIA - Anno 11 n. 2 - Set t embre 2002 83
O rla n d o - D ra go n i - B a gn a sc o Ev oluz ione archit et t urale e t ecnologica degli OSS
ciascuna componente effettua in tempo reale le
azioni di gestione necessarie per garantire il funzio-
namento della rete e i livelli di servizio.
La tecnologia che abilita, oggi, la distribuzione del-
lintelligenza in rete basata sul policy based manage-
ment e un suo utilizzo non limitato solo alla gestione
degli elementi di rete ma essa pu essere impiegata in
modo efficace anche da componenti applicative che
cooperano in un sistema distribuito alla realizzazione
delle regole di business delloperatore.
Un prototipo di architettura che coniuga lutilizzo
della tecnologia policy base management e i moderni
principi sulla definizione di architetture distribuite
stato proposto, e successivamente promosso, da
Telecom Italia Lab nellambito del progetto Catalyst
del TMF (TeleManagement Forum). Il progetto denomi-
nato fine grain NGOSS (http://www.finegrain.org/Phase2),
dimostra in modo pragmatico la possibilit di realiz-
zare sistemi di supporto per la gestione sia dei servizi
di nuova generazione sia degli elementi di rete con un
livello di granularit che pu essere progettata sulla
base delle esigenze del singolo gestore.
Di seguito sono elencati i principali benefici che
pu ottenere un gestore pubblico di reti di teleco-
municazione che intenda adottare la soluzione archi-
tetturale fine grain:
introdurre i servizi di gestione policy based mana-
gement sulla base di regole di gestione definite;
aggiungere servizi innovativi per un segmento di
mercato ad-hoc, differenziando lofferta sulla base
delle esigenze del cliente;
conciliare lesigenza di personalizzazione delle
offerte di servizio con il rapido sviluppo di servizi a
valore aggiunto;
realizzare uninfrastruttura unica per la gestione
degli apparati di rete, dei server e delle applica-
zioni;
gestire con una granularit variabile lefficienza
di unarchitettura distribuita e scalabile;
ridurre i costi di sviluppo del servizio e di
gestione del framework architetturale, il CAPEX
(CAPital EXpenditure), attraverso un ciclo di svi-
luppo efficiente;
ri durre i costi Operati vi , OPEX (OPerat i ve
EXpenditure), attraverso un processo di fornitura
flessibile.
Il progetto Catalyst Fine Grain NGOSS, basato
sul framework JINI
TM
e integra le diverse tecnolo-
gie software JAVA, JavaSpace, J2EE, XML, CORBA
e Web Services.
Telecom Italia, tramite TILAB, ha, come si
detto, sponsorizzato il progetto fine grain phase II e
ha collaborato alla definizione dello scenario di busi-
ness, realizzato attraverso un prototipo basato su
prodotti COTS (Commercial Off-The-Shelf systems) che
stato presentato nel corso dellesposizione del
TeleManagement World di Nizza, nel maggio di
questanno.
6 . C o n c l u si o n i
Lallungamento della catena del valore, levolu-
zione delle tecnologie di rete, la crescita di domanda
di nuovi servizi e la competizione sono i fattori pri-
mari che hanno determinato lobsolescenza dellat-
tuale piattaforma degli OSS di Telecom Italia, svi-
luppatasi prevalentemente nella seconda met degli
anni Novanta.
Nel 2001 sono state gettate le basi per la nuova
piattaforma di gestione, progettata secondo le indica-
zioni del TeleManagement Forum: architettura del
framework NGOSS e modello dei processi eTOM.
Larchitettura in corso di realizzazione prevede,
infatti, un bus di comunicazione derivato dallEAI
(Enterprise Application Integration), a garanzia di
ottenere una rapida ed economica integrazione
degli OSS che compongono la piattaforma.
Una delle scelte strategiche gi adottate, in
accordo con gli orientamenti manifestati nel conte-
sto internazionale, riguarda ladozione massiccia di
pacchetti commerciali (COTS), come alternativa al
make.
Le aree di intervento prioritarie riguardano la
gestione delle reti e dei servizi broadband, il network
inventory, il datawarehouse, la gestione del personale
tecnico e dei reclami.
I risultati finora conseguiti sono di assoluto
rilievo, a conferma della precisa ed appropriata
impostazione del progetto nel suo complesso: oltre
a recuperare le criticit del passato, la nuova piat-
taforma consente, infatti, di traguardare a obiettivi
futuri rimarchevoli in termini di contenimento dei
costi e di flessibilit nellerogazione dei nuovi ser-
vizi che il mercato richieder.
Essa, quindi, costituisce un elemento fonda-
mentale per migliorare sensibilmente lefficienza
del servizio offerto ai clienti e, al tempo stesso, di
migliorare leconomicit della gestione della rete.
[1] Or l ando, S. ; Ior i o, N. ; Pi et r opaol o, R. ;
Pinnola, A.; Versini, R.: Gestione delle reti e dei
servizi broadband. Su questo stesso numero
del Notiziario Tecnico Telecom Italia, pp.
85-102.
[2] eTOM: The Business Process Framework for the
Inf ormat i on and Communi cat i ons Ser vi ce
Provider - TMF Approved Version 3.0. TMF
GB921, giugno 2002.
[3] NGOSS Archi t ect ure Technol ogy Neut ral
Specification - Public Version 2.6. TMF 053,
ottobre 2002.
[4] Shared Inf ormat i on/ Dat a (SID) Model -
Deliverable 1: Concepts, Principles and Business
Entities - Public Version v1.5. TMF GB 922,
agosto 2002.
84 NOTIZIARIO TECNICO TELECOM ITALIA - Anno 11 n. 2 - Set t embre 2002
O rla n d o - D ra go n i - B a gn a sc o Ev oluz ione archit et t urale e t ecnologica degli OSS
ACL/IA Automazione Centri Lavoro Impianti
Abbonato
ACL/RC Automazione Centri Lavoro Registri
di Centrale
ACL/RE Automazione Centri Lavoro Rete
ACL/RR Automazione Centri Lavoro Registri
di Rete
ACL/PS Automazione Centri Lavoro Prodotti
Servizi
ADSL Asymmetric Digital Subscriber Line
ATM Asynchronous Transfer Mode
BAC Business Aware Components
B2B Business-to-Business
CAGR Compound Annual Growth Rate
CAPEX CAPital EXpenditure
CCA Current Cost Account
CDR Call Data Record
CLU Centro di Lavoro Unico
COR Centro Operativo Rete
COP Centro Operativo Privati
COTS Commercial Off-The-Shelf systems
CPF Centro Portanti Fisici
CSOT Centro Supervisione Organizzazione
Territoriale
DB Data Base
DNS Domain Name Server
EAI Enterprise Application Integration
EM Element Manager
eTOM e-Telecommunication Operations Map
FAS Field Access System
FSC Framework Service Component
GAT Gestione Automatata Trasmissione
GEM GEstione Materiali
IETF Internet Engineering Task Force
IP Internet Protocol
ISV Independent Software Vendor
KPI Key Performance Indicator
LIDO Livello Integrato Dati Operazionali
NAS Network Access Server
NGOSS New Generation Operating Systems
and Software
NSCLGRA Nuovo Sistema Centro di Lavoro
Gestione Reti Accesso
ODS Operational Data Storage
OL Ordinativo Lavoro
OPEX OPerative EXpenditure
OSI Open System Interconnection
OSS Operational Support System
PBM Policy Based Management
PDH Plesyochronous Digital Hierarchy
PS Prodotti Servizi
Laura Dragoni responsabile, nellambito
della Funzione Sistemi di Domestic Wireline -
Rete, della Funzione Assurance ossia dello
sviluppo dei sistemi per la Service Assurance
delle diverse Piattaforme di rete. Laureata in
Fisica presso lUniversit degli studi di Roma,
ha iniziato la sua attivit come progettista
software degli autocommutatori numerici
presso lItaltel. In SIP (oggi Telecom Italia) dal
1982, ha operato, nellambito della Funzione
Rete, prima nel contesto dellIngegneria di
Commutazione e poi dellIngegneria dei Sistemi di gestione.
Enrico Bagnasco si laureato in Scienze
dellInformazione presso lUniversit di
Torino. Entra in CSELT (oggi Telecom Italia
Lab) nel 1988. Inizia subito ad occuparsi di
gestione della rete e dei servizi, partecipando
alle attivit di standardizzazione (ETSI, ITU e
ANSI T1.M1) e coordinando diversi progetti
di studio internazionali (EU ed Eurescom)
nonch attivit finalizzate verso le BU del
Gruppo (DW e TIM). Inoltre, ha condotto il
TMN Working Group dellETNO ed molto
attivo in ambito IEEE, dove ha recentemente presieduto
NOMS2002, il maggior congresso scientifico internazionale sui
temi del Network&Service Management. Infine, il
rappresentante del Gruppo Telecom Italia nel Board del
TeleManagement Forum. In ambito Telecom Italia Lab,
attualmente responsabile della funzione OSS&Processes.
Saverio Orlando responsabile dal 2000
della Funzione Sistemi nellambito della Rete
di Telecom Italia Domestic Wireline. La
responsabilit di questa Funzione quella di
progettare e rilasciare in esercizio i Sistemi
utilizzati per il Service Delivery e la Service
Assurance, la gestione dei reclami e della forza
lavoro, la network creation e la gestione del
traffico di rete. Dopo aver assunto la
responsabilit della Funzione, ha promosso la
completa reingegnerizzazione dellambiente
OSS e la progressiva sostituzione degli ambienti legacy,
principalmente basati su architetture mainframe con architetture
basate sul paradigma NGOSS di TMF. Ha iniziato la sua attivit
nel 1982 in Italtel ricoprendo diversi incarichi tecnici nellambito
del progetto ITAPAC e, successivamente, del progetto rete
intelligente. Nel 1991 stato assunto in SIP (oggi Telecom Italia) e
nel 1992 stato incaricato del gruppo di collaudo della rete
intelligente. Nel 1994 ha assunto la responsabilit di tutto il
progetto rete intelligente e nel 1995 anche quella dei sistemi di
telefonia pubblica, di messaggistica e di servizi speciali. Durante
questo periodo ha promosso la realizzazione nella Rete di Telecom
Italia della pi potente Rete Intelligente dEuropa capace di
servire 40 milioni di chiamate al giorno e pi di trenta servizi.
Saverio Orlando si laureato presso il Politecnico di Torino in
Ingegneria Elettronica nel 1981.
RADIUS Remote Access Dial In User Service
RPA Rilevazione Presenze Attivit
RTG Rete Telefonica Generale
SI System Integrator
SLA Service Level Agreement
TMF TeleManagement Forum
TTM Trouble Ticket Management
TTMS Trouble Ticket Management System
WFMS Work Force Management System
XML eXtensible Markup Language