Capitolato tecnico prestazionale

Sommario

La Società Terrecablate Reti e Servizi Società Benefit istituisce la procedura di gara per effettuare la sostituzione della centrale telefonica i-VLS Italtel attualmente in esercizio nella propria rete.

Tale esigenza scaturisce dal fatto che la piattaforma i-VLS Italtel dal prossimo anno (2022) non avrà più possibilità di essere manutenuta. Non sarà più possibile effettuare patch o attività correttive al software rischiando così malfunzionamenti e disservizi. Infatti, Xxxxxxx ha dichiarato in relazione alla suddetta centrale:

• End of life del software di i-VLS

• End of support dell’hardware COTS che ospita le VM di i-VLS

• Obsolescenza del sw di SNMP Concentrator

La soluzione individuata da Terrecablate per l’upgrade evolutivo prevede l’adozione della piattaforma iMCS di Italtel che verrà descritta successivamente nel presente documento. Si è giunti alla individuazione di questo prodotto a seguito delle seguenti considerazioni di natura tecnica ed organizzativa aziendale:

• Mantiene le stesse interfacce di configurazione e provisioning consentendo di non modificare i software sviluppati in azienda per attivazione/cessazione clienti e per tutte le attività di assurance.

• Permette di non dover fare sviluppi software in relazione al sistema di Billing e non crea interruzione sulla fatturazione di tutti i clienti attualmente già attivi.

• Si integra con l’attuale rete intelligente senza dover fare sviluppi software o adeguamenti.

• Si integra con l’attuale OPM (Optical Peripheral Module: Mediagateway) consentendo di non provvedere alla sua sostituzione che risulterebbe onerosa economicamente e complessa tecnicamente. È garantita quindi la compatibilità con il protocollo V5.2 che significa poter mantenere inalterata tutta l’attuale rete di accesso basata su tecnologie Alcatel e Keymile.

Significa inoltre poter mantenere attivi altri servizi basati su protocolli legacy come

l’interconnessione SS7 verso la PSTN e servizi PRI ISDN per il rilegamento di alcuni clienti.

• Permette di costruire una soluzione di disaster recovery su sedi fisicamente separate garantendo, in caso di fault di una delle due, la continuità del servizio o, nel peggiore dei casi, un ripristino veloce stimato in poche ore.

• Consente una migrazione del traffico con minima indisponibilità, con minimo impatto operativo e di riconfigurazione dei sistemi interconnessi.

L’obiettivo di Terrecablate è quello di avere una soluzione “chiavi in mano” che consenta di superare le limitazioni attuali, di avere un impatto trascurabile sulle proprie risorse umane per quanto riguarda il processo di migrazione, ed implementare alcune funzionalità aggiuntive descritte nel seguito. Sono da ritenersi oggetto della fornitura tutte le componenti hardware e software necessarie al funzionamento della nuova centrale Italtel iMCS e di tutto il suo contesto applicativo descritto nel presente bando.

Il soggetto aggiudicatario, oltre alla fornitura delle componenti hardware e software, sarà tenuto alla fornitura dei seguenti servizi professionali finalizzati alla definitiva messa in esercizio della nuova centrale:

• Installazione e collaudo della soluzione completa delle ridondanze sui sistemi hardware e software forniti ed oggetto della presente gara;

• Integrazione senza nessuna attività da parte di Terrecablate con i seguenti sistemi attualmente in uso:

o sistema di Billing infINIT-OLO

o sistema di Rete Intelligente InfINIT-NGN

o piattaforma IP Centrex Kalliope

o applicativi sviluppati internamente per attività di Provisioning ed Assurance

o sistema NetMatch-S

o OPM

• Training

• Gestione della migrazione degli utenti attualmente attivi nella piattaforma iVLS senza nessuna

attività da parte di Terrecablate

• Collaudo finale;

• Servizio di assistenza tecnica con pronto intervento su hardware, software e servizi telefonici di centrale. Supporto e manutenzione correttiva ed evolutiva.

Terrecablate ha altresì deciso di inserire nel presente bando di gara anche la fornitura, la configurazione e la messa in esercizio di un nuovo SBC con funzionalità User Network Interface, che dovrà affiancare e incrementare le funzionalità di Sip Server attualmente erogate da i-VLS senza alterare l’interoperabilità di tutti i sistemi descritti precedentemente.

1 Descrizione della soluzione attuale

Attualmente la rete per i servizi voce di Terrecablate è quella rappresentata nella seguente figura:

Figura 1 Architettura attuale della rete voce

Il nodo di commutazione della rete è costituito dal softswitch Italtel i-VLS (iMSS VLiteSwitch) che si compone di moduli software in esecuzione sia su hardware proprietario OPM (caratterizzato dal fornire le interfacce TDM e le risorse di Media Server) che in ambiente virtualizzato VMware su hardware COTS.

i-VLS si interfaccia mediante protocollo SIP con altri Application Server che erogano servizi per l’utenza dell’operatore, mentre per le interconnessioni verso altri operatori può usare sia interfacce TDM-SS7, gestite attraverso il modulo OPM, sia interfacce SIP attraverso il Session Border Controller Italtel NetMatch-S.

i-VLS si interfaccia inoltre con una soluzione di rete intelligente Infinit-NGN interconnessa tramite trunk SIP che fornisce funzionalità di AFS (Advanced FreePhone Service, numerazioni non geografiche in decade 8) e Number Translation.

La soluzione di billing utilizzata è infinit-OLO-RTBS che comunica con i-VLS tramite un flusso ftp.

Il processo di provisioning è realizzato tramite suite software sviluppata internamente che utilizza connessioni telnet verso OMS.

2 Descrizione della soluzione richiesta

La soluzione individuata da Terrecablate per la sostituzione della propria centrale telefonica è la piattaforma

iMCS di Italtel che si colloca in continuità con l’esperienza della attuale iVLS .

Terrecablate ha la necessità di sostituire alcune componenti della soluzione in esercizio, in particolare la nuova soluzione utilizzerà la suite i-MCS (italtel Multimedia Communication Suite) in sostituzione di i-VLS e l’Element Manager/Network Manager iNEM (italtel Neutral Element Manager) al posto dell’obsoleto SNMP Concentrator.

Oltre alla suddetta necessità riveste particolare importanza, nella scelta della soluzione i-MCS da parte di Terrecablate, la possibilità di implementare la funzionalità di ridondanza geografica su due siti fisicamente distinti.

