Free Press

Introduzione

In questo secondo post della serie su Bluetooth 5, copriamo la nuova caratteristica della velocità 2x migliorata insieme ad una panoramica generale del throughput per un’applicazione BLE (il post precedente ha superato le nuove caratteristiche di Bluetooth 5 in generale e più specificamente ha coperto la caratteristica della maggiore capacità pubblicitaria).

Prima di tutto, dobbiamo capire che le velocità pubblicizzate (1 Mbps e il nuovo 2 Mbps) sono solo teoriche e sono ridotte quando si tratta di throughput delle applicazioni. Questo è dovuto a molteplici ragioni che esamineremo nella prossima sezione.

La caratteristica Bluetooth 5 “2x velocità” richiede un aggiornamento hardware quindi i vecchi dispositivi/chip/moduli non la supporteranno. È anche importante notare che per ottenere questa maggiore velocità è necessario che entrambi i dispositivi BLE che comunicano tra loro supportino il nuovo LE 2M PHY (che rende possibile il trasferimento dei dati a questa maggiore velocità).

Il nuovo LE 2M PHY, così come l’originale LE 1M PHY, sono entrambi chiamati Uncoded PHYs poiché usano una rappresentazione a 1 simbolo per bit di dati (in confronto al nuovo LE Coded PHY che usa una rappresentazione a 2 o 8 simboli per bit di dati).

Un’altra cosa importante da notare è che quando si utilizza il PHY a velocità superiore, si ottiene effettivamente un consumo di energia inferiore (dato che si trasferisce la stessa quantità di dati). Questo perché il tempo di accensione della radio è ridotto senza che la potenza di trasmissione sia aumentata. Questo a sua volta migliora anche la coesistenza con altre tecnologie wireless all’interno dello spettro di 2,4 GHz (anche a causa del ridotto tempo di accensione della radio).

In questo post, copriremo:

• Qual è il throughput pratico da aspettarsi da BLE?
• Il nuovo 2M PHY di Bluetooth 5 per il trasferimento dati
• Quali sono i fattori che impattano/determinano il throughput dei dati?
• Come si calcola il throughput dei dati dell’applicazione?
• Come si massimizza il throughput dei dati?
• Test, misurazione e calcolo del throughput dei dati utilizzando due kit di sviluppo della serie nRF52

Perché è impossibile raggiungere le velocità teoriche di BLE?

Le velocità di trasmissione dati di 1 Mbps (LE 1M PHY), 2 Mbps (LE 2M PHY), 125 kbps e 500 kbps (entrambi utilizzando il LE Coded PHY con S=8 e S=2, rispettivamente) sono le velocità a cui la radio trasmette i dati, ma questo non è raggiungibile per il throughput dell’applicazione a causa delle seguenti ragioni:

• Limite sul numero di pacchetti per intervallo di connessione
• Ritardo IFS (Inter Frame Space) tra i pacchetti (150 us)
• Pacchetti vuoti che devono essere inviati da un dispositivo anche se nessun dato è disponibili per la trasmissione
• Packet overhead – non tutti i byte in un pacchetto sono usati per il payload

Per capire meglio questi fattori e capire cosa impatta sul throughput delle applicazioni, dobbiamo dare uno sguardo più profondo al formato del pacchetto. La figura seguente mostra come sono fatti i pacchetti dati LE 1M PHY e 2M PHY:

La parte che ci interessa (e quella che definisce veramente i dati dell’applicazione) è il Payload ATT. Come potete vedere dalla figura, ci sono un certo numero di byte di overhead che sono usati da ogni livello in Bluetooth Low Energy.

• Nella 4.0 e 4.1, il massimo ATT Payload è 20 byte.
• Nella 4.2 e 5.0, una nuova caratteristica chiamata Data Length Extensions (DLE) permette all’ATT Payload di contenere fino a 244 byte di dati.

Velocità Bluetooth 5: velocità 2x utilizzando il nuovo PHY 2M

È utile capire le limitazioni dell’utilizzo del nuovo LE 2M PHY in Bluetooth 5:

• Non può essere utilizzato per trasmettere gli annunci primari (sui canali primari).
• Può essere usato per i “pacchetti ausiliari” secondari inviati sugli stessi canali dei pacchetti di dati (37 canali: 0-36).
  Per saperne di più sulle pubblicità primarie e secondarie, fate riferimento al mio precedente post sul blog: Annunci Bluetooth 5: Tutto quello che dovete sapere.
