Dans cette vidéo nous allons voir comment distribuer les ressources en fonction des besoins des équipements. La fonction d'allocation des ressources s'appelle l'ordonnancement ou scheduling en anglais. Il y a 3 grands principes à retenir concernant l'allocation. Le premier, on l'a déjà vu, c'est que les ressources ne sont allouées que s'il y a un besoin de transmission effectif. Le deuxième, c'est que tout est centralisé par l'eNodeB pour la voie descendante comme pour la voie montante. Enfin, le troisième c'est que l'eNodeB informe les terminaux de l'allocation des ressources en publiant, à chaque sous-trame, une table d'allocations pour la voie montante et la voie descendante. Avant d'approfondir, il faut introduire un point sur la notion d'adressage. En radio, comme tout le monde entend ce qui se passe, il est nécessaire d'adresser des messages, c'est-à -dire d'indiquer à qui est destinée quelle information. Pour cela, on a besoin d'un identifiant. On pourrait utiliser les identités qu'on a déjà introduites dans les leçons précédentes. Mais la taille de ces adresses est généralement trop longue, car elles doivent garantir l'unicité au sein d'un réseau global. Là , au contraire, on a plutôt besoin d'une adresse courte, car on va la transmettre souvent et que le nombre de terminaux dans une cellule est assez limité. On a donc introduit une nouvelle identité qui n'est valable qu'au sein de la cellule, c'est le RNTI, ça signifie Radio Network Temporary Identifier. Elle est gérée par l'eNodeB. Donc quand un terminal arrive dans une cellule, l'eNodeB lui attribue le RNTI dont il va se servir pour discuter avec lui pendant toute la durée de sa présence dans la cellule. Le RNTI est codé sur 16 bits. Certaines adresses sont réservées à des usages un peu particuliers, mais ça laisse quand même un peu plus de 65 000 combinaisons. Ça semble raisonnable pour adresser les terminaux d'une cellule. Comment se passe l'allocation sur la voie descendante ? À chaque sous-trame, l'ordonnanceur de l'eNodeB détermine l'allocation des ressources, c'est-à -dire à quel utilisateur sont destinées les données de chaque resource block de la sous-trame. Pour que les destinataires sachent où sont les données qui les concernent, l'eNodeB publie un début de trame, une table d'allocations qui donne en quelque sorte le plan de la sous-trame. Par exemple, pour cette sous-trame ici, la table d'allocations est publiée sur cet espace bleu et on voit que les resource blocks 12 et 13 sont attribuées aux mobiles de RNTI 63 qui est ce mobile vert, c'est pour ça qu'on a colorié des deux resource blocks en vert. De la même façon, les resource blocks 4 à 7 sont attribués au mobile RNTI 62 qui est ici en rouge. Alors un des avantages de cette façon de faire est que ça permet de limiter la consommation d'énergie des terminaux. En effet, si un mobile s'aperçoit qu'il n'a pas de données à recevoir, il peut repasser en veille jusqu'à la prochaine sous-trame. Et même s'il doit recevoir des données, par exemple notre mobile vert, ici, et bien il peut éviter de gaspiller de l'énergie à décoder les données qui ne lui sont pas destinées. Il va focaliser ses efforts uniquement sur les resource blocks qui lui sont destinés. Pour la voie montante, on reprend le même principe que pour la voie descendante, c'est-à -dire que c'est toujours l'eNodeB qui alloue des ressources aux terminaux. Il le fait via une table d'allocations qui va être publiée en même temps que celle de la voie descendante. Mais il y a quelques différences. Tout d'abord, l'eNodeB ne sait pas a priori quand les terminaux vont avoir besoin de transmettre. Il faut donc d'abord que le terminal exprime une demande. Donc ça, c'est un peu paradoxal parce que pour pouvoir émettre, le terminal doit envoyer un message de demande. Donc on verra un peu plus tard comment on résout ce problème. Pour l'instant, on considère le problème comme résolu, et donc on considère que l'eNodeB vient de recevoir une demande. Une fois cette demande reçue, l'eNodeB réalise l'allocation, publie cette information dans une table d'allocations de la voie montante. Et quand le mobile reçoit cette information, il n'est pas forcément prêt à émettre son message immédiatement. C'est pourquoi la norme prévoit que la table d'allocations publiée par l'eNodeB pour la voie montante ne porte en fait que sur la quatrième prochaine sous-trame, donc ce qui va se passer dans 4 millisecondes, de façon à laisser le temps au terminal de préparer son bloc de transport et son émission. Sur cette figure, on a représenté des motifs de trame LTE pour la voie descendante et pour la voie montante. On voit que dans les 2 cas on a réservé des ressources pour dissocier les données de contrôle des données utiles. Sur la voie descendante, le canal de contrôle apparaît ici en bleu. Il utilise les premières ressources élément de chaque sous-trame. Il transporte notamment les tables d'allocation des voies montantes et descendantes. Le reste constitue le canal de données qui va transporter les données utiles des utilisateurs. Sur la voie montante, le canal de contrôle apparaît en gris. Il est constitué des blocs de ressources situés aux 2 extrémités du spectre. Les données, elles, seront transportées sur les blocs de ressources situés au centre du spectre. Tout à l'heure je vous avais dit que j'allais vous expliquer comment les terminaux peuvent formuler une demande d'émission auprès de la station de base, alors qu'ils n'ont a priori pas de droit d'émission. Et bien ils vont l'envoyer sur le canal de contrôle de la voie montante. Et pour ces ressources-là , LTE définit un mécanisme d'accès un peu particulier qui permet à tous les terminaux de la cellule de disposer à tour de rôle d'un droit d'émission sur ce canal, sans avoir à en demander l'accès. Alors juste un mot pour vous expliquer que la norme LTE généralise cette notion de canal. En fait elle définit de nombreux canaux avec des acronymes assez barbares. Vous pouvez voir ici des noms de canaux, du type PUSCH, PUCCH, PDCCH, PDSCH. Mais rassurez-vous, on ne descendra pas à ce niveau de détails, et dans le cadre de ce cours, on retiendra juste que l'on peut faire une différence entre des canaux de données et des canaux de contrôle. En résumé, l'allocation est gérée par l'eNodeB pour la voie montante, comme pour la voie descendante. Les ressources ne sont allouées que si un besoin de transmission avéré se présente. Des canaux de contrôle sont réservés pour les échanges liés à l'allocation. Sur la voie montante, le terminal doit d'abord formuler une demande sur le canal de contrôle avant de se voir allouer une ressource qui sera active 4 sous-trames plus tard.
