Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

45
UNIVERSITÀ DEGLI STUDI DI TRIESTE DIPARTIMENTO DI INGEGNERIA ED ARCHITETTURA Tesi di laurea in RETI DI CALCOLATORI PREDIZIONE DI MALFUNZIONAMENTI IN RETI DI TELECOMUNICAZIONI CON TECNICHE DI MACHINE LEARNING Relatore: prof. Alberto Bartoli Correlatore: prof. Eric Medvet Laureando: Francesco Occhioni Anno accademico: 2015-2016

Transcript of Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

Page 1: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

UNIVERSITÀ DEGLI STUDI DI TRIESTE

DIPARTIMENTO DI INGEGNERIA ED ARCHITETTURA

Tesi di laurea in

RETI DI CALCOLATORI

PREDIZIONE DI MALFUNZIONAMENTI IN

RETI DI TELECOMUNICAZIONI CON

TECNICHE DI MACHINE LEARNING

Relatore: prof. Alberto Bartoli

Correlatore: prof. Eric Medvet

Laureando: Francesco Occhioni

Anno accademico: 2015-2016

Page 2: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

I

A Minerva

Page 3: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

II

Indice 1. Introduzione ..................................................................................................................................... 1

2. Presentazione delle richieste ............................................................................................................ 2

3. Analisi delle richieste ....................................................................................................................... 2

4. Strumenti necessari allo sviluppo del Progetto ................................................................................ 3

4.1. Hardware ................................................................................................................................... 3

4.1.1. PC Notebook MSI GE-62 .................................................................................................. 3

4.2. Software .................................................................................................................................... 4

4.2.1. Mongo DB.......................................................................................................................... 4

4.2.2. R Studio.............................................................................................................................. 4

4.2.3. Software Java ..................................................................................................................... 4

4.2.4. NetBeans ............................................................................................................................ 4

5. Stato Attuale ..................................................................................................................................... 5

5.1. Descrizione del CPE ................................................................................................................. 5

5.1.1. Ciclo di vita di un CPE ...................................................................................................... 5

5.2. Sistemi di monitoraggio ............................................................................................................ 6

5.2.1. HaWMo .............................................................................................................................. 7

5.2.1.1. LISTA KPI ...................................................................................................................... 8

5.2.2. SeQuMo ........................................................................................................................... 10

5.2.2.1. LISTA KPI .................................................................................................................... 10

5.2.3. CDSeQuMo ...................................................................................................................... 12

5.2.3.1. LISTA KPI .................................................................................................................... 12

5.3. Sistema di Ticketing ................................................................................................................ 14

5.3.1. Workflow di un Ticket ..................................................................................................... 14

5.3.2. Chi può aprire un Ticket................................................................................................... 14

5.3.3. Contenuto dei ticket ......................................................................................................... 15

5.3.4. Lavori Programmati ......................................................................................................... 15

6. Progettazione della macchina ad apprendimento automatico ........................................................ 16

6.1. Scelta del classificatore ........................................................................................................... 17

6.1.1. Random Forest ................................................................................................................. 17

6.1.2. Valutazioni delle prestazioni ............................................................................................ 18

6.1.3. Curva ROC ....................................................................................................................... 20

6.2. Costruzione del Dataset .......................................................................................................... 21

6.2.1. Riferimenti Temporali per il Dataset ................................................................................ 21

6.2.2. Creazione delle Feature .................................................................................................... 22

6.2.3. Scelta dei Ticket ............................................................................................................... 23

Page 4: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

III

6.2.3. Scelta dei Campioni ......................................................................................................... 23

6.2.4. Trattamento dei Missing Values ....................................................................................... 24

6.2.5. Trattamento dei dati sbilanciati ........................................................................................ 24

6.3. Prestazioni del classificatore ................................................................................................... 25

6.3.1. CDSeQuMo ...................................................................................................................... 25

6.3.1.1. True Positive Rate ......................................................................................................... 25

6.3.1.2. False Positive Rate ........................................................................................................ 26

6.3.1.3. True Positive Rate @1% ............................................................................................... 27

6.3.1.4. True Positive Rate @0,15% .......................................................................................... 28

6.3.2. SeQuMo ........................................................................................................................... 29

6.3.2.1. True Positive Rate ......................................................................................................... 29

6.3.2.2. False Positive Rate ........................................................................................................ 30

6.3.2.3. True Positive Rate @1% ............................................................................................... 31

6.3.2.4. True Positive Rate @0.15% .......................................................................................... 32

6.3.3. Valutazione delle prestazioni in ambito di applicazione reale. ........................................ 33

7. Conclusioni .................................................................................................................................... 34

Bibliografia ........................................................................................................................................ 35

Indice delle figure .............................................................................................................................. 35

Appendice A – Risultati Numerici ..................................................................................................... 36

A.1 CDSeQuMo ............................................................................................................................. 36

A.2 SeQuMo .................................................................................................................................. 39

Page 5: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

1

1. Introduzione La tesi descritta all’interno di questo documento andrà a trattare e sviluppare l’analisi

di tecniche di Machine Learning per predire possibili guasti e disservizi in Reti di

Telecomunicazioni.

Si tratta di un progetto sviluppato in collaborazione con Emaze S.p.a e un’importante

azienda di telecomunicazioni (il committente) e vuole fornire strumenti di supporto

alla proactive assurance per migliorare il servizio di customer care offerto dal

committente del progetto.

Il primo obiettivo posto per lo sviluppo è quello di analizzare la struttura dei sistemi

informativi preesistenti atti al monitoraggio e al controllo delle infrastrutture di rete

fissa. Si è reso pertanto necessario lo studio approfondito dei sistemi database

preesistenti, la loro organizzazione e le informazioni utili che potessero contribuire

allo sviluppo del progetto. Successivamente ci si è occupato della manipolazione

delle informazioni per progettare e realizzare il sistema ad apprendimento automatico

come strumento utile per rilevare disservizi o guasti di linea.

Lo sviluppo è stato realizzato interamente in locale, ma tenendo in considerazione la

possibilità di migrare il sistema su macchina remota in un secondo momento.

I capitoli della tesi sono così organizzati:

• 2) e 3) presentano le specifiche richieste dal committente e la relativa analisi

del progetto;

• 4) descrive l’hardware e software utilizzato;

• 5) analizza lo stato attuale dei sistemi informativi preesistenti;

• 6) analizza e progetta la macchina ad apprendimento automatico;

• 7) propone sviluppi futuri del lavoro creato.

Page 6: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

2

2. Presentazione delle richieste Il committente del progetto non ha presentato particolari richieste se non quelle di

uno sviluppo di uno studio di fattibilità riguardante la previsione dei guasti per

migliorare il servizio di proactive assurance e, di conseguenza, migliorare il grado di

soddisfazione della clientela nell’utilizzo dei servizi offerti. Il progetto descritto nel

presente elaborato di tesi è da considerare come un proof of concept per fornire una

valutazione oggettiva al committente riguardo l’applicazione di tecniche di machine

learning applicate al mondo delle telecomunicazioni.

Lo sviluppo del progetto dovrà inoltre occuparsi della sola clientela business in

quanto gode dei servizi aggiuntivi rispetto all’utenza non business quali il

monitoraggio dello stato della linea per ogni cliente.

3. Analisi delle richieste

Considerando lo sviluppo del progetto completamente libero, e non avendo richieste

specifiche da parte del committente, si è optato per realizzare una macchina ad

apprendimento automatico che possa prevedere apertura di ticket da parte della

clientela del committente. Un ticket, nel nostro caso specifico, rappresenta una

lamentela o un reclamo da parte della clientela in relazione ad un disservizio

sull’infrastruttura di rete fissa. Si è infatti ritenuto che la predizione di un ticket in

arrivo nel breve termine possa rappresentare un utile strumento di supporto ad un

reparto di customer relationship management per migliorarne il servizio offerto.

Il progetto, per la sua realizzazione, richiede uno studio approfondito di strutture dati

già sviluppate su motore Mongo DB.

Non meno importante sarà l’analisi delle informazioni fornite dal committente per

velocizzare lo sviluppo in quanto il sistema da realizzare dovrà potersi adattare

facilmente a una complessa infrastruttura già operativa.

Infine ci si occuperà dello studio degli algoritmi di machine learning più utili allo

scopo e di come manipolare i dati per ottenere una corretta previsione.

Ultimo passo del progetto sarà l’analisi dei risultati ottenuti sia per fornire al

committente eventuali sviluppi futuri sia per valutare altre applicazioni di tecniche di

machine learning relative al mondo delle telecomunicazioni.

Page 7: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

3

4. Strumenti necessari allo sviluppo del Progetto Il progetto necessita dell’utilizzo del seguente elenco di hardware e software.

Di seguito ne vengono descritte le caratteristiche.

4.1. Hardware

4.1.1. PC Notebook MSI GE-62 È il portatile a disposizione del laureando, montante un processore Intel core I7

octacore e 16 gigabyte di ram ddr3. Le prestazioni offerte dal calcolatore non sono

risultate per nulla superflue in quanto il progetto ha richiesto in prima battuta la

manipolazione di enormi quantità di dati (≈ 30 gigabyte) e, successivamente, una

buona potenza di calcolo a causa delle molteplici implementazioni relative

all’algoritmo di classificazione.

Page 8: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

4

4.2. Software

4.2.1. Mongo DB È il database management system che consente la creazione, manipolazione e

interrogazione dei database presenti nei sistemi informativi in uso da parte del

committente e sviluppati da Emaze. Verrà principalmente utilizzato per recuperare le

informazioni utili riguardo lo stato delle linee.

4.2.2. R Studio Ambiente di sviluppo basato su linguaggio R, un software statistico open source che

