Brevet FR3116689A1 — publié le 20220527

L’invention concerne un dispositif et un procédé de reconfiguration dynamique de la qualité de service ‘QoS’ dans un réseau de télécommunication. Le réseau comprend une pluralité d’équipements configurés pour émettre et/ou recevoir des flux de données transitant dans le réseau. Une configuration de QoS est prédéfinie lors d’une phase de préparation « hors ligne » qui prend en compte une pluralité de flux devant transiter dans le réseau, afin de calculer des changements de configuration de QoS à appliquer au réseau selon l’évolution des flux dans le réseau en phase « en ligne ». Le procédé comprend des étapes consistant : - à détecter une apparition ‘A’ ou une fin ‘F’ de flux dans le réseau ; - à déterminer si une évolution de flux est prévue par la configuration de QoS prédéfinie pour cette apparition ‘A’ ou cette fin ‘F’ de flux; - si l’évolution est prévue, à retrouver le changement de configuration de QoS à appliquer au réseau ; et - à appliquer ce changement de configuration de QoS au réseau. Figure pour l’abrégé : Fig.1 Procédé et dispositif de reconfiguration de la Qualité de Service dans un réseau Domaine de l’invention L’invention est dans le domaine technique des réseaux de télécommunication, et concerne plus particulièrement un procédé de reconfiguration dynamique de la Qualité de Service (QoS) dans un réseau de télécommunication et un dispositif pour sa mise en œuvre. Etat de la Technique La Qualité de Service (QoS) est la capacité à acheminer dans de bonnes conditions un type de flux donné au sein d’un réseau de télécommunication selon les besoins propres à ce type de flux, ces besoins de QoS pouvant s’exprimer par exemple en termes de disponibilité, débit, délais de transmission (latence), gigue, taux de perte de paquets, etc. En pratique la détermination de la configuration de la QoS est un problème technique complexe. En effet, les exigences de QoS des flux peuvent s’exprimer selon des métriques/paramètres très variés (p.ex. bande passante, latence, gigue, taux de perte de paquets minimum…) et les protocoles de QoS (et les paramètres de ces protocoles) peuvent également être très variés. Parmi les protocoles de QoS, on peut citer notamment les protocoles 802.1 Time Sensitive Network (TSN), qui visent à permettre, sur des réseaux Ethernet, la transmission de flux déterministes à fortes exigences temporelles (ex. synchronisation, latence de transmission bornée, latence garantie, très faible taux de perte de paquets…) et la coexistence harmonieuse de ceux-ci avec d’autres flux exposant d’autres types d’exigences de QoS (p.ex. débit minimum pour un flux audio ou vidéo). La suite de protocoles TSN regroupe aujourd’hui plus d’une vingtaine de protocoles, avec chacun de multiples paramètres. Ainsi la question de pouvoir déterminer si un réseau peut acheminer un ensemble de flux de données, chaque flux ayant des besoins de QoS spécifiques, et comment les acheminer (c’est-à-dire avec quelle configuration de la QoS dans le réseau), est un problème technique complexe de par la multiplicité des combinaisons possibles (i.e. une très grande taille de l’espace des configurations possibles) et des interactions non triviales entre les protocoles de QoS. L’état de l’art défini deux approches principales pour mettre en place une configuration de QoS au sein d’un réseau de communication : l’approche décentralisée et l’approche centralisée. Approche décentralisée : L’approche décentralisée s’appuie sur un protocole de réservation de ressources tel que le protocole « Resource Reservation Protocol » (RSVP) ou le protocole « Stream Reservation Protocol » (SRP) ce dernier s’appliquant dans le cadre des réseaux Ethernet 802.1 TSN. Ces protocoles permettent à un équipement « émetteur » à l’origine d’un flux devant être transmis dans le réseau, de réserver les ressources nécessaires au bon acheminement du flux (QoS) au niveau des équipements intermédiaires (par exemple des commutateurs ou « switchs » en anglais) le long de la route vers l’équipement « récepteur » au sein du réseau. Le flux ne peut être acheminé dans le réseau que si les ressources requises sont effectivement disponibles au niveau de tous les équipements intermédiaires. Dans le cas contraire l’acheminement du flux n’est pas autorisé, de manière à ne pas pénaliser les flux en cours. L’approche décentralisée ne permet toutefois pas d’assurer un usage optimal des ressources du réseau puisqu’elle peut engendrer des conflits entre plusieurs procédures de réservation concurrentes. Ceci résulte en un refus d’admission de plusieurs flux entrants, alors que le réseau dispose pourtant de suffisamment de ressources pour en admettre au moins un parmi eux. A titre d’illustration de ce problème, on peut prendre le cas de deux flux - « Src1Dest1 » et « Src2Dest2 » - devant simultanément entrer dans le réseau et devant transiter par une portion commune du réseau constituée des équipements intermédiaires (i.e. switchs) SW1, SW2 et SW3. Les deux procédures de réservation des ressources se déroulent en parallèle et celles pour le flux « Src1Dest1 » parvient à réserver les ressources requises sur SW1 et SW2 mais pas sur SW3 car ces ressources ont été à l’instant réservée pour le flux « Src2Dest2 » et il n’en reste plus suffisamment pour le flux « Src1Dest1 ». De la même manière, les switchs SW1 et SW2 ne disposent également plus de ressources pour satisfaire la demande du flux « Src2Dest2 ». Dans ce scénario, les deux flux « Src1Dest1 » et « Src2Dest2 » se voient donc refuser l’accès au réseau, alors qu’en principe les équipements SW1, SW2 et SW3 disposaient de suffisamment de ressources pour acheminer l’un d’entre eux. Les ressources du réseau sont donc sous-exploitées. Approche centralisée : L’approche centralisée vise à résoudre le problème précédent en s’appuyant sur une unique entité fonctionnelle au sein du réseau apte à mettre en place une réservation de ressources auprès des équipements du réseau. Dans le cas des réseaux Ethernet 802.1 TSN, cette approche est définie par le modèle IEEE 802.1Qcc qui permet au CNC/CUC (« Centralized Network Configuration / Centralized User Configuration ») de communiquer avec chacun des équipements du réseau pour mettre en place la réservation des ressources. Le modèle IEEE précité ne définit toutefois pas explicitement comment déterminer si un nouveau flux peut ou non être acheminé dans le réseau (sur la base de ses besoins en QoS et des flux déjà en cours dans le réseau). Il ne définit pas non plus quelle configuration mettre en place pour ce nouveau flux. Notamment, compte tenu de la multiplicité des configurations de QoS envisageables pour un nouveau flux (liées à la multiplicité des protocoles TSN et des paramètres de ces protocoles), le CNC/CUC doit être en mesure (a) de déterminer la configuration de QoS réseau applicable/acceptable à ce nouveau flux (c’est-à-dire déterminer quel protocole et quels paramètres appliquer) et (b) de vérifier si cette configuration peut effectivement être mise en place dans le réseau (sur la base des ressources restantes). Même si la vérification (b) peut être réalisée par le CNC/CUC en interagissant avec les équipements du réseau (i.e. les switchs) pour vérifier si les ressources correspondant à une configuration de QoS donnée sont disponibles, cette approche n’est pas suffisante sans une connaissance de la configuration de QoS réseau applicable/acceptable pour ce flux. La détermination (a) de la configuration de QoS réseau applicable/acceptable pour un flux et la vérification (b) que celle-ci peut être mise en place dans le réseau, peuvent être réalisées « hors ligne », c’est-à-dire avant de mettre en place le réseau, grâce à des méthodes et des outils de simulation de réseaux hors-ligne. De tels outils sont connus, comme par exemple l’outil (ou suite logicielle) de simulation RTaW-Pegase pour les réseaux TSN, qui peut s’appuyer sur la modélisation des ressources du réseau et la combinaison d’algorithmes « d’exploration d’espace de conception » (« design space exploration » en anglais) et de méthodes de « calcul réseau » (« network calculus » en anglais). Ces outils prennent comme données d’entrée la topologie du réseau, les caractéristiques des flux à acheminer dans le réseau (c’est-à-dire la source et la destination du flux, les exigences de QoS du flux) et les protocoles TSN supportés par le réseau. Ils peuvent produire en sortie (si elle existe) une configuration globale/unique de la QoS à appliquer au sein du réseau, de manière à satisfaire les exigences de QoS de l’ensemble du flux dans le respect des ressources disponibles dans le réseau. Cette configuration de QoS globale/unique du réseau définit ainsi la configuration de QoS à appliquer au niveau de chacun des équipements du réseau. Un algorithme « d’exploration d’espace de conception » connu tel que « ZeroConfig-TSN » pour les réseaux TSN fonctionne (a) en créant de manière itérative des solutions candidates (c’est-à-dire en créant des configurations de QoS réseau candidates pour l’ensemble des flux) et (b) en évaluant pour chacune de ces solutions candidates (via des méthodes d’analyse d’ordonnançabilité ou de calcul réseau) si les exigences sont satisfaites (c’est-à-dire si les exigences de QoS de tous les flux sont satisfaites pour cette configuration et si elle est applicable au réseau compte tenu des ressources dont il dispose). Cette approche de génération d’une configuration de QoS réseau par l’utilisation de méthodes et outils de simulation hors-ligne présentent toutefois plusieurs inconvénients : - Ils ne sont applicables que pour des systèmes ou réseaux dits « fermés » c’est-à-dire des réseaux où l’on connait dès la conception de manière précise l’ensemble des flux qui doivent transiter sur le réseau. - Ils sont extrêmement coûteux en termes de temps de calcul (même sur des environnements de calcul très performants) de par l’explosion des configurations à évaluer, et ils ne peuvent donc pas être utilisés « en ligne » dans l’optique de déterminer rapidement une nouvelle configuration réseau à mettre en place au sein d’un réseau déjà déployé, par exemple lorsqu’un nouveau flux apparait. - Ils ne permettent pas de calculer rapidement un changement de configuration à appliquer dans un réseau lorsqu’un nouveau flux apparait. En effet, la configuration initiale du réseau n’étant pas une donnée d’entrée de ces méthodes et outils, il est nécessaire de refaire le calcul complet de la configuration globale du réseau même si un seul flux est rajouté (il n’y a pas de possibilité d’un nouveau calcul incrémental pour une nouvelle configuration à partir d’une configuration initiale). - Ils ne permettent pas d’assurer un usage optimal des ressources du réseau une fois déployé puisque ces méthodes et outils font l’hypothèse que tous les flux coexistent dans le réseau, en calculant une configuration de QoS unique pour le réseau qui sera utilisée sur toute sa durée de vie. Hors, en pratique, il arrive très souvent (même sur des systèmes fermés) que tous les flux susceptibles de transiter à un moment sur le réseau ne coexistent pas en permanence (certains peuvent apparaitre ou disparaitre selon l’état du système qui utilise ce réseau). Ces méthodes et outils de simulation hors ligne impliquent donc de devoir sur-dimensionner les ressources matérielles (et donc le coût des équipements réseau) pour acheminer l’ensemble des flux, ou au contraire impliquent une limitation fonctionnelle (et donc avoir moins de flux possibles pour des ressources réseau prédéfinies). Une variante des méthodes & outils de simulation hors-ligne utilisés pour la génération d’une configuration de QoS réseau unique/globale, consiste à remplacer dans la phase de vérification des solutions candidates, l’usage des méthodes d’analyse d’ordonnançabilité ou de calcul réseau par des méthodes d’apprentissage automatique (« Machine Learning » en anglais) afin d’améliorer les temps de calcul. L’article de N. Navet, T.L. Mai, J. Migge, “Using Machine Learning to Speed Up the Design Space Exploration of Ethernet TSN networks“, Technical Report, January 2019 décrit une telle approche. Cette approche requiert une phase d’apprentissage au cours de laquelle un algorithme de Machine Learning (ML) est entrainé à partir de données préalablement générées et stockées dans une base de données d’apprentissage. Des approches de type apprentissage supervisé (« supervised learning » en anglais) ou de type apprentissage non supervisé (« unsupervised learning » en anglais) peuvent être utilisées. Les données utilisées lors de la phase d’apprentissage sont représentatives (1) de la topologie du réseau, (2) des caractéristiques des flux à acheminer dans le réseau (c’est-à-dire la source et la destination du flux, les exigences de QoS du flux), (3) de configurations QoS réseau candidates générées en grandes quantités, et (4) de l’applicabilité de chacune de ces configurations QoS réseau candidates pour satisfaire les exigences de QoS des flux à acheminer dans le réseau. Cette dernière partie (4) doit être générée préalablement en utilisant des méthodes d’analyse d’ordonnançabilité ou de calcul réseau, ce qui représente donc une charge de calcul (et un temps important) pour générer la base de données d’apprentissage qui serait ensuite utilisée dans la phase d’apprentissage (supervisée ou non supervisée). Une fois l’algorithme de ML entrainé grâce à la base de données d’apprentissage, celui-ci peut alors être utilisé pour estimer / prédire la configuration de QoS réseau applicable pour des scénarios (i.e. des topologies de réseau ou des caractéristiques nouvelles des flux) ne faisant pas partie de la base de données d’apprentissage (là encore en testant de manière itérative des solutions candidates jusqu’à trouver une solution satisfaisante). L’avantage est un temps de détermination d’une solution candidate satisfaisante a priori plus rapide qu’avec les outils de simulation hors-ligne classiques grâce à l’usage du ML dans cette phase d’évaluation des solutions candidates. Un inconvénient majeur reste toutefois que cette approche n’est pas exacte (par l’existence de faux positifs) et qu’elle ne peut donc pas garantir à coup sûr qu’une configuration de QoS réseau candidate qui aura été estimée / prédite comme satisfaisante selon cette approche ML est effectivement satisfaisante en pratique. Ainsi, une marge d’erreur et donc un risque éventuel persistent avec cette approche. Aussi, il existe un besoin pour des solutions au problème technique de « comment faire coexister harmonieusement plusieurs flux de données au sein d’un même réseau de télécommunication, sachant que chacun des flux peut avoir des besoins et des exigences (nécessaires au bon acheminement des flux) en termes de Qualité de Service très différents et hétérogènes, et sachant que les ressources du réseau sont limitées ? ». Une telle solution doit lever les inconvénients des approches connues et doit permettre de : - déterminer si un nouveau flux peut ou non être accepté et acheminé au sein d’un réseau en lui offrant la QoS (c’est-à-dire les ressources réseaux) dont il a besoin et sans compromettre la QoS (c’est-à-dire les ressources réseaux) des autres flux déjà présents dans le réseau ; et si un nouveau flux peut être accepté, - déterminer quelle reconfiguration de la QoS doit être mise en place dans le réseau. La présente invention répond à ces besoins. Un objet de la présente invention est de proposer un procédé de reconfiguration dynamique de la Qualité de Service (QoS) dans un réseau de télécommunication, notamment un réseau TSN, permettant de déterminer la configuration de QoS à appliquer au sein d’un réseau. Avantageusement, le procédé de l’invention permet de déterminer une configuration de la QoS à appliquer au sein d’un réseau qui permet d’optimiser l’usage des ressources du réseau, c’est-à-dire capable d’acheminer plus de flux, avec plus d’exigences de QoS, que les méthodes et outils de simulation hors-ligne connus, pour des ressources réseau prédéfinies. Avantageusement le procédé de l’invention est applicable à un système ouvert, c’est-à-dire un système ou un réseau dans lequel tous les flux ne sont pas nécessairement tous connus a priori lors de la conception du réseau. Avantageusement le procédé de l’invention est apte à déterminer une nouvelle configuration optimale du réseau, si elle est possible, à chaque instant lorsque le système évolue, c’est-à-dire lors de l’arrivée ou de la fin d’un flux. Avantageusement le procédé de l’invention est capable dès que nécessaire, de déterminer rapidement, i.e. dynamiquement, une nouvelle configuration optimale « en ligne », c’est-à-dire lorsque que le réseau est déployé et en opération. Avantageusement le procédé de l’invention est apte à garantir que le système reste sûr, c’est-à-dire que de nouveaux flux ne sont pas acceptés si leur QoS ne peut pas être garantie sans impacter la QoS des autres flux existants dans le réseau. Un autre objet de l’invention est de proposer un dispositif qui comprend des moyens permettant de mettre en œuvre le procédé de l’invention. Avantageusement, le procédé de l’invention permet, lors de l’apparition d’un nouveau flux au sein du réseau, de reconfigurer dynamiquement les paramètres de gestion de la QoS du réseau de manière à prendre en charge ce nouveau flux selon ses propres besoins de QoS, sans compromettre la QoS des autres flux déjà présents dans le réseau. En d’autres termes, le procédé de l’invention permet d’allouer au sein du réseau les ressources nécessaires au bon acheminement d’un nouveau flux sans compromettre les ressources préalablement allouées aux autres flux. L’invention s’applique tout particulièrement dans le cas d’une gestion centralisée de la QoS dans un réseau où une entité (éventuellement virtualisée) au sein du réseau est en charge de la gestion de la configuration de la QoS du réseau. Ainsi, l’invention trouve une application avantageuse aux cas des réseaux déterministes et notamment les réseaux de type Ethernet 802.1 Time Sensitive Network (TSN). Les domaines d’application industrielle de l’invention sont multiples mais couvrent en priorité les réseaux industriels (domaines de l’usine du future, industrie 4.0 / usines fortement reconfigurables) et les réseaux intra-véhiculaires (domaines de véhicules de tout type : automobile, camions, bus, train, bateau…). A titre d’exemple, dans le domaine de l’automobile, qui s’appuie traditionnellement sur des réseaux intra-véhiculaires fermés, l’invention permet de réduire les coûts et la complexité des équipements réseau à déployer dans un véhicule, permet d’intégrer plus de fonctionnalités au véhicule (pour des ressources réseau prédéfinies). L’invention permet par ailleurs (à travers sa prise en charge des réseaux ouverts) de pouvoir rajouter de nouvelles options à un véhicule (c’est-à-dire de nouveaux flux à transmettre via le réseau intra-véhicule) très facilement sans requérir un re-paramétrage en profondeur du véhicule par un professionnel dans un garage. De manière générale, le procédé de l’invention pour reconfigurer de manière dynamique la QoS dans un réseau, s’articule autour de deux phases, une première phase de préparation « hors ligne » des multiples configurations de QoS à appliquer au sein du réseau selon l’évolution des flux transitant sur le réseau, et une deuxième phase consistant à mettre en place dynamiquement « en ligne » au sein du réseau les changements de configuration de QoS réseau prédéterminés, selon l’apparition de nouveaux flux ou la terminaison de flux existants au sein du réseau. Dans un mode de réalisation, la première phase hors ligne comprend au moins un enchaînement d’étapes consistant à : générer un « Diagramme de Coexistence Temporelle des flux » (DCT) au sein du réseau, en prenant en compte les flux connus a priori ; déduire l’ensemble des groupes de flux coexistant (Gi) à chaque instant donné au sein du réseau, à partir du DCT ; générer un « Graphe des Transitions » (GT) entre ces groupes de flux coexistant, chaque transition correspondant à une arrivée (A) d’un nouveau flux ou à la fin (F) d’un flux ; calculer la configuration de QoS réseau à appliquer pour chaque groupe de flux coexistant Gi (c’est-à-dire pour chaque nœud du GT), notée Config(Gi) ; calculer le changement de configuration de QoS réseau DeltaConfig(GiGj) à appliquer au réseau pour accompagner chaque transition du GT (par exemple la transition entre les groupes de flux coexistant Gi et Gj) ; stocker le Graphe des Transitions (GT) et l’ensemble des changements de configuration de QoS réseau associés aux transitions (DeltaConfig(GiGj)) dans un système de configuration réseau centralisé, en charge d’assurer la configuration de QoS d’un réseau « en ligne » (en opération, une fois déployé). Dans un mode de réalisation, le calcul de la configuration Config(Gi) consiste à utiliser un outil de simulation « hors ligne ». Dans un mode de réalisation, le changement de configuration de QoS réseau est défini par l’ensemble le plus petit possible (et donc le plus rapide à mettre en place) des commandes de reconfiguration de QoS du réseau à appliquer au réseau pour accompagner la transition (i.e. apparition (A) d’un nouveau flux ou fin (F) d’un flux existant) d’un groupe de flux coexistant initial (Gi) vers un groupe de flux coexistant final (Gj), et donc pour passer de la configuration de QoS réseau initiale (avant la transition) à la configuration de QoS réseau finale (après la transition). Dans une application au réseau TSN, le système de configuration réseau centralisé pour stocker le Graphe des Transitions (GT) peut être le CNC/CUC du réseau TSN. Dans un mode de réalisation, la mise en œuvre de la deuxième phase se fait sur la base des informations stockées dans le système de configuration centralisé. Pour obtenir les résultats recherchés, il est proposé un procédé de reconfiguration dynamique de la qualité de service ‘QoS’ dans un réseau de télécommunication qui comprend une pluralité d’équipements configurés pour émettre et/ou recevoir des flux de données transitant dans le réseau. Le réseau a une configuration de QoS qui est prédéfinie lors d’une phase de préparation « hors ligne » qui prend en compte une pluralité de flux devant transiter dans le réseau, afin de calculer des changements de configuration de QoS à appliquer au réseau selon l’évolution des flux dans le réseau, une évolution correspondant à une apparition ‘A’ d’un flux ou à une fin ‘F’ d’un flux. Le procédé est mis en œuvre par ordinateur et comprend des étapes consistant : - à détecter une apparition ‘A’ ou une fin ‘F’ de flux dans le réseau ; - à déterminer si une évolution de flux est prévue par la configuration de QoS prédéfinie pour cette apparition ‘A’ ou cette fin ‘F’ de flux; - si l’évolution est prévue, à retrouver le changement de configuration de QoS à appliquer au réseau ; et - à appliquer le changement de configuration de QoS au réseau. Selon des modes de réalisation alternatifs ou combinés : - le procédé comprend de plus, si l’évolution de flux prévue est l’apparition ‘A’ d’un flux dans le réseau, une étape d’accepter le flux dans le réseau. - le procédé comprend après l’étape de déterminer si l’apparition ‘A’ d’un flux est prévue par la configuration de QoS prédéfinie, une étape de refuser le flux si l’apparition ‘A’ dudit flux n’est pas prévue par la configuration de QoS prédéfinie. - le procédé comprend après l’étape de déterminer si l’évolution ‘A’ ou ‘F’ de flux est prévue par la configuration de QoS prédéfinie, une étape de générer une notification d’erreur si l’évolution n’est pas prévue par la configuration de QoS prédéfinie. - la phase de préparation « hors ligne » comprend des étapes consistant à : - générer un diagramme de coexistence temporelle des flux ‘DCT’ au sein du réseau, pour lister les différents flux connus a priori du réseau et les temps où ces flux apparaissent et disparaissent ; - calculer à partir du DCT, l’ensemble des groupes de flux coexistant ‘Gi’ à chaque instant donné au sein du réseau ; - générer un graphe des transitions ‘GT’ entre les groupes de flux coexistant, chaque transition correspondant à une arrivée ‘A’ d’un nouveau flux ou à la fin ‘F’ d’un flux connu ; - calculer une configuration de QoS réseau ‘Config(Gi)’ pour chaque groupe de flux coexistant Gi ; - calculer le changement de configuration de QoS réseau ‘DeltaConfig(GiGj)’ à appliquer au réseau pour chaque transition du GT ; et - stocker le GT et l’ensemble des changements de configuration de QoS réseau associés aux transitions dans une base d’information d’un système de configuration réseau en charge d’assurer la configuration de QoS dudit réseau. - l’étape de déterminer si l’évolution de flux est prévue par la configuration de QoS prédéfinie, consiste à vérifier dans le graphe des transitions, si une transition existe pour ladite évolution de flux qui est détectée pour l’état courant Gi du graphe des transitions GT. - l’étape de retrouver le changement de configuration de QoS à appliquer au réseau, comprend une étape de déterminer l’état final Gj du graphe des transitions GT après ladite transition. - le procédé comprend après l’étape d’appliquer ledit changement de configuration de QoS au réseau, une étape de mettre à jour l’état courant Gi du graphe des transitions avec l’état final Gj, puis revenir à une étape de surveillance du réseau. - le procédé comprend de plus si l’évolution pour l’apparition ‘A’ dudit flux n’est pas prévue par la configuration de QoS prédéfinie, des étapes permettant de vérifier si ledit flux peut être accepté ou non dans le réseau comme un nouveau flux, lesdites étapes comprenant au moins une étape d’appliquer un changement de configuration de QoS du réseau si ledit flux peut être accepté comme nouveau flux. - le procédé comprend de plus si l’évolution pour la fin ‘F’ dudit flux n’est pas prévue par la configuration de QoS prédéfinie, des étapes permettant de déterminer si un changement de configuration de QoS du réseau doit être appliqué. L’invention concerne aussi un dispositif de reconfiguration dynamique de la qualité de service ‘QoS’ dans un réseau de télécommunication comprenant une pluralité d’équipements configurés pour émettre et/ou recevoir des flux de données transitant dans le réseau, ledit réseau ayant une configuration de QoS prédéfinie lors d’une phase de préparation « hors ligne » prenant en compte une pluralité de flux devant transiter dans ledit réseau afin de calculer des changements de configuration de QoS à appliquer au réseau selon l’évolution des flux dans le réseau, une évolution correspondant à une apparition ‘A’ d’un flux ou à une fin ‘F’ d’un flux, le dispositif comprenant des moyens pour mettre en œuvre les étapes du procédé de l’invention de reconfiguration dynamique de la qualité de service ‘QoS’ dans le réseau de télécommunication. Dans un mode de réalisation, le réseau de télécommunication est soit un réseau dit fermé où tous les flux transitant sur le réseau sont a priori connus, et où la phase de préparation « hors ligne » prend en compte tous les flux connus a priori, soit un réseau dit ouvert où des flux non connus a priori peuvent transiter sur le réseau, et où la phase de préparation « hors ligne » prend en compte des flux connus a priori. Dans un mode de réalisation, le réseau de télécommunication est un réseau déterministe, notamment un réseau de type Ethernet 802.1 Time Sensitive Network. L’invention concerne aussi un système de configuration réseau centralisé pour réseau déterministe, notamment pour un réseau de type Ethernet 802.1 Time Sensitive Network, le système comprenant un contrôleur en charge de gérer les configurations de QoS dudit réseau, ledit contrôleur étant un contrôleur SDN couplé à une entité fonctionnelle qui comprend des applications logicielles de type service SDN, et notamment une application logicielle permettant d’effectuer les étapes du procédé de l’invention. L’invention concerne aussi un produit programme d’ordinateur qui comprend des instructions de code permettant d’effectuer les étapes du procédé de l’invention, lorsque le programme est exécuté sur un ordinateur. Description des figures D’autres caractéristiques et avantages de l’invention apparaîtront à l’aide de la description qui suit et des figures des dessins annexés dans lesquels : La illustre un exemple d’architecture réseau permettant d’implémenter le procédé de l’invention ; La est un organigramme des principales étapes des deux phases « hors ligne » et « en ligne » du procédé de l’invention ; La montre un exemple de diagramme de coexistence temporelle (DCT) des flux dans un réseau ; La montre un exemple de groupes de flux coexistant (Gi) au sein d’un diagramme de coexistence temporelle ; La montre un exemple de Graphe de Transition (GT) ; La est un organigramme des étapes du procédé opéré pour la phase en ligne dans le cas d’un réseau fermé ; La est un organigramme d’étapes complémentaires du procédé de reconfiguration en ligne de l’invention, pour le traitement de l’arrivée d’un flux, dans le cas de réseaux ouverts ou de réseaux fermés avec un GT incomplet ; La est un diagramme illustrant un exemple du traitement de l’arrivée inattendue d’un flux connu selon un mode de réalisation de l’invention; La est un diagramme illustrant un exemple du traitement de l’arrivée inattendue d’un flux inconnu selon un mode de réalisation de l’invention; La est un organigramme d’étapes complémentaires du procédé de reconfiguration en ligne de l’invention, pour le traitement de la fin d’un flux, dans le cas de réseaux ouverts ou de réseaux fermés avec un GT incomplet; et La est un diagramme illustrant un exemple du traitement de la fin d’un flux selon un mode de réalisation de l’invention. Description détaillée de l’invention Il est adopté pour la description d’un mode de réalisation de l’invention, les notations et définitions suivantes : QoS : la Qualité de service ; DCT : le Diagramme de coexistence temporelle des flux ; Fi : le flux ‘i’ ; Src(fi) : l’équipement source du flux fi ; Dest(fi) : l’équipement destinataire du flux fi ; Gi : l’ensemble de groupes de flux coexistant à chaque instant donné au sein d’un réseau ; GT : le Graphe des Transitions ; A(fi) : l’arrivée d’un nouveau flux fi ou flux arrivant ; F(fi) : la fin d’un flux fi existant ; Config(Gi) : la configuration de QoS calculée pour le groupe de flux Gi ; DeltaConfig(GiGj) : le changement de configuration de QoS réseau pour accompagner une transition Gi à Gj ; DeltaConfig(A(fi)) : le changement de configuration de QoS réseau associée à l’arrivée d’un nouveau flux fi ; TSN : un Réseau sensible au temps et les protocoles 802.1 ; CNC/CUC : Contrôleur de réseau central / Configuration utilisateur centralisée ; QoSreq(fi) : les exigences de QoS pour le flux fi ; Ti : une transition ‘i’ entrante ou sortante. La illustre un exemple d’environnement permettant d’implémenter et de mettre en œuvre le procédé de l’invention. L’architecture prise à titre d’exemple non limitatif, est basée sur un réseau TSN 100 avec un système de configuration réseau centralisé (CNC/CUC) en charge de gérer les configurations de QoS dans le réseau TSN qui est orienté « SDN », acronyme signifiant « Software Defined Network » en anglais. Pour l’homme de l’art, une approche dite SDN correspond à un modèle d’architecture réseau qui permet aux administrateurs de réseaux de gérer les services de réseaux par abstraction de fonctionnalités, de contrôler ou de configurer le réseau de manière intelligente et centralisée à l’aide d’applications logicielles. Cela consiste en un ensemble de technologies ayant comme points communs : - un contrôle centralisé des ressources réseau ; - une orchestration centralisée ; - une virtualisation des ressources physiques. Le réseau TSN est composé d’une pluralité d’équipements 102 qui sont sources et/ou destinataires des flux de données dans le réseau TSN (les « EndNodes TSN » en anglais). Les équipements 102 sont connectés à des commutateurs 104 via des liens Ethernet 106. Le système de configuration réseau centralisé comprend un contrôleur SDN 110 couplé à une entité fonctionnelle 108 qui comprend des applications logicielles de type service SDN, et qui comprend notamment une application logicielle permettant d’effectuer les étapes du procédé revendiqué. L’entité fonctionnelle 108 implémentée sur la forme de service SDN (i.e. service réseau virtualisé) s’interface au contrôleur SDN 110 via l’interface « Northbound » 109 du contrôleur. Le contrôleur SDN 110 s’interface avec le réseau TSN via son interface « Southbound », notamment vers les commutateurs TSN 104 et optionnellement directement vers les EndNodes TSN 102. Dans un mode de réalisation, le service SDN est implémenté au sein du CNC/CUC comme un programme d’ordinateur comprenant des instructions de code permettant d’effectuer les étapes du procédé de l’invention en phase opérationnelle du réseau. Sur la base de l’exemple décrit pour un réseau TSN, l’homme du métier pourra dériver des variantes d’implémentation du procédé de l’invention pour d’autres réseaux de type filaires ou sans-fils, notamment des réseaux déterministes, tels que : - Deterministic Networking (detnet); - IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch); - Ultra-reliable and low latency communication (URLLC) (TR 38.824, Study on physical layer enhancements for NR ultra-reliable and low latency case (URLLC)); - « Avionics Full-Duplex Switched Ethernet (AFDX) »; - ... La est un organigramme illustrant les principales étapes des deux phases du procédé de l’invention, une phase de préparation « hors ligne » 200 et une phase de mise en œuvre « en ligne » 220. Le procédé de l’invention est décrit pour l’exemple d’un réseau fermé, c’est-à-dire un réseau pour lequel il est connu de manière précise dès la conception, l’ensemble des flux qui doivent transiter sur le réseau. Le réseau peut être un réseau TSN comme celui de la . Afin de reconfigurer dynamiquement la QoS dans un réseau opérationnel, une phase initiale « hors ligne » 200 permet de générer un ensemble de configurations de QoS à appliquer au sein du réseau selon l’évolution des flux transitant sur le réseau, i.e. selon l’évolution du système au sein duquel le réseau est utilisé. Dans un mode de réalisation, la première phase hors ligne comprend une première étape 202 consistant à générer un diagramme de coexistence temporelle des flux (DCT) au sein du réseau, en prenant en compte les flux connus a priori. La montre un exemple de (DCT) des flux dans un réseau, pour neuf flux f1 à f9. Sur l’exemple illustré, le flux f1peut coexister avec zéro, un ou plusieurs des flux f2 à f9 sur différentes plages de temps de durées variables. Pour un réseau simple, typiquement constitué de quelques flux, associé à un système dont le fonctionnement est facilement modélisable, comme par exemple un système périodique (i.e. un système dans lequel les flux sont initiés et terminés de manière périodique, la période d’apparition de chacun des flux dans le réseau étant connue a priori), la modélisation peut être réalisée de manière manuelle par les concepteurs du système, par exemple sur la base d’une connaissance précise de la causalité entre flux, de la périodicité des flux, etc.. De manière plus générale, le DCT peut être généré dynamiquement en utilisant des outils numériques de simulation du système considéré au sein duquel est utilisé le réseau en question. Un tel outil est connu sous la désignation de « jumeau numérique » (ou « digital twin » ou « device shadow » en anglais), et permet de modéliser le fonctionnement du système, sans que cet outil toutefois n’ait besoin d’être en mesure de simuler de manière précise ledit réseau. Un jumeau numérique est une réplique numérique d'un objet, d'un processus ou d'un système qui peut être utilisé à diverses fins. La représentation numérique fournit à la fois les éléments et la dynamique de fonctionnement d'un dispositif de l'Internet des objets tout au long de son cycle de vie. Les jumeaux numériques intègrent l'intelligence artificielle, l'apprentissage automatique et l'analyse des données avec des données pour créer des modèles de simulation numérique qui se mettent à jour et changent à mesure que leurs contreparties physiques changent. Un jumeau numérique apprend en permanence et se met à jour en utilisant de multiples sources pour représenter son statut, sa condition de travail ou sa position en temps quasi réel. Ce système d'apprentissage, apprend de lui-même, en utilisant : des données de capteurs qui transmettent divers aspects de son état de fonctionnement; d'experts humains, tels que des ingénieurs ayant une connaissance approfondie et pertinente du domaine industriel; d'autres machines similaires; d'autres flottes de machines similaires ; et de systèmes plus vastes et de l'environnement desquels il fait partie. Un jumeau numérique intègre également des données historiques de l'utilisation passée de la machine qu'il intègre à son modèle numérique. Dans divers secteurs industriels, les jumeaux numériques sont utilisés pour optimiser le fonctionnement et la maintenance des actifs physiques, des systèmes et des processus de fabrication. Les jumeaux numériques constituent une technologie de formation pour l'Internet industriel des objets, où les objets physiques peuvent vivre et interagir virtuellement avec d'autres machines et personnes. Dans ce contexte d'Internet des Objets, ils sont parfois mentionnés sous l'appellation « cyberobjets » ou « avatars digitaux ». Il existe différent types d’outils de simulation de systèmes complexes tels que par exemple « Papyrus » qui peut être utilisé comme un jumeau numérique fonctionnel d’un système ou encore « XDE » qui peut être utilisé en partie comme un jumeau numérique physiquement réaliste apte à prendre en charge une simulation multi-physique et interactive d’un système. Pour être en mesure de générer le DCT d’un réseau, l’outil numérique de simulation du système doit seulement être en mesure de simuler différents scénarios d’usage du système, et de simuler les interactions entre les composants du système qui engendrent l’apparition ou la terminaison d’un flux de données sur le réseau, sans avoir à simuler lesdits flux de données ni les protocoles réseaux associés. L’homme du métier comprend qu’il est recommandé de simuler de manière la plus exhaustive possible l’ensemble des cas d’utilisation possibles du système, de manière à générer un DCT qui puisse être le plus complet et réaliste possible. Dans un mode de réalisation, le DCT est implémenté sous la forme d’une base de donnée qui liste les différents flux du réseau et les temps (lors de la simulation) où ces flux apparaissent et disparaissent. Revenant à la , le procédé poursuit avec une étape 204 consistant à déterminer l’ensemble des groupes de flux coexistant (Gi) à chaque instant donné au sein du réseau. La montre un exemple de groupes de flux coexistant (Gi) au sein du diagramme de coexistence temporelle de la . Ainsi, le procédé permet d’identifier que les groupes de flux coexistant qui peuvent apparaitre dans le système sont les suivants : Ø : lorsque aucun flux ne transite sur le réseau G1 : constitué du seul flux {f1} G2 : constitué des flux {f1, f2} G3 : constitué des flux {f1, f2, f3} G4 : constitué des flux {f1, f2, f3, f4} G5 : constitué des flux {f1, f2, f4} G6 : constitué des flux {f1, f4} G7 : constitué des flux {f1, f4, f6} G8 : constitué des flux {f1, f6} G9 : constitué des flux {f1, f5, f6} G10 : constitué des flux {f1, f5} G11 : constitué des flux {f1, f5, f7} G12 : constitué des flux {f1, f5, f8, f9}. On notera qu’un même groupe de flux coexistant (Gi) peut naturellement apparaitre plusieurs fois au sein du DCT sur des plages temporelles disjointes, tels que par exemple les groupes G1 et G10 pour l’exemple utilisé. Selon la précision de la modélisation temporelle du DCT, i.e. le pas de temps minimal utilisé, il peut arriver que le DCT indique que plusieurs flux apparaissent ou disparaissent simultanément dans le réseau, alors qu’en pratique le système d’admission et de configuration de la QoS réseau ne pourra gérer l’admission de ces flux que de manière séquentielle. C’est par exemple le cas pour les flux f8 et f9 dans l’exemple de la . Pour adresser ce cas particulier, le procédé de l’invention définit qu’une transition entre deux groupes de flux coexistant, par exemple une transition entre le groupe Gi et le groupe Gj, ne peut concerner qu’un seul et unique flux, i.e. l’arrivée d’un nouveau flux ou la terminaison d’un flux existant, et ainsi de considérer que plusieurs flux qui semblent arriver simultanément dans le réseau selon le DCT, peuvent indifféremment (en pratique) arriver les uns avant les autres. De manière similaire, le procédé définit que plusieurs flux qui semblent se terminer simultanément dans le réseau selon le DCT, peuvent indifféremment (en pratique) se terminer les uns avant les autres. La conséquence est alors l’apparition et la prise en compte de nouveaux groupes de flux coexistant, correspondants à ces multiples configurations. En reprenant l’exemple du DCT de la , dans le cas des flux f8 et f9 qui apparaissent et disparaissent simultanément, le procédé permet de considérer en plus du groupe G12 de la , les groupes de flux coexistant supplémentaires suivants : G12a : constitué des flux {f1, f5, f8} ; et G12b : constitué des flux {f1, f5, f9}. L’intégralité des groupes de flux coexistant (Gi) qui est pris en compte par le procédé de l’invention est alors : Ø : lorsque aucun flux ne transite sur le réseau G1 : constitué du seul flux {f1} G2 : constitué des flux {f1, f2} G3 : constitué des flux {f1, f2, f3} G4 : constitué des flux {f1, f2, f3, f4} G5 : constitué des flux {f1, f2, f4} G6 : constitué des flux {f1, f4} G7 : constitué des flux {f1, f4, f6} G8 : constitué des flux {f1, f6} G9 : constitué des flux {f1, f5, f6} G10 : constitué des flux {f1, f5} G11 : constitué des flux {f1, f5, f7} G12 : constitué des flux {f1, f5, f8, f9} G12a : constitué des flux {f1, f5, f8} G12b : constitué des flux {f1, f5, f9}. Revenant à la , le procédé poursuit avec une étape 206 consistant à générer un Graphe des Transitions (GT) entre les groupes de flux coexistant (Gi). La montre un Graphe de Transition (GT) généré à partir des groupes de flux coexistant pour l’exemple choisi des groupes (Ø à G12b). Chaque transition dans le graphe GT correspond soit à une arrivée d’un nouveau flux (A), soit à la fin (F) d’un flux existant, une transition étant directionnelle, partant d’un groupe initial/source et arrivant à un groupe final/destination. Ainsi, la transition du groupe Ø où aucun flux ne circule sur le réseau, au groupe G1 où seul le flux f1 circule sur le réseau correspond à l’arrivée A(f1) du flux f1. A titre d’un autre exemple, la transition du groupe G11 où les flux f1, f5 et f7 circulent sur le réseau, au groupe G10 où les flux f1 et f5 circulent sur le réseau, correspond à la fin F(f7) du flux f7 sur le réseau. Le graphe GT montre aussi une transition A(f7) du groupe G10 vers le groupe G11, correspondant à l’arrivée du flux f7. L’homme du métier comprend donc qu’il peut exister entre deux groupes Gi et Gj, soit une seule transition de type (A) ou (F), soit deux transitions (A) et (F), l’une de Gi vers Gj et l’autre de Gj vers Gi, ces deux transitions étant alors de « type opposé » : l’une est de type arrivée de flux (A) et l’autre de type fin de flux (F). Revenant à la , le procédé poursuit avec une étape 208 consistant, pour chaque groupe de flux coexistant (Gi), à calculer la configuration de QoS réseau Config(Gi) à appliquer. Dans un mode de réalisation, le calcul de la configuration de QoS réseau pour chaque nœud du graphe de transitions, est fait en utilisant une méthode, un outil de simulation « hors ligne » tels que ceux précités. Une fois l’ensemble des configurations QoS réseau calculées, le procédé continue avec une étape 210 consistant, pour chaque transition du GT, par exemple la transition entre les groupes de flux coexistant Gi et Gj, à calculer le changement de configuration de QoS réseau « DeltaConfig(GiGj) » à appliquer au réseau pour accompagner cette transition. Dans un mode de réalisation, le changement de configuration de QoS réseau est défini par l’ensemble le plus petit possible (et donc le plus rapide à mettre en place) des commandes de reconfiguration de QoS du réseau à appliquer au réseau pour accompagner la transition (i.e. apparition d’un nouveau flux ou fin d’un flux existant) d’un groupe de flux coexistant initial (Gi) vers un groupe de flux coexistant final (Gj), et donc pour passer de la configuration de QoS réseau initiale (avant la transition) à la configuration de QoS réseau finale (après la transition). La notation suivante peut être adoptée: Config (Gj) = Config(Gi) + DeltaConfig(GiGj). Une fois que tous les changements de configuration de QoS réseau sont calculés, le procédé poursuit par une étape 212 de stockage, consistant à stocker le Graphe des Transitions (GT) et l’ensemble des changements de configuration de QoS réseau associés aux transitions (DeltaConfig(Gi Gj)). Dans un mode de réalisation, les donnes sont stockées dans une base d’information d’un système de configuration réseau centralisé, en charge d’assurer la configuration de QoS d’un réseau « en ligne », i.e. en opération une fois déployé. Dans le cas d’un réseau TSN, le système de configuration réseau centralisé peut être le CNC/CUC du réseau TSN. Revenant à la , le procédé de l’invention va opérer « en ligne » lors d’une deuxième phase 220, pour mettre en place au sein du réseau des changements de configuration de QoS réseau selon les changements prédéfinis et stockés dans la base d’information, qui ont été prédéterminés lors de la première phase 200. Les changements de configuration de QoS réseau sont appliqués de manière dynamique au sein du réseau selon l’apparition ‘A’ de nouveaux flux ou la terminaison ‘F’ de flux existants. Généralement, le procédé 220 consiste à détecter une évolution ‘A’ ou ‘F’ d’un flux dans le réseau ; déterminer si cette évolution ‘A’ ou ‘F’ de flux est prévue par la configuration de QoS prédéfinie ; et appliquer le changement de configuration de QoS au réseau si l’évolution ‘A’ ou ‘F’ est prévue. La est un organigramme des étapes du procédé 600 opéré pour la phase en ligne 220, dans le cas d’un réseau fermé. Dans le contexte d’un réseau TSN, le procédé est opéré depuis le système de configuration réseau centralisé en charge de gérer les configurations de QoS des équipements du réseau, typiquement le CNC/CUC du réseau TSN. Le procédé est initialisé 602 pour un état courant (Gi) d’un graphe des transitions GT tel que préalablement défini et stocké dans la base d’information. La surveillance (« monitoring ») du réseau par le système de configuration réseau centralisé peut être initiée de différentes manières, en vue de détecter l’apparition ‘A’ ou la fin ‘F’ d’un flux 604. Dans un mode de réalisation, l’équipement source émetteur d’un nouveau flux est configuré pour émettre vers le système de configuration réseau centralisé, une signalisation (notification, message) spécifique en vue de requérir la mise en place de la configuration de QoS réseau appropriée pour ce flux et de recevoir une autorisation d’injecter ce flux dans le réseau. L’équipement source peut de plus être configuré pour notifier la fin du flux, et ainsi permettre au système de configuration réseau centralisé de libérer les ressources réseau (QoS) correspondantes. Dans un autre mode de réalisation, un équipement réseau (par exemple un switch en bordure du réseau) connecté à un équipement source émetteur d’un flux est configuré pour émettre une notification, lorsqu’il détecte l’apparition de ce nouveau flux sur l’un de ses ports d’entrée. Une telle notification peut être émise vers le système de configuration réseau centralisé en vue de demander la mise en place de la configuration de QoS réseau appropriée pour ce flux et de recevoir une autorisation d’injecter ce flux dans le réseau. Une notification peut également être émise par l’équipement réseau pour notifier la fin du flux, et ainsi permettre au système de configuration réseau centralisé de libérer les ressources réseau (QoS) correspondantes. L’équipement réseau (i.e. le switch) peut aussi être configuré pour détecter lui-même la fin d’un flux par exemple en détectant que plus aucun paquet de données associé à ce flux n’arrive sur son port d’entrée pendant un certain temps (selon une valeur paramétrable). Dans une variante de réalisation, la remontée de notifications de flux (apparition ou fin) vers le système de configuration réseau centralisé, peut être faite via des sondes réseau en charge de surveiller le trafic transitant sur certains ou sur tous les liens du réseau. Après l’étape 604 de détection d’un flux (fi), le procédé permet de vérifier si la transition correspondante est prévue dans la configuration de QoS prédéfinie, i.e. si elle existe dans le graphe des transitions GT stocké. Dans un mode de réalisation, le procédé met en œuvre une routine appropriée selon qu’il est détecté l’apparition (A) ou la fin (F) d’un flux. Lors de la détection de l’arrivée d’un nouveau flux, le procédé permet de vérifier 606 si cette transition A(fi) existe dans le GT, à partir de l’état courant Gi. Si la transition A(fi) n’est pas prédéfinie dans le GT stocké dans la base d’information, le procédé consiste dans une étape suivante 607 à ne pas accepter le flux arrivant (fi) dans le réseau, et à revenir à l’étape initiale 602 de surveillance du réseau. De manière optionnelle, le procédé permet de déclencher 609 l’émission d’une notification d’erreur, par exemple sous la forme d’un log. Ce type de notification révèle un comportement inattendu du réseau tel que l’apparition d’un flux inconnu ou l’apparition d’un flux connu mais au mauvais moment. Si la transition A(fi) est prédéfinie dans le GT à partir de l’état courant Gi, le procédé permet dans une étape suivante 608 de déterminer l’état final Gj du GT après la transition A(fi), de retrouver et d’appliquer la reconfiguration du réseau DeltaConfig(A(fi)) associée à cette transition et stockée dans la base d’information. Dans une étape suivante 610, le procédé permet d’accepter le flux arrivant (fi) dans le réseau, puis de mettre à jour 612 l’état courant du GT selon l’état final Gj. Revenant à l’étape 604, lors de la détection de la fin d’un flux, le procédé permet de vérifier 616 si la transition F(fi) existe dans le GT, à partir de l’état courant Gi. Si la transition F(fi) n’est pas prédéfinie dans le GT stocké dans la base d’information, le procédé permet de revenir à l’étape 602 de surveillance du réseau. Le procédé permet de déclencher (617) l’émission d’une notification d’erreur, par exemple sous la forme d’un log. Ce type de notification révèle un comportement inattendu du réseau tel que la terminaison d’un flux connu, mais au mauvais moment. Les évènements inattendus d’arrivée ou de fin de flux, peuvent être dus par exemple à des attaques portées sur le réseau ou à un disfonctionnement du système qui fait usage du réseau (par exemple une panne d’un équipement) ou encore être dus à une mauvaise conception du GT qui aurait pu être construit à partir d’un DCT non suffisamment complet. Ces notifications d’erreur peuvent être prises en compte par le concepteur du système pour vérifier l’origine du problème et reconstruire un DCT et un GT plus approprié au besoin. Si la transition F(fi) est prédéfinie dans le GT à partir de l’état courant Gi, le procédé permet dans une étape suivante 618 de déterminer l’état final Gj du GT après la transition F(fi), puis d’appliquer la reconfiguration du réseau DeltaConfig(F(fi)) associée à cette transition et stockée dans la base d’information. Puis le procédé permet de mettre à jour 620 l’état courant du GT selon l’état final Gj. Le procédé de l’invention présente un avantage technique significatif par rapport aux approches de l’état de l’art même dans le cas des réseaux fermés. En effet, l’invention permet d’optimiser les ressources du réseau de manière significative par rapport aux méthodes classiques qui se basent sur l’utilisation d’un outil de simulation hors-ligne, notamment dans des scénarios où les flux du réseau ne coexistent pas tous en permanence au sein du réseau (i.e. certains peuvent apparaitre ou disparaitre selon l’état du système qui utilise ce réseau). Avantageusement, la mise en œuvre du procédé de l’invention permet alors de réduire les coûts et la complexité des équipements réseau à déployer, et permet d’intégrer plus de fonctionnalités au système (i.e. permet d’acheminer plus de flux pour des ressources réseau prédéfinies). En reprenant l’exemple du réseau illustré par les figures 3 du DCT et 4 des Gi, on lit que le nombre maximum de flux qui peuvent coexister dans le réseau à un instant donné est de 4 (i.e. la taille des groupes G4 et G12) alors que le nombre total de flux existant est lui de 9. Aussi, l’homme de l’art comprend que dans ce cas (en faisant l’hypothèse simplificatrice que tous ces flux consomment la même quantité de ressources réseau) le gain apporté par la mise en œuvre du procédé de l’invention en termes d’économie des ressources réseau est de l’ordre de 50%. Grâce au procédé de reconfiguration dynamique de l’invention, les 9 flux peuvent être acheminés (selon le DCT de la ) avec des équipements réseaux ne devant en pratique disposer que de ressources pour 4 flux en parallèle, contrairement aux méthodes classiques se basant sur l’utilisation d’un outil de simulation hors-ligne, qui requerraient des équipements réseaux devant disposer de ressources capable d’acheminer les 9 flux en parallèle. Dans une variante d’implémentation, le procédé de l’invention permet de reconfigurer dynamiquement la QoS réseau dans des réseaux ouverts où tous les flux ne sont pas nécessairement tous connus a priori lors de la conception du réseau et donc où il n’est pas possible de construire un graphe des transitions GT complet avant la mise en place opérationnelle du réseau. Dans une autre variante d’implémentation, le procédé de l’invention s’applique également dans le cas de réseaux fermés dont le GT serait incomplet et pour lesquels il peut être nécessaire de pouvoir dynamiquement autoriser de nouvelles transitions pour les flux connus (et alors mettre dynamiquement à jour le GT) sans avoir à repasser par une phase hors ligne et de devoir recalculer un GT complet avec les nouvelles transitions. La est un organigramme des étapes complémentaires au procédé de reconfiguration dynamique de l’invention, permettant le traitement d’un nouveau flux dans un réseau ouvert ou dans un réseau fermé avec un GT incomplet. Les étapes identiques en fonctionnalité aux étapes décrites pour la gardent les mêmes références. De manière à prendre en charge ces deux variantes d’implémentations, l’étape de stockage 212 est complétée lors de la phase hors ligne, de manière à stocker, en plus du Graphe des Transitions (GT) et de l’ensemble des changements de configuration de QoS réseau associés aux transitions (DeltaConfig(GiGj)), les informations supplémentaires que sont : - les caractéristiques des flux connus (du DCT), notamment les équipements sources et destinations de ces flux et leurs exigences en termes de QoS, de notation QoSreq(fi) qui représente les exigences de QoS du flux fi ; et - toutes les configurations de QoS réseau des groupes de flux coexistant (Gi) telles qu’elles sont calculées à l’étape 208, de notation Config(Gi). Revenant à l’étape 604 de la de la détection de l’arrivée d’un nouveau flux, suivie de l’étape 606 ayant vérifié que cette apparition de flux ne correspond pas à une transition A(fi) connue dans le GT (compte tenu de l’état courant GT = Gi du graphe), le procédé poursuit par une étape de vérification 702 consistant à déterminer si le nouveau flux (fi) est ou non répertorié dans la base d’information. A la différence du procédé de la défini pour les réseaux fermés dont le GT est considéré comme complet, et qui consiste à « 607 : ne pas accepter le flux fi dans le réseau » et à « 609 : notifier un erreur de type A », le procédé pour les deux variantes d’implémentation précitées consiste à déterminer les conditions permettant d’accepter dans le réseau (i.e. réseau ouvert ou réseau fermé avec un GT incomplet), le nouveau flux (fi), tout en étant en mesure de déterminer dynamiquement en ligne, la reconfiguration de QoS à appliquer dans le réseau et à mettre celle-ci en place également rapidement. Si le nouveau flux (fi) est connu et répertorié dans la base d’information, le procédé poursuit par une étape 704 consistant à vérifier s’il existe dans le GT un groupe de flux coexistant Gj incluant le nouveau flux (fi), tel que Gj=Gi+{fi}. Si un tel groupe Gj existe, le procédé poursuit par un enchainement d’étapes 706, 708, 710, 712 afin de : - 706 : rajouter la transition A(fi) de Gi vers Gj dans le GT, et de calculer la reconfiguration pour la transition DeltaConfig(A(fi)) = Config(Gj) – Config(Gi) ; - 708 : appliquer la reconfiguration de QoS du réseau associée à cette transition ; - 710 : accepter le flux (fi) dans le réseau ; et - 712 : faire transiter Gi l’état courant du GT vers Gj le nouvel état courant du GT. Avantageusement, le GT est mis à jour pour prendre en charge une nouvelle possibilité d’apparition de flux (fi) dans le réseau en un état courant Gi, et le flux est accepté dans le réseau en mettant en place la QoS correspondante sans impacter les autres flux présents. Les étapes de reconfiguration de QoS, d’acceptation de nouveau flux et de mise à jour de l’état courant GT (706, 708, 710, 712) s’appliquent au cas des réseaux fermés pour lesquels il est souhaitable de pouvoir compléter dynamiquement les transitions du GT en ligne, mais aussi au cas des réseaux ouverts pour lesquels un nouveau flux (non connu initialement) aurait été rajouté au système. La est un diagramme illustrant un exemple du traitement de l’arrivée inattendue d’un flux connu f4 selon un mode de réalisation de l’invention, pour un graphe des transitions GT selon la qui est dans l’état courant G2. Cet exemple correspond au déroulé des étapes 702, 704, 706, 708, 710, 712 de la , où, alors que la transition A(f4) correspondante n’existe pas encore dans le GT, un flux connu qui apparait peut quand même être accepté dans le réseau et avoir le GT mis à jour en conséquence. Cet exemple illustre le cas des vérifications où « 702, branche ‘oui’ : Le flux fi est connu (il est enregistré dans la base d’information) » et « 704, branche ‘oui’ : il existe déjà dans le GT un groupe Gj tel que Gj=Gi+{fi} ». En considérant l’exemple du GT de la , il est fait l’hypothèse de l’arrivée du flux f4 lorsque le GT du réseau est dans l’état G2 (c’est-à-dire que seuls les flux f1 et f2 sont actifs). Bien que le GT initial de la ne comprenne pas de transition A(f4) (donc ne permettant pas a priori d’accepter le flux f4), le procédé va déterminer qu’il existe dans le GT un groupe G5= {f1, f2, f4} comprenant les flux f1, f2, f4, donc tel que G5 = G2 + {f4}. Le procédé permet alors de mettre à jour dynamiquement le GT pour selon l’étape 706 rajouter une nouvelle transition A(f4) de G2 vers G5 (visible sur la ) et calculer le DeltaConfig(A(f4)) = Config(G5) – Config(G2), ces deux Config() de G5 et G2 étant connues et stockées dans la base d’information. Le procédé poursuit par les étapes 708 d’appliquer cette reconfiguration au réseau, 710 d’accepter le flux f4 dans le réseau, et 712 tout en faisant transiter l’état courant du GT vers G5. Dans cet exemple, l’homme du métier comprend que le DCT ( ) n’avait pas couvert à travers les scenarios d’usage simulés du système en hors-ligne, le cas où le flux f4 démarrerait avant le flux 3, mais malgré cela le procédé de l’invention permet tout de même de prendre en charge le flux f4 dans cette situation particulière. Revenant à l’étape 704 consistant à vérifier s’il existe dans le GT un groupe de flux coexistant Gj incluant le nouveau flux (fi), tel que Gj=Gi+{fi}, si un tel groupe Gj n’existe pas, le procédé poursuit par l’étape 607 consistant à ne pas accepter ce nouveau flux (fi) dans le réseau. Dans un mode de réalisation, le procédé permet 707 de lancer en tâche de fond, un calcul de configuration de QoS pour ce nouveau groupe Gj=Gi+{fi}, notée ‘Config(Gj)’, en prenant en compte les exigences de QoS de ce flux fi, notées ‘QoSreq(fi)’. Le procédé peut reboucler sur l’étape initiale 602 sans attendre la fin du calcul de Config(Gj) qui peut potentiellement être long, de manière à ne pas retarder le traitement d’autres flux pouvant apparaitre ou se terminer. Revenant à l’étape 702, si le nouveau flux (fi) n’est pas connu, i.e. il n’existe pas dans la base d’information, le procédé poursuit à l’étape 714 consistant à déterminer la source Src(fi) du flux (fi), la destination Dest(fi) du flux (fi) et les exigences QoSreq(fi) de QoS du flux (fi). Dans le cas d’un réseau ouvert, si le flux fi est inconnu (n’est pas encore enregistré dans la base d’information) mais que dans l’état actuel du réseau (i.e. l’état courant GT = Gi), celui-ci serait en mesure d’accepter un flux (fx) connu, transitant par le même chemin que fi, et dont les exigences de QoS sont supérieures à celles de fi, le procédé permet de considérer que le réseau est alors en mesure d’accepter le flux fi inconnu en lui allouant des ressources réseau correspondantes aux exigences de QoS du flux fx connu (et donc en pratique suffisantes pour fi car supérieures à ses propres exigences de QoS). Le procédé poursuit par une étape 716 consistant à déterminer s’il existe dans le GT au moins une transition de type « apparition » A(fx) sortante de Gi correspondant à un flux fx connu, et telle que : - les flux fx et fi peuvent transiter par le même chemin au sein du réseau (c’est-à-dire qu’ils peuvent traverser exactement les même équipements) puisque partageant la même source et la même destination : Src(fi)= Src(fx) et Dest(fi)= Dest(fx) ; et - les exigences de QoS du flux fi sont moindres que celles du flux fx : QoSreq(fi) ≤ QoSreq(fx). Différentes approches peuvent être utilisées pour comparer les exigences de QoS de deux flux (fi et fx). A titre d’exemple, la fonction « QoSreq(fi) ≤ QoSreq(fx) » retourne « vrai » si et seulement si : - les métriques de QoS (par exemple le débit requis Dreq() et/ou la latence maximum autorisée Lmax() et/ou le taux de perte maximum autorisé Pmax()…) exprimant les exigences de QoS sont strictement identiques pour les deux flux fi et fx ; et - la taille des paquets émis par fi est inférieure à celle des paquets émis par fx ; et - pour chacune des métriques de QoS prise individuellement, les exigences de QoS de fi sont inférieures aux exigences de QoS de fx : - pour la métrique « débit requis » : Dreq(fi) ≤ Dreq(fx) - pour la métrique « latence maximum autorisée » : Lmax(fi) ≥ Lmax(fx) - pour la métrique « taux de perte maximum autorisé » : Pmax(fi) ≥ Pmax(fx). Si à l’étape 716, il est déterminé qu’il existe plusieurs transitions candidates satisfaisant ces contraintes, dans un mode préféré de l’invention, le procédé permet de sélectionner la transition A(fx) correspondant au flux fx dont les exigences de QoS sont les plus proche de celles du flux fi. Une fois la transition A(fx) et le flux fx identifiés, le procédé dans des étapes suivantes permet, de mettre à jour en ligne le GT utilisé par le système de configuration réseau centralisé, de reconfigurer la QoS du réseau pour prendre en charge fi et d’accepter ce flux. Dans un mode de réalisation, ces étapes comprennent : - une étape 718 consistant à : - déterminer l’ensemble des groupes du GT dans lesquels le flux fx apparait et rajouter pour chacun de ces groupes Ga un nouveau groupe Gb au GT tel que Gb=Ga-{fx}+{fi} ; - copier toutes les transitions Ta (entrantes ou sortantes, de type A ou F) de Ga comme une nouvelle transition Tb de Gb, en remplaçant fx par fi pour celles ou fx apparaitrait ; - définir une même reconfiguration de QoS pour Ta et Tb : DeltaConfig(Tb) = DeltaConfig(Ta) ; - définir une même configuration de QoS pour Ga et Gb : Config(Gb) = Config(Ga). - une étape 720 consistant à : - marquer le flux fi comme étant maintenant un flux connu et pris en charge par le réseau avec des exigences de QoS égales à celles de fx : QoSReq(fi) = QoSReq(fx) ; et - stocker dans la base d’information des informations sur le flux fi : (Src(fi), Dest(fi), QoSreq(fi)). - des étapes (722, 724, 726) consistant à : - 722 : appliquer la reconfiguration du réseau associée la transition A(fi) sortant de Gi, DeltaConfig(A(fi)) : - 724 : accepter le flux fi dans le réseau ; et - 726 : transiter l’état courant du GT vers le nouvel état Gi-{fx}+{fi}. Ainsi, le procédé de l’invention permet de mettre à jour le GT de manière dynamique pour prendre en charge cette nouvelle possibilité d’apparition d’un flux fi dans le réseau (en l’état courant Gi), même si ce flux n’était pas connu, et permet d’accepter ce flux dans le réseau en mettant en place la QoS correspondante sans impacter les autres flux présents. La est un diagramme GT illustrant un exemple du traitement de l’arrivée inattendue d’un flux inconnu selon un mode de réalisation de l’invention. Cet exemple correspond au déroulé des étapes 702, 714, 716, 718, 720, 722, 724, 726 de la , où un flux f10 inconnu (pas encore enregistré dans la base d’information) qui apparait peut quand même être accepté dans le réseau et le GT mis à jour en conséquence. Cet exemple vaut pour un réseau qui dans son état courant serait en mesure d’accepter un flux (fx) connu transitant par le même chemin que le flux f10 inconnu, et dont les exigences de QoS sont supérieures à celles de f10. Le réseau peut être considéré comme en mesure d’accepter le flux f10 en lui allouant des ressources réseau correspondantes aux exigences de QoS du flux fx (et donc en pratique suffisantes pour fi car supérieures à ses propres exigences de QoS). En considérant le graphe des transitions GT initial de la , il est pris pour hypothèse l’arrivée du flux inconnu f10 lorsque le GT du réseau est dans l’état G2 (seuls les flux f1 et f2 sont actifs). Il est également pris pour hypothèse que les flux f10 et f3 partagent les mêmes équipements source et destination, et que les exigences de QoS initiales du flux f10 sont inférieures à celles du flux f3. L’homme du métier comprend que les hypothèses prises ne le sont que pour des raisons de simplification de la description, et non comme des limitations, toute autre variante d’hypothèse pouvant être prise en charge par le procédé de l’invention. L’étape 716 du procédé permet d’identifier une transition A(f3) sortant de G2 correspondant au flux f3, et avec les hypothèses prises, le procédé permet : - selon l’étape 718, de : déterminer l’ensemble des groupes du GT dans lesquels le flux f3 apparait : il s’agit des groupes G3 et G4 ; rajouter pour chacun de ces groupes un nouveau groupe au GT : il s’agit des groupes G3’=G3-{f3}+{f10}={f1, f2, f10} et G4’=G4-{f3}+{f10}={f1, f2, f10, f4} ; copier toutes les transitions de G3 comme des nouvelles transitions de G3’, et toutes les transitions de G4 comme des nouvelles transitions de G4’, en veillant pour les transitions qui correspondent au flux f3 à les remplacer par des transitions correspondant au flux f10 ; définir le DeltaConfig() de chaque nouvelle transition comme étant égal au DeltaConfig() de la transition existante dont elle est dérivée ; et définir la Config() de chaque nouveau groupe comme étant égale à la Config() du groupe existant dont il est dérivé. - selon l’étape 720 : d’enregistrer le nouveau flux f10 dans la base d’information du système de configuration réseau centralisé en veillant à préciser que les exigences de QoS (finales) de f10 prises en compte pour permettre son acceptation dans le réseau sont égales à celle de f3 (QoSreq(f10) = QoSreq(f3)). A partir de là, le flux f10 est donc considéré comme un flux connu par le système de configuration réseau centralisé. - selon l’étape 722 : d’appliquer la configuration DeltaConfig(A(10)), faisant transiter l’état du GT de G3 vers G3’, et en acceptant le flux f10 dans le réseau. Le flux f10 bénéficie alors d’une QoS configurée équivalente à celle qui aurait été mise en place pour f3. Revenant à l’étape 716, s’il est déterminé qu’il n’existe pas dans le GT au moins une transition de type « apparition » A(fx) sortant de Gi et correspondant à un flux fx connu et tel que - Src(fi)=Src(fx) et Dest(fi)=Dest(fx) et QoSReq(fi) Le procédé peut reboucler sur l’étape initiale 602 sans attendre la fin du calcul 719 de Config(Gj) qui peut potentiellement être long, de manière à ne pas retarder le traitement d’autres flux pouvant apparaitre ou se terminer. Par ailleurs, le procédé permet de créer une mention spécifique dans la base d’information pour indiquer que le « calcul QoS Config(Gj=Gi+{fi}) est en cours pour l’arrivée du flux fi inconnu avec QoSreq(fi) » de manière à préciser qu’un tel calcul a été lancé pour le flux fi de type « inconnu » sans toutefois enregistrer ce flux fi dans la base d’information car il est non encore accepté par le réseau. Lorsque le calcul de configuration de QoS Config(Gj) pour le nouveau groupe Gj=Gi+{fi} est terminé par l’étape 707 ou par l’étape 719, et que le procédé est dans l’état 602 de « Monitorer le réseau » où l’état courant du GT est alors un état quelconque Gw, le système de configuration réseau centralisé peut alors mettre à jour dynamiquement le GT utilisé, afin d’y rajouter ce nouveau groupe Gj avec la transition A(fi) de Gi vers Gj correspondant au calcul de configuration de QoS Config(Gj) qui vient de se terminer. La mise à jour du GT peut être faite sous réserve de différentes vérifications (A), (B), (C) : (A) Si le flux fi est connu (enregistré dans la base d’information) mais que la base d’information contient tout de même une mention spécifique « calcul QoS Config(Gj=Gi+{fi}) en cours pour l’arrivée du flux fi inconnu avec QoSreq(fi) », cela signifie que le flux fi a finalement été admis dans le réseau après le démarrage de ce calcul, probablement lorsque le réseau était dans un autre état Gz et que le flux fi aura alors pu être accepté via les étapes 714 à 724 décrites précédemment. Dans ce cas, la QoS allouée au flux fi « QoSreq(fi) configurée » et stockée dans la base d’information peut être supérieure aux exigences de QoS initiales « Qosreq(fi) initiale » utilisée pour le calcul (en tâche de fond) de Config(Gj). Le procédé permet alors de comparer les exigences. Si la QoS allouée est supérieure, alors le calcul fait en tâche de fond de la configuration de QoS Config(Gj=Gi+{fi}) est ignoré en ne mettant pas à jour le GT et en supprimant la mention « calcul QoS Config(Gj=Gi+{fi}) en cours pour l’arrivée du flux fi inconnu avec QoSreq(fi) » de la base d’information. Si par contre la QoS allouée n’est pas supérieure aux exigences de QoS initiales, le procédé permet de définir que la « QoSreq(fi) configurée » est égale à la « QoSreq(fi) initiale », et : - Si le groupe Gj existe déjà (il a pu être créé lorsque le réseau était dans un autre état Gz et que le flux fi a pu être accepté) alors on ignore le calcul (fait en tâche de fond) de configuration de QoS Config(Gj=Gi+{fi}) (car déjà connu) et on peut mettre à jour dynamiquement le GT utilisé afin d’y rajouter la transition A(fi) de Gi vers Gj. On stocke également dans la base d’information la reconfiguration DeltaConfig(A(fi))=Config(Gj)-Config(Gi) associée à cette nouvelle transition A(fi) entre Gi et Gj. Cela permettra ainsi au réseau d’être en mesure d’accepter le flux fi s’il apparait dans le futur alors que le réseau est dans l’état Gi. Enfin on supprime l’indication « calcul QoS Config(Gj=Gi+{fi}) en cours pour l’arrivée du flux fi inconnu avec QoSreq(fi) » de la base d’information. - Si le groupe Gj n’existe pas encore, le GT utilisé peut être mis à jour dynamiquement afin d’y rajouter ce nouveau groupe Gj avec la transition A(fi) de Gi vers Gj. Le procédé permet aussi de stocker dans la base d’information, la configuration de QoS de Gj, Config(Gj), et la reconfiguration DeltaConfig(A(fi))=Config(Gj)-Config(Gi) associée à la nouvelle transition A(fi) entre Gi et Gj. Cela permet ainsi au réseau d’être en mesure d’accepter le flux fi s’il apparait dans le futur alors que le réseau est dans l’état Gi. Le procédé permet de plus de supprimer la mention « calcul QoS Config(Gj=Gi+{fi}) en cours pour l’arrivée du flux fi inconnu avec QoSreq(fi) » de la base d’information. (B) Si le flux fi est connu (enregistré dans la base d’information) et que la base d’information ne contient pas de mention spécifique « calcul QoS Config(Gj=Gi+{fi}) en cours pour l’arrivée du flux fi inconnu avec QoSreq(fi) », cela signifie que le flux fi était déjà connu du système lorsque le calcul en tâche de fond a été initié. Dans ce cas, le procédé permet de mettre à jour dynamiquement le GT utilisé afin d’y rajouter ce nouveau groupe Gj avec la transition A(fi) de Gi vers Gj. Le procédé permet de stocker également dans la base d’information, la configuration de QoS de Gj, Config(Gj), et la reconfiguration DeltaConfig(A(fi))=Config(Gj)-Config(Gi) associée à la nouvelle transition A(fi) entre Gi et Gj. Cela permet ainsi au réseau d’être en mesure d’accepter le flux fi s’il apparait dans le futur alors que le réseau est dans l’état Gi. (C) Si le flux fi est inconnu et que la base d’information contient bien la mention spécifique « calcul QoS Config(Gj=Gi+{fi}) en cours pour l’arrivée du flux fi inconnu avec QoSreq(fi) », cela signifie que le flux fi n’a jamais encore été admis dans le réseau (donc aucune QoS n’a encore été configurée pour fi). Dans ce cas, le procédé permet de mettre à jour dynamiquement le GT utilisé afin d’y rajouter le nouveau groupe Gj avec la transition A(fi) de Gi vers Gj. Le procédé permet de plus d’enregistrer le nouveau flux fi dans la base d’information de manière à indiquer qu’il est maintenant connu, en stockant ses informations Src(fi), Dest(fi) et QoSreq(fi). Le procédé permet aussi de stocker dans la base d’information, la configuration de QoS de Gj, Config(Gj), et la reconfiguration DeltaConfig(A(fi))=Config(Gj)-Config(Gi) associée à la transition A(fi) entre Gi et Gj. Cela permet ainsi au réseau d’être en mesure d’accepter le flux fi s’il apparait dans le futur alors que le réseau est dans l’état Gi. Le procédé permet de plus de supprimer la mention « calcul QoS Config(Gj=Gi+{fi}) en cours pour l’arrivée du flux fi inconnu avec QoSreq(fi) » de la base d’information. La montre un organigramme d’étapes complémentaires au procédé de reconfiguration de l’invention pour le traitement de la fin d’un flux, pour le cas de réseaux ouverts ou de réseaux fermés avec un GT incomplet. Les étapes identiques en fonctionnalité aux étapes décrites pour la gardent les mêmes références. Après l’étape 616 qui a vérifié qu’une transition F(fi) n’existe pas dans le graphe des transitions GT pour l’état courant Gi, le procédé peut poursuivre par une étape 1002 consistant à vérifier si le flux (fi) est enregistré dans la base d’information. Si le flux fi n’est pas connu, il est simplement ignoré, ce flux n’est a priori pas concerné par le système de gestion de la QoS, et le procédé reboucle à l’étape 602 de surveillance du réseau. Si le flux fi est connu (il existe dans la base d’information), le procédé poursuit par une étape 1004 consistant à déterminer s’il existe dans le GT un groupe Gj contenant tous et uniquement les flux de Gi sauf le flux (fi), i.e. un groupe tel que Gj=Gi-{fi}. S’il existe un tel groupe Gj, le GT utilisé (en ligne) peut être mis à jour par le système de configuration réseau centralisé et la QoS du réseau peut être configurée sur de prochaines étapes consistant à : - 1006 : rajouter la transition F(fi) de Gi vers Gj dans le GT ; et calculer DeltaConfig(F(fi)) = Config(Gj) – Config(Gi) ; - 1008 : appliquer la reconfiguration du réseau associée à cette transition DeltaConfig(F(fi)) ; - 1010 : faire transiter l’état courant du GT vers l’état Gj. Le procédé revient ensuite à l’étape 602 de surveillance du réseau. Si à l’étape 1004, il est déterminé que bien que le flux fi soit connu dans la base d’information, il n’existe pas dans le GT un groupe Gj tel que Gj=Gi-{fi}, le procédé va lancer, en tâche de fond 1012, un calcul de configuration de QoS pour ce nouveau groupe Gj=Gi-{fi}, notée Config(Gj), en prenant en compte les exigences de QoS de ce flux fi, QoSreq(fi), qui sont stockées dans la base d’information. Le procédé peut reboucler sur l’étape 602 de surveillance du réseau sans attendre la fin de ce calcul (potentiellement long) de manière à ne pas retarder le traitement d’autres flux pouvant apparaitre ou se terminer. Il est à noter que cette situation est particulière car le flux fi s’est terminé mais les ressources de QoS correspondantes QoSreq(fi) n’ont pas encore pu être libérées du réseau, et le système de configuration réseau centralisé considère alors que le flux est présent. Aussi, les prochains états du GT continueront alors à contenir le flux {fi} tant que le calcul de configuration de QoS lancé en tâche de fond pour ce nouveau groupe Gj=Gi-{fi} n’aura pas terminé. Lorsque ce calcul de configuration de QoS Config(Gj) lancé en tâche de fond pour ce nouveau groupe Gj-=Gi-{fi} est terminé et que le procédé de l’invention est dans l’état 602 « Monitorer le réseau » (l’état courant du GT est alors un état quelconque Gw), le système de configuration réseau centralisé peut alors mettre à jour dynamiquement le GT utilisé afin d’y rajouter ce nouveau groupe Gj=Gi-{fi} et la transition F(fi) de Gi vers Gj en stockant également dans la base d’information Config(Gj) et DeltaConfig(F(fi))=Config(Gj)-Config(Gi). Le système de configuration réseau centralisé, à chaque fois qu’il est dans l’état « Monitorer le réseau » peut alors vérifier si l’état courant du GT (un état quelconque Gu) permet de libérer les ressources réseau du flux fi, qui est maintenant terminé depuis un certain temps mais dont les ressources réseau correspondantes n’ont pas encore été libérées. Pour ce faire (non illustré) : - S’il existe une transition F(fi) sortant de l’état courant Gu vers un état Gu’ alors il est appliqué la reconfiguration de QoS réseau DeltaConfig(F(fi)) correspondante et l’état passe à l’état courant Gu’. Les ressources réseau qui avaient été allouées au flux fi ont alors été libérées. - S’il n’existe pas de transition F(fi) sortant de l’état courant Gu mais qu’il existe dans le GT un état Gu’ tel que Gu’=Gu-{fi}, alors il est ajouté dynamiquement la transition F(fi) entre Gu et Gu’, il est calculé DeltaConfig(F(fi))=Config(Gu’)-Config(Gu) et il est appliqué cette transition F(fi), ce qui permet de basculer l’état du GT vers l’état Gu’ et de libérer ainsi les ressources réseau qui avaient été allouées au flux fi. La est un diagramme illustrant un exemple du traitement de la fin d’un flux selon un mode de réalisation de l’invention. Cet exemple illustre les étapes de la , correspondant au cas où, alors que la transition correspondante n’existe pas encore dans le GT, un flux connu qui se termine peut quand même être prise en charge dans le réseau, en reconfigurant la QoS réseau pour libérer les ressources qui lui étaient assignées, et en mettant à jour le GT en conséquence. En considérant l’exemple du GT de la , il est fait l’hypothèse de la fin du flux f10 (maintenant connu du système) lorsque le GT du réseau est dans l’état G3’. Bien que le GT initial correspondant au GT de la ne comprenne pas de transition de fin de flux F(f10) (et ne permettant donc pas a priori de gérer la reconfiguration du réseau sur cet évènement), le procédé peut identifier un groupe G2 tel que G2 = G3’ - {f10}. Il est alors possible de mettre à jour dynamiquement le GT pour rajouter une nouvelle transition F(f10) de G3’ vers G2 et calculer le DeltaConfig(F(f10)) = Config(G2) – Config(G3’), ces deux Config() de G3’ et G2 étant connues et stockées dans la base d’information. Cette reconfiguration peut être appliquée au réseau et il est ainsi possible de libérer les ressources réseau qui étaient assignées au flux f10, tout en faisant transiter l’état courant du GT vers G2. Ainsi la présente invention apporte des avantages différenciants pour la gestion de la Qualité de Service (QoS) dans un réseau de télécommunication, et notamment un réseau TSN, que ce soit pour des réseaux fermés ou pour des réseaux ouverts. Dans le contexte de réseaux fermés : l’invention permet d’optimiser les ressources du réseau de manière significative par rapport aux méthodes classiques basées sur l’utilisation d’un outil de simulation hors-ligne, et notamment dans des scénarios où les flux du réseau ne coexistent pas tous en permanence au sein du réseau (certains peuvent apparaitre ou disparaitre selon l’état du système qui utilise ce réseau). Le procédé de l’invention permet soit de réduire les coûts et la complexité des équipements réseau à déployer, soit d’intégrer plus de fonctionnalités au système, en permettant d’acheminer plus de flux pour des ressources réseau prédéfinies. Dans le contexte de réseaux ouverts : l’invention permet (a) de prendre en charge dynamiquement, en ligne, la reconfiguration de la QoS dans un réseau de manière à y accepter de nouveaux flux non connus a priori lors du déploiement initial du réseau, et (b) de déterminer et de mettre en place cette reconfiguration de manière suffisamment rapide, tout en garantissant que le système reste sûr et en veillant à optimiser les ressources réseaux. La présente invention constitue donc une solution unique qui permet une configuration de la QoS dans un réseau ouvert selon une approche centralisée, là où les approches de l’état de l’art basées sur des outils de simulation hors-ligne échouent, et elle offre des gains significatifs en termes d’optimisation des ressources réseau par rapport à une approche décentralisée. En résumé, les avantages principaux de l’invention décrite sont les suivants : - Solution capable d’optimiser l’usage des ressources du réseau, pour des ressources réseau prédéfinies, en acheminant plus de flux, avec plus d’exigences de QoS, que les méthodes et outils de simulation hors-ligne connus ; - Solution applicable à un système ouvert dans lequel tous les flux ne sont pas nécessairement tous connus a priori lors de la conception du réseau ; - Solution apte à déterminer une nouvelle configuration optimale du réseau (si elle est possible) à chaque instant lorsque le système évolue, i.e. lors de l’arrivée ou la terminaison d’un flux ; - Solution capable de déterminer une nouvelle configuration rapidement « en ligne », i.e. lorsque que le réseau est déployé et en opération, dès que nécessaire ; et - Solution apte à garantir que le système reste sûr, c’est-à-dire qu’un nouveau flux n’est pas accepté dans le réseau si sa QoS requise ne peut pas être garantie sans impacter la QoS des autres flux existants dans le réseau. Procédé (600) de reconfiguration dynamique de la qualité de service ‘QoS’ dans un réseau de télécommunication comprenant une pluralité d’équipements configurés pour émettre et/ou recevoir des flux de données transitant dans le réseau, ledit réseau ayant une configuration de QoS prédéfinie lors d’une phase de préparation « hors ligne » prenant en compte une pluralité de flux devant transiter dans ledit réseau afin de calculer des changements de configuration de QoS à appliquer au réseau selon l’évolution des flux dans le réseau, une évolution correspondant à une apparition ‘A’ d’un flux ou à une fin ‘F’ d’un flux, le procédé étant mis en œuvre par ordinateur et comprenant des étapes de : détecter (604) une apparition ‘A’ ou une fin ‘F’ de flux dans le réseau ; déterminer (606, 616) si une évolution de flux est prévue par la configuration de QoS prédéfinie pour cette apparition ‘A’ ou cette fin ‘F’ de flux; si l’évolution est prévue, retrouver (608, 618) le changement de configuration de QoS à appliquer au réseau ; et appliquer (608, 618) ledit changement de configuration de QoS au réseau. Le procédé selon la revendication 1 comprenant de plus, si l’évolution de flux prévue est l’apparition ‘A’ d’un flux dans le réseau, une étape (610) d’accepter le flux dans le réseau. Le procédé selon la revendication 1 ou 2 comprenant après l’étape de déterminer (606) si l’apparition ‘A’ d’un flux est prévue par la configuration de QoS prédéfinie, une étape de refuser le flux si l’apparition ‘A’ dudit flux n’est pas prévue par la configuration de QoS prédéfinie. Le procédé selon l’une quelconque des revendications 1 à 3 comprenant après l’étape de déterminer (606, 616) si l’évolution ‘A’ ou ‘F’ de flux est prévue par la configuration de QoS prédéfinie, une étape (609, 617) de générer une notification d’erreur si l’évolution n’est pas prévue par la configuration de QoS prédéfinie. Le procédé selon l’une quelconque des revendications 1 à 4 dans lequel la phase de préparation « hors ligne » (200) comprend des étapes consistant à : générer (202) un diagramme de coexistence temporelle des flux ‘DCT’ au sein du réseau, pour lister les différents flux connus a priori du réseau et les temps où ces flux apparaissent et disparaissent ; calculer (204) à partir du DCT, l’ensemble des groupes de flux coexistant ‘Gi’ à chaque instant donné au sein du réseau ; générer (206) un graphe des transitions ‘GT’ entre les groupes de flux coexistant, chaque transition correspondant à une arrivée ‘A’ d’un nouveau flux ou à la fin ‘F’ d’un flux connu ; calculer (208) une configuration de QoS réseau ‘Config(Gi)’ pour chaque groupe de flux coexistant Gi ; calculer (210) le changement de configuration de QoS réseau ‘DeltaConfig(GiGj)’ à appliquer au réseau pour chaque transition du GT ; et stocker (212) le GT et l’ensemble des changements de configuration de QoS réseau associés aux transitions dans une base d’information d’un système de configuration réseau en charge d’assurer la configuration de QoS dudit réseau. Le procédé selon la revendication 5 dans lequel l’étape de déterminer (606, 616) si l’évolution de flux est prévue par la configuration de QoS prédéfinie, consiste à vérifier dans le graphe des transitions, si une transition existe pour ladite évolution de flux qui est détectée pour l’état courant Gi du graphe des transitions GT. Le procédé selon la revendication 6 dans lequel l’étape (608, 618) de retrouver le changement de configuration de QoS à appliquer au réseau, comprend une étape de déterminer l’état final Gj du graphe des transitions GT après ladite transition. Le procédé selon la revendication 7 comprenant après l’étape (608, 618) d’appliquer ledit changement de configuration de QoS au réseau, une étape (612, 620) de mettre à jour l’état courant Gi du graphe des transitions avec l’état final Gj, puis revenir à une étape (602) de surveillance du réseau. Le procédé selon l’une quelconque des revendications 1 à 8 comprenant de plus si l’évolution pour l’apparition ‘A’ dudit flux n’est pas prévue par la configuration de QoS prédéfinie, des étapes (702 à 726) permettant de vérifier si ledit flux peut être accepté ou non dans le réseau comme un nouveau flux, lesdites étapes comprenant au moins une étape (708, 722) d’appliquer un changement de configuration de QoS du réseau si ledit flux peut être accepté comme nouveau flux. Le procédé selon l’une quelconque des revendications 1 à 8 comprenant de plus si l’évolution pour la fin ‘F’ dudit flux n’est pas prévue par la configuration de QoS prédéfinie, des étapes (1002 à 1010) permettant de déterminer si un changement de configuration de QoS du réseau doit être appliqué. Un produit programme d’ordinateur, ledit programme d’ordinateur comprenant des instructions de code permettant d’effectuer les étapes du procédé selon l'une quelconque des revendications 1 à 10, lorsque ledit programme est exécuté sur un ordinateur. Un dispositif de reconfiguration dynamique de la qualité de service ‘QoS’ dans un réseau de télécommunication (100) comprenant une pluralité d’équipements (102) configurés pour émettre et/ou recevoir des flux de données transitant dans le réseau, ledit réseau ayant une configuration de QoS prédéfinie lors d’une phase de préparation « hors ligne » prenant en compte une pluralité de flux devant transiter dans ledit réseau afin de calculer des changements de configuration de QoS à appliquer au réseau selon l’évolution des flux dans le réseau, une évolution correspondant à une apparition ‘A’ d’un flux ou à une fin ‘F’ d’un flux, le dispositif comprenant des moyens pour mettre en œuvre les étapes du procédé de reconfiguration dynamique de la qualité de service ‘QoS’ dans le réseau de télécommunication, selon l’une quelconque des revendications 1 à 10. Le dispositif selon la revendication 12 où le réseau de télécommunication est soit un réseau dit fermé où tous les flux transitant sur le réseau sont a priori connus, et où la phase de préparation « hors ligne » prend en compte tous les flux connus a priori, soit un réseau dit ouvert où des flux non connus a priori peuvent transiter sur le réseau, et où la phase de préparation « hors ligne » prend en compte des flux connus a priori. Le dispositif selon la revendication 12 ou 13 où le réseau de télécommunication est un réseau déterministe de type Ethernet 802.1 Time Sensitive Network. Un système de configuration réseau centralisé pour réseau déterministe, le système comprenant un contrôleur en charge de gérer les configurations de QoS dudit réseau, ledit contrôleur étant un contrôleur SDN 110 couplé à une entité fonctionnelle 108 comprenant des applications logicielles de type service SDN, et notamment une application logicielle permettant d’effectuer les étapes du procédé selon l’une quelconque des revendications 1 à 10.