Figura 2.18: Calcolo ritardo di trasmissione
un secondo canale di comunicazione affidabile che verrà utilizzato solo per il recupero dei pacchetti, che nella precedente trasmissione sono andati persi. Il canale può essere utilizzato sia dal peer del medico che dal peer del paziente. Il primo controller è l’id del pacchetto ricevuto con quelli adiacenti e, nel caso non ci sia una progressione unitaria, invierà un messaggio di ritrasmissione del pacchetto mancante nel nuovo canale. Il secondo peer, ricevuto il messaggio, invierà il pacchetto che verrà poi, nel peer ricevente, inserito nella posizione idonea per essere visualizzato. Tutto ciò deve pervenire prima che la porzione di dati debba essere visualizzata sull’interfaccia del medico e quindi la necessità di avere un buffer di dimensioni ragionevoli.
2.6 Test sul canale DataChannel
Il primo test effettuato ha lo scopo di determinare la dimensione massima del pacchetto dati che può essere trasmesso senza dover ricorrere a tecniche di frammentazione dello stesso. Poichè il DataChannel si basa su SCTP, che a sua volta è basato su DTLS, UDP ed IP, la dimensione massima del pacchet- to sarà data dalla Maximum Transmitting Unit (MTU), ovvero la dimensione massima di un pacchetto inviato in rete di telecomunicazioni meno i byte di overhead dei protocolli utilizzati. La dimensione della MTU di un pacchetto SCTP, impostata dai client WebRTC, è 1280 bytes, mentre quella degli ove- rhead dei protocolli è mostrata nella tabella 2.3. Considerando le dimensioni minime di overhead di ogni protocollo, si ottiene un overhead complessivo di 76 byte che, tolti alla dimensione massima del pacchetto di 1280 bytes, ci consente di avere 1204 bytes per i dati. Nel nostro caso, poichè il segnale dell’elettrocar- diogramma è formato anche da valori con segno negativo, si utilizzerà un byte
Tabella 2.3: Dimensione overhead dei protocolli di rete Protocollo Dimensione [byte]
IP 20-40
UDP 8
DTLS 20-40
SCTP 28
Tabella 2.4: Risultati al variare del numero di campioni per pacchetto e del numero di pacchetti inviati al secondo
Num campioni/ pacchetto Num secondo inviati Rate misurata [byte/s] Dim tot pacchetto [byte] 1 100 12016 120 2 50 6887 138 20 5 2276 456
per rappresentarne il segno, implicando un byte di differenza nel numero totale disponibile per il campo dati. L’header del pacchetto sarà formato dai campi Type, NumSample, Id, TimeStamp e T0 e con il passare del tempo, avrà dimen- sioni variabili a causa dell’aumento del TimeStamp e di T0. Le prove effettuate per calcolare il rate, la dimensione del pacchetto al variare del numero di cam- pione per pacchetto e del numero di pacchetti inviati al secondo, sono mostrate nella tabella 2.4. Ovviamente anche in un canale non affidabile si possono in- viare pacchetti di grandi dimensioni, ma in questo caso l’applicazione bufferizza l’informazione, frammenta il pacchetto e lo invia. Supponendo un pacchetto di grandi dimensioni come 120KB e una percentuale di perdita di pacchetti del 1%, il messaggio verrà diviso in 100 pacchetti per essere trasmesso. Se uno dei pacchetti andrà perso, in un canale inaffidabile non verrà ritrasmesso e quindi in ricezione non potrà essere ricostruita l’informazione originale. Per ovviare a tale problema si possono diminuire le dimensioni del pacchetto complessivo al di sotto dei 1204 bytes, contenibili in un unico pacchetto [6], o implementare un secondo canale per la ritrasmissione dei pacchetti persi, come effettuato nel nostro caso. Partendo dalla dimensione massima del messaggio, inviato tra- mite il DataChannel, si può ottenere il numero massimo di campioni che un pacchetto può contenere, evitando la frammentazione. Dai bytes ottenuti si può togliere l’header e, dividendo per la dimensione del campione, si ottiene 61 come numero di campioni che possono essere contenuti in uno stesso pacchetto senza che questo venga frammentato.
Come seconda prova è stato calcolato il ritardo di trasmissione al variare del numero di campioni contenuti in un pacchetto e quindi della frequenza di tra- smissione su DataChannel SCTP. Le prove sono state effettuate tra due peers
2.6 Test sul canale DataChannel
Tabella 2.5: Risultati delle prove effettuate Campioni Dim. Pacchetto [byte] Pacchetti per secondo Rate trasmissivo [byte/s] Ritardo Medio [ms] Dev. Stnd. 1 120 100 12000 45 23 20 462 5 2310 44 52 40 822 2.5 2056 44 46 60 1182 1.67 1970 48 30 80 1542 1.25 1928 69 67 100 1902 1 1902 54 46 120 2262 0.23 1886 46 57
connessi ad internet con normale linea ADSL, dove sono stati inviati pacchetti con numero di campioni variabile da 1 a 120 con passo 20. Poichè Arduino invia un campione ogni 10ms, questi saranno bufferizzati fino ad ottenere il numero desiderato per la composizione del pacchetto. Quindi il peer invierà un pacchetto ogni n*10ms, la cui dimensione sarà data da header più numero di campioni per dimensione del singolo pacchetto. La rate invece sarà calcolata come la dimensione del pacchetto per numero di pacchetti inviati al secondo. La tabella 2.5 mostra la dimensione dei pacchetti al variare del numero di cam- pioni e il ritardo di trasmissione ottenuto. Dalle prove effettuate si evidenzia come il ritardo di trasmissione non cambia in maniera considerevole al varia- re delle dimensioni del pacchetto. Inoltre esso non è cumulativo in quanto il sistema riesce ad inviare la quantità di messaggi richiesta senza necessità di bufferizzazione. La figura 2.19 mostra le prove effettuate con Id del pacchetto in ascissa e ritardo di trasmissione in ordinata.
Figura 2.19: Ritardo di trasmissione al variare del numero di pacchetti
Come ultima prova sono stati inviati pacchetti di 120 campioni per dieci minuti ottenendo un ritardo medio di 48.34 millisecondi. Dalla figura 2.20 si può notare come il ritardo, eccetto picchi sporadici dovuti alle condizioni della rete, ritorna nell’intorno del ritardo medio calcolato dalle prove di tabella 2.5. Da qui, visto il ritardo inferiore ai 100ms, si può concludere che il sistema mantiene delle buone performance anche per trasmissioni prolungate nel tempo con grande numero di campioni.