• LE 1M è obbligatorio, mentre LE 2M è opzionale. Quindi, non tutti i chip che dichiarano di supportare Bluetooth 5 possono necessariamente gestire il throughput più elevato.
• Gli annunci e la scoperta possono avvenire sul LE 2M PHY, e poi le connessioni avvengono sul canale pubblicitario secondario utilizzando il LE 2M PHY

Il trasferimento di dati applicativi da un dispositivo all’altro avviene solitamente durante una connessione tra i due dispositivi. I dispositivi collegati possono negoziare l’uso di un PHY diverso tramite la procedura di aggiornamento PHY. Può essere avviata sia dallo slave che dal master dopo che una connessione è stata stabilita, ma il master prenderà la decisione finale su quale PHY viene utilizzato per ogni direzione (in base alla richiesta dello slave e ai PHY supportati dal master).

Fattori che influenzano/determinano il throughput dei dati

Ci sono alcuni fattori che influenzano il throughput dei dati di un’applicazione BLE. I più comuni sono:

• PHY utilizzata (LE 1M vs. LE 2M vs. LE Coded (S=2 o S=8))
• Intervallo di connessione
• Numero massimo di pacchetti per intervallo di connessione
• Unità massima di trasmissione ATT (ATT MTU)
• Data Length Extension (DLE)
• Tipo di operazione: Write with response vs. write without response, Indications vs. Notifications
• Inter Frame Space (IFS): intervallo di tempo tra pacchetti successivi (150 us)
• Trasmissione di pacchetti vuoti
• Packet overhead – non tutti i byte, in un pacchetto, sono usati per il payload dell’applicazione

Vediamo ognuno di questi in dettaglio.

PHY

Ci sono fondamentalmente tre PHY in Bluetooth 5: il PHY originale da 1 Mbps, il nuovo 2 Mbps, e il PHY codificato (con S=2, o S=8). Il PHY usato avrà un impatto diretto sul massimo throughput di dati che puoi raggiungere, poiché determina la velocità effettiva di dati grezzi in cui i pacchetti sono inviati via etere.

Intervallo di connessione & max pacchetti per evento di connessione

L’intervallo di connessione determina effettivamente quanti pacchetti possono essere inviati durante un evento di connessione. Più alto è il valore, più pacchetti possono essere inviati in un evento di connessione (fino a un certo limite per alcuni dispositivi).

Per saperne di più sugli intervalli di connessione: Intervalli ed eventi di connessione BLE

Tuttavia, il numero di pacchetti per evento di connessione dipende dal dispositivo e dallo stack BLE, quindi è limitato e differisce tra dispositivi e versioni dello stack su un dispositivo specifico. Questo valore dipende anche dal funzionamento del dispositivo, quindi la radio potrebbe dover partecipare ad altri eventi e il numero di pacchetti inviati per eventi di connessione potrebbe non raggiungere il massimo consentito dallo stack. Per esempio, il numero differisce tra iOS e Android e cambia anche a seconda della versione del sistema operativo in esecuzione sul dispositivo.

A volte è utile aggiornare dinamicamente i parametri di connessione in base al caso d’uso. Tuttavia, tieni presente che spetta al master accettare queste raccomandazioni o aggiornare i parametri per adattarli.

Data Length Extensions (DLE)

Questa caratteristica permette alla dimensione del pacchetto di contenere una maggiore quantità di carico utile (fino a 251 byte contro 27 quando è disabilitata). Questa caratteristica è stata introdotta nella versione 4.2 delle specifiche Bluetooth.

ATT Maximum Transmission Unit (ATT MTU)

ATT MTU Determina la quantità massima di dati che possono essere gestiti dal trasmettitore e dal ricevitore e che possono tenere nei loro buffer.

Il valore MTU influenza la quantità di dati in testa (in particolare l’intestazione ATT che è 3 byte). Il minimo MTU ATT consentito è 27 byte. Questo permette un massimo di 20 byte di carico utile ATT (3 byte sono usati per l’intestazione ATT, e 4 byte per l’intestazione L2CAP).

