FR 3099332 A1 20210129 FR 1908443 A 20190725 Description Titre de l'invention : Procédé et dispositif de contrôle de la congestion dans un réseau maillé [0001] L'invention se situe clans le domaine des réseaux de communication, et concerne plus particulièrement un procédé et un dispositif de contrôle de la congestion dans un réseau maillé [0002] Le contrôle de la congestion dans les réseaux de communication permet de garantir une bonne performance réseau face à un environnement dynamique caractérisé par des contraintes matérielles, telles que la bande passante et la mémoire disponibles, et par les exigences des applications, telles que le débit d'entrée/sortie et la fiabilité des transmissions. [0003] Lc contrôle de la congestion se base sur la collecte d'informations spécifiques des équipements du réseau, comme le niveau d'occupation mémoire, le débit d'entrée/sortie, le taux de perte des paquets par exemple, pour permettre de prendre une décision de reconfiguration réseau, soit dans un mode proactif pour de l'anticipation, soit dans un mode réactif pour résoudre une congestion réseau détectée. [0004] Cependant, cette collecte d'informations peut engendrer un volume important de données dans le réseau et occuper une bonne partie de la mémoire d'entrée/sortit. Ceci est particulièrement vrai lorsque la taille de l'information collectée est importante ou lorsque le nombre d'équipements gérés est important. [0005] Des solutions de gestion de la congestion dans les réseaux existent. Ainsi, par exemple : [0006] La demande de brevet KR100865722BI, propose une méthode de notification explicite d'un état de congestion au niveau d'un noeud pour les réseaux de capteurs sans fil. Cette méthode permet de détecter et localiser le noeud congestionné par le « sink » (gatcway). Dans cette méthode, un champ est utilisé pour marquer l'identifiant du noeud en situation de congestion et un autre champ pour inclure une notification explicite de la congestion. L'inconvénient est que l'identifiant du noeud congestionné est automatiquement transmis avec l'information de congestion, ce qui impactc le volume de trafic dans le réseau. [0007] Dans le brevet US6741555 qui propose une méthode de notification de congestion dans les réseaux TCP/IP, lorsqu'une congestion est détectée sur le chemin d'un paquet, ce paquet est marqué par un flag CE (« Congestion Experienced »). Lorsque le paquet marqué arrive à destination, le destinataire informe le noeud émetteur de la présence d'une congestion sur le chemin par le biais d'un paquet « ECN-ECHO ACK ». L'émetteur adapte en conséquence son débit d'émission du trafic. Cependant, cette 2 invention n'offre pas de moyen d'identification du/des noeud (s) congestionnés afin de prendre une décision de reconfiguration centrale du réseau. [0008] Le brevet US5457687 propose une méthode pour le contrôle de la congestion dans les réseaux ATM (« Asynchronous Transfer Mode »). Un noeud est reconnu comme étant en état de congestion lorsque sa file d'attente dépasse un seuil prédéfini. Lorsqu'une congestion est détectée sur le chemin d'un paquet, un signal sous forme de BECN (« Backward Explicit Congestion Notification ») est immédiatement envoyé à l'émetteur afin que ce dernier ajuste son débit d'émission. Cependant, cette méthode est limitée à l'envoi individuel d'une information de congestion et ne prévoit pas d'envoi unique de plusieurs informations de congestion, chacune étant associée à un noeud différent. De plus, l'identifiant du noeud congestionné est indiqué lors de l'envoi de l'information de congestion, ce qui impacte le volume de trafic dans le réseau. [0009] Dans la demande de brevet US 20110170410A1, la congestion est indiquée par le noeud congestionné à travers un marquage de paquets. Après réception du paquet indiquant l'état du chemin, une demande de réduction de débit est faite au noeud émetteur par le destinataire, et l'émetteur ajuste son débit pour une durée déterminée. Cependant, cette méthode, au même titre que la précédente, décrit l'envoi individuel de l'information de congestion et ne prévoit pas l'envoi unique de plusieurs informations de congestion. De plus, l'identifiant du noeud congestionné est indiqué lors de l'envoi de l'information de congestion, ce qui impacte le volume de trafic dans le réseau. [0010] Dans la demande de brevet US 20110170408A1, il est décrit une méthode permettant de déterminer le niveau de congestion dans un réseau de communication. La méthode s'appuie sur un mécanisme de notification explicite pour indiquer le niveau de congestion d'un chemin de transmission en fonction de valeurs seuils prédéfinies. Le niveau de congestion dans le réseau quant à lui est déterminé par le destinataire sur la base du pourcentage de paquets reçus marqués par un tlag CE (« Congestion Experienced »). L'inconvénient de cette méthode est qu'elle n'offre pas de moyen d'identification du/des noeud (s) congestionnés afin de prendre une décision de reconfiguration du réseau. Par ailleurs, il n'est pas proposé de possibilité d'envoi unique de plusieurs informations de congestion. [0011] La demande de brevet US 20060176810 Al propose un mécanisme se basant sur une notification explicite de congestion dans les réseaux 3G, qui permet le marquage du champ de données d'un paquet pour indiquer s'il y a la présence d'un noeud en situation de congestion, afin de notifier le destinataire qui peut informer l'émetteur de la présence de congestion. Cette solution ne présente pas de mécanisme d'identification des noeuds en situation de congestion, et n'offre pas de possibilité d'envoi unique de plusieurs informations de congestion. [0012] Les auteurs de l'article « ESRT : Event-to-Sink Reliable Transport in Wireless 3 Scnsor Networks », Yogcsh Sankarasubramaniam, (»et B. Akan et Ian F. Akyildiz in Broadband & Wireless Networking, Laboratory, School of Electrical & Computer Engineering, Gcorgia Instituts of Technology (2003), proposent le protocole (ESRT) pour permettre une détection fiable des événements par des capteurs. Cette proposition inclue un processus de détection de congestion basé sur un mécanisme de notification explicite, où chaque noeud envoie une notification explicite vers une passerelle afin de signaler son état de congestion. Cette façon de procéder génère un surcoût lié aux messages de contrôle. La solution n'offre pas non plus la possibilité d'envoi unique de plusieurs informations de congestion, ni celle de ne pas indiquer les identifiants des noeuds congestionnés. [0013] Les auteurs de l'article « ECODA: Enhanced Congestion Detection and Avoidance for Multiple Class of Traffic in Scnsor », Li Qiang Tao et Feng Qi Yu, IEEE Transactions on Consumer Electronics (Volume: 56, Issue: 3, Aug. 2010) proposent un mécanisme de détection de congestion ECODA dans les réseaux de capteurs sans fil. ECODA détecte la congestion sur la hase de deux valeurs seuils pour le registre d'entrée/sortit du trafic. Ces deux valeurs seuils découpent donc le buffcr en trois parties ("acccpt state", "filter state" et "reject state), afin de pouvoir accepter ou refuser des paquets. Dans cette approche, chaque noeud du réseau surveille l'état de son registre et informe les autres noeuds de son état de congestion afin qu'ils puissent adapter leur débit d'émission. L'inconvénient de cette solution est qu'elle génère un surcoût lié aux messages de contrôle. Par ailleurs, la solution n'offre pas non plus la possibilité d'envoi unique de plusieurs informations de congestion, ni celle de ne pas indiquer les identifiants des noeuds congestionnés. [0014] Les auteurs de l'article « DACC: Dynamic Agile Congestion Control Scheme for Effective Multiple Traffic Wireless Sensor Networks », 2017 International Conference on Wireless Communications, Signal Processing and Networking (WiSPNET), Joseph Auxilius Jude et V. C. Diniesh, proposent un mécanisme (DACC) pour la gestion de la congestion dans les réseaux de capteurs sans fil. Dans cette approche, la passerelle utilise un champ réservé de la trame Ethernet pour informer ses noeuds voisins de son état de congestion afin que ces noeuds puissent établir un ordre de priorité pour le transfert de tout paquet vers la passerelle. Toutefois, dans cette solution, la congestion est traitée uniquement au niveau local (voisinage direct d'un noeud) et elle n'offre pas de possibilité d'envoi unique de plusieurs informations de congestion, ni celle de ne pas indiquer les identifiants des noeuds congestionnés. [0015] Les auteurs de l'article « CCRPM : Centralized Congestion Control Routing Protocol » Yao Yukun, Liu Jiangbing, Xu Dongliang, Ren 711i et Hu Qing, The Journal of China Universities of Posts and Telecommunications, 12 December 2017, proposent le protocole (CCRPM) pour la gestion de la congestion dans les réseaux sans fil à faibles ressources fonctionnant avec le protocole RPL (« Routing Protocol for Low-Power and Lossy Networks »). Un seuil de congestion a été défini pour permettre aux noeuds 'fils' d'un noeud congestionné de pouvoir prendre un nouveau parent moins congestionné. Dans cette solution, le noeud congestionné procède au marquage d'un champ du paquet à destination de ses fils pour signifier son état de congestion à ces derniers. Cependant, cette solution ne permet pas à plusieurs noeuds sur un même chemin de routage vers un point central (par exemple, le noeud RPL root), d'un envoi unique de plusieurs informations de congestion, ni celle de ne pas indiquer les identifiants des noeuds congestionnés. [0016] Ainsi, Il n'existe pas de solution pour contrôler la congestion réseau, qui permette de réduire la surcharge réseau induite par les informations de contrôle de congestion qui sont envoyées à une entité de gestion. Il n'existe pas non plus de solution connue qui permette simultanément de fournir une vue globale de l'état du réseau. [0017] La présente invention permet de pallier les inconvénients des approches connues et de répondre aux besoins précités. [0018] Ainsi, un objet de l'invention est de fournir une solution de contrôle de la congestion dans un réseau, qui réduit la surcharge réseau à travers un mécanisme d'agrégation dans un même bloc transmis au contrôleur du réseau, de toutes les informations de contrôle de congestion provenant de plusieurs noeuds sur un même chemin de routage. Sur la hase de l'information agrégée contenue dans ce bloc, appelé bloc d'informations de congestion (BIC), le contrôleur réseau peut déterminer quels sont les noeuds ayant rapporté une information de congestion et si nécessaire, procéder à la reconfiguration du réseau. [0019] L'invention permet à un ensemble de noeuds sur un chemin de routage d'un réseau maillé de remonter vers un contrôleur du réseau (par exemple un noeud racine ou skin, root » en anglais), des informations de congestion qui sont agrégées dans un bloc d'informations de congestion (BIC) associé à une adresse source, et qui permettent au contrôleur du réseau de déduire le chemin de routage à travers lequel le BIC a transité. [0020] Avantageusement, l'agrégation des informations de congestion des noeuds d'un chemin de routage, permet de ne pas générer une surcharge excessive de la bande passante réseau. En effet, l'information de congestion générée par un noeud est agrégée dans un bloc d'informations de congestion (BIC) sans inclure l'identifiant du noeud. Le BIC va contenir les informations de congestion de l'ensemble des noeuds d'un chemin de routage d'un réseau maillé. Ce bloc se transmet de proche en proche jusqu'à atteindre le contrôleur du réseau. Durant son transit vers le contrôleur du réseau, le BIC peut être mis à jour par tout noeud désirant y inclure son information de congestion. [0021] Dans un mode de réalisation, le bloc d'informations de congestion contient au moins une valeur booléenne (par exemple : vrai/faux ou 0/1) générée par le noeud correspondant considéré. [0022] Dans un mode de réalisation, la valeur booléenne est générée sur la hase du dé- passement ou non d'un seuil prédéfini d'occupation de la mémoire d'entrée/sortie du noeud correspondant considéré. [0023] Selon d'autres modes de réalisation, la valeur du seuil prédéfini est basée sur d'autres paramètres comme par exemple le taux d'usage du processeur. [0024] Dans un mode de réalisation, un noeud rapporte un état de congestion en remplissant le BIC avec une valeur booléenne égale à 'vrai' ou à '1'. [0025] A réception d'un BIC, le contrôleur du réseau peut déterminer l'association {information de congestion, identifiant du noeud} sur la base de l'adresse source du message contenant le BIC et de l'index de l'information de congestion contenue dans le BIC. Le contrôleur peut identifier un noeud qui a envoyé une information de congestion, sur la hase d'un « mapping » entre l'adresse source associée au BIC et une information spécifique associée au BIC, comme par exemple l'index de l'information de congestion dans le BIC. [0026] Une fois les noeuds présentant une congestion (ou un risque de congestion) identifiés, le contrôleur du réseau peut procéder à la reconfiguration du chemin du routage, en excluant les noeuds concernés par la congestion [0027] L'invention est particulièrement avantageuse pour les réseaux maillés en offrant une méthode qui minimise la consommation de la bande passante lors de la remontée de l'information de congestion, tout en permettant l'identification des noeuds congestionnés par le contrôleur du réseau, sans pour autant que leur identifiant ne soit transmis avec l'information de congestion. [0028] La présente invention trouvera de nombreux domaines d'application et en particulier celui de l'Intemet des Objets (IoT) avec les réseaux sans fil à faibles ressources où un ensemble de capteurs remonte des données vers une entité centrale dans le but de surveiller des installations. [0029] Ainsi l'invention est applicable au contexte de l'industrie du futur, le bâtiment in- telligent, ou la ville intelligente. L'invention offre la possibilité de surveiller de manière souple (sans surcharger la bande passante), l'état de congestion du réseau sans fil et le reconfigurer, le cas échéant, de manière à éviter les noeuds congestionnés. [0030] Pour obtenir les résultats recherchés, il est proposé un procédé mis en oeuvre par or- dinateur pour contrôler la congestion dans un réseau maillé opérant un protocole de type Internet Protocol (IP) de communication de messages selon un chemin de routage entre un noeud émetteur et un noeud récepteur, le procédé comprenant les étapes de - recevoir par le noeud récepteur un message IP ; - déterminer si le message IP contient un bloc d'informations de congestion ; 6 - si oui, déterminer l'adresse source du noeud émetteur du message IP ; et - analyser le bloc d'informations de congestion pour identifier tous les noeuds de congestion sur le chemin de routage du message IP entre le noeud émetteur et le noeud récepteur. [0031] Selon des modes de réalisation alternatifs ou combinés: - l'étape de déterminer si le message IP contient un bloc d'informations de congestion consiste à vérifier si le champ de données applicatives du message IP contient au moins un emplacement représentatif d'une information de congestion. - l'étape de déterminer l'adresse source du noeud émetteur du message IP consiste à identifier dans le champ d'entête du message IP, l'adresse source du noeud émetteur. - l'étape d'analyser le bloc d'informations de congestion comprend les étapes de : - vérifier si l'adresse source du noeud émetteur du message IP est présente dans une table de routage du noeud récepteur ; - si oui, vérifier si le bloc d'informations de congestion contient au moins une valeur représentative d'un état de dépassement d'un seuil de congestion ; et - si oui, déterminer l'adresse dudit au moins un noeud en dépassement de seuil de congestion, par la lecture d'une table de correspondance entre la position dans le bloc d'informations de congestion de ladite au moins une valeur représentative d'un état de dépassement d'un seuil de congestion et l'adresse source du noeud émetteur du message IP. - le procédé comprend de plus une étape d'ajouter l'adresse dudit au moins un noeud en dépassement de seuil à une liste d'exclusion de noeuds en dépassement de seuil. - le procédé comprend de plus une étape de reconfigurer le réseau en excluant ledit au moins un noeud en dépassement de seuil. - le bloc d'informations de congestion est généré par l'un des noeuds du chemin de routage entre le noeud émetteur du message IP et le noeud récepteur, ledit noeud générant le bloc d'informations de congestion étant configuré pour déterminer son état de congestion et ajouter une première information de congestion correspondante dans le bloc d'informations de congestion. - le bloc d'informations de congestion reçu par le noeud récepteur contient de plus des informations de congestion ajoutées par au moins un noeud intermédiaire sur le chemin de routage entre le noeud qui a généré le bloc d'informations de congestion et le noeud récepteur, ledit noeud intermédiaire étant configuré pour déterminer son état de congestion et ajouter une information de congestion dans le bloc d'informations de congestion, à la position associée à sa position sur le chemin de routage entre le noeud qui a généré le bloc d'informations de congestion et le noeud récepteur. - ledit au moins un noeud intermédiaire est configuré pour envoyer ledit bloc d'informations de congestion vers un prochain noeud dudit chemin de routage. 7 - le bloc d'informations de congestion contient au moins une valeur booléenne. - ladite au moins une valeur booléenne est générée sur la base du dépassement ou non d'un seuil prédéfini d'occupation de la mémoire d'entrée/sortie du noeud correspondant. [0032] L'invention couvre un produit programme d'ordinateur comprenant des instructions de code non transitoire permettant d'effectuer les étapes du procédé revendiqué, lorsque le programme est exécuté sur un ordinateur. [0033] L'invention couvre de plus un dispositif pour contrôler la congestion d'un réseau maillé, le dispositif comprenant des moyens pour mettre en oeuvre les étapes du procédé revendiqué de contrôle de congestion du réseau. [0034] L'invention adresse aussi un contrôleur réseau d'un réseau maillé de type « Low- Power and Lossy Network » comprenant un dispositif tel que revendiqué. [0035] L'invention vise de plus un réseau maillé comprenant au moins un contrôleur réseau tel que revendiqué et une pluralité de noeuds configurés tels que revendiqués. [0036] D'autres caractéristiques, détails et avantages de l'invention ressortiront à la lecture de la description faite en référence aux dessins annexés donnés à titre d'exemple et qui représentent, respectivement : [0037] [fig.1] montre un exemple d'implémentation du dispositif de l'invention dans un contexte de ville intelligente ; [0038] [fig.2] illustre un exemple de réseau maillé pour mettre en oeuvre le procédé de l'invention dans un mode de réalisation ; [0039] [fig.3a] et [0040] [fig.3b] illustrent l'exemple de datagramme d'un paquet IPv6 pour un réseau LLN (Low-Power and Lossy Network) de type 6LowPAN, comprenant un bloc d'informations de congestion (BIC) selon deux modes de réalisation ; [0041] [fig.4] montre un enchainement d'étapes pour générer un premier bloc d'informations de congestion (BIC) selon un mode (le réalisation du procédé de l'invention ; [0042] [fig.5] montre un enchainement d'étapes pour mettre à jour un BIC pour un noeud in- termédiaire, selon un mode de réalisation du procédé de l'invention ; [0043] [fig.6] montre un enchainement d'étapes du traitement d'un BIC par un contrôleur réseau selon un mode de réalisation du procédé de l'invention ; [0044] [fig.7] montre une représentation d'une table de routage (700) et d'une table de cor- respondance (720) dans un mode de réalisation du procédé de l'invention ; [0045] [fig.8] montre un exemple d'architecture d'un noeud d'un réseau permettant de mettre en oeuvre le procédé de l'invention selon un mode de réalisation ; et [0046] [fig.9] montre un exemple d'architecture d'un noeud contrôleur de réseau permettant de mettre en oeuvre le procédé de l'invention selon un mode de réalisation. 8 [0047] La figure 1 montre un exemple d'implémentation du dispositif de l'invention dans un contexte de ville intelligente. [0048] L'expression « ville intelligente » ou « Smart City » selon l'anglicisme adopté, désigne une ville utilisant les technologies de l'information et de la communication (TTC) et divers dispositifs physiques connectés à un réseau de capteurs tel 'Internet des Objets (IoT), pour améliorer la qualité des services urbains ou encore réduire ses coûts. Une ville intelligente utilise différents capteurs de collecte de données pour fournir des informations permettant de gérer efficacement les ressources et les actifs. Cela peut comprendre les données collectées auprès des citoyens, des dispositifs mécaniques, des actifs, qui sont traitées et analysées pour surveiller et gérer différents systèmes comme les systèmes de circulation et de transport, les centrales électriques, les réseaux d'approvisionnement en eau, la gestion des déchets, les systèmes d'information, les écoles, les bibliothèques, les hôpitaux, etc. [0049] Il existe différents réseaux IoT, allant des réseaux personnels attachés à la personne, souvent liés aux smartphones, à des dispositifs miniaturisés et portables, aux réseaux « indoor » pour les bâtiments (industriels ou domestiques), ou encore aux réseaux « outdoor » à l'échelle des territoires, des pays ou même mondiaux. [0050] Les réseaux peuvent mettre en oeuvre différents protocoles de communication pour permettre de connecter un objet à un réseau. La connexion peut être filaire (câbles, CPL, fibre optique) ou sans fil (radio, cellulaire 2G/3G/4G, Bluctooth, ZigBee, WiFi, Li-Fi, LoRaWan, ...). Un réseau peut comporter des passerelles (ou « gateways » en anglais) pour connecter un objet d'un réseau à Internet. [0051] Un réseau de capteurs comme par exemple celui illustré sur la figure 1 est composé d'une pluralité de capteurs intelligents (100) qui peuvent mesurer un grand nombre de paramètres. Les capteurs permettent de collecter des informations pour connaître l'état d'un objet, sa localisation et sa nature. Les données collectées peuvent être transmises en temps réel aux utilisateurs (citoyens ou autorités concernées) pour par exemple, surveiller le niveau de pollution dans chaque rue de la ville ou encore recevoir une alerte quand le niveau de radiations atteint dépasse une certaine limite. D'autres utilisations des informations remontées par les capteurs peuvent couvrir par exemple l'optimisation de l'usage de l'eau ou des éclairages ou du trafic routier. [0052] La figure 2 illustre un exemple de réseau maillé (200) permettant de mettre en oeuvre le procédé de l'invention dans un mode de réalisation. Pour des raisons de clarté et de simplification de la description, le réseau maillé considéré est un réseau de capteurs IP sans fil à faibles ressources fortement contraints tel qu'un réseau LLN (« Low-Power and Lossy Networks » décrit dans la [RFC 6550]). Les réseaux LLN ont deux caractéristiques principales : - ils sont constitués de noeuds ayant une puissance limitée, une faible mémoire, une 9 capacité de traitement minime et pouvant fonctionner sur batterie (donc potentiellement contraints en énergie) ; - le medium de communication utilisé offre une connectivité fluctuante avec perte, un faible débit et beaucoup d'instabilités (par exemple IEEE 802.15.4, Bluctooth, Low Power Win, ou CPL). [0053] LIFTE (« Internet Engineering Task Force »), l'organisme en charge de la standar- disation des protocoles de l'Internet, a spécifié une architecture IPv6 pour les réseaux LLN et des protocoles de routage, comme le protocole RPL (« Routing Protocol for Low-Power and Lossy Nctworks ») qui permet de construire une topologie de routage sur les réseaux contraints et de définir la manière de transporter des datagrammes TPv6 sur des liens à bas débit et à faible consommation. [0054] Les réseaux de capteurs peuvent être construits selon différents types d'architecture logique comme la topologie en maillage ou « tnesh » selon l'anglicisme consacré, la topologie en étoile ou encore la topologie cellulaire. La figure 2 montre un réseau maillé dont la structure décrit un arbre multi-bonds ayant une pluralité de noeuds (202) convergeant vers un noeud racine (204). Dans la littérature, un noeud à l'extrémité d'un réseau structuré en arbre peut être désigné comme un noeud feuille. Dans la suite de la description, le terme noeud sera indifféremment utilisé pour désigner un noeud quelconque du réseau qu'il soit un noeud feuille ou non. Le terme « noeud » fait référence à un élément du réseau et peut être considéré comme un objet avec une capacité de communication, i.e. un capteur connecté. Dans un mode de réalisation, le noeud racine (204) peut jouer le rôle de contrôleur du réseau, les noeuds (NI à N21) étant les capteurs du réseau maillé RPL. Dans ce type de réseau, les données peuvent transiter clans un sens ascendant des noeuds vers la racine (par exemple pour des remontées de températures, d'alarmes, etc., émanant de noeuds feuilles et/ou de noeuds sur le chemin vers la racine ) ou bien les données peuvent transiter dans un sens descendant du noeud racine vers les noeuds (par exemple pour des requêtes ou des commandes émanant de la racine vers des noeuds feuilles et/ou vers des noeuds sur le chemin entre la racine et des noeuds feuilles). [0055] Selon le principe de l'invention, un noeud (i.e. un capteur) du réseau maillé transmet au contrôleur réseau des informations de contrôle de congestion, tout en permettant au contrôleur réseau de pouvoir identifier le noeud du réseau à l'origine de cette information et en lui permettant de décider d'une reconfiguration du réseau maillé ou non. [0056] Dans un mode de réalisation de l'invention, l'information de congestion d'un noeud, peut représenter le taux d'occupation de la mémoire d'entrée/sortie de ce noeud. Avantageusement, une valeur seuil de taux d'occupation de la mémoire peut être prédéfinie pour permettre d'indiquer un risque de congestion au niveau du noeud. [0057] Dans un mode de réalisation préféré, l'information de congestion transmise par tout noeud du réseau se résume en une valeur booléenne/binaire (par exemple, '1' pour vrai, et '0' pour faux) indiquant si la valeur de congestion a atteint un seuil critique ou non. Ainsi, sur un chemin de routage allant d'un noeud du réseau donné vers le noeud racine, chaque noeud peut indiquer la valeur de son information de congestion dans un même bloc, nommé bloc des informations de contrôle (BIC), au fur et à mesure que ce bloc se transmet de proche-en-proche vers le noeud racine (i.e. le contrôleur réseau). [0058] Lorsque le noeud racine reçoit le paquet comprenant le BIC, il détermine l'adresse source du paquet et l'utilise pour déterminer si sur un noeud donné sur le chemin de routage suivi par le paquet, la valeur seuil de congestion a été dépassée. Si la valeur seuil a été dépassée pour au moins un noeud sur le chemin de routage du paquet contenant le BIC, le contrôleur du réseau peut décider de reconfigurer un ou plusieurs chemins de routage de manière à exclure le(s) noeud(s) ayant rapporté un dépassement de la valeur seuil de congestion. [0059] Les figures 3a et 3h illustrent sur un exemple de datagramme d'un paquet IPv6 pour le cas d'un réseau LLN de type 6LowPAN (« IPv6 Low power Wireless Personal Arca Networks »), la présence d'un bloc d'informations de congestion (BIC) selon deux modes de réalisation de De manière connue, le datagramme d'un paquet IPv6 circulant sur un réseau 6LowPAN comprend différents champs, constitués de champs d'entête (302), et de champs de données (304). L'homme du métier pourra se reporter à la littérature existante pour les définitions et contenus des différents champs, comme par exemple la [RFC 4944]. L'un des champs d'entête spécifie l'adresse de la source du paquet (noeud émetteur). [0060] Les données transportées par un paquet se trouvent dans le champ de données (304). Cela peut être le cas par exemple pour un paquet ICMPv6, un paquet UDP, ou un segment TCP. Avantageusement, le procédé de l'invention permet aux noeuds du réseau de mettre une information de congestion dans des emplacements du champ de données, l'ensemble des informations (au moins une) formant un bloc d'informations de congestion (BIC). La figure 3a montre un BIC (306-a) occupant une partie du champ des données avec les informations de congestion (1, 0, 0,1). La partie non occupée par le BIC peut contenir des données applicatives quelconques, comme par exemple la température du noeud source du paquet contenant le BIC. Elle peut être remplie par un noeud congestionné ou non congestionné. [0061] La figure 3b montre un BIC (306-b) occupant l'intégralité du champ des données avec les informations de congestion (0, 0, 1, 1, 1, 0, 0, 1). Dans un tel cas, il n'y a pas de données applicatives additionnelles renvoyées vers le contrôleur. Cependant, l'homme du métier comprend que ces exemples sont donnés à titre d'illustration, mais ne sont pas limitatifs quant aux valeurs indiquées dans les BIC, ni au nombre 11 d'emplacements occupés. [0062] La figure 4 montre un enchainement d'étapes (400) pour générer et envoyer un premier bloc d'informations de congestion (BIC) selon un mode de réalisation du procédé de l'invention. Il est à noter que sur un chemin donné allant d'un noeud vers la racine, la première information de congestion peut être générée par n'importe quel noeud du chemin, mis à part le noeud racine si le contrôleur réseau est co-localisé à la racine. Si le contrôleur réseau est découplé du noeud racine, celui-ci peut avoir son information de congestion dans le bloc au même titre que les autres noeuds du réseau. [0063] La première étape du procédé est la génération d'un BIC (402) pour un noeud 'V du réseau. La génération d'un BIC au niveau d'un noeud 'i' peut être initiée soit par le contrôleur du réseau soit par le noeud 'V. Dans le cas d'une initiation par le contrôleur du réseau, celui-ci envoie une demande explicite au noeud 'i' l'invitant à générer le BIC. [0064] Le contrôleur du réseau peut initier la génération d'un BIC au niveau d'un noeud 'i' périodiquement (par exemple, toutes les heures) ou sur évènement prédit ou non (par exemple, augmentations/pics du volume de trafic dans le réseau, anticipation d'évènements réseau sur la hase de modèles prédictifs de congestion ou de pannes dans le réseau, ctc.). De manière alternative, un noeud 'V peut initier la génération d'un BIC périodiquement ou sur évènement prédit ou non. [0065] Quand le bloc d'informations de congestion est généré par l'un des noeuds du chemin de routage entre le noeud émetteur du message IP et le noeud racine récepteur, le noeud générant le bloc d'informations de congestion est configuré pour déterminer son état de congestion et ajouter une première information de congestion correspondante dans le bloc d'informations de congestion. Ainsi, dans une étape suivante (404), le procédé permet de calculer le taux d'occupation de la mémoire d'entrée/sortie du noeud 'i', puis de le comparer (406) à une valeur seuil critique de congestion, qui a été préétablie pour ce noeud. Si le résultat de la comparaison indique que le taux d'occupation est supérieur au seuil critique (branche oui), le procédé permet dans une étape suivante (408) de notifier ce dépassement de seuil en générant une valeur binaire associée à cette situation de congestion (par exemple la valeur '1'), puis de mettre (410) dans le BIC cette valeur. [0066] Si le résultat de la comparaison indique que le taux d'occupation est inférieur au seuil critique (branche non), le procédé permet dans une étape suivante (412) de notifier ce non-dépassement de seuil en générant une valeur binaire associée à cette situation de non congestion (par exemple la valeur '0'), puis de mettre (410) dans le BIC cette valeur. [0067] Dans une variante de réalisation, un noeud peut ne mettre aucune entrée dans un BIC s'il reçoit un paquet avec un BIC déjà initialisé avec la valeur biliaire correspondant à 12 sa situation de congestion ou non-congestion. [0068] Dans une étape suivante (414), le procédé se poursuit par l'envoi du BTC sur le chemin vers la racine (sens ascendant). Deux modes d'envoi du BIC sont possibles : - l'envoi via un paquet IP en transit vers la racine : dans ce cas, le noeud insère le BTC dans le paquet en question (par exemple dans le champ de données). L'adresse source associée à ce BIC est donc l'adresse source du paquet IP ; - la génération d'un paquet IP pour l'envoi du BIC : dans ce cas, le noeud insère le BIC dans le paquet en question (par exemple dans le champ de données). L'adresse source associée à ce BIC est donc l'adresse source du noeud. [0069] La figure 5 illustre les étapes (500) du procédé de remplissage d'un BTC applicable à un noeud 'parent' qui reçoit un BTC existant d'un noeud 'fils'. Le noeud parent est configuré, lorsqu'il reçoit (502) un BIC transitant dans un sens ascendant, pour calculer (504) le taux d'occupation de sa mémoire d'entrée/sortie, puis le comparer (506) à une valeur seuil critique de congestion, qui a été préétablie pour ce noeud. Le procédé permet ensuite de générer (508 ou 512) une valeur binaire (par exemple '0' ou `1') en fonction du résultat de la comparaison avec le seuil critique préétabli. La valeur binaire est ensuite indiquée (510) dans le bloc d'informations de congestion. Comme pour le cas de la génération de la première information de congestion, le noeud peut décider de ne rien indiquer sur le BIC si ce bloc en question est déjà initialisé avec la valeur binaire que le noeud souhaite saisir. Le procédé permet ensuite d'envoyer (514) le BIC complété sur le chemin vers la racine (sens ascendant) en utilisant l'un des deux modes d'envoi possibles précédemment décrits. [0070] Revenant sur l'étape de remplissage du BIC (412 ou 512), le procédé permet de re- chercher à quelle position l'information de congestion associée à un noeud doit être indiquée. Lorsque le résultat binaire est généré après la comparaison du taux d'occupation de la mémoire d'entrée/sortie avec la valeur seuil, le procédé permet de parcourir le BIC jusqu'à l'index correspondant à la position du noeud dans la branche. Dans un mode de réalisation, les index d'un bloc sont ordonnés par ordre croissant (1 à n), allant du premier bond depuis la racine jusqu'au noeud feuille. Ainsi, en considérant par exemple la branche `Racine-N20-N16-N7' de la figure 2, les noeuds N20, N16, et N7 auront respectivement les index 1, 2, et 3, et les noeuds N20, N16 et N7 porteront leur valeur binaire respective aux emplacements correspondants, comme illustré par la table suivante : [0071] [Tableauxl] 13 [0072] Dans un mode de réalisation où un noeud 'S' est le premier à générer une information de congestion pour une instance donnée du BIC, il génère alors un BIC contenant une seule entrée dans laquelle il met sa valeur calculée de l'information de congestion. Tout noeud sur le chemin allant du noeud 'S' vers la racine peut ajouter sa propre valeur d'information de congestion à la fin du BIC, comme illustré par la table suivante pour le même exemple des noeuds N7, N16 et N20, où le premier noeud N7 crée le BIC avec une première valeur '0', puis le noeud suivant N16, ajoute sa valeur de BIC '1' et le noeud suivant N20 ajoute sa valeur de BIC '0' à la fin : [0073] [Tableaux2] [0074] Dans un mode de réalisation préférentiel, tous les noeuds sur le chemin implémentent le dispositif de l'invention, et sont configurés pour indiquer leur valeur d'information de congestion dans un BIC. Cependant pour des modes de réalisation où certains noeuds sur le chemin allant du noeud initiateur de BIC 'S' vers la racine n'implémentent pas cette solution, le contrôleur du réseau est configuré pour le/les ignorer. Ainsi, par exemple, un noeud qui n'implémente pas le dispositif de l'invention n'aura pas d'indexe, ou alors il a un index connu par le contrôleur du réseau. Cette dernière alternative suppose que la valeur associée à l'index en question dans le BIC est initialisée par le noeud générateur du BIC et est alors ignorée par le contrôleur du réseau. [0075] La figure 6 montre un enchainernent d'étapes (600) du traitement d'un BIC par un contrôleur réseau selon un mode de réalisation du procédé de l'invention. Dans un mode de réalisation, le contrôleur réseau stocke dans sa mémoire tous les chemins de routage allant de l'extrémité du réseau maillé vers le noeud racine. Dans l'exemple du réseau en arbre RPL, il s'agit de tous les chemins entre les noeuds feuilles et le noeud racine, et le noeud racine stocke en mémoire tous les chemins de routage allant des noeuds feuilles vers le noeud racine. 100761 Le procédé débute quand le contrôleur réseau reçoit (602) un paquet contenant un BIC d'un noeud fils du réseau. Le procédé permet de retrouver (604) l'adresse source @s' du paquet (dans les champs d'entête par exemple), puis d'utiliser l'adresse source du paquet contenant le BIC et les index du BIC pour déterminer quels sont les éventuels noeuds sur le chemin entre l'adresse source et le contrôleur qui ont rapporté 14 un dépassement du seuil critique d'occupation de leur mémoire d'entrée/sortie. Ces opérations sont couvertes par les étapes successives (606) de vérification que l'adresse source `@s' du paquet est présente dans une table de routage du contrôleur et que le BIC du paquet reçu n'est pas vide (sinon le procédé s'arrête); puis de vérification (608) sur tous les emplacements (les index) du BIC s'il y a au moins une valeur indiquant un état de dépassement de seuil. Si au moins une valeur indique une congestion (branche oui de 608), le procédé détermine (610) par une table correspondance entre la position (l'index) de la valeur dans le BIC et l'adresse du noeud source du message, l'adresse du noeud en dépassement de seuil. [0077] En reprenant l'exemple de la Table 1 du chemin (N7, N16, N20) de la figure 2, le BIC reçu par le contrôleur du réseau contient les valeurs (0, 1, 0). Le procédé permet de déterminer que seul le noeud d'index 2 rapporte une information de congestion. En effet, sur la hase de l'adresse source indiquée dans les champs entête du paquet contenant le BIC (@s=@N7), puis par une correspondance entre les index (1, 2, 3) et les noeuds (N20, N16, N7), le procédé permet de déterminer que l'adresse du noeud d'index 2 est celle du noeud N16 : @N16. [0078] La figure 7 illustre une représentation d'une table de routage (700) et d'une table de correspondance (720) (index BIC, adresse Noeud) générée de manière temporaire à partir de la table de correspondance pour un noeud source d'adresse @s=@N7. L'homme du métier comprend qu'il peut y avoir autant de tables de correspondance que de sources possibles pour un paquet contenant un BIC. Dans un mode de réalisation, toute table de correspondance peut être générée temporairement à la réception d'un paquet contenant un BIC, être stockée en mémoire, puis supprimée une fois utilisée. Cette génération temporaire peut s'effectuer en parcourant par exemple, séquentiellement ligne par ligne, les différentes entrées (710, 712, 714) de la table de routage (700) stockée dans la mémoire du contrôleur du réseau, pour rechercher la première occurrence de l'adresse source @s (voir étape 1 sur la table 700). Une fois cette adresse @s trouvée, les différentes adresses sur les différents bonds à partir du premier bon depuis la racine jusqu'à cette adresse @s, sont copiées dans la première colonne (712) de la table de correspondance (720). Ainsi, les adresses N20 du premier bond, N16 du deuxième bond, et N7 du troisième bond sont copiées dans une colonne des adresses (722) de la table de correspondance (voir étape 2 sur la table 720). L'index de chaque adresse copiée est déduit à partir de la position de cette même adresse dans l'entrée trouvée dans la table de routage (700). Par exemple, l'index peut être un compteur du numéro de la colonne, ou du nombre de bonds depuis la racine, associé à l'adresse à indexer. Dans l'exemple choisi, la colonne (710) du 3ème bond est associée à l'index '3', la colonne (712) du 2ème bond est associée à l'index '2' et la colonne (714) du I bond est associée à l'index '1' L'index qui est déduit est ensuite copié dans une deuxième colonne des index (724) de la table de correspondance (voir étape 3 sur la figure 2). [0079] Revenant au procédé de la figure 6, après avoir déterminé l'adresse d'un noeud indiquant une valeur de dépassement de seuil (étape 610), le procédé permet d'ajouter (612) l'adresse du noeud en dépassement de seuil à une liste d'exclusion de noeuds en dépassement de seuil pouvant être exclus lors d'une éventuelle reconfiguration. Puis le procédé poursuit par l'analyse de la prochaine valeur du BIC (614) jusqu'à la dernière valeur présente dans le BIC. [0080] A la fin de l'analyse du BIC (branche oui 614), si au moins une entrée du BIC indique un dépassement du seuil critique d'occupation d'une mémoire d'entrée/sortie, le procédé permet de reconfigurer le réseau en calculant une nouvelle route (616) en établissant un chemin alternatif qui exclue le ou les noeuds ayant rapporté un dépassement. [0081] En cas de changement dans un chemin du réseau RPL, les noeuds impactés sur le chemin concerné, peuvent déduire leur nouvel index à partir de diverses informations issues de fonctionnalités et protocoles standards (par exemple par l'option « hop-hy-hop » de l'entête d'extension IPv6, par la valeur 'rang' (« rank ») du message `DIO' (« DODAG Information Ohject ») du protocole RPL, etc.). Ces aspects n'entrent pas dans le champ direct de l'objet de l'invention et ne sont pas plus développés. [0082] La figure 8 illustre un exemple d'architecture d'un noeud (800) d'un réseau permettant de mettre en oeuvre le procédé de l'invention selon différents modes de réalisation. Dans un mode de réalisation particulier, un tel noeud peut être un objet connecté d'un réseau LLN et comprendre un ou plusieurs processeurs (802), un ou plusieurs capteurs (804), une source d'alimentation (806), une ou plusieurs interfaces réseau d'Entrée/Sortie (808), et une mémoire (810) interconnectée aux autres composants par un bus (812). [0083] Les interfaces d'Entrée/Sortie (808) permettent de connecter le noeud (800) au réseau auquel il appartient afin de transmettre vers et/ou recevoir des messages d'autres noeuds et/ou d'un contrôleur de réseau. [0084] La mémoire (810) est configurée pour stocker des instructions de code de différents programmes (812, 814, 816) exécutables par le(s) processeur(s) (802) selon le système d'exploitation existant (818), et pour stocker des données selon différents formats (820) en fonction des modes de réalisation de l'invention. [0085] Les différents programmes comprennent au moins un programme lié à un processus de routage (812) des messages entre les noeuds du réseau, un programme lié à un processus de vérification de l'occupation d'une mémoire d'Entrée/Sortie (815), et un programme lié à un processus de traitement du BIC (816) selon les principes de 16 l'invention, tels que décrits par les figures 4 et 5. [0086] La figure 9 illustre un exemple d'architecture d'un noeud contrôleur de réseau (900) permettant de mettre en oeuvre le procédé de l'invention selon différents modes de réalisation. Dans un mode de réalisation particulier, le réseau (908) est un réseau LLN composé de noeuds ayant une architecture selon la figure 8. [0087] Le contrôleur de réseau (900) comprend un ou plusieurs processeurs (902), une source d'alimentation (904), une ou plusieurs interfaces réseau d'Entrée/Sortit (906), et une mémoire (910) interconnectée aux autres composants par un bus (912). [0088] Les interfaces d'Entrée/Sortie (906) permettent de connecter le contrôleur réseau (900) au réseau (908) qu'il contrôle afin de transmettre vers et/ou recevoir des messages des noeuds (800) du réseau. [0089] La mémoire (910) est configurée pour stocker des instructions de code de différents programmes (916, 918) exécutables par lc(s) processeur(s) (902) selon le système d'exploitation existant (914), et pour stocker des données selon différents formats (920) en fonction des modes de réalisation de l'invention. [0090] Les différents programmes comprennent au moins un programme lié à un processus de gestion de la congestion réseau (916) et un programme lié à un processus de traitement du BIC (918) selon les principes de l'invention tels que décrits par les figures 6 et 7. La mémoire (910) permet de plus de stocker la topologie du réseau et/ou la table de routage, ainsi que la table de correspondance (917) utilisées dans les processus de gestion de la congestion et de traitement du BIC. [0091] Ainsi, la présente description illustre une implémentation préférentielle de l'invention, mais n'est pas limitative. Des exemples sont choisis pour permettre une bonne compréhension des principes de l'invention et une application concrète, mais ne sont en rien exhaustifs et doivent permettre à l'homme du métier d'apporter des modifications et des variantes d'implémentation en conservant les mêmes principes. [0092] L'invention peut s'implémenter à partir d'éléments matériel et/ou logiciel. Elle peut être disponible en tant que produit programme d'ordinateur exécuté par un processeur dédié ou par un contrôleur mémoire d'un système de stockage, et qui comprend des instructions pour exécuter les étapes des procédés dans leurs différents modes de réalisation. 17 REVENDICATIONS[Revendication 1] Un procédé mis en oeuvre par ordinateur pour contrôler la congestion dans un réseau maillé opérant un protocole de type Internet Protocol (IP) de communication de messages selon un chemin de routage entre un noeud émetteur et un noeud récepteur, le procédé comprenant les étapes suivantes : - recevoir par le noeud récepteur un message IP ; - déterminer si le message IP contient un bloc d'informations de congestion ; - si oui, déterminer l'adresse source du noeud émetteur du message IP ; et - analyser le bloc d'informations de congestion pour identifier tous les noeuds de congestion sur le chemin de routage du message IP entre le noeud émetteur et le noeud récepteur. [Revendication 2] Le procédé selon la revendication 1 dans lequel l'étape de déterminer si le message IP contient un bloc d'informations de congestion consiste à vérifier si le champ de données applicatives du message IP contient au moins un emplacement représentatif d'une information de congestion. [Revendication 3] Le procédé selon la revendication 1 ou 2 dans lequel l'étape de dé- terminer l'adresse source du noeud émetteur du message IP consiste à identifier dans le champ d'entête du message IP, l'adresse source du noeud émetteur. [Revendication 4] Le procédé selon l'une quelconque des revendications 1 à 3 dans lequel l'étape d'analyser le bloc d'informations de congestion comprend les étapes de : - vérifier si l'adresse source du noeud émetteur du message IP est présente dans une table de routage du noeud récepteur ; - si oui, vérifier si le bloc d'informations de congestion contient au moins une valeur représentative d'un état de dépassement d'un seuil de congestion ; et - si oui, déterminer l'adresse dudit au moins un noeud en dépassement de seuil de congestion, par la lecture d'une table de correspondance entre la position dans le bloc d'informations de congestion de ladite au moins une valeur représentative d'un état de dépassement d'un seuil de congestion et l'adresse source du noeud émetteur du message IP. [Revendication 5] Le procédé selon la revendication 4 comprenant de plus une étape d'ajouter l'adresse dudit au moins un noeud en dépassement de seuil à 18 une liste d'exclusion de noeuds en dépassement de seuil. [Revendication 6] Le procédé selon la revendication 5 comprenant de plus une étape de re- configurer le réseau en excluant ledit au moins un noeud en dépassement de seuil. [Revendication 7] Le procédé selon l'une quelconque des revendications 1 à 6 dans lequel le bloc d'informations de congestion est généré par l'un des noeuds du chemin de routage entre le noeud émetteur du message IP et le noeud récepteur, ledit noeud générant le bloc d'informations de congestion étant configure pour déterminer son état de congestion et ajouter une première information de congestion correspondante dans le bloc d'informations de congestion. [Revendication 8] Le procédé selon la revendication 7 dans lequel le bloc d'informations de congestion reçu par le noeud récepteur contient de plus des informations de congestion ajoutées par au moins un noeud intermédiaire sur le chemin de routage entre le noeud qui a généré le bloc d'informations de congestion et le noeud récepteur, ledit noeud intermédiaire étant configure pour déterminer son état de congestion et ajouter une information de congestion dans le bloc d'informations de congestion, à la position associée à sa position sur le chemin de routage entre le noeud qui a généré le bloc d'informations de congestion et le noeud récepteur. [Revendication 9] Le procédé selon la revendication 8 dans lequel ledit au moins un noeud intermédiaire est configuré pour envoyer ledit bloc d'informations de congestion vers un prochain noeud dudit chemin de routage. [Revendication 10] Le procédé selon l'une quelconque des revendications 1 à 9 dans lequel le bloc d'informations de congestion contient au moins une valeur booléenne. [Revendication 11] Le procédé selon la revendication 10 dans lequel ladite au moins une valeur booléenne est générée sur la base du dépassement ou non d'un seuil prédéfini d'occupation de la mémoire d'entrée/sortie du noeud correspondant. [Revendication 12] Un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code non transitoire permettant d'effectuer les étapes du procédé selon l'une quelconque des revendications 1 à 11, lorsque ledit programme est exécuté sur un ordinateur. [Revendication 13] Un dispositif pour contrôler la congestion d'un réseau maillé, le dispositif comprenant des moyens pour mettre en oeuvre les étapes du procédé de contrôle de congestion du réseau selon l'une quelconque des 19 [Revendication 14] revendications 1 à 11. [Revendication 15] Un contrôleur réseau d'un réseau maillé de type « Low-Power and Lossy Network » comprenant un dispositif selon la revendication 13. Un réseau maillé comprenant au moins un contrôleur réseau selon la revendication 14 et une pluralité de noeuds configurés selon l'une quelconque des revendications 7 à 9.