Quelle est la pile de protocole pour une interface SBI? Comment les interactions entre NF sont-elles organisées? C'est ce que nous allons voir dans cette vidéo. Nous l'avons déjà évoqué, c'est HTTP/2 qui est utilisé pour les dialogues entre NF. C'est une évolution de HTTP/1.1 qui permet d'avoir plus de rapidité et plus de fiabilité. En 5G, les messages sont encodés en JSON. L'intérêt de ce format est qu'il est orienté texte. Pour interpréter les messages, il suffit de les lire. L'accent est mis donc sur la lisibilité et aussi la facilité d'évolution. Pour éviter d'avoir des messages trop longs, on peut utiliser un algorithme de compression, gzip bien connu, mais d'autres algorithmes qui montent actuellement comme Brotli. Autant que possible, c'est une approche REST qui est utilisée. Nous allons la décrire dans quelques minutes. Pour sécuriser les échanges, c'est le protocole TLS qui est proposé par défaut, ou Transport Layer Security. Si l'opérateur le veut, il peut utiliser d'autres moyens de sécurisation. Nous avons donc la pile de protocole suivante entre une NF consommatrice et une NF productrice, avec HTTP/2 au-dessus éventuellement de TLS, toujours au-dessus de TCP, lui-même au-dessus de IP. Qu'est-ce que REST? Cela signifie REpresentational State Transfer. C'est un concept très général qui a été défini dans les années 2000 par Roy Thomas Fielding dans sa thèse de doctorat. Une notion centrale dans REST c'est la ressource. Qu'est-ce qu'une ressource? C'est un objet avec un type de données associées et des méthodes qui permettent d'agir sur cet objet, et éventuellement des relations avec d'autres objets, c'est-à -dire des relations entre différentes ressources. Des exemples vont mieux situer de quoi il s'agit. Une ressource, ça peut être un fichier texte. Cela peut être une page HTML, une image, une vidéo ; mais pour prendre un contexte plus 5G, un profil d'abonné, les droits d'accès d'un abonné, ou l'état d'un UE sur quelle technologie il est positionné, 3G, 5G ou WiFi. Ou alors, cela peut être un pointeur, par exemple un pointeur vers une vidéo, et on retrouve les relations entre ressources. Pour qu'une API soit dite compatible REST ou RESTful API, il y a six contraintes définies par Fielding. La première c'est d'avoir une interface uniforme pour accéder ou modifier une ressource. La deuxième c'est une approche client-serveur. C'est ce que nous avons en 5G. La troisième c'est un dialogue sans état ou stateless. Cela veut dire que le serveur doit traiter chaque requête comme si c'était une nouvelle requête. Il n'a pas à faire référence à un historique quelconque. Tous les éléments permettant de traiter la requête sont présents dans la requête. Il n'y a aucune notion de session. Nous avons une propriété liée à cela, c'est l'idempotence. Si on considère de multiples requêtes identiques successives, elles doivent avoir le même effet qu'une seule requête. Cela signifie qu'il y a possibilité de mettre des éléments en cache. Si plusieurs requêtes sont envoyées et qu'elles sont identiques, un équipement intermédiaire peut stocker la réponse qu'il a vue lors de la première requête et répondre directement aux requêtes qui suivent pour décharger le serveur. Il y a possibilité d'avoir un système en couches. Il ne s'agit pas du tout, dans ce contexte, des couches OSI. Il s'agit plutôt des architectures dites multi-tier où, par exemple, on va séparer la représentation des données, le traitement lui-même et le stockage qui peuvent être implémentés dans des matériels différents. La sixième propriété est le code à la demande, qui est optionnel. Un client peut demander le code d'exécution à un serveur. Une notion centrale, nous l'avons dit, en REST, c'est la ressource. On accède à chaque ressource dans un réseau cœur 5G par son URI ou Uniform Resource Identifier, qui a le format suivant. On commence par un champ appelé apiRoot, qui inclut le protocole utilisé, http ou https lorsqu'on utilise TLS, et qui inclut ensuite l'autorité. L'autorité permet d'être sûr qu'une ressource est unique. Une autorité peut être, pour l'opérateur Sydavie Télécom, http://syltel.com, ou https://5Goperator.fr pour un autre opérateur en France. Cela peut être aussi une adresse IP. Cette partie apiRoot est spécifique à l'opérateur au réseau. Ensuite, on trouve quelque chose que nous avons déjà vu, le nom de l'API, par exemple nudm-sdm, pour l'UDM et le service de gestion des profils, Subscriber Data Management. Mais il y a, bien sûr, un grand nombre d'autres API possibles : la version de l'API pour permettre l'évolutivité, et ensuite une partie spécifique à l'API. Toute cette partie est complètement spécifiée dans les recommandations 3GPP. Il n'y a pas de flexibilité, au contraire de l'apiRoot. Notons qu'il y a une structure hiérarchique, c'est-à -dire qu'on peut définir un parent et des fils, petit-fils et ainsi de suite. Un exemple d'API qui peut correspondre à une ressource en 5G http://syltel.com, c'est l'apiRoot, nudm-sdm le nom de l'API, la version. Et ensuite, on va indiquer le SUPI de l'abonné, son identité et am-data, les données d'abonnement liées à l'accès et la mobilité. Cette structure hiérarchique, nous pouvons la représenter sous la forme d'un arbre, et nous pouvons voir toutes les ressources par exemple de l'UDM comme un arbre, la racine étant l'apiRoot. Et nous voyons le nom de l'API, la version, ce qui signifie, par exemple, que le profil de chaque abonné va être indiqué par un URI où on va retrouver l'IMSI de l'abonné, puisque dans la plupart des cas, le SUPI est égal à l'IMSI. Un abonné différent avec un IMSI différent va avoir la même structure, mais bien sûr peut avoir un profil d'abonné différent. Nous avons donné quelques exemples. Ce qui est important c'est de bien voir qu'ici, on définit la ressource, on l'identifie sans jamais s'occuper de savoir où physiquement les données correspondantes sont stockées. Pour conclure, dans l'approche REST, la notion centrale est la ressource, et en exagérant un peu, on peut dire : tout est ressource. Chaque ressource est identifiée par son URI, qui commence par la partie apiRoot variable, dépendant de l'opérateur, et une partie dépendant du service et totalement spécifiée. Les actions sur les ressources dans le cadre de la 5G sont possibles avec HTTP/2, qui peut être utilisé au-dessus de TLS pour la sécurisation et qui est toujours au-dessus de TCP/IP. Dans la vidéo suivante, nous allons voir plus concrètement quelles sont les actions possibles sur une ressource. [MUSIQUE] [MUSIQUE]
