On a vu dans une leçon précédente que pour pouvoir émettre une demande de transmission, les terminaux doivent d'abord s'enregistrer auprès d'eNodeB. Dans cette vidéo, on va voir comment ça fonctionne. On va tout d'abord revenir sur une notion théorique. En réseau, on est souvent amené à devoir définir des règles pour que plusieurs utilisateurs puissent partager le même canal. En effet, si tout le monde parle en même temps, ça génère des brouillages et la communication ne fonctionne pas. Ces règles sont appelées protocole d'accès, elles servent à définir qui peut parler, quand et comment. On distingue 2 grandes familles de protocoles d'accès. Dans la première famille, celle des protocoles dits à contention, on fait l'hypothèse qu'il y a peu de chance d'avoir une collision. Chacun peut émettre quand il le veut. Comme un brouillage peut quand même arriver, on se donne un moyen de savoir si le message est bien arrivé, par exemple avec un système d'acquittement. Si la transmission a échoué, on refera une tentative un peu plus tard. Le Wi-Fi par exemple, fonctionne sur ce principe. L'autre famille est celle des protocoles dits à réservation. Dans ce cas, la ressource est décomposée en petits éléments qui sont alloués aux différents émetteurs. On peut par exemple convenir que chaque utilisateur aura le droit de parler à tour de rôle pendant une milliseconde. Cette allocation peut être fixe, c'est-à -dire définie une fois pour toutes au départ ou dynamique et dans ce cas, elle peut être modifiée en fonction des besoins. LTE fait partie de cette famille. La ressource est divisée dans le temps et en fréquence, on l'a vu, et elle est allouée dynamiquement. Dans le sens descendant, il n'y a pas de problème, puisque toutes les émissions sont réalisées par l'eNodeB. Par contre dans le sens montant, on a vu que les terminaux doivent d'abord envoyer une requête avant de se voir allouer des ressources qu'ils pourront utiliser pour transmettre. On a vu également que ces requêtes passent par le canal de contrôle de la voie montante sur lequel tous les terminaux connus ont un droit de parole à tour de rôle. Cela suppose, bien entendu, que les terminaux se soient enregistrés auprès de la station de base. Pour cela, il faut bien qu'ils aient pu émettre à un moment ou un autre pour se signaler. La solution en LTE consiste à introduire une dose de contention au sein de la voie montante. Sur la voie montante, un groupe de ressources est donc réservé pour permettre aux nouveaux terminaux de s'annoncer. Ce groupe de ressources constitue un nouveau canal physique, celui-là s'appelle le PRACH pour Physical Random Access Chanel ou en français, canal à accès aléatoire. Il est constitué de 6 paires de resource blocks adjacentes et revient toutes les une à 20 millisecondes en fonction du paramétrage de l'eNodeB. L'accès à ce canal se fait d'une façon un peu particulière qui s'appelle le CDMA pour Code Division Multiple Access. On ne s'étendra pas sur cette technique, mais il faut juste retenir qu'en CDMA, les émetteurs encodent leurs émissions avec des codes que l'on appelle séquences. Et les propriétés mathématiques de ces séquences font que si 2 équipements émettent simultanément avec des séquences différentes, le récepteur pourra quand même distinguer chacune des 2 transmissions. Une autre petite précision sur la façon dont LTE utilise ce canal, sur l'espace attribué de une milliseconde, en fait on ne va transmettre qu'un seul symbole et ce symbole va s'étendre sur les 6 resource block du canal. Donc lorsqu'un terminal émet sur ce canal, il ne transmet donc pas de données, mais simplement, comme la station de base va détecter qu'une émission a eu lieu, elle en déduira qu'un nouveau terminal souhaite se connecter et en plus, elle saura identifier ce terminal grâce à la séquence qu'il a utilisée. Il y a 64 séquences disponibles, donc si tous les utilisateurs choisissent une séquence différente, on pourra avoir jusqu'à 64 demandes simultanées. On va voir juste après ce qui se passe si 2 utilisateurs utilisent en même temps la même séquence. Tout d'abord, que se passe-t-il quand un nouvel arrivant entre dans une cellule et qu'il est tout seul ? Donc on a vu dans une leçon précédente que pour réaliser l'allocation de ressources, l'eNodeB attribue à chaque terminal un identifiant court qui s'appelle le RNTI. La procédure est la suivante: le terminal qui arrive écoute les émissions de l'eNodeB pour identifier à quel moment est programmé le PRACH. Il choisit ensuite, au hasard, une séquence parmi les 64 possibles, puis il émet sur le canal à accès aléatoire avec cette séquence, au moment voulu. L'eNodeB détecte cette émission et la séquence qui a été employée. Donc pour l'instant, il ne connaît pas l'identité du mobile, mais il va se servir du numéro de cette séquence pour identifier temporairement le terminal et il va lui attribuer un RNTI. Mais ce RNTI n'est pour l'instant connu que de l'eNodeB. L'eNodeB ne peut donc pas s'en servir comme d'une adresse de destination pour envoyer un message au terminal. À la place, il va utiliser un autre identifiant, le RARNTI pour Random Access RNTI et cet identifiant, il le calcule à partir du numéro de séquence qui a été utilisé par le mobile. Donc le terminal comme l'eNodeB sont tous les 2 capables de calculer le RARNTI. Donc à ce moment-là , l'eNodeB fait 2 choses: il envoie un message au mobile pour lui indiquer un certain nombre de paramètres, dont le RNTI qui lui a été attribué, et il se sert de l'adresse RARNTI comme adresse de destination pour son message. Et en plus, l'eNodeB alloue une ressource à ce terminal pour qu'il puisse émettre une requête de connexion. Donc, à réception de ce message, le terminal va pouvoir émettre sa requête de connexion sur la ressource qui lui a été attribuée et en utilisant le RNTI qu'on lui a donné. La suite de la procédure de connexion est décrite dans une autre semaine de ce MOOC. Alors, j'avais promis de vous expliquer ce qui se passe quand 2 UE accèdent en même temps au canal de contention avec la même séquence, eh bien chaque terminal va dérouler la procédure d'accès aléatoire en pensant qu'il est tout seul. L'eNodeB va percevoir une demande en pensant qu'elle est unique et va donc dérouler la procédure qu'on vient de voir, c'est-à -dire qu'il va attribuer un RNTI et allouer une ressource de transmission et envoyer ces informations sur la voie radio. Les 2 mobiles vont recevoir ce message en considérant qu'il leur est destiné, chacun va donc transmettre une requête de connexion sur la voie radio et là , un brouillage va se produire. En considérant le brouillage, il y a 2 cas possibles. Soit la station de base ne peut décoder aucun des 2 messages et donc elle ne répond pas, dans ce cas les mobiles reprendront la procédure un peu plus tard, au bout d'une durée aléatoire. L'autre cas, c'est que la station de base arrive à décoder l'un des 2 messages, et c'est ce qui est représenté ici. Dans ce cas, elle n'a pas conscience du problème, elle croit qu'il n'y a qu'un seul utilisateur et elle poursuit la procédure. Et ça, ça crée donc une ambiguïté, car on ne sait pas lequel des 2 terminaux a été enregistré. Donc pour répondre à cette ambiguïté, la norme dit que l'eNodeB doit envoyer à l'UE un écho de sa demande de connexion. Et comme à la demande de connexion contient l'identité du terminal, le terminal va pouvoir comparer sa propre identité à celle qui est contenue dans cet écho. Si c'est bien son identité, il continuera la procédure de connexion, sinon il va arrêter la procédure et il la reprendra un peu plus tard, il la recommencera un peu plus tard. En résumé, LTE est un protocole à réservation. L'allocation est gérée dynamiquement par l'eNodeB. Les terminaux enregistrés dans la cellule disposent d'un droit de parole sur le canal de contrôle pour envoyer leur demande d'émission. Pour s'enregistrer dans une nouvelle cellule, les terminaux utilisent le canal à accès aléatoire. Ce canal est géré en contention et un protocole permet de lever les ambiguïtés qui peuvent survenir en cas de collision.