fornisce un insieme di macro e librerie utili per la gestione, l’analisi dei dati e la

produzione di grafici.

4.2.3. Software Java Java è un linguaggio di programmazione e una piattaforma di elaborazione sviluppati

da Sun Microsystems nel 1995. È un linguaggio orientato agli oggetti

specificatamente progettato per essere il più possibile indipendente dalla piattaforma

di utilizzo. Dal download del software Java si ottiene Java Runtime Environment

(JRE). JRE è composto dalla Macchina virtuale Java (JVM), dalle classi core della

piattaforma Java e dalle librerie Java di supporto.

4.2.4. NetBeans NetBeans è un ambiente di sviluppo integrato multi-linguaggio e multipiattaforma.

Nello specifico verrà utilizzato per la produzione di software applicativo in

linguaggio Java. La versione utilizzata è 8.1 rilasciata il 4 novembre 2015

Page 9: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

5

5. Stato Attuale Questo capitolo si concentrerà sullo studio dei sistemi informativi esistenti e già

integrati nell’infrastruttura del committente.

I sistemi informativi che costituiscono le principali fonti di dati per il progetto sono

due: il primo relativo all’acquisizione dei ticket, il secondo relativo all’acquisizione

dei key performance indicator (KPI), ovvero indicatori dello stato della linea per ogni

cliente. L’acquisizione dei ticket è gestita da un gruppo interno del committente,

mentre l’acquisizione dei KPI è invece affidata a tre sistemi di monitoraggio

sviluppati da Emaze S.p.a.

5.1. Descrizione del CPE Il Customer Premise Equipment (CPE) è il dispositivo elettronico assegnato ad ogni

cliente, che permette la connessione alla rete di comunicazione geografica (WAN) . I

principali attributi di un CPE sono vendor, modello e software version.

5.1.1. Ciclo di vita di un CPE E’ composto, in prima approssimazione, da tre macro stati:

1. Preattivo 2. Attivo (o “in produzione”) 3. Dismesso

Quando il CPE è in stato Preattivo, sono

presenti molte fasi interne relative a opzioni

di configurazione, collaudi e test di linea.

Una volta effettuati e verificati con successo

lo stato del CPE passa in Attivo e si avvia,

se previsto, il monitoraggio del CPE e dello

stato della linea.

Un CPE attivo può essere sostituito in caso di guasto o dismesso in caso di

risoluzione di contratto. Il cliente è effettivamente pagante solo quando il CPE è

attivo.

Figura 1: Workflow CPE

Page 10: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

6

Ogni CPE è univocamente identificabile dal suo link reference e per ogni link

reference esistono diversi tipi di linea:

• ADSL • SHDSL • CDN • FTTC_MAKE • FTTC_NGA_VULA • FTTH_GPON • PONTE_RADIO • MOBILE

e diversi tipi di servizi offerti:

• Voice-Data: linea VOCE e/o DATI - dedicata a piccoli uffici • DataC: DATI per Corporate Data - linee con infrastruttura più complessa • VoiceC-DataC: VOCE e DATI per Corporate Data - linee con infrastruttura più

complessa

5.2. Sistemi di monitoraggio Sono attualmente in produzione tre sistemi di monitoraggio:

• HaWMo (Hardware Monitor) • SeQuMo (Service Quality Monitor) • CDSeQuMo (Corporate Data Service Quality Monitor)

SeQuMo e CDSeQuMo si occupano di monitorare lo stato della linea dei CPE allo

scopo di misurare la qualità dei servizi voce e dati tramite acquisizione di

misurazioni di KPI effettuate dagli apparati, mentre HaWMo si occupa di monitorare

le performance hardware dei CPE attraverso dati diagnostici generati dai CPE stessi.

Allo stato attuale la numerosità dei CPE monitorati è la seguente:

#HaWMo = 9782 #SeQuMo = 28133 #CDSeQuMo = 6610

#(CDSeQuMo∩HaWMo)= 3495 #(SeQuMo∩HaWMo)= 6184 #(CDSeQuMo∩SeQuMo) = 0

Figura 2: Organizzazione

sistemi di monitoraggio

Page 11: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

7

In totale sono monitorati all’incirca 35000 CPE su una base totale di 40000. È bene

notare che il sistema di monitoraggio non sia statico, ma sia fortemente dinamico in

quanto giornalmente vengono aggiunti e dismessi nuovi CPE.

Vengono ora analizzati più in dettaglio le macchine di monitoraggio con i relativi

KPI.

Codici di Errore I tre sistemi di monitoraggio hanno in comune la stessa rappresentazione dei codici di errore:

• -1: errore generico durante l'esecuzione del test • -2: OID SNMP non configurato sul dispositivo • -3: timeout durante l'acquisizione • -4: dati non disponibili sul dispositivo • -5: formato dati ricevuti invalido • -6: differenza negativa • -7: calcolo non valido • -66: interfaccia down

5.2.1. HaWMo Il sistema è responsabile dell’acquisizione periodica dei KPI relativi allo stato

hardware dei CPE. Tale acquisizione avviene ad intervalli regolari di campionamento

di 15 minuti e viene mantenuto uno storico di 30 giorni (pari a 2880 campioni) per

CPE.

Prima di elencare i KPI acquisiti da HaWMo, è bene fare una precisazione sul

funzionamento del buffer di memoria di ogni CPE. La memoria di ogni CPE è

suddivisa staticamente in 6 pool, ognuno contenente un insieme di buffer di

dimensione fissa. Quando è necessario memorizzare un pacchetto e non ci sono

buffer disponibili, viene creato un nuovo buffer nel pool con dimensione minima

adeguata per il pacchetto (e viene incrementato il buffer miss counter). Quando tale

pool non ha più spazio disponibile, si usa il pool con buffer di dimensione

immediatamente superiore (e viene incrementato il buffer failure counter, vedi più

sotto). Se nessun pool ha un buffer disponibile, il pacchetto viene scartato.

Page 12: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

8

5.2.1.1. LISTA KPI

• Uso CPU ultimi 5 minuti (%) Rappresenta il valore percentuale di utilizzo della CPU (relativo a un periodo pari a 5

minuti) del dispositivo CPE.

• Uso memoria (%)

Rappresenta il valore percentuale di utilizzo della memoria del dispositivo CPE.

Note: I dispositivi VendorB non supportano l’acquisizione di questo KPI.

• Buffer failure

Rappresenta il numero di buffer failures negli ultimi 15 minuti.

I dispositivi VendorA e VendorB non supportano l’acquisizione di questo KPI

(quindi solo VendorB).

• Misses totali sui buffer Numero di buffer miss negli ultimi 15 minuti.

I dispositivi VendorA e VendorC non supportano l’acquisizione di questo KPI

(quindi solo dispositivi VendorB)

• Uptime

Rappresenta il l’intervallo di tempo trascorso dall’ultima accensione del CPE

• Lista delle Interfacce HaWMo raccoglie, per ogni CPE, la lista delle interfacce valide. Per ognuna di tali

interfacce vengono acquisiti anche i KPI relativi allo stato operativo e

all’occupazione di banda in ingresso ed uscita (vedi KPI successivi).

• Stato Operativo dell’Interfaccia (di rete)

Presente per ognuna delle interfacce valide, questo KPI rappresenta lo stato operativo

dell’interfaccia in questione. Valori possibili sono:

• up • down • testing • unknown • dormant • notPresent • lowerLayerDown

Page 13: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

9

• In - per Interfaccia Presente per ognuna delle interfacce valide, questo KPI rappresenta l’occupazione di

banda in ingresso relativa all’interfaccia in questione.

• Out - per Interfaccia

Presente per ognuna delle interfacce valide, questo KPI rappresenta l’occupazione di

banda in uscita relativa all’interfaccia in questione.

• Uptime - per Interfaccia

Presente solo nell’interfaccia cellular dati di un box 4G, rappresenta il l’intervallo di

tempo trascorso dall’ultima attivazione dell’interfaccia coinvolta.

• Raggiungibilità

Questo KPI è associato al CPE (non alla singola interfaccia). Non viene acquisito in

maniera diretta dai CPE, bensì calcolato indirettamente in base ai valori acquisiti per

gli altri KPI. Qualora durante l’acquisizione di uno o più KPI si verifichino situazioni

di timeout, la raggiungibilità viene determinata come KO. Qualora invece tutte le

acquisizioni siano andate a buon fine (ovvero sia stato possibile acquisire un valore

per ognuno degli altri KPI, sia esso un valido o meno) senza incorrere in alcun

timeout, la raggiungibilità viene determinata come OK.

Page 14: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

10

5.2.2. SeQuMo A intervalli periodici di 15 minuti, il sistema SeQuMo si preoccupa di interrogare

tramite protocollo SNMP tutti i dispositivi coinvolti per la raccolta dei risultati dei

test eseguiti dai singoli CPE.

Ogni CPE viene interrogato in relazione ai seguenti messaggi:

• request http; • query DNS; • ICMP echo;

Ogni PROBE (dispositivo dedicato ai test relativi la sola parte voce) verrà

interrogata in relazione al KPI MOS, mean opinion score, per tutti i CPE abilitati.

5.2.2.1. LISTA KPI

• MOS Le PROBE eseguono a intervalli regolari di 15 minuti i test di tipo Voce, simulando

una chiamata telefonica verso i CPE. Il valore del MOS (Mean Opinion Score) è una

misura della chiarezza di una trasmissione telefonica. Questa misurazione va da 0 a

5: 5 indica una qualità della voce eccellente, mentre 0 indica una qualità pessima.

Figura 3: Schema di funzionamento di SeQuMo

SeQuMo

Page 15: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

11

• Stato Linea Primaria Questo KPI viene derivato dal sistema SeQuMo dalla presenza degli altri KPI