La piattaforma i-MCS, come già detto, è in continuità con quella i-VLS e questo consente di gestire ed integrare parti di essa che devono continuare ad erogare servizi. Una di queste componenti essenziali è il modulo OPM, già presente in rete Terrecablate come componente di i-VLS, che può essere mantenuto con le sue funzionalità e le sue interfacce (V5.2, XX0, XXXX) in quanto i-MCS è in grado di gestirlo esattamente come avviene attualmente con i-VLS.

La nuova architettura i-MCS utilizzerà hw COTS e dovrà essere certificata sugli ambienti di virtualizzazione più aggiornati.

Si rende inoltre necessario inserire un livello di separazione e sicurezza aggiuntiva, costituito da un SBC-UNI, tra l’utenza SIP terrecablate e i-MCS. Attualmente le funzionalità di SIP Server sono erogate da i-VLS che non ha funzionalità di session border controller.

La figura seguente illustra, ad alto livello, come si comporrà la nuova piattaforma per i servizi voce:

Figura 2 Evoluzione della rete voce

2.1 Software di centrale iMCS

La suite Italtel i-MCS viene ritenuta in grado di coprire tutte le necessità di Terrecablate ed è caratterizzata

da un’elevata modularità software e da un’implementazione in ambiente virtualizzato.

La piattaforma è nativamente pensata anche per situazioni evolutive di soluzioni già “in-field” basate su

prodotti delle linee i-SSW, i-VLS, i-MSS e i-MCS.

Infatti, la suite i-MCS ha queste specifiche caratteristiche:

• Conserva tutte le funzionalità sviluppate da Italtel nelle linee di prodotto basate su i-SSW release 22.x, compreso i-VLS 1.x

• Supporta completamente gli apparati basati su hardware proprietario Italtel già in uso presso i clienti, ed in particolare le funzionalità “Media Gateway Integrato” e “Media Server Integrato” basate sul modulo proprietario OPM

• Aumenta la capacità di installare i moduli software su hardware commerciale consentendo l’espansione di siti utilizzando nuovi server commerciali insieme ad hardware proprietario Italtel esistente

• Arricchisce la linea di prodotti softswitch di Italtel introducendo funzionalità standard IMS quali I/S- CSCF, TAS, IBCF/BGCF e MRF

• Permette configurazioni eterogenee per quello che riguarda la gestione di media server consentendo ad uno stesso modulo di call control di utilizzare media server “legacy” basati su OPM come pure i nuovi moduli software MRF attraverso l’utilizzo di criteri configurabili

• Migliora l’integrazione con i prodotti Italtel dedicati al bordo della rete quali Italtel Media Gateway

(Italtel Netmatch-M) e Border Gateway (Italtel Netmatch-S).

i-MCS consente la convergenza della rete di Terrecablate, fornisce interfacce per tutte le tipologie di rete (IP o TDM, fissa o mobile) e permette l’evoluzione della rete verso architetture innovative con diverse configurazioni che possono utilizzare i seguenti elementi di rete:

• Softswitch NGN Class-independent

• Funzionalità di Bordo IP: IP-IP NNI IBCF (centralizzato) + controllo del BGW

• Funzionalità di Transito: attraverso l’uso di una funzionalità integrata di “Routing and Policy function” (RPF) o usando una funzione centralizzata di “Routing and Policy function” realizzata dal prodotto Italtel i-RPS

• Funzionalità di Bordo TDM (CS):

🡺 IP-TDM NNI (MGCF)

🡺 NGN Class 4 Softswitch (TDM-TDM)

La seguente figura riassume in forma grafica una soluzione integrata di i-MCS evidenziando le diverse interconnessioni con gli specifici domini, utilizzando le configurazioni di i-MCS elencate in precedenza.

Figura 3 Soluzione integrata i-MCS verso domini esterni

• Lawful Interception

La funzionalità di Lawful Interception dovrà essere erogata dalla nuova soluzione senza l’utilizzo di funzionalità erogate da OPM (Ponti conferenziatori), come avviene attualmente. La futura dismissione dell’OPM non dovrà in nessun modo avere ripercussioni sull’erogazione del servizio di lawful interception.

2.1.1 Architettura

i-MCS è una piattaforma con elevata flessibilità, la suite si compone con diverse componenti e molteplici interfacce e può essere implementata sia in modalità “all-in-a-box” sia con un approccio di Network Element distribuito.

La figura seguente rappresenta tutti i macro blocchi funzionali della piattaforma i-MCS.

Figura 4 Framework i-MCS

2.1.2 Features in rete Terrecablate

La suite i-MCS è stata modellata sulla base dei servizi già attivi e comunque necessari in Terrecablate e sulla base di alcuni pre-requisiti. La configurazione di i-MCS richiesta per sostituire i-VLS è quella mostrata in figura:

Figura 5 Funzionalità i-MCS in rete Terrecablate

Le funzionalità di i-MCS sono completamente compatibili a quelle di i-VLS e consentono di mantenere invariate le interfacce esterne verso gli altri elementi di rete interessati al servizio voce, quali i diversi SIP Application Server come Infinit NGN oppure Kalliope PBX, come pure le interfacce verso i sistemi superiori OSS/BSS.

Alle funzionalità indicate nella precedente figura occorre aggiungere anche quelle relative al Media Resource Function che si rende necessario per mantenere in rete Terrecablate alcuni dei servizi oggi forniti da OPM Media Server, come evidenziato nella figura precedente, in ottica di una successiva dismissione dello stesso modulo OPM. Si tratta di una funzionalità della suite i-MCS che si presenta in rete come un network element distinto con una propria funzione di Operation&Management e che si compone dei blocchi indicati nella successiva figura.

Figura 6 Funzionalità Media Server nella suite i-MCS

La funzionalità MRF in senso stretto è composta dal sottomodulo Media Resource Function Control (MRFC) che si interfaccia con i vari Call Handler attraverso SIP/NETANN (RFC 4240) oppure SIP/MSCML (RFC 4722) e controlla il sottomodulo Media Resource Function Processor (MRFP) usando una interfaccia standard H.248.

All’interno della suite i-MCS la funzionalità MRF garantisce:

• Annunci

• Audio conferenze

• Raccolta cifre DTMF

