Comme énoncé précédemment, nous nous basons sur le système GSM et le standard EC-GSM-IoT, pour réaliser cette implémentation. Néanmoins, à cause de certaines limitations techniques et pour faciliter la réalisation des expérimentations, nous prenons quelques libertés vis à vis de la norme. Notre travail se basant sur les spécifications techniques du 3GPP TS 45.002 à TS 45.005, décrivant les couches basses des standards 2G dont EC-GSM-IoT, nous invitons les lecteurs intéressés par une description conforme des standards à les consulter.
La Fig. 5.4 décrit le groupement de 10 trames TDMA qui est transmis en continu par la BTS. Nous nous affranchissons donc des formats de multitrame usuels1. La répétition de cet ensemble permet d’obtenir une périodicité parfaite pour chaque canal logique, notamment pour la voie balise, ce qui n’est pas le cas dans le système GSM, à cause du format particulier de la 51-multitrame. Les bursts et les séquences binaires qu’ils contiennent, sont donc répétés en boucle, nous permettant par la suite de mesurer facilement les performances en termes de BER et BLER.
Figure 5.4 – L’ensemble des 10 trames TDMA répétées par la carte émettrice. La notation “TS” signifie Time Slot, et représente les slots temporels contenant les bursts de données. Les bursts notés “DB” sont des Dummy Bursts.
La durée des slots a également été adaptée. Dans le cadre de notre expérimentation, chaque slot correspond à une durée de 156 bits, soit 577.48 µs à 270 kbps, au lieu de corres-pondre à une durée de 156.25 bits, soit 577 µs à 270.83 kbps dans la norme GSM/GPRS. Dans le standard EC-GSM-IoT, la durée des slots a aussi été ramenée à des valeurs entières. En effet, tous les slots numérotés 0 et 3 doivent contenir 157 bits, et une durée équivalente à 156 bits a été spécifiée pour les autres slots. C’est à chaque fois la durée de la période de garde après chaque burst qui est affectée, les bursts contenant toujours 148 bits. Ainsi, une trame TDMA a une durée identique entre les standards GSM/GPRS et EC-GSM-IoT, correspondant à un total de 1250 bits. Dans notre cas, la durée d’une trame TDMA ne correspondra qu’à 1248 bits, mais ce choix facilite le traitement des données, notamment dans le cadre des recombinaisons à effectuer.
La chaîne d’émission générale que nous utilisons est présentée Fig. 5.5. Elle correspond
1. Pour rappel, il existe deux formats de multitrame GSM, une avec 26 trames TDMA (26-multitrame) et l’autre avec 51 trames TDMA (51-multitrame). La multitrame GPRS est elle composée de 52 trames TDMA.
à une chaîne d’émission classique GSM/GPRS, et a déjà été employée dans les chapitres 3 et 4 (voir Fig. 3.4). Pour l’étape de codage de canal, on retrouve donc le code convolutif à 16 états et de rendement 1
2, ainsi qu’un processus d’entrelacement. Puis, après un mapping sur une constellation BPSK et un décodage différentiel, les symboles sont transmis au mo-dulateur GMSK. En l’occurrence, nous employons l’objet MATLAB GMSKModulator pour réaliser cette modulation. Les échantillons en sortie du modulateur sont ensuite envoyés à la carte radio via USB. Suivant le type de canal logique considéré, certains processus de la chaîne d’émission ne seront pas appliqués.
Figure 5.5 – Schéma de la chaîne d’émission générale utilisée.
On pourra aussi noter le fait que la phase du modulateur GMSK employé est remise à son état initial au début de chaque burst. De cette façon, les bursts contenant les mêmes bits contiendront également les mêmes symboles GMSK. Dans la norme, la valeur de la phase initiale du modulateur GMSK n’est pas spécifiée, de même qu’aucune réinitialisation au début de chaque burst n’est requise. Ceci pose un inconvénient dans le cadre de EC-GSM-IoT, car une recombinaison de type IQ efficace nécessite d’avoir des symboles complexes de phases identiques (comme déjà observé dans les précédents chapitres). Or, il est impossible pour le récepteur de connaître le déphasage initial entre deux bursts différents, sauf si ces bursts sont émis dans des slots consécutifs. C’est pourquoi le standard EC-GSM-IoT utilise la possibilité introduite dans le standard GPRS d’émettre sur 4 slots consécutifs. Les bursts transmis sur ces slots pourront, par la suite, être recombinés par le mécanisme IQ. Les répétitions effectuées sur des trames TDMA différentes ou simplement sur des slots non contigus doivent être recombinées en utilisant d’autres mécanismes de recombinaison. En réinitialisant la phase du modulateur, nous nous affranchissons de cette contrainte et pouvons plus facilement comparer les performances obtenues par les différents schémas de recombinaison.
5.2.1 Les canaux GSM
Différents bursts issus du standard GSM sont émis sur l’ensemble des 10 trames TDMA. Les bursts de synchronisation SCH et de contrôle BCCH étant émis, mais non utilisés, nous ne les détaillerons pas ici. Par abus de langage, nous étendrons parfois le nom du canal logique au nom du burst qu’il transporte. Par exemple, on pourra nommer “burst SCH” le burst porté par le canal SCH.
Parlons tout d’abord du burst dédié à la synchronisation fréquentielle et transporté par le canal FCCH. Le format utilisé est décrit sur la Fig. 5.6. Ce burst est constitué de 148 bits à “0”, et d’une période de garde d’une durée de 8 bits. Pour rappel, à cause des spécificités de la modulation (G)MSK et de la composition du burst FCCH, ce dernier se comporte dans le plan fréquentiel comme une sinusoïde pure de fréquence fc + 4T1
S, avec fc la fréquence porteuse et TS la durée d’un symbole. Originellement, le décalage en fréquence était de 67.7 kHz, mais comme nous avons modifié le débit symbole, le nouveau décalage est de 67.5 kHz. La norme EC-GSM-IoT emploie le canal FCCH disponible sur les canaux GSM/GPRS et ne définit donc pas de burst ou de mapping spécifique. Le burst
FCCH employé est donc très proche de la norme, mais son mapping diffère. En effet, le burst FCCH est normalement émis sur le slot 0 (voie balise de GSM/GPRS), aux trames TDMA 1, 11, 21, 31 et 41 de chaque 51-multitrame. Il y a donc une certaine rupture de la périodicité dans l’apparition du canal FCCH. Dans notre implémentation, le canal FCCH apparaît périodiquement toutes les 10 trames TDMA, facilitant le traitement en réception.
Figure 5.6 – Le burst FCCH envoyé.
Le second burst issu de la norme GSM/GPRS est le Dummy Burst ou DB sur la Fig. 5.4. La BTS devant émettre en continu sur l’ensemble des slots, le Dummy Burst a été conçu pour être émis lorsque la BTS n’a pas d’informations spécifiques à envoyer. Il est constitué des 6 bits de queue usuels (3 au début et 3 à la fin du burst), et d’une séquence de 142 bits prédéterminée. Aucune opération n’est effectuée sur ces bursts en réception.
5.2.2 Le canal EC-SCH
Le canal EC-SCH est l’équivalent du canal logique SCH pour le standard EC-GSM-IoT. Son rôle est donc de fournir une synchronisation temporelle globale et fine à l’objet. La Fig. 5.7 décrit la composition du burst EC-SCH utilisé dans le cadre de l’implémentation. Il se base sur le format d’un burst de synchronisation, également utilisé par le SCH. La séquence d’apprentissage étendue permet de détecter le burst, ainsi que d’effectuer une synchronisation temporelle fine. Le récepteur peut ensuite réaliser un sous-échantillonnage au débit symbole, et démoduler les informations contenues dans le burst EC-SCH. Ces informations sont destinées, entre autres, à la synchronisation globale du récepteur, qui peut alors déterminer le numéro de la multitrame. Dans le cadre de notre implémentation, nous utilisons la séquence d’apprentissage étendue définie dans la norme, mais nous ne fournissons aucune information de synchronisation globale au sein du burst. La séquence de données binaires est identique pour tous les bursts EC-SCH, nous permettant ainsi de facilement réaliser tout type de recombinaison et de calculer les performances en termes de BER. Par ailleurs, 4 bits de padding de valeur 0 sont ajoutés à la suite de la séquence d’information de 35 bits, afin de “fermer” le treillis du codeur convolutif, et forcer ainsi l’état final à 0 à la fin de la transmission de la séquence. Cette séquence est par la suite encodée, pour obtenir en sortie un total de 78 bits, ne subissant pas le processus d’entrelacement (conformément à la norme ici). Finalement, la séquence est transmise au processus de mapping BPSK, puis au décodeur différentiel, et enfin au modulateur GMSK, avant d’être émise.
Dans la spécification, le canal EC-SCH est toujours mappé sur le slot 1, la voie balise de EC-GSM-IoT. Chaque burst EC-SCH est répété un total de 28 fois, réparties sur quatre 51-multitrames. Au sein de chacune des 51-multitrames, le burst est répété sur 7 trames TDMA successives, en partant toujours de la première trame TDMA de la multitrame. Le nombre de répétitions à recombiner dépend de la classe de couverture de l’objet. Nous nous sommes détachés de ce mapping, pour avoir plus de liberté vis à vis du mécanisme de
Figure 5.7 – Le burst EC-SCH transmis.
recombinaison à étudier, mais nous avons conservé la position du canal EC-SCH sur le slot 1. Concernant le nombre de répétitions, notre burst EC-SCH est répété à chaque trame TDMA, comme présenté Fig. 5.4.
5.2.3 Le canal EC-PDTCH
Dans le cadre du standard EC-GSM-IoT, c’est le canal EC-PDTCH qui est chargé de transporter les données utiles en voie montante et descendante, en référence au canal PDTCH du standard GPRS. Le burst utilisé est un burst normal, la Fig. 5.8 décrivant le modèle que nous utilisons pour l’implémentation. Il existe plusieurs séquences d’apprentis-sage disponibles. En l’occurrence, nous utiliserons toujours la séquence correspondant au TSC (Training Sequence Code) 0 du set 1 (voir tableau 5.2.3a du TS 45.002). Concernant les données transmises et le codage de canal à appliquer, le standard EC-GSM-IoT se base sur les schémas de modulation et de codage MCS-1 à 9, définies dans le cadre du standard EDGE. Si l’objet est en situation d’extension de couverture, des répétitions en aveugle doivent être effectuées, et le MCS-1 est alors employé. Dans ce cas, le bloc de données transmis au codeur convolutif est classiquement composé de 31 bits de signalisation et de 178 bits de données. Le codeur étant de rendement 1
3 et associé à un mécanisme de poin-çonnage, le bloc en sortie est constitué d’un total de 456 bits. Ce bloc est ensuite entrelacé et séparé en sous-blocs de 116 bits, qui seront émis au sein de 4 bursts, et éventuellement répétés dans le cas de EC-GSM-IoT. Encore une fois, nous nous détachons du modèle de codage de canal normalisé. Nous considérons 54 bits de données auxquels sont ajoutés 4 bits de padding de valeur 0. Cet ensemble de 58 bits est encodé par le codeur convolutif de rendement 1
2, déjà considéré précédemment. On obtient donc directement 116 bits, qui seront par la suite transmis au sein d’un seul et même burst. Avant l’application du pro-cessus de mapping sur la constellation BPSK, un mécanisme d’entrelacement est appliqué. Comme nous ne pouvons pas employer le schéma d’entrelacement décrit dans la norme (à cause de la taille du bloc), nous avons décidé d’utiliser un schéma hélicoïdal, réalisé en MATLAB par la fonction helscanintrlv. Le bloc d’entrée est placé dans une matrice 4 × 29, remplie ligne par ligne. La pente de la diagonale suivie par le schéma hélicoïdal est fixée à une valeur de 3. Nous avons choisi ce schéma car il semblait suffisamment performant pour notre application, sans nécessiter de synchronisation entre les processus d’entrelacement et de désentrelacement, et fonctionnant sur des blocs de données de petites tailles. L’objectif de l’entrelacement est ici d’éviter l’entrée d’une suite de bits erronés (ou ayant des LLR faibles) dans le décodeur au niveau du récepteur.
Dans la spécification de EC-GSM-IoT, le nombre de répétitions dépend de la classe de couverture de l’objet, comme présenté sur la Fig. 5.9. Sur la figure, chaque couleur repré-sente un burst et ses répétitions. En supposant 4 répétitions, soit la classe de couverture CC2, chacun des 4 bursts transportant 1
Figure 5.8 – Le burst normal utilisé pour le canal EC-PDTCH.
L’ensemble forme alors un total de 16 bursts, ou 4 fois 4 bursts. Lorsqu’un burst est répété, les répétitions sont d’abord placées sur des slots successifs, offrant ainsi la possibilité d’ef-fectuer une recombinaison de type IQ en réception. Les bursts transportant des données différentes sont alors placés sur des trames TDMA successives, lorsque cela est possible. Au delà de 4 répétitions, il n’est plus possible, d’après le standard, de répéter des bursts sur des slots consécutifs. Dans ce cas, l’ensemble des 16 bursts précédents est répété sur les groupements de 4 trames TDMA suivantes. Dans le cadre de notre implémentation, le mapping employé pour le canal EC-PDTCH est semblable à celui de la norme (voir Fig. 5.4), à la différence que chaque burst transporte la totalité de l’information. Ce mapping nous permettra facilement d’employer des mécanismes de recombinaison hybrides.
Figure 5.9 – Exemple de mapping du canal EC-PDTCH, figure basée sur la Fig. 9b du TS 45.002 version 14.3. Chaque couleur représente un burst et ses répétitions.