acquisiti dal CPE e indica se la linea primaria è attiva.

• Http

Rappresenta il Round Trip Time (latenza) relativo all’acquisizione di una pagina web

via HTTP. Il CPE è configurato per l’esecuzione periodica dell’acquisizione di una

pagina HTTP, e il relativo RTT viene acquisito interrogando direttamente il CPE

sotto monitoraggio tramite l’uso del protocollo SNMP.

• Dns

Rappresenta il Round Trip Time (latenza) relativo alla risoluzione di un hostname

tramite interrogazione di un DNS server da parte del CPE. Questo test non è

supportato dai device VendorA. Per tali device viene sostituito dal test ICMP. Il CPE

deve essere configurato per l’esecuzione periodica della risoluzione di un hostname

sul DNS.

• Icmp Average e Icmp failure rate

Questo test viene usato in sostituzione al test DNS, in particolare a beneficio dei

device VendorA. Viene effettuato un ping continuo verso il server DNS; in base ai

risultati di tali ping il sistema ricava due KPI, uno relativo alla latenza (RTT) media

dei pacchetti ICMP, l’altro relativo alla percentuale di pacchetti persi nella

comunicazione fra il CPE e il server DNS. Vengono letti 30 valori, dei quali viene

fatta la media per estrarre la latenza in millisecondi e la valutazione del packet loss

percentuale.

• Reboot

Rappresenta il numero di reboot del device nell’intervallo di tempo considerato,

ovvero dall’acquisizione precedente.

• Ima Up

Rappresenta il numero di risalite di flussi IMA del device negli ultimi 15 minuti.

Ima (Inverse multiplexing over ATM) identifica una modalità di trasmissione nella

quale il flusso di dati viene suddiviso in pacchetti inviati sui collegamenti fisici

disponibili e ricomposti successivamente, una volta giunti a destinazione

Page 16: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

12

• Ima Down

Rappresenta il numero di cadute di flussi IMA del CPE nell’intervallo di tempo

considerato.

• Interface Up

Rappresenta il numero di risalita di portante del CPE nell’intervallo di tempo

considerato.

• Interface Down

Rappresenta il numero di cadute di portante del CPE nell’intervallo di tempo

considerato.

5.2.3. CDSeQuMo Il suo funzionamento è analogo a quello di SeQuMo, ma è dedicato solo per la

clientela Corporate. A differenza di SeQuMo monitora ulteriori KPI come utilizzo

banda in download/upload e parametri di QoS, ovvero parametri di qualità del

servizio fissati al momento del contratto. Tale acquisizione avviene ad intervalli

regolari di campionamento di 15 minuti.

5.2.3.1. LISTA KPI

• Raggiungibilità Questo KPI indica la raggiungibilità (in termini di packet loss) del CPE. Valori molto

bassi (idealmente 0%) sono indicativi di corretta raggiungibilità del dispositivo,

mentre valori molto alti (nel caso peggiore, 100%) sono indicativi di CPE spento o

non raggiungibile a causa di problematiche di rete.

CDSeQuMo effettua ping continui verso i CPE, secondo le seguenti modalità:

Ogni ping consiste di un messaggio ICMP, il quale viene dichiarato perso

dopo un’attesa di 3 secondi. Le sessioni di ping sono organizzate in slot

sequenziali di durata minima di 1 secondo:

– se l’esecuzione di uno slot richiede più di 1 secondo, il successivo

viene avviato appena il corrente finisce

– se l’esecuzione di uno slot termina in meno di 1 secondo, c’è un

periodo di attesa prima dell’esecuzione del successivo

Page 17: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

13

Durante ogni slot vengono contattati un massimo di 200 indirizzi ip, in

maniera sequenziale.

Viene comunque garantito che non vengano inviati pacchetti ICMP verso lo

stesso indirizzo IP con frequenza maggiore di 3 secondi.

– questo significa che qualora nel sistema siano registrati, per

esempio, meno di 200 indirizzi IP, la distanza minima fra l’invio di

pacchetti ICMP verso gli stessi CPE sarà di 3 secondi

Al termine di ogni ciclo di polling, ovvero ogni 15 minuti, per ogni CPE si effettua il

conteggio dei pacchetti ICMP inviati e ricevuti e si calcola la percentuale di packet

loss.

• Http

Analogo al test effettuato su SeQuMo.

• Dns Analogo al test effettuato su SeQuMo.

• Icmp Analogo al test effettuato su SeQuMo.

• Download rate Rappresenta il Download rate complessivo della banda dati del CPE, non

differenziato per classe di servizio, negli ultimi 15 minuti.

A partire dal numero di byte acquisiti durante l’acquisizione n-esima, e dal valore

raccolto durante l’acquisizione precedente [n-1], si ricava l’occupazione di banda in

kbps secondo la formula:

����[�] = (��� [�] − ��� [� − 1]) / 1024 ∗ 8 / � ����

• Upload rate Rappresenta l’Upload rate complessivo della banda dati del CPE, non differenziato

per classe di servizio, nell’arco degli ultimi 15 minuti.

A partire dal numero di byte acquisiti durante l’acquisizione n-esima, e dal valore

raccolto durante l’acquisizione precedente [n-1], si ricava l’occupazione di banda in

kbps secondo la formula:

����[�] = (��� [�] − ��� [� − 1]) / 1024 ∗ 8 / � ����

Page 18: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

14

5.3. Sistema di Ticketing

5.3.1. Workflow di un Ticket Nel momento in cui il cliente percepisce un disservizio sulla sua linea, chiama il

CRM (customer relationship management). Il CRM si suddivide internamente in due

gruppi: il 1° Livello (frontline) che gestisce tutte le chiamate in entrata della clientela

e il 2° Livello (backoffice) che si occupa di sistemare problemi più “blandi” in

quanto ha a disposizione strumenti di visibilità e di troubleshooting da remoto. In

media il CRM risolve il 60% delle chiamate, il resto si tramuta in apertura di un

ticket.

Nel caso in cui il CRM non abbia gli strumenti necessari per risolvere il problema

entra in gioco Assurance, il gruppo di gestione di ticket che, arrivati a questo punto

del workflow, vengono considerati Ticket Tecnici. Assurance suddivide il ticket in 2

tipologie:

• Work Order (ticket interno) • Terze Parti (ticket aperto a sua volta a operatori telefonici di terze parti)

e si occupa di identificare un gruppo interno per risoluzione del problema.

Una volta che il gruppo interno dichiara di aver terminato il troubleshooting, il ticket

ritorna ad Assurance che, o tramite un controllo diretto sul CPE o tramite una

telefonata al cliente (o delegando il controllo al CRM), verifica la risoluzione del

problema.

Se, al momento del contatto col cliente, si rileva che il problema persiste o non sia

stato sistemato viene riaperto un altro ticket, ex novo, non agganciato al precedente.

5.3.2. Chi può aprire un Ticket Gli enti e le persone fisiche che possono aprire un ticket sono:

• Cliente, in qualsiasi momento; chiamando il CRM. • PM (gestore dell’installazione e configurazione del CPE), nella fase di

preattivazione e nei primi 15 gg dell’attivazione; • Il sistema CDSeQuMo, in qualsiasi momento; automaticamente in caso di lettura di

PacketLoss = 100% nell’arco di 30 minuti. Questi ticket sono considerati automaticamente ticket tecnici

Page 19: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

15

5.3.3. Contenuto dei ticket Un singolo ticket contiene:

• Data di Apertura • Data di Chiusura • Link Reference : per identificare il CPE e la relativa linea • Tipologia Ticket • Status: disposizione del progetto solo ticket con status Answered (problema risolto)

e Closed (verificato col cliente) • Context: tipo di cliente e di gestione che deve avere (tempistiche, workflow di

lavorazione). • Tripletta: costituito dai campi Service MacroArea, Service Name e Trouble

Description. • Close_Code: campo compilato solo quando lo Status è Answered oppure Closed.

Rappresenta l'indicazione del problema rilevato una volta effettuato il troubleshooting e rappresenta quindi quanto di più vicino a una descrizione del problema. Non sempre infatti il ticket è indicatore di un degrado/disservizio, ma può anche accadere che venga aperto per effettuare modifiche sui servizi, sulle classi di servizio o modifiche di configurazione sul CPE.

5.3.4. Lavori Programmati Un’informazione utile fornita dal committente è quella relativa ai lavori

programmati, ovvero una lista di Link Reference che giornalmente sono sottoposti a

potenziali problemi di linea in termini di rilevazione dei KPI in quanto è in corso un

lavoro fisico, come ad esempio una sostituzione di cablaggi o riconfigurazioni di

Broadband Network Gateway, sull’infrastruttura di rete. Questo tipo di informazione

si è rilevata molto utile in termini di riduzione del rumore in quanto ticket aperti

durante lavori programmati non sono stati presi in considerazione.

Page 20: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

16

6. Progettazione della macchina ad apprendimento automatico Con il termine classificazione si intende l’operazione di assegnare degli oggetti

chiamate istanze ad alcune categorie predefinite chiamate classi: si tratta di un

problema diffuso che riguarda molte applicazioni diverse. Tra gli esempi che si

possono citare c’è l’identificazione delle email di spam sulla base dell’oggetto e del

contenuto, la categorizzazione delle cellule come benigne o maligne oppure la

classificazione delle galassie secondo la loro forma.

Tipicamente l’input per un problema di classificazione è rappresentato da un insieme

di dati chiamato training set, l’obiettivo è quello di creare una descrizione generale

che permetta di catalogare dati futuri non ancora visti. Ogni istanza appartenente a un

training set è composta da attributi che descrivono lo stato della istanza e una o più

label che descrive una o più classi di appartenenza per quella istanza. Gli attributi

