Determinazione della velocità di trasferimento dati di picco per NB-IoT

Lo standard NB-IoT è stato sviluppato da 3GPP per fornire connettività wireless ai miliardi di dispositivi e sensori previsti che popoleranno le città, case e aziende intelligenti del futuro.  Rispetto agli attuali standard cellulari, NB-IoT è stato progettato per soddisfare i requisiti di basso consumo energetico, maggiore portata, e dense distribuzioni di dispositivi come contatori, attuatori e sensori che sporadicamente inviano e ricevono soltanto piccole quantità di dati, nell’ordine di pochi byte.

Quando si considera l’adozione della tecnologia NB-IoT per un dispositivo o un servizio, è importante comprendere quali siano le velocità dati tipiche che potranno essere raggiunte, e quali le variabili al fine di ottenere la migliore ottimizzazione delle applicazioni e servizi che possono essere distribuiti attorno ai dispositivi NB-IoT. Potrebbe anche essere utile tenere in considerazione servizi quali la manutenzione da remoto dei dispositivi o gli aggiornamenti del software, che potrebbero richiedere velocità di trasmissione dati più elevate rispetto a quelle disponibili nel normale funzionamento aziendale.

La maggior parte dei valori relativi alla velocità dati di NB-IoT fanno riferimento a velocità di “picco” nell’intervallo di 200 Kbps  nel downlink e 250 kbps per l’uplink. Il fatto che siano indicati come di “picco” suggerisce che questi non siano i valori che un dispositivo possa effettivamente sperimentare, e questo ne è il caso in esame.

In questo articolo, osserveremo come viene determinata la velocità di trasmissione dati di picco ma cercheremo anche di spiegare perché i dispositivi (release 13 Categoria NB1 dispositivi) non saranno in grado di sostenere questi picchi di velocità dati. E’ più probabile infatti che questa risulti inferiore di un fattore 10 a causa di motivi come la scheduling dati, il supporto per un unico processo HARQ e il sovraccarico di header  RLC/MAC.  Per i dispositivi che operano ai margini della copertura delle celle, le velocità dati saranno ulteriormente ridotte a causa della ridotta spaziatura delle sottoportanti in uplink (3,75 KHz) e della necessità di ripetizioni dati.

Velocità dati di picco per NB-IoT

Quando un dispositivo NB-IoT è in uno stato di connessione, la trasmissione dati utente in downlink si verificherà sulla Narrow Band Physical Downlink Shared Channel (NPDSCH)  e in uplink su Narrow Band Physical Uplink Shared channel (NPUSCH). L’UE deve in primo luogo decodificare le Dedicated Control Information  (DCI) inviate sulla Narrow Band Downlink Physical Control Channel (NDPCCH)  al fine di stabilire come e quando la trasmissione dati deve essere pianificata.

Le dimensioni del blocco di trasporto variano a seconda della quantità di dati da inviare, delle risorse di rete disponibili e delle condizioni radio. Considerando la direzione di downlink in primo luogo e supponendo che l’allocazione massima sia data alla UE, i dati potranno essere trasmessi utilizzando una dimensione massima del blocco di trasporto di 680 bit ovvero un minimo di 3 subframe (dove un subframe NB-IoT ha una durata di 1ms).  Queste informazioni di dimensione del blocco di trasporto possono essere determinati da 3GPP 36,213 tabelle 16.4.1.3 1 e 16.4.1.5.1-1.  Solo considerando questi 3ms di trasmissione la velocità dati sarebbe 680/3ms = 226kbs, in prossimità dei 200 kbps di velocità dati massima in downlink menzionati sopra.

Nella direzione di uplink, la dimensione del blocco di trasporto massimo è 1000 bit e potrebbe essere trasmesso nel migliore dei casi utilizzando 4 unità di risorsa. Un’unità di risorsa è l’unità di trasmissione minima uplink utilizzata in NB-IoT ed è formata da un numero di sottoportanti per un periodo di tempo misurato (in questo caso misurato negli slot, e dove un subframe è costituito da 2 slot).  Facendo riferimento a 36.213, Tabelle 16.5.1.2-2 e 6.5.1.1-2, e 36.211 Tabella 10.1.2.3-1, utilizzando il formato 1 NPUSCH  per il trasferimento dei dati e la spaziatura delle sottoportanti a 15 kHz, l’allocazione ottimale delle unità di risorse di 12 sottoportanti determina una trasmissione su 2 slot . Poiché sono necessarie  4 RU per inviare 1000 bit, ciò comporterebbe una trasmissione su 8 slot (o 4 subframe) che fornisce una velocità di dati di picco di 1000/4ms = 250kbs al physical layer.

Velocità di trasmissione dati tipica per NB-IoT

La spiegazione sopra riportata conferma che il physical layer  NB-IoT è in grado di raggiungere velocità di trasmissione istantanee dei dati di 226 Kbps nella direzione del downlink e al contempo fino a 250kbps in uplink, tuttavia le velocità di trasmissione effettivamente sostenute saranno probabilmente inferiori e di un fattore 10, a causa di diverse ragioni.

In primo luogo, il protocollo non permette che nuovi dati siano programmati in subframe consecutivi e dato che c’è un unico processo HARQ (Hybrid Automatic Repeat Request), i dati in primo luogo devono essere riconosciuti dal destinatario prima che il blocco di trasporto successivo sia pianificato ( sebbene questo riconoscimento sia facoltativo in downlink e sotto il controllo della rete).

