C APITOLO 4: A PPLICAZIONE DELL ’ ALGORITMO SW-CLT AL TRAFFICO DI RETE RADIOMOBILE

63

C ^APITOLO 4: A PPLICAZIONE DELL ’ ^ALGORITMO SW-CLT AL TRAFFICO DI RETE RADIOMOBILE

Dopo aver affrontato analiticamente la trattazione dell’algoritmo SW-CLT nel capitolo precedente, in questo IV ed ultimo capitolo l’algoritmo viene applicato alle tracce di traffico (per cella) estratte dai dataset di cui al paragrafo 1.3.1 a pagina 10. Si ricorda che, a differenza delle tracce utilizzate nell’analisi temporale del paragrafo 2.2, quelle utilizzate ora si riferiscono, per una data cella, al traffico generato da tutti i CC senza distinzione alcuna: in sintesi si tratta del traffico complessivo della cella, con la stessa risoluzione temporale offerta nativamente dai dataset (time-slot da 10 minuti) e relativo, come al solito, al solo mese di Dicembre 2013. Le tracce consistono in serie temporali di 4464 campioni poiché per ogni ora si considerano 6 time-slot da 10 minuti i quali, moltiplicati per 24 ore giornaliere e 31 giorni del mese originano, per l’appunto, 4464 campioni (6 × 24 × 31 = 4464).

Le tracce sono state memorizzate per cella, all’interno di una matrice di traffico TR di dimensione 10^4 × 4464.

4.1 I POTESI DI LAVORO

Nell’applicare l’algoritmo alle tracce di traffico “reali” estratte dai dataset, devono esser necessariamente fatte delle ipotesi di lavoro al fine di interpretare al meglio i risultati finali proposti da tale elaborazione.

4.1.1 S CELTA DEI PARAMETRI

Innanzitutto, per come è stato implementato lo SW-CLT, esso riceve in ingresso la serie temporale da analizzare, la Probabilità di falso allarme a Priori ϵ e la lunghezza m di una delle due finestre adiacenti.

La prima ipotesi è stata quella di scegliere valori di m piccoli per ottenere le migliori

prestazioni possibili come suggerito dalle tabelle prestazionali del paragrafo 3.2.3 a pagina

53. Nello specifico si è scelto di applicare l’algoritmo con m = 3 in modo tale da far lavorare

sulla serie temporale due finestre adiacenti che coprono complessivamente 6 campioni

corrispondenti a 6 time-slot da 10 minuti ovvero ad un’ora. Così facendo si vogliono

individuare le anomalie di traffico di breve durata.

64

La Probabilità di Falso Allarme a Priori è stata scelta pari a 10^-4, scegliendo come ordine di grandezza il reciproco del numero di campioni delle serie da analizzare, pari a 4464

. Valori più bassi avrebbero diminuito la numerosità dei falsi allarmi sperimentati, rendendo però inconsistenti i risultati ottenuti avendo a disposizione solo 4464 campioni.

4.1.2 F ILTRAGGIO DEGLI ALLARMI

L’algoritmo implementato, dati in ingresso i parametri m e ϵ , restituisce le posizioni temporali dei fronti in salita e discesa individuati. Per ipotesi, un allarme sulla serie temporale reale inizia con un fronte in salita e termina con il corrispettivo fronte in discesa.

Da prove sperimentali su tracce campione analizzate, è emerso un certo numero di situazioni inconsistenti che sono state filtrate secondo la strategia sequenziale riportata di seguito:

1 Se non sono presenti fronti in salita, si ipotizza che l’algoritmo, con i parametri usati, non abbia individuato alcun allarme (per reale assenza di allarmi o per fallimento dell’algoritmo stesso);

2 Se il passo 1 non è verificato, dunque esistono fronti in salita rilevati.

Ad ogni fronte in salita viene associato uno ed un solo fronte in discesa. L’allarme finale è quindi quello tra ogni fronte in salita ed il suo corrispettivo fronte in discesa, per la durata pari alla distanza temporale T tra le due entità. Sempre da prove sperimentali, è emersa l’eventualità di fronti in salita e discesa molto distanti tra loro: si è scelto, quindi di limitare la durata di un allarme a 𝑻𝑻 _{𝒎𝒎𝒎𝒎𝒎𝒎} = 𝟕𝟕𝟕𝟕 campioni (numero di time-slot presenti in mezza giornata) considerando allarmi 𝑻𝑻 ≥ 𝑻𝑻 _{𝒎𝒎𝒎𝒎𝒎𝒎} come falsi allarmi (si ipotizza cioè che un allarme di durata maggiore di 72 time-slot è eccessivamente lungo per essere considerato valido). Detto ciò si possono distinguere 3 casi:

