 Bien, merci pour l'introduction, merci pour la prononciation. Alors, je voudrais remercier le Fondation Linux pour m'inviter ici, spécialement, selon le fait que six mois auparavant, je pensais encore que le Fondation Linux était un peu étudiant dans le garage. Et en fait, je l'ai trouvé dans les six mois que ce n'est pas tout ça. Je vois que leurs revenus et leurs grosses sont beaucoup plus hauts que l'orange, en fait. Donc, mon background est dans la Network Radio-Access. Et j'ai fait ça pour les dernières 15 ans, avec 3G, 4G, 5G. Et l'opinion des softwares n'est pas la première partie, on dirait, dans le domaine network qui a été changé. La Network Radio-Access est un peu derrière d'autres domaines. Mais nous sommes arrivés. To be honest, ce n'est pas vraiment la première partie. Je me souviens que 15 ans auparavant, il y avait un projet qui s'appelle OpenBTS. Le goal de OpenBTS était d'implémenter les 2G protocoles en source de l'opinion, afin d'en faire un tour sur la PC. Et en fait, techniquement speaking, c'est travaillé. Mais c'était vraiment de petite scale. Et ce que je veux expliquer aujourd'hui, c'est que maintenant, nous allons à une grande scale pour la Network Radio-Access, avec 5G. Et afin de faire ça, nous avons créé un main-tour qui s'appelle Oran. Oran s'appelle OpenRan, et l'alliance OpenRan a été créée 18 mois plus tard. Avec 5 opérateurs, including Oran. Il y a AT&T pour l'US, il y a Oran et Dush Telecom, pour l'Europe et l'Afrique, China Mobile, China, et NTT Yukomo pour Japan. Et c'était vraiment important pour nous de créer cette alliance sur une base globale. C'est parce qu'il sera difficile, à l'honneur, d'ouvrir l'Oran. L'Oran, comme je vous l'explique aujourd'hui, c'est plutôt un monde de plus en plus. Et afin d'y arriver, nous devons vraiment être sur une scale globale. Oran a été créé sur deux prévues alliances et forums, le X-Ran Forum qui était principalement western orienté et le C-Ran Alliance qui était principalement chinois orienté. Donc, le succès est assez bon, donc après une année d'opérations pratiques sur les cinq fonds, nous avons maintenant 16 opérateurs qui s'entendent de tous les autres mondes. Nous avons, bien sûr, tous les grands opérateurs US. Nous avons maintenant Coréen qui s'entend. Nous avons beaucoup d'opérateurs européens. Nous avons tous les opérateurs chinois. Sur ce opérateur, nous avons maintenant 80, probablement plus maintenant, mais plus que 85 non-opérateurs contributaires. Et ces contributaires viennent de différents domaines. Certaines font des chipsets, par exemple, comme l'Intel ou le Broadcom. Nous avons aussi les grandes vendeurs de networks, comme Ericsson, pour exemple, mais nous avons aussi Nokia, ZTE, Cisco, etc. Nous avons aussi un sub-système. Certaines font du hardware, parce que pour avoir un bon network de radio access, vous avez besoin d'un radio. Et le radio est hardware. Nous avons des gens qui créent des power amplifiers, des antennes actives, des choses comme KMW, et nous avons aussi des joueurs pureurs de softwares, ou des intégrateurs, comme Mevenir ou Radisys. Nous avons créé un très bon écosystème, qui a déjà travaillé beaucoup. Donc, aujourd'hui, ce que je veux passer par un message, c'est que c'est vraiment un bon temps de faire ça. Je l'ai dit avant qu'il y avait des attentes dans la histoire, mais elles étaient très petites. Et si nous avons besoin d'un large scale, il y a vraiment de la raison pour ça. La première raison est pour les services. Nous voulons en enlever avec 5G. Sur ce slide, vous pouvez voir deux de les familles les plus importantes, que nous allons délever. La première est l'immersif vidéo, comme VR, AR, et la deuxième famille, qui est assez grande, est ce que nous appelons la application verticale. Donc, c'est un set de services qui sont dédicatés à des secteurs spécifiques, et tous de ces secteurs ont des requirements spécifiques. Mais le point commun de tous ces services est que, à la plupart du temps, ils nécessitent une très low latency. Et cette très low latency, je peux vous dire, c'est quelque chose que nous ne pouvons pas délever avec notre réseau current. Notre architecture qui a été créée avec 2G, et qui n'a pas évolué, pour être honnête, beaucoup, de 2G à 3G à 4G. Bien sûr, il y avait de nouvelles fonctions, de nouvelles names, etc. Mais, on va dire que la topologie de notre réseau n'a pas changé beaucoup. Nous devons changer ça, c'est un très grand change, parce que la low latency, pour une fois, une raison très fondamentale, que nous ne pouvons pas changer. C'est la vitesse de lumière. Pour le faire simple, la vitesse de lumière est 300 000 km par seconde dans l'air, et c'est un peu moins en fibre, c'est environ 200 000 km par seconde. Donc, quelque chose de ça, nous pensons que c'est très rapide, mais en fait, ce n'est pas. Retournir et forcer à cette vitesse, si vous voulez avoir une millisecondes latency, vous ne pouvez pas aller plus loin que 100 km. C'est une raison fondamentale, pourquoi nous devons changer la topologie de notre réseau, pour changer la position où nous avons mis les nodes, l'application, les clouds, etc. Et nous devons s'agir, d'un certain extent, avec l'écosystème de comment faire ça, parce que nous ne voulons pas faire ça différemment. Tout le grand opérateur a beaucoup de respect pour les standards. Et il y a une raison pour ça, c'est parce que les standards ont fait notre succès. Si nous faisons quelque chose, disons séparément, nous perdons l'économie et nous n'y arriverons pas. Donc, les standards et la source d'opérations sont vraiment clés pour les opérateurs, pour changer cette architecture et pour le rendre plus compact. Il y a une autre raison fondamentale, pourquoi nous devons changer maintenant. C'est ce que j'appelle le sens de l'histoire. Donc, en regardant cet exemple, vous devez savoir, si vous êtes à l'aise de ma petite device, en fait, c'est une device de jeu. Donc, c'est quelque chose que 35 ans auparavant, je pense, nous pouvons acheter, et c'est un jeu avec un hardware spécifique et un software spécifique. Donc, vous achetez un jeu, mais en même temps, vous achetez un hardware. Donc, ce n'est pas très flexible. Pour certaines raisons, nous avons probablement pris 100 heures sur ça, mais ma fille ne ferait pas ça. Parce que mes enfants, ce qu'ils veulent faire, c'est d'être capable de changer, d'avoir de nouveaux jeux, etc. Et donc, pendant ces 35 ans, il y avait plusieurs changements, pour arriver à une situation où nous avons une séparation entre le hardware, la plateforme, on dirait, et le jeu. Et c'est très flexible. Donc, maintenant, dans le domaine de la ronde, nous sommes très près de la situation ici. Donc, si vous pouvez me l'introduire, où nous sommes, nous sommes à la stage de ce que je disais, la networks de radio-accès traditionnelles. Ce qui est ici. C'est-à-dire que nous voulons acheter des équipements qui sont fermés. Nous avons principalement deux sacs. Un sac est le radio, on l'a appelé RRH, radio remote, radio-head. C'est le hardware spécialisé, power amplifier, receveur, converters, etc. C'est quelque chose qui est très analogique, à l'honneur. Et un autre sac qui contient tout le processus digital avec les différentes layers. C'est probablement 99% de l'équipement qui est déployé par le grand opérateur. C'est la situation de la situation. Et ça change maintenant dans le modèle que nous avons ici, dans le milieu, que nous l'avons virtualisé. Et le premier change que nous faisons est que nous introduisons une infrastructure de cloud dans la network de radio-accès. Et cette infrastructure de cloud est en charge de manager le meilleur layer du processus digital. C'est ce que nous appelons Layer 3. Donc c'est probablement 1% de l'équipement de radio-accès que nous avons. Et le target que nous nous installons est la network de radio-accès désagrégée. C'est quelque chose que vous savez pour quelques autres domaines. Mais il est maintenant venu sur le tour. Et dans ce modèle, la plupart des processus digitales sont supportés dans le cloud avec différents modules. Et ces modules peuvent être l'open source de propriété. Et vous avez besoin d'un lot de, on dirait, des interfaces bien définies afin d'exprimer ça proprement. Donc, juste une petite vue sur l'architecture que vous avez ici. Donc je ne vais pas décrire tous les textes, bien sûr. Mais on dirait, en parlant profondément, c'est trois parties. Au-dessus, vous avez le système de management de radio-accès qui est non réel. Et ensuite, vous avez ce que nous appelons la «CU » pour la unité centrale. Donc ici, c'est vraiment la unité radio-accès elle-même et la unité distribuée. Donc la unité centrale est normalement exécutée sur un data centre d'âge. Et la unité distribuée est normalement très close à l'antenne. Donc l'alliance à l'open-run a évolué ceci. L'alliance à l'open-run a créé l'architecture et au-dessus de la création de l'architecture, l'alliance à l'open-run provides principalement deux choses. La première est l'interface à l'open-run. C'est très important de proprement définir les interfaces et les API. Parce que si vous n'avez pas vu ce point, si vous créez une interface qui n'est pas à un bon endroit et qui n'est pas bien définie, ce que vous allez faire est moins que de ne pas avoir aucune standardisation. Parce que vous pouvez avoir pour les performances et vous pouvez aussi géopardiser l'évolution de votre système. Parce que cette interface n'est pas correctement définie. Puis, elle va bloquer les deux parties sur les deux côtés de l'interface pour évoluer correctement. Donc, nous avons pris beaucoup de temps dans l'alliance pour proprement définir ces interfaces. D'ailleurs, beaucoup d'entre eux sont définis en 3GPP dans les standards. Donc, soit ils sont définis en 3GPP et ensuite l'alliance au-delà crée des profiles afin d'en faire plus facile pour en faire multivendre. Ou soit ce n'est pas existé en 3GPP et ensuite c'est totalement créé dans l'alliance. La deuxième chose qui est créée dans le domaine et je vais l'expliquer après la façon dont c'est créé est, bien sûr, les modules d'open source. La networks de radioaccès est currently 90% fermée. Donc, nous ne ferons pas faire un source d'open source complètement comme l'année prochaine. Ça va prendre du temps. Donc, le bon moyen pour progresser dans cette direction est de créer un module d'open source par module. Donc, il y a des modules qui sont plus simples pour faire un source d'open source et nous commençons avec ça et avec le temps, nous allons avoir plus et plus de source d'open source. Peut-être un spécialiste qui appuie durant les dernières semaines et mois est sur la fragmentation de l'écosystème. Donc, je ne sais pas si certains de vous ont suivi ça, mais il y a des discussions, je dirais, entre les États-Unis et China. Et ces discussions sont sur la trade et la sécurité. Donc, ce qui pourrait arriver à la fin de cette discussion, personne ne le sait. Je veux dire, peut-être, nous serons exactement dans la même façon d'opération qu'aujourd'hui, dans deux ans, ou peut-être que ce sera différent. Ce qui pourrait arriver c'est que ça pourrait créer un régulier additionnel de l'équipement que nous devons suivre dans les différents pays. Et parfois, ce régulier de l'équipement, si vous appuyez à un système de fermeture, vous n'avez pas de choix. C'est oui ou non. Si vous appuyez à un système d'open source, puis à un opérateur, vous devez avoir de choix pour dire, OK, ce module, ce régulier de l'équipement, crée ce constrain, mais ce module est, on dirait, plus relaxé. Et c'est... Et puis, vous pouvez, on dirait, sourcer avec pas trop d'issues. Donc, si nous voulons l'écosystème, selon cette discussion, pour rester vraiment globale, puis, cette architecture d'open-run pourrait aider beaucoup. Donc, j'ai dit, 18 mois auparavant, nous avons créé l'alliance. Et plus recently, nous avons créé la communauté de software d'open-run qui a été introduite déjà par le professeur précédent. Et la façon dont nous avons fait ça est d'associer l'alliance Oran avec l'Linux Foundation. Et nous avons pensé, nous avons pensé beaucoup sur ça. Pourquoi faire ça avec l'Linux Foundation ? C'est parce que, dans le régime, nous n'avons pas un grand background, et l'Linux Foundation était probablement la meilleure option pour être, on dirait, un professeur et globale, large-scale, un moyen d'attracter le développeur, à proposer la documentation, à proposer le test et l'intégration, la méthodologie, et l'objet d'un software d'open source comme ceci. Bien sûr, cette communauté d'open-run qui est inclusée dans l'Linux Foundation est coordinée très tôt afin d'assurer que l'architecture qui est définie en Oran sera suivie. Donc, une grande date pour cette OSC est en novembre où la première édition, qui s'appelle Ember, de l'architecture devrait être échouée. Et ça va s'occuper de ce qu'on appelle le contrôle radio-intelligent qui est en charge, comme c'est dit, c'est-à-dire contrôler le réseau radio. Juste un mot sur le challenge. Donc, tout ce que j'ai dit est très, je veux dire, excité mais pour faire un succès, nous avons beaucoup de challenges, mais entre ces challenges, l'un d'entre eux est très tôt, très haut. C'est sur test et intégration. Donc, je peux vous dire que comme opérateur et comme racineur, nous avons bien sûr, intégré la racine avec l'architecture, avec tout l'environnement, avec différents interfaces, et tout ça. Mais comme opérateur, nous n'avons jamais vraiment intégré la racine. Un peu d'interface de la racine. Et c'est complexe. Nous ne devons pas vraiment l'estimer. C'est très complexe. Il pourrait prendre beaucoup de temps. Si vous n'avez pas d'assurance, vous avez la bonne méthodologie. Et donc, ce que nous commençons à faire maintenant c'est d'en comprendre comment nous pouvons faire efficacement. Donc, il y a beaucoup de choix que vous pouvez faire pour cette test et intégration. Donc, plus ou moins, vous pouvez aller votre propre façon comme orange. Nous disons, OK, je vais mettre test et intégration au centre. Ce sera seulement pour orange. Je vais demander les vendeurs. Et je vais mettre l'opensource module et les intégrateurs ensemble. Et ils vont faire surement que ça fonctionne à l'end. Et il y a un autre moyen de faire ça. C'est de discuter entre les différents opérateurs, discuter avec les vendeurs, discuter avec les développeurs et ainsi. Et essayer de dire, OK, dans cette test et intégration, il y a des choses que nous pouvons facturer que nous pouvons faire une fois pour l'écosystème. Et nous pouvons peut-être créer un multi-opérateur, multi-vendeurs, intégrateur, développeurs et so on. Certaines places où une grande partie de la test et intégration sera faite. Et sur ce point, bien sûr, nous devons mettre un seul opérateur d'intégration à l'end afin de faire surement que dans chaque et chaque des pays où nous opérons que la solution fonctionne. Bien sûr, nous avons des valeurs d'intégration pour faire. Mais probablement, vous pouvez faire 80% du travail qui est commun à plusieurs opérateurs. Et puis, 20% restant qui doit être managé par chaque et chaque opérateur. Donc, merci. C'est l'endement de mon speech. Et c'est le break, par contre.