• Supporto ai servizi Call Hold, Call Waiting, Music on Hold e Three Party Call

• Duplicazione dei flussi IP per Lawful Interception

i-MCS può operare contemporaneamente sia con la funzione MRF illustrata sia con il Media Server integrato in OPM, ed in tal caso vengono applicati specifici criteri a livello di call handler per selezionare quale delle due funzionalità ingaggiare per erogare i necessari servizi.

La configurazione di i-MCS per Terrecablate quindi si compone sostanzialmente di cinque moduli: OMS, OPM, LBI, VTCHS ed il network element MRF.

I primi tre sono già presenti nella attuale rete di Terrecablate e saranno sostanzialmente aggiornati in termini di release software, mentre il nuovo modulo VTCHS sostituirà il modulo VTCHX precedente, sarà equivalente per features e dimensionamento ma introdurrà un meccanismo proprietario per realizzare la protezione in alta affidabilità locale non appoggiandosi più a meccanismi esterni di fault tolerance. Questo consentirà di rimuovere i vincoli di dipendenza dai servizi dello strato di virtualizzazione rendendo più flessibile l’inserimento in una infrastruttura già esistente.

Il modulo MRF si affiancherà ad OPM Media Server sostituendolo completamente nel momento in cui verrà dismesso il modulo OPM.

Nella configurazione in alta affidabilità che è richiesta, le istanze dei moduli di i-MCS, come accade per i-VLS, dovranno essere duplicate. A differenza dell’attuale meccanismo che vede la ridondanza del modulo VTCHX gestita attraverso la feature di Fault Tolerance di VMware, in i-MCS i moduli VTCHS dovranno essere in architettura active-active, i due lati del modulo dovranno elaborare lo stesso input nello stesso istante evitando quindi di dover effettuare una successiva sincronizzazione, verificando lo stato raggiunto alla fine dell’operazione per controllare il mantenimento dello stato di sincronizzazione.

2.1.3 Dimensionamenti i-MCS

La piattaforma i-MCS dovrà essere fornita con i dimensionamenti minimi riportati nella seguente tabella . I dimensionamenti non dovranno subire variazioni in relazione alla ridondanza geografica ed alla conseguente duplicazione di risorse hardware e software. La soluzione dovrà garantire la possibilità di ampliamenti nei dimensionamenti previo adeguamento delle licenze e, qualora necessario, aumento delle risorse virtuali dei componenti HW.

I dimensionamenti per la nuova Piattaforma i-MCS non potranno essere comunque in nessun caso peggiorativi rispetto alla fornitura esistente.

M/O	Item	Qty
M	HA base configuration not including OEM HW & SW (up to 250 calls)	1
M	license for Classless feature set (SIP, SIP-I, ISUP, SIP UA + trunk) + System Setup Support	1

O	P/S 1000VA 48VCC/230VAC	0
O	Additional(*) USEDSP-A2 - Integrated Media Gateway card	0
O	USTM1 - TDM line card/1STM-1 Electrical (working+protection)	0
O	USTM1 - TDM line card/1STM-1 Optical (working+protection)	3
O	UL2M16 - TDM line card TDM/16E1 75 Ohm (working+protection)	0
O	UL2M16 - TDM line card TDM/16E1 120 Ohm (working+protection)	0
O	SBC lite-USEDSP-A1 for IP-IP GW - up to 750 sessions + SW(working+protection)	0
O	USEDSP Cable for connection to Catalyst	0
O	USEDSP Acavet	0

O	license for H.248+Sigtran (M2UA, M3UA, IUA)	1
O	license for MGCP	1
O	license for V.5.2 (line card TDM required)	1
O	license for PRI (line card TDM required)	1
O	license for INAP (line card TDM required)	1
O	license for LI services	1
O	license for integrated SCP services	0
O	license for additional 30k configured users	1
O	license for block of additional 250 active calls	0
O	license for block of additional 1000 active calls (20% discount)	0
O	license for block of additional 2000 active calls (25% discount)	1
O	license for block of additional 5000 active calls (30% discount)	0

2.2 Sistema di gestione i-NEM

La soluzione richiesta da Terrecablate include il sistema i-NEM, in prima istanza come risposta all’esigenza legata all’obsolescenza del SNMP concentrator, ma non solo: i-NEM infatti presenta alcuni aspetti evolutivi rispetto alla situazione attuale, che meglio verranno descritti successivamente.

i-NEM è un sistema di monitoraggio, diagnostica e configurazione che fornisce la gestione in tempo reale a livello di risorse, che comprende Fault and Performance, Accounting, Inventory and Provisioning, Subscriber Management, per XXX, XXX, 0X, Data e Application Servers Product Suite di Italtel, nonché un vasto insieme di elementi di rete di terze parti inclusi nelle relative soluzioni Italtel.

i-NEM viene generalmente utilizzato nelle reti complesse e infrastrutture al fine di:

• supervisionare e gestire i Network Element (NE) in maniera centralizzata

• fornire funzionalità O&M unificate, indipendentemente dal NE gestito e dalla sua piattaforma

• ricoprire il ruolo di mediation, tra la rete e il livello OSS/BSS, fornendo loro una visione astratta e più semplice di una rete composta da apparecchiature eterogenee.

Figura 7 - Framework i-NEM

i-NEM come Network Manager supporta le seguenti caratteristiche:

• Gestione, supervisione e controllo di tutti i nodi presenti in rete. I criteri e le modalità di gestione sono indipendenti dalle caratteristiche e dai vincoli definiti dai differenti Vendor

• Integrabilità con applicazioni di altri competitor

• Federazione degli EM di altri vendor

• Abilitazione replacement delle applicazioni e/o degli EM di tecnica, spesso obsoleti, non scalabili e che introducono punti di vulnerabilità in la rete

• Integrazione/cooperazione con le catene gestionali

• Mascheramento della complessità della rete ad OSS/BSS con riduzione dei costi di adeguamento

• Traduzione dei dati nel formato riconosciuto dai sistemi utilizzatori

Le funzionalità principali sono funzioni di gestione applicabili a un elemento di rete generico o funzione di rete.

Il modulo Fault Management è dedicato alla “network surveillance”. Raccoglie gli eventi dalla rete, li filtra per riconoscere gli eventi di allarme e li normalizza, consente la riclassificazione di gravità e permette di effettuare un audit degli allarmi (riallineamento). Completa il set di feature una gestione da GUI del ciclo di vita dell'allarme e l'interfaccia Northbound che permette l'inoltro dell'allarme ai sistemi superiori.