2.1 Tra due fronti in salita consecutivi 𝑼𝑼𝑼𝑼 _𝟏𝟏 e 𝑼𝑼𝑼𝑼 _𝟕𝟕 non esiste alcun fronte in discesa:

𝑼𝑼𝑼𝑼 _𝟏𝟏 è quindi “orfano” del proprio fronte in discesa, è quindi da considerarsi inconsistente e viene scartato;

2.2 Tra due fronti in salita consecutivi 𝑼𝑼𝑼𝑼 _𝟏𝟏 e 𝑼𝑼𝑼𝑼 _𝟕𝟕 (rispettivamente agli istanti 𝒕𝒕 _{𝒖𝒖𝒖𝒖𝟏𝟏} e 𝒕𝒕 _{𝒖𝒖𝒖𝒖𝟕𝟕} ) esiste un solo fronte in discesa 𝑫𝑫𝑫𝑫𝑫𝑫𝑫𝑫 _𝟏𝟏 (istante 𝒕𝒕 _{𝒅𝒅𝒅𝒅𝒅𝒅𝒅𝒅𝟏𝟏} ): l’allarme reale è quindi quello tra 𝑼𝑼𝑼𝑼 _𝟏𝟏 e 𝑫𝑫𝑫𝑫𝑫𝑫𝑫𝑫 _𝟏𝟏 a condizione che 𝒕𝒕 _{𝒅𝒅𝒅𝒅𝒅𝒅𝒅𝒅𝟏𝟏} − 𝒕𝒕 _{𝒖𝒖𝒖𝒖𝟏𝟏} < 𝑻𝑻 _{𝒎𝒎𝒎𝒎𝒎𝒎} . Se la

6

₄₄₆₄ ¹ = 2.2 × 10 ⁻⁴

65 condizione su 𝑻𝑻 𝒎𝒎𝒎𝒎𝒎𝒎 non è soddisfatta si considera la coppia 𝑼𝑼𝑼𝑼 𝟏𝟏 e 𝑫𝑫𝑫𝑫𝑫𝑫𝑫𝑫 𝟏𝟏 come un caso da scartare, spostando l’analisi al fronte in salita successivo;

2.3 Tra due fronti in salita consecutivi 𝑼𝑼𝑼𝑼 _𝟏𝟏 e 𝑼𝑼𝑼𝑼 _𝟕𝟕 (rispettivamente agli istanti 𝒕𝒕 _{𝒖𝒖𝒖𝒖𝟏𝟏} e 𝒕𝒕 _{𝒖𝒖𝒖𝒖𝟕𝟕} ) esistono più fronti in discesa consecutivi 𝑫𝑫𝑫𝑫𝑫𝑫𝑫𝑫 𝟏𝟏 … . . 𝑫𝑫𝑫𝑫𝑫𝑫𝑫𝑫 _𝑫𝑫 (istanti 𝒕𝒕 𝒅𝒅𝒅𝒅𝒅𝒅𝒅𝒅𝟏𝟏 … . . 𝒕𝒕 𝒅𝒅𝒅𝒅𝒅𝒅𝒅𝒅𝑫𝑫 ): gli N-1 fronti in discesa 𝑫𝑫𝑫𝑫𝑫𝑫𝑫𝑫 𝟕𝟕 … . . 𝑫𝑫𝑫𝑫𝑫𝑫𝑫𝑫 𝑫𝑫 vengono scartati poiché inconsistenti e l’allarme reale è quindi quello tra 𝑼𝑼𝑼𝑼 𝟏𝟏 e 𝑫𝑫𝑫𝑫𝑫𝑫𝑫𝑫 𝟏𝟏

a condizione che 𝒕𝒕 𝒅𝒅𝒅𝒅𝒅𝒅𝒅𝒅𝟏𝟏 − 𝒕𝒕 𝒖𝒖𝒖𝒖𝟏𝟏 < 𝑻𝑻 𝒎𝒎𝒎𝒎𝒎𝒎 . Se la condizione su 𝑻𝑻 𝒎𝒎𝒎𝒎𝒎𝒎 non è soddisfatta si considera la coppia 𝑼𝑼𝑼𝑼 _𝟏𝟏 e 𝑫𝑫𝑫𝑫𝑫𝑫𝑫𝑫 _𝟏𝟏 come un caso da scartare, spostando l’analisi al fronte in salita successivo;

4.2 M ATRICE DEGLI ALLARMI