(chiamati anche feature) sono solitamente di due tipi: nominali oppure numerici.

Formalmente si definisce classificatore il task di apprendere una funzione F che

mappa un insieme di feature A in una delle classi di C.

Le feature usate per lo sviluppo del progetto sono di tipo numerico e la numerosità

delle classi è pari a due (apertura del ticket e non apertura del ticket): lo sviluppo del

progetto verterà quindi sull’addestramento e valutazione delle prestazioni di un

classificatore binario.

Page 21: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

17

6.1. Scelta del classificatore Per lo sviluppo del progetto si è optato per l’algoritmo di classificazione chiamato

Random Forest.

6.1.1. Random Forest È basato su alberi decisionali. Un albero decisionale è un albero in cui ogni nodo

interno è associato un test su una delle feature e gli archi verso i figli sono etichettati

come i risultati distinti del test. Infine ogni foglia è associata a una classe che

permette così di creare una partizione del training set in classi distinte. Gli alberi

decisionali presentano diversi vantaggi tra cui:

• Facilità di interpretazione;

• Offrono una buona accuratezza generale;

• Robustezza al rumore;

Il classificatore Random Forest genera, durante la fase di addestramento, una foresta

di alberi decisionali. Al momento del test ogni albero genera la sua predizione

relativa a una stessa istanza e i risultati dei singoli test vengono aggregati, valutando

la classe di maggioranza e fornendo una classificazione per quella istanza. Si è optato

per un classificatore di tipo Random Forest in quanto è un tipo di classificazione

molto efficiente e resistente all’overfitting. Per overfitting si intende quando un

modello di classificazione si adatta eccessivamente ai dati osservati fornendo ottime

prestazioni sui dati di addestramento, mentre le prestazioni sui dati non visionati

saranno peggiori.

Page 22: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

18

6.1.2. Valutazioni delle prestazioni Per quanto riguarda le prestazioni del classificatore sono fornite dalla fase di

validazione. Infatti non è significativo studiare le prestazioni del classificatore sulle

istanze del training set dato che la funzione di classificazione è stata costruita su di

essa. Si effettua perciò la validazione su dati mai analizzati dal classificatore. Per

dimostrare la bontà del classificatore creato si effettuerà una validazione di tipo K-

fold (con K = 10) funzionante nel seguente modo:

1. Si suddivide il dataset in K sottoinsiemi disgiunti garantendo la stessa proporzione

delle classi; 2. Ad ogni passo (in totale ci sono K passi), la parte 1/K-esima del dataset viene

utilizzata come validation set, mentre la restante parte costituisce il training set.

In ogni passo si ricavano le prestazioni del classificatore confrontando i dati di

predizione del validation set con i dati reali.

È prassi infatti raccogliere i risultati di classificazione in una tabella chiamata

Confusion Matrix la quale fornisce delle metriche significative relative alla bontà

della classificazione. La rappresentazione di una Confusion Matrix relativa a un

problema di classificazione binario è la seguente:

Classe Reale + -

Classe Predetta + TP FP - FN TN

Dove:

• TP (True Positive): previsione positiva di istanza positiva

• FP (False Positive): previsione positiva di istanza negativa

• FN (False Negative): previsione negativa di istanza positiva

• TN (True Negative): previsione negativa di istanza negativa

Page 23: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

19

Le metriche significative di un problema di classificazione sono:

• TPR, True Positive Rate: rappresenta la frazione delle istanze positive classificate correttamente e può essere vista come la capacità del classificatore di identificare

istanze positive. Viene calcolato come: ��� = ���� !"

• FPR, False Positive Rate: rappresenta la frazione delle istanze negative classificate come positive e possono essere interpretate, nel nostro caso specifico come la

capacità di generare falsi allarmi. Viene calcolato come: #�� = !�!� �"

• FNR, False Negative Rate: rappresenta la frazione delle istanze positive classificate

come negative e viene calcolato come: #$� = !"�� !"

Page 24: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

20

6.1.3. Curva ROC ROC sta per Receiver Operating Characteristics ed è una tecnica utilizzata nei

classificatori binari per visualizzare i classificatori in base alle loro performance. È

una curva bidimensionale dove il True Positive Rate è lungo l’asse Y e il False

Positive Rate lungo l’asse X. La curva ROC permette di studiare i rapporti tra allarmi

veri e i falsi allarmi e si ottiene, una volta addestrato il classificatore, studiando

l’andamento delle coppie (TPR, FPR) nello spazio ROC al variare della threshold

(soglia di votazione fornita dagli alberi decisionali che di default è il 50%+1 ) del

classificatore Random Forest. Una volta ottenuti i punti nello spazio ROC è possibile

ottenere una curva tramite tecniche di interpolazione.

I punti significativi in una curva ROC sono i seguenti:

• (0,0): Rappresenta un classificatore la cui predizione risulta, indipendentemente dall’istanza valutata, sempre Negativa;

• (0,1): Rappresenta la classificazione perfetta, ovvero quanto il classificatore non produce falsi allarmi e riesce a predire tutte le istanze Positive;

• (1,1): Rappresenta un classificatore la cui predizione risulta, indipendentemente dall’istanza valutata, sempre Positiva.

La linea diagonale y = x rappresenta una strategia di classificazione random,

paragonabile cioè ad un lancio di una moneta per la predizione di eventi, mentre una

curva più è distante dalla diagonale e maggiore sarà la sua capacità di previsione.

Per comparare due classificatori attraverso la curva ROC viene introdotto il

Figura 4: Esempio di Curva ROC

Page 25: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

21

coefficiente AUC, Area Under Curve, che valuta l’area sottesa alla curva ROC:

maggiore è il coefficiente di AUC e maggiore sarà l’accuratezza del classificatore.

Infine le curve ROC vengono utilizzate anche in fase di ottimizzazione: possono

essere utili cioè per fissare un valore di cut-off per garantire valori di False Positive

Rate desiderati e studiare il classificatore in termini di True Positive Rate.

6.2. Costruzione del Dataset Viene ora descritta la procedura relativa alla costruzione del Dataset usata per

addestrare e validare il classificatore.

6.2.1. Riferimenti Temporali per il Dataset Poiché la tesi si propone di valutare la previsione di ticket in seguito a lettura dei

KPI, e non avendo indicazioni dal committente riguardanti la lunghezza della

previsione e il numero di previsioni da fare al giorno sono state fissate delle variabili

temporali per studiare dove si ottengono i migliori risultati e per valutare quale può

essere l’orizzonte di predizione utile per il committente.

Le variabili temporali fissate sono le seguenti:

• W (in ore): lunghezza della finestra temporale in cui si calcola una feature come aggregato delle letture di KPI (per quanto tempo raccolgo i dati);

• G (in ore): gap (quanto tempo prima ho a disposizione la predizione);

• H (in ore): lunghezza dell’orizzonte di predizione (per quanto tempo vale la predizione).

Se t è l’istante in cui genero una predizione, allora vengono raccolte osservazioni tra

t-W e t; all’istante t genero una predizione valida per l’intervallo tra t+G e t+G+H.

Figura 5: Finestre Temporali W, G e H

Page 26: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

22

Sono stati scelti diversi valori per le 3 variabili e combinati tra loro ottenendo così

Dataset diversi su cui si sono valutate le prestazioni:

• W=12 (h);

• H= 0.25, 1, 4, 8(h);

• G= da 0 a 24 (h) a intervalli di 1 ora.

6.2.2. Creazione delle Feature Per ogni KPI preso in considerazione sono state realizzate 5 feature attraverso cinque

distinte funzioni di aggregazione relative alla finestra temporale W. Le funzioni

utilizzate sono le seguenti:

• Massimo: max(()) = * ( | ( > () ∀ � = 1, … , � }

• Minimo: min(()) = * ( | ( < () ∀ � = 1, … , � }

• Media: med(()) = ∑ 7889 :�� � = 1, … , � }

• Conteggio degli errori: c_err(()) = ∑ >(())) :�� >(()) = ?1 � () = −30 AB���C ���

• Conteggio dei dati non disponibili: c_na(()) = D >(())

) :�� >(()) = ?1 � () ∈ *−1, −2, −4, −5, −6}

0 AB���C ���

I KPI considerati per lo sviluppo del progetto sono i seguenti: Per CDSeQuMo:

• Raggiungibilità (s)

• Packet Loss (pl, tx, rx)

• Download Rate (ib)

• Upload Rate (ob)

• Latenza http (h)

• Latenza dns ( d oppure icmp in base al tipo di Vendor)

Per SeQuMo: • Latenza http (h)

• Latenza dns ( d oppure icmp in base al tipo di Vendor)

• Reboot (dr)

• Interface Up (iu)

• Interface Down (id)

Mentre sono stati esclusi i seguenti KPI in quanto non sempre presenti su tutti i dispositivi:

• QOS (qos)

• MOS (m)

• Flussi Ima

Page 27: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

23

6.2.3. Scelta dei Ticket Per ridurre al minimo il rumore presente all’interno dei ticket si è effettuata una

selezione in quanto i ticket forniti dal committente erano relativi, oltre che a guasti e

disservizi sulla linea, anche a riconfigurazioni del dispositivo o a situazioni anomale

non predicibili in alcun modo dalla lettura dei KPI.

Sono stati pertanto filtrati così i ticket:

• rimossi i Ticket automatici del Portale di Monitoring

• rimossi i Ticket con CLOSE_CODE: No_Trouble_Found

• rimossi i Ticket aperti durante il periodo di lavori programmati

• tra i rimanenti, considerati solo i primi ticket aperti per ogni link reference

• tra i rimanenti, considerati solo quelli con una CLOSE_CODE che effettivamente indicasse un guasto o disservizio sulla linea

Ottenendo così un sottoinsieme significativo di ticket relativi a problemi di linea.

