Annesso I – Capitolato d`oneri

COMMISSIONE EUROPEA
Centro Comune di Ricerca
Istituto per la Protezione e la Sicurezza dei Cittadini
Unità Supporto di gestione
Annesso I – Capitolato d'oneri
“Fornitura di servizi di comunicazione via SMS dal web per i sistemi di allarme
del Centro comune di ricerca”
1. Titolo del contratto
Fornitura del servizio di comunicazione SMS tramite web per il sistema di allerta
del Centro Comune di Ricerca
2. Finalità e ambito del contratto
L’Unità Global Security and Crisis Management (GlobeSec) dell’Istituto per la
Protezione e la Sicurezza del Cittadino (IPSC) del Centro Comune di Ricerca
della Commissione Europea fornisce un supporto scientifico e tecnico alla
Direzione Generale della Commissione con responsabilità nello sviluppo,
attuazione e monitoraggio delle politiche dell’UE in relazione alle Relazioni
Estere, Sicurezza, a Anti-Frode. All’interno di questa missione, l’Unità sviluppa
due sistemi informatici per la raccolta e l’analisi d’informazione in grado di
generare allerte in caso di nuovi eventi: il Global Disaster Alert and Coordination
System (GDACS, sistema mondiale per l’allerta dei disastri e per la coordinazione
dell’assistenza internazionale) e Europe Media Monitor (EMM, sistema per il
monitoraggio delle notizie).
Un primo sistema, GDACS, è un sistema che controlla i disastri naturali mondiali
e allerta le comunità umanitarie nel caso in cui un evento abbia un’alta probabilità
di diventare un disastro di dimensioni internazionali per la popolazione locale.
GDACS presta un servizio alla Commissione Europea, alle Nazioni Unite e a tutte
le maggiori organizzazioni umanitarie e di protezione civile.. In caso di un
improvviso disastro, GDACS manda messaggi di allerta a tutti gli utenti tramite
SMS, fax e email. Tipicamente, solo poche allerte sono generate per ogni mese,
ma un’allerta può generare fino a 6000 SMS, i quali necessitano di essere mandate
il più velocemente possibile (meno di 5 minuti) ovunque nel mondo. È atteso una
capacità d’invio di 10 SMS al secondo o maggiore. Tenendo conto di un
moderato aumento degli utenti, GDACS genera in media 150000 SMS all’anno.
Un secondo sistema è l’Europe Media Monitor (EMM), un servizio di
monitoraggio delle notizie on line. Esso controlla alcune 15 nuove agenzie, più di
2000 fonti d’informazione on line (TV, radio e stampa) e tutte le rassegne stampe
quotidiane delle 27 capitali dell’UE e oltre. EMM è il risultato di un progetto di
ricerca in corso al CCR, il quale sviluppa nuove tecniche per la raccolta e l’analisi
automatica di informazioni. EMM è ora operativo per molti servizi della
Commissione e in particolare per il DG COMM. Un aspetto importante delle
operazioni dell’EMM è il servizio di allerta tramite SMS, il quale informa i
Portavoci della Commissione e altre persone in tempo reale delle importanti
notizie dell’ultima ora rilevate da EMM, ovunque essi siano nel mondo.
1
Tipicamente, EMM genera circa 300 SMS al giorno con punte di 2000 SMS al
giorno, che in media sono circa 100000 SMS all'anno.
Entrambi i sistemi richiedono servizi di comunicazione che siano rapidi, robusti
affidabili e con un’ampia copertura internazionale. È importante essere in grado di
raggiungere i telefoni cellulari in qualsiasi paese indipendentemente dalla
tecnologia di rete (GSM o CDMA). Inoltre, i messaggi vengono inviati in 25
lingue e il servizio di comunicazione dovrebbe quindi supportare la codifica
Unicode. In particolare l’Interfaccia di Programmazione per Applicazioni (API)
deve accettare i messaggi Unicode (Codifica UTF-8).
Sia EMM che GDACS sono servizi operativi con interfacce esistenti per i sistemi
SMS basati su HTTP POST. Al fine di consentire un facile passaggio verso il
nuovo sistema SMS, le interfacce devono essere basate su HTTP POST e devono
essere disponibili e ampiamente testate senza ulteriore sviluppo da parte
dell’offerente.
3. Oggetto del contratto
L’oggetto del bando di gara è la fornitura di un servizio SMS tramite web.
La struttura dell’offerta tecnica deve seguire la struttura del paragrafo di questa
sezione. Ogni sezione (da 3.1. Livello di servizio, a 3.5. Requisiti di sicurezza)
deve apparire nell’offerta.
Le offerte devono essere conformi alle prescrizioni tecniche obbligatorie che sono
indicate in grassetto e formulate usando il termine “deve” o “devono”.
3.1
Livello di Servizio
Il servizio deve essere disponibile per il 99% del tempo. I livelli di
servizio devono essere definiti nell’offerta.
Il tempo massimo di intervento in caso di mancanza di servizio deve essere
definito nell’offerta e non deve superare le 2 ore.
Il minimo e massimo throughput (numero massimo di messaggi al
secondo) e il minimo e massimo latency (differenza tra la ricezione della
richiesta di messaggio da parte del CCR e l’invio del messaggio) dei
messaggi devono essere definiti nell’offerta. Il minimo throughput per il
servizio SMS è di 2 messaggi/secondo.
3.2
Formato del servizio SMS
a. Il servizio deve essere disponibile al momento della firma del
contratto attraverso un semplice HTTP POST. I parametri specifici
del messaggio (ad esempio a, da, testo del messaggio ecc.) devono
essere specificati con semplici parametri HTTP POST.
b. L’offerta deve includere una documentazione dettagliata sulle
specifiche di interfaccia per ogni funzione (includendo un esempio).
3.3
Funzionalità del servizio
Le seguenti funzionalità devono essere fornite dal servizio.
2
a. Invio dei messaggi: il servizio viene richiesto con un messaggio
(possibilmente in formato Unicode o equivalente) e uno o più numeri
di telefono dei destinatari. I messaggi più lunghi devono essere
accettati e inviati come SMS concatenati automaticamente. È
sottointeso che i messaggi concatenati potrebbero incorrere in un costo
proporzionale al numero totale di messaggi usati. Il sistema dovrebbe
consentire di monitorare lo stato dei messaggi inviati, oppure
registrando un codice identificativo specificato dal CCR oppure
restituendo un identificatore unico del messaggio. Il mittente dell’SMS
mostrato al destinatario dovrebbe essere un campo di testo descrittivo,
e dovrebbe essere uno dei parametri del messaggio (campo “da”).
Attualmente questo campo può assumere almeno tre differenti valori
(EMM, RNS e GDACS), ma dovrebbe essere possibile per il CCR
nominare un altro valore, possibilmente previa consultazione con il
fornitore del servizio.
b. WAP PUSH: Deve essere possibile mandare messaggi WAP Push.
c. Stato del messaggio: per ogni messaggio, deve essere possibile
determinare lo stato di consegna: consegnato o non consegnato, con
timestamp (indicazione data e ora) e descrizione degli errori. Il metodo
dovrebbe essere in forma di un call-back: il fornitore del servizio
chiama un URL (da determinare da parte del CCR) con l’ID di
messaggio, lo stato del messaggio, identificatore “da” e timestamp
come parametri minimi.
d. Resoconto: deve essere possibile richiedere (usando API o un servizio
web) il numero di messaggi che sono stati inviati e il numero di
messaggi che possono essere ancora inviati.
e. Personalizzazione mittente del messaggio: dato che almeno due (EMM
e GDACS) o più sistemi useranno il servizio, deve essere possibile per
il CCR fornire un Identificatore di Sistema per ogni messaggio per
avere le statistiche di utilizzo da parte del Sistema Identificativo (ad
esempio “EMM” or “GDACS”). Questo può anche assumere la forma
di un nome utente diverso per ogni sistema con un appropriato
resoconto per utente/account.
f. Copertura Routing: deve essere possibile verificare (usando API o un
servizio web), senza l’utilizzo di credito, se un numero di telefono è
abilitato a ricevere messaggi dal fornitore del servizio.
3.4
Copertura geografica
a. Il servizio dovrebbe avere un’estensione geografica globale. Il servizio
dovrebbe preferibilmente non dipendere da un singolo provider di
telecomunicazioni.
b. Se l’estensione non è universale, devono essere forniti precisazioni su
quali aree geografiche (paesi dell’elenco ITU-T E.2121) sono
1
http://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-E.212A-2007-PDF-E.pdf
3
completamente coperte dal servizio e quali paesi sono coperti solo
parzialmente o per nulla. Fattori limitanti come l’incompatibilità del
servizio con una o più tecnologie di rete (ad esempio GSM or CDMA)
e problemi noti con filtri spam o reti particolari (ad esempio l’utilizzo
di un shared short code) nei paesi riceventi devono essere resi noti.
c. Il prezzo unitario del messaggio deve essere indipendente dal paese
di destinazione.
3.5
Requisiti di sicurezza
Il provider del servizio deve garantire che i messaggi mandati
attraverso il loro sistema non possano essere accessibili a terzi senza il
consenso del CCR.
4. Test del servizio
Per verificare la disponibilità e il funzionamento del servizio, gli offerenti devono
rendere disponibile un account con un numero limitato di crediti (almeno 100
crediti) in modo che il CCR possa eseguire le prove elencate nella tabella
sottostante.
Tutti i test devono superare i requisiti obbligatori. I test saranno eseguiti
utilizzando un modulo HTML in un normale browser su un sito web interno al
CCR il quale sarà presentato con il metodo POST (o GET) a un URL specificato
dall’offerente con i parametri specificati dall’offerente. Le parole chiavi dei
parametri (non i valori) usati nel servizio di test devono essere identiche come nel
servizio operazionale.
Test
Criteri di successo
Ripetuti
Crediti minimi
necessari
Invio di un
messaggio più breve
di 160 caratteri ad
un numero3, con un
“da” definito dal
CCR.
Messaggio ricevuto
entro 10 secondi1
5
5x1=5
5
5 x 3 = 15
2
2x2=4
Identificatore “da”
visibile sul telefono
Callback2 eseguito
Invio di un
messaggio a più
numeri (almeno tre)
Messaggio ricevuto
da tutti e tre i
destinatari entro 10
secondi1
Callback2 eseguito
Invio di un
Messaggio
messaggio più lungo (composto di tutte le
di 160 (ma più
parti) ricevuto
breve di 320)
4
caratteri ad un
numero
Callback2 eseguito
Invio di un
messaggio
UNICODE ad un
numero
Messaggio ricevuto
correttamente
Controllo della
copertura routing
I numeri di telefono
esistenti (dal
database del CCR)
sono indicati come
abilitati
5
5x1=5
100
0
Callback2 eseguito
Note
1. Il CCR comprende che il tempo di consegna di un messaggio non è
completamente sotto il controllo dell’offerente, in quanto dipende anche dal
gestore locale della rete mobile. I criteri di successo hanno pertanto un lungo
tempo di consegna di 10 secondi. Il CCR eseguirà i test unicamente dopo aver
verificato che gli SMS, usando l’attuale provider, vengano consegnati entro 5
secondi e ripeterà i test 5 volte.
2. Il fornitore del servizio chiama un URL (da specificare dal CCR) con l’ID del
messaggio, stato del messaggio, identificatore “da” e timestamp come
parametri minimi. I logs del server web del CCR saranno usati per verificare
se il callback è stato eseguito.
3. I numeri dei destinatari per i test saranno scelti in uno dei paesi nei quali
l’offerente ha la copertura del servizio.
5. Volume stimato del contratto
Servizio SMS [SMS service]: 250000 messaggi all’anno.
5