Applicando la strategia di filtraggio del 4.1.2 per ogni traccia analizzata è stato possibile estrarre una sequenza coerente di fronti in salita e corrispettivi fronti in discesa in determinate posizioni temporali. Da tale sequenza è stata generata un’ulteriore sequenza a 2 livelli (0 e 1) sempre pari a 0 eccetto che per le durate 𝑻𝑻 _𝒊𝒊 dei vari allarmi rilevati (dove la sequenza vale 1). Le 10^4 sequenze così generate (una per ogni cella) sono state memorizzate in una matrice degli allarmi MA di dimensioni 10^4 × 4464. Una delle possibili rappresentazioni di una matrice offerte da Matlab® è quella ottenuta attraverso il comando imagesc(·) e la relativa mappa colore colormap(·). La matrice degli allarmi ottenuta con i parametri m = 3 e ϵ = 10^-4 è rappresentata in Figura 51.

Figura 51: matrice degli allarmi con parametri m = 3 e ϵ ^{= 10^-4}

66

Ad eccezione di una certa regolarità complessiva che si percepisce visivamente durante i giorni feriali del mese di Dicembre 2013 e per il giorno 25 dello stesso mese, com’era prevedibile immaginare, data l’alta risoluzione spazio-tempo della matrice MA, una valutazione delle informazioni in essa contenute non è possibile in base alla sua intera rappresentazione di Figura 51. Si è scelto quindi di soffermarsi su alcune sue porzioni, di particolare interesse per la valutazione degli allarmi generati dall’applicazione dello SW- CLT.

4.2.1 Z ONA S TADIO G. M EAZZA IN S AN S IRO

Ricorrendo al tool di ricerca geografica per cella disponibile sul portale dandelion.eu e di cui si è accennato nel paragrafo 1.3.2 a pagina 15, è stato possibile indentificare la cella 5738 come quella centrata esattamente sullo stadio Giuseppe Meazza di Milano (riferimento geografico in Figura 52).

Figura 52: individuazione cella 5738 attraverso il tool online del portale dandelion.eu

Partendo dalla cella 5738 e spostandosi in un suo intorno nelle direzioni nord, sud, est ed

ovest, è stata estratta la porzione della matrice MA relativa alle celle 5638, 5737, 5738, 5739

e 5838 (d’ora in poi complessivamente indicate come ZONA_1). Il risultato è quello di

Figura 53.

67

Figura 53: matrice degli allarmi con parametri m = 3 e ϵ = 10^-4 – zoom sulla ZONA_1

Considerando come cella di riferimento la 5738, si nota subito che gli allarmi comuni fra le cinque celle sono esattamente localizzati nelle ultime ore dei giorni 4, 8, 11, 16 e 22 Dicembre 2013. Dopo una breve ricerca, si è scoperto che le date riportate corrispondono esattamente alle partite di calcio:

• Inter – Trapani (TIM CUP, ore 20:45 del 04/12/2013);

• Inter – Parma (Campionato Serie A Tim, ore 20:45 del 08/12/2013);

• Milan – Ajax (Champions League, ore 20:45 del 11/12/2013);

• Milan – Roma (Campionato Serie A Tim, ore 20:45 del 16/12/2013);

• Inter – Milan (Campionato Serie A Tim, ore 20:45 del 22/12/2013);

Si notano anche altri allarmi, non a comune con la cella 5738 e/o con altre celle, sintomo probabilmente di altra attività non inerente agli eventi appena elencati e di cui non è stata individuata alcuna informazione.

Per completezza nel report dei risultati appena descritti, si riportano in Figura 54 gli allarmi

temporali riferiti ad ogni singola cella della zona appena analizzata, con riferimento

all’evoluzione temporale del traffico delle celle stesse. Il tratto in nero rappresenta il traffico

di un determinata cella, il tratto in rosso è l’evoluzione degli allarmi rilevati (sequenza

binaria già discussa a pagina 65). Si noti che per compensare i livelli di traffico molto diversi

fra le cinque celle, tutti i grafici hanno la stessa scala sull’asse delle ordinate (quantità di

traffico), portando inevitabilmente al troncamento fuori scala dei picchi istantanei più alti

per le celle maggiormente attive.

68

Figura 54: andamento del traffico nelle celle della ZONA_1 e relativi allarmi rilevati (tratto rosso)

I grafici di Figura 54 mettono in evidenza come nonostante i diversi ordini di grandezza del traffico medio di ogni singola cella, l’algoritmo, a meno di falsi allarmi e mancati avvistamenti, individua degli allarmi consistenti per la singola cella 5738 e coerenti con quelli delle celle adiacenti.

4.2.2 Z ^ONA M ^EDIOLANUM F ^{ORUM DI} A ^SSAGO

Iterando lo stesso tipo di indagine già fatta per la ZONA_1, è stata valutata anche la risposta dell’algoritmo nella zona del Mediolanum Forum di Assago (Figura 55).

Figura 55: individuazione cella 2144 attraverso il tool online del portale dandelion.eu