6.2.3. Scelta dei Campioni Per quanto riguarda la creazione dei campioni significativi per addestrare e validare

l’algoritmo di classificazione si è proceduto al seguente modo:

Sia LR l’insieme dei Link Reference:

1. Identifico l’insieme TT di ticket costruito come sopra; 2. Partiziono LA in due sottoinsiemi:

• LRsi contenente i link reference che hanno generato un ticket di TT;

• LRno contenente i link reference che non hanno generato nessun ticket di TT. 3. Costruisco il dataset D come unione di:

• Dsi, n1 istanze per ogni elemento di LRsi (n1=H*4);

• Dno, n2 (n2 = 3) istanze per ogni elemento di LRno ; n3 (n3=3) istanze per ogni elemento di LRsi; ogni istanza corrisponde ad una finestra W;

• nessuna finestra W contiene una apertura di ticket

Numero di Istanze SI = |LRsi |* H * 4 Numero di Istanze NO = 3*|LRsi | + 3*|LRno| = |LR|*3

Page 28: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

24

6.2.4. Trattamento dei Missing Values Quando si ha a che fare con dati provenienti dal mondo reale è impossibile non

imbattersi nel problema dei dati mancanti. Molto spesso i record presentano alcune

variabili per le quali non è noto il valore. In generale un numero di Missing Values

inferiore al 5% sul totale del dataset viene considerato solitamente gestibile, valori

dal 5% al 15% richiedono metodi ad hoc, mentre valori superiori al 15% sono

difficilmente gestibili. Per quanto riguarda lo sviluppo del progetto si è optato per

sostituire i valori mancanti con la media dei valori della feature su tutto il Dataset.

6.2.5. Trattamento dei dati sbilanciati Nel caso trattato ci si è trovati difronte alla creazione di Dataset sbilanciati, ovvero

Dataset in cui una classe è presente in numero molto maggiore rispetto ad un’altra.

Nel nostro caso specifico la classe relativa alle istanze NO ha il rapporto con la

classe delle istanze SI di 1000:1. Ovviamente lo sbilanciamento dei dati in questione

è intrinseco al problema stesso e non causato da una raccolta sbilanciata dei dati. La

soluzione proposta per ovviare allo sbilanciamento dei dati è quella di adottare un

approccio Cost-Sensitive ovvero associando, durante la fase di training, un diverso

costo dell’errore per classe; il costo è stato assegnato in modo da essere inversamente

proporzionale alla cardinalità della classe stessa assegnando pertanto un peso

maggiore alla classe di minoranza.

Page 29: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

25

6.3. Prestazioni del classificatore Vengono ora valutati i risultati forniti fornendo un approfondimento relativo alle

prestazione del classificatore creato in relazione ai parametri temporali G e H.

6.3.1. CDSeQuMo Relativamente al sistema CDSeQuMo si possono fare le seguenti considerazioni:

6.3.1.1. True Positive Rate Per quanto riguarda le prestazioni in termini di True Positive Rate si può notare come

i risultati migliori si ottengano all’aumentare della finestra di previsione H.

Per quanto riguarda la previsione con H pari a 15 minuti (0,25 ore) si segnala come

all’aumentare del Gap G ci sia un calo si prestazioni in termini di TPR passando da

un massimo di 0,8 a un minimo di 0,6 , mentre considerando una finestra di

previsione maggiore non c’è un calo significativo delle performance.

Figura 6: TPR per CDSeQuMo

CDSeQuMo

Page 30: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

26

6.3.1.2. False Positive Rate Nonostante l’aumentare di H porti dei miglioramenti in termini di TPR, la situazione

invece si ribalta nella valutazione dei False Positive Rate (o FPR). Come si evince

dal grafico sottostante il tasso dei falsi positivi aumenta, fino addirittura a triplicare

rispetto al caso migliore, all’aumentare della finestra di previsione H.

Nonostante siano valori molto bassi questi ultimi non vanno sottovalutati in relazione

al problema considerato: infatti considerando che l’apparato CDSeQuMo monitora

7000 dispositivi diversi e supponendo un numero di previsioni al giorno pari a 10 per

ogni linea, ciò comporta potenzialmente un numero di falsi positivi pari a 700 nel

caso migliore (H = 1) e 2100 nel caso peggiore (H=8).

A tal proposito si è scelto di valutare le prestazioni del classificatore agendo sulla

soglia del classificatore stesso per migliorare le prestazioni in termini di False

Positive Rate e analizzare come una variazione in tal senso modifica le prestazioni in

Figura 7: FPR per CDSeQuMo

CDSeQuMo

Page 31: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

27

termini di True Positive Rate. Sono stati pertanto fissati due indici di False Positive

Rate e letto il corrispettivo valore di True Positive per ogni curva ROC creata. Per

quanto riguarda gli indici fissati si è optato per un valore di False Positive pari a 0,01

e 0,0015 ottenendo rispettivamente gli indici TPR@1% e TPR@0,15%.

6.3.1.3. True Positive Rate @1% Analizzando il grafico è chiaro come impostando cut-off di FPR pari a 0,01 le

prestazioni non cambino in maniera significativa rispetto all’indice di TPR con una

soglia del classificatore di default.

Figura 8: TPR@1% per CDSeQuMo

CDSeQuMo

Page 32: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

28

6.3.1.4. True Positive Rate @0,15% Situazione ben diversa la si ha andando a impostare un cut-off sul FPR pari a 0,015.

Per quanto riguarda le previsioni con finestra temporale pari a 15 minuti le

performance in termini di TPR si aggirano sul 20% cioè si riuscirebbe a prevedere

solo un quinto dei ticket totali. D’altra parte per valori di H maggiori di un’ora si può

notare come le prestazioni calino, ma si assestino su valori molto buoni.

Considerando una finestra di previsione maggiore di un’ora e su un totale di 7000

linee e 10 misurazioni al giorno si ha, a fronte di 105 falsi positivi giornalieri, una

previsione dei ticket che si aggira al 75% rispetto alla totalità dei ticket.

Si ritiene pertanto che questi ultimi rappresentino dei risultati più interessanti per il

committente in quanto una diminuzione di un ordine di grandezza dei falsi positivi

comporta un calo delle prestazioni in termini di TPR in media del solo 20%.

Figura 9: TPR@0,15% per CDSeQuMo

CDSeQuMo

Page 33: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

29

6.3.2. SeQuMo Relativamente alla macchina SeQuMo si possono fare le seguenti considerazioni:

6.3.2.1. True Positive Rate

Analogamente al classificatore applicato alla macchina CDSeQuMo, per quanto

riguarda le prestazioni in termini di True Positive Rate si può apprezzare come i

risultati migliori si ottengano all’aumentare della finestra di previsione H.

Per quanto riguarda nello specifico la previsione con H pari a 15 minuti (0,25 ore) si

segnala come all’aumentare del Gap G ci sia un calo si prestazioni in termini di TPR

soprattutto dopo le 12 ore passando da un massimo di 0,8 a un minimo di 0,6 ,

mentre considerando una finestra di previsione maggiore non c’è un calo così

significativo delle performance.

Figura 10: TPR per SeQuMo

SeQuMo

Page 34: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

30

6.3.2.2. False Positive Rate Nonostante l’aumentare di H porti dei miglioramenti in termini di TPR, la situazione

invece si ribalta nella valutazione dei False Positive Rate (o FPR). Come si evince

dal grafico sottostante il valore relativo dei falsi positivi aumenta , fino addirittura a

triplicare rispetto al caso migliore, all’aumentare della finestra di previsione H.

Si può notare come il False Positive Rate sia di gran lunga più elevato rispetto al

False Positive Rate ottenuto con il classificatore relativo a CDSeQuMo. Tenendo in

considerazione che è stato applicato lo stesso processo per entrambe le

macchine di monitoraggio si può fare una considerazioni su come le feature (e

pertanto i relativi KPI ) di CDSeQuMo abbiano una maggior correlazione con

l’apertura dei ticket rispetto alle feature di SeQuMo.

Analogamente a quanto fatto per CDSeQuMo vengono ora valutate le prestazioni del

classificatore andando a fissare un valore di cut-off sul FPR per analizzarne il TPR.

Figura 11: FPR per SeQuMo

SeQuMo

Page 35: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

31

6.3.2.3. True Positive Rate @1% Impostando un cut-off sul FPR pari a 0,1 e indipendentemente dalla finestra di

previsione si può sostenere che il TPR cali all’aumentare del gap G e assuma

globalmente valori tra compresi tra il 50% e il 90%.

È da notare, e a tal proposito ci si propone di svolgere un’analisi più approfondita, un

andamento anomalo della curva per Gap compreso tra le 10 e le 20 ore. Questo

potrebbe essere sinonimo di una scelta errata dei campioni significativi oppure indice

di una certa stagionalità oraria nell’apertura dei ticket da parte della clientela del

committente.

Figura 12: TPR@1% per SeQuMo

SeQuMo

Page 36: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

32

6.3.2.4. True Positive Rate @0.15% Impostando un cut-off sul FPR pari a 0,015 e indipendentemente dalla finestra di

previsione si può sostenere che il TPR cali all’aumentare del gap G e assuma

globalmente valori tra compresi tra il 30% e il 70%.

In questo caso si sottolinea come si possano ottenere risultati con un True Positive

Rate pari al 60% solo per valori di gap molto bassi e inferiori alle 5 ore. D’altra

parte va considerato che SeQuMo monitora all’incirca 30000 dispositivi e,

supponendo un numero di previsioni pari a 10 per linea, si ottengono giornalmente

all’incirca 450 falsi positivi al giorno.

Figura 13: TPR@0,15% per SeQuMo

SeQuMo

Page 37: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