Il modulo Performance Management esegue un monitoraggio quasi in tempo reale della qualità e dello stato del funzionamento della rete raccogliendo e analizzando le misurazioni raccolte dalla rete. Viene fornita la gestione dei KPI, generando indicatori (es. disponibilità, Latenza, Throughput, Jitter...) dall'elaborazione delle misurazioni delle prestazioni e CDR dalla rete.

L’Accounting è dedicato alla raccolta e all'elaborazione dei dati di utilizzo della rete dagli abbonati: eventi Rf e/o CDR. Gli eventi Rf vengono raccolti e quindi correlati per produrre IMS CDR. I CDR, anche se raccolti direttamente dall'elemento di rete o ottenuti per correlazione da eventi Rf, vengono formattati e quindi inoltrati agli OSS/BSS di livello superiore interessati. In questo modo i-NEM espone una funzione di mediazione tra le risorse di rete coinvolte nel servizio che generano i dati contabili ei sistemi OSS preposti all'elaborazione e all'elaborazione dei dati (tipicamente Billing Systems). L'interfaccia Northbound è basata

sul protocollo SFTP e supporta sia il metodo get che put. Viene fornito un formato CDR predefinito per CDR legacy mentre il formato CDR IMS è fornito per eventi Rf.

Il Provisioning è dedicato alla funzionalità di provisioning del subscriber. i-NEM supporta un'interfaccia SPML in direzione nord per la funzionalità di provisioning. Service Provisioning Markup Language (SPML) è un framework basato su XML, definito da OASIS per eseguire il provisioning di subscriber e servizi.

Per quanto riguarda l’area di Security Management ed Access Control, i-NEM fornisce le seguenti capabilities:

• Accesso centralizzato a tutti gli elementi di rete gestiti

• Autenticazione/Autorizzazione/strong auth (on demand)

• Restrizione degli accessi in rete e funzionalità di IDM anche per i nodi che non hanno analoghe funzionalità locali

• Autenticazione e autorizzazione locale, su DB LDAP embedded

• Autenticazione e autorizzazione su AAA server remoto (server LDAP del cliente)

• User Management: abilitazione attività d’operatore sulla base dei privilegi e delle autorizzazioni

configurate (segregazione domini)

• Remotizzazione GUI elementi gestiti

i-NEM ha una GUI intuitiva e Web-based, che fornisce tutte le operazioni di gestione di base sulla rete gestita. Integra le diverse tecnologie offerte dai framework software utilizzati ereditandone le componenti grafiche, tramite la GUI remota di target NE (dove applicabile).

2.2.1 Architettura

i-NEM si basa sui principi SOA come illustrato nella figura seguente:

Figura 8 - Architettura SW modulare i-NEM

Ogni modulo funzionale gira sulla piattaforma i-NEM. La piattaforma i-NEM funge da collante per i componenti interni. Virtualizza e migliora le funzionalità del sistema operativo e gestisce anche i servizi di security, logging e comunicazione utilizzati dai componenti dell'applicazione.

Mentre i moduli funzionali FM sono basati su framework open source (OpenNMS), i moduli funzionali CM e AM sono proprietari (i moduli funzionali PM, CM e AM sono proprietari)

i-NEM è composto da blocchi base (piattaforma, anagrafica NE, UM) e blocchi opzionali (FM, PM, AM). Tali blocchi saranno abilitati e configurati sulla base dello scenario e delle esigenze specifiche di Terrecablate.

2.2.2 Features in rete Terrecablate

i-NEM viene richiesto, come già detto, in sostituzione dell’obsoleto SNMP Concentrator, che realizzava, nella

soluzione corrente, solo la funzionalità di raccolta allarmi.

Nella soluzione proposta, i-NEM realizza tutte le funzionalità FCAPS, sostituisce le funzioni dell’SNMP Concentrator, ed offre un arricchimento delle feature rispetto alla precedente soluzione, apportando indubbi e assoluti vantaggi legati all’introduzione di feature evolutive.

Le funzionalità che verranno erogate all’interno del perimetro della soluzione sono quelle di Assurance, che

comprendono il Fault Management e il Performance Management.

Per quanto riguarda il Fault Management il set di features contemplerà una gestione completa degli allarmi (ricezione, filtraggi, normalizzazione…) nonché il mantenimento dell’interfaccia northbound SNMP verso i sistemi OSS, come già accade nella soluzione attuale.

Funzionalità completamente nuova sarà quella della gestione delle misure di Performance, che prevede la raccolta delle misure non solo da i-MCS ma anche dal NetMatch-S LE e da MRF presenti in soluzione, e una gestione locale che consente di configurare i report di raccolta selezionando la tipologia delle misure e dei contatori di interesse, impostando la frequenza e il periodo di raccolta, e consentendo una visualizzazione sulla GUI di i-NEM articolata in browser e diagrammi. La GUI del Performance Management sarà acceduta da una utile dashboard che riporterà delle informazioni di sintesi.

Il sistema, essendo modulare, dovrà essere fornito con le componenti funzionali mandatorie, cioè la piattaforma, lo User Management, la Security, e il modulo di Assurance che comprende le feature di Fault Management, deputato alla gestione allarmi, e Performance Management, deputato alla raccolta delle misure dai NE gestiti. i-NEM nel perimetro della soluzione di Terrecablate gestisce i-MCS, NetMatch-S e MRF; quest’ultimo, pur essendo una funzionalità della suite i-MCS, si presenta in rete come un Network Element distinto, con le sue peculiarità funzionali e il suo OPM. La sua gestione, in ogni caso, è identica a quella di un qualsiasi i-MCS, se ne evidenzia l’identità solamente per ribadire il suo ruolo caratteristico nell’ambito della rete gestita.

Le funzionalità che dovranno essere erogate nell’ambito del Fault Management sono quelle di Alarm

Surveillance:

• Raccolta eventi

• Logging eventi

• Normalizzazione eventi

• Filtraggio eventi

• Ciclo di vita dell’allarme

• Audit

• Riclassificazione gravità

• Correlazione eventi (inizio/fine/variazione allarme caratterizzato dallo stesso ID)

• Interfaccia Northbound SNMP

• Storico allarmi

