L'objectif de l'architecture 4G a été de séparer les différentes fonctions: 1) contrôle de la partie radio entre l'eNodeB et le terminal et 2) gestion de la sécurité et de la mobilité dans le MME. Comment permettre à un MME de ne traiter que la partie sécurité et mobilité ? Comment permettre à un eNodeB de se concentrer sur les fonctions de gestion et de connexion radio ? Telle est la question à laquelle nous allons répondre avec cette vidéo. Tout d'abord, il faut rappeler la notion de plan de contrôle ou plan de commande ou « control plane » en anglais. On peut définir le plan contrôle comme contenant tous les protocoles, mécanismes et messages permettant de configurer les éléments de réseaux informatiques ou de télécom afin de permettre la fourniture effective d'un service de communication. C'est une définition un peu formelle. Un exemple : le mécanisme d'attachement. Tous les échanges de sécurité sont nécessaires pour que le réseau fonctionne correctement, mais en eux-mêmes ils ne transportent pas des données utilisateurs. Ce sont donc des échanges placés dans le plan contrôle. Pour généraliser, on peut dire que le plan contrôle, ce sont tous les échanges de signalisation. Le dialogue entre un terminal, un UE, et MME est donc uniquement dans le plan contrôle puisque le MME ne va voir passer aucun paquet de données de l'utilisateur, c'est uniquement des messages de contrôle. Dans le contrôle, on peut Distinguer, ce qui est gestion de la mobilité, de la sécurité, qui est prise en charge par le MME et ce qui est allocation de ressources radios, établissement des connexions radios. Ce sont des échanges entre le terminal, l'UE et l'eNobeB. Ces messages, ces protocoles sont extrêmement liés à la technologie radio. Nous avons vu qu'entre un terminal et l'eNode B, il y a une connexion radio et le terminal est identifié par le RNTI, Radio Network Temporary Identifier. Et que sur la connexion radio qui est établie, on va utiliser des valeurs de LCID, Logical Channel Identifier, pour distinguer les données utilisateurs et la signalisation. Pour être plus précis, on va utiliser 2 valeurs différentes, l'une pour les messages de signalisation qui sont envoyés, par exemple, par le terminal et à destination du MME. Nous avons vu la notion de connexion S1-AP : les messages envoyés par le terminal à destination du MME vont transiter sur la connexion radio et ensuite sur la connexion S1-AP. Bien sûr, la même chose se passe dans l'autre sens pour les échanges du MME vers le terminal. L'ensemble de ces messages forme ce qu'on appelle le Non Access Stratum, NAS. Les messages NAS, et ça c'est un point très important, sont relayés par l'eNodeB, mais leur contenu n'est jamais analysé. C'est-à -dire qu'on peut changer complètement le protocole, le type de messages NAS, sans avoir une seule ligne de codes à modifier dans l'eNodeB. Les messages AS, pour Access Stratum, sont tous ceux qui sont liés à la technologie radio, à l'établissement et la gestion de la connexion radio. Ils sont échangés entre le terminal et l'eNodeB. Par exemple, une modification d'un bearer radio sera un message AS. Si nous regardons maintenant le point de vue de la pile de protocoles. On a représenté ici le terminal, UE, l'eNodeB et le MME. Entre l'eNodeB et le MME, nous avons un réseau IP, donc une couche 1 quelconque, une couche 2 quelconque et le protocole IP comme protocole réseau. Le choix qui a été fait, c'est d'utiliser un protocole de transport qui n'est ni TCP, ni UDP. UDP ne fournit pas de fiabilité et TCP est un petit peu trop complexe et surtout il n'est pas orienté messages. Il a un certain nombre de défauts et il est plus fait pour transmettre un flux. Ici, ce qu'on souhaite, c'est faire des échanges de messages de signalisation de façon fiable. Pour ça, il y a un protocole qui convient qui est SCTP, pour Stream Control Transmission Protocol. Ce protocole est fiable, mais il évite les retransmissions inutiles. Pourquoi on utilise un tel protocole ? Eh bien, on peut avoir quelquefois entre l'eNodeB et le MME des liaisons par des faisceaux hertziens qui ne sont pas forcément très fiables. Donc mettre un protocole qui gère la retransmission des messages en cas de perte est une bonne chose. Au-dessus de SCTP, nous trouverons le protocole S1 AP. Ce protocole est orienté connexion et il y a autant de connexions que de terminaux gérés par le MMA. Si on regarde le coté de l'interface radio, nous revoyons les choses connues: la couche physique qui est indiquée ici comme couche 1, L1, Layer 1 ; la couche MAC, Medium Access Control ; la couche RLC, Radio Link Control ; la couche PDCP, couche de convergence ; et au-dessus RRC pour l'établissement des connexions radio. Tous les messages RRC sont échangés entre le terminal, l'UE et l'eNodeB. En revanche, il y a d'autres messages qui sont envoyés par l'UE à destination du MME ou envoyés par le MME à destination de l'UE. Ces messages sont transportés dans des messages RRC, mais ils ont trait à un autre protocole qui est de type NAS, Non Access Stratum, avec deux niveaux: EMM pour la gestion de la mobilité et MM pour Mobility Management et ESM pour la gestion des cessions, Sessions Management. Le E voulant dire Evolved, faisant référence au fait qu'on est dans le réseau EPC, Evolved Packet Core. Si nous regardons derrière l'eNodeB, nous avons déjà vu qu'il y a une notion de tunnel pour transporter les données utilisateurs. Chaque tunnel est identifié par une paire de TEID. Mais il faut quand même un minimum de contrôle pour établir ces tunnels. De ce fait, on va définir aussi des tunnels de contrôle. Chaque tunnel est identifié par une paire de TEID, comme pour les tunnels de données, mais les valeurs sont différentes. On a donc des tunnels de contrôle entre le Serving Gateway et le P Gateway et entre le MME et le Serving Gateway. Ces tunnels de contrôle vont connaître des échanges de type GTPC, GPRS Tunnel Protocol in the Control Plane. Ce sont tous les messages nécessaires pour l'établissement, le maintien et la libération des tunnels de données. Nous avons donc la pile de protocoles que nous avons déjà un petit peu entrevue pour le plan utilisateurs, ici c'est pour le plan contrôle avec IP et au-dessus de IP, UDP et GTPC, que ça soit entre le Serving Gateway et le P Gateway ou entre le Serving Gateway et le MME. Si nous essayons d'avoir une vue plus globale, toujours dans le plan contrôle, nous avons la figure représentée ici que vous pourrez prendre le temps de regarder à partir des transparents. Cette figure symbolise l'ensemble de ce que nous avons vu dans les transparents précédents. Il n'y a pas que le plan contrôle, il y a le plan usagers, User Plane, c'est le plus important, c'est celui qui transportent des données utilisateurs. Nous pouvons le représenter dans le schéma. Il apparaît ici et nous avons ainsi une vue globale de l'ensemble des protocoles entre l'UE, l'eNodeB, le MME, le Serving Gateway, le P Gateway. En bleu, nous avons représenté systématiquement le plan contrôle et en rose le plan usagers ou User Plane. Les messages NAS, Non Access Stratum, sont donc tous ceux qui sont échangés entre l'eNodeB et le MME et qui sont retransmis pas l'eNodeB. Avec cette notion de connexion, S1 AP, de tunnels de contrôle et de tunnels de données, chacun étant identifié par une paire d'identificateurs, on peut facilement gérer des centaines de milliers ou des millions de dialogues simultanés.
