} if ( s t r c m p ( a r g v [1] , " S e n d ") == 0) { S e n d P a c k e t (); r e t u r n ( T C L _ O K ); } } r e t u r n ( A g e n t :: c o m m a n d ( argc , a r g v )); }
In questo esempio common(), appartenente alla classe RFID (che rappresenta una possibile estensione di Agent), `e in grado di interpretare due possibili comandi Otcl:
call-my-priv-func che richiamer`a il metodo MyPrivFunc() Send che richiamer`a SendPacket()
A livello Tcl sar`a quindi saranno sufficienti le seguenti righe per eseguire il metodo SendPacket su un’istanza della classe RFID.
set r e a d e r [ new A g e n t / R F I D ] $reader Send
6.4
Estensione di Packet e Agent
Negli ultimi due paragrafi sono stati descritti due elementi fondamentali di NS-2 quali l’Agent e il Packet accennando ad una possibile estensione delle classi in cui sono implementate. Proprio quest’ultima potenzialit`a ci ha per- messo di creare tipologie di Agent e di Packet peculiari a quelle dei sistemi RFID e dei protocolli basati su Aloha.
Lo scopo dei nostri studi `e quello di confrontare tra loro prestazioni di RFID che utilizzano il protocollo Slotted Aloha per risolvere i problemi di tag collision con RFID che utilizzano EPCGlobal. Queste due tipologie di reti sono state implementate in due fasi indipendenti e in ognuna di esse sono stati realizzati un nuovo header per la classe packet e due nuovi agent differenti per emulare i diversi comportamenti del reader e dei tag.
6.4.1
Descrizione implementativa
Per prima cosa dobbiamo creare un nuovo header per la classe packet con- tenente i campi per le informazioni che reader e transponder si dovranno inviare per la simulazione del protocollo.
s t r u c t h d r _ M e s s a g e R F I D { int Id ; d o u b l e s e n d _ t i m e ; d o u b l e r c v _ t i m e ; c h a r ret ; int seq ; int i n v i a t o ; d o u b l e w a i t _ s e n d ; int N u m e r o S l o t ; d o u b l e S i z e S l o t ; int d e s t i n a t a r i o ; s t a t i c int o f f s e t _ ; i n l i n e s t a t i c int & o f f s e t () { r e t u r n o f f s e t _ ;} i n l i n e s t a t i c h d r _ M e s s a g e R F I D * a c c e s s ( c o n s t P a c k e t * p ) { r e t u r n ( h d r _ M e s s a g e R F I D *) p - > a c c e s s ( o f f s e t _ ); } };
Una volta creati i campi del nuovo header `e possibile passare all’estensione della classe PacketHederClass
s t a t i c c l a s s R F I D H e a d e r C l a s s : P a c k e t H e a d e r C l a s s { p u b l i c : R F I D H e a d e r C l a s s (): P a c k e t H e a d e r C l a s s (" P a c k e t H e a d e r / M e s s a g e R F I D " , s i x e o f ( h d r _ M e s s a g e R F I D ){ } } c l a s s _ M e s s a g e R F I D h d r
6.4. Estensione di Packet e Agent 71
Una volta creato il nuovo header, vediamo in quale maniera `e stato imple- mentato il Reader (nel file ReaderAgent.h,.cc) di un sitema RFID estenden- do la classe Agent. Nel file ReaderAgent.h sono stati semplicemente inserite tutte le variabili e i metodi che verranno poi utilizzati in ReaderAgent.cc
c l a s s R e a d e r A g e n t : p u b l i c A g e n t { p u b l i c : R e a d e r A g e n t (); int n u m S l o t _ ; ... ... ... }
Quindi l’implementazione vera propria che si articola in due fasi. Nella prima viene creato il collegamento con il codice OTcl estendendo la classe TclClass s t a t i c c l a s s R e a d e r C l a s s : p u b l i c T c l C l a s s { p u b l i c : R e a d e r C l a s s () : T c l C l a s s (" A g e n t / M e s s a g e R F I D ") {} T c l O b j e c t * c r e a t e ( int , c o n s t c h a r * c o n s t *) { r e t u r n ( new R e a d e r A g e n t ( ) ) ; } } c l a s s _ M e s s a g e R F I D ;
Grazie a questo collegamento sar`a possibile creare un’istanza di Reader- Agent durante la simulazione in OTcl per mezzo del comando:
set M y R e a d e r [ new A g e n t / M e s s a g e R F I D ]
Quindi, viene implementato il costruttore di ReaderAgent in cui facciamo anche utilizzo delle bind di cui abbiamo parlato sopra.
R e a d e r A g e n t :: R e a d e r A g e n t () : A g e n t ( P T _ R F I D R E A D E R ){ b i n d (" p a c k e t S i z e _ " , & s i z e _ ); b i n d (" N u m e r o S l o t _ " , & N u m S l o t _ ); b i n d (" F r a m e D i n a m i c o _ " , & S i z e D i n a m i c a _ ); N u m S l o t _ = 30; S l o t C o l l = 0; ... ...
Il metodo command() di ReaderAgent sar`a relativamente semplice in quanto potr`a ricevere il solo comando send che richiamer`a il metodo Send- Packet() dando il via al processo di identificazione degli RFID.
Concludiamo quindi analizzando in che modo il Reader utilizza il l’Head- erPacket appena creato, lo invia all’interno della SendPacket() e lo analizza in caso di recv() v o i d R e a d e r A g e n t :: S e n d P a c k e t () { P a c k e t * pkt = a l l o c p k t (); h d r _ c m n * ch = H D R _ C M N ( pkt ); h d r _ i p * iph = H D R _ I P ( pkt ); ch - > p t y p e ()= P T _ R F I D R E A D E R ; h d r _ M e s s a g e R F I D * ph = h d r _ M e s s a g e R F I D :: a c c e s s ( pkt ); ph - > w a i t _ s e n d = 0; ph - > N u m e r o S l o t = n u m S l o t _ ; ... s e n d ( pkt ,( H a n d l e r *) 0);
Come possiamo vedere dal codice, una volta creato il pacchetto pkt per mezzo della allockpkt(), vengono creati due puntatori all’header cmn e al- l’header ip per poterne riempire alcuni campi, quali il ptype. Quindi viene creato l’oggetto ph del nuovo header appena creato (hdr MessageRFID), ag- giunto a pkt per poter trasmettere le informazioni in esso contenute. Dopo aver riempito i campi di ph il pacchetto pu`o essere inviato per mezzo della send.
La recv() procede nella stessa maniera, ma in maniera inversa: come de- scritto in precedenza, una volta invocata restituisce un puntatore al pacchetto ricevuto in modo da poter leggere l’informazione inviata dal mittente.
v o i d R e a d e r A g e n t :: r e c v ( P a c k e t * pkt , H a n d l e r *) { h d r _ i p * h d r i p = h d r _ i p :: a c c e s s ( pkt );
h d r _ M e s s a g e R F I D * hdr = h d r _ M e s s a g e R F I D :: a c c e s s ( pkt ); int n = hdr - > seq ;
6.4. Estensione di Packet e Agent 73
Prima di poter procedere all’utilizzo dei nuovi componenti implementati `e stato necessario effettuare ulteriore moodifiche in alcuni file interni di Ns-2. Per prima cosa dobbiamo inserire in pacekt.h i riferimenti ai nuovi pacchetti utilizzati e n u m p a c k e t _ t { ... P T _ R F I D R E A D E R .. } ... c l a s s p _ i n f o { p u b l i c : p _ i n f o () { n a m e _ [ P T _ R F I D R E A D E R ] = " M e s s a g e R i f i d "
In seconda analisi dobbiamo aggiornare il file ns-default.tcl (con i valori di default di alcuni campi quali la size) e ns-packet.tcl con il nuovo pacchetto. La creazione del Tag per lo Slotted Aloha e di tutto il sistema (pacchetto, reader, tag) per la realizzazione dell’EPCGlobal procede in maniera analoga a quella che abbiamo appena visto. I passi appena illustrati sono infatti abbastanza genereci e sono grosso modo gli stessi ogni qual volta si voglia creare un nuovo Agent e un nuovo Packet.
Ovviamente ci saranno molte differenze negli algoritmi interni dei diversi Agent in base al ruolo e ai comportamenti che dovranno avere all’interno della
simulazione. Prendendo ad esempio il Tag, questo avr`a il metodo common()
vuoto, in quanto gli unici comandi che pu`o ricevere provengono dal Reader
durante un ciclo di interrogazioni.
Allo stesso modo sia il Reader che il Tag di un sistema EPCGlobal avran-
no una struttura interna pi`u complessa per poter emulare tutte le fasi del
protocollo in questione, ma anche in questo caso le procedure di estensione degli Agent e dei Packet procedono sulla falsariga di quelli appena descritti.
Figura 6.3: Schema pila protocollare NS-2
6.5
Rete Wireless e livello MAC
Fino ad ora, non abbiamo preso in considerazione un’aspetto fondamentale per i nostri scopi: una rete RFID `e, ovviamente basata su ambiente wirelss.
NS-2 offre in maniera ottimale la possibilit`a di simulare reti in ambiente
wireless utilizzando anche protocolli di livello di rete pi`u bassi quali il MAC. In questo paragrafo daremo una descrizione generale dell’ambiente wire- less in NS-2 descrivendo le modifiche effettuate a livello MAC per meglio simulare una rete RFID.
NS-2 organizzato secondo una struttura modulare in cui ciascun oggetto esegue le proprie elaborazioni e poi ne comunica i risultati agli oggetti adi- acenti. In particolare, un nodo (W)LAN ha differenti oggetti che simulano
indipendentemente i tre livelli pi`u bassi del modello ISO-OSI: LL, MAC e
PHY. Un apposito modello `e schematizzato in figura 6.3
Un pacchetto generato dai livelli superiori viene accodato nel Link Layer, poi passato al MAC layer, che definisce le regole per accedere al canale fisico, implementato dall’oggetto Channel, che a sua volta provvede a simulare la
6.5. Rete Wireless e livello MAC 75
propagazione e a far giungere in istanti opportuni i pacchetti ai diversi nodi in ascolto sullo stesso mezzo. Il pacchetto ricevuto si trova eventualmente ad effettuare il percorso inverso e a risalire i diversi layer, giungendo fino al livello applicativo del nodo destinatario. Come avviene realmente nelle reti wireless, tutti i nodi vedono sul canale tutti i pacchetti trasmessi (se sono in visibilit`a radio), ma sar`a compito del livello MAC di ciascun nodo accettare e trasferire ai livelli superiori solo quelli destinati al nodo stesso. La
maggiore complessit`a in ciascun nodo risiede proprio nell’oggetto MAC, che
deve provvedere a simulare oltre al funzionamento dei protocolli di accesso al canale propri del particolare livello MAC simulato, anche gli eventuali meccanismi di carrier sense e collision detection mentre quelli di propagazione sono simulati dall’oggetto Channel.
Ognuno di questi oggetti `e implementato da una classe C++ che for-
nisce mebri pubblici per interfacciarsi con gli altri oggetti e per essere con- figurabili durante la simulazione OTcl. All’inizio del codice OTcl `e infatti possibile andare a configurare parametri del sistema di trasmissione con cui poi configureremo i nodi della rete. Il seguente codice mostra una possibile configurazione.
set val ( c h a n ) C h a n n e l / W i r e l e s s C h a n n e l ; # C h a n n e l T y p e
set val ( p r o p ) P r o p a g a t i o n / T w o R a y G r o u n d ; # radio - p r o p a g a t i o n m o d e l set val ( n e t i f ) Phy / W i r e l e s s P h y ; # n e t w o r k i n t e r f a c e t y p e set val ( mac ) Mac / 8 0 2 . 1 1 ; # M A C t y p e
set val ( ifq ) Q u e u e / D r o p T a i l / P r i Q u e u e ; # i n t e r f a c e q u e u e t y p e set val ( ll ) LL ; # l i n k l a y e r t y p e set val ( ant ) A n t e n n a / O m n i A n t e n n a ; # a n t e n n a m o d e l set val ( i f q l e n ) 50 ; # m a x p a c k e t in i f q
Come appena descritto, un ruolo fondamentale nella gestione dei pac- chetti che arrivano o partono da un nodo lo riveste il livello Mac. Per questo motivo e con l’intento di realizzare una rete il pi`u simile possibile a quel-
la RFID, sono stati implementati livelli MAC con apposite caratteristiche. Senza addentrarci troppo sui dettagli implementativi, a livello MAC un nodo RFID deve:
inoltrare immediatamente un pacchetto in uscita ( e dunque prove- niente dal livello Agent) senza fare alcun tipo di carrier sense
rilevare eventuali collisioni tra pacchetti entranti e, eventualmente, co- municarle all’Agent in modo che questo possa gestirle secondo il proprio protocollo (Slotted Aloha o EPCGlobal)
scartare eventuali pacchetti non destinati a lui.
Pur essendo praticamente uguali, sono stati implementati due protocol- li MAC distinti per lo SLotted ALoha e per l’EPCGlobal rispettivamente richiamabili inserendo
set val ( mac ) Mac / A l o h a set val ( mac ) Mac / EPC
Capitolo 7
Simulazioni e risultati
Una volta terminata l’estensione di NS-2, si pu`o passare alla simulazione dei protocolli Slotted Aloha ed EPCglobal.
I due protocolli in questione verranno simulati in meniera separata e, per ognuno di questi, proveremo a cambiare alcuni paramteri interni in modo da poter trovare la migliore configurazione possibile. Quindi, in ultima analisi, i due protocolli verranno confrontati tra loro per cercare di stabilire quale si adatti meglio ad un sistema RFID.
7.1
Slotted Aloha
Come abbiamo visto nel cap. 3, un reader che utilizza lo Slotted Aloha stabilisce una framesize iniziale espressa in numero di slot e invita ogni tag a scegliere in maniera casuale lo slot in cui trasmettere. Terminato il ciclo di interrogazioni per quel frame, il reader, qualora avesse riscontrato delle collisioni, pu`o decidere per la nuova fase di identificazione se lasciare invariato
il numero di slot del frame (BFSA) o ricalcoralo attraverso la disuguaglianza di Chebyshev (DFSA).
Nelle nostre simulazioni abbiamo provato entrambe le versioni dello Slot- ted Aloha partendo da molteplici dimensioni iniziali del frame e fissando alcuni parametri comuni1:
La dimensione di un pacchetto contenente dati `e stata fissata a 16 byte, quella di un ack ad 1 byte.
La velocit`a di trasmissione `e stata fissata a 0,1 Mbps
La dimensione temporale di un singolo slot `e stata tarata in modo da poter contenere il tempo necessario all’invio dei dati da parte del tag e del relativo ack e arrotondata per eccesso a 0,0015 secondi.
Il raggio d’azione del reader `e di 5 metri con i tag che si dispongono in maniera casuale.
In tabella 7.1 possiamo vedere i risultati di una simulazione in cui si dovevano identificare 50 tag utilizzando le due tipologie differenti di Slotted Aloha (statico e dinamico) e variando il numero di slot iniziali del frame.
Numero Slot Iniziali
10 25 35 50 75 100 200
BFSA 0,7163s 0,2867s 0,2556s 0,2865s 0,3360s 0,4107s 0,6172s
DFSA 0,2522s 0,2352s 0,2202s 0,2235s 0,2371s 0,2605s 0,3867s
Tabella 7.1: Simulazione Slotted Aloha con 50 tag
1Questi parametri sono stati fissati basandosi su reali specifiche tecniche consultabili anche nelle specifiche dell’EPCglobal
7.1. Slotted Aloha 79
Ogni singolo risultato riportato in tabella rappresenta il tempo medio (espresso in secondi) di riconoscimento dei 50 tag con quella particolare configurazione ed `e stato ottenuto ripetendo la simulazione per 100 volte.
Si pu`o notare da subito come il Dinamic Frame Slotted Aloha sia pi`u
veloce del protocollo con frame statico indipendentemente dalla dimensione iniziale del frame. Inoltre, in base ai dati raccolti durante le simulazioni, si `e potuta notare una maggiore stabilit`a dei risultati del DFSA nei confronti del BFSA; i risultati ottenutinelle nelle 100 simulazioni di ognuna delle con- figurazioni con protocollo statico hanno infatti un’indice di dispersione che arriva anche al 19% (contro l8% del dinamico) a testimonianza di una forte fluttualit`a delle prestazioni.
Aumentando il numero di tag da identificare, i risultati confermano sem- pre di pi`u i risultati ottenuti nelle simulazioni precedenti.
Numero Slot Iniziali
25 50 75 100 125 150 200
BFSA 0,8255s 0,5272s 0,5317s 0,6117s 0,6734s 0,7245s 0,8677s
DFSA 0,4844s 0,4626s 0,4357s 0,4535s 0,4502s 0,4798s 0,5279s
Tabella 7.2: simulazione Slotted Aloha con 100 tag
Numero Slot Iniziali
50 75 100 125 150 200 300
BFSA 0,9036 0,8144s 0,8252s 0,8650s 0,9478s 1,0754s 1,3621s
DFSA 0,7068s 0,6928s 0,6594s 0,6613s 0,6709s 0,6909s 0,7006s
Tabella 7.3: simulazione Slotted Aloha con 150 tag
Analizzando le tabelle riportate e la figura 7.1, si pu`o notare anche un’al- tra caratteristica comune: in tutti e quattro gli scenari, la migliori configu-
Numero Slot Iniziali
75 100 125 150 200 300 400
BFSA 1,1279s 1,0853s 1,1024s 1,2715s 1,4397s 1,5717s 1,8666s
DFSA 0,9337s 0,9253s 0,8860s 0,8976s 0,9113s 0,9473s 1,0546s
Tabella 7.4: simulazione Slotted Aloha con 200 tag
Figura 7.1: Tempi medi di identificazione dei tag utilizzando DFSA in
funzione della framesize iniziale
razioni, oltre a basarsi sul protocollo dinamico, sono quelle che partono con una dimensione del frame pi`u piccola rispetto al numero di tag da identificare o, meglio ancora, compresa tra il numero dei tag e la met`a di questi.
Questa osservazione pu`o risultare utile ai fini di una installazione di una rete RFID; se `e infatti vero che un reader non pu`o sapere, per definizione propria del sistema, il numero di tag che si presenteranno ad ogni ciclo di interrogazione pu`o per`o farne una stima basandosi su esperienze passate e rimodificare dinamicamente le proprie impostazioni di base per cercare di ottimizzare le prestazioni.
Nelle simulazioni descritte sopra, sono stati osservati anche gli aspetti riguardanti la quantit`a di slot necessaria al riconoscimento dei tag in ques-
7.2. EPCGlobal 81
tione. I risultati, mostrati nelle tabelle 7.5 7.6 7.7, confermano la superi-
orit`a del DFSA e la leggera ottimizazzione delle prestazioni partendo con
dimensioni del frame leggermente inferiori al numero di tag da identificare. Numero Slot Iniziali
10 25 35 50 75 100 200
BFSA 440,5 196,5 172,2 198,5 234,0 289,0 436,0
DFSA 162,2 152,2 143,3 145,9 155,7 171,9 258,0
Tabella 7.5: Slotted Aloha con 50 tag: numero medio degli slot totali utilizzati
Numero Slot Iniziali
25 50 75 100 125 150 200
BFSA 573,2 355,0 361,5 426,0 467,5 501,0 616,0
DFSA 317,5 303,9 286,5 298,8 297,9 317,6 349,9
Tabella 7.6: Slotted Aloha con 100 tag: numero medio degli slot totali utilizzati
Numero Slot Iniziali
50 75 100 125 150 200 300
BFSA 601,5 550,5 566,0 598,7 655,5 750,0 954,0
DFSA 465,8 457,4 435,4 438,0 444,3 457,5 525,4
Tabella 7.7: Slotted Aloha con 150 tag: numero medio degli slot totali utilizzati
7.2
EPCGlobal
Il protocollo di comunicazione EPCglobal, come ampiamente descritto nel
cap. 4, pu`o essere visto come una modfica di DFSA: come quest’ultimo,
Numero Slot Iniziali
75 100 125 150 200 300 400
BFSA 769,2 735,0 752,5 598,7 878,0 1000,0 1110,0
DFSA 617,4 612,5 586,4 594,7 604,2 629,2 700,7
Tabella 7.8: Slotted Aloha con 200 tag: numero medio degli slot totali utilizzati
ad una potenza di due, scanditi dal comando QueryRep, ed offre la possi- bilt`a aggiuntiva di ridimensionare il frame senza attendere la terminazione dello stesso. Quest’ultima possibilit`a `e stata largamente utilizzata durante le simulazioni effettuate con NS-2. Fissato, infatti, il numero di slot in- iziali sono state simulate diverse varianti del protocollo cambiando l’istante in cui analizzare i risultati fino a quel momento ottenuti ed, eventualmente, ridimensionare il frame.
Come abbiamo fatto per lo Slotted Aloha sono state fissate alcune im- postazioni di base valide per tutte le simulazioni effettuate:
Basandosi sulle specifiche ufficiali dell’EPCglobal sono state fissate le seguenti dimensioni dei pacchetti:
– Query = 3 byte;
– QueryRep e QueryAdjust = 1 byte; – Ack = 1 byte;
– RN16 = 1 byte;
– PC+EPC+CRC16 = 16 byte;
7.2. EPCGlobal 83
Punto in cui ricalcolare la size
10% 15% 25% 50% 75% 90% 100% Q = 3 0,3713s 0,2667s 0,2075s 0,1758s 0,1720s 0,1650s 0,1619s Q = 4 0,3348s 0,2590s 0,2107s 0,1767s 0,1692s 0,1620s 0,1602s Q = 5 0,3457s 0,2608s 0,2100s 0,1727s 0,1676s 0,1622s 0,1595s Q = 6 0,3511s 0,2600s 0,2159s 0,1943s 0,1750s 0,1830s 0,1848s Q = 7 0,3437s 0,2654s 0,2143s 0,1994s 0,2008s 0,2278s 0,2390s
Tabella 7.9: Prestazioni EPCglobal con 50 tag
Il tempo di attesa del reader prima di stabilire l’assenza di messaggi
nello slot in corso ed inviare una QueryRep/QueryAdjust `e di 0,001
secondi.
Il raggio d’azione del reader `e di 5 metri con i tag che si dispongono in maniera casuale.
La tabella 7.9 mostra i risultati di una simulazione in cui si dovevano identificare 50 tag per mezzo del protocollo EPCglobal e con diverse config- urazioni di base del protocollo stesso. Come si pu`o notare, infatti, abbiamo provato lo stesso scenario partendo da differenti dimensioni iniziali del frame
(espresse tramite il parametro Q2) e per ognuna di questa abbiamo fissato
il punto, espresso in percentuale, in cui analizzare i risultati fino a quel mo- mento ottenuti ed eventualmente inviare la QueryAdjust per ridimensionare il frame.
Osservando i risultati delle simulazioni si pu`o subito notare un aspetto importante: `e consigliabile utilizzare le QueryAdjust nelle parti finali del frame se non addiruttura al termine di questo nel caso in cui si utilizzino
2Si ricorda, dal cap. 4, che Q `e il parametro utilizzato dal reader, e passato ai, tag per identificare la dimensione del frame pari a 2Q
dimensioni iniziali relativamente piccole. La motivazione di questo pu`o ess- er legata al fatto che, facendo mediante Chebishev l’analisi degli slot fino a quel momento controllati in uno stato avanzato del frame, abbiamo una
mole di informazioni molto pi`u grande da poter analizzare con una maggiore
attendibilit`a dei risultati e conseguente precisione pi`u elevata riguardo alla successiva dimensione del frame.
Quest’ultima osservazione viene avvalorata anche da un altro dato. La grande quantit`a di simulazioni effettuata per ogni singola configurazione ha evidenziato una forte variabilit`a dei risultati nei casi in cui si procedeva all’utilizzo di Chebishev, e ad una eventuale QueryAdjust, in fasi iniziali di lettura del frame. Ad esempio, il risultato ottenuto dalla media delle simulazioni con configurazione Q=3 e analisi del frame al 10% porta con se un indice di dispersione superiore al 40% e i risultati oscillano da un minimo di 0,206s a un massimo di 1,084s. Aumentando la dimensione iniziale del frame i risultati migliorano ma non in maniera determinante mantenendo
un indice che si aggira intorno al 30%. Evidentemente, la minore quantit`a
di dati su cui lavorare porta a considerazioni troppo aleatorie riguardante il numero previsto di tag e il conseguente ridimensionamento del frame per minimizzare le collisioni.
La situazione generale descritta, cambia leggermente partendo da dimen- sioni grandi del frame (quali Q=7) rispetto al numero di tag da identificare; in questo caso la posizione migliore in cui effettuare la QueryAdjust tende a spostarsi leggermente verso il centro. Evidentemente, superato un cer- to numero di slot, il tempo necessario per ascoltare gli slot successivi del frame risulta troppo elvato rispetto alla quantit`a di informazione che pu`o
7.2. EPCGlobal 85
Punto in cui ricalcolare la size
10% 15% 25% 50% 75% 90% 100% Q = 3 0,6043s 0,4893s 0,4117s 0,3598s 0,3404s 0,3304s 0,3306s Q = 4 0,5974s 0,4907s 0,4093s 0,3564s 0,3425s 0,3313s 0,3304s Q = 5 0,6064s 0,4876s 0,4055s 0,3498s 0,3340s 0,3286s 0,3258s Q = 6 0,5932s 0,4851s 0,4079s 0,3513s 0,3330s 0,3269s 0,3245s Q = 7 0,5889s 0,4647s 0,4316s 0,3746s 0,3563s 0,3712s 0,3800s Q = 8 0,5842s 0,4839s 0,4204s 0,3922s 0,4238s 0,4587s 0,4850s
Tabella 7.10: Prestazioni EPCglobal con 100 tag
aggiungere a quella gi`a ottenuta nella prima parte.
Occorre comunque notare che il punto in cui ricalcolare la dimensione del frame viene stabilito all’inizio dell’intero processo di identificazione e rimane tale per tutto il suo svolgimento Fissare quindi il calcolo di Chebyshev in
un punto intermedio del frame pu`o portare a buoni risultati nell’immediato
(in quanto abbiamo una dimensione del frame grande ) ma pu`o portare a
prestazioni peggiori non appena questo viene ridotto in numero di slot. Quest’ultima osservazione `e probabilmente collegata ad un altro dato che evdiente mostrato dalla tabella e che conferma, in un certo senso, quanto gi`a avevamo intuito con lo Slotted Aloha: le prestazioni migliori si otten- gono fissando la dimensione iniziale del frame in un numero inferiore a quel- lo dei tag presenti, o quanto meno previsti, in un determinato processo di identificazione.
Le tabelle 7.10, 7.11, 7.12 mostrano rispettivamente i risultati ottenuti in scenari con 100, 150 e 200 tag.
Una prima osservazione da notare, aumentando il numero di tag da iden- tificare, riguarda l’istante in cui effettuare i calcoli la QueryAdjust. Abbi- amo appena che le prestazioni migliori si ottengono utilizzando Chebyshev
Punto in cui ricalcolare la size 10% 15% 25% 50% 75% 90% 100% Q = 3 0,8192s 0,7269s 0,6241s 0,5484s 0,4917s 0,5009s 0,5026s Q = 4 0,8330s 0,7347s 0,6237s 0,5440s 0,4950s 0,4990s 0,5000s Q = 5 0,8400s 0,7360s 0,6217s 0,5450s 0,4930s 0,4990s 0,4997s Q = 6 0,8183s 0,7432s 0,6246s 0,5419s 0,4889s 0,4930s 0,4937s Q = 7 0,8062s 0,7365s 0,6148s 0,5348s 0,5006s 0,5076s 0,5219s Q = 8 0,8104s 0,7497s 0,6270s 0,5714s 0,5251s 0,5424s 0,5674s
Tabella 7.11: Prestazioni EPCglobal con 150 tag
Punto in cui ricalcolare la size
10% 15% 25% 50% 75% 90% 100% Q = 4 1,1119s 0,9649s 0,8164s 0,7108s 0,6800s 0,5559 0,4542 Q = 5 1,0857s 0,9651s 0,8199s 0,6941s 0,6683s 0,6482s 0,6523s Q = 6 1,0892s 0,9704s 0,8174s 0,6941s 0,6683s 0,6482s 0,6523s Q = 7 1,1037s 0,9715s 0,8200s 0,7030s 0,6646s 0,6530s 0,6560s Q = 8 1,1110s 0,9289s 0,8628s 0,7718s 0,7095s 0,7430s 0,7780s Q = 9 1,1018s 0,9380s 0,8327s 0,7915s 0,8595s 0,9188s 0,9750s
7.2. EPCGlobal 87
Figura 7.2: Prestazioni EPCGlobal in funzione di Q con QueryAdjust al 90%
al termine del frame.Aaumentando il numero di tag notiamo, invece, che, seppur con differenze minime, i risultati migliori si ottengono effettuando la QuqryAdjust in posizioni comprese tra il 75% e il 90% del frame.
L’aspetto particolare che, comunque, emerge fortemente da queste nuove
simulazioni `e legato alla dimensione iniziale del frame: nonstante un au-
mento del numero di tag presenti nell’area di lettura del reader, le migliori prestazioni si ottengono mantenendo dimensioni relativamente basse della framesize e in tutti casi i migilori risultati si ottiengono per Q=6 e Q=5.
Quest’ultimo aspetto pu`o rappresentare un punto di forza dell’EPCglobal: possiamo infatti affermare che fissando la dimensione iniziale del frame a Q=6 o Q=5 e stabilendo di fare l’eventuale QueryAdjust in un punto compreso tra il 75% e il 100% del frame stesso, otterremo risultati in generale ottimali indipendentemente dal numero di tag da riconoscere.
La figura 7.2 descrive le prestazioni di EPCglobal al variare della dimen-
sione iniziale 2Q del frame e fissando la QueryAdjust al 90% del frame evi-
Figura 7.3: Prestazioni EPCglobal al variare del momento in cui effettuaree la QueryAdjust
del frame relativamente basse.
7.3
EPCglobal vs DFSA
Dalle simulazioni descritte negli ultimi due paragrafi emergono in maniera ab- bastanza nitida le migliori performance dello stadard EPCglobal nei confronti di DFSA, e, a maggior ragione, di BFSA.
I grafici in figura 7.4 descrivono l’andamento dei due protocolli in funzione della lunghezza iniziale del frame e con QueryAdjust, per l’EPCglobal, al 90% del frame. Per fare un confronto ancora pi`u accurato, sono state anche fatte simulazioni dello Slotted Aloha con dimensioni iniziali del frame uguali a potenze di due.