• Gestione allarmi nativi i-NEM Nell’ambito del Performance Management:

Sempre nel perimetro delle funzionalità di Assurance, la funzionalità di Performance Monitoring fornisce le seguenti feature:

• Raccolta misure dalla rete

• Elaborazione misure

• Generazione KPI

• Configurazione report di misure, intesa come configurazione dei parametri relativi alla raccolta

misure (tipologia, frequenza di raccolta…)

• Performance GUI

Nell’area di Performance Management, i-NEM offre una GUI il cui punto di ingresso è la dashboard.

Dalla dashboard l'utente si potrà accedere ai moduli per l'amministrazione (utilizzati per configurare l'oggetto da raccogliere, le soglie e così via) o ai moduli che mostrano gli indicatori raccolti.

Saranno disponibili diversi strumenti per rappresentare e visualizzare gli indicatori e si potrà selezionare l'elenco degli oggetti da visualizzare nella schermata della GUI.

Tutti i contatori di ogni misura potranno essere esportati in un unico file CSV e salvati su un'area definita dall'utente.

Il sistema dovrà essere customizzato sulle esigenze di Terrecablate affinché in qualsiasi momento, possa essere visualizzato lo stato generale della centrale con descrizione degli allarmi attivi in una modalità ben comprensibile all’operatore. Dovrà essere visualizzabile lo stato delle interfacce V5.2, PRI E1, SS7 e lo stato dei vari moduli hardware/software del sistema.

2.3 Session Border controller UNI

Il fornitore dovrà proporre un SBC carrier grade che possa integrarsi completamente all’interno della soluzione ITALTEL per poter gestire tutte le funzionalità di SIP SERVER, SIP REGISTRAR e Load balancer per le utenze voip Terrecablate, siano esse attestate su rete privata Terrecablate che su rete pubblica. Il numero delle sessioni gestibili dovrà essere in grado di supportare con ampi margini tutto il traffico attuale della rete Terrecablate e dovrà poter essere incrementato tramite adeguamento delle licenze software. Tale SBC dovrà essere completamente compatibile con la soluzione ITALTEL, e sarà carico del fornitore gestirne l’integrazione con il nuovo ambiente, con la rete VOIP Terrecablate e le sue CPE (zyxel, adb, aethra, kalliope, asterisk). L’SBC proposto dovrà essere certificato con Microsoft TEAMS.

L’ SBC dovrà essere di un vendor di primaria importanza nel panorama internazionale ed il fornitore dovrà

dare evidenza che tale soluzione sia in esercizio nella rete di almeno tre operatori nazionale.

La soluzione sbc fornita, dovrà essere installata all’interno dell’ambiente hardware/software facente parte

del presente bando che ne dovrà pertanto tener conto.

Dovrà seguire un collaudo che certifichi la corretta funzionalità del SBC nei vari scenari di rete. Inoltre il fornitore dovrà gestire, in collaborazione con Terrecablate, l’inserimento in rete dell’sbc come front end tra il dominio SIP dell’utenza VOIP Terrecablate e l’attuale sip server (xxxx.xxxx.xx:5.43.239.1) secondo le specifiche e le modalità che il fornitore stesso suggerirà per minimizzare i disservizi verso i clienti.

Adesso tutte l’utenza voip Terrecablate si registra/autentica su xxxx.xxxx.xx:5.43.239.1. Successivamente l’utenza voip dovrà vedere il nuovo SBC che poi inoltrerà le richieste di registrazione/autenticazione verso i- MCS.

L’inserimento del nuovo SBC non dovrà alterare la continuità di fatturazione con il sistema InfINIT-OLO.

L’SBC dovrà essere ridondato tra i due siti di Siena e Poggibonsi così come già previsto per gli altri componenti (e come descritto al punto seguente) della soluzione in maniera da poter garantire la continuità del servizio nel caso di fault di una delle due sedi.

Questo il dimensionamento:

Numero di sessioni audio: 500 Transcoding su sessioni audio: 10 % DOS/DDOS Protection and Static ACL MTF - Media Termination Function CDR - Call Detail Records (Opzionale)

CDR and QOS - CDR w Quality of Service information (Opzionale) Ci sarà una percentuale minoritaria di utenti dietro NAT

2.4 Ridondanza geografica

2.4.1 Descrizione soluzione

La soluzione richiesta, e descritta nei precedenti paragrafi, prevede una evoluzione dei servizi presenti con una configurazione in ridondanza geografica tra il sito di Siena (primario) ed il sito di Poggibonsi (secondario).

Si evidenzia che la soluzione non considera la protezione in ridondanza geografica del modulo OPM con le relative attestazioni (V5, PRI, ISUP).

In caso di disastro del sito principale di Siena, dove oggi sono allocati tutti i Network Elements e le applicazioni, le attestazioni e servizi erogati da OPM non saranno disponibili fino a suo ripristino.

Sotto si riporta ciò che la soluzione proposta prevede per i singoli NE presenti:

• i-MCS

I diversi moduli costituenti i-MCS hanno diversi approcci e configurazioni nella realizzazione della ridondanza geografica. Nella seguente figura si possono vedere come si distribuiscono i diversi moduli di i-MCS tra i due siti e le caratteristiche di ciascuno di essi:

Figura 9 Ridondanza geografica per i-MCS

Di seguito il dettaglio dei diversi comportamenti:

o OMS: viene splittato nelle sue componenti OMU tra i due siti, a titolo di esempio considerando la dinamicità dello stato di ciascun OMU si potrà avere OMU_A (ONL) nel sito Master di Siena e OMU_B (BAK) nel sito Slave di Poggibonsi.

In caso di disastro di uno qualunque dei due siti, l’OMU nel sito rimasto se BAK prende in carico in automatico tutta la operatività swappando da BAK a ONL, se invece è già ONL non compie nessuna azione.

Per garantire la sincronizzazione tra i due OMU il collegamento tra i due siti deve avere una latenza di 5 msec ed una banda di 1Gbps con almeno 100 Mbps garantiti.

o VTCHS e LBI: I moduli VTCHS ed il LBI sono attivi, in high availability, solo nel sito Master di Siena. Devono essere predisposte le VMs relative anche nel sito Slave di Poggibonsi, che deve poter gestire gli stessi IPs relativi agli applicativi presenti in Siena.

In caso di disastro del sito secondario di Poggibonsi, nessuna azione deve essere fatta lato i- MCS, non avendo impatto su VTCHS e LBI attivi in Siena.

In caso di disastro del sito primario di Siena, devono essere isolate le VMs di VTCHS e LBI di Siena, onde evitare successivo split brain, e devono essere accese le VMs VTCHS e LBI di Poggibonsi e caricate da OMS/OMU_B con il relativo sw e configurazione (tempo inferiore ad 1h).

o MRF: il modulo MRF con tutte le sue componenti viste in precedenza sarà attivo, in configurazione di high availability, in entrambi i siti con le risorse a disposizione del modulo VTCHS attivo che richiederà i servizi indipendentemente dal sito in cui si trova. Le risorse di MRF sono a disposizione anche del modulo OPM nel sito primario.

In caso di disastro del sito primario le risorse di MRF rimaste saranno a disposizione del VTCHS del sito secondario quando quest’ultimo avrà terminato le procedure di avvio.

• NM-S LE

Si prevede l’inserimento di un secondo NM-S LE, identico al primo per caratteristiche, sw e dimensionamento, nel sito secondario di Poggibonsi.

Su base progetto implementativo si potranno prevedere due modalità alternative di gestione della ridondanza geografica dei NM-S LE: in modalità active-active, con una ripartizione del traffico tra i due siti oppure in modalità active-standby dove solo il sito primario verrà interessato dal traffico entrante/uscente dalla rete di Terrecablate.

Nella prima modalità, in caso di down di uno qualsiasi dei due siti, sono abbattute le chiamate in corso nel sito che ha subito il disastro. Se il down è relativo al sito primario, il NM-S del sito secondario deve attendere il ripristino di VTCHS e LBI della componente i-MCS.

Nella seconda modalità un fault del sito primario implicherà ovviamente la perdita delle chiamate in corso nel sito ed una ripartenza del NM-SLE nel sito secondario diventato attivo quando saranno ripristinate anche VTCHS e LBI della componente i-MCS.

• SBC UNI

Si prevede che SBC UNI sia fornito in configurazione di high availability locale ed installato in entrambi i siti. I due SBC UNI saranno in modalità active-active e si potranno distribuire l’utenza SIP ma saranno dimensionati in modo da gestire tutta l’utenza su uno solo in caso di fault di un sito, sia esso primario o secondario.

• i-NEM

i-NEM viene fornito in configurazione DR active / standby tra i siti di Siena e Poggibonsi. Architettura:

o Due ambienti virtualizzati interconnessi

o Sito primario attivo

o Sito secondario in standby

Requisiti funzionali:

o Costante allineamento del software applicativo (software e patch di i-NEM) installato sui due siti.

o Procedura di backup periodico, con frequenza configurabile da GUI da un operatore con opportuni privilegi.

o Procedura di restore sul file-system del sito secondario, per il caricamento dei dati backuppati.

o Procedura di switch delle attività di gestione dal sito primario al secondario.

Si specifica che Il sito primario e quello secondario saranno in grado di scambiare una quantità significativa di dati con banda di interconnessione sufficiente a garantire il trasferimento dei dati in tempi ragionevoli.

Procedure di backup e restore Backup

o Sul sito primario vengono effettuati periodicamente i backup necessari.

o I file di backup vengono immediatamente esportati (via SCP) verso file-system dedicati disponibili sul sito secondario.

o Le frequenze di export e retrieve sono configurabili

o L’allineamento per i dati previsti in Terrecablate (fault, performance) viene effettuato normalmente con periodicità giornaliera

Restore

o Tipicamente, il sito secondario è in standby e non esegue operazioni.

o Quando sul sito primario si verifica un disastro, il sys admin esegue la procedura di restore sul sito secondario.

o La procedura di restore viene eseguita manualmente e richiede la password di root per accedere ai server di i-NEM del sito secondario.

o Al completamento della procedura di restore, il sito secondario contiene tutti i dati critici derivati dal sito primario.

Figura 10 - Procedura di sincronizzazione fra i-NEM primario e secondario

Procedura di switch

La procedura di switch attiva i-NEM secondario dopo un disastro (evento catastrofico naturale, attacco, ecc.) che ha generato un guasto totale del sito primario. Questa procedura configura il sito secondario come i-NEM attivo di riferimento. In caso di down del sito Master, il ruolo del sito in standby viene modificato quindi in Master.

Figura 11 - Procedura di switch fra i-NEM primario e secondario

La procedura di switch sarà manuale e dovrà essere eseguita sul sito secondario da un amministratore di sistema che necessiterà dell'accesso root alle macchine.

Gli IPs di comunicazione verso Northbound e Southbound del sito Standby saranno diversi da quelli del sito Master. Tutti i NE e tutti gli OSS/BSS dovranno essere configurati in modo da utilizzare i nuovi indirizzi IP virtuali i-NEM come nuovi punti di riferimento per stabilire la connessione con l'Element Manager.

In questo modo, opportunamente preconfigurati i NE, la comunicazione si ripristinerà senza modifiche lato NE. Verso il layer northbound, sarà sufficiente che l’OSS ricevente abbia aperta la comunicazione IPs con il sito secondario e non saranno necessarie modifiche durante disastro di sito per ricevere i dati.

In caso di down di sito standby nessuna azione dovrà essere prevista ed il ripristino del sito standby sarà fatto con procedure standard che verranno fornito in fase di Delivery.

2.5 Hardware / Software

La fornitura dell’hardware e software dovrà essere parte integrante del presente bando di gara. Il partecipante dovrà fornire l’infrastruttura hardware e software per entrambi i siti di Siena e Poggibonsi dimensionata in maniera tale da poter gestire tutte le vm specifiche per il funzionamento di quanto esplicato ai punti precedenti 2.1, 2.2, 2.3 e 2.4.

L’infrastruttura HW/SW (così come nell’attuale soluzione i-VLS implementata nel sito di Siena) dovrà poter ospitare anche le VM relative ad INFINIT-NGN ed INFINIT-OLO-RTBS in ridondanza anch’esse.

Queste le specifiche tecniche per le suddette macchine virtuali da prevedere nella nuova infrastruttura virtuale:

	sistema	vCPU	ram	GB
SERVER 1	db	8	16	300
SERVER 2	db	8	16	300
SERVER 3	db	8	16	300
SERVER 1	web	2	8	300
SERVER 2	web	2	8	300
SERVER 1	slee	4	12	300
SERVER 2	slee	4	12	300
SERVER 1	media	8	12	300
SERVER 2	media	8	12	300
SERVER 1	mediation	2	8	300
SERVER 2	mediation	2	8	300
SERVER 3	Bacula	1	2	100
SERVER 3	CC	2	8	50
SERVER 3	GDW	1	6	140

L’installazione e collaudo dei servizi relativi a INFINIT-NGN ed INFINIT-OLO-RTBS e la relativa ridondanza,

NON fanno parte del presente bando di gara.

Sarà carico di Terrecablate predisporre tutta la parte di networking limitata alla raggiungibilità dei due siti sulla base delle specifiche dettate dal fornitore in termini di banda, vlan, numero e tipologia di porte. Si lascia al fornitore la configurazione del livello IP e la fornitura degli eventuali switches.

L’hardware dovrà essere fornito con alimentazione a 220V. Sarà cura di Terrecablate fornire spazio rack ed alimentazione a 220V sulla base delle specifiche tecniche che il fornitore dovrà dettagliare in una documentazione preliminare all’esecuzione del progetto.

2.6 Funzionalità aggiuntive

2.6.1 Re-routing

i-MCS dovrà implementare la funzionalità di re-routing che consenta in maniera automatica di instradare le chiamate su altro flusso di interconnessione qualora le venga restituita una determinata causa di rilascio.

3 Servizi professionali

3.1 Training

Il fornitore dovrà garantire 10 gg di training on site, non necessariamente consecutivi, da fornire agli operatori terrecablate. Tale training potrà riguardare aspetti di I-MCS, i-NEM, Netmatch, sbc UNI e aspetti sistemistici legati anche alla procedura di disaster recovery.

3.2 Installazione hardware, software ed integrazione dei sistemi a contorno

• Definizione progetto esecutivo in collaborazione con Terrecablate ed il fornitore dei sistemi di rete intelligente e billing

• installazione Hardware e configurazione delle VM che ospiteranno i-MCS, i-NEM, SBC UNI sui siti di Siena e Poggibonsi

• Adeguamento del SBC NNI e relativa installazione delle VM sul sito di Poggibonsi

• Interfacciamento con il soggetto fornitore del sistema di rete intelligente e billing per l’installazione di

queste due soluzioni nella nuova infrastruttura

• Integrazione del nuovo ambiente nell’infrastruttura telefonica esistente intesa anche come tutti i sistemi al contorno che la costituiscono (Billing, SLEE, OPM, ecc…)

• Verifica procedura per gestione disaster recovery

• Pre-collaudo della soluzione completa che dovrà precedere l’attività di migrazione.

3.3 Migrazione

A seguito del positivo esito delle attività di cui al punto precedente la migrazione sarà effettuata secondo i seguenti step:

1) blocco delle attività di configurazione sulla soluzione in esercizio

