Peut-on disposer de qualité de service dans un réseau 4G ? Telle est la question à laquelle nous allons répondre dans cette vidéo. Pour bien situer cette question, il est nécessaire de reprendre ce que nous avons vu jusqu'à ce niveau du cours. Un, la mise sous tension, un terminal 4G s'attache au réseau, il reçoit une adresse IP et en même temps il y a établissement de l'ensemble des tunnels, c'est-à -dire que le terminal 4G dispose dès la mise sous tension et en permanence d'un Bearer par défaut. Ce Bearer n'est pas associé à un niveau de qualité de service, c'est-à -dire que comme on a un réseau qui est basé sur IP avec des files d'attente dans les différents routeurs, il peut y avoir une fluctuation sur le délai de traversée du réseau, c'est-à -dire sur la latence. Et si la mémoire d'un routeur est pleine, il va perdre des paquets et donc il peut y avoir des pertes de paquets. Le Bearer par défaut est toujours disponible, mais il n'est pas associé à une qualité de service. Cela convient pour un grand nombre d'applications. En effet, on a en général le protocole TCP qui gère les retransmissions des paquets. Donc si je surfe sur le web, si j'ai des applications comme du streaming, cela convient tout à fait. On peut très bien utiliser, et on le sait bien, un terminal 4G avec un grand nombre de services. En revanche, pour certaines applications comme la téléphonie sur IP, il est nécessaire de garantir un faible délai dans le réseau. Pour certaines applications critiques également, une faible latence est nécessaire. Le Bearer par défaut ne permet pas de garantir cela, car tous les paquets sont traités avec le même niveau de priorité, c'est-à -dire qu'il y a absence de concept de priorité. On va donc définir dans un réseau 4G, un Bearer dédié qui va comporter des paquets qui vont avoir un TEID différent. Grâce à ce TEID différent, on peut associer à une certaine qualité de service. Cela veut dire concrètement que ces paquets transportés sur des tunnels dédiés vont être gérés de façon prioritaire par rapport aux autres paquets par l'opérateur. Si on a une file d'attente, le paquet va aller par exemple en tête de file d'attente. De cette façon-là , les paquets transitant sur les Bearers dédiés vont arriver statistiquement avant les autres. C'est ce qu'on appelle la garantie de qualité de service. On a des mécanismes qui existent sur IP, comme par exemple Div Serv qui est très utilisé. Le Bearer supplémentaire, le Bearer dédié vient en supplément de tout ce qui existe. Nous le voyons sur cette figure, nous retrouvons les Bearers liés aux données, nous gardons un tunnel de contrôle et une connexion S1AP et le Bearer dédié vient en supplément. On peut en avoir un ou plusieurs. La demande est en général faite à l'initiative du mobile, mais elle est faite en utilisant le Bearer par défaut et en utilisant des protocoles de signalisation particuliers. Par exemple, le protocole SIP peut servir à établir une communication de voies sur IP et le réseau analyse les messages du protocole SIP, et à ce moment-là , il va voir qu'il y a nécessité d'établir un Bearer dédié. Pourquoi laisse-t-on l'établissement du Bearer dédié à l'initiative de l'opérateur ou sous le contrôle de l'opérateur ? Eh bien, précisément parce que si tout le monde établissait un Bearer dédié, il serait difficile de fournir de la qualité de service. Donc derrière la qualité de service, il y a quelque part des mécanismes de contrôle d'admission. Il faut de toute façon que l'opérateur puisse contrôler cet établissement pour garantir vraiment une qualité de service. Le Bearer dédié correspond au même contexte que le Bearer par défaut, c'est-à -dire que c'est relié au même Access Point Name et à la même adresse IP, c'est ce que nous traitons dans le cours. Il est possible d'établir plusieurs Bearers par défaut, c'est-à -dire qu'un mobile peut très bien selon la norme, ce n'est pas forcément un service fourni, demander à avoir plusieurs adresses IP. Nous ne traitons pas ce cas dans le cours. Pendant l'état initial, nous avons notre configuration maintenant classique. Nous supposons que le terminal est attaché au réseau, c'est-à -dire qu'il est dans l'état EMM registered et par ailleurs que les connexions radio et S1AP sont établies, c'est-à -dire que le terminal est dans l'état ECM connected. La procédure d'activation de Bearer dédié va fonctionner comme suit. C'est fait à l'initiative du P Gateway qui a pu recevoir une sollicitation d'un autre élément du réseau. Le P Gateway va envoyer un message GTP "Create Bearer request" et il va indiquer le niveau de qualité de service, QoS pour Quality of Service. Plusieurs niveaux sont précisés dans la norme. Le S-Gateway avertit le MME de la demande, il répercute aussi le niveau de QoS et le MME retransmet 2 choses. Il va transmettre un message S1AP pour indiquer à l'eNode B qu'il va y avoir de la qualité de service à gérer, c'est-à -dire qu'on va avoir une connexion radio avec des paquets prioritaires. En effet, il faut que sur la voie radio, le paquet soit aussi rendu prioritaire. Donc il faut que l'eNode B soit bien au courant et qu'il en tienne compte dans l'ordonnanceur lorsqu'il choisit les blocs de ressources radio qu'il alloue aux différents terminaux. Et d'autre part, il faut aussi avertir le terminal, puisque ça concerne aussi l'application qui se trouve dans le terminal, qu'il y a cet établissement. C'est le but du message ESM Activate Dedicated Bearer Context Request que nous voyons ici. L'eNode B va retransmettre une indication qu'il y a un changement sur la connexion radio et qu'il y a en plus ce Bearer dédié. Le terminal acquitte lorsqu'il a bien pris en compte la modification liée à la configuration radio. Cet acquittement provoque l'envoi d'un message "Setup Response" pour indiquer que la demande a bien été prise en compte. D'autre part, lorsque l'applicatif, par exemple, les couches supérieures ont bien pris en compte l'établissement du Bearer dédié, le niveau Session Management va renvoyer un message d'acquittement du message précédent. Il s'agit d'Activate Dedicated Bearer Context Accept. Ceci est renvoyé au MME, c'est un message de type NAS, Non Access Stratum. Et à cet instant, le MME sait que le mobile a bien pris en compte l'établissement de ce Bearer dédié, que l'eNode B a bien aussi pris en compte la gestion de la qualité de service liée à l'établissement de ce Bearer dédié. Le MME peut ainsi envoyer la réponse à la demande du S Gateway. L'ensemble des messages inclut les TEID qui correspondent à ce Bearer supplémentaire. À la fin de la procédure, nous avons le Bearer dédié qui est établi. Différents TEID sont utilisés pour les différents Bearers par défaut et Bearers dédiés. Le fait d'avoir des TEID différents peut aider à la gestion de la qualité de service. On peut activer, il faut penser à la désactivation. La désactivation se passe de la même façon, à l'initiative du P Gateway. Nous n'allons pas détailler l'échange de messages, on peut les regarder tranquillement après la vidéo. Ça passe toujours par le Serving Gateway, le MME, une demande à l'eNode B et un message NAS vers le terminal. Quand il a pris en compte la libération du Bearer dédié, on envoie les messages d'acquittement jusqu'au P Gateway. À la fin de la procédure, nous nous retrouvons dans le cas initial avec seulement le Bearer par défaut. Le Bearer par défaut est bien sûr maintenu, la connectivité reste maintenue.