33

6.3.3. Valutazione delle prestazioni in ambito di applicazione reale. Vengono ora contestualizzati i risultati ottenuti fornendo un possibile scenario di

gestione dei ticket con il classificatore.

Supponiamo di voler fornire al CRM uno strumento di supporto durante l’orario

d’ufficio (9-17) relativamente alla possibile apertura di ticket da parte dell’utenza

CDSeQuMo. Viene suggerita pertanto questa strategia: fornire al CRM due

previsioni al giorno, una relativa alla mattina e una relativa al pomeriggio in modo

tale da allertare gli addetti ai lavori fornendo indicazioni sul possibile carico di

lavoro in arrivo e in modo da permettere una migliore gestione della forza lavoro in

termini di risorse umane nell’arco della giornata.

Lo specifico ambito applicativo richiede una finestra di previsione H pari a 4 ore e un

gap G di 1 ora per fornire al CRM il tempo necessario ad allocare le risorse. I dati

relativi a CDSeQuMo con H=4h e G=1h sono a tal proposito molto promettenti:

infatti in questo caso si ha una predizione dei ticket pari al 78% con un False Positive

Rate dello 0,15%. Contestualizzando le percentuali si può supporre che, a fronte di

100 ticket reali nell’arco della giornata, ne vengano predetti correttamente 78 e

vengano generati 18 falsi allarmi.

In alternativa è possibile fornire indicazioni utili coprendo l’intero della giornata

generando predizioni per 24 volte in un giorno (con H =1h) o per 3 volte in un giorno

(con H=8h). In entrambi i casi si possono prevedere ticket con una precisione del

75%, e un False Positive Rate dello 0,15%. È tuttavia da tenere in considerazione che

il numero di Falsi Positivi che genera la macchina è direttamente proporzionale al

numero di previsioni fatte, pertanto con 24 previsioni al giorno si generano

all’incirca 200 falsi positivi e con 3 previsioni al giorno se ne generano appena 27

pur mantenendo la stessa percentuale di previsione dei True Positive.

Page 38: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

34

7. Conclusioni Lo sviluppo del progetto commissionato è risultato di grosso interesse anche a livello

formativo. L’utilizzo di un software come R Studio mi ha dato la possibilità di

studiare e analizzare oltre che un nuovo tool, un nuovo linguaggio di manipolazione

e rappresentazione di dati.

Lo sviluppo del progetto è stato inizialmente lento a causa dello studio e dell’analisi

dei sistemi preesistenti, ma una volta compreso il sistema nel suo complesso si è

impiegato del tempo utile nella comprensione del linguaggio utilizzato e delle

rispettive librerie velocizzando l’intero sviluppo.

È curioso da segnalare come la libertà fornita dal committente si sia rivelata un’arma

a doppio taglio: non avendo chiari gli obbiettivi da sviluppare si è optato per un

problema che comprendesse il maggior numero di utenza monitorata senza entrare

troppo nel dettaglio delle linee e delle loro eventuali criticità.

Mi ritengo piuttosto soddisfatto della possibilità fornitami, poiché l’apprendimento di

un tool a me sconosciuto all’inizio del progetto, e la possibilità di toccare con mano

metodologie e tecniche di Machine Learning rappresentano una branca del computer

science che dovrebbero far parte del bagaglio culturale di ogni Ingegnere

Informatico.

Possibili sviluppi futuri del progetto sono:

• Presentazione delle prestazioni al committente;

• Inserimento in produzione del classificatore con taratura dello stesso e valutazione

delle performance nell’ambiente reale;

• Suddividere il classificatore in base a differenti tipologie di linee;

• Progettazione e sviluppo di un classificatore per la previsione di guasti di linea;

• Estensione del classificatore creato attraverso l’aggiunta di feature provenienti da

altri sistemi di monitoraggio.

Page 39: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

35

Bibliografia Phil Spector. Data Manipulation with R. Peter Dalgaard. Introductory Statistics with R Shai Shalev-Shwartz. Understanding Machine Learning: From Theory to Algorithms Jason Bell. Machine Learning: Hands-On for Developers and Technical

Professionals

J. Ross Quinlan. Induction of decision trees Peter Harrington. Machine Learning in Action

Documentazione JAVA · http://docs.oracle.com/javase/6/docs/api/

Documentazione R - http://www.r-project.org/

Indice delle figure

Figura 1: Workflow CPE…………………………………………………………………………………..…pag 5

Figura 2: Organizzazione Macchine di monitoraggio………………………………………….pag 6

Figura 3: Schema di funzionamento di SeQuMo…………………………………………….pag 10

Figura 4: Esempio di Curva ROC………………………………………………………………………pag 20

Figura 5: Finestre Temporali W, G e H……………………………………………………………..pag 21

Figura 6: TPR per CDSeQuMo………………………………………………………………………..pag 25

Figura 7: FPR per CDSeQuMo………………………………………………………………………..pag 26

Figura 8: TPR@1% per CDSeQuMo………………………………………………………………..pag 27

Figura 9: TPR@0,15% per CDSeQuMo……………………………………………………………pag 28

Figura 10: TPR per SeQuMo…………………………………………………………………………..pag 29

Figura 11: FPR per SeQuMo…………………………………………………………………………..pag 30

Figura 12: TPR@1% per SeQuMo…………………………………………………………………..pag 31

Figura 13: TPR@0,15% per SeQuMo……………………………………………………………..pag 32

Page 40: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

36

Appendice A – Risultati Numerici

A.1 CDSeQuMo

W G H FPR TPR ACC ACCPes AUC EER TPR015 TPR1%

12 0 0.25 0.0089 0.7960 0.9899 0.8935 0.9086 0.1467 0.3249 0.6258

12 1 0.25 0.0101 0.7163 0.9886 0.8531 0.8885 0.1749 0.2755 0.6085

12 2 0.25 0.0104 0.7128 0.9881 0.8512 0.8805 0.1841 0.1716 0.5361

12 3 0.25 0.0104 0.6707 0.9881 0.8301 0.8798 0.1878 0.1366 0.6219

12 4 0.25 0.0106 0.6081 0.9876 0.7988 0.8803 0.1893 0.2485 0.5371

12 5 0.25 0.0107 0.6998 0.9878 0.8445 0.8888 0.1650 0.1745 0.5829

12 6 0.25 0.0106 0.6388 0.9878 0.8141 0.8848 0.1779 0.2656 0.5611

12 7 0.25 0.0108 0.5544 0.9870 0.7718 0.8934 0.1603 0.2249 0.6052

12 8 0.25 0.0097 0.5987 0.9879 0.7945 0.8808 0.1835 0.1750 0.6043

12 9 0.25 0.0098 0.6124 0.9877 0.8013 0.8828 0.1822 0.2281 0.6416

12 10 0.25 0.0095 0.6345 0.9882 0.8125 0.8852 0.1767 0.1396 0.5885

12 11 0.25 0.0093 0.6277 0.9883 0.8092 0.8768 0.1875 0.3504 0.6260

12 12 0.25 0.0094 0.6161 0.9880 0.8033 0.8769 0.1857 0.1325 0.5907

12 13 0.25 0.0094 0.5915 0.9877 0.7910 0.8858 0.1756 0.1247 0.5293

12 14 0.25 0.0097 0.5772 0.9877 0.7838 0.8845 0.1748 0.2301 0.5830

12 15 0.25 0.0101 0.5189 0.9870 0.7544 0.8815 0.1769 0.1580 0.5550

12 16 0.25 0.0101 0.5025 0.9869 0.7462 0.8704 0.1915 0.1417 0.5875

12 17 0.25 0.0098 0.5477 0.9875 0.7689 0.8788 0.1821 0.1284 0.5271

12 18 0.25 0.0096 0.5849 0.9877 0.7877 0.8805 0.1795 0.1923 0.6137

12 19 0.25 0.0099 0.5676 0.9874 0.7788 0.8760 0.1890 0.1811 0.5834

12 20 0.25 0.0107 0.6098 0.9876 0.7996 0.8726 0.1915 0.1545 0.5402

12 21 0.25 0.0110 0.5328 0.9871 0.7609 0.8745 0.1887 0.1153 0.6296

12 22 0.25 0.0110 0.5321 0.9869 0.7605 0.8749 0.1861 0.1378 0.5507

12 23 0.25 0.0110 0.5519 0.9868 0.7704 0.8651 0.2068 0.1305 0.5451

12 24 0.25 0.0109 0.6465 0.9876 0.8178 0.8782 0.1886 0.1799 0.6452

12 0 1 0.0102 0.9085 0.9861 0.9492 0.9391 0.0957 0.7219 0.8752

12 1 1 0.0087 0.9290 0.9884 0.9602 0.9438 0.0888 0.8322 0.8776

12 2 1 0.0072 0.9222 0.9893 0.9575 0.9466 0.0814 0.7286 0.9113

12 3 1 0.0072 0.9129 0.9888 0.9529 0.9469 0.0811 0.7880 0.9116

12 4 1 0.0071 0.9081 0.9887 0.9505 0.9559 0.0731 0.8154 0.9140

12 5 1 0.0074 0.9240 0.9892 0.9583 0.9525 0.0737 0.8123 0.9015

12 6 1 0.0078 0.9112 0.9882 0.9517 0.9446 0.0885 0.7038 0.9045

12 7 1 0.0076 0.9129 0.9886 0.9526 0.9556 0.0719 0.7468 0.9068

12 8 1 0.0071 0.9080 0.9887 0.9504 0.9569 0.0668 0.7185 0.9134

12 9 1 0.0073 0.9003 0.9881 0.9465 0.9520 0.0823 0.7065 0.9166

12 10 1 0.0072 0.9095 0.9888 0.9511 0.9556 0.0706 0.7115 0.9034