2) acquisizione da i-VLS in esercizio della configurazione di sistema e del database degli utenti. Tali informazioni dovranno essere elaborate attraverso tools di conversione per essere poi importate in i-MCS

3) isolamento delle VM di i-VLS dalla rete

4) startup di i-MCS con caricamento dei moduli virtualizzati e di OPM che passa nella nuova release, e della base dati importata da i-VLS. Terminata la fase di avvio, i-MCS inizia a gestire il traffico reale.

5) esecuzione dei test di validazione e monitoraggio della nuova soluzione

6) riapertura alla normale operatività sulla nuova rete

7) Collaudo finale

In caso di necessità, una procedura di rollback provvederà a ripristinare le funzionalità di i-VLS riportando la rete alla situazione precedente la migrazione.

Il riutilizzo da parte delle funzioni di i-MCS degli stessi indirizzi IP di rete già in uso su i-VLS ed il mantenimento delle interfacce verso gli apparati esterni dovrà consentire di passare da i-VLS ad i-MCS senza ripercussioni verso i sistemi superiori di Terrecablate o verso le reti interconnesse con quella dell’operatore. Il fornitore dovrà essere in grado di condurre in autonomia rispetto a terrecablate tutte le attività di cui ai punti immediatamente precedenti. Con Terrecablate il fornitore dovrà preventivamente concordare il piano delle operazioni. In questa fase dovrà essere definita anche la procedura per la migrazione delle registrazioni/autenticazioni degli utenti SIP dal sip server al SBC-UNI. Sarà poi cura di Terrecablate decidere le tempistiche per l’attuazione del piano di migrazione ad SBC-UNI.