69 Individuata la cella di pertinenza, ovvero la 2144, ed estendendo l’indagine al suo intorno nelle direzioni nord, sud, est ed ovest, è stata estratta la porzione della matrice degli allarmi inerente alle cinque celle 2044, 2143, 2144, 2145 e 2244 (d’ora in poi ZONA_2): il risultato è quello di Figura 56.

Figura 56: matrice degli allarmi con parametri m = 3 e ϵ = 10^-4 – zoom sulla ZONA_2

Rispetto al caso precedente, la situazione è molto più “frastagliata”, sintomo presumibilmente di parametri meno adatti alla rilevazione di allarmi per il traffico generato dalle cinque celle in esame e/o di eventi più frequenti e meno a comune fra le celle della ZONA_2. Si individuano comunque, rispetto alla cella di riferimento 2144, allarmi a comune nei giorni 12, 22, 26 e 29 Dicembre 2013. Dopo una rapida ricerca, effettivamente alcune delle date citate corrispondono ad eventi in programma al Mediolanum Forum:

• 12/12/2013 - Finale di X Factor 7;

• 22/12/2013 - Family Christmas Show di Laura Pausini;

Per le restanti date non sono state trovate corrispondenze degne di nota. Potrebbe trattarsi dunque di eventi individuati dall’algoritmo ma di cui non si hanno corrispondenze tra le informazioni degli archivi consultati.

Come già per il caso precedente, anche per la ZONA_2 si propone l’andamento temporale

del traffico per singola cella con i relativi allarmi (Figura 57).

70

Figura 57: andamento del traffico nelle celle della ZONA_2 e relativi allarmi rilevati (tratto rosso)

Anche in questo caso, la scala delle ampiezze è stata standardizzata per tutte le celle in modo da avere un confronto visivo coerente ma troncando spesso le ampiezze di picco per le celle più attive. Si notano gli allarmi in prossimità delle date citate sopra, nonché mancati avvistamenti e falsi allarmi.

4.2.3 Z ONA Q UARTIERE F IERISTICO DI R HO -P ERO

Come terzo ed ultimo caso di applicazione dell’algoritmo SW-CLT, si propone uno zoom sulla zona del Quartiere Fieristico di Rho-Pero. La ricerca ha individuato il numero di cella di riferimento nella 7723 (Figura 58).

Figura 58: individuazione cella 7723 attraverso il tool online del portale dandelion.eu

71 L’indagine è stata estesa alle celle adiacenti e nello specifico 7623, 7624 e 7724 coprendo gran parte del polo fieristico in esame (d’ora in avanti ZONA_3). Da prove sperimentali, l’applicazione dell’algoritmo sulle celle della ZONA_3 con i parametri usati fin ora (m=3 e

ϵ = 10^-4) non ha generato alcun allarme. Si è scelto quindi, a parità di Probabilità di Falso Allarme a Priori ( ϵ = 10^-4) di variare (aumentare) la dimensione della finestra m, scegliendo m=6 (rendendo quindi l’algoritmo sensibile a variazione più lunghe nel tempo).

La porzione della matrice MA relativa alla ZONA_3 con i nuovi parametri di lavoro è quella rappresentata in Figura 59.

Figura 59: matrice degli allarmi con parametri m = 6 e ϵ = 10^-4 – zoom sulla ZONA_3

In Figura 60 è riportato l’andamento del traffico per le celle della ZONA_3 e i relativi allarmi rilevati.

Figura 60: andamento del traffico nelle celle della ZONA_3 e relativi allarmi rilevati (tratto rosso)

72

Da entrambe le ultime due figure, è evidente come l’algoritmo rilevi degli allarmi all’inizio del mese di Dicembre 2013, dove tra l’altro il traffico delle celle è indubbiamente maggiore che nel resto del mese. Una rapida ricerca sul web ha confermato infatti l’esistenza di un evento fieristico nella zona di indagine nel periodo 30 Novembre – 8 Dicembre 2013 [20].

Quest’ultimo caso di applicazione ha messo in evidenza l’importanza del parametro m per

il funzionamento dell’algoritmo: infatti eventi sporadici e con rapide variazioni del traffico

(in aumento e non) sono più adatti ad una rilevazione per mezzo di finestre “piccole” che

possano “captare” le variazioni in valor medio in un gate temporale ristretto (eventi della

ZONA_1 e ZONA_2). Nel caso della ZONA_3, la natura continuativa di un evento in un

determinato periodo del mese ha provocato, invece, un andamento del traffico abbastanza

regolare per le celle interessate, richiedendo, come dimostrato sperimentalmente, una

finestra m doppia rispetto ai casi precedenti vista la necessità di rilevare fronti in salita e

discesa nei livelli di traffico con variazioni più lente.