12 11 1 0.0070 0.9023 0.9885 0.9476 0.9545 0.0726 0.7076 0.8905

Page 41: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

37

W G H FPR TPR ACC ACCPes AUC EER TPR015 TPR1%

12 12 1 0.0071 0.9064 0.9886 0.9496 0.9482 0.0857 0.7049 0.9167

12 13 1 0.0065 0.8996 0.9889 0.9466 0.9560 0.0740 0.6823 0.9124

12 14 1 0.0080 0.8978 0.9874 0.9449 0.9531 0.0750 0.7502 0.8897

12 15 1 0.0075 0.8991 0.9880 0.9458 0.9469 0.0852 0.6526 0.9173

12 16 1 0.0067 0.9060 0.9890 0.9496 0.9526 0.0750 0.6562 0.9152

12 17 1 0.0082 0.9017 0.9874 0.9467 0.9522 0.0776 0.6681 0.9005

12 18 1 0.0064 0.9016 0.9890 0.9476 0.9506 0.0771 0.6833 0.9297

12 19 1 0.0071 0.9104 0.9888 0.9517 0.9531 0.0740 0.7153 0.9118

12 20 1 0.0074 0.9083 0.9885 0.9505 0.9494 0.0786 0.7097 0.8846

12 21 1 0.0065 0.9005 0.9888 0.9470 0.9491 0.0773 0.7163 0.9117

12 22 1 0.0067 0.9057 0.9889 0.9495 0.9496 0.0751 0.7227 0.8898

12 23 1 0.0070 0.9089 0.9888 0.9509 0.9441 0.0843 0.6976 0.8928

12 24 1 0.0065 0.9060 0.9890 0.9497 0.9498 0.0744 0.7000 0.9125

12 0 4 0.0233 0.9660 0.9750 0.9714 0.9682 0.0555 0.8112 0.9035

12 1 4 0.0233 0.9715 0.9758 0.9741 0.9685 0.0513 0.8314 0.9052

12 2 4 0.0228 0.9708 0.9762 0.9740 0.9624 0.0681 0.8366 0.9044

12 3 4 0.0220 0.9694 0.9766 0.9737 0.9658 0.0655 0.8234 0.8855

12 4 4 0.0216 0.9684 0.9768 0.9734 0.9668 0.0615 0.8227 0.9011

12 5 4 0.0207 0.9692 0.9776 0.9742 0.9637 0.0673 0.8193 0.9170

12 6 4 0.0207 0.9678 0.9774 0.9735 0.9641 0.0695 0.8925 0.9118

12 7 4 0.0207 0.9697 0.9777 0.9745 0.9636 0.0697 0.8335 0.9209

12 8 4 0.0192 0.9651 0.9782 0.9730 0.9627 0.0698 0.7970 0.9307

12 9 4 0.0191 0.9651 0.9783 0.9730 0.9591 0.0703 0.7996 0.9130

12 10 4 0.0185 0.9667 0.9791 0.9741 0.9623 0.0687 0.8164 0.9325

12 11 4 0.0184 0.9642 0.9786 0.9729 0.9605 0.0697 0.8146 0.9215

12 12 4 0.0187 0.9676 0.9790 0.9745 0.9570 0.0704 0.7993 0.9148

12 13 4 0.0185 0.9681 0.9793 0.9748 0.9567 0.0672 0.8024 0.9193

12 14 4 0.0193 0.9678 0.9786 0.9743 0.9572 0.0688 0.7775 0.9160

12 15 4 0.0187 0.9683 0.9792 0.9748 0.9519 0.0779 0.8008 0.9230

12 16 4 0.0176 0.9692 0.9802 0.9758 0.9563 0.0673 0.7894 0.9182

12 17 4 0.0183 0.9693 0.9796 0.9755 0.9566 0.0689 0.7825 0.9233

12 18 4 0.0179 0.9686 0.9798 0.9754 0.9585 0.0751 0.8014 0.9177

12 19 4 0.0183 0.9684 0.9794 0.9751 0.9580 0.0698 0.8115 0.9224

12 20 4 0.0201 0.9683 0.9780 0.9741 0.9565 0.0708 0.8051 0.9259

12 21 4 0.0199 0.9679 0.9781 0.9740 0.9506 0.0769 0.8216 0.9143

12 22 4 0.0203 0.9679 0.9777 0.9738 0.9527 0.0753 0.7921 0.9243

12 23 4 0.0204 0.9690 0.9778 0.9743 0.9543 0.0766 0.7916 0.9247

12 24 4 0.0196 0.9702 0.9787 0.9753 0.9498 0.0796 0.8053 0.9234

12 0 8 0.0278 0.9594 0.9684 0.9658 0.9750 0.0453 0.8161 0.8941

12 1 8 0.0278 0.9604 0.9687 0.9663 0.9750 0.0446 0.7980 0.9021

12 2 8 0.0284 0.9607 0.9684 0.9661 0.9753 0.0484 0.8467 0.9015

12 3 8 0.0295 0.9606 0.9676 0.9655 0.9745 0.0474 0.8390 0.9080

Page 42: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

38

W G H FPR TPR ACC ACCPes AUC EER TPR015 TPR1%

12 4 8 0.0284 0.9592 0.9680 0.9654 0.9745 0.0452 0.8355 0.8987

12 5 8 0.0274 0.9605 0.9690 0.9665 0.9744 0.0480 0.8297 0.9078

12 6 8 0.0276 0.9615 0.9692 0.9669 0.9743 0.0471 0.8399 0.9078

12 7 8 0.0269 0.9592 0.9690 0.9662 0.9742 0.0451 0.8326 0.9130

12 8 8 0.0253 0.9614 0.9708 0.9681 0.9741 0.0485 0.8122 0.9084

12 9 8 0.0273 0.9609 0.9693 0.9668 0.9742 0.0486 0.8377 0.9168

12 10 8 0.0275 0.9636 0.9698 0.9680 0.9749 0.0454 0.8189 0.9191

12 11 8 0.0260 0.9652 0.9714 0.9696 0.9739 0.0490 0.8295 0.9220

12 12 8 0.0290 0.9655 0.9694 0.9682 0.9732 0.0501 0.8227 0.9150

12 13 8 0.0301 0.9731 0.9708 0.9715 0.9724 0.0483 0.8166 0.9219

12 14 8 0.0305 0.9685 0.9690 0.9690 0.9728 0.0503 0.7897 0.9262

12 15 8 0.0295 0.9656 0.9690 0.9680 0.9725 0.0560 0.8190 0.9161

12 16 8 0.0306 0.9710 0.9698 0.9702 0.9717 0.0501 0.7864 0.9193

12 17 8 0.0270 0.9638 0.9703 0.9684 0.9741 0.0500 0.7775 0.9265

12 18 8 0.0273 0.9650 0.9704 0.9688 0.9719 0.0523 0.8050 0.9238

12 19 8 0.0304 0.9684 0.9691 0.9690 0.9711 0.0512 0.8099 0.9241

12 20 8 0.0289 0.9607 0.9680 0.9659 0.9707 0.0512 0.8144 0.9119

12 21 8 0.0307 0.9663 0.9684 0.9678 0.9680 0.0588 0.8129 0.9185

12 22 8 0.0295 0.9626 0.9681 0.9665 0.9714 0.0534 0.8075 0.9166

12 23 8 0.0317 0.9699 0.9687 0.9691 0.9716 0.0518 0.7992 0.9250

12 24 8 0.0312 0.9693 0.9689 0.9691 0.9692 0.0615 0.8206 0.9203

Page 43: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

39

A.2 SeQuMo

W G H FPR TPR ACC ACCPes AUC EER TPR015 TPR1%

12 0 0.25 0.0044 0.8293 0.9926 0.9124 0.9720 0.0492 0.5862 0.9060

12 1 0.25 0.0061 0.8290 0.9913 0.9115 0.9585 0.0716 0.5327 0.8564

12 2 0.25 0.0071 0.8292 0.9904 0.9111 0.9480 0.0894 0.5157 0.8260

12 3 0.25 0.0077 0.8192 0.9898 0.9057 0.9407 0.1007 0.4273 0.8036

12 4 0.25 0.0088 0.7949 0.9885 0.8931 0.9333 0.1112 0.3973 0.7623

12 5 0.25 0.0090 0.7776 0.9881 0.8843 0.9311 0.1138 0.4156 0.7497

12 6 0.25 0.0090 0.7870 0.9883 0.8890 0.9244 0.1244 0.4003 0.7369

12 7 0.25 0.0093 0.7820 0.9880 0.8864 0.9255 0.1213 0.4057 0.7147

12 8 0.25 0.0094 0.7884 0.9882 0.8895 0.9346 0.1049 0.4290 0.7037

12 9 0.25 0.0090 0.8106 0.9889 0.9008 0.9487 0.0880 0.4225 0.6985

12 10 0.25 0.0092 0.8148 0.9887 0.9028 0.9474 0.0911 0.4077 0.6950

12 11 0.25 0.0097 0.8052 0.9882 0.8978 0.9405 0.1012 0.4465 0.6520

12 12 0.25 0.0108 0.7928 0.9871 0.8910 0.9262 0.1182 0.3425 0.6224

12 13 0.25 0.0130 0.7458 0.9850 0.8664 0.9032 0.1441 0.2491 0.5252

12 14 0.25 0.0140 0.7196 0.9840 0.8528 0.8880 0.1600 0.2010 0.4925

12 15 0.25 0.0154 0.6798 0.9829 0.8322 0.8713 0.1838 0.1512 0.4540

12 16 0.25 0.0161 0.6464 0.9823 0.8152 0.8606 0.1968 0.1637 0.4261