3.4 Collaudo finale

La fase di collaudo finale della nuova infrastruttura dovrà prevedere il test di tutti i servizi attivi in rete Terrecablate e la verifica del corretto funzionamento. Per servizi attivi si intendono tutti i servizi che saranno oggetto di migrazione da i-VLS e tutti i servizi non ancora attivi ma che sono oggetto della presente fornitura, compreso il sistema di monitoraggio ed SBC-UNI.

La firma del collaudo avverrà non prima di 30gg dal giorno della migrazione. Periodo di monitoraggio durante il quale dovranno essere gestite e risolte tutte le eventuali segnalazioni di disservizio o le difformità rispetto a quanto richiesto nel bando.

Si rimanda comunque ad una test list dettagliata che verrà fornita da Terrecablate nella fase esecutiva del progetto. Il superamento dei test definiti in test list e la risoluzione di tutti i problemi che dovessero sorgere nel periodo di monitoraggio definirà il superamento del collaudo.

La fornitura sarà dichiarata conclusa solo a seguito dell’avvenuto collaudo positivo e le successive fasi

manutentive decorreranno da tale data.

4 Assistenza tecnica con pronto intervento, supporto e manutenzione

Il fornitore dovrà garantire un servizio di assistenza, supporto e manutenzione così come definito ai punti seguenti e riguardante tutti gli elementi hardware e software oggetto della presente fornitura.

4.1 Punto di Accesso e SLA

Il fornitore dovrà mettere a disposizione un punto di Accesso preposto all’erogazione dei servizi di assistenza, supporto e manutenzione. L’accesso ai servizi di assistenza dovrà essere possibile mediante telefono, e-mail o con accesso diretto ad un sistema di web ticketing. Ad ogni ticket aperto sarà assegnato un numero di riferimento univoco. Tale servizio dovrà essere erogato in lingua italiana.