Non c’è limite per le specifiche su quanto alto possa essere il valore MTU, ma lo specifico stack in uso può avere le sue limitazioni. Per esempio, se abiliti DLE allora puoi trasferire fino a 251 – 4 = 247 byte (dopo aver dedotto la dimensione dell’intestazione L2CAP). Dopo aver preso in considerazione l’intestazione ATT (3 byte), ci rimangono 244 byte per i dati del carico utile ATT effettivo. Se l’MTU è almeno 247 byte, allora l’MTU entrerà in un singolo pacchetto. Se l’MTU è maggiore di 247 byte, allora l’MTU si estenderà su più pacchetti causando una diminuzione del throughput (a causa dell’overhead del pacchetto e dei tempi tra i pacchetti).

L’effettivo MTU viene determinato dal valore minimo di ATT MTU che il client e il server supportano. Per esempio, se un client supporta un ATT MTU di 100 byte e il server risponde che supporta un ATT MTU di 150 byte, allora il client deciderà che l’ATT MTU da utilizzare per la connessione da quel momento in poi è 100 byte.

Tipo di operazione: Write with response vs. write without response, Indications vs. Notifications

Se si desidera un alto throughput allora possiamo usare Write without response o Notifications per trasferire i dati dal client al server e dal server al client. Queste operazioni eliminano la necessità che l’altro dispositivo riconosca la ricezione dei dati e risponda prima che il successivo blocco di dati possa essere inviato.

Inter Frame Space (IFS): ritardo tra pacchetti consecutivi (150 us)

Dalla specifica Bluetooth:

4.1.1 Inter Frame Space

L’intervallo di tempo tra due pacchetti consecutivi sullo stesso indice di canale è chiamato Inter Frame Space. È definito come il tempo dalla fine dell’ultimo bit del pacchetto precedente all’inizio del primo bit del pacchetto successivo.
L’Inter Frame Space è designato “T_IFS” e deve essere di 150 μs.

Trasmissione di pacchetti vuoti

Se il dispositivo che riceve i dati non ha dati da inviare indietro, deve comunque inviare un pacchetto vuoto come da specifica Bluetooth.

Packet overhead

Come abbiamo visto nella figura del formato del pacchetto, il pacchetto include alcuni dati overhead che non contano nei dati dell’applicazione (dati ATT). Fondamentalmente, questi byte consumeranno una parte della tua velocità di trasferimento dati, senza tenere conto dei byte inviati come parte dei dati dell’applicazione.

Calcolo del throughput dei dati dell’applicazione

La grande domanda è: come calcoliamo il throughput della nostra applicazione?

Come abbiamo detto prima, ci sono alcune variabili che influenzano il throughput dei dati:

• Versione Bluetooth & PHY usato
• DLE: Data Length Extensions – abilitato o no
• Valore MTUATT
• Intervallo di connessione
• Numero massimo di pacchetti per evento di connessione
• Operazione (scritture con risposte vs. scrive senza risposte, e notifica vs. indicazione)
• Inter Frame Space (IFS): 150 microsecondi

La versione Bluetooth e il PHY determinano la velocità di trasferimento dati grezza. Per esempio, se stiamo usando Bluetooth versione 4.2 e il PHY LE 1M, allora la velocità di trasferimento è di 1 Mbps. Se invece stiamo usando il Bluetooth 5 LE Coded PHY con S=8, allora la velocità di trasferimento dati scende a 125 kbps.

Il DLE, l’ATT MTU, l’intervallo di connessione, il numero massimo di pacchetti per intervallo di connessione, il funzionamento e l’IFS determinano tutti la porzione di tempo on-radio che viene utilizzata per il trasferimento effettivo dei dati.

Il formato del pacchetto gioca un ruolo importante nella quantità di dati che vengono trasferiti sono i dati dell’applicazione effettiva. Il LE 1M PHY e il LE 2M PHY hanno entrambi un formato di pacchetto simile. Il LE Coded PHY ha un formato di pacchetto significativamente diverso, quindi guarderemo questi due casi separatamente.

LE 1M PHY e LE 2M PHY calcolo

Riferimento al formato di pacchetto per LE Uncoded PHYs:

La quantità di overhead per ogni PHY è leggermente diversa. Il preambolo è di 1 byte nel caso del PHY 1M e di 2 byte nel caso del PHY 2M. Il campo MIC è un campo opzionale che si usa solo per le connessioni criptate. Per semplicità, considereremo solo le connessioni non criptate – per il caso criptato, aggiunge semplicemente 4 byte di overhead.

Per i PHY codificati LE, il formato del pacchetto appare così (dalla specifica Bluetooth 5.0 Vol 6, Parte B, Sezione 2.2):