Inoltre, in modo molto significativo, al fine di aumentare notevolmente il budget di collegamento di 20dB rispetto alle tecnologie cellulari esistenti (ad esempio GPRS) permettendo una più estesa copertura, il protocollo NB-IoT impiega la ripetizione di dati. I canali NPDCCH, NPDSCH e NPUSCH possono essere configurati per ripetere le trasmissioni in subframe consecutivi. Per esempio, blocchi di trasporto DL trasportati dalla NPDSCH possono essere ripetuti fino a 2048 volte e viceversa 128 volte per la NPUSCH.

Quindi, qual è la reale velocità di trasmissione dati sostenuta, che potrebbe essere raggiunta se non fossero state configurate ripetizioni? Nella sostanza, il timing dei dati di downlink è dettagliato in figura 1.

Figura 1: Scheduling della trasmissione in Downlink

Il Downlink Control Information (DCI) occuperà 1 subframe ma, come mostrato Figura 1, è destinata a ripetersi più volte in subframe consecutivi (ne sono configurabili fino a 2048). Il ritardo tra la ricezione NPDSCH e DCI è costituito da un minimo di 4 subframe, ma le informazioni di DCI indicheranno se debba essere applicato anche un ritardo di scheduling, il che consterebbe di una aggiunta di ulteriori 4 subframe.  A seguito della ricezione del NPDSCH, UE (se richiesto dalla rete) riconosce la ricezione del blocco di trasporto di downlink utilizzando NPUSCH (NPUSCH Format 2). L’ACK sarà successivo di almeno 12 subframe, richiedendo 4 slot ma, analogamente ad altre trasmissioni, potrebbero essere ripetute in slot consecutivi se la rete ha indicato all’UE di farlo.

Supponendo che NPDCCH e riconoscimento siano ripetuti due volte e nessun ritardo di scheduling sia configurato dalla rete per ricezione NPDSCH o trasmissione ACK, il tempo di decodifica di DCI e blocco di trasporto 680-bit , e il successivo invio del riconoscimento sarebbe di 25ms.

Se venisse ripetuto continuamente, si otterrebbe una velocità dati sostenuta di 27 kbps (680/25 ms).

Tuttavia anche questa velocità dati è improbabile a causa dello scheduling del NPDCCH (che sarà necessario al fine di rientrare in un certo numero di subframe per soddisfare lo spazio Specific Search UE), ignorando i subframe utilizzati per la trasmissione SIB e a causa della natura Half Duplex dello standard, viene consentita la commutazione del tempo UE tra trasmissione uplink e ricezione downlink.  Quindi, come è ovvio, ci saranno altri dispositivi per i quali la rete dovrà pianificare le risorse, quindi il DCI non sarà sempre per il dispositivo in questione e NW specificherà un ritardo di scheduling per inserire le trasmissioni NPDSCH destinate ai diversi dispositivi.

Figura 2: Scheduling della trasmissione in Uplink 

Nella direzione uplink, la situazione è simile, ad eccezione del ritardo tra ricezione DCI e trasmissione NPUSCH che è di almeno 8 frame. Il timing tra NPUSCH e riconoscimento della rete di ricezione del blocco di trasporto è di almeno 3ms.

Supponendo che NPDCCH venga ripetuto due volte, ma con un’unica trasmissione singola del blocco di trasporto (1000 bit) su NPUSCH, il tempo complessivo della trasmissione uplink sarebbe di 19ms, fornendo così una velocità di trasmissione dati sostenuta di 52kbs (1000/19ms).

Ancora una volta, per quanto riguarda la direzione di downlink , non viene presa in considerazione la programmazione di altri dispositivi e la necessità di evitare le trasmissioni SIB. Si presuppone inoltre che l’UE abbia ragionevolmente una buona copertura e venga utilizzata la configurazione di NPUSCH più efficiente mediante sottoportanti da 15 KHz per la trasmissione.

L’Importanza dei Test

Per comprendere come un modulo che utilizzi NB-IoT si comporti in condizioni di rete variabili, è importante testare in laboratorio con un simulatore di stazione radio base. Utilizzare una rete reale per il test, sebbene sia anche questo importante, potrebbe tuttavia mascherare molti dei problemi.

Figura 3: MT8821C Radio Communications Analyser di  Anritsu

Un simulatore di stazione radio base come l’MT8821C Radio Communications Analyser di Anritsu fornisce la flessibilità necessaria per modificare l’allocazione di dati fornita alla UE. Ripetizione, dimensione del blocco di trasporto e spaziatura delle sottoportanti sono alcune delle impostazioni che possono essere controllate per variare le condizioni di velocità dati che un UE potrebbe realmente sperimentare nel campo.

La figura 4 mostra una misura del throughput effettivo in uplink durante il test di un modem NB-IoT. Il risultato di 37kbps come previsto risulta essere inferiore al valore “ideale” precedentemente calcolato.

Figura 4: Misura del Throughput Uplink  su rete  NB-IoT simulata

Se le ripetizioni vengono poi applicate alla trasmissione NPUSCH (una semplice variazione dei parametri), come si può vedere nella Figura 5, in modo tale che i dati di collegamento in uplink vengano ripetuti 32 volte l’impatto sulla velocità di trasmissione dati può essere visto chiaramente.

Figura 5: Misura del Throughput con ripetizioni Uplink abilitate

Il test delle varie condizioni assicurerà che qualsiasi applicazione si comporti come previsto, anche quando il dispositivo funziona ai margini della copertura delle celle o in uno scenario di densa distribuzione in cui le velocità dei dati potrebbero essere in bit per secondo anziché kilobit al secondo.

Riferimenti

3GPP TS 36.331 Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol Specification
3GPP TS 36.213 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures3GPP TS 36.211 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and modulation

A cura di Anritsu EMEA Ltd