Le richieste dovranno essere gestite in accordo ai Livelli di Servizio elencati nella seguente tabella.

SERVIZI

Gravità Anomalia e

	Livello di prestazione
	Critica	Grave	Lieve
Punto di Accesso
Disponibilità	7x24
Assistenza 1°/2°/3° livello
Tempo di richiamata dello specialista	< 1 H	<8 BH	<2 BD
Tempo di risoluzione provvisoria anomalia	< 8 H	0 XX	0 XX
Tempo di risoluzione definitiva anomalia	5 XX	0 XX	00 XX

XX: Business Day, NBD: Next Business Day, CD: Calendar Day, BH: Business Hour. Service Level Agreement

La definizione della gravità del guasto sarà definita dal tecnico Terrecablate all’apertura del ticket.

Le anomalie saranno classificate in base alla loro gravità in:

• Critica: anomalia del prodotto tale da causare interruzione del traffico o gravi riduzioni delle funzionalità principali. Di seguito vengono elencati alcuni esempi a titolo indicativo e non esaustivo:

• L’anomalia produce interruzione totale o parziale del traffico pagante.

• La rete non è più controllabile attraverso il sistema di gestione: in questo caso non ci sono altri modi per sapere se si sono manifestate anomalie che provocano interruzione di traffico.

• L’anomalia produce perdita delle informazioni di tariffazione.

• L'anomalia causa la perdita delle funzioni principali della centrale di switching.

• L’anomalia non permette l’importazione o la valorizzazione dei CDR sul Billing.

• L’anomalia causa il blocco dell’esportazione dei dati per la fatturazione.

• Grave: anomalia che non causa interruzione di traffico, ma che tuttavia riduce in modo sensibile le funzionalità principali del prodotto. Di seguito vengono elencati alcuni esempi a titolo indicativo e non esaustivo:

• Anomalia del sistema di gestione di rete che impedisce l’attivazione di un nuovo servizio.

• Impossibilità di raccogliere le informazioni per la valutazione del livello di qualità del servizio erogato.

• Problemi nell’utilizzo dell’interfaccia del Billing o dell’accesso al DBMS

• Anomalie riscontrate duranti i controlli nella fase di fatturazione che possono riguardare, ad esempio, elaborazioni parziali dei CDR, errate valorizzazioni di alcune voci di costo, mancate fatturazioni di alcuni clienti.

• Lieve: anomalia che non disturba in modo sensibile le funzioni principali del prodotto. Il problema può essere facilmente tollerato durante l’esercizio oppure può essere facilmente aggirato usando altre procedure. Di seguito vengono elencati alcuni esempi a titolo indicativo e non esaustivo:

• Anomalie nella rappresentazione grafica degli elementi di rete.

• Anomalia nei programmi accessori per l’elaborazione dei dati di qualità di traffico

(istogrammi, statistiche)

• Anomalie non bloccanti nella fase di provisioning sul Billing.

• Accesso non consentito ad alcune utenze.

Viene richiesto che il fornitore metta a disposizione di Terrecablate un numero telefonico univoco con disponibilità h24/365 con la risposta di uno specialista tecnico per l’apertura di guasti con gravità critica e per la gestione delle escalation.

4.2 Assistenza di 1°/2°/3° livello

Il servizio di Assistenza di 1°/2°/3° livello, dovrà fornire interventi finalizzati alla correzione o neutralizzazione di anomalie hardware e/o software nei prodotti della rete e relativi Sistemi di Gestione offerti.

Rientrano nel servizio di assistenza le sostituzioni, totali o parziali dei materiali forniti, necessarie alla risoluzione definitiva delle anomalie.

Nella gestione dei ticket è richiesto al fornitore di dotarsi di un ambiente per il test dei servizi con l’obiettivo di essere autonomo, ove possibile, nell’analisi dei disservizi e nel recupero dei tracciati necessari al troubleshooting.

Il fornitore, pertanto, a fronte dell’apertura del ticket da parte di Terrecablate, dovrà procedere in maniera autonoma a prelevare i tracciamenti sugli apparati di rete utilizzando strumenti hardware/software che dovranno far parte della fornitura. Terrecablate fornirà tutto il supporto necessario per la predisposizione di tali strumenti.

Sarà quindi compito del fornitore l’analisi della segnalazione, l’individuazione del problema mediante configurazione/reperimento dei tracciati e la risoluzione dello stesso qualora imputabile ad elementi facenti parte della fornitura.

Durante la sessione di telediagnostica saranno prese tutte le cautele per evitare turbative al traffico in rete. L’Aggiudicatario garantirà un’elevata sicurezza e segretezza per la protezione di tutti i dati di Terrecablate in ottemperanza delle Leggi vigenti.

Tutte le azioni volte alla risoluzione delle anomalie saranno eseguite dal fornitore in accordo con il personale Terrecablate.

Al termine dell’intervento sarà inviato a Terrecablate un rapporto sul lavoro svolto.

4.3 Intervento on site

Se l'anomalia non potesse essere neutralizzata tramite l'intervento di telediagnostica, Il fornitore dovrà garantire l'intervento on site rispettando gli SLA precedentemente stabiliti.

4.4 Manutenzione evolutiva

Il servizio di manutenzione dovrà essere di tipo evolutivo, dovrà cioè comprendere tutti gli aggiornamenti hardware/software della piattaforma che verranno rilasciati durante il periodo di validità del contratto di manutenzione.

4.5 Affiancamento post migrazione

Il fornitore dovrà garantire un periodo di affiancamento post migrazione, durante quindi la fase di collaudo, da parte di un tecnico specializzato presso Terrecablate per un totale di 5 giorni lavorativi. Tali giorni di affiancamento saranno richiesti da Terrecablate a seconda delle proprie esigenze e necessità e non necessariamente in maniera continuativa.

4.6 Supporto

Il fornitore dovrà mettere a disposizione un servizio di supporto per tutte le attività che dovranno essere svolte sulla piattaforma e che non saranno direttamente vincolate alla presenza di una anomalia. Di seguito vengono elencati alcuni esempi a titolo indicativo e non esaustivo:

• Supporto per la configurazione di nuovi servizi

• Supporto per spiegazioni relative al funzionamento di alcuni servizi

Document Metadata

Table of Contents

Capitolato tecnico prestazionale

Document Metadata