12 17 0.25 0.0159 0.6427 0.9823 0.8134 0.8484 0.2145 0.1355 0.4354

12 18 0.25 0.0155 0.6758 0.9827 0.8302 0.8397 0.2272 0.1721 0.4622

12 19 0.25 0.0151 0.6591 0.9827 0.8220 0.8392 0.2314 0.1639 0.4898

12 20 0.25 0.0141 0.6499 0.9830 0.8179 0.8542 0.2149 0.1816 0.5343

12 21 0.25 0.0136 0.6560 0.9834 0.8212 0.8910 0.1668 0.2029 0.5784

12 22 0.25 0.0130 0.6762 0.9840 0.8316 0.9340 0.1036 0.2024 0.6252

12 23 0.25 0.4600 0.6292 0.5707 0.5846 0.5968 0.4244 0.0020 0.0183

12 24 0.25 0.0127 0.6615 0.9839 0.8244 0.9437 0.0880 0.1929 0.6371

12 0 1 0.0108 0.9372 0.9857 0.9632 0.9954 0.0231 0.6326 0.9207

12 1 1 0.0126 0.9351 0.9840 0.9612 0.9941 0.0300 0.6262 0.8789

12 2 1 0.0131 0.9289 0.9831 0.9579 0.9924 0.0352 0.5743 0.8596

12 3 1 0.0140 0.9133 0.9812 0.9496 0.9875 0.0420 0.5487 0.8416

12 4 1 0.0157 0.8912 0.9781 0.9377 0.9853 0.0485 0.6042 0.8200

12 5 1 0.0155 0.8901 0.9783 0.9373 0.9861 0.0499 0.6102 0.8136

12 6 1 0.0165 0.8906 0.9775 0.9371 0.9862 0.0493 0.5791 0.8000

12 7 1 0.0180 0.8970 0.9768 0.9395 0.9847 0.0513 0.5407 0.7833

12 8 1 0.0202 0.9037 0.9755 0.9418 0.9875 0.0472 0.5274 0.7629

12 9 1 0.0225 0.9150 0.9742 0.9463 0.9895 0.0436 0.4944 0.7756

12 10 1 0.0245 0.9134 0.9723 0.9445 0.9894 0.0443 0.4912 0.7657

12 11 1 0.0268 0.9138 0.9702 0.9435 0.9891 0.0450 0.4533 0.7467

12 12 1 0.0310 0.8981 0.9656 0.9335 0.9845 0.0552 0.3512 0.6671

12 13 1 0.0366 0.8849 0.9601 0.9241 0.9796 0.0633 0.2153 0.6005

12 14 1 0.0389 0.8770 0.9578 0.9191 0.9793 0.0649 0.1689 0.5651

Page 44: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

40

W G H FPR TPR ACC ACCPes AUC EER TPR015 TPR1%

12 15 1 0.0414 0.8614 0.9550 0.9100 0.9750 0.0697 0.1892 0.5130

12 16 1 0.0431 0.8631 0.9536 0.9100 0.9673 0.0801 0.2026 0.4837

12 17 1 0.0421 0.8746 0.9548 0.9163 0.9664 0.0819 0.2177 0.5015

12 18 1 0.0411 0.8761 0.9556 0.9175 0.9670 0.0814 0.2005 0.5324

12 19 1 0.0389 0.8791 0.9577 0.9201 0.9600 0.0855 0.2061 0.5548

12 20 1 0.0365 0.8761 0.9597 0.9198 0.9722 0.0680 0.1924 0.5893

12 21 1 0.0347 0.8733 0.9611 0.9193 0.9814 0.0543 0.2457 0.6436

12 22 1 0.0293 0.8661 0.9651 0.9184 0.9870 0.0457 0.2591 0.7007

12 23 1 0.0000 0.8141 0.8146 0.9070 0.8045 0.2351 0.0026 0.0173

12 24 1 0.0277 0.8631 0.9663 0.9177 0.9876 0.0438 0.2756 0.7097

12 0 4 0.0342 0.9698 0.9667 0.9678 0.9957 0.0327 0.6959 0.9011

12 1 4 0.0435 0.9693 0.9592 0.9629 0.9931 0.0436 0.6802 0.8682

12 2 4 0.0484 0.9556 0.9525 0.9536 0.9891 0.0504 0.6737 0.8261

12 3 4 0.0531 0.9491 0.9474 0.9480 0.9843 0.0598 0.6242 0.7710

12 4 4 0.0576 0.9477 0.9434 0.9450 0.9818 0.0676 0.6171 0.7644

12 5 4 0.0625 0.9480 0.9396 0.9428 0.9834 0.0677 0.5890 0.7639

12 6 4 0.0683 0.9513 0.9355 0.9415 0.9845 0.0612 0.5928 0.7562

12 7 4 0.0745 0.9552 0.9309 0.9403 0.9861 0.0567 0.5568 0.7362

12 8 4 0.0792 0.9593 0.9276 0.9401 0.9868 0.0570 0.5236 0.7295

12 9 4 0.0804 0.9592 0.9266 0.9394 0.9868 0.0587 0.4926 0.7272

12 10 4 0.0873 0.9562 0.9201 0.9344 0.9853 0.0630 0.4257 0.6961

12 11 4 0.0899 0.9511 0.9171 0.9306 0.9833 0.0668 0.3630 0.6694

12 12 4 0.1037 0.9455 0.9042 0.9209 0.9800 0.0739 0.3118 0.6147

12 13 4 0.1164 0.9407 0.8920 0.9122 0.9756 0.0822 0.2545 0.5655

12 14 4 0.1265 0.9377 0.8823 0.9056 0.9696 0.0938 0.2641 0.5270

12 15 4 0.1330 0.9347 0.8759 0.9009 0.9633 0.1022 0.2706 0.5052

12 16 4 0.1320 0.9430 0.8780 0.9055 0.9614 0.1052 0.3203 0.5235

12 17 4 0.1305 0.9479 0.8801 0.9087 0.9600 0.1086 0.2905 0.5371

12 18 4 0.1261 0.9540 0.8851 0.9140 0.9604 0.1075 0.3125 0.5631

12 19 4 0.1177 0.9555 0.8931 0.9189 0.9620 0.1076 0.3173 0.5962

12 20 4 0.1048 0.9492 0.9040 0.9222 0.9697 0.1003 0.3248 0.6319

12 21 4 0.0856 0.9409 0.9193 0.9277 0.9756 0.0948 0.3667 0.6767

12 22 4 0.0599 0.9324 0.9385 0.9362 0.9832 0.0767 0.3841 0.7369

12 23 4 0.0599 0.9455 0.9455 0.9362 0.8624 0.1974 0.0061 0.0408

12 24 4 0.0596 0.9308 0.9384 0.9356 0.9832 0.0767 0.4032 0.7289

12 0 8 0.0692 0.9771 0.9470 0.9539 0.9903 0.0523 0.6574 0.8662

12 1 8 0.0926 0.9718 0.9290 0.9396 0.9809 0.0711 0.6352 0.7896

12 2 8 0.1079 0.9668 0.9162 0.9294 0.9743 0.0817 0.6063 0.7340

12 3 8 0.1203 0.9648 0.9063 0.9223 0.9720 0.0891 0.5750 0.7081

12 4 8 0.1301 0.9649 0.8987 0.9174 0.9737 0.0910 0.5541 0.7172

12 5 8 0.1348 0.9649 0.8950 0.9151 0.9764 0.0859 0.5158 0.7061

12 6 8 0.1374 0.9644 0.8928 0.9135 0.9768 0.0842 0.5172 0.6873

Page 45: Predizione di malfunzionamenti in reti di telecomunicazioni con tecniche di machine learning

41

W G H FPR TPR ACC ACCPes AUC EER TPR015 TPR1%

12 7 8 0.1370 0.9625 0.8926 0.9128 0.9767 0.0850 0.4604 0.6755

12 8 8 0.1266 0.9539 0.8982 0.9136 0.9760 0.0865 0.4009 0.6676

12 9 8 0.1143 0.9400 0.9033 0.9128 0.9745 0.0894 0.4089 0.6526

12 10 8 0.1021 0.9155 0.9040 0.9067 0.9717 0.0947 0.3614 0.6399

12 11 8 0.0984 0.8983 0.9005 0.9000 0.9685 0.1023 0.3277 0.6183

12 12 8 0.1122 0.8954 0.8904 0.8916 0.9629 0.1131 0.3152 0.5881

12 13 8 0.1392 0.9140 0.8778 0.8874 0.9587 0.1185 0.2894 0.5600

12 14 8 0.1637 0.9225 0.8616 0.8794 0.9528 0.1276 0.2935 0.5188

12 15 8 0.1826 0.9223 0.8464 0.8699 0.9478 0.1405 0.3267 0.5386

12 16 8 0.1837 0.9068 0.8419 0.8616 0.9431 0.1462 0.3929 0.5448

12 17 8 0.1793 0.9044 0.8449 0.8626 0.9437 0.1495 0.3701 0.5496

12 18 8 0.1697 0.9076 0.8533 0.8690 0.9467 0.1511 0.3668 0.5765

12 19 8 0.1548 0.9088 0.8649 0.8770 0.9512 0.1486 0.3600 0.6076

12 20 8 0.1331 0.9030 0.8789 0.8850 0.9584 0.1358 0.3804 0.6359

12 21 8 0.1157 0.9130 0.8941 0.8986 0.9665 0.1162 0.3994 0.6666

12 22 8 0.0859 0.9358 0.9218 0.9249 0.9781 0.0910 0.4063 0.7091

12 23 8 0.0859 0.9719 0.9719 0.9249 0.8542 0.2054 0.0058 0.0387

12 24 8 0.1024 0.9238 0.9067 0.9107 0.9703 0.1039 0.3741 0.6700