- La technologie de communication NB-IoT a été conçue afin que les appareils connectées puissent transmettre des informations sur une longue portée avec une faible consommation d’énergie.
- Anritsu explique dans cet article, comment est déterminé le débit maximal de données et présente comment mesurer le débit montant pendant le test d’un modem NB-IoT.
Le standard NB-IoT a été développé par le groupement 3GPP pour permettre la connexion sans fil de quelques milliards d’appareils et capteurs qui devraient dans un avenir proche être exploités par les villes intelligentes ainsi que aux seins des habitations et des bureaux connectés. Par rapport aux standards de communication sans fil existants, le NB-IoT a été conçu pour répondre à certaines exigences telles qu’une consommation plus faible, une meilleure portée et des déploiements plus denses, correspondant aux besoins des appareils tels que les compteurs intelligents, les petits modules et capteurs qui envoient et reçoivent uniquement des petites quantités de données, de l’ordre de quelques octets, à une fréquence de répétition faible dans une journée.
Avant de choisir la technologie NB-IoT pour un appareil ou un service, il convient de comprendre ce que sont les débits de données typiques qui peuvent être atteints et leur variabilité afin d’optimiser au mieux les applications et services pouvant être déployés autour des appareils NB-IoT. Il peut également s’avérer utile de pouvoir effectuer des opérations telles que la maintenance ou les mises à jour logicielles à distance, ce qui exige des débits de données plus importants par rapport aux débits de fonctionnement habituels.
La plupart des chiffres relatifs aux débits de données NB-IoT annoncent des débits maximaux de l’ordre de 200 kbit/s en liaison descendante (Downlink) et de 250 kbit/s en liaison montante (Uplink). Avec cette désignation de « débit maximal », on comprend que ce débit n’est pas celui que les appareils affichent habituellement, et c’est effectivement le cas.
Dans cet article, nous étudierons comment le débit maximal de données est déterminé et nous expliquerons également pourquoi certains appareils (Release 13, catégorie NB1) ne pourront pas atteindre ces débits maximum de données. En réalité, le débit de données a plutôt tendance à être 10 fois moindre que ces débits maximum, du fait notamment de l’ordonnancement des données, de la prise en charge d’un seul processus HARQ et de la surcharge des entêtes RLC/MAC. Pour les appareils fonctionnant à l’extrême périphérie de la couverture réseau, les débits de données seront d’autant plus réduits, à cause de l’utilisation de valeurs d’espacement de sous porteuses plus réduites en Uplink (3,75 kHz) et de la nécessité des répétitions de l’envoi des données.
Débits maximum de données NB-IoT
Lorsqu’un appareil NB-IoT est à l’état connecté, la transmission des données de l’utilisateur en Downlink s’effectue sur le canal NPDSCH (Narrow Band Physical Downlink Shared Channel) et en Uplink sur le canal NPUSCH (Narrow Band Physical Uplink Shared Channel). Le terminal doit d’abord décoder les messages DCI (Dedicated Control Information) contenant les informations de contrôle dédiées envoyées sur le canal NDPCCH (Narrow Band Physical Uplink Control Channel) afin de déterminer quand et comment la transmission de données doit être ordonnancée.
Selon la quantité de données à envoyer, les ressources réseau disponibles et les conditions radio, la taille du bloc de transport (TBS) peut varier. Prenons d’abord le sens descendant et supposons que l’allocation maximale est affectée à l’équipement utilisateur (UE), les données peuvent être transmises en utilisant la taille de bloc de transport maximale de 680 bits, constituée de 3 sous-trames au minimum (sachant qu’une sous-trame NB-IoT a une durée de 1 ms). L’information relative à la taille du bloc de transport peut être déterminée à partir des tableaux 16.4.1.3-1 et 16.4.1.5.1-1 du 3GPP 36.213. Rien qu’en prenant en compte ces 3 ms de transmission, le débit de données serait de 680/3 ms = 226 Kbit/s, proche du débit maximal de données descendant de 200 Kbit/s mentionné ci-dessus.
Dans le sens montant, la taille de bloc de transport maximale est de 1000 bits et peut être transmise dans le meilleur des cas en utilisant quatre unités de ressource. Une unité de ressources est l’unité minimale de transmission sur la voie montante utilisée en NB-IoT. Elle est constituée d’un certain nombre de sous-porteuses pendant un intervalle de temps mesuré (le temps, dans ce cas, est mesuré en nombre de « Time Slots », avec une sous-trame composée de 2 slots). Selon le référentiel 36.213, tableaux 16.5.1.2-2 et 6.5.1.1-2, et le référentiel 36.211, tableau 10.1.2.3-1, en utilisant le Format 1 NPUSCH pour le transfert de données et un espacement de sous-porteuses de 15 kHz, la meilleure allocation d’unités de ressources (ou RU, Ressources Units) de 12 sous-porteuses donne une transmission sur 2 slots. Comme il faut 4 RU pour envoyer 1000 bits, on obtient une transmission sur 8 slots (ou 4 sous-trames), ce qui donne un débit maximal de données de 1000/4 ms=250 Kbit/s à la couche physique.
Débits de données NB-IoT typiques
Les explications ci-dessus confirment que la couche physique NB-IoT est capable de débits maximum de données instantanés de 226 Kbit/s en liaison descendante, contre 250 Kbit/s en liaison montante. Cependant, les débits de données constants seront plutôt 10 fois inférieurs en raison de plusieurs facteurs.
Tout d’abord, le protocole ne permet pas d’ordonnancer de nouvelles données dans des sous-trames consécutives, et comme il n’y a qu’une seule procédure HARQ (Hybrid Automatic Repeat Request), la réception des données doit d’abord être confirmée par le destinataire avant que le bloc de transport suivant soit ordonnancé (bien que l’accusé de réception soit optionnel en liaison descendante et contrôlé par le réseau).
Par ailleurs, et de façon très significative, afin d’augmenter grandement le bilan de liaison de 20 dB par rapport aux technologies cellulaires existantes (par ex. GPRS) et permettre une couverture plus étendue, le protocole NB-IoT utilise la répétition de données. Les canaux NPDCCH, NPDSCH et NPUSCH peuvent être configurés pour répéter les transmissions dans des sous-trames consécutives. Par exemple, les blocs de transport en liaison descendante (DL) portés par le canal NPDSCH peuvent être répétés jusqu’à 2048 fois et jusqu’à 128 fois pour le NPUSCH.
Ainsi, quels sont les débits de données constants typiques qui pourraient être atteints si aucune répétition n’avait été configurée ? La figure 1 présente essentiellement l’ordonnancement des données en liaison descendante.
Les informations de contrôle de la voie descendante (DCI) occupent une sous-trame, mais comme le montre le figure 1, elles peuvent être répétées à de nombreuses reprises dans des sous-trames consécutives (possibilité de configurer jusqu’à 2048 répétitions). Le délai entre la réception du message DCI et du NPDSCH s’étend sur un minimum de 4 sous-trames, mais les informations DCI indiqueront si un délai d’ordonnancement doit également être appliqué, à ajouter à ces 4 sous-trames. Une fois le NPDSCH reçu, le terminal (si pris en charge par le réseau) accuse réception du bloc de transport descendant à l’aide de NPUSCH (en utilisant le Format 2 NPUSCH). L’accusé de réception (ACK) arrivera au moins 12 sous-trames plus tard, occupant 4 slots, mais tout comme pour les autres transmissions, il pourra être répété sur des slots consécutifs si le réseau a indiqué au terminal de le faire.
En supposant que le NPDCCH et que l’accusé de réception sont répétés deux fois et qu’aucun délai d’ordonnancement n’est configuré par le réseau pour la réception du NPDSCH ou de la transmission ACK, le temps nécessaire pour décoder le message DCI et le bloc de transport de 680 bits, puis pour envoyer l’accusé de réception, serait de 25 ms.
Si ce schéma est répété de façon continue, on obtiendrait un débit de données constant de 27 kbit/s (680/25 ms).
Cependant, même si ce débit de données est improbable en raison de l’ordonnancement du NPDCCH (qui devra nécessairement « tomber » en même temps que certaines sous-trames pour correspondre à l’espace de recherche spécifique de l’UE), en ignorant les sous-trames utilisées pour la transmission SIB (System Information Block) et en raison de la nature Half Duplex du standard, cela permettra à l’UE d’avoir le temps de commuter entre la transmission UL et la réception DL. Il y aura ensuite évidemment d’autres appareils pour lesquels le réseau devra planifier des ressources, et donc les informations DCI ne seront pas toujours destinées à l’appareil concerné et le réseau spécifiera un délai de programmation afin d’entrelacer les transmissions NPDSCH destinées à différents équipements.
Dans le sens montant, la situation est similaire, mise à part que le délai entre la réception du message DCI et la transmission NPUSCH comporte au moins 8 trames. Le temps entre la transmission NPUSCH et l’envoi de l’accusé de réception du réseau pour le bloc de transport est d’au moins 3 ms.
Si on suppose que le NPDCCH est répété deux fois mais qu’il n’y a qu’une seule transmission du bloc de transport (100 bits) sur NPUSCH, la durée totale de la transmission ascendante devrait être de 19 ms, pour un débit de données constant de 52 kbit/s (1000/19 ms).
Une fois encore, tout comme pour le sens descendant, ces calculs ne prennent pas en compte l’ordonnancement des autres services, ni la nécessité d’éviter les transmissions SIB. Ils supposent également que le terminal est doté d’une relativement bonne couverture et que la configuration NPUSCH la plus efficace utilisant des sous-porteuses 15 kHz est utilisée pour la transmission.
L’importance des tests
Pour comprendre comment un module utilisant la norme NB-IoT se comporte dans des conditions variables, il est important de le tester en laboratoire sur un simulateur de station de base.
L’utilisation d’un réseau réel pour les tests, bien qu’ayant aussi son importance, peut en effet occulter de nombreux problèmes.
Un simulateur de station de base tel que l’analyseur de communications radios MT8821C d’Anritsu offre la flexibilité de modifier l’allocation des données fournies au terminal. La répétition, la taille du bloc de transport et l’espacement des sous-porteuses constituent certains des paramètres qui peuvent être contrôlés pour faire varier les conditions des débits de données que le terminal pourrait rencontrer sur le terrain.
La figure 4 montre une mesure de débit montant pendant le test d’un modem NB-IoT. Le résultat, comme l’on peut s’y attendre, est de 37 kbit/s, plus faible que la valeur idéale calculée précédemment.
Si les répétitions sont appliquées à la transmission NPUSCH (simple changement de paramètre), comme illustré sur la figure 5, de sorte que les données montantes sont répétées 32 fois, l’impact sur le débit de données est clairement visible.
Les tests effectués dans différentes conditions garantiront que toute application se comportera comme prévu, y compris si l’appareil est opérationnel à l’extrême périphérie de la couverture réseau ou dans un scénario de déploiement dense, où les débits de données pourraient être de l’ordre de quelques bits par seconde, au lieu de plusieurs kilo-bits par seconde.
Références
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 procedures
3GPP TS 36.211 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and modulation