Passi per calcolare il throughput (in Mbps):

Per semplicità, assumiamo quanto segue:

• La crittografia NON è abilitata (il campo MIC non è incluso nel pacchetto)
• Siamo interessati al throughput per una direzione (es. Master to Slave), quindi assumiamo che l’altra direzione trasferisca solo pacchetti vuoti
• Scritte senza risposte (il che aiuterebbe a massimizzare il throughput quando si trasferiscono grandi quantità di dati

Passi:

1. Determinare il PHY usato e annotare il tasso di trasferimento dati grezzi
   E.g. per 1M PHY -> 1 Mbps, per PHY codificato e S=8 -> 125 kbps
2. Determinare il tempo necessario per inviare un pacchetto di dati e il pacchetto vuoto dal ricevitore.
   Il tempo durante il quale un pacchetto di dati può essere inviato includerà quanto segue:

   Data_Packet_Time = Tempo per trasmettere il pacchetto vuoto + IFS + Tempo per trasmettere il pacchetto di dati effettivo + IFS.
   Un tempo di trasmissione di un pacchetto vuoto può essere calcolato come segue:

   Tempo per trasmettere un pacchetto vuoto = dimensione del pacchetto vuoto / velocità dei dati grezzi

   Un pacchetto vuoto conterrà i seguenti campi:

   Preamble + Indirizzo di accesso + LL Header + CRC.

   Per 1M PHY, il Preambolo sarà 1 byte, e così la dimensione totale del pacchetto vuoto = 1 + 4 + 2 + 3 byte = 10 byte = 80 bit.
   (per 2M PHY, la dimensione di un pacchetto vuoto sarà 88 bit poiché il Premable è 2 byte invece di 1 byte).

   In base a questo, il tempo per trasmettere un pacchetto vuoto 1M PHY sarà:

   Tempo per trasmettere un pacchetto vuoto = dimensione pacchetto vuoto / velocità dati grezzi = 80 bit / 1 Megabit al secondo = 80 micro secondi

   Un pacchetto dati conterrà tutti i campi elencati nel diagramma del formato del pacchetto ad eccezione del campo MIC (crittografia disabilitata).

   Tempo di trasmissione del pacchetto dati = dimensione del pacchetto dati / velocità dei dati grezzi

   Se abbiamo DLE abilitato e l’ATT MTU è uguale al massimo di byte permesso in un pacchetto: 247 byte, allora possiamo calcolare la dimensione del pacchetto dati come:

   Dimensione pacchetto dati = 1 + 4 + 2 + 4 + 247 + 3 byte = 265 byte = 265*8 bit = 2088 bit

   Tempo per trasmettere il pacchetto dati = 2088 bit / 1 Mbps = 2,088 micro secondi

   Data_Packet_Time = Tempo per trasmettere il pacchetto vuoto + IFS + Tempo per trasmettere il pacchetto dati effettivo + IFS = 80 + 2*150 + 2088 = 2.468 microsec
   Per confronto, nel caso di 2M PHY, sarebbe:

   Data_Packet_Time = Tempo per trasmettere il pacchetto vuoto + IFS + Tempo per trasmettere il pacchetto dati effettivo + IFS = 88/2 + 2*150 + (2 + 4 + 2 + 4 + 247 + 3)*8/2 = 1.392 microsecs
   Quando DLE è abilitato e l’ATT MTU è impostato a meno di 247, ci ritroviamo con più overhead (poiché ora i dati più grandi dell’ATT MTU vengono suddivisi in più pacchetti). Per esempio, diciamo che abbiamo l’ATT MTU impostato a 158, allora per trasferire 244 byte di dati dell’applicazione, avremo bisogno di due pacchetti invece di uno, causando una diminuzione del throughput a causa dell’aumento dell’overhead dei byte e dell’aumento dell’IFS tra i pacchetti. In un altro scenario, potremmo avere DLE disabilitato (dimensione del carico utile fino a 27 byte) e l’MTU ATT maggiore di 27 byte. Qui, questo risulterà anche in più pacchetti necessari da inviare per la stessa quantità di dati, causando il throughput a scendere.

   Nota: Lo stesso metodo per calcolare le dimensioni dei pacchetti dati e vuoti che abbiamo usato sopra può essere usato per il LE Coded PHY.

3. Capire quanti pacchetti possono essere trasmessi durante un intervallo di connessione
   Questo calcolo non è sempre puramente matematico – è necessario prendere in considerazione le limitazioni dello stack e del dispositivo utilizzato. iOS e Android hanno dei massimi che cambiano con la versione del sistema operativo, quindi non è sempre facile da capire. Detto questo, su un MCU, l’SDK del fornitore di solito elenca il massimo nella loro documentazione. È anche utile fare un tentativo e capire cosa supporta il tuo dispositivo specifico.

   Una volta che hai capito il massimo, puoi calcolare il numero massimo teorico di pacchetti che entrerebbero in un intervallo di connessione a scelta. Per esempio, se avessimo un intervallo di connessione di 7,5 millisec (il più basso permesso dalle specifiche), allora per il nostro esempio sopra (usando 1M PHY, DLE abilitato):

   Massimo # di pacchetti dati per intervallo di connessione = , dove si arrotonda al numero intero più alto (intero)Massimo # di pacchetti dati per intervallo di connessione = = 3 pacchetti

   Di solito, questo numero non è realistico poiché ci sono ritardi di tempo tra i pacchetti che vengono inviati su eventi di connessione consecutivi. Quindi, per il nostro esempio, andremo con 2 pacchetti invece di 3.

4. Una volta che abbiamo capito il numero massimo di pacchetti di dati che possono essere trasferiti per intervallo di connessione, possiamo calcolare il throughput dei dati:Data throughput = dati per intervallo di connessione / intervallo di connessione = No. di pacchetti di dati per intervallo di connessione * Dimensione dei dati per pacchetto / intervallo di connessione
   = 2 * 244 * 8 bit / 7.5 millisec = 520.533 bit/sec ~= 508 kbps

Test e calcolo del throughput dei dati tra due kit di sviluppo nRF52

In questa sezione, eseguiremo diversi test di trasferimento dati, calcoleremo il throughput usando la procedura che abbiamo descritto prima, e poi li confronteremo con il throughput misurato riportato dall’applicazione in esecuzione sulle schede di sviluppo. I test sono eseguiti sulla base dell’applicazione demo fornita da Nordic Semiconductor e presentata in questo post del blog: Throughput and long range demo.

Il codice sorgente per l’esempio può essere trovato alla pagina GitHub qui.

Caso 1 (PHY: 1 Mbps, ATT MTU = 23 byte, DLE: abilitato, Intervallo di connessione: 7,5 millisecondi)

Data throughput riportato dal firmware:

Tempo: 36.11 secondi trascorsi.
Throughput: 232.29 Kbits/s.
Inviato 1048580 bytes di payload ATT.

Calcolato throughput dei dati:

Con l’MTU impostato a 23 bytes, DLE non influenza realmente il throughput dei dati e le dimensioni dei pacchetti.

Tempo per trasmettere il pacchetto dati = dimensione del pacchetto dati / velocità dati grezzi = 1 + 4 + 2 + 4 + 23 + 3 byte / 1 Mbps= 37*8 bit / 1 Mbps = 296 microsec

Data_Packet_Time = Tempo per trasmettere il pacchetto vuoto + IFS + Tempo per trasmettere il pacchetto dati effettivo + IFS = 80 + 150 + 296 + 150 microsec = 676 microsec

Numero massimo di pacchetti dati per intervallo di connessione = = = = 11 pacchetti
Dati totali trasferiti per intervallo di connessione = 11 * 20 byte = 11 * 20 * 8 bit = 1760 bit

Passaggio dati = Dati totali trasferiti per intervallo di connessione / intervallo di connessione = 1760 bit / 7.5 millisecondi = 234,67 Kbits/s
Come possiamo vedere, il valore calcolato e quello misurato sono abbastanza vicini.

Caso 2 (PHY: 2 Mbps, ATT MTU = 23 byte, DLE: abilitato, Intervallo di connessione: 7.5 millisecondi)

Data throughput riportato dal firmware:

Tempo: 27.23 secondi trascorsi.
Throughput: 307.96 Kbits/s.
Inviato 1048580 bytes di ATT payload.

Calcolo del throughput dei dati:

Tempo per trasmettere il pacchetto dati = dimensione del pacchetto dati / velocità dati grezzi = 2 + 4 + 2 + 4 + 23 + 3 byte / 2 Mbps= 38*8 bit / 2 Mbps = 152 microsec

Data_Packet_Time = Tempo per trasmettere il pacchetto vuoto + IFS + Tempo per trasmettere il pacchetto dati effettivo + IFS = 44 + 150 + 152 + 150 microsec = 496 microsecs

Numero massimo di pacchetti dati per intervallo di connessione = = = = 15 pacchetti
Dati totali trasferiti per intervallo di connessione = 15 * 20 byte = 15 * 20 * 8 bit = 2400 bit

Passaggio dati = Dati totali trasferiti per intervallo di connessione / intervallo di connessione = 2400 bit / 7.5 millisecondi = 320 Kbits/s
Come possiamo vedere, il valore calcolato e quello misurato sono abbastanza vicini.

Caso 3 (PHY: 1 Mbps, ATT MTU = 158 byte, DLE: abilitato, Intervallo di connessione: 7.5 millisecondi)

Data throughput riportato dal firmware:

Tempo: 17.53 secondi trascorsi.
Throughput: 478.36 Kbits/s.
Inviato 1048730 bytes di ATT payload.

Passaggio dati calcolato:

Tempo per trasmettere il pacchetto dati = dimensione del pacchetto dati / velocità dati grezzi = 1 + 4 + 2 + 4 + 158 + 3 byte / 1 Mbps= 172*8 bit / 1 Mbps = 1376 microsecs

Data_Packet_Time = Tempo per trasmettere il pacchetto vuoto + IFS + Tempo per trasmettere il pacchetto dati effettivo + IFS = 80 + 150 + 1376 + 150 microsec = 1756 microsecs

Numero massimo di pacchetti dati per intervallo di connessione = = = = 4 pacchetti
Dati totali trasferiti per intervallo di connessione = 4 * 155 byte = 4 * 155 * 8 bit = 4960 bit

Passaggio dati = Dati totali trasferiti per intervallo di connessione / intervallo di connessione = 4960 bit / 7.5 millisecondi = 661,33 Kbits/s

Caso 4 (PHY: 2 Mbps, ATT MTU = 247 byte, DLE: abilitato, intervallo di connessione: 7.5 millisecondi)

Passaggio dati riportato dal firmware:

Tempo: 8.45 secondi trascorsi.
Passaggio: 992.07 Kbits/s.
Inviato 1048712 byte di carico utile ATT.

Passaggio dati calcolato:

Tempo per trasmettere il pacchetto dati = dimensione del pacchetto dati / velocità dati grezzi = 2 + 4 + 2 + 4 + 247 + 3 byte / 2 Mbps= 262*8 bit / 2 Mbps = 1048 microsecs

Data_Packet_Time = Tempo per trasmettere il pacchetto vuoto + IFS + Tempo per trasmettere il pacchetto dati effettivo + IFS = 44 + 150 + 1048 + 150 microsec = 1392 microsec

Numero massimo di pacchetti dati per intervallo di connessione = = = = 5 pacchetti
Dati totali trasferiti per intervallo di connessione = 5 * 244 byte = 5 * 244 * 8 bit = 9760 bit

Passaggio dati = Dati totali trasferiti per intervallo di connessione / intervallo di connessione = 9760 bit / 7.5 millisecondi = 1301.33 Kbits/s

Nota: Negli ultimi due casi, il numero di pacchetti per intervallo di connessione è piccolo e qualsiasi differenza tra quello che calcoliamo e quello che viene misurato avrà un grande impatto sul throughput di dati effettivo. Per esempio, se il numero di pacchetti per intervallo di connessione finisce per essere 4 invece di 5 nel caso 4, il throughput calcolato diventa 1.041,1 Kbps invece di 1.301,33 Kbps (che è una grande differenza e potrebbe spiegare la discrepanza nei numeri qui).

Caso 5 (PHY: 2 Mbps, ATT MTU = 247 byte, DLE: abilitato, intervallo di connessione: 50 millisecondi)

Passaggio dati riportato dal firmware:

Tempo: 6.34 secondi trascorsi.
Passaggio: 1322.33 Kbits/s.
Inviato 1048712 bytes di ATT payload.

Passaggio dati calcolato:

Tempo per trasmettere il pacchetto dati = dimensione del pacchetto dati / velocità dati grezzi = 2 + 4 + 2 + 4 + 247 + 3 byte / 2 Mbps= 262*8 bit / 2 Mbps = 1048 microsec

Tempo_Pacchetto_Dati = Tempo per trasmettere il pacchetto vuoto + IFS + Tempo per trasmettere il pacchetto dati effettivo + IFS = 44 + 150 + 1048 + 150 microsec = 1392 microsec

Numero massimo di pacchetti dati per intervallo di connessione = = = 35 pacchetti

Dati totali trasferiti per intervallo di connessione = 36 * 244 byte = 35 * 244 * 8 bit = 68320 bit

Passaggio dati = Dati totali trasferiti per intervallo di connessione/intervallo di connessione = 70272 bit / 50 millisecondi = 1366.4 Kbits/s

Caso 6 (PHY: 2 Mbps, ATT MTU = 247 byte, DLE: abilitato, intervallo di connessione: 400 millisecondi)

Passaggio dati riportato dal firmware:

Tempo: 6.11 secondi trascorsi.
Passaggio: 1371.82 Kbits/s.
Inviato 1048712 byte di carico utile ATT.

Passaggio dati calcolato:

Tempo per trasmettere il pacchetto dati = dimensione pacchetto dati / velocità dati grezzi = 2 + 4 + 2 + 4 + 247 + 3 byte / 2 Mbps= 262*8 bit / 2 Mbps = 1048 microsec

Tempo_Pacchetto_Dati = Tempo per trasmettere il pacchetto vuoto + IFS + Tempo per trasmettere il pacchetto dati effettivo + IFS = 44 + 150 + 1048 + 150 microsec = 1392 microsec

Numero massimo di pacchetti dati per intervallo di connessione = = = = 287 pacchetti

Dati totali trasferiti per intervallo di connessione = 287 * 244 byte = 287 * 244 * 8 bit = 560224 bit

Passaggio dati = Dati totali trasferiti per intervallo di connessione/intervallo di connessione =560224 bit / 400 millisecondi = 1400.56 Kbits/s

Ottimizzazione per il massimo throughput di dati

In base ai fattori che abbiamo esaminato, possiamo notare quanto segue quando si ottimizza per un alto throughput di dati:

• Abilita sempre DLE
  Ovviamente, se stai usando Bluetooth v4.1 o precedente, questa non è una valida opzione. In generale, comunque, assicurati di aver abilitato DLE per massimizzare il tuo pacchetto all’efficienza dei dati dell’applicazione
• Usa LE 2M PHY
  Se sai che i dispositivi su entrambe le estremità supportano Bluetooth 5, allora utilizzare LE 2M PHY è uno dei modi migliori per massimizzare il throughput dei dati dell’applicazione. Usare il LE 2M PHY aiuterà anche a ridurre il consumo di energia, così si prendono due piccioni con una fava!
• Utilizzare le Notifiche e le Scritte senza Risposte
  Utilizzare queste aiuterà a rimuovere qualsiasi pacchetto inutile che viene trasmesso (rispetto alle Indicazioni e alle Scritte normali che richiedono che l’estremità ricevente riconosca ogni pacchetto ricevuto).
• Scegli un valore ATT MTU almeno maggiore di 247 byte
  Questo minimizzerà qualsiasi overhead in byte di pacchetto.
• Scegli un intervallo di connessione che permetta il massimo numero di pacchetti per intervallo di connessione
  Ma tieni presente che l’intervallo di connessione influenza il consumo di energia. Più breve è l’intervallo, più energia consumerà il tuo dispositivo a causa dell’aumento del tempo di accensione della radio. Dovete anche assicurarvi di non scegliere un intervallo troppo alto, altrimenti comprometterà l’esperienza dell’utente (un intervallo di connessione più alto comporta una maggiore latenza). Un’ultima cosa di cui assicurarsi di tenere conto sono le eventuali limitazioni dei dispositivi nel tuo sistema in termini di numero massimo di pacchetti per intervallo di connessione supportato.

Sommario & chiusura

I valori calcolati che abbiamo elencato sopra sono ancora teorici e potrebbero non allinearsi con il throughput dei dati misurato nella pratica e negli ambienti reali, ma sono comunque un buon punto di partenza e danno una buona indicazione di cosa aspettarsi (almeno per un massimo). Anche le interferenze e gli errori di trasmissione/ricezione influenzano il throughput dei dati (i tentativi, la perdita di dati e gli eventi di chiusura della connessione comportano un throughput inferiore). Questi possono essere causati dalla presenza di altri dispositivi che utilizzano la stessa banda a 2,4 GHz del Bluetooth, da una distanza maggiore tra i dispositivi, dall’esistenza di ostacoli tra i dispositivi, e altro ancora…

.