Dans cette leçon, on va étudier le dernier maillon de la pile protocolaire de l'interface radio. C'est le protocole PDCP, qui assure l'interface avec le réseau-cœur et donc avec le protocole IP. Ensuite, on va mettre en perspective les principales notions que l'on a vues cette semaine, de façon à élaborer une vue globale de l'interface radio. PDCP signifie Packet Data Convergence Protocol. Il est mis en œuvre au-dessus de chaque instance de RLC qui fonctionne en mode acquitté, ou non. Il assure l'interface avec le cœur de réseau, c'est-à -dire avec les protocoles IP pour les données utiles, et RRC pour les messages de signalisation. Il fournit trois types de services. Pour commencer, la compression d'en-têtes. Comme vous le savez sûrement, les applications reposent sur des piles de protocoles et chaque protocole rajoute son en-tête. Par exemple, on voit sur IP, les paquets font typiquement trente octets. Ils sont encapsulés dans RTP qui rajoute douze octets, UDP qui rajoute huit octets et IP qui rajoute 40 octets, si on utilise la version IPv6. Et on voit que les en-têtes font soixante octets, c'est-à -dire le double des données utiles. Donc on transmet deux fois plus de données protocolaires que de données utiles. Or, ces données protocolaires changent très peu d'un paquet à l'autre. D'où la possibilité de les compresser. Pour réaliser cette fonction LTE utilise un protocole standard de l'Internet quis'appelle ROHC qui signifie, Robust Header Compression. Ce n'est pas un hasard si LTE réutilise des protocoles de l'Internet, en effet il a justement pour ambition de se rapprocher des protocoles standards, notamment pour son réseau-cœur. Une autre fonction de PDCP est d'éviter les pertes de paquets ou les déséquencements qui peuvent se produire lors des Handhovers. On a vu que RLC gère les retransmissions, mais il le fait uniquement au sein d'une cellule. Avec PDCP, lors d'un changement de cellule l'ancien eNodeB peut informer le nouveau sur l'état exact des transmissions en cours et il peut lui faire suivre les données qui étaient en attente d'émission, ou de réception d'un acquittement. La dernière fonction de PDCP concerne la sécurité. En effet, la liaison radio est un élément particulièrement vulnérable en termes de sécurité, PDCP permet donc de chiffrer les données pour garantir la confidentialité des échanges et il propose aussi un système de contrôle d'intégrité qui est utilisé sur les données de signalisation afin de vérifier qu'elles n'ont pas été modifiées lors de la transmission. Ce n'est pas très important, mais toutes les fonctions de PDCP ne sont pas utilisables dans tous les cas. Ce tableau est un petit récapitulatif. La compression d'en-tête, par exemple, ne fonctionne que pour les données encapsulées dans l'IP. Elle ne peut donc pas être mise en œuvre pour les messages de contrôle au format RRC. La prévention des pertes liées au Handover ne fonctionne que pour les instances de RLC qui fonctionnent en mode acquitté. Le chiffrement lui est possible dans tous les cas. Il est optionnel, mais il est très fortement recommandé de l'activer. Enfin, le contrôle de l'intégrité n'est utilisable que pour les messages protocolaires. Mais c'est là que c'est le plus important, car si le système venait à prendre en compte un message corrompu, ça pourrait poser de gros problèmes. Si les applications ont besoin d'un contrôle d'intégrité, elles devront l'implémenter par elles-mêmes. Ce schéma présente une vue synthétique de la pile protocolaire de l'interface radio. Il résume ce qu'on a vu au cours de cette semaine. En partant du bas vers le haut, on voit la couche physique qui assure le codage correcteur d'erreurs, et la modulation multiporteuse de type OFDM. Au-dessus, on voit la couche MAC qui contrôle le choix de la modulation de la couche physique, de manière indépendante pour chaque terminal, elle en déduit les capacités de transmission et donc sur l'eNode B elle assure l'allocation des ressources, pour les deux voies, montantes et descendantes. La couche MAC assure également la fiabilisation de la transmission à bas niveau par un mécanisme de répétition, appelé HARQ, qui est le multiplexage des différents canaux logiques, en provenance des différentes instances du RLC. La couche RLC, quant à elle, propose des services de remise en séquence, de segmentation et de retransmission. Plusieurs instances de RLC tournent en parallèle et ça correspond à différents niveaux de service. Enfin, la couche PDCP assure l'interface avec le cœur de réseau en IP, pour les données utiles, et RRC pour les messages de signalisation. Elle propose des services optionnels de sécurité, de compression d'en-têtes, et de reprise de connexion lors des Handovers. Ce dernier schéma donne une représentation du cheminement des paquets de données. En rose on a représenté des données utilisateurs en IP, et en bleu un message de contrôle au format RRC. Donc c'est plus un schéma de référence, mais on peut quand même faire quelques commentaires dans le cadre de ce MOOC. Au niveau de PDCP, on voit par exemple la compression d'en-têtes qui s'applique sur des messages au format IP et pas sur les formats RRC. Au niveau RLC, on voit que les deux messages rouges appartiennent à la même instance de RLC, ils ont été concaténés dans un même RLC PDU. Ce n'est pas le cas du message de contrôle. Au niveau MAC, on regroupe les MAC SDU issus des deux instances de RLC, on y ajoute des en-têtes pour former un bloc de transport qui sera fourni à la couche physique. Au niveau de la couche physique, on a rajouté en pointillé le RMTI. Il est en pointillé, car il n'est pas transmis avec les données, mais il est fourni de façon implicite au travers de la table d'allocations. Enfin, pour mémoire, cette planche reprend la liste des acronymes qui ont été employés au cours